Apparence
Uubu.fr

Les systèmes Linux, l’open source, les réseaux, l’interopérabilité, etc.
« Il vaut mieux viser la perfection et la manquer que viser l’imperfection et l’atteindre. » (Bertrand Arthur William RUSSEL)
21 juillet 2014

htmlpdflatexmanmd




rfc4556

rfc4556

PKINIT

   Ce document décrit des extensions au protocole Kerberos. Ces extensions fournissent une méthode pour intégrer le clé de chiffrement publique dans l'échange d'authentification initiale, en utilisant les clé asymétrique pour les algorithmes de chiffrement et/ou de signature dans les champs de donnée de pré-authentification.

   La pierre angulaire de Kerberos 5 sont le ticket et l'authenticator. Un ticket encapsule une clé symétrique ( la clé de session ) dans un enveloppe ( un message publique ) à destination d'un service spécifique. Le contenu de ce ticket est chiffré avec une clé secrète partagée entre le principale de service et le KDC. La partie chiffrée du ticket contient le nom du principal du client, et d'autre éléments. Un authenticator est un enregistrement qui est généré en utilisant la clé de session du ticket associé. La clé de session est connue du client qui demande le ticket. Le contenu de l'authenticator est chiffré avec cette clé de session et contient un timestamp et le nom du principal du client.

   Le protocole Kerberos 5 consiste des échanges de messages suivant, entre le client et le KDC, et le client et les services d'application:

- L'échange d'AS, où le client obtient un ticket initial, les TGT.
- L'échange TGT, où le client utilise sont TGT pour s'authentifier et demander des tickets de service.
- L'échange AP, où le client faite des demandes avec des messages consistant d'un ticket de service et d'un authenticator qui certifie que le client possède la clé de session du ticket. Le serveur peut optionnellement y répondre. Ces échange négocient généralement des clé de session symétriques.

Généralement, l'AS et le TGS sont intégrés dans un seul périphérique, appelé le KDC.
___________________+- - - - - - - +
________+- - - - -›|__KDC_________|
AS-REQ_/___+- - - -|______________|
______/___/________+- - - - - - - +
_____/___/__________^___________|
____/____|AS-REP___/____________|
___|_____|________/_TGS-REQ_____+_TGS-REP
___|_____|_______/_____________/
___|_____|______/_____________/
___|_____|_____/___+- - - - -+
___|_____|____/___/
___|_____|___/___/
___|_____|__/___/
___|_____v_/___v
__++- - -+- - - - +_____________+- - - - - - - - -+
__|__Client_______+- - - - - - ›|__Application____|
__|_______________|____AP-REQ___|__Server_________|
__|_______________|‹- - - - - - |_________________|
__+- - - - - - - -+____AP-REP___+- - - - - - - - -+

   Dans l'échange AS, la réponse du KDC contient la clé de session du ticket, avec d'autres éléments, qui est chiffré en utilisant une clé partagée entre le client et le KDC. La clé de réponse AS est généralement dérivée du mot de passe du client. Cependant, pour les personnes physiques, la force du protocole Kerberos est sujette à la force du mot de passe.

   L'utilisation d'une clé asymétrique sous la forme d'un certificat X.509 permet de faciliter l'authentification de l'origine des données et la préservation du secret. Un PKI fournis une gestion et des mécanismes de distribution des clés qui peuvent être utilisé pour établir une authentification et une communication sûre.

   L'avantage du TGT Kerberos est que le client expose sa clé à long-terme secrète seulement une fois. Le TGT est ses clé de session associés peuvent être utilisées pour d'autres demandes de ticket. Cela permet à toutes les autres authentification d'être indépendant de la méthode d'authentification initiale. En plus, l'utilisation de clé symétrique après l'authentification initial est préférable pour des raisons de performance.

Extensions

   Cette section décris les extensions pour supporter le chiffrement à clé publique dans la requête initiale pour un ticket. Brièvement, cet document définis les extensions suivantes:

- Le client indique l'utilisation d'une authentification à clé publique en incluant un pré-authentifiant spécial dans la demande initiale. Ce pré-authentifiant contient la clé publique du client et une signature.
- Le KDC teste la demande du client avec sa stratégie d'authentification et les autorités de certification de confiance.
- Si le demande passe les tests de vérification, le KDC répond normalement, mais la réponse est chiffrée en utilisant soit:

        - Un clé générée avec l'échange DH avec le client, signé avec la clé de signature du KDC; ou
        - Un clé de chiffrement symétrique, signée avec la clé de signature du KDC est chiffrée en utilisant la clé publique du client.

- Le client valide la signature du KDC, obtient la clé de chiffrement, déchiffre la réponse, et traite la suite normalement.

Algorithmes requis

   Toutes les implémentations PKINIT doivent supporter les algorithmes suivant:

- l'enctype de la réponse AS: aes128-cts-hmac-sha1-96 and aes256-cts-hmac-sha1-96
- L'algorithme de signature: sha-1WithRSAEncryption
- La méthode de livraison de la clé de la réponse AS: La méthode DH.

   En plus, les implémentations de cette spécification doivent être capable de traiter l'extension EKU et le id-pkinit-san otherName de l'extention SAN dans les certificat X.509.

Algorithmes recommandés

   Toutes les implémentations PKINIT devraient supporter les algorithmes suivant:

- La méthode de livraison de la clé de la réponse AS: voir la section Utiliser le chiffrement à clé publique

   Pour les implémentations qui supporte le chiffrement à clé publique pour les méthodes de livraison de clé, Les algorithmes suivant doivent être supportés:

- Les algorithmes de transport de clé identifiés dans le champ keyEncryptionAlgorithm du type KeyTransRecipientInfo pour le chiffrement de clé temporaire dans le champ encryptedKey avec un clé publique: rsaEncryption.
- Les algorithmes de chiffrement de contenu identifiés dans le champ contentEncryptionAlgorithm du type EncryptedContentInfo pour le chiffrement de la clé de réponse AS avec la clé temporaire contenue dans le champ encryptedKey du type KeyTransRecipientInfo: des-ede3-cbc

Messages définis et types de chiffrement

PKINIT utilise les types de pré-auhentification suivants:
PA_PK_AS_REQ 16
PA_PK_AS_REP 17
PKINIT utilisé les types de données d'autorisation suivants:
AD_INITIAL_VERIFIED_CAS 9
PKINIT introduit les nouveaux codes d'erreurs suivants:
KDC_ERR_CLIENT_NOT_TRUSTED 62
KDC_ERR_INVALID_SIG 64
KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED 65
KDC_ERR_CANT_VERIFY_CERTIFICATE 70
KDC_ERR_INVALID_CERTIFICATE 71
KDC_ERR_REVOKED_CERTIFICATE 72
KDC_ERR_REVOCATION_STATUS_UNKNOWN 73
KDC_ERR_CLIENT_NAME_MISMATCH 75
KDC_ERR_INCONSISTENT_KEY_PURPOSE 77
KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED 78
KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED 79
KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED 80
KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED 81
PKINIT utilise les type de données suivant pour les erreurs:
TD_TRUSTED_CERTIFIERS 104
TD_INVALID_CERTIFICATES 105
TD_DH_PARAMETERS 109

Type de chiffrement Kerberos pour CMS Algorithm Identifiers

   PKINIT définis les numéros de type de chiffrement Kerberos, qui peut être utilisé dans le champ etype du message AS-REQ pour indiquer au KDC l'acceptation du client les algorithmes correspondant ( incluant les algorithmes de transport de clé algorithmes de chiffrement de contenu, et algorithmes de signature ). Les type de chiffrement dans le champ etype sont dans l'ordre décroissant de préférence du client. La présent de chacun de ces types de chiffrement dans le champ etype est équivalent à la présence du l'OID l'algorithme correspondant la le champ supportedCMSTypes, et l'ordre de préférence dans le champ supportedCMSTypes a précédence sur l'ordre de préférence dans le champ etype.


Kerberos Encryption Type Name____Num____Corresponding Algorithm OID
=============================____===____===============================
id-dsa-with-sha1-CmsOID__________ 9_____id-dsa-with-sha1 [RFC3370]
md5WithRSAEncryption-CmsOID______10_____md5WithRSAEncryption [RFC3370]
sha-1WithRSAEncryption-CmsOID____11_____sha-1WithRSAEncryption [RFC3370]
rc2-cbc-EnvOID___________________12_____rc2-cbc [RFC3370]
rsaEncryption-EnvOID_____________13_____rsaEncryption [RFC3447][RFC3370]
id-RSAES-OAEP-EnvOID_____________14_____id-RSAES-OAEP [RFC3447][RFC3560]
des-ede3-cbc-EnvOID______________15_____des-ede3-cbc [RFC3370]

   Les numéros de type de chiffrement ci-dessus sont seulement utilisé pour indiquer le support des algorithmes correspondant dans PKINIT; ils ne correspondant pas aux types de chiffrement Kerberos actuels et ne doivent pas être utilisé dans le champ etype. L'assignation des numéros de type de chiffrement Kerberos pour indiquer le support pour les algorithmes CMS est déprécié, et les nouveaux numéros ne devraient pas être assignés dans ce but. À la place, le champ supportedCMSTypes devrait être utilisé pour identifier les algorithmes supportés par le client et l'ordre de préférence du client.

   Pour une intéropérabilité maximiale, cependant, les clients PKINIT désirant indiquer au KDC le support pour un ou plusieur algorithmes listés ci-dessus devraient inclure les numéros dans le champ etype de l'AS-REQ.

Syntaxe et utilisation de la pré-authentification PKINIT

   Cette section définie la syntaxe et l'utilisation des champs de pré-authentification utilisés par PKINIT.

Génération d'une demande client

   La demande d'authentification initilale ( AS-REQ ) est envoyée avec un élément de pré-authentification, dont le padata-type est PA PK_AS_REQ et dont padata-value contient le DER du type PA-PK-AS-REQ.


PA-PK-AS-REQ ::= SEQUENCE {
    signedAuthPack    [0] IMPLICIT OCTET STRING
    trustedCertifiers [1] SEQUENCE OF ExternalPrincipalIdentifier OPTIONAL
    kdcPkId [2] IMPLICIT OCTET STRING OPTIONAL
    ...
}
DHNonce ::= OCTET STRING
ExternalPrincipalIdentifier ::= SEQUENCE {
    subjectName [0] IMPLICIT OCTET STRING OPTIONAL
    issuerAndSerialNumber [1] IMPLICIT OCTET STRING OPTIONAL
    subjectKeyIdentifier [2] IMPLICIT OCTET STRING OPTIONAL
    ...
}
AuthPack ::= SEQUENCE {
    pkAuthenticator [0] PKAuthenticator,
    clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL
    supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier OPTIONAL
    clientDHNonce [3] DHNonce OPTIONAL
    ...
}
PKAuthenticator ::= SEQUENCE {
    cusec [0] INTEGER (0..999999)
    ctime [1] KerberosTime
    nonce [2] INTEGER (0..4294967295)
    paChecksum [3] OCTET STRING OPTIONAL
    ...
}

signedAuthPack Contient un CMS type ContentInfo. Le champ contentType est id-signedData (1.2.840.113549.1.7.2), et le champ tontent est un SignedData. le Champ eContentType pour le type SignedData est id-pkinit-authData (1.3.6.1.5.2.3.1), et le champ eContent contient le DER du type AuthPack
trustedCertifiers Liste de CA, trusté par le client qui peuvent être utilisés pour certifier le KDC.
kdcPkId Contient un CMS type SignerIdentifier. Identifie, si présent, une clé publique d'un KDC particulier que le client a déjà.
subjectName Conient un nom de type PKIX. Identifie le sujet du certificat par le nom distinct du sujet.
issuerAndSerialNumber Contient un type CMS IssuerAndSerialNumber. Identifie un certificat du sujet.
subjectKeyIdentifier Identifie la clé publique du sujet par une ID de clé.
clientPublicValue Spécifie les paramètres de domaine DH et la valeur de clé publique du client.
supportedCMSTypes Liste d'algorithmes CMS qui identifie les algorithmes de transport de clé ou de signature supportés par le client, par ordre de préférence.
clientDHNonce Présent seulement si le client indique qu'il souhaite ré-utiliser les clés DH ou autoriser le KDC à le faire.
paChecksum Contient le checksum SHA1.

eContentType ce champ pour le type SignedData est id-pkinit-authData: { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) pkinit(3) authData(1) }
eContent Ce champ pour le type SignedData contient le DER du type AuthPack
signerInfos Ce champ pour le type SignedData contient un simple signerInfo, qui contient la signature du type AuthPack.
AuthPack Cette structure contient un PKAuthenticator, les informations de clé publique client, les type de chiffrement CMS supportés et un DHNonce.

        pkAuthenticator certifie au KDC que le client a une connaissance récente de la clé de signature qui authentifie le client.
        clientPublicValue spécifie les paramètre de domaine DH et la valeur de clé publique du client. La valeur de clé publique SH est encodée en BIT STRING.
        clientPublicValue est présent seulement si le client désire utilisé DH.
        supportedCMSTypes spécifie la liste des ID d'algorithmes CMS qui sont supportés par le client et peut être utilisé pour identifier un algorithme de signature ou un algorithme de transport de clé dans le champ keyEncryptionAlgorithm de type KeyTransRecipientInfo, ou un algorithme de chiffrement de contenu dans le champ contentEncryptionAlgorithm de type EncryptedContentInfo.
        clientDHNonce est décrit plus bas

ctime dans la structure PKAuthenticator contient l'heure courante dans l'hôte du client, et le champ cusec est la partie micro-secondes. Ils sont utilisé ensemble pour spécifier un timestamp suffisamment précis. le champ nonce est choisi au hasard. le champ paChechsum doit être présent et contient un checksum SHA1. Pour faciliter les migrations futures de l'utilisation de SHA1, le champ paChecksum est optionnel: quand la demande est étendue à la négociation d'algorithmes de hash, le nouveau client qui souhaite ne pas utiliser SHA1 va envoyer la demande sans ce champ. Le KDC ce conformant à cette spécification doivent retourner KRB-ERROR avec le code KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED. Cela permet à un nouveau client de retenter avec SHA1 si permis par la stratégie locale.
certificates de type SignedData, contient les certificats utilisés pour la construction du chemin de certification, pour que le KDC puisse vérifier la signature sur le type AuthPack. Cet certificats devraient être suffisants pour construire au moins chemin de certification depuis le certificat client. Le client doit être capable d'inclure un tel jeu de certificats s'il est configuré pour le faire. Le champ certificates ne doit pas contenir de certificat CA root.
clientPublicValue La valeur public Diffie-Hellman est inclues si le client veut utiliser la méthode DH. Les paramètres de domaine DH pour la clé public du client sont spécifiés dans le champ algorithm du type SubjectPublicKeyInfo, et la valeur de clé publique DH du client est mapppé à un ubjectPublicKey. En utilisant la méthode d'agrément de clé DH, les implémentations doivent supporter Oakley 1024-bits Modular Exponential (MODP) group 2 et OakleOakley 2048-bits Modular Exponential (MODP) group 14 et devraient supporter OakleOakley 4096-bits Modular Exponential (MODP) group 16.

   La structure ExternalPrincipalIdentifier est utilisée dans ce document pour identifier la clé publique du sujet. Cette structure est construite comme suit:

subjectName Contient un nom de type PKIX encodé en accord avec la rfc3280. Ce champ identifie le sujet du certificat par un nom de sujet distinct. Ce champ est requis quand il y a un distinguished subject name présent dans le certificat utilisé.
issuerAndSerialNumber Contient un type CMS encodé. Ce champ identifie un certificat du sujet. Il est requis pour TD-INVALID-CERTIFICATES et TD-TRUSTED-CERTIFIERS
subjectKeyIdentifier Identifie la clé publique du sujet par une key identifier. Quand un certificat X.509 est référencé, cette Key Identifier matche la valeur d'extention subjectKeyIdentifier. Quand d'autres fomats de certificat sont référencés, les documents qui spécifient le format de certificat et leur utilisation avec le CMS doivent inclurent les détails du match de key identifier au champ de certificat approprié.

   Le champ trustedCertifiers du type PA-PK-AS-REQ contient une liste de CA, trustés par le client, qui peut être utilisé pour certifier le KDC. Chaque ExternalPrincipalIdentifier identifie une CA ou un certificat CA. Le champ kdcPkId du type PA-PK-AS-REQ contient un type CMS SignerIdentifier encodé. Ce champ identifie, si présent, une clé publique d'un KDC particulier que le client possède.

Réception de la demande client

   Une fois reçu la demande du client, le KDC la valide. Le KDC vérifie la signature du client dans le champ signedAuthPack. Si, pendant la validation du certificat du client, le KDC ne peut pas construire un chemin de validation, il retourne un KRB-ERROR avec le code KDC_ERR_CANT_VERIFY_CERTIFICATE. Le e-data qui l'accompagne est un TYPED-DATA qui contient un élément dont data-type est TD_TRUSTED_CERTIFIERS, et contient le DER du type TD-TRUSTED-CERTIFIERS:


TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
    ExternalPrincipalIdentifier
    -- Identifies une liste de CA trustés par le KDC.
    -- Chaque ExternalPrincipalIdentifier identifies une CA
    -- ou un certificat CA

   Une fois ce message d'erreur reçu, le client devrait retenter seulement s'il a un jeu de certificats différent qui forment un chemin de certification acceptable pour le KDC.

   Si, pendant le traitement du chemin de certification, de KDC détermine qu'une signature dans le champ signedAuthPack est invalide, il retourne KRB-ERROR avec le code KDC_ERR_INVALID_CERTIFICATE. Le e-data qui l'accompagne est un TYPED-DATA qui contient un élément dont data-type est TD_INVALID_CERTIFICATES, et contient le DER du type TD-INVALID-CERTIFICATES:

TD-INVALID-CERTIFICATES ::= SEQUENCE OF
    ExternalPrincipalIdentifier
    -- Chaque ExternalPrincipalIdentifier identifie un
    -- Certificat (envoyé par le client) avec une signature invalide

   Si plus d'une signature est invalide, le KDC peut inclure un IssuerAndSerialNumber par signature invalide dans le TD-INVALID-CERTIFICATES. Le certificat X.509 du client est validé en accord avec la rfc3280.

   En fonction de la stratégie locale, le KDC peut également vérifier si un certificat X.509 dans le chemin de certification a été révoqué. Si c'est le cas, le KDC doit retourner un message d'erreur avec le code KDC_ERR_REVOKED_CERTIFICATE. Si le KDC tente de déterminer le statut de révocation mais n'est pas en mesure de le faire, il devrait retourner un message d'erreur avec le code KDC_ERR_REVOCATION_STATUS_UNKNOWN. Le ou les certificats affectés sont identifiés comme pour le code d'erreur KDC_ERR_INVALID_CERTIFICATE.

   Noter que les données d'erreur TD_INVALID_CERTIFICATES est uniquement utilisé pour identifier les certificats invalides envoyés par le client dans le demande.

   La clé publique du client est ainsi utilisée pour vérifier la signature. Si la vérification de la signature échoue, le KDC doit retourner un message d'erreur avec le code KDC_ERR_INVALID_SIG. Il n'y a pas de e-data pour ce message d'erreur.

   En plus de la validation de la signature du client, le KDC doit également vérifier que la clé publique du client utilisée pour vérifier la signature est liée au principal du client comme suit:

1. Si le KDC a sa propre liaison entre la clé publique du client ou le certificat du client et le nom du principal du client, il utilise cette liaison.
2. Sinon, si le certificat X.509 du client contient un SAN avec un KRB5PrincipalName dans le champ otherName de type GeneralName, il lie le certificat du client à ce nom.

Le type de champ otherName est AnotherName. Le champ type-id du type AnotherName est id-pkinit-san:
id-pkinit-san OBJECT IDENTIFIER ::=
    { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
    x509SanAN (2) }

Et le champ valeur du type AnotherName est un KRB5PrincipalName:
KRB5PrincipalName ::= SEQUENCE {
    realm [0] Realm,
    principalName [1] PrincipalName
    }

   Si le nom du client dans le AS-REQ ne matche pas un nom lié par le KDC, ou s'il n'y a aucune liaison trouvée par le KDC, le KDC doit retourner un message d'erreur avec le code KDC_ERR_CLIENT_NAME_MISMATCH. Il n'y a pas de e-data pour ce type d'erreur.

   Même si le chemin de certification est validée et que le certificat est mappé au nom principal du client, le KDC peut décider de ne pas accepter le certificat du client, en fonction de la stratégie locale.

Le KDC peut imposer la présence du EKU KeyPurposeId id-pkinit-KDClientAuth dans le champ extensions du certificat du client:
id-pkinit-KPClientAuth OBJECT IDENTIFIER ::=
    { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
    pkinit(3) keyPurposeClientAuth(4) }
    -- PKINIT client authentication.
    -- Key usage bits that MUST be consistent:
    -- digitalSignature.

   Le bit d'utilisation de clé digitalSignature doit être présent quand le but du certificat du client est restreins avec le id-pkinit-KDClientAuth.

   Si ce EKU KeyPusposeId est requis mais n'est pas présent, ou si le certificat du client est restreins à ne pas l'utiliser pour PKINIT, le KDC doit retourner un message d'erreur avec le code KDC_ERR_INCONSISTENT_KEY_PURPOSE. Il n'y a pas de e-data pour cette erreur. Les KDC implémentant ce requis devraient également accepter le EKU KeyPurposeId id-ms-kp-sc-logon (1.3.6.1.4.1.311.20.2.2), vu que de nombreux certificats déployés pour PKINIT ont ce EKU.

   En conséquence de la stratégie locale, le KDC peut décider de rejeter les demandes sur la base de l'absence ou la présence d'autres EKU spécifiques.

   Si l'algorithme digest utilisé pour générer la signature CA pour la clé publique dans un certificat de la demande n'est pas acceptable, le KDC doit retourner un KRB-ERROR avec le code KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED. Le e-data doit être un TYPED-DATA encodé, bien que rien n'est définis.

   Si la clé publique du client n'est pas acceptée pour des raisons autre que ceux spécifiés, le KDC retourne un message KRB-ERROR avec le code KDC_ERR_CLIENT_NOT_TRUSTED. Il n'y a pas de e-data dans ce message.

   Le KDC doit vérifier le timestamp pour s'assurer que la demande n'est pas rejouée, et que la plage de temps est dans la limite acceptable. Si la vérification échoue, le KDC doit retourner un code d'erreur KRB_AP_ERR_REPEAT ou KRB_AP_ERR_SKEW, respectivement.

   Si clientPublicValue est remplis, indiquant que le client désire utiliser la méthode d'agrément de clé DH, le KDC devrait vérifier si les paramètres satisfont sa stratégie. Si ce n'est pas le cas, il doit retourner un message d'erreur avec le code KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED. Le e-data qui l'accompagne est un TYPED-DATA qui contient un élément dont le data-type est TD-DH--PARAMETERS:


TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
    -- Chaque AlgorithmIdentifier spécifie un jeu de
    -- paramètres de domaine Diifie-Hellman. Cette liste
    -- est dans l'ordre de préférence décroissante.

   La structure AlgorithmIdentifier est définie dans la rfc3280 et est renseigné en accord avec la rfc3279. Si le client inclus un champ kdcPkId dans le PA-PK-AS-REQ et que le KDC ne possède pas la clé correspondante, le KDC doit ignorer le kdcPkId comme si le client ne l'avait pas inclus.

   Si l'algorithme digest utilisé par le id-pkinit-authData n'est pas acceptable par le KDC, le KDC doit retourner un KRB-ERROR avec le code KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED. Le e-data qui l'accompagne doit être encodé en TYPED-DATA, bien que rien n'est définis.

Génération de la réponse KDC

   Si le paChechsum dans la demande n'est pas présente, le KDC se conformant a cette spécification doivent retourner un KRB-ERROR avec le code KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED. Le e-data qui l'accompagne doit être encodé dans un TYPED-DATA.

   En assumant que la demande du client a été validée, le KDC procède comme dans la rfc4120, excepté ce qui suit.

Le KDC doit mettre le flag initial et inclure un élément de donnée d'autorisation de ad-type AD_INITIAL_VERIFIED_CAS dans le ticket fournis. Le champ ad-data contient le DER du type AD-INITIAL-VERIFIED-CAS:
AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF ExternalPrincipalIdentifier
    -- Identifie le chemin de certification avec lequel le certificat
    -- client a été validé. Chaque ExternalPrincipalIdentifier
    -- identifie une CA ou un certificat CA

   Noter que la syntaxe pour les données d'autorisation AD-INITIAL-VERIFIED-CAS ne permet pas d'encoder des SEQUENCES vides. De tels séquences vides peuvent uniquement être utilisée si le KDC garantis lui-même le certificat du client.

   l'AS enveloppe toute donnée AD-INITIAL-VERIFIED-CAS dans des conteneur AD-IF-RELEVANT si la liste des CA satisfait la stratégie locale de l'AS. De plus, tout TGS doit copier de telles données d'autorisation depuis les tickets utilisé dans un PA-TGS-REQ du TGS-REQ dans le ticket résultant. Si la liste des CA satisfait la stratégie de domaine du KDC, le TGS peut envelopper les données dans le AD-IF-RELEVANT; sinon, il peut sortir les données d'autorisation du conteneur AD-IF-RELEVANT.

   Les serveurs d'application qui comprennent ce type de données d'autorisation devraient appliquer la stratégie locale pour déterminer si un ticket donné comportant un tel type non contenu dans un conteneur AD-IF-RELEVANT est acceptable. ( Cela correspond au serveur AP qui vérifie le champ transited quand le flag TRANSITED-POLICY-CHECKED n'est pas mis). Si un tel type de donnée est contenu dans un conteneur AD-IF-RELEVANT, les serveurs AP peuvent appliquer la stratégie locale pour déterminer si les données d'autorisation sont acceptables.

Un élément de donnée de pré-authentification, dont padata-type est PA_PK_AS_REP et dont padata-value contient le DER du type PA-PK-AS-REP, est inclus dans le AS-REP.
PA-PK-AS-REP ::= CHOICE {
    dhInfo [0] DHRepInfo,
    -- Sélectionné quand l'échange de clé DH est utilisé
    encKeyPack [1] IMPLICIT OCTET STRING,
    -- Sélectionné quand le chiffrement par clé publique est utilisé
    -- Contient un type CMS ContentInfo encodé
    -- le champ contentType de type ContentInfo est id-envelopedData (1.2.840.113549.1.7.3)
    -- Le champ content est un EnvelopedData
    -- le champ contentType pour le type EnvelopedData est id-signedData (1.2.840.113549.1.7.2)
    -- le champ eContentType pour le type SignedData est id-pkinit-rkeyData (1.3.6.1.5.2.3.3)
    -- et le champ eContent contient le DER du type ReplyKeyPack
}
KDCDHKeyInfo ::= SEQUENCE {
    subjectPublicKey [0] BIT STRING,
    -- La clé publique DH du KDC
    -- la clé publique DH est encodée en BIT STRING
    nonce [1] INTEGER (0..4294967295),
    -- Contient le nonce dans le champ pkAuthenticator dans le demande si les clés DH ne sont pas réutilisées. 0 sinon.
    dhKeyExpiration [2] KerberosTime OPTIONAL,
    -- Temp d'expiration pour la paire de clé du KDC, présent si est seulement si les clé DH sont réutilisées
    -- Si présent, la clé publique DH du KDC ne doit pas être utilisé passé cette expiration
    -- Si ce champ est omis, le champ serverDHNonce doit également être utilisé.
}

   Le contenu de AS-REP est inchangé sinon. Le KDC chiffre la réponse normalement, mais pas avec la clé long-terme du client. À la place, il le chiffre avec soit une clé partagée dérivée d'un échange DH, ou une clé de chiffrement générée. Le contenu de PA-PK-AS-REP indique quelle méthode de livraison de clé est utilisé.

   Si le client ne souhaite pas utiliser la méthode DH ( le champ clientPublicValue n'est pas présent dans la demande ) et que le KDC ne supporte pas la méthode de livraison de clé de chiffrement à clé publique, le KDC doit retourner un message d'erreur avec le code KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED. Il n'y a pas de e-data accompagnant ce message d'erreur.

   En plus, la durée de vie du ticket retourné par le KDC ne doit pas excéder celle de la paire de clé du client.

Utiliser l'échange de clé Diffie-Hellman

   Dans ce cas, le PA-PK-AS-REP contient une structure SHRepInfo. La structure ContentInfo pour le champ shSignedData est remplis comme suis:

1. Le champ contentType du type ContentInfo est id-signedData, et le champ content est un SignedData
2. Le champ eContentType pour le type SignedData est l'OID pour id-pkinit-DHKeyData: { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) pkinit(3) DHKeyData(2) }.
3. Le champ eContent pour le type SignedData contient le DER du type KDCDHKeyInfo.
4. La structure KDCDHKeyInfo contient la clé publique du KDC, un nonce, et optionnellement l'expiration de la clé DH du KDC qui est réutilisée. Le champ subjectPublicKey du type KDCDHKeyInfo identifie la clé publique DH du KDC. Ce clé est encodée en BIT STRING. Le champ nonce contient le nonce dans le champ pkAuthenticator dans le demande si les clés DH ne sont pas réutilisées. La valeur de ce champ nonce est 0 si les clés DH sont réutilisées. Le champ dhKeyExpiration est prisent si et seulement si les clé DH sont réutilisées. Si le champ dhKeyExpiration est présent, la clé publique DH du KDC dans cette structure KDCDHKeyInfo ne doit pas être utilisée passé ce temps. Si ce champ est omis, le champ serverDHNonce doit également être omis.
5. Le champ signerInfo du type SignedData contient un simple signerInfo, qui contient la signature pour le type KDCDHKeyInfo.
6. Le champ certificat du type SignedData contient les certificats prévus pour faciliter la construction du chemin de certification, pour que le client puisse vérifier la signature du KDC pour le type KDCDHKeyInfo. Les informations contenus dans le trustedCertifiers dans la demande devraient être utilisés par le KDC pour l'aider dans sa sélection d'une chaîne de certificats approprié à retourner au client. Ce champ peut être vide si la clé publique du KDC spécifiée par le champ kdcPkId dans le PA-PK-AS-REQ a été utilisé pour signer. Le KDC doit être capable d'inclure un tel jeu de certificat s'il est configuré pour le faire. Ce champ ne doit pas contenir de certificat CA root.
7. Si le client inclus le champ clientDHNonce, le KDC peut choisir de réutiliser ses clés DH, et doit inclure un temps d'expiration. Quand le serveur réutilise les clé DH, il doit inclure un serverDHNonce au moins aussi long que la longueur des clé pour le système de chiffrement symétrique utilisé pour chiffrer la réponse AS. Noter qu'inclure le serverDHNonce change la manière dont le client et le serveur calculent le clé à utiliser pour chiffrer la réponse. Le KDC ne dervait pas réutiliser les clé DH sauf si clientDHNonce est présent dans la demande.

   La réponse AS est dérivée comme suit:

1. Le KDC et le client calculent la clé partagée comme suit: Quand MODP Diffie-Hellman est utilisé, les DHSharedSecret être la valeur de clé secrète. DHSharedSecret est la valeur ZZ, et est remplis avec des 0 pour la taille en octets soit la même que le modulo, et représente une chaîne d'octet dans l'ordre big-endian.
2. Laisse K être la source de génération de clé de la réponse AS.
3. Définie la fonction octetstring2key() comme suis:


octetstring2key(x) == random-to-key(K-truncate(
    SHA1(0x00 | x) |
    SHA1(0x01 | x) |
    SHA1(0x02 | x) |
    ...
    ))

   où x est une chaîne d'octets, | est l'opérateur de concaténation, 0x00, etc. sont représentés comme octet simple, random-to-key() est une opération qui génère une clé de protocole depuis un bitstring de longueur K; et K-truncate tronque son entrée au premiers K bits.

4. Quand les clé DH sont réutilisées, laisse n_c être le clientDHNonce et n_k être le serverDHNonce, sinon ils sont vides.
5. La clé de réponse AS est: k = octetstring2key(DHSharedSecret | n_c | n_k)

Utiliser le chiffrement à clé publique

   Dans ce cas, le PA-PK-AS-REP contient le champ encKeyPack où la clé de réponse AS est chiffrée. La structure ContentInfo pour le champ encKeyPack est construit comme suit:

1. Le champ contentType du type ContentInfo est id-envelopedData, et le champ content est un EnvelopedData
2. Le champ contentType pour le type EnvelopedData est id-signedData: { iso (1) member-body (2) us (840) rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2) }
3. Le champ eContentType pour le type SignedData ( quand déchiffré depuis le champ EncryptedContent pour le type EnvelopedData) est id-pkinit-rkeyData: { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) pkinit(3) rkeyData(3) }.
4. Le champ eContent pour le type SignedData contient le DER du type ReplyKeyPack
5. Le champ signerInfos du type SignedData contient un simple signerInfo, qui contient la signature pour le type ReplyKeyPack.
6. Le champ certificates pour le type SignedData contient les certificats pour construire le chemin de certification, pour que le client puisse vérifier la signature du KDC pou le type ReplyKeyPack. Les informations contenues dans le trustedCertifiers dans la demande devraient être utilisés par le KDC comme guide dans sa sélection d'une chaîne de certification appropriée. Ce champ peut être vide si la clé publique du KDC spécifiée par le champ kdcPkId dans le PA-PK-AS-REQ a été utilisé pour signer. Sinon, pour la validation du chemin, ces certificats devraient être suffisant pour construire au moins un chemin de certification depuis le certificat du KDC. Le KDC doit être capable d'inclure un tel jeu s'il est configuré pour le faire. Ce champ ne doit pas contenir de certificat CA root.
7. Le champ recipientInfos du type EnvelopedData est un jeu qui doit contenir exactement un membre du type KeyTransRecipientInfo. Le encryptedKey de ce membre contient la clé temporaire qui est chiffrée en utilisant la clé publique du client.
8. Les champs unprotectedAttrs ou originatorInfos du type EnvelopedData peut être présent.

   S'il y a un champ supportedCMSTypes dans le AuthPack, le KDC doit vérifier s'il supporte un des types listés. S'il supporte plus d'un type, le KDC devrait utilisé le premiers qui listé. S'il n'en supporte aucun, le KDC doit retourner un message d'erreur avec le code KDC_ERR_ETYPE_NOSUPP.

   Le KDC calcule le checksum du AS-REQ dans la demande du client. Ce checksum est effectué sur le type AS-REQ, et la clé de protocole de l'opération checksum est le replyKey, et le numéro d'utilisation de clé est 6. Si le enctype de replyKey est "newer", l'opération checksum est l'opération checksum requise de ce enctype:


ReplyKeyPack ::= SEQUENCE {
    replyKey [0] EncryptionKey,
    -- contient la clé de session utilisé pour chiffrer le
    -- champ enc-part dans le AS-REP. par ex: la clé de réponse AS
    asChecksum [1] Checksum,
    -- Contient le checksum du AS-REQ correspondant au AS-REP
    -- Le checksum est effectué sur le type AS-REQ.
    ...
    }

   Les implémentations de cette méthode de livraison de clé de chiffrement RSA devraient supporter les clé RSA d'au moins 2048-bits.

Réception de la réponse du KDC

   Une fois la réponse du KDC reçus, le client procède comme suit. Si le PA-PK-AS-REP contient le champ dhSignedData, le client dérive le clé de réponse AS en utilisant la même procédure utilisée par le KDC. Sinon, le message contient le champ encKeyPack, et le client déchiffre de extrait la clé temporaire dans le champ encryptedKey du membre KeyTransRecipientInfo et l'utilise comme clé de réponse AS. Si la méthode de chiffrement à clé publique est utilisé, le client doit vérifier le asChecksum dans le ReplyKeyPack.

   Dans tous les cas, le client doit vérifier la signature dans le SignedData. En plus, sauf si le client peut vérifier que la clé publique utilisée pour vérifier la signature du KDC est liée au KDC du domaine cible, le certificat du KDC doit contenir un SAN ayant un AnotherName dont type-id est id-pkinit-san et dont la valeur est un KRB5PrincipalName qui correspond au nom du TGS du domaine cible.

À moins que le client connaisse par d'autres moyens que le certificat du KDC est prévu pour un KDC, le client doit imposer que le certificat du KDC contienne le EKU KeyPurposeId id-pkinit-KPKdc:
id-pkinit-KPKdc OBJECT IDENTIFIER ::=
    { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) pkinit(3) keyPurposeKdc(5) }

   Le bit d'utilisation de clé digitalSignature doit être mis quand le but du certificat du KDC est restreins avec le EKU id-pkinit-KPKdc. Si le certificat du KDC contient le nom du TGS encodé en SAN id-pkinit-san, ce certificat est certifié par la CA qui l'a délivré, et donc l'EKU id-pkinit-KPKdc n'est pas requis. Si toutes les vérifications applicables sont satisfaites, le client déchiffre le champ enc-part du KDC-REP dans le AS-REP, utilisant la clé de réponse AS, puis procède normalement.

Prérequis d'intéropérabilité

   Le client doit être capable d'envoyer un jer de certificats suffisant pour permettre au KDC de construire un chemin de certification pour le certificat du client, si le jeu correct de certificat est fournis via la configuration ou la stratégie. Si le client envoie tous les certificats X.509 dans un chemin de certification en une chaîne acceptable pour le KDC, et si le KDC ne peut par vérifier la clé publique du client, le KDC doit être capable de traiter la validation pour le certificat du client basé sur les certificats dans le demande.

Indication du support PKINIT

   Si la pré-authentification est requise mais n'est pas présente dans la requête, un message d'erreur avec le code KDC_ERR_PREAUTH_FAILED est retourné, et un objet METHOD-DATA sera présent dans le champ e-data du message KRB-ERROR pour spécifier quels mécanismes de pré-authentification sont acceptables. Le KDC peut ainsi indiquer le support de PKINIT en incluant un élément vide dont le padata-type est PA_PK_AS_REQ dans l'objet METHOD-DATA.

   Sinon s'il est requis par la stratégie local du KDC que le client doive être pré-authentifié en utilisant le mécanisme de pré-authentification spécifié dans ce document, mais qu'aucune pré-authentification PKINIT n'est présent dans la requête, une message d'erreur avec le code d'erreur KDC_ERR_PREAUTH_FAILED devrait être retourné.

   Le KDC doit laisser le champ padata-value de l'élément PA_PK_AS_REQ dans le METHOD-DATA du KRB-ERROR vide, et les clients doivent l'ignorer. De futures extensions de ce protocole peuvent spécifier d'autres données à envoyer au lieu d'un OCTET STRING vide.
^
07 juillet 2014

htmlpdflatexmanmd




rfc4120

rfc4120

Le protocole Kerberos v5

Le protocole Kerberos

   Kerberos fournit un moyen de vérifier les identités des principaux sur un réseau non-sûr. Ceci est fait sans s'appuyer sur la confiance des assertions par le système hôte, sans confiance basé sur les adresses de l'hôte, sans nécessiter de sécurité physique des hôtes sur le réseau, et en assumant qui les paquets sur le réseau peuvent être lus, modifiés et insérés. Kerberos effectue une authentification dans ces conditions en tant que service d'authentification tiers en utilisant la cryptographie conventionnelle. Les extensions Kerberos peuvent permettre l'utilisation de chiffrements à clé publique durant certaines phases de l'authentification.

   Le processus d'authentification de base de Kerberos se déroule comme suit: Un client envoie une demande au serveur d'authentification (AS) pour les accréditations pour un serveur donné. l'AS répond avec ces accréditations, chiffrés avec la clé du client. les accréditations consistent d'un ticket pour le serveur et une clé de chiffrement temporaire (souvent appelé un clé de session). Le client transmet le ticket ( qui contient l'identité du client et une copie de la clé de session, le tout chiffré avec la clé du serveur) au serveur. La clé de session (maintenant partagée par le client et le serveur) est utilisé pour authentifier le client et peut optionnellement être utilisé pour authentifier le serveur. Il peut être utilisé également pour chiffrer d'autres communications entre les 2 parties ou pour échanger une clé de sous-session séparée à utiliser pour chiffrer d'autres communications.

   L'implémentation du protocole de base consiste d'un ou plusieurs serveurs d'authentification fonctionnant sur un hôte sécurisé. Les serveurs d'authentification maintiennent une base de données de principaux et leur clés secrète. Pour ajouter l'authentification à ses transactions, une application réseaux ajoute des appels à la librairie Kerberos directement ou via GSS-API. Ces appels résultent en la transmission des messages nécessaires pour accomplir l'authentification.

   Le protocole de base consiste de nombreux sous-protocoles ( ou échanges ). Il y a 2 méthodes de base pour lequel un client peut demander des accréditations. Dans la première approche, le client envoie une requête en texte clair pour le serveur désiré au serveur AS. La réponse est envoyée chiffrée avec la clé secrète du client. Généralement cette requête est pour un TGT (Ticket-Granting Ticket), qui peut être utilisé ultérieurement avec le TGS (Ticket-Granting Server). Dans la seconde méthode, le client envoie une requête au TGS. Le client utilise de TGT pour s'authentifier lui-même auprès du TGS de la même manière que s'il avait contacté un serveur d'application qui nécessitait une authentification Kerberos. La réponse est chiffrée dans la clé de session du TGT. Bien que la spécification du protocole décrive l'AS et le TGT comme des serveurs séparés, en pratique il sont souvent implémentés comme points d'entrée différents du protocole dans seul serveur Kerberos.

   Une fois obtenues, les accréditations peuvent être utilisés pour vérifier l'identité des principaux dans une transaction, pour s'assurer de l'intégrité des messages échangés entre eux, ou pour préserver la confidentialité des messages. L'application est libre de choisir qu'elle protection est nécessaire.

   Pour vérifier les identités des principaux dans une transaction, le client transmet le ticket au serveur d'application. Parce que le ticket est envoyé en clair (de partie sont chiffrés, mais ce chiffrement ne déjoue pas la répétition) et peut être intercepté et réutilisé par un attaquant, des informations additionnelles sont envoyées pour prouver que le message a bien pour origine le principal à qui le ticket a été fourni. Cette information ( appelée l'authentifiant) est chiffrée dans la clé de session et inclus un horodatage. l'horodatage prouve que le message a été récemment envoyés et n'est pas rejouée. Chiffrer l'authentifiant dans la clé de session prouve qu'il a été généré par un partie possédant la clé de session. Vu que personne excepté le principal et le serveur ne connaît la clé de session ( qui n'est jamais envoyée sur le réseau en clair ), cela garantis l'identité du client.

   L'intégrité des messages échangés entre les principaux peut également être garantis en utilisant la clé de session ( passée dans le ticket et contenus dans les accréditations ). Cette approche fournis la détection contre les attaques à répétition et les attaques par modification de flux. C'est accomplis en générant et en transmettant un checksum à l'épreuve des collisions du message du client, entrée avec la clé de session. La confidentialité et l'intégrité des messages échangés entre les principaux peuvent êrte sécurisé en chiffrant le données en utilisant la clé de session contenus dans le ticket ou la clé de sous-session trouvée dans l'authentifiant.

   les échanges d'authentification mentionnés plus haut nécessitent un accès lecture seule à la base de données Kerberos. Parfois, cependant, les entrées dans la base de données doit être modifiée, par exemple pour ajouter des principaux ou changer la clé d'un principal. Pour cela on utilise un protocole entre un client et un serveur Kerberos tiers, le serveur d'administration Kerberos (KADM). Il y a aussi un protocole pour maintenir plusieurs copies de la base Kerberos. Aucun de ces protocoles n'est décris dans ce document.

Fonctionnement inter-domaine

   Le protocole Kerberos est conçus pour opérer au delà des limites organisationnelle. Un client dans une organisation peut être authentifié pour un serveur dans une autre organisation. Chaque organisation souhaitant utiliser un serveur Kerberos établis son propre "domaine" (realm). Le nom de ce domaine dans lequel un client est enregistré fait partie du nom du client et peut être utilisé par le service final pour décider d'honorer ou non une requête.

   En établissant des clé inter-domaine, les administrateurs de 2 domaines peuvent permettre à un client authentifié dans le domaine local de prouver son identité aux serveurs dans les autres domaines. Les échanges de clé inter-domaines ( une clé séparée peut être utilisé pour chaque direction ) enregistrent le service d'allocation de ticket de chaque domaine comme un principale dans l'autre domaine. Un client est ainsi capable d'obtenir un TGT pour le service d'allocation de ticket du royaume distant depuis le domaine local. Quand ce TGT est utilisé, le service d'allocation de ticket distant utilise la clé inter-domaine ( qui généralement diffère de sa propre clé TGS normale ) pour déchiffrer le TGT; ainsi il est certain que le ticket a été fournis par le TGS du client. Les tickets fournis par le service d'allocation de ticket distant va indiquer au service final que le client a été authentifié depuis un autre domaine.

   Sans opération inter-domaine et avec les permissions appropriées, le client peut l'enregistrement d'un principal nommé séparément dans en royaume distant et engager un échange normal avec ce domaine. Cependant, même pour un petit nombre de clients, cela devient lourd à gérer, et méthodes plus automatiques sont nécessaires.

   Un domaine est dit communiquer avec un autre si les 2 domaines partagent un clé inter-domaine, ou si le domaine local partage une clé inter-domaine avec un domaine intermédiaire qui communique avec le domaine distant. Un chemin d'authentification est la séquence de domaines intermédiaire qui servent de transit d'un domaine à un autre.

   Les domaines peuvent être organisés hiérarchiquement. Chaque domaine partage une clé avec son parent et une clé différente avec chaque enfant. Si une clé inter-domaine n'est pas directement partagée par 2 domaines, l'organisation hiérarchique permet de construire facilement un chemin d'authentification. Si une organisation hiérarchique n'est pas utilisée, il peut être nécessaire de consulter une base de données pour construire un chemin d'authentification entre les domaines.

   Bien que les domaines sont typiquement hiérarchiques, les domaines intermédiaire peuvent être bypassés pour effectuer une authentification inter-domain au travers d'un chemin alternatif. Il est important pour le service final de connaître les domaines traversés. Pour simplifier cette décision, un champ dans chaque ticket contient les noms des domaines qui ont servis dans l'authentification du client.

   Le serveur d'application est responsable au final d'accepter ou non l'authentification et devrait vérifier le champ de transit. Le serveur d'application peut choisir de s'appuyer sur le KDC pour la vérification de ce champ. Le KDC du serveur d'application va mettre le flag TRANSITED-POLICY-CHECKED dans ce cas. Les KDC des domaines intermédiaire peuvent également vérifier ce champ vu qu'ils fournissent des TGT pour d'autre domaines, mais ils sont encouragés à ne pas le faire. Un client peut demander que les KDC ne vérifient pas ce champ en mettant le flag DISABLE-TRANSITED-CHECK. Les KDC devraient honorer ce flag.

Choisir un principal avec lequel communiquer

   Le protocole Kerberos fournis un moyen de vérifier que l'entité avec laquelle il communique est la même que celle enregistrée avec le KDC en utilisant l'identité revendiquée (le principal). Il est nécessaire de déterminer que cette identité correspond à l'entité avec laquelle on tente de communiquer.

   Quand des données appropriées ont été échangées en avance, l'application peut effectuer cette détermination syntaxiquement basé sur la spécification du protocole de l'application, les informations fournies par l'utilisateur, et les fichiers de configuration. Par exemple, le nom principal du serveur (incluant le domaine) pour un serveur telnet peut être dérivé du nom d'hôte spécifié par l'utilisateur (depuis la ligne de commande), le préfixe "host/" spécifié dans la spécification du protocole de l'application, et un mappage à un domaine Kerberos dérivé syntaxiquement depuis la partie domaine du nom d'hôte et des informations spécifiées depuis la base de domaines Kerberos locale.

   On peut également s'appuyer sur les tiers de confiance qui font cette détermination, mais seulement quand les données obtenues depuis un tiers sont convenablement protégées en intégrité lorsqu'elles résident sur le serveur du tiers de confiance et lors de leur transmission. Par exemple, on ne devrait pas pas se fier à un enregistrement DNS non protégé pour

   Les implémentations de Kerberos et les protocoles basés sur Kerberos ne doivent pas utiliser de requêtes DNS non sécurisés pour canoniser les composants du nom d'hôte des noms de principal de service. Dans un environnement sans service de nom sécurisé, les auteurs d'application peuvent ajouter un nom de domaine configuré statiquement pour les noms d'hôtes non qualifiés avant de passer ce nom aux mécanismes de sécurité. Les facilités de service de nom sécurisés, si disponible, peuvent être trustés pour la canonisation de nom d'hôte, mais une telle canonisation par le client ne devrait pas être requise par les implémentations du KDC.

Authorisation

   En tant que service d'authentification, Kerberos fournis un moyen de vérifier l'identité des principaux sur un réseau. L'authentification est généralement la première étape dans le processus d'autorisation, déterminant si un client peut utiliser un service, à quels objets le client à accès, et le type d'accès permis pour chacun. Kerberos ne fournis pas par lui-même d'autorisation. La possession d'un ticket client pour un service fournis uniquement l'authentification de ce client pour ce service, et en l'absence de procédure d'autorisation, une application ne devrait pas lui autoriser l'utilisation de ce service.

   Des méthodes d'autorisation séparés peuvent être implémentés comme fonctions de contrôle d'accès spécifique à l'application et peut utiliser des fichiers sur le serveur d'application, sur des accréditations d'autorisation fournis séparément tels que ceux fournis dans les proxys. Ces accréditations peuvent être embarqués dans une donnée d'authentification du ticket lorsqu'il est encapsulé par l'élément de données d'autorisation produit par le KDC.

   Les applications ne devraient pas accepter la délivrance d'un ticket de service par le serveur Kerberos (même par un serveur Kerberos modifié) comme accordant l'autorisation d'utiliser le service, car de telles applications peuvent devenir vulnérables au détournement de cette vérification d'autorisation dans un environnement où sont fournies d'autres options pour l'authentification d'application, ou si elles interopèrent avec d'autres KDC.

Étendre Kerberos sans rupture d'intéropérabilité

   Avec la base d'implémentation de Kerberos déployée grandissante, étendre Kerberos devient de plus en plus important. Malheureusement, certaines extensions du protocole existant créent des problèmes d'intéropérabilité à cause de l'incertitude au regard du traitement de certaines options d'extentions par certaines implémentations.

   Kerberos fournis un mécanisme général pour l'extensibilité du protocole. Certains messages du protocole contiennent des trous typés -- des sous-messages qui contiennent une chaîne d'octet et un entier qui définis comment interpréter cette chaîne d'octet. Les types entier sont enregistrés centralement, mais ils peuvent être utilisés par les vendeurs d'extension et pour les extensions standardisés.

   Dans ce document, le mot extension réfère à une extension en définissant un nouveau type à insérer dans un trou typé existant dans un message du protocole. Il ne réfère pas à l'extension en ajoutant de nouveaux champs ASN.1, sauf mention.

Envoyer des messages extensibles

   If faut s'assurer que les anciennes implémentations peuvent comprendre les messages envoyés, même si elles ne comprennent pas une extension utilisée. À moins que l'emeteur sache qu'une extension est supportée, l'extension ne peut pas changer les sémantiques du coeur du message ou des extensions définies précédemment.

   Par exemple, une extension incluant des information de clé nécessaire à déchiffrer la partie chiffrée d'un KDC-REP pourrait seulement être utilisé dans les situations où le receveur est connus pour supporter l'extension. Donc en définissant de tels extensions il est important de fournir une manière pour le receveur de notifier à l'envoyeur la prise en charge de l'extension. Par exemple dans le cas d'une extension qui change la clé de réponse de KDC-REP, le client pourrait indiquer la prise en charge de l'extension en incluant un élément padata dans la séquence AS-REQ. Le KDC ne devrait utiliser l'extension que si cet élément padata est présent dans le AS-REQ. Même si la politique exige l'utilisation de l'extension, il est préférable de retourner une erreur en indiquant que l'extension est exigée que d'utiliser l'extension alors que le receveur peut ne pas la prendre en charge.

Hypothèse sur l'environnement

   Kerberos impose quelques hypothèses sur l'environnement dans lequel il peut fonctionner de façon appropriées, qui sont les suivantes:

- Les attaques DOS ne sont pas résolues avec Kerberos. Il y a des endroits dans le protocoles où un intrus peut empêcher une application de participer aux étapes d'authentification appropriées.
- Les principaux doivent garder secrètes leurs clés secrète. Si un intrus s'empare d'une manière un d'une autre de la clé d'un principal, il sera capable de se faire passer pour ce principal ou de se déguiser en n'importe quel serveur du principal légitime.
- Les attaques en devinant le mot de passe ne sont pas résolues par Kerberos. Si un utilisateur choisit un mot de passe faible, il est possible à un agresseur de monter avec succès une attaque de dictionnaire.
- Chaque hôte sur le réseaux doit avoir une horloge synchronisée à l'heure des autres hôtes. Cette synchronisation est utilisée pour réduire les besoins d'enregistrement des serveurs d'application lorsqu'ils refont effectivement la détection. Si les horloges sont synchronisées sur le réseaux, le protocole doit lui-même être synchronisé. Le degré d'approximation normal est de l'ordre de 5 minutes
- Les identifiants de principal ne sont pas recyclés à court terme. Un contrôle de mode d'accès normal utilise des ACL pour accorder les permissions à des principaux particuliers. Si une entrée d'acl périmée subsiste pour un principal supprimé et si l'identifiant du principal est réutilisé, le nouveau principal va hériter des droits spécifiés dans l'entrée d'acl périmée. On supprime ce problème en ne réutilisant pas les identifiants de principal.

Glossaire

Authentification Vérifier l'identité revendiquée par un principal
En-tête d'authentification Enregistrement qui contient un ticket et un authentifiant à présenter à un serveur au titre du processus d'authentification.
Chemin d'authentification Séquence de domaines intermédiaires traversés dans le processus d'authentification lors de la communication d'un domaine à l'autre.
Authentifiant Enregistrement contenant des informations dont on peut montrer qu'elles ont été générées récemment en utilisant la clé de session connue seulement du client et du serveur.
Autorisation Processus pour déterminer si un client a la permission d'utiliser un service, à quels objets le client a la permission d'accès et le type d'accès permis pour chacun.
Capacité Jeton qui accorde au porteur la permission d'accéder à un objet ou service. Dans Kerberos, ce peut être un ticket dont l'utilisation est restreinte par le contenu du champ de données d'autorisation, mais qui ne donne pas d'adresse réseau, avec la clé de session nécessaire pour utiliser le ticket.
Texte chiffré Résultat d'une fonction de chiffrement. Le chiffrement transforme le texte clair en texte chiffré
Client Processus qui utilise un service réseau au nom d'un utilisateur. Noter que dans certains cas, un serveur peut être lui-même un client de quelque autre serveur (par exemple, un serveur d'impression peut être un client d'un serveur de fichiers)
Accréditifs Un ticket plus la clé de session secrète nécessaire pour utiliser ce ticket avec succès dans un échange d'authentification
Type de chiffrement (etype) Associé à des données chiffrées; un type de chiffrement identifie l'algorithme utilisé pour chiffrer les données et est utilisé pour choisir l'algorithme approprié pour déchiffrer les données. Les étiquettes de type de chiffrement sont communiquées dans d'autres messages pour énumérer les algorithmes qui sont souhaités, pris en charge, préférés, ou permis en utilisation pour le chiffrement des données entre les parties. Cette préférence est combinée aux informations et politiques locales pour choisir l'algorithme à utiliser.
KDC (Key Distribution Center) Centre de distribution de clés. Service réseau qui fournit les tickets et les clés de sessions temporaires ; ou instance de ce service ou l'hôte sur lequel il fonctionne. Le KDC sert à la fois le ticket initial et les demandes de ticket d'allocation de ticket. La portion de ticket initial est parfois appelée serveur (ou service) d'authentification. La portion de ticket d'allocation de ticket est parfois appelée serveur (ou service) d'allocation de ticket.
Kerberos Nom donné au service d'authentification du Projet Athéna, protocole utilisé par ce service, ou code utilisé pour mettre en œuvre le service d'authentification. Le nom vient de celui du chien à trois têtes qui garde l'Hadès
Numéro de version de clé (kvno,Key Version Number) Étiquette associée aux données chiffrées qui identifie quelle clé a été utilisée pour le chiffrement lorsque une clé à longue durée associée à un principal change au fil du temps. Il est utilisé durant la transition vers une nouvelle clé de sorte que la partie qui déchiffre un message puisse dire si les données ont été chiffrées avec la vieille ou la nouvelle clé
Texte en clair Entrée dans une fonction de chiffrement ou sortie d'une fonction de chiffrement. Le déchiffrement transforme le texte chiffré en texte clair.
Principal Entité client ou serveur nommée qui participe à une communication réseau, avec un nom qui est considéré comme canonique.
Identifiant de principal Nom canonique utilisé pour identifier de façon univoque chaque différent principal.
Sceau Pour chiffrer un enregistrement contenant plusieurs champs de telle sorte que les champs ne puissent pas être remplacés individuellement sans connaissance de la clé de chiffrement ou sans laisser de traces d'altération.
Clé secrète Clé de chiffrement partagée par un principal et le KDC, distribuée en dehors des limites du système, avec une durée de vie longue. Dans le cas du principal d'un utilisateur humain, la clé secrète peut être déduite d'un mot de passe.
Serveur Principal particulier qui fournit une ressource aux clients réseau. Le serveur est parfois appelé serveur d'application.
Service Ressource fournie aux clients réseau; souvent fournie par plus d'un serveur (par exemple, un service de fichier distant)
Clé de session Clé de chiffrement temporaire utilisée entre deux principaux, avec une durée de vie limitée à la durée d'une seule "session" de connexion. Dans le système Kerberos, une clé de session est générée par le KDC. La clé de session est distincte de la sous-clé de session, décrite ci-après
Sous-clé de session Clé de chiffrement temporaire utilisée entre deux principaux, choisie et échangée par les principaux en utilisant la clé de session, et avec une durée de vie limitée à la durée d'une seule association. La sous-clé de session est aussi appelée sous-clé.
Ticket Enregistrement qui aide un client à s'authentifier auprès d'un serveur; il contient l'identité du client, une clé de session, un horodatage, et d'autres informations, toutes scellées en utilisant la clé secrète du serveur. Il ne sert qu'à authentifier un client lorsqu'il est présenté avec un authentifiant frais.

Utilisation et demandes de flags de ticket

   Chaque ticket Kerberos contient un ensemble de flags utilisés pour indiquer les attributs de ce ticket. La plupart des flags peuvent être demandés par un client lorsque le ticket est obtenu; certains sont automatiquement activés et désactivés en fonction des besoins du serveur. À l'exception du flag INVALID, les clients doivent ignorer les flags qu'ils ne reconnaissent pas. Les KDC doivent ignorer les options KDC qui ne sont pas reconnus. Certaines mises en œuvre de la rfc1510 sont connues pour rejeter les options KDC si la demande a été rejetée alors qu'elle avait été envoyée avec des options ajoutées depuis la rfc1510. Comme les nouveaux KDC ignorent les options inconnues, les clients doivent confirmer que le ticket retourné satisfait leur besoins.

   Noter qu'il n'est en général pas possible de déterminer si une option n'a pas été satisfaite parce qu'elle n'a pas été comprise ou si elle a été rejetée à cause de la configuration ou de la politique. Lors de l'ajout d'une nouvelle option au protocole Kerberos, les concepteurs devraient examiner si la distinction est importante pour leur option. Si elle l'est, il faut fournir un mécanisme pour que le KDC retourne une indication comme quoi l'option a été comprise mais rejetée, dans la spécification de l'option. Souvent dans de tels cas, le mécanisme doit être suffisamment tolérant pour permettre qu'une erreur soit retournée.

Ticket initial, pré-authentification, et matériel authentifié

   Le flag INITIAL indique qu'un ticket a été produit en utilisant le protocole d'AS, plutôt que produit sur la base d'un TGT. Les serveurs d'application qui veulent demander la preuve de la connaissance de la clé secrète d'un client (par exemple, un programme à changement de mot de passe) peut insister pour que ce flag soit établi dans tous les tickets qu'il accepte, et peut donc être assuré que la clé du client a été récemment présentée au serveur d'authentification.

   Les flags PRE-AUTHENT (pré-authentifié) et HW-AUTHENT (matériel-authentifié) donnent des informations supplémentaires sur l'authentification initiale, que le ticket en cours ait été produit directement (dans ce cas le flag INITIAL est établi) ou qu'il soit produit sur la base d'un TGT (le flag INITIAL n'est pas mis, mais PRE-AUTHENT et HW-AUTHENT sont ramenés du TGT).

Tickets invalides

   Le flag INVALID indique qu'un ticket est invalide. Les serveur d'application doivent rejeter les tickets qui ont ce fjag. Un ticket postdaté sera toujours produit sous cette forme. Les tickets invalides doivent être validés par le KDC avant utilisation, en étant présentés au KDC dans une demande TGS avec l'option VALIDATE spécifié. Le KDC ne validera le ticket qu'après l'heure de début soit passée. La validation est exigée de sorte que les tickets postdatés qui ont été volés avant leur heure de début puissent être rendus invalides de façon permanente (grâce à un mécanisme de liste noire)

Tickets renouvelables

   Les applications peuvent désirer détenir des tickets qui soient valides pour de longues durées. Cependant, cela peut exposer leurs accréditifs à des menaces de vol. Utiliser simplement des tickets à courte durée de vie et en obtenir périodiquement de nouveaux exige que le client ait un accès à long terme à sa clé secrète, ce qui présente un risque encore plus grand. Les tickets renouvelables peuvent être utilisés pour atténuer les conséquences d'un vol. Les tickets renouvelables ont 2 heures d'expiration: la première est quand l'instance actuelle du ticket expire, et la seconde est la valeur permissible la plus tardive pour une heure d'expiration individuelle. Un client d'application doit périodiquement présenter au KDC un ticket renouvelable, avec l'option RENEW dans la demande.

   Le KDC va produire un nouveau ticket avec une nouvelle clé de session et une nouvelle heure d'expiration. Tous les autres champs du ticket sont laissés inchangés par le processus de renouvellement. Lorsque arrive l'heure d'expiration la plus tardive permissible, le ticket est expiré de façon permanente. À chaque renouvellement, le KDC peut consulter une liste noire pour déterminer si le ticket a été noté volé depuis son dernier renouvellement.

   Le flag RENEWABLE dans un ticket n'est normalement interprété que par le service d'allocation de tickets. Il peut habituellement être ignoré par les serveurs d'application. Cependant, certains serveurs d'application particulièrement soigneux peuvent interdire les tickets renouvelables.

   Si un ticket renouvelable n'est pas renouvelé à son heure d'expiration, le KDC ne renouvellera pas le ticket. Le flag RENEWABLE est rétabli par défaut, mais un client peut demander qu'il soit établi en mettant l'option RENEWABLE dans le message KRB_AS_REQ. S'il est établi, le champ renew-till dans le ticket contient l'heure après laquelle le ticket ne peut plus être renouvelé.

Tickets postdatés

   Les applications peuvent parfois avoir besoin d'obtenir des tickets à utiliser beaucoup plus tard; par exemple, un système de soumission par lots aura besoin de tickets valides au moment où le lot est à traiter. Cependant, il est dangereux de détenir des tickets valides dans une file d'attente. Les tickets postdatés fournissent le moyen d'obtenir ces tickets du KDC au moment de la soumission de la tâche, mais de les laisser dormants jusqu'à ce qu'ils soient activés et validés par une demande ultérieure du KDC. Si un vol de ticket devait être rapporté dans l'intervalle, le KDC refuserait de valider le ticket.

   Le flag MAY-POSTDATE dans un ticket n'est normalement interprété que par le service d'allocation de tickets. Il peut être ignoré par les serveurs d'application. Ce flag doit être établi dans un TGT afin de produire un ticket postdaté sur la base du ticket présenté. Il est rétabli par défaut; un client peut le demander en établissant l'option ALLOW-POSTDATE dans le KRB_AS_REQ. Ce flag ne permet pas à un client d'obtenir un TGT postdaté; les TGT postdatés ne peuvent être obtenus qu'en demandant le postdatage dans le KRB_AS_REQ. La durée de vie d'un ticket postdaté sera la durée de vie restante du TGT au moment de la demande. Sauf si l'option RENEWABLE est aussi établie, auquel cas elle peut être la durée de vie complète du TGT. Le KDC peut limiter la durée d'un ticket postdaté.

   Le flag POSTDATED indique qu'un ticket a été postdaté. Le serveur d'application peut vérifier le champ authtime dans le ticket pour voir quand est survenue l'authentification originale. Certains services peuvent choisir de rejeter ces tickets, ou ne les accepter que dans une certaine période après l'authentification originale. Lorsque le KDC produit un ticket POSTDATED, il sera aussi marqué INVALID, de sorte que le client d'application doit présenter le ticket au KDC pour validation avant utilisation.

Tickets mandatables et mandataires

   Il peut être nécessaire qu'un principal permette à un service d'effectuer une opération en son nom. Le service doit être capable de prendre l'identité du client, mais seulement pour un objet particulier. Un principal peut permettre à un service de faire cela en lui accordant un mandat (proxy).

   Le processus de délivrance d'un mandat en utilisant les flags proxy et proxiable est utilisé pour fournir des accéditifs à utiliser avec des services spécifiques. Bien que ce soit conceptuellement aussi un mandat, les utilisateurs qui souhaitent déléguer leur identité dans une forme utilisable à tous propos doivent utiliser le mécanisme de transmission de ticket décrit au paragraphes suivant pour transmettre un TGT.

   Le flag PROXIABLE dans un ticket n'est normalement interprété que par le service d'allocation de tickets. Il peut être ignoré par les serveurs d'application. Lorsqu'il est établi, ce flag dit au TGS qu'il est d'accord pour produire un nouveau ticket (mais pas un TGT) avec une adresse réseau différente fondée sur ce ticket. Ce flag est établi s'il est demandé par le client à l'authentification initiale. Par défaut, le client demandera qu'il soit établi lorsqu'il demande un TGT, et gu'il soit rétabli lorsqu'il demande tout autre ticket.

   Ce flag permet à un client de passer au serveur proxy d'effectuer une demande distante en son nom (par exemple, un client de service d'impression peut donner mandat au serveur d'impression d'accéder aux fichiers du client sur un serveur de fichiers particulier afin de satisfaire à une demande d'impression).

   Afin de compliquer l'utilisation des accréditifs volés, les tickets Kerberos sont souvent valides pour les seules adresses réseau spécifiquement incluses dans le ticket, mais il est permis, comme option de politique de permettre des demandes et de produire des tickets sans aucune adresse réseau spécifiée. Lorsqu'il accorde un mandat, le client doit spécifier la nouvelle adresse réseau à partir de laquelle le mandat sera utilisé ou indiquer que le mandat est produit pour être utilisé sur toute adresse.

   Le flag PROXY est établi dans un ticket par le TGS lorsqu'il produit un ticket proxy. Les serveurs d'application peuvent vérifier ce flag; et optionnellement peuvent demander une authentification supplémentaire de la part de l'agent qui présente de mandat afin de fournir une trace d'audit.

Tickets transmissibles

   La transmission d'authentification est une instance de mandat dans laquelle le service qui est accordé est l'utilisation complète de l'identité du client. Exemple: Un usager qui s'enregistre sur un système distant et veut l'authentification pour travailler à partir de ce système comme si l'enregistrement était local.

   Le flag FORWARDABLE dans un ticket n'est normalement interprété que par le service d'allocation de tickets. Il peut être ignoré par les serveurs d'application. Le flag FORWARDABLE a une interprétation similaire à PROXIABLE, sauf que les TGT peuvent aussi être produits avec des adresses réseau différentes. Ce flag est ré-initialisé par défaut, mais les utilisateurs peuvent demander qu'il soit établi en mettant l'option FORWARDABLE dans la demande d'AS lorsqu'ils demandent le TGT initial.

   Le flag FORWARDED est mis par le TGS lorsqu'un client présente un ticket avec le flag FORWARDABLE mis et demande un ticket transmis en spécifiant l'option KDC FORWARDED et en fournissant un ensemble d'adresses pour le nouveau ticket. Il est aussi établi dans tous les tickets produits sur la base de tickets ayant le flag FORWARDED mis. Les serveurs d'application peuvent choisir de traiter les tickets FORWARDED différemment.

   Si les tickets sans adresse sont transmis d'un système à un autre, les clients devraient continuer d'utiliser cette option pour obtenir un nouveau TGT afin d'avoir des clés de session différentes sur les différents systèmes.

Vérification des stratégies traversées

   Dans Kerberos, le serveur d'application est responsable en dernier ressort de l'acceptation ou du rejet de l'authentification, et il devrait vérifier que seuls des KDC de confiance sont impliqués dans l'authentification d'un principal. Les champs de transit dans le ticket identifient quels domaines ( et donc quels KDC ) ont été impliqués dans le processus d'authentification, et un serveur d'application devrait normalement vérifier ce champ. Si l'un d'eux n'est pas de confiance pour authentifier le principal de client indiqué (probablement déterminé par une politique fondée sur le domaine), la tentative d'authentification doit être rejetée. La présence de ?DC de confiance dans cette liste ne donne aucune garantie; un KDC compromis peut avoir fabriqué la liste.

   Bien que le serveur d'extrémité décide en dernier ressort si l'authentification est valide, le KDC pour le domaine du serveur l'extrémité peut appliquer une politique spécifique du domaine pour la validation du champ de transit et l'acceptation des accréditifs pour l'authentification de traversée de domaine. Lorsque le KDC applique de telles vérifications et accepte une telle authentification de traversée de domaine, il va établir le flag TRANSITED-POLICY-CHECKED dans les tickets de service qu'il produit sur la base du TGT de traversée de domaine. Un client peut demander que les KDC ne vérifient pars le champ en mettant le flag DISABLE-TRANSITED-CHECK. Les KDC devraient respecter ce flag.

   Les serveurs d'application doivent soit faire eux-mêmes les vérifications de domaine traversé soit rejeter les tickets de traversée de domaine sans que TRANSITED-POLICY-CHECKED sois mis.

OK-as-Delegate

   Pour certaines applications, un client peut avoir besoin de déléguer son autorité à un serveur pour agir en son nom en contactant d'autres services. Cela exige que le client transmette les accréditifs à un serveur intermédiaire. La capacité pour un client à obtenir un ticket de service pour un serveur n'apporte pas d'information au client sur la question de savoir si le serveur devrait être considéré comme de confiance pour accepter des accréditifs délégués. Le flag OK-AS-DELEGATE donne à un KDC un moyen pour communiquer une politique de domaine local à un client sur le sujet de savoir si un serveur intermédiaire est de confiance pour accepter de tels accréditifs.

   La copie des flags de ticket dans la partie chiffrée de la réponse du KDC peut avoir le flag OK-AS-DELEGATE établi pour indiquer au client que le serveur spécifié dans le ticket a été déterminé par la politique du domaine comme étant un récepteur convenable de délégation. Un client peut utiliser la présence de ce flag pour l'aider à décider de déléguer des accréditifs (en accordant soit un mandat soit un TGT retransmis) à ce serveur. Il est acceptable d'ignorer la valeur de ce flag. Lorsqu'il établit ce flag, un administrateur devrait considérer la sécurité et le placement du serveur sur lequel va fonctionner le service, ainsi que si le service exige l'utilisation d'accréditifs délégués.

Autres options de KDC

   Il y a 3 options supplémentaires qui peuvent être établies dans une demandes de KDC du client

Renewable-OK

   L'option REMEWABLE-OK indisque que le client acceptera un ticket renouvelable si un ticket avec la durée de vie demandée ne peut pas être autrement fourni. Si un ticket avec la durée de vie demandée ne peut pas être fourni, le KDC peut alors produire un ticket renouvelable avec un renew-till égal à la fin de durée de vie demandée. La valeur du champ renew-till peut encore être ajustée par des limites déterminées par le site ou des limites imposées par le principal ou serveur individuel.

ENC-TKT-IN-SKEY

   Dans sa forme de base, le protocole Kerberos prend en charge l'authentification dans un montage client-serveur et ne convient pas bien pour l'authentification dans un environnement d'homologue à homologue parce que la clé à long terme de l'usager ne reste pas sur la station de travail après la connexion initiale. L'authentification de tels homologues peut être prise en charge par Kerberos dans sa variante d'usager à usager. L'option ENC-TKT-IN-SKEY prend en charge l'authentification d'usager à usager en permettant que le KDC produise un ticket de service chiffré en utilisant la clé de session provenant d'un autre TGT produite pour un autre usager. L'option ENC-TKT-IN-SKEY n'est honorée que par le TGT. Elle indique que le ticket à produire pour le serveur est à chiffrer dans la clé de session à partir du second TGT supplémentaire fourni avec la demande.

Authentification hardware sans mot de passe

   L'option OPT-HARDWARE-AUTH indique que le client souhaite utiliser une forme d'authentification de matériel à la place de ou en plus du mot de passe du client ou autre clé de chiffrement à longue durée de vie. OPT-HARDWARE-AUTH n'est honoré que par l'AS. S'il est pris en charge et admis par la politique, le KDC va retourner un code d'erreur de KDC_ERR_PREAUTH_REQUIRED et inclure les METHOD-DATA exigées pour effectuer une telle authentification.

Échange de messages

   Les paragraphes qui suivent décrivent les interactions entre les clients et serveurs réseau et les messages impliqués dans ces échanges.

Échange service d'authentification

   L'échange de service d'authentification ( AS ) entre le client et le serveur d'authentification Kerberos est initialisé par un client qui souhaite obtenir des accréditifs d'authentification pour un serveur donné mais ne détient pas actuellement d'accréditifs. Dans la forme de base, la clé secrète du client est utilisée pour le chiffrement et le déchiffrement. Cet échange est normalement utilisé à l'initialisation d'une session de connexion pour obtenir des accréditifs pour un serveur d'allocation de tickets ( TGS ). qui seront utilisés ultérieurement pour obtenir des accréditifs pour d'autres serveurs sans avoir besoin d'utiliser la clé secrète du client. Cet échange est aussi utilisé pour demander des accréditifs pour des services qui ne doivent pas passer par le TGS ( le service de changement de mot de passe refuse les demandes si le demanteur ne peut pas démontrer qu'il a connaissance du vieux mot de passe ).

   Cet échange ne fournit par lui-même aucune assurance de l'identité de l'usager. Pour authentifier un usager qui s'inscrit sur un système local, les accréditifs obtenus dans l'échange d'AS peuvent d'abord être utilisés dans un échange TGS pour obtenir des accréditifs pour un serveur local; ces accréditifs doivent ensuite être vérifiés par un serveur local à travers l'achèvement réussi de l'échange client/serveur.

   L'échange AS consiste en 2 messages: KRB_AS_REQ et KRB_AS_REP ou KRB_ERROR.

   Dans la demande, le client envoie (en clair) sa propre identité et l'identité du serveur pour lequel il demande les accréditifs, d'autres informations sur les accréditifs qu'il demande, et un nom temporaire généré de façon aléatoire qui peut être utilisé pour détecter des répétitions et pour associer les réponses aux demandes correspondantes. Ce nom temporaire doit être généré de façon aléatoire par le client et mémorisé pour vérification par rapport au nom aléatoire dans la réponse attendue. La réponse, KRB_AS_REP, contient un ticket que le client présentera au serveur, et une clé de session qui sera partagée par le client et le serveur. La clé de session et les informations supplémentaire sont chiffrées avec la clé secrète du client. La partie ciffrée du message KRB_AS_REP contient aussi le nom temporaire qui doit correspondre au nom temporaire provenant du message KRB_AS_REQ.

   Sans pré-authentification, l'AS ne sait pas si le client est réellement le principal nommé dans la demande. Il envoie simplement une réponse sans savoir s'il sont les mêmes et sans s'en soucier. Ceci est acceptable puisque personne sauf le principal dont l'identité a été donnée dans la demande se sera capable d'utiliser la réponse. Ses information critiques sont chiffrées avec la clé du principal. Cependant, un attaquant peut envoyer un message KRB_AS_REQ pour obtenir du texte en clair connu afin d'attaquer la clé du principal. Et particulièrement si la clé se fonde sur un mot de passe, cela peut créer un danger pour la sécurité. Ainsi, la demande initiale prend en charge un champ facultatif qui peut être utilisé pour passer des informations supplémentaires nécessaire pour l'échange initial. Ce champ devrait être utilisé pour la pré-authentification.

   Diverses erreurs peuvent survenir; elles sont indiquées par une réponse d'erreur KRB_ERROR à la place de la réponse KRB_AS_REP. Le message d'erreur n'est pas chiffré. Ce message contient des informations qui peuvent être utilisées pour l'associer au message auquel il répond. Le contenu du message KRB_ERROR n'est pas protégé en intégrité, donc le client ne peut pas détecter les répétitions, contrefaçons, ou modifications. Une solution à ce problème sera donnée dans une prochaine version du protocole.

Génération du message KRB_AS_REQ

   Le client peut spécifier un certain nombre d'options dans la demande initiale. Parmi ces options figure la question de savoir si la pré-authentification est à effectuer; si le ticket demandé est renouvelable, mandatable, ou transmissible; s'il devrait être postdaté ou permettre de postdatage de tickets déduits; et si un ticket renouvelable sera accepté à la place d'un ticket non renouvelable si la date d'expiration du ticket demandé ne peut pas être satisfaite par un ticket non renouvelable.

Réception du message KRB_AS_REQ

   Si tout va bien, le traitement du message KRB_AS_REP résultera en la création d'un ticket que le client présentera au serveur.

   Parce que Kerberos peut fonctionner sur des transports non fiables comme UDP, le KDC doit être prêt à retransmettre des réponses dans le cas où elles sont perdues. Si un KDC reçoit une demande identique à l'une de celles qu'il a récemment traitées avec succès, le KDC doit répondre par un message KRB_AS_REP plutôt qu'une erreur de répétition. Afin de réduire la quantité de texte chiffré à disposition d'un attaquant potentiel, les KDC peuvent envoyer la même réponse que générée lors du premier traitement de la demande. Les KDC doivent obéir à ce comportement de répétition même si le transport réel utilisé est fiable.

Génération du message KRB_AS_REP

   Le serveur d'authentification cherche dans sa base de données les principaux de client et de serveur nommés dans le message KRB_AS_REQ, et en extrait les clés respectives. Si le principal client demandé nommé dans la demande est inconnu parce qu'il n'existe pas dans la base de données de principaux du KDC, un message d'erreur est retourné avec un KDC_ERR_C_PRINCIPAL_UNKNOWN.

   S'il lui est demandé de faire ainsi, le serveur pré-authentifie la demande, et si la vérification de pré-authentification échoue, un message d'erreur avec le code KDC_ERR_PREAUTH_FAILES. Si la pré-authentification est exigée, mais n'était pas présente dans la demande, un message d'erreur avec le code KDC_ERR_PREAUTH_REQUIRED est retourné, et un objet METHOD-DATA sera mémorisé dans le champ e-data du message KRB-ERROR pour spécifier quels mécanismes de pré-authentification sont acceptables. Cela inclure habituellement les éléments PA-ETYPE-INFO et/ou PA-ETYPE-INFO2. Si le serveur ne peut pas s'accommoder d'un des types de chiffrement demandé par le client, un message d'erreur avec le code KDC_ERR_ETYPE_NOSUPP est retourné.

   Autrement, le KDC génère une clé de session "aléatoire", ce qui signifie, entre autres choses, qu'il devrait être impossible de deviner la prochaine clé de session sur la base de la connaissance des clés de session passées. Bien que cela puisse être réalisé avec un générateur de nombres pseudo-aléatoires s'il se fonde sur les principes cryptographiques, il est plus souhaitable d'utiliser un générateur de nombres vraiment aléatoires, comme un de ceux fondés sur la mesure de phénomènes physiques aléatoires.

   En réponse à une demande d'AS, s'il y a plusieurs clés de chiffrement inscrites pour un client dans la base de données Kerberos, le champ etype de la demande d'AS est utilisé par le KDC pour choisir la méthode de chiffrement à utiliser pour protéger la partie chiffrée du message KRB_AS_REP qui est envoyé au client. S'il y a plus d'un type de chiffrement fort dans la liste etype, le KDC devrait utiliser le premier etype fort valide pour lequel une clé de chiffrement est disponible.

   Lorsque la clé de l'utilisateur est générée à partir d'un mot de passe ou d'une passphrase, la fonction string-to-key pour le type de clé de chiffrement particulier est utilisé, comme spécifié dans la rfc 3961. La valeur de salt et les paramètres supplémentaires pour la fonction string-to-key ont des valeurs par défaut qui peuvent être remplacés par les données de pré-authentification (n (PA-PW-SALT, PA-AFS3-SALT, PA-ETYPE-INFO, PA-ETYPE-INFO2, etc.). Comme le KDC est supposé mémoriser une copie seulement de la clé résultant, ces valeurs ne devraient pas être changées pour des clés fondées dus des mots de passe excepté lorsqu'on change la clé du principal.

   Lorsque le serveur d'AS va inclure les données de pré-authentification dans un KDC-ERROR ou dans un AS-REP, il doit utiliser PA-ETYPE-INFO2 et non PA-ETYPE-INFO, si le champ etype de la AS-REQ du client comporte au moins un type de chiffrement "plus récent". Autrement (lorsque le champ etype de l'AS-REQ ne comporte aucun type de chiffrement plus récent), il doit envoyer les deux PA-ETYPE-INFO2 et PA-ETYPE-INFO (tous 2 avec une entrée pour chaque enctype). Un enctype "plus récent" est tout enctype spécifié officiellement en premier concurrement ou ultérieurement à la publication de la présent rfc. Les enctypes DES, 3DES, ou RC4 et tous ceux définis dans la RFC1510 ne sont pas des enctypes "plus récents"

   Il n'est pas possible de générer une clé utilisateur de façon fiable selon une passphrase donnée sans contacter le KDC, car on ne pourra pas savoir si des valeurs de salt ou de paramètres de remplacement sont nécessaires.

   Le kDC va essayer d'allouer le type de la clé de session aléatoire d'après la liste des méthodes dans le champ etype. Le KDC va sélectionner le type approprié en utilisant la liste des méthodes fournie et les informations tirées de la base de données Kerberos qui indique les méthodes de chiffrement acceptables pour le serveur d'application. Le KDC ne produira pas de tickets avec un type faible de chiffrement de clé de session.

   Si l'heure de début demandée est absente, indique une heure passée, ou est dans une fenêtre acceptable pour le KDC et si l'option POSTDATE n'a pas été spécifié, l'heure de début du ticket est réglée à l'heure en cours du serveur d'authentification. S'il indique une heure future au delà de la fenêtre acceptable, mais si l'option POSTDATED n'a pas été spécifiée, l'erreur KDC_ERR_CANNOT_PORTDATE est retournée. Autrement, l'heure de début demandée est vérifiée par rapport à la politique du domaine local, et si l'heure de début du ticket est acceptable, il est réglé comme demandé, et le flag INVALID est mis dans le nouveau ticket.

   L'heure d'expiration du ticket sera réglée au plus tôt de l'heure de fin demandée et de l'heure déterminée par la politique locale, éventuellement en utilisant des facteurs spécifiques du domaine ou du principal. Par exemple, l'heure d'expiration peut être réglée au plus tôt de ce qui suit:

- L'heure d'expiration demandée dans le message KRB_AS_REQs
- L'heure de début du ticket plus la durée de vie maximum admissible associée au principal d'après la base de données du serveur d'authentification.
- L'heure de début du ticket plus la durée de vie maximum admissible associée au principal
- L'heure de début du ticket plus la durée de vie maximum réglée par la stratégie du domaine local

   Si l'heure d'expiration demandée moins l'heure de début est inférieur à la durée de vie minimum déterminée par un site, un message d'erreur avec le code KDC_ERR_NEVER_VALID est retourné. Si l'heure d'expiration demandée pour le ticket excède ce qui a été déterminé ci-dessus, et si l'option RENEWABLE-OK était demandé, le flag RENEWABLE est alors mis dans le nouveau ticket, et le champ renew-till peut être réglé au plus tôt de:

- Sa valeur demandée
- L'heure de début du ticket plus le minimum des deux durées de vie maximum associées aux entrées de base de données des principaux
- L'heure de début plus la durée de vie renouvelable maximum réglée par la politique du domaine local

   Le champ des flags du nouveau ticket aura les options suivantes établies s'ils ont été demandés et si la politique du domaine local le permet: FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE.. Si le nouveau ticket est postdaté, son flag INVALID est également mis.

   Si tout ce qui précède réussit, le serveur va chiffrer la partie de ciphertext du ticket en utilisant la clé de chiffrement extraite de l'enregistrement du principal du serveur dans la base de données Kerberos en utilisant le type de chiffrement associé à la clé du principal du serveur (ce choix n'est pas affecté par le etype dans la requête). Il forge alors un message KDC_AS_REP, en copiant les adresses de la demande dans le caddr de la réponse, en plaçant toutes les données de pré-authentification demandées dans le padata de la réponse, et en chiffrant la partie ciphertext dans la clé du client en utilisant une méthode de chiffrement acceptable demandée dans le champ etype de la demande, ou dans une clé spécifiée par le mécanisme de pré-authentification utilisé.

Génération du message KDC_ERROR

   Plusieurs erreurs peuvent survenir, et le serveur d'authentification répond en envoyant un message d'erreur, KDC_ERROR, au client, avec les champs code d'erreur et e-text réglés aux valeurs appropriées.

Réception du message KRB_AS_REP

   Si le type du message de réponse est KDC_AS_REP, le client vérifie alors que les champs cname et crealm de la portion de texte en clair de la réponse correspondent à ce qui était demandé. Si un champ padata est présent, il peut être utilisé pour déduire la clé secrète appropriée pour déchiffrer le message. Le client déchiffre la partie chiffrée de la réponse en utilisant sa clé secrète et vérifie que le nom temporaire dans la partie chiffrée correspond au nom occasionnel qu'il a fourni dans sa demande (pour détecter des répétitions). Il vérifie aussi que sname et srealm de la réponse correspondent à ceux de la demande (ou des valeurs attendues), et que le champ d'adresse d'hôte est correcte. Il mémorise alors le ticket, la clé de sessions, les heures de début et d'expiration, et les autres informations pour un usage ultérieur. Le champ last-req (et le champ déconseillé key-expiration) tirés de la partie chiffrée de la réponse peuvent être vérifiés pour notifier à l'utilisateur une expiration de clé imminente. Ceci permet au programme client de suggérer un remède, comme un changement de mot de passe.

   À la validation du message KRB_AS_REP (en comparant le nom temporaire avec celui envoyé), le client sait que l'heure courante du KDC est celle lue dans le champ authtime de la partie chiffrée de la réponse. Le client peut optionnellement utiliser cette valeur pour synchroniser l'horloge dans les messages suivant en enregistrant avec le ticket la différence entre la valeur de authtime et l'horloge locale. Cet offset peut ainsi être utilisé par le même utilisateur pour ajuster le temps lu de l'horloge système lors de la génération des messages.

   Cette technique doit être utilisée en ajustant le biais d'horloge au lieu de changer directement l'horloge système, parce que la réponse du KDC n'est authentifiée qu'auprès de l'utilisateur dans la clé secrète a été utilisée, mais pas auprès du système ou de la workstation.

   Le déchiffrement correcte du message KRB_AS_REP n'est pas suffisant à l'hôte peut vérifier l'identité de l'utilisateur qui se connecte sur la workstation. L'utilisateur et un attaquant pourraient coopérer pour générer un message de format KRB_AS_REP qui se déchiffre correctement mais ne serait pas du KDC approprié. Si l'hôte souhaite vérifier l'identité de l'utilisateur, il doit exiger que l'utilisateur présente des accréditifs d'application qui puissent être vérifiés en utilisant une clé secrète que l'hôte aura mémorisé en toute sécurité. Si ces accréditifs peuvent être vérifiés, l'identité de l'usager peut alors être assurée.

Réception du message KRB_ERROR

   Si le type de message de réponse est KRB_ERROR, le client l'interprète alors comme une erreur et effectue toute tâche spécifique de l'application qui est nécessaire pour récupérer.

Échange d'authentification client/serveur

   L'échange d'authentification client/serveur (CS) est utilisé par les applications réseau pour authentifier le client auprès du serveur et vice versa. Le client doit déjà avoir acquis des accréditifs pour le serveur en utilisant l'échange AS ou TGS.

Message KRB_AP_REQ

   KRB_AP_REQ contient des informations d'authentification qui devraient faire partie du premier message dans une transaction authentifiée. Il contient un ticket, un authentifiant, et quelques informations de comptabilité supplémentaire. Le ticket est insuffisant par lui-même pour authentifier un client, car les tickets passent à travers le réseau. L'authentifiant est utilisé pour empêcher la répétition invalide de tickets en prouvant au serveur que le client connaît la clé de session du ticket et est donc fondé à utiliser le ticket. Le message KRB_AP_REQ est par ailleurs appelé un "en-tête d'authentification".

Génération d'un message KRB_AP_REQ

   Lorsqu'un client souhaite initier l'authentification auprès d'un serveur, il obtient (soit avec un cache d'arréditifs, l'échange d'AS, ou l'échange TGS) un ticket et une clé de session pour le service désiré. Le client peut réutiliser tous les tickets qu'il détient jusqu'à leur expiration. Pour utiliser un ticket, le client construit un nouvel authentifiant à partir de l'heure du système et de son nom, et facultativement à partir d'une somme de contrôle spécifique de l'application, un numéro de séquence initial à utiliser dans les messages KRB_SAFE ou KRB_PRIV, et/ou une sous-clé de session à utiliser dans les négociations pour une clé de session unique pour cette session particulière. Les authentifiants ne doivent pas être réutilisés et devraient être rejetés s'ils sont répétés sur un serveur. Noter que cela peut rendre les applications fondées sur des transports non fiables difficiles à coder correctement. Si le transport peut délivrer des messages dupliqués, un nouvel authentifiant doit être généré pour chaque essai, ou le serveur d'application doit faire correspondre demandes et réponses et répéter la première répétition en réponse à un duplicata détecté.

   Si un numéro de séquence doit être inclus, il devrait être choisi de façon aléatoire de sorte que même après l'échange de nombreux messages il n'y ait aucune probabilité de collision avec un autre numéro de séquence utilisé. Le client peut indiquer une exigence d'authentification mutuelle ou l'utilisation d'un ticket fondé sur une clé de session en mettant le ou les flags appropriés dans le champ ap-options du message. L'authentifiant est chiffré dans la clé de session et combiné avec le ticket pour former le message KRB_AP_REQ, qui est alors envoyé au serveur d'extrémité avec toutes information supplémentaires spécifiques de l'application.

Réception du message KRB_AP_REQ

   L'authentification se fonde sur l'heure courante du serveur, sur l'authentifiant, et sur le ticket. Plusieurs erreurs sont possibles. Si une erreur survient, on attend du serveur qu'il réponde un message KRB_ERROR au client. Ce message peut être encapsulé dans le protocole d'application si sa forme brute n'est pas acceptable pour le protocole.

   L'algorithme de vérification des informations d'authentification est le suivant. Si le type de message n'est pas KRB_AP_REQ, le serveur retourne l'erreur KRB_AP_ERR_MSG_TYPE. Si la version de clé est indiquée par le ticket dans KRB_AP_REQ n'est pas une de celles que le serveur peut utiliser (par exemple, elle indique une vieille clé, et le serveur ne possède plus de copie de la vieille clé), l'erreur KRB_AP_ERR_BADKEYVER est retournée. Si le flag USE-SESSION-KEY est mis dans le champ ap-options, il indique au serveur l'utilisation de l'authentification d'utilisateur à utilisateur. et le chiffrement du ticket avec la clé de session provenant du TGT du serveur plutôt qu'avec la clé secrète du serveur.

   Le champ srealm dans la portion non chiffrée du ticket dans KRB_AP_REQ est utilisé pour spécifier quelle clé secrète devrait utiliser le serveur pour déchiffrer le ticket, parce qu'il est possible au serveur d'être enregistré dans plusieurs domaines, avec des clés différentes dans chacun. Le code d'erreur KRB_AP_ERR_NOKEY est retourné si le serveur n'a pas la clé appropriée pour déchiffrer le ticket.

   Le ticket est déchiffré en utilisant la version de la clé du serveur spécifiée par le ticket. Si la routine de déchiffrement détecte une modification du ticket (chaque système de chiffrement doit fournir des sauvegardes pour détecter le texte chiffré modifié), l'erreur KRB_AP_ERR_BAD_INTEGRITY est retournée (il y a de bonnes chances que différentes clés aient été utilisées pour chiffrer et pour déchiffrer).

   L'authentifiant est déchiffré en utilisant la clé de session extraite du ticket déchiffré. Si le déchiffrement montre qu'il a été modifié, l'erreur KRB_AP_ERR_BAD_INTEGRITY est retournée. Le nom et le domaine du client tirés du ticket sont comparés aux champs correspondants dans l'authentifiant. S'ils ne correspondent pas, l'erreur KRB_AP_ERR_BADMATCH est retournée; ceci est normalement causé par une erreur client ou une tentative d'attaque. Les adresses dans le ticket sont alors examinées à la recherche d'une adresse correspondant à l'adresse mentionnée par le système d'exploitation du client. Si aucune correspondance n'est trouvée, ou si le serveur insiste sur les adresses du ticket mais qu'aucune n'est présente dans le ticket, l'erreur KRB_AP_ERR_BADADDR est retournée. Si l'heure locale du serveur et l'heure du client dans l'authentifiant diffèrent au delà de l'admissible, l'erreur KRB_AP_ERR_SKEW est retournée.

   À moins que le serveur d'application ne fournisse ses propres moyens pour se protéger contre la répétition (par exemple, une séquence challenge-réponse initiée par le serveur après l'authentification, ou l'utilisation d'une sous-clé de chiffrement générée par le serveur), le serveur doit utiliser un cache pour mémoriser tout authentifiant présenté dans la plage de temps admissible. Une analyse soigneuse du protocole et de la mise en œuvre de l'application est recommandée avant d'éliminer ce cache. Le cache mémorise au moins les champ de nom du serveur, de nom du client, et d'heures tirés des authentifiants vus le plus récemment, et si une correspondance est trouvée, l'erreur KRB_AP_ERR_REPEAT est retournée. Noter qu'ici, le rejet est restreint aux authentifiants provenant du même principal vers le même serveur. Les autres principaux de clients qui communiquent avec le même principal du serveur ne devraient pas voir leurs authentifiants rejetés si les champ heure et microseconde se trouvent correspondre à d'autres authentifiants du client.

   Si un serveur perd la trace des authentifiants présentés pendant l'horaire admissible, il doit rejeter toutes les demandes jusqu'à la fin de la plage de temps, lui donnant l'assurance que tout authentifiant perdu ou répété se retrouvera hors plage.

   Note de mise en œuvre: Si un client génère plusieurs demandes au KDC avec le même horodatage, y compris le champ timestamp, toutes les demandes reçues sauf la première seront rejetées comme répétitions. Cela peut arriver, par exemple, si la résolution de l'horloge du client est trop grossière. Les mises en œuvre client devraient s'assurer que les horodatages ne sont pas réutilisés, éventuellement en incrémentant le champ timestamp dans l'horodatage lorsque l'horloge retourne la même heure pour plusieurs demandes.

   Si plusieurs serveur ( par exemple, différents services sur une machine, ou un seul service mis en œuvre sur plusieurs machines ) partagent un principal de service ( pratique non recommandée en général ), ils doivent partager ce cache, ou bien le protocole d'application doit être conçu de façon à en éliminer le besoin. Noter que ceci s'applique à tous les services. Si un protocole d'application n'a pas de protection contre la répétition, un authentifiant utilisé avec un tel service pourrait être répété ultérieurement dans un service différent avec le même principal de service mais sans protection contre la répétition.

   Si un numéro de séquence est fourni dans l'authentifiant, le serveur le sauvegarde pour utilisation ultérieure en traitant les messages KRB_SAFE et/ou KRB_PRIV. Si une sous-clé est présente, le serveur la sauvegarde pour plus tard ou l'utilise pour aider à générer son propre choix d'une sous-clé à retourner dans un message KRB_AP_REP.

   Le serveur calcule l'âge du ticket: heure locale du serveur moins l'heure de début dans le ticket. Si l'heure de début est plus tardive que l'heure en cours de plus que la plage horaire admissible, ou si le flag INVALID est mis, l'erreur KRB_AP_ERR_TKT_NYV est retournée. Autrement, si l'heure en cours est plus tardive que l'heure de fin de plus que la plage admissible, l'erreur KRB_AP_ERR_TKT_EXPIRED est retournée.

   Si toutes ces vérification ont réussi sans erreur, le serveur est assuré que le client possède les accréditifs du principal nommé dans le ticket, et donc, que le client a été authentifié auprès du serveur.

   Réussir ces vérifications ne fournit que l'authentification du principal désigné; cela n'implique pas l'autorisation d'utiliser le service désigné. Les applications doivent gérer l'autorisation sur la base du nom authentifié de l'utilisateur. de l'opération demandée, des informations de commande d'accès locales telles que celles contenues dans un fichier .k5login ou .k5users, et éventuellement d'un service d'autorisation distribué distinct.

Génération d'un message KRB_AP_REP

   Normalement, la demande l'un client va inclure à la fois les informations d'authentification et sa demande initiale dans le même message, et le serveur n'a pas besoin de répondre explicitement au KRB_AP_REQ. Cependant, si l'authentification mutuelle (authentifiant non seulement le client auprès du serveur, mais aussi le serveur auprès du client) est effectuée, le message KRB_AP_REQ aura MUTUAL-REQUIRED établi dans son champ ap-options, et un message KRB_AP_REP est exigé en réponse. Comme avec le message d'erreur, ce message peut être encapsulé dans le protocole d'application si sa forme "brute" n'est pas acceptable pour le protocole d'application. Les champs horodatage et microseconde utilisés dans la réponse doivent être les champs horodatage et microseconde du client (tels que fournis par l'authentifiant). Si un numéro de séquence doit être inclus, il devrait être choisi de façon aléatoire comme décrit ci-dessus pour l'authentifiant. Une sous-clé peut être incluse si le serveur désire négocier une sous-clé différente. Le message KRB_AP_REP est chiffré dans la clé de session extraite du ticket.

Réception du message KRB_AP_REP

   Si un message KRB_AP_REP est retourné, le client utilise la clé de session provenant des accréditifs obtenus pour que le serveur déchiffre le message et vérifie que les champs horodatage et microseconde correspondent à ceux de l'authentifiant qu'il a envoyé au serveur. S'ils correspondent, le client est alors assuré que le serveur est authentique. Le numéro de séquence est la sous-clé ( si présente ) sont conservés pour utilisation ultérieure ( noter que pour chiffrer le message KRB_AP_REP, la sous-clé de session n'est pas utilisée, même si elle est présent dans l'authentification ).

Utilisation de la clé de chiffrement

   Après que l'échange KRB_AP_REQ/KRB_AP_REP est terminé, le client et le serveur partagent une clé de chiffrement qui peut être utilisée par l'application. Dans certains cas, l'utilisation de cette clé de session sera implicite dans le protocole; dans d'autres, la méthode d'utilisation doit être choisie entre plusieurs possibilités. L'application peut choisir la clé de chiffrement réelle à utiliser pour KRB_PRIV, KRB_SAFE, ou d'autres utilisation spécifiques de l'application fondées sur la clé de session à partir du ticket et des sous-clés dans le message KRB_AP_REP et l'authentifiant. Les mises en œuvre du protocole peuvent fournir des routines pour choisir les sous-clés sur la base des clés de session et de nombres aléatoires et générer une clé négociée à retourner dans le message KRB_AP_REP.

   Pour atténuer l'effet des défaillances de la génération de nombres aléatoire chez le client, il est vivement recommandé que toute clé déduite par une application pour utilisation ultérieure incluent la pleine entropie de clé déduite de la clé de session générée par le KDC portée dans le ticket. On laisse les négociations de protocole sur la façon d'utiliser la clé (par exemple, pour choisir un type de chiffrement ou de somme de contrôle) au programmeur de l'application. Le protocole Kerberos n'impose pas de contrainte sur les options de mise en œuvre, mais un exemple de la façon dont cela peut être fait figure ci-après.

   Une façon qu'une application peut choisir pour négocier une clé à utiliser pour la protection ultérieure d'intégrité et de confidentialité est que le client propose une clé dans le champ sous-clé à l'authentifiant. Le serveur peut alors choisir une clé en utilisant la clé proposée par le client en entrée, retournant la nouvelle sous-clé dans le champ sous-clé de la réponse de l'application. Cette clé eut alors être utilisée pour la suite de la communication.

   Avec les échanges d'authentification aussi bien unilatérale que mutuelle, les homologues devraient veiller à ne pas s'envoyer l'un l'autre d'informations sensibles sans garanties appropriées. En particulier, les applications qui exigent la confidentialité ou l'intégrité devraient utiliser la réponse KRB_AP_REP du serveur au client pour que le client et le serveur s'assurent tous deux de l'identité de leur homologue. Si un protocole d'application exige la confidentialité de ses messages, il peut utiliser le message KRB_PRIV. Le message KRB_SAFE peut être utilisé pour s'assurer de l'intégrité.

Échange TGS

   L'échange TGS entre un client et le TGS est initié par un client lorsqu'il cherche à obtenir des accréditifs d'authentification pour un serveur donné (qui peut être enregistré dans un domaine distant), lorsqu'il cherche à renouveler ou valider un ticket existant, ou lorsqu'il cherche à obtenir un ticket mandataire. Dans le premier cas, le client doit déjà avoir acquis un ticket pour le TGS auprès de l'AS ( Le TGT est généralement obtenu quand un client quand un client s'authentifie sur le système ). Le format pour l'échange TGS est presque identique à l'échange AS. La différence principale est que le chiffrement et le déchiffrement dans l'échange TGS n'est pas effectuée dans le clé du client. À la place, le clé de session du TGT ou du ticket renouvelable, ou de la clé de sous-session d'un authentifiant est utilisé. Comme c'est le cas pour tous les serveur d'application, les tickets expirés ne sont pas acceptés par le TGS, donc une fois une TGT ou un renouvelable expiré, le client doit utiliser un échange séparé pour obtenir des tickets valides.

   L'échange TGS consiste de 2 messages: une requête ( KRB_TGS_REQ ), et une réponse ( KRB_TGS_REP ou KRB_ERROR ). Le message KRB_TGS_REQ inclus les informations authentifiant le client plus une requête pour des accréditifs. Les information d'authentification consistent de l'en-tête d'authentification ( KRB_AP REQ ), qui inclus le ticket TGT, renouvelable ou invalide du client précédemment obtenus. Dans les cas de TGT et de proxy, la requête peut inclure un ou plusieurs éléments: une liste d'adresses réseaux, une collection de données d'autorisation typées, ou des tickets supplémentaires. La réponse TGS ( KRB_TGS_REP ) contient es accréditifs demandés, chiffrés dans la clé de session provenant du TGT ou le ticket renouvelable, ou, si elle est présente, dans la sous-clé de session provenant de l'authentifiant. Le message KRB_ERROR n'est pas chiffré. Le message KRB_TGS_REP contient des informations qui peuvent être utilisées pour détecter les répétitions, et pour l'associer au message auquel il répond.

Génération du message KRB_TGS_REQ

   Avant d'envoyer une demande au TGS, le client doit déterminer dans quel domaine il pense qu'est enregistré le serveur d'application. Cela peut se faire de diverses façons. Il peut être connu à l'avance, peut être mémorisé dans un serveur de noms, ou peut être obtenu d'un fichier de configuration. Si le client connaît le nom et le domaine du principal du service et s'il ne possède pas encore un TGT pour le domaine approprié, il doit alors en obtenir un. Il essaye d'abord en demandant un TGT pour le domaine de destination à un serveur Kerberos pour lequel le client possède un TGT ( en utilisant de façon récurrent le message KRB_TGS_REQ ). Le serveur Kerberos peut retourner un TGT pour le domaine désiré, auquel cas le traitement peut se poursuivre. Autrement, le serveur Kerberos peut retourner un TGT pour un domaine qui est plus proche du domaine désiré. Noter que dans ces cas, la mauvaise configuration du serveur Kerberos peut causer les boucles dans le chemin d'authentification résultant. ce que le client devrait veiller à détecter et éviter.

   Si le serveur Kerberos retourne un TGT pour un domaine plus proche que le domaine désiré, le client peut utiliser la configuration de la politique locale pour vérifier que le chemin d'authentification utilisé est acceptable. Autrement, un client peut choisir son propre chemin d'authentification, plutôt que de s'appuyer sur le serveur Kerberos pour en choisir un. Dans les 2 cas, toute information de politique ou de configuration utilisée pour choisir ou valider des chemins d'authentification, par le serveur Kerberos ou par le client, doit être obtenue d'une source de confiance.

   Lorsqu'un client obtient un TGT qui est plus proche du domaine de destination, il peut mettre en cache ce ticket et le réutiliser dans des échange KRB_TGS futures avec les services dans le domaine plus proche. Cependant, si le client devait obtenir un TGT pour le domaine plus proche en commençant au KDC initial plutôt qu'au titre de l'obtention d'un autre ticket, un chemin plus court vers le domaine plus proche pourrait être utilisé. Ce chemin plus court peut être désirable parce que moins de KDC intermédiaires connaîtraient la clé de session du ticket impliqué. Pour cette raison, les clients devraient évaluer s'ils ont confiance dans les domaines de transit pour obtenir le ticket plus proche lorsqu'ils prennent la décision d'utiliser le ticket à l'avenir.

   Une fois que le client a obtenu un TGT pour le domaine approprié, il détermine quels serveur Kerberos servent ce domaine et contacte l'un d'entre eux. Leur liste peut être obtenue par un fichier de configuration ou un service réseau, ou elle peut être générée à partir du nom du domaine. Tant que les clés secrètes échangées par domaine sont gardées secrètes, seul de DOS résulte de l'utilisation d'un faux serveur Kerberos.

   Comme dans l'échange d'AS, le client peut spécifier un certain nombre d'options dans le message KRB_TGS_REQ. Une de ces options est l'options ENC-TKT-IN-SKEY utilisée pour l'authentification d'utilisateur à utilisateur. Lors de la génération du message KRB_TGS_REQ, cette option indique que le client inclut un TGT obtenu du serveur d'application dans le champ de tickets supplémentaires de la demande et que le KDC devrait chiffrer le ticket pour le serveur d'application en utilisant la clé de session provenant de ce ticket supplémentaire, au lieu d'une clé de serveur provenant de la base de données du principal.

   Le client prépare le message KRB_TGS_REQ, qui fournit un en-tête d'authentification comme élément du champ padata, et incluant les même champs qu'utilisés dans le message KRB_AS_REQ avec plusieurs champs facultatifs: le champ enc-authorization-data pour l'usage du serveur d'application et les tickets supplémentaires requis par certaines options.

   Pour préparer l'en-tête d'authentification, le client peut choisir une sous-clé de session avec laquelle sera chiffrée la réponse du serveur Kerberos. Si le client choisit une sous-clé de session, il faut veiller à s'assurer du caractère aléatoire de la sous-clé de session choisie.

   Si la sous-clé de session n'est pas spécifiée, la clé de session provenant du TGT sera utilisée. Si enc-authorization-data est présent, il doit être chiffré dans la sous-clé de session, si elle est présente, à partir de la portion d'authentifiant de l'en-tête d'authentification, ou, si elle n'est pas présente, en utilisant la clé de session provenant du TGT.

   Une fois préparé, le message est envoyé au serveur Kerberos pour le domaine de destination.

Réception du message KRB_TGS_REQ

   Le message KRB_TGS_REQ est traité de manière similaire au message KRB_AS_REQ mais il y a de nombreuses vérification supplémentaires à effectuer. D'abord, le serveur Kerberos doit déterminer pour quel serveur est le ticket d'accompagnement, et il doit choisir la clé appropriée pour le déchiffrer. Pour un message KRB_TGS_REQ normal, ce sera pour le TGS, et la clé du TGS sera utilisée. Si le TGT a été produit par un autre domaine, les clés inter-domaines appropriées doivent être utilisées. Si (a) le ticket d'accompagnement n'est pas un TGT pour le domaine courant, mais est pour un serveur d'application dans le domaine courant, (b) les options RENEW, VALIDATE ou PROXY sont spécifiées dans la demande, et (c) le serveur pour lequel un ticket est demandé est le serveur désigné dans le ticket d'accompagnement, pus le KDC va déchiffrer le ticket dans l'en-tête d'authentification en utilisant la clé du serveur pour lequel elle a été produite. Si aucun ticket ne peut être trouvé dans le champ padata, l'erreur KDC_ERR_PADATA_TYPE_NOSUPP est retournée.

   Une fois que le ticket d'accompagnement a été déchiffré, la somme de contrôle fournie par l'utilisateur dans l'authentifiant doit être vérifiée par rapport au contenu de la demande, et le message doit être rejeté si les sommes de contrôle ne correspondent pas ( avec un code d'erreur KRB_AP_ERR_MODIFIED ) ou si la somme de contrôle n'est pas à l'épreuve des collisions ( avec un code d'erreur KRB_AP_ERR_INAPP_CKSUM ). Si le type de somme de contrôle n'est pas accepté, l'erreur KDC_ERR_SUMTYPE_NOSUPP est retournées.

   Si un des déchiffrements indique un échec de vérification d'intégrité, l'erreur KRB_AP_ERR_BAD_INTEGRITY est retournée. Le KDC doit envoyer un message KRB_TGS_REP valide s'il reçoit un message KRB_TGS_REQ identique à celui qu'il a traité récemment. Cependant, si l'authentifiant est une répétition, mais que le reste de la demande n'est pas identique, de KDC devrait alors retourner KRB_AP_ERR_REPEAT.

Génération du message KRB_TGS_REP

   Le message KRB_TGS_REP partage son format avec KRP_AS_REP, mais avec son champ de typee réglé à KRB_TGS_REP.

   La réponse va comporter un ticket pour le serveur demandé ou pour un serveur d'allocation de ticket d'un KDC intermédiaire à contacter pour obtenir le ticket demandé. La base de données Kerberos est interrogée pour restituer l'enregistrement pour le serveur approprié ( y compris la clé avec laquelle le ticket sera chiffré ). Si la demande est pour un TGT d'un domaine distant, et s'il n'y a pas de partage de clé avec le domaine demandé, le serveur Kerberos va alors choisir le domaine le plus proche du domaine demandé avec lequel il partage une clé et utiliser ce domaine à la place. C'est le seul cas où la réponse pour le KDC sera pour un serveur différent de celui demandé par le client.

   Par défaut, le champ d'adresse, le nom et le domaine du client, la liste des domaines de transit, l'heure de l'authentification initiale, l'heure d'expiration, et les données d'autorisation du ticket nouvellement produit seront copiées du TGT ou du ticket renouvelable. Si les champs de transit ont besoins d'être mis à jour, mais que le type de transit n'est par accepté, l'erreur KDC_ERR_TRTYPE_NOSUPP est retournée.

   Si la demande spécifie une heure de fin, l'heure de fin du nouveau ticket est réglée au minimum de (a) cette demande, (b) de l'heure de fin provenant du TGT, et (c) de l'heure de début du TGT plus le minimum de la durée de vie maximum pour le serveur 'application et la durée de vie maximum pour le domaine local ( la durée de vie maximum pour le principal demandeur a déjà été appliquée lors de la production du ticket ). Si le nouveau ticket doit être un renouvellement, l'heure de fin ci-dessus est alors remplacée par le minimum de (a) la valeur du champ renew_till du ticket et (b) l'heure de début pour le nouveau ticket plus la durée de vie (heure de fin - heure de début ) du vieux ticket.

   Si l'option FORWARDED a été demandée, le ticket résultant contiendra alors les adresses spécifiées par le client. Cette option ne sera honorée que si le flag FORWARDABLE est mis dans le TGT. L'option PROXY est similaire; le ticket résultant contiendra les adresses spécifiées par le client. Elle ne sera honorée que si le flag PROXIABLE est établi dans le TGT. L'option PROXY ne sera pas honorée sur les demandes de TGT supplémentaires.

   Si l'heure de début demandée est absente, indique une heure passée, ou est dans la plage horaire admissible pour le KDC et si l'option POSTDATE n'est pas spécifiée, l'heure de début du ticket est réglée à l'heure en cours de l'AS. Si elle indique une heure dans le futur au delà de la plage horaire admissible, mais l'option POSTDATE n'est pas spécifiée ou si le flag MAY-POSTDATE n'est pas mis dans le TGT, l'erreur KDC_ERR_CANNOT_POSTDATE est alors retournée. Sinon, si le TGT a le flag MAY-POSTDATE mis, le ticket résultant sera postdaté, et l'heure de début demandée sera vérifiée par rapport à la politique du domaine local. Si elle est acceptable, l'heure de début du ticket sera réglée comme demandé, et le flag INVALID sera mis. Le ticket postdaté doit être validé avant utilisation en le présentant au KDC après l'heure de début a été atteinte. Cependant, en aucun cas l'heure de début, de fin, ou de fin de renew-till d'un ticket postdaté nouvellement produit ne peut être étendue au delà de l'heure de renew-till du TGT.

   Si l'option ENC-TGT-IN-SKEY a été spécifiée et si un ticket supplémentaire a été inclus dans la demande, il indique que le client utilise l'authentification d'utilisateur à utilisateur pour prouver son identité à un serveur qui n'a pas d'accès à une clé persistante. Lors de la génération du message KRB_TGS_REP, cette option dans le message KRB_TGS_REQ dit au KDC de déchiffrer le ticket supplémentaire en utilisant la clé pour le serveur auquel le ticket supplémentaire a été produit et de vérifier qu'il est un TGT. Si le nom du serveur demandé manque dans la demande, le nom du client dans le ticket supplémentaire sera utilisé. Autrement, le nom du serveur demandé sera comparé au nom du client dans le ticket supplémentaire. Si c'est différent, la demande sera rejetée. Si la demande réussit, la clé de session provenant du ticket supplémentaire sera utilisée pour chiffrer le nouveau ticket produit au lieu d'utiliser la clé du serveur pour lequel le nouveau ticket sera utilisé.

   si (a) le nom du serveur dans le ticket qui est présenté au KDC au titre de l'en-tête d'authentification n'est pas celui du TGS lui-même, (b) le serveur est enregistré dans le domaine de ce KDC, et (c) l'option RENEW est demandé, donc le KDC va vérifier que le flag RENEWABLE est mis dans le ticket, que le flag INVALID n'est pas mis, et que le temp renew-till est dans le future. Si l'option VALIDATE est requis, le KDC va vérifier que le starttime a passé et que le flag INVALID est mis. Si l'option PROXY est demandé, le KDC va vérifier que le flag PROXIABLE est mis dans le ticket. Si le test réussis et que le ticket passe toutes les vérifications décris dans la prochaine section, le KDC va fournir le nouveau ticket approprié.

   La parie ciphertext de la réponse dans le message KRB_TGS_REP est chiffrée dans la clé de sous-session de l'authentifiant, si présent, ou dans la clé de session du TGT. Elle n'est pas chiffré en utilisant la clé secrète du client. De plus, les champs de date d'expiration de la clé du client et de numéro de version de clé sont laissés de côté car ces valeurs sont stockées avec les enregistrements de la base de données du client, et il n'y a pas besoin de cet enregistrement pour satisfaire une demande sur la base d'un TGT.

Recherche de tickets révoqués

   Chaque fois qu'une demande est faite au TGS, le ou les tickets présentés sont confrontés à une liste rouge de tickets annulés. Celle liste peut être mise en œuvre en mémorisant une gamme d'horodatages de production de tickets suspects; si un ticket présenté a un authtime dans cette gamme, il sera rejeté. De cette façon, un TGT volé ou un ticket renouvelable ne peut pas être utilisé pour obtenir des tickets supplémentaires une fois que le vol a été rapporté au KDC pour le domaine dans lequel réside le serveur. Tout ticket normal obtenu avant qu'il ait été rapporté volé sera toujours valide ( parce que les tickets n'exigent pas l'interaction avec le KDC ), mais seulement jusqu'à son heure d'expiration normale. Si les TGT ont été produites pour une authentification inter-domaine, l'utilisation du TGT inter-domaine se sera pas affectée sauf si la liste rouge est transmise aux KDC pour les domaines pour lesquels de tels tickets inter-domaine avaient été produits.

Codage du champ de transit

   Si l'identité du serveur dans le TGT qui est présenté au KDC au titre de l'en-tête d'authentification est celle du service d'allocation de tickets, mais si le TGT a été produit à partir d'un autre domaine, le KDC va chercher la clé inter-domaines partagée avec ce domaine et utiliser cette clé pour déchiffrer le ticket. Se le ticket est valide, le KDC va alors honorer la demande, sous réserve des contraintes soulignées ci-dessus au paragraphe qui décrit l'échange d'AS. La partie domaine de l'identité du client sera tirée du TGT. Le nom de domaine qu'a produit le TGT, si ce n'est par le domaine du principal client, sera ajouté au champ de transit du ticket à produire. Ceci est accomplis en lisant le champ de transit d'après de TGT ( qui est traité comme un ensemble non ordonné de noms de domaines ), en ajoutant le nouveau domaine à l'ensemble, et en construisant et écrivant sa forme ( abrégée ) codée (ce qui peut impliquer un réarrangement du codage existant ).

   Noter que le service d'allocation de tickets n'ajoute pas le nom de son propre domaine. Au lieu de cela, sa responsabilité est d'ajouter le nom du domaine précédent. Cela empêche un serveur Kerberos malveillant d'inscrire intentionnellement son propre nom ( il pourrais cependant omettre les noms d'autres domaines ).

   Ni les noms du domaine local ni ceux du domaine du principal ne sont à inclure dans le champ de transit. Ils apparaissent ailleurs dans le ticket et tous deux sont connus pour prendre part à l'authentification du principal. Parce que les points d'extrémité ne sont pas inclus, aussi bien l'authentification inter-domaine local que celle à un seul bond résulte en un champ de transit qui est vide.

   Comme à ce champ est ajouté le nom de chaque domaine de transit, il peut éventuellement être très long. Pour diminuer la longueur de ce champ, son contenu est codé. Les codages initialement acceptés sont optimisés sur le cas normal de communication inter-domaine: un arrangement hiérarchique de domaines utilisant les noms de domaine de style domaine ou X.500. Ce codage ( appelé DOMAIN-X500-COMPRESS ) est décris ci-dessous.

   Les noms de domaine dans le champ de transit sont séparés par une ",", les caractères ",", "\", les "." de fin, et les espaces d'en-tête sont des caractères spéciaux, et s'ils font partie d'un nom de domaine, ils doivent être entre guillemets dans le champ de transit en les faisant précéder d'un "\"

   Un nom de domaine se terminant par un "." est interprété comme étant ajouté au domaine précédent. Par exemple, ou peut coder la traversée de EDU, MIT.EDU, ATHENA.MIT.EDU, , WASHINGTON.EDU, et CS.WASHINGTON.EDU par:

  "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS."

  Noter que si ATHENA.MIT.EDU, ou CS.WASHINGTON.EDU étaient des points d'extrémité, ils ne seraient pas inclus dans ce champ, et on aurait:

  "EDU,MIT.,WASHINGTON.EDU"

   Un nom de domaine commençant par un "/" est interprété comme ayant été ajouté au domaine précédent. Pour les besoins de l'ajout, le domaine précédant le premier domaine de la liste est considéré comme le domaine nul (""). Si un nom de domaine commençant par un "/" doit être autonome, il devrait alors être précédé d'un espace (" "). Par exemple, on pour coder la traversée de /COM/HP/APOLLO,/COM/HP,/COM, et /COM/DEC par:

  "/COM,/HP,/APOLLO, /COM/DEC"

  Comme dans l'exemple ci-dessus, si /COM/HP/APOLLO et /COM/DEC étaient des points d'extrémité, ils ne seraient pas inclus dans ce champ:

  "/COM,/HP"

   Un sous-champ nul précédant ou suivant une "," indique que tous les domaines entre le domaine précédent et le prochain domaine ont été traversés. Pour les besoins de l'interprétation des sous-champs nuls, le domaine du client est considéré comme précédant ceux du champ de transit, et le domaine du serveur est considéré les suivre. Et donc, "," signifie que tous les domaines le long du chemin entre le client et le serveur ont été traversées. ",EDU, /COM," signifie que tous les domaines depuis le domaine du client jusqu'à EDU ( dans une hiérarchie de type domaine ) ont été traversés, et que tous depuis /COM jusqu'au domaine du serveur dans un style X.500 ont aussi été traversés. Cela pourrait survenir si le domaine EDU dans une hiérarchie partage une clé inter-domaine directement avec le domaine /COM dans une autre hiérarchie.

Réception du message KRB_TGS_REP

   Lorsque le message KRB_TGS_REP est reçu par le client, il est traité de la même manière que le traitement KRB_AS_REP décrit ci-dessus. La principale différence est que la partie chiffrée de la réponse doit être déchiffrée en utilisant la sous-clé de session provenant de l'authentifiant, s'il a été spécifié dans la demande, ou la clé de session provenant du TGT, plutôt que la clé secrète du client. Le nom du serveur retourné dans la réponse est le vrai nom du principal du service.

L'échange KRB_SAFE

   Le message KRB_SAFE peut être utilisé par des clients qui exigent la capacité à détecter les modifications des messages qu'ils échangent. Ceci est réalisé en incluant une somme de contrôle à l'épreuve des collisions des données utilisateur et de quelques informations de contrôle. La somme de contrôle est assortie avec une clé de chiffrement ( normalement la dernière clé négociée via des sous-clés, ou la clé de session si aucune négociation n'est survenue.

Génération d'un message KRB_SAFE

   Lorsqu'une application souhaite envoyer un message KRB_SAFE, elle collecte ses données et les informations de contrôle appropriées et calcule une somme de contrôle sur l'ensemble. L'algorithme de somme de contrôle devrait être la somme de contrôle assortie mandatée pour être mise en œuvre ainsi que le système de chiffrement utilisé pour la clé de session ou de sous-session. La somme de contrôle est générée en utilisant la sous-clé de session, si elle est présente, ou la clé de session. Certaines mise en œuvre utilisent un algorithme de somme de contrôle différent pour les messages KRB_SAFE mais il n'est pas toujours possible de faire ainsi de façon interopérable.

   Les informations de contrôle pour le missage KDB_SAFE comportent à la fois un horodatage et un numéro de séquence. Le concepteur d'une application utilisant le message KRB_SAFE doit choisir au moins un des 2 mécanismes. Ce choix devrait se fonder sur les besoins du protocole d'application.

   Les numéros de séquence sont utiles lorsque tous les messages envoyés sont reçus par l'homologue. L'état de connexion est actuellement exigé pour l'entretien de la clé de session, aussi la maintenance du prochain numéro de séquence ne devrait pas présenter de problème supplémentaire.

   Si le protocole d'application est prévu pour tolérer des pertes de messages sans qu'ils soient renvoyés, l'utilisation de l'horodatage est le mécanisme de détection de répétition approprié. L'utilisation des horodatages est aussi le mécanisme approprié pour les protocoles de diffusion groupée dans lesquels tous les homologues partagent une sous-clé de session commune, mais certains messages seront envoyés à un sous-ensemble d'un homologue.

   Après le calcul de la somme de contrôle, le client transmet les informations et la somme de contrôle au receveur.

Réception du message KRB_SAFE

   Lorsqu'une application reçoit un message KRB_SAFE, elle le vérifie comme suit. Si une erreur survient, un code d'erreur est retourné.

   On vérifie d'abord que les champs version et type du protocole du message correspondent respectivement à la version en cours et à KRB_SAFE. Une discordance génère une erreur KRB_AP_ERR_BADVERSION ou KRB_AP_ERR_MSG_TYPE. L'application vérifie que la somme de contrôle utilisée est une somme de contrôle à l'épreuve des collisions qui utilise des clés compatibles avec la clé de session ou clé de sous-session selon le cas approprié ( ou la clé d'application déduite des clés de session ou de sous-session ). Si ce n'est pas le cas, une erreur KRB_AP_ERR_INAPP_CKSUM est générée. D'adresse de l'expéditeur doit être incluse dans les informations de contrôle; le receveur vérifie que le rapport du système d'exploitation de l'adresse de l'expéditeur correspond à l'adresse de l'expéditeur dans le message, et ( si une adresse de réception est spécifiée ou si le receveur exige une adresse ) qu'une des adresses du receveur apparaît comme adresse de réception dans le message. Pour travailler avec la traduction d'adresse réseau, les expéditeurs peuvent utiliser le type d'adresse directionnel pour l'adresse d'expéditeur et ne pas inclure d'adresse de receveur. Un échec de correspondance pour l'un de ces cas génère une erreur KRB_AP_ERR_BADADDR. Puis les champs timestamp et usec et/ou de numéro de séquence sont vérifiés. Si timestamp et usec sont attendus et absents, ou s'ils sont présents mais ne sont pas ceux en cours, l'erreur KRB_AP_ERR_SKEW est générée. Il n'est pas exigé que les timestamp soient strictement ordonnées; il est seulement exigé qu'ils soient dans la plage permise. Si les champs nom du serveur, ainsi que nom du client, heure, et microsecondes de l'authentifiant correspondent à de tels tuples récemment vus (envoyés ou reçus), l'erreur KRB_AP_ERR_REPEAT est générée. Si un numéro de séquence incorrect est inclus, ou si un numéro de séquence est attendu mais n'est pas présent, l'erreur KRB_AP_ERR_BADORDER est générée. Si ni un timestamp ni usec ni un numéro de séquence ne sont présents, une erreur KRB_AP_ERR_MODIFIED est générée. Finalement, la somme de contrôle est calculée sur les informations de données te de contrôle, et si elle ne correspond pas à la somme d contrôle reçue, une erreur KRB_AP_ERR_MODIFIED est générée.

   Si toutes les vérification réussissent, l'application est sûr que le message a été généré par son homologue et n'a pas été modifié dans le transit.

   Les mises en œuvre devraient accepter tout algorithme de checksum qui a à la fois la sécurité adéquate et des clés compatibles avec la clé de session ou de sous-session. Les chechsums non keyed ou qui ne sont pas à l'épreuve des collisions ne conviennent pas pour cette utilisation.

L'échange KRB_PRIV

   Le message KRB_PRIV peut être utilisé par les clients qui exigent la confidentialité et la capacité à détecter les modifications des messages échangés. Il réalise cela en chiffrant les messages et en ajoutant des informations de contrôle.

Génération du message KRB_PRIV

   Lorsqu'une application souhaite envoyer un message KRB_PRIV, elle collecte ses données et les informations de contrôle appropriées et les chiffre avec une clé de chiffrement ( habituellement la dernière clé négociée via des sous-clés, ou la clé de session si aucune négociation n'est survenue ). Au titre des informations de contrôle, le client doit choisir d'utiliser soit un timestamp soit un numéro de séquence (ou les 2). Après le chiffrement des données d'utilisateur et des informations de contrôle, le client transmet le texte chiffré et certaines des informations "d'enveloppe" au receveur.

Réception du message KRB_PRIV

   Lorsqu'une application reçoit un messagse KRB_PRIV, elle le vérifie comme suit. Si une erreur survient, un code d'erreur est rapporté.

   Il est d'abord vérifié que les champs de version et type du protocole du message correspondent respectivement à la version en cours et au KRB_PRIV. Une discordance génère une erreur KRB_AP_ERR_BADVERSION ou KRB_AP_ERR_MSG_TYPE. L'application déchiffre ensuite le texte chiffré et traite le texte clair qui en résulte. Si le déchiffrement montre que les données ont été modifiées, une erreur KRB_AP_ERR_BAD_INTEGRITY est générée.

   L'adresse de l'éxpéditeur doit être incluse dans les informations de contrôle; le receveur vérifie que le rapport du système d'exploitation de l'adresse de l'expéditeur correspond à l'adresse de l'expéditeur dans le message. Si une adresse de receveur est spécifiée ou si le receveur exige une adresse, une des adresse du receveur doit également apparaître comme adresse de receveur dans le message. Lorsqu'une adresse d'expéditeur ou de receveur peut ne par correspondre à l'adresse du message à cause d'une traduction d'adresse réseau, une application peut être écrite pour utiliser les adresses du type d'adresse directionnel à la place de l'adresse réseau réelle.

   Après cela intervient la vérification des champs timestamp et usec et/ou de numéro de séquence. Si le timestamp et usec sont attendus et ne sont pas présents, ou s'ils sont présents mais ne sont pas ceux en cours, l'erreur KRB_AP_ERR_SKEW est générée. Si les champs de nom du serveurs, ainsi que le nom du client, l'heure, et microseconde provenant de l'authentifiant correspondent à tout tuple de ces valeurs vu récemment, l'erreur KRB_AP_ERR_REPEAT est générée. Si un numéro de séquence incorrect est inclus, ou si un numéro de séquence est attendu mais n'est pas présent, l'erreur KRB_AP_ERR_BADORDER est générée. Si ni un timestamp, ni usec ni un numéro de séquence n'est présent, une erreur KRB_AP_ERR_MODIFIED est générée.

   Si toutes les vérifications réussissent, l'application peut supposer que le message a été généré par son homologue et a été transmis en toute sécurité.

L'échange KRB_CRED

   Le message KRB_CRED peut être utilisé par les clients qui exigent la capacité à envoyer des accréditifs Kerberos d'un hôte à l'autre. Ceci est réalisé par l'envoi des tickets avec les données chiffrées qui contiennent les clés de session et les autres informations associées à ces tickets.

Génération d'un message KRB_CRED

   Lorsqu'une application souhaite envoyer un message KRB_CRED, elle obtient d'abord ( en utilisant l'échange KRB_TGS ) des accréditifs à envoyer à l'hôte distant. Elle construit ensuite un message KRB_CRED en utilisant le ou les tickets ainsi obtenus, plaçant la clé de session qu'il est nécessaire d'utiliser pour chaque ticket dans le champ clé de la séquence KrbCredInfo correspondante dans la partie chiffrée du message KRB_CRED.

   Les autres information associées à chaque ticket et obtenues durant l'échange KRB_TGS sont aussi placées dans la séquence KrbCredInfo correspondante dans la partie chiffrée du message KRB_CRÉD. L'heure courante et, s'ils sont spécifiquement exigés par l'application, les champs nonce, s-address, et r-address sont placés dans la partie chiffrée du message KRB_CRED, qui est alors chiffré avec la clé de chiffrement précédemment échangée dans le KRB_AP ( habituellement la dernière clé négociée via des sous-clés, ou la clé de session si aucune négociation n'est intervenue ).

   Note de mise en œuvre: lors de la construction d'un message KRB_CRED pour l'inclure dans un jeton de contexte initial GSS-API, la mise en œuvre MIT de Kerberos ne chiffrera pas le message KRB_CRED si la clé de session est DES ou triple DES. Pour l'intéropérabilité avec MIT, la mise en œuvre Microsoft ne chiffrera pas le KRB_CRED dans un jeton GSS-API si elle utilise une clé de session DES. MIT Kerberos peut recevoir et décoder des jetons KRB_CRED chiffrés ou non dans l'échange GSS-API. La mise en œuvre Heimdal de Kerberos peut aussi accepter des messages KRB_CRED chiffrés ou non. Comme le message KRB_CRED dans un jeton GSS-API est chiffré dans l'authentifiant, le comportement du MIT ne présente pas de problème de sécurité, bien qu'il soit en violation de la spécification Kerberos.

Réception d'un message KRB_CRED

   Lorsqu'une application reçoit un message KRB_CRED, elle le vérifie. Si une erreur survient, un code d'erreur est rapporté pour être utilisé par l'application Le message est vérifié en s'assurant que les champs de version et type de protocole correspondent respectivement à la version en cours et à KRB_CRED. Une discordance génère une erreur KRB_AP_ERR_BADVERSION ou KRB_AP_ERR_MSG_TYPE. L'application déchiffre alors le texte chiffré et traite le texte clair résultant. Si le déchiffrement montre que les données ont été modifiées, une erreur KRB_AP_ERR_BAD_INTEGRITY est générée.

   Si elle est présente ou exigé, le receveur peut vérifier que le rapport du système d'exploitation sur l'adresse de l'expéditeur correspond à l'adresse de l'expéditeur dans le message, et qu'une des adresse de réception apparaît comme adresse de réception dans le message. La vérification d'adresse ne fournit aucune sécurité supplémentaire, car l'adresse, si elle est présente, a déjà été vérifiée dans le message KRB_AP_REQ et il n'y a aucun intérêt pour un agresseur à retourner un message KRB_CRED à celui qui l'a généré. Et donc, le receveur peut ignorer l'adresse même si elle est présente afin de mieux travailler dans des environnement de traducteur d'adresses réseau (NAT). L'échec de correspondance pour l'un de ces cas génère une erreur KRB_AP_ERR_BADADDR. Les receveurs peuvent sauter la vérification d'adresse, car le message KRB_CRED ne peut généralement pas être reflété à celui qui l'a généré. Les champs timestamp et usec ( et nonce, s'il est exigé) sont vérifiés ensuite. Si timestamp et usec ne sont pas présents, ou s'ils sont présents mais ne sont pas celui en cours, l'erreur KRB_AP_ERR_SKEW est générée.

   Si toutes les vérifications ont réussi, l'application mémorise chacun des nouveaux tickets dans sa mémoire cache d'accréditifs avec la clé de session et les autres informations dans la séquence KrbCredInfo correspondante de la partie chiffrée du message KRB_CRED.

Échanges d'authentification user to user

   L'authentification d'utilisateur à utilisateur fournit une méthode pour effectuer l'authentification lorsque le vérificateur n'a pas accès à un service de clé à long terme. Ce peut être le cas lorsqu'on utilise un serveur (par ex: un serveur Windows) comme utilisateur sur une workstation. Dans un tel cas, le serveur peut avoir accès au TGT obtenu lorsque l'utilisateur se connecte sur la workstation, mais comme le serveur fonctionne comme un utilisateur non privilégié, il peut ne pas avoir accès aux clés du système. Des situations similaires peuvent survenir en faisant fonctionnes des applications paire-à-paire.

   Pour traiter ce problème, le protocole Kerberos permet au client de demander que le ticket produit par le KDC soit chiffré en utilisant une clé de session provenant d'un TGT produit par la partie qui va vérifier l'authentification. Ce TGT doit être obtenu du vérificateur au moyen d'un échange extérieur au protocole Kerberos, habituellement au titre du protocole d'application. Noter que parce que le TGT est chiffré avec la clé secrète du KDC, il ne peut pas être utilisé pour l'authentification sans la possession de la clé secrète correspondante. De plus, parce que le vérificateur ne révèle pas la clé secrète correspondante, fournir le TGT du vérificateur ne permet pas de se faire passe pour le vérificateur.

   Le premier message est une négociation spécifique de l'application entre le client et le serveur, à la fin de laquelle tous deux ont déterminé qu'ils vont utiliser l'authentification d'utilisateur à utilisateur, et le client a obtenu le TGT du serveur.

   Ensuite, le client inclut le TGT du serveur comme ticket supplémentaire dans sa demande KRB_TGS_REQ au KDC et spécifie l'option ENC-TKT-IN-SKEY dans sa demande.

   S'il est validé, le ticket d'application retourné au client va être chiffré en utilisant la cé de session provenant du ticket supplémentaire et le client va le noter lorsqu'il utilise ou mémorise le ticket d'application.

   Lorsqu'il contacte le serveur en utilisant un ticket obtenu pour l'authentification l'utilisateur à utilisateur, le client doit spécifier le flag USE-SESSION-KEY dans le champ ap-options. Cela dit au serveur d'application d'utiliser la clé de session associée à son TGT pour déchiffrer le ticket de serveur fourni dans la demande d'application.

Spécifications de chiffrement et de checksum

   Les protocoles Kerberos décrits dans le présent document sont conçus pour le chiffrement de messages de tailles arbitraires, en utilisant le chiffrement de flux ou de blocs. Le chiffrement est utilisé pour prouver les identités des entités du réseau qui participent à l'échange de messages. Le KDC pour chaque domaine est de confiance pour tous les principaux enregistrés dans ce domaine pour mémoriser une clé secrète. La preuve de la connaissance de cette clé secrète est utilisée pour vérifier l'authenticité d'un principal.

   Le KDC utilise la clé secrète du principal ( dans l'échange d'AS ) ou une clé de session partagée ( dans l'échange de TGS ) pour chiffrer les réponses aux demandes de ticket; la capacité à obtenir la clé secrète ou la clé de session implique la connaissance des clés appropriées et l'identité du KDC. La capacité d'un principal à déchiffrer la réponse du KDC et à présenter un ticket et un authentifiant correctement formé ( généré avec la clé de session provenant de la réponse du KDC ) à un service vérifie l'identité du principal; de même, la capacité du service à extraire la clé de session du ticket et à prouver ainsi sa connaissance du secret dans une réponse vérifie d'identité du service.


   L'opération string-to-key fournie par la rfc3961 est utilisée pour produire une clé à long terme pour un principal ( généralement pour un utilisateur ). La chaîne salt par défaut, si fournis via les données de pré-authentification, est l'enchaînement des composants de domaine et de nom du principal, dans l'ordre, et sans séparateur. Sauf indication contraire, on utilise l'ensemble des paramètres opaque de string-to-key par défaut comme définis dans la rfc3961.

   Les données chiffrées, et les checksums sont transmis en utilisant les objets de données EncryptedData, EncryptionKey, et Checksum. Les opérations de chiffrement, déchiffrement, et de checksums décrites dans le présent document utilisent les opérations correspondantes de chiffrement, déchiffrement, et get_mic décrites dans la rfc3961, avec la génération implicite de clé spécifique utilisant les valeurs de KeyUsage spécifiées dans la description de chaque objet EncryptedDate ou Checksum pour faire varier la clé pour chaque opération. Noter que dans certains cas, la valeur à utiliser dépend de la méthode de choix de la clé ou du contexte du message.

   Les utilisations de clé sont des entiers non signés 32-bits, le 0 n'est pas permis. Les valeurs d'utilisation de clé de 512 à 1023 sont réservés pour des utilisation internes à une mise en œuvre de Kerberos. ( par exemple, alimenter un générateur de nombre pseudo-aléatoire avec une valeur produite en chiffrant quelque chose avec une clé de session et une valeur d'utilisation de clé non utilisée pour un autre objet. ) Les valeurs d'utilisation de clé de 1024 à 2047 sont réservés à l'usage des applications; les applications devraient utiliser des valeurs paires pour le chiffrement et des valeurs impaires pour les checksums dans cette gamme.

   Il peut exister d'autres documents qui définissent les protocoles dans les termes des types de chiffrement ou de checksums de la rfc1510. Ces documents ne connaissent rien sur les utilisations de clé. Afin que ces spécifications continuent d'avoir un sens en attendant leur mise à jour, si aucune valeur d'utilisation de clé n'est spécifié, les utilisation de clé 1024 et 1025 doivent être utilisés pour déduire les clés pour le chiffrement et les checksums, respectivement. ( ceci ne s'applique pas aux protocoles qui ont leur propre chiffrement indépendemment du présent cadre, en utilisant directement la clé qui résulte de l'échange d'authentification de Kerberos. ) De nouveaux protocoles définis en termes de types de chiffrement et de checksum Kerberos devraient utiliser leurs propres valeurs d'utilisation de clé.

   Sauf indication contraire, aucun chaînage d'état de chiffrement n'est fait d'une opération de chiffrement à un autre.

   Note de mise en œuvre: Bien que ce ne soit pas recommandé, certains protocoles d'application vont continuer d'utiliser directement les données de clé, même si c'est seulement dans les spécifications de protocole qui existent actuellement. Une mise en œuvre destinée à prendre en charge les applications Kerberos générales peuvent donc avoir besoin de rendre disponibles les données de clé, ainsi que les attributs et opérations décrits dans la rfc3961. Une des raisons les plus courantes pour effectuer directement le chiffrement est le contrôle direct sur la négociation et le choix d'un algorithme de chiffrement suffisamment fort ( dans le contexte d'une application de données ). Bien que Kerberos ne fournisse pas directement de facilité de négociation des types de chiffrement entre le client et le serveur d'application, il y a des approches qui utilisent Kerberos pour faciliter cette négociation. Par exemple, un client peut ne demander que des types de clé de session suffisamment fort au KDC et espérer que tout type retourné par le KDC sera compris et pris en charge par le serveur d'application.

Spécifications de message

   Le protocole Kerberos est défini ici en termes de notation ASN.1, qui fournit une syntaxe de spécification à la fois de la disposition abstraite des messages du protocole et de leurs codages. Les mises en œuvre qui n'utilisent pas un compilateur ASN.1 existant ou une bibliothèque de soutien devraient avoir une bonne compréhension de la spécification ASN.1 réelle afin de s'assurer d'un comportement correcte de la mise en œuvre.

   Noter qu'en plusieurs endroits, ds changements des types abstraits ont été faits par rapport à la rfc1510. Ceci en partie pour répondre à des hypothèses largement répandues faites par diverses mises en œuvre, qui résultent dans certains cas de violations non intentionnelles de la norme ASN.1. Elles sont clairement mentionnées lorsqu'elles surviennent. Les différences entre les types abstraits de la rfc1510 et les types abstraits dans le présent document peuvent causer l'émission de codages incompatibles quand on utilise certaines règles de codage, par exemple, les règles de codage compact ( PER, Packed Encoding Rules ). Cette incompatibilité théorique ne devrait pas être pertinente pour Kerberos, car Kerberos spécifie explicitement l'utilisation des règles de codage en méta-langage distinctif (DER, Distinguished Encoding Rules). Ce peu être un problème pour les protocoles qui cherchent à utiliser les types de Kerberos avec d'autres règles de codage. ( Cette pratique n'est pas recommandée ) À très peu d'exceptions près ( en particulier d'utilisation du BIT STRING ), les codages résultant de l'utilisation de DER restent identiques entre les types définis dans la rfc1510 et les types définis dans le présent document.

Les définitions de type de la présente section supposent une définition de module ASN.1 de la forme suivante:
KerberosV5Spec2 {
    iso(1) identified-organisation(3) dod(6) internet(1)
    security(5) kerberosV5(2) modules(4) krb5spec2(2)
} DEFINITIONS EXPLICIT TAGS ::= BEGIN
    -- reste de la définition ici
END

   Ceci spécifie que le contexte d'étiquetage du module devra être explicite et non automatique. Noter que dans certaines autres publications ( comme la rfc1510 et la rfc1964 ), la portion "dod" de d'identifiant d'objet est spécifiée par erreur comme ayant la valeur de "5". Dans le cas de la rfc1964, l'utilisation de la valeur d'OID correcte résulterait en un changement du protocole du câble; elle reste donc inchangée pour l'instant.

   Noter qu'ailleurs dans le document, la nomenclature de divers types de message est incohérente, mais elle suit largement les conventions du langage C, y compris l'utilisation du caractère souligné (_) et de l'écriture en majuscules de noms destinés à être des constantes numériques. Aussi, à certains endroits, les identifiants ( particulièrement ceux qui se réfèrent à des constantes ) sont écrits en majuscules afin de les distinguer du texte explicatif environnant.

   La notation ASN.1 ne permet pas de souligner dans les identifiants, aussi dans les définitions ASN.1 réelles, les soulignés sont remplacés par le traits d'union (-). De plus, les noms de membre de la structure et les valeur définies en ASN.1 doivent commencer par une lettre minuscule, alors que les noms du types doivent commencer par une majuscule.

Notes de compatibilité ASN.1

   Pour les besoins de la compatibilité, les mises en œuvre devraient tenir compte des notes spécifiques suivantes concernant l'utilisation de l'ASN.1 dans Kerberos. Ces notes ne décrivent pas les variantes standard de l'ASN.1. L'objet de ces notes est plutôt de décrire quelques bizarreries historiques et non la conformité de diverses mises en œuvre, ainsi que des ambiguïtés historiques, qui, bien qu'elles soient de l'ASN.1 valide, peuvent amener une certaine confusion dans la mise en œuvre.

Règles de codage distinct ASN.1

   Les codage des messages du protocole Kerberos doit obéir aux règles de codage en DER de l'ASN.1 telles que décrites dans X690. Certaines mises en œuvre ( qui sont principalement celles dérivées de DCE 1.1 et antérieures ) sont connues pour utiliser les règles de codage de base ( BER ) les plus générales; en particulier, cet mises en œuvre envoient des codages de longueur indéfinie. Les mises en œuvre peuvent accepter de tels codages dans l'intérêt de la rétro compatibles, bien qu'on doive prévenir les mises en œuvre que le décodage du BER le plus général est plein de périls.

Champs d'entier facultatifs

   Certaines mises en œuvre de distinguent par en interne entre une valeur d'entier facultative omise et une valeur transmise de zéro. Les endroits du protocole où ceci est pertinent sont divers champs de micro-secondes, de noms occasionnels, et de numéro de séquence. Les mises en œuvre devraient traiter les valeurs d'entier facultatives omises comme ayant été transmises avec une valeur de zéro, si c'est ce qu'attend l'application.

Types SEQUENCE OF vides

   Il y a des endroits du protocole où un message contient un type de SEQUENCE OF qui est un membre facultatif. Il peut en résulter un codage contenant une SEQUENCE OF vide. Le protocole Kerberos ne fait pas de distinction sémantique entre un type de SEQUENCE OF facultatif absent et un type de SEQUENCE OF facultatif présent mais vide. Les mises en œuvre ne devraient pas envoyer de codages de SEQUENCE OF vides marqués OPTIONAL, mais devraient les accepter comme équivalents à un type OPTIONAL vide. Dans la syntaxe ASN.1 qui décrit les messages Kerberos, les instances de ces types de SEQUENCE OF facultatifs problématiques sont indiquées avec un commentaire.

Tag Numbers non reconnus

   De futures révisions du présent protocole pourraient comporter de nouveaux types de message avec des numéros d'étiquette de classe APPLICATION différents. De telles révisions devraient protéger les mises en œuvre plus anciennes en envoyant seulement les types de messages que les parties comprennent; par exemple, au moyen d'un flag mis par le receveur dans une demande précédente. Dans l'intérêt de la robustesse du traitement d'erreurs, les mises en œuvre devraient accepter de traiter de toutes façons un message reçu avec une étiquette non reconnue, et retourner le cas échéant un message d'erreur.

   En particulier, les KDC devraient retourner KRB_AP_ERR_MSG_TYPE si le tag incorrecte est envoyé sur TCP. Les KDC ne devraient pas répondre aux messages reçus avec un tag inconnus sur UDP afin d'éviter les attaques DOS. Pour les applications non KDC, la mise en œuvre de Kerberos indique normalement une erreur à l'application qui prend les mesures appropriées sur la base du protocole d'application.

Tag Number supérieurs à 30

   Une mise en œuvre simple de décodeur ASN.1 DER peut rencontrer des problèmes avec les numéros d'étiquette ASN.1 supérieures à 30, du fait que de tels numéros sont codés en utilisant plus d'un octet. Les révisions futures du présent protocole pourraient utiliser les numéros supérieurs à 30, et les mises en œuvre devraient être préparées à retourner une erreur, le cas échéant, lorsqu'elles ne reconnaissent pas l'étiquette.

Types Kerberos de base

   Ce paragraphe définit un certain nombre de types de base qui sont éventuellement utilisés dans plusieurs messages du protocole Kerberos

KerberosString

   La spécification d'origine du protocole Kerberos dans la rfc1510 utilise GeneralString à de nombreux endroits pour les données de chaîne human-readable. Les mise en œuvre historiques de Kerberos ne peuvent pas utiliser toute la puissance de GeneralString. Ce type ASN.1 exige l'utilisation de séquences d'échappement de désignation et d'invocation comme spécifié dans la norme ISO-2022/ECMA-35 pour commuter les ensembles de caractères, et l'ensemble de caractères par défaut qui est conçus désigné sous le nom de G0 est la version de référence internationale ( IRV ) - US ASCII de ISO-646/ECMA-6.

   La nomes ISO-2022/ECMA-35 définit 4 éléments de code d'ensemble de caractèrse (G0 à G3) et 2 éléments de code de fonction de contrôle (C0 à C1). DER interdit la désignation des ensembles de caractères autres que les ensembles G0 et C0. Malheureusement, cela semble avoir l'effet collatéral d'interdire l'utilisation de l'ensemble de caractères ISO Latin (ISO-8859) ou de tout autre ensemble de caractères qui utilise un jeu de 96 caractères, comme ISO-2022/ECMA-35 interdit de les désigner comme l'élément de code G0.

   En pratique, de nombreuses mises en œuvre traitent GeneralStrings comme chaînes 8 bits par défaut quel que soit le jeu de caractères, sans considération de l'utilisation correcte des séquences d'échappement. Le jeu de caractères par défaut est souvent déterminé par la localisation du systèmes d'exploitation de l'utilisateur habituel. Au moins une mise en œuvre majeure place des caractères Unicode codés en UTF-8 dans GeneralString. Cette incapacité à s'en tenir aux spécifications de GeneralString a pour conséquence des problèmes d'interopérabilité lorsque des codages de caractères incompatibles sont utilisés par des client, services et KDC Kerberos.

   Cette situation malheureuse est le résultat d'une documentation défectueuse des restrictions du type ASN.1 de GeneralString dans les spécifications Kerberos précédentes. Le nouveau (post-RFC 1510) type KerberosString, défini ci-dessous est une GeneralString qui a pour contrainte de ne contenir que des caractères en IA5String.

  KerberosString := GeneralString (IA5String)

   En général, les caractères de contrôle US-ASCII ne devraient pas être utilisés dans KerberosString. Les caractères de contrôle ne devraient pas être utilisés dans des noms de principal ou des noms de domaine

   Pour la compatibilité, les implémentations peuvent choisir d'accepter les valeurs de GeneralString qui contiennent des caractères autres que ceux permis par IA5String, mais elles devraient être conscientes que les codes de désignation de jeu de caractères seront vraisemblablement absents, et que le codage devrait probablement presque de toutes façons être traité comme spécifique de la localisation. Les implémentations peuvent aussi choisir d'émettre des valeurs de GeneralString qui sont au-delà ce celles permises par IA5String, mais elles devraient être conscientes que faire cela est extraordinairement risqué du point de vue de l'interopérabilité.

   Certaines mises en œuvre existantes utilisent GeneralString pour coder des caractères spécifiques de la localisation sans échappement. C'est une violation de la norme ASN.1. La plupart de ces mises en œuvre codent l'US-ASCII dans la moitié gauche, aussi tant que la mise en œuvre ne transmet que de l'US-ASCII, la norme ASN.1 n'est pas violée à cet égard. Lorsque ces mises en œuvre codent les caractères sans échappement spécifiques de la localisation avec le bit de plus fort poids établi, cela viole la norme ASN.1

   D'autres mises en œuvre sont connues pour utiliser GeneralString avec un codage UTF-8. Cela aussi est une violation de la norme ASN.1, car UTF-8 est un codage différent, et pas un jeu "G" à 94 ou 96 caractères tel que défini par la norme ISO 2022. On pense que ces mises en œuvre n'utilisent même pas la séquence d'échappement de ISO 2022 pour changer le codage des caractères. Même si les mises en œuvre devaient annoncer le changement de codage en utilisant la séquence d'échappement, la norme ASN.1 interdit l'utilisation de toute séquence d'échappement autre que celles utilisées pour désigner/invoquer les ensembles "G" ou "C" permis par GeneralString.

   De futures révisions de ce protocole permettront presque certainement une représentation plus interopérable des noms de principaux, probablement en y incluant UTF8String. Noter qu'appliquer une nouvelle contrainte à un type qui n'en avait pas auparavant constitue la création d'un nouveau type ASN.1. Dans ce cas particulier, le changement n'aboutit pas à un changement de codage en DER.

Domaine et PrincipalName


Realm ::= KerberosString
PrincipalName ::= SEQUENCE {
    name-type [0] Int32,
    name-string [1] SEQUENCE OF KerberosString
}

   Les noms de domaine Kerberos sont codés comme KerberosStrings. Les domaines se doivent pas contenir de caractère avec le code 0 (US-ASCII NULL). La plupart des domaines vont normalement comporter plusieurs composants séparés par des points, dans le style des noms de domaine Internet, ou séparés par des "/", dans le style des noms X.500. Un PrincipalName est une séquences typée de composants comportant les sous champs suivants:

name-type Ce champ spécifie le type de nom qui suit. Ce champ devrait être traité comme conseil.
name-string Ce champ code une séquence de composants qui forment un nom, chaque composant étant codé comme un KerberosString. Pris ensemble, un PrincipalName et un domaine forment un identifiant de principal.

KerberosTime


KerberosTime ::= GeneralizedTime – sans fraction de seconde

   Les horodatages utilisés dans Kerberos sont codés comme GeneralizedTime. Une valeur KerberosTime ne doit pas inclure de portions fractionnée de seconde. Comme exigé par les DER, elle ne doit pas non plus inclure de séparateur, et elle doit spécifier la zone de temps UTC (Z). Exemple: le seul format valide pour l'heure UTC 6 minutes, 27 secondes aprés 21h le 6 novembre 1985 est 19851106210627Z.

Contraintes sur les types entiers

   Certains membres de type entier devraient être contraints à des valeur représentables en 32-bits, pour la compatibilité avec des limites raisonnables d'implémentation.


Int32 ::= INTEGER (-2147483648..2147483647)
    -- valeurs signées représentables en 32 bits
UInt32 ::= INTEGER (0..4294967295)
    -- valeurs de 32 bits non signées
Microseconds ::= INTEGER (0..999999)
    -- microsecondes

   Bien qu'il en résulte des changements des types abstraits de la version de la rfc1510, le codage DER ne devrait pas être altéré. Les anciennes implémentations étaient normalement limitées à des valeurs d'entier 32-bits, et les numéros alloués devraient entrer dans l'espace des valeurs entières représentables en 32-bits afin de promouvoir l'intéropérabilité. Plusieurs champs d'entiers dans les messages sont contraints à des valeurs fixes.

pvno comme TGT-VNO ou AUTHENTICATOR-VNO, ce champ récurant vaut toujours 5.
msg-type Ce champ est habituellement identique au tagNumber d'application du type de message qui le contient

HostAddress et HostAddresses


HostAddress ::= SEQUENCE {
    addr-type [0] Int32,
    address [1] OCTET STRING
}

   Note:HostAddress est toujours utilisé comme champ OPTIONAL et ne devrait pas être vide. Le codage d'adresse d'hôte comporte 2 champs:

addr-type Ce champ spécifie le type d'adresse suivant.
address Code une seule adresse du type addr-type.

AuthorizationData

AuthorizationData est toujours utilisé comme champ OPTIONAL et ne devrait pas être vide.
AuthorizationData
::= SEQUENCE OF SEQUENCE {
    ad-type [0] Int32,
    ad-data [1] OCTET STRING
}

ad-data Contient des données d'authorisation à interpréter conformément à la valeur du chanp ad-type correspondant
ad-type Spécifie le format du sous-champ ad-data.

   Chaque séquence de type et données est perçue comme un élément d'autorisation. Les éléments peuvent être spécifiques à l'application; cependant, il y a un jeu commun d'éléments récursifs qui devraient être compris par toutes les implémentations. Ces éléments contiennent d'autres éléments embarqués, et l'interprétation de l'élément encapsulé détermine lequel des éléments embarqués doit être interprétés, et ceux qui peuvent être ignorés.

   Ces éléments de données d'autorisation communs sont définis récursivement, signifiant que ad-data pour ces types va lui-même contenir une donnée de séquence d'autorisation. dont l'interprétation est affectée par l'élément encapsulant. En fonction de la signification de l'élément encapsulant, les éléments encapsulés peuvent être ignorés, pourraient être interprétés produit directement par le KDC, ou pourraient être stockés dans une partie plaintext séparé du ticket. Les types d'éléments encapsulant sont spécifiés comme partie de la spécification Kerberos parce que comportement fondé sur ces valeurs devrait être compris te toutes les implémentations, alors que d'autre éléments n'ont besoin d'être compris que par les applications qu'ils affectent.

   Les éléments de données d'autorisation sont considérés comme critiques s'ils sont présents dans un ticket ou un authentifiant. Si un type d'élément de données d'autorisation inconnu est reçu par un serveur dans un AP-REQ ou dans un ticket contenu dans un AP-REP, alors, sauf s'il est encapsulé dans un élément de données d'autorisation commun qui amende la criticité des éléments qu'il contient, l'authentification doit échouer. Les données d'autorisation sont destinées à restreindre l'utilisation d'un ticket. Si le service ne peut pas déterminer si la restriction s'applique à ce service, il peut en résulter une faiblesse de la sécurité de l'utilisation de ce ticket pour ce service. Les éléments d'autorisation qui sont facultatifs peuvent être inclus dans un élément AD-IF-RELEVANT.

Contenu des ad-data__________________ad-type
Codage DER de AD-IF-RELEVANT_________1
Codage DER de AD-KDCIssued___________4
Codage DER de AD-AND-OR______________5
Codage DER de AD-MANDATORY-FOR-KDC___8

IF-RELEVANT

   AD-IF-RELEVANT ::= AuthorizationData

  Les éléments encapsulés au sein de l'élément if-relevant sont destinés seulement à être interprétés par les serveurs d'application qui comprennent le ad-type particulier de l'élément incorporé. Les serveurs d'application qui ne comprennent pas le type d'un élément incorporé au sein de l'élément if-relevant peuvent ignorer l'élément non interprétable. Cet élément aide à l'interopérabilité des implémentations qui peuvent avoir des extensions locales pour l'autorisation.

  Le ad-type pour AD-IF-RELEVANT est (1)

KDCIssued


AD-KDCIssued ::= SEQUENCE {
    ad-checksum [0] Checksum,
    i-realm [1] Realm OPTIONAL,
    i-sname [2] PrincipalName OPTIONAL,
    elements [3] AuthorizationData
}

ad-checksum ckecksum cryptographique calculés sur le codage DER de AuthorizationData dans le champ "elements", keyed avec la clé de session. Son checksumtype est le type de checksum obligatoire pour le type de chiffrement de la clé de sessio, et sa valeur d'utilisation de clé est 19.
i-realm, i-sname Le nom du principal qui émet, s'il est différent de celui du KDC. Ce champ devrait être utilisé lorsque le KDC peut vérifier l'authenticité des éléments signés par le principal qui émet, et permet au KDC de notifier au serveur d'application la validité de ces éléments.
elements Séquence d'éléments de données d'autorisation produite par le KDC.

   Le champ ad-data produit par le KDC est destiné à fournir un moyen pour que les accréditifs de principal Kerberos incorporent en leur sein les attributs de privilège et autres mécanismes d'autorisation positive, amplifiant les privilèges du principal au-delà de ce qui peut être fait en utilisant des accréditifs sans un tel élément a-data.

   Les moyens ci-dessus ne peuvent être fournis sans cet élément à cause de la définition du champ authorization-data qui permet d'ajouter des éléments à volonté par le porteur d'un TGT au moment où il demande les tickets de service, et des éléments peuvent aussi être ajoutés à un ticket délégué par inclusion dans l'authentifiant.

   Pour les éléments produits par le KDC, ceci est empêché parce que les éléments sont signés par le KDC en incluant un checksum chiffrée en utilisant la clé du serveur (la même que celle utilisée pour chiffrer le ticket ou une clé dérivée de cette clé). Les éléments encapsulés avec l'élément produit par le KDC doivent être ignorés par le serveur d'application si cette signature n'est pas présente. De plus, les éléments encapsulés au sein de cet élément à partir d'un TGT peuvent être interprétés par le KDC, et utilisés comme base, conformément à la politique, pour inclure des éléments nouvellement signés au sein de tickets dérivés, mais ils ne seront par copiés directement sur un ticket dérivé. S'ils sont copiés directement sur un ticket dérivé par un KDC qui n'est pas au courant de cet élément, la signature ne sera pas correcte pour les éléments de ticket d'application, et le champ sera ignoré par le serveur d'application.

   Cet élément et les éléments qu'il encapsule peuvent être ignorés en toute sécurité par les applications, serveur d'application, et KDC qui n'implémentent pas cet élément.

AND-OR


AD-AND-OR ::= SEQUENCE {
    condition-count [0] Int32,
    elements [1] AuthorizationData
}

   Lorsque des éléments AD restrictifs sont encapsulés au sein de l'élément and-or, l'élément and-or est considéré comme satisfait si et seulement si au foins le nombre d'éléments encapsulés spécifié dans condition-count est satisfait. Donc, cet élément peut être utilisé pour mettre en œuvre une opération "ou" en réglant le champ condition-count à 1, et il peut spécifier une opération "et" en réglant le compte de condition au nombre d'éléments incorporés. Les serveurs d'application qui ne mettent pas en œuvre cet élément doivent rejeter les tickets qui contiennent des éléments de données d'autorisation de ce type. Le ad-type pour AD-AND-OR est (5)

MANDATORY-FOR-KDC

   AD-MANDATORY-FOR-KDC ::= AuthorizationData

  Les éléments AD encapsulés au sein de l'élément mandatory-for-kdc sont à interpréter par le KDC. Les KDC qui ne comprennent pas le type d'un élément incorporé au sein de l'élément mandatory-for-kdc doivent rejeter la demande. Le ad-type pour AD-MANDATORY-FOR-KDC est (8)

PA-DATA

   Historiquement, les PA-DATA étaient connues comme des données de pré-authentification, ce qui signifie qu'elles étaient utilisée pour augmenter l'authentification initiale auprès du KDC. Depuis cette époque, elles ont aussi été utilisées comme trou typé avec lequel on étend les échanges de protocoles avec le KDC.


PA-DATA ::= SEQUENCE {
    -- NOTE : la première étiquette est [1], et non [0]
    padata-type [1] Int32,
    padata-value [2] OCTET STRING -- peut être codée AP-REQ
}

padata-type Indique la façon d'interpréter l'élément padata-value. Les valeurs négatives de padata-type sont réservées pour des utilisations non-enregistrées; les valeurs non négatives sont utilisée pour une interprétation répertoriée du type d'élément.
padata-value Contient habituellement le codage DER d'un autre type; le champ padata-type identifie quel type est codé ici.


type de padata__Nom_______________Contenu de la valeur padata
1_______________pa-tgs-req________Codage en DER de AP-REQ
2_______________pa-enc-horodatage_Codage en DER de PA-ENC-TIMESTAMP
3_______________pa-pw-salt________sel (non codé en ASN.1)
11______________pa-etype-info_____Codage en DER de ETYPE-INFO
19______________pa-etype-info2____Codage en DER de ETYPE-INFO2

   Ce champ peut aussi contenir des informations nécessaires à certaines extensions au protocole Kerberos. Par exemple, il peut être utilisé pour vérifier l'identité d'un client avant qu'aucune réponse ne soit retournée.

   Le champ padata peut aussi contenir les informations nécessaires pour aider le KDC ou le client à choisir la clé nécessaire pour générer ou déchiffrer la réponse. Cette forme de padata est utile pour la prise en charge de l'utilisation de certaines cartes avec Kerberos.

PA-TGS-REQ

   Dans le cas de demandes de tickets supplémentaire KRB_TGS_REQ, padata-value contient une AP-REQ coddée. La somme de contrôle dans l'authentifiant ( qui doit être à l'épreuve des collisions ) est à calculer sur le codage de KDC-REQ-BODY.

Pré-authentification à timestamp chiffré

   Il y a des types de pré-authentification qui peuvent être utilisés pour pré-authentifier un client au moyen d'un timestamp chiffré.


PA-ENC-TIMESTAMP ::= EncryptedData -- PA-ENC-TS-ENC
    
PA-ENC-TS-ENC ::= SEQUENCE {
    patimestamp [0] KerberosTime -- client's time --,
    pausec [1] Microseconds OPTIONAL
}

   patimestamp contient l'heure du client, et pausec contient les microsecondes, qui peuvent être omises si un client ne va pas générer plus d'une demande par seconde. Le texte chiffré ( padata-value ) comporte le codage de PA-ENC-TS-ENC, chiffré en utilisant la clé secrète du client et une valeur d'utilisation de clé de 1.

PA-PW-SALT

   padata-value pour ce type de pré-authentification contient de salt pour le string-to-key à utiliser par le client pour obtenir la clé pour déchiffrer la partie chiffrée d'un message AS-REP. Malheureusement, pour des raisons historiques, l'ensemble de caractères à utiliser n'est pas spécifié et probablement spécifique à la localisation.

   Dans l'exemple trivial, une chaîne de salt de longueur 0 est très courant pour les domaines qui ont converti leur bases de données de principal depuis une version 4. Un KDC ne devrait par envoyer PA-PW-SALT lorsqu'il produit un message KRB-ERROR qui demande une pré-authentification supplémentaire. Note d'implémentation: Certaines implémentations de KDC produisent un PA-PW-SALT erroné lorsqu'elle envoient un message KRB-ERROR qui demande une pré-authentification supplémentaire. Donc, les clients devraient ignorer un PA-PW-SALT accompagnant un KDC-ERROR qui demande une pré-authentification supplémentaire. Un KDC ne doit pas envoyer PA-PW-SALT lorsque le AS-REQ du client comporte au moins un etype "newer".

PA-ETYPE-INFO

   Le type de pré-authentification ETYPE-INFO est envoyé par le KDC dans un KRB-ERROR indiquant l'exigence d'une pré-authentification supplémentaire. Il est habituellement utilisé pour notifier à un client quelle clé utiliser pour le chiffrement d'un timestamp chiffré pour les besoins de l'envoi d'une valeur PA-ENC-TIMESTAMP de pré-authentification. Il peut aussi être envoyé dans un AS-REP pour fournir des informations au client sur le salt de clé à utiliser pour le string-to-key que le client doit utiliser pour obtenir la clé de déchiffrement de la partie chiffrée du AS-REP.


ETYPE-INFO-ENTRY ::= SEQUENCE {
    etype [0] Int32,
    salt [1] OCTET STRING OPTIONAL
}
ETYPE-INFO ::= SEQUENCE OF ETYPE-INFO-ENTRY

   Le salt, comme celui de PA-PW-SALT, est aussi complètement non spécifié par rapport au jeu de caractères et est probablement spécifique à la localisation. Si ETYPE-INFO est envoyé dans un AS-REP, il doit être exactement un ETYPE-INFO-ENTRY, et son etype doit correspondre à celui du enc-part dans AS-REP. Un KDC ne doit pas envoyer PA-ETYPE-INFO lorsque le AS-REQ du client comporte un moins un etype "newer".

PA-ETYPE-INFO2

   Le type de pré-authentification ETYPE-INFO2 est envoyé par le KDC dans un KRB-ERROR indiquant l'exigence d'une pré-authentification supplémentaire. Il est habituellement utilisé pour notifier à un client quelle clé utiliser pour le chiffrement d'un timestamp chiffré pour les besoins de l'envoi d'une valeur PA-ENC-TIMESTAMP de pré-authentification. Il peut aussi être envoyé dans un AS-REP pour fournir des informations au client sur le salt de clé à utiliser pour le string-to-key que le client doit utiliser pour obtenir la clé de déchiffrement de la partie chiffrée du AS-REP


ETYPE-INFO2-ENTRY ::= SEQUENCE {
    etype [0] Int32,
    salt [1] KerberosString OPTIONAL,
    s2kparams [2] OCTET STRING OPTIONAL
}
ETYPE-INFO2 ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO2-ENTRY

   Le type de salt est un KerberosString, mais les installations existantes peuvent avoir des caractères spécifiques de la localisation mémorisés dans le chaînes de salt, et les développeurs peuvent choisir de les traiter. L'interprétation de s2kparams est spécifiée dans la description du cryptosystem associé au etype. Chaque cryptosystem a une interprétation par défaut de s2kparams qui restera si cet élément est omis dans le codage de ETYPE-INFO2-ENTRY.

   Si ETYPE-INFO2 est envoyé dans un AS-REP, il doit être exactement un ETYPE-INFO2-ENTRY, et son etype doit correspondre à celui du enc-part dans le AS-REP. L'ordre préféré des données de pré-authentification conseillé qui affecte le choix de clé du client est: ETYPE-INFO2, suivi par ETYPE-INFO, suivi par PW-SALT. Un KDC ne doit pas envoyer de ETYPE-INFO ou PW-SALT lorsque AS-REQ comporte au moins un etype "newer".

KerberosFlags



KerberosFlags ::= BIT STRING (SIZE (32..MAX))
    -- nombre minimum de bits qui doivent être envoyés, mais pas moins de 32

   Note de compatibilité: les paragraphes suivants décrivent un changement par rapport à la description de la rfc1510 des chaînes binaires qui résulteraient en une incompatibilité dans le cas d'une mise en œuvre strictement conforme au DER de l'ASN.1 et à la RFC1510.

   Les chaînes binaires ASN.1 ont plusieurs utilisations. L'utilisation la plus simple d'une chaîne est de contenir un vecteur de bits, sans signification particulière attachée aux bits individuels. Ce vecteur de bits n'est pas nécessairement un multiple de 8 bits de longueur. L'utilisation par Kerberos d'une chaîne binaire comme vecteur booléen compact dans lequel chaque élément a une signification distincte pose quelques problèmes. La notation naturelle pour un vecteur booléen compact est la notation ASN.1 "NamedBit", et les DER exigent que les codages d'une chaîne binaire qui utilise la notation "NamedBit" excluent tous bits à zéro en queue. Il est facile de négliger cette troncature, tout particulièrement dans les implémentations de langage C qui choisissent naturellement de mémoriser les vecteur booléens comme des entiers de 32bits.

   Par exemple, si la notation de KDCOptions devait inclure la notation "NamedBit", comme dans la rfc1510, et si la valeur KDCOptions à coder avait seulement le bit "transmissible" (bit numéro 1) mis, le codage DER doit n'inclure que 2 bits: le premier est à 0 et est réservé, et le bit de valeur 1 pour transmissible.

   La plupart des implémentations de Kerberos envoient inconditionnellement 32 bits sur le réseau lors du codage de chaînes binaires utilisée comme vecteurs booléens. Ce comportement viole la syntaxe ASN.1 utilisée pour les valeurs de flag dans la rfc1510, mais cela survient si fréquemment que la description du protocole en est modifiée pour s'en accommoder.

   Par conséquent, le présent document retire la notation "NamedBit" pour les bits individuels, les relèguant en commentaires. La contrainte de taille sur le type KerberosFlags exige qu'au moins 32 bits soient codés à tout moment, bien qu'une implémentation laxiste puisse choisir d'accepter moins de 32bits et de traiter les bits manquants comme mis à 0.

   Actuellement, aucune utilisation de KerberosFlags ne spécifie plus de 32bits de flags, bien que de futures révisions du présent document puissent le faire. Lorsque plus de 32 bits sont à transmettre dans une valeur de KerberosFlags, les futures révisions du présent document spécifieront spécifieront vraisemblablement que le plus petit nombre de bits nécessaires pour coder le bit de valeur un de plus haut rang devrait être envoyé. Ceci est assez similaire au codage en DER d'une chaîne binaire qui est déclarée avec la notation "NamedBit".

Type liés au cryptosystem

   De nombreux messages de protocole Kerberos contiennent un EncryptedData comme conteneur pour des données chiffrées de façon arbitraire, qui sont souvent le codage chiffré d'un autre type de données. Les champs au sein de EncryptedData assistent le receveur dans le choix d'une clé pour le déchiffrer


EncryptedData ::= SEQUENCE {
    etype [0] Int32 -- EncryptionType --,
    kvno [1] UInt32 OPTIONAL,
    cipher [2] OCTET STRING – texte chiffré
}

etype Ce champ spécifie l'algorithme de chiffrement utilisé pour chiffrer le texte
kvno Ce champ contient le numéro de version de clé utilisée pour chiffrer les données. n'est présent que dans les messages chiffrés avec des clés à longue durée.
cipher Contient le texte chiffré.

   Le type EncryptionKey est le moyen par lequel les clés cryptographiques utilisée pour le chiffrement sont transférées.


EncryptionKey ::= SEQUENCE {
    keytype [0] Int32 -- actually encryption type --,
    keyvalue [1] OCTET STRING
}

keytype Spécifie le type de chiffrement de la clé de chiffrement qui suit dans le champ keyvalue.
keyvalue Contient la clé elle-même, codée comme une chaîne d'octet.

   Les messages qui contiennent des données de texte en clair à authentifier le feront habituellement en utilisant un membre du type Checksum. La plupart des instances de Checksums utilisent un hachage chiffré, bien que des exceptions existent.


Checksum ::= SEQUENCE {
    cksumtype [0] Int32,
    checksum [1] OCTET STRING
}

cksumtype Indique l'algorithme utilisé pour générer la somme de contrôle qui l'accompagne
checksum Contient la somme de contrôle elle-même.

Tickets

   Ce paragraphe décrit les paramètres de format et de chiffrement pour les tickets et les authentifiants. Lorsqu'un ticket ou un authentifiant est inclus dans un message de protocole, il est traité comme un objet opaque. Un ticket est un enregistrement qui aide un client à s'authentifier auprès d'un service. Un ticket contient les informations suivantes:


Ticket ::= [APPLICATION 1] SEQUENCE {
    tkt-vno [0] INTEGER (5),
    realm____[1] Realm,
    sname____[2] PrincipalName,
    enc-part_[3] EncryptedData -- EncTicketPart
}
-- Partie chiffrée du ticket
EncTicketPart ::= [APPLICATION 3] SEQUENCE {
    flags______________[0] TicketFlags,
    key________________[1] EncryptionKey,
    crealm_____________[2] Realm,
    cname______________[3] PrincipalName,
    transited__________[4] TransitedEncoding,
    authtime___________[5] KerberosTime,
    starttime__________[6] KerberosTime OPTIONAL,
    endtime____________[7] KerberosTime,
    renew-till_________[8] KerberosTime OPTIONAL,
    caddr______________[9] HostAddresses OPTIONAL,
    authorization-data_[10] AuthorizationData OPTIONAL
}
-- champs traversés codés
TransitedEncoding ::= SEQUENCE {
tr-type__[0] Int32 -- doit être enregistré --,
contents_[1] OCTET STRING
}
TicketFlags ::= KerberosFlags
    -- reserved(0),
    -- forwardable(1),
    -- forwarded(2),
    -- proxiable(3),
    -- proxy(4),
    -- may-postdate(5),
    -- postdated(6),
    -- invalid(7),
    -- renewable(8),
    -- initial(9),
    -- pre-authent(10),
    -- hw-authent(11),
-- les flags suivants sont nouveaux depuis la RFC 1510
    -- transited-policy-checked(12),
    -- ok-as-delegate(13)

tkt-vno Spécifie le numéro de version pour le format de ticket. Ce document décrit la version 5
realm Spécifie le domaine qui a produit un ticket. Sert à identifier la partie de domaine de l'identifiant de principal du serveur. Comme un serveur Kerberos ne peut produire de tickets que pour des serveurs au sein de son domaine, les deux seront toujours identiques.
sname Spécifie tous les composants de la partie nom de l'identité du serveur, incluant les parties qui identifient une instance spécifique d'un service.
enc-part Contient le codage chiffré de la séquence EncTicketPart. Il est chiffré avec la clé partagée par Kerberos et le serveur d'extrémité (la clé secrète du serveur), en utilisant une clé de valeur d'utilisation de 2.
flags Indique lesquelles des diverses options ont été utilisées ou demandées lorsque le ticket a été produit. La signification des flags est la suivante:

        0 (Réserved)
        1 (forwardable) Le flag FORWARDABLE n'est normalement interprété que par le TGS, et peut être ignoré par les serveurs d'extrémité. Lorsqu'il est mis, ce flag dit au TGS qu'il est ok pour produire un nouveau TGT avec une adresse réseau différente fondée sur le ticket présenté.
        2 (forwarded) Lorsque mis, ce flag indique que le ticket a été transmis ou a été produit sur la base d'une authentification impliquant un TGT transmis.
        3 (proxiable) Normalement interprété que par le TGS et est identique que FORWARDABLE, excepté qu'il dit au TGS que seuls des non-TGT peuvent être produits avec des adresses réseau différentes.
        4 (proxy) Indique que ce ticket a été mandaté
        5 (may-postdate) Normalement interprété que par le TGS et indique qu'un ticket post-daté peut être produit sur la base de ce TGT.
        6 (postdated) Indique que ce ticket est post-daté
        7 (invalid) Indique que ce ticket est invalide, et qu'il doit être validé par le KDC avant utilisation.
        8 (renewable) Normalement interprété que par le TGS et peut être utilisé pour obtenir un ticket de remplacement qui expire à une date ultérieur.
        9 (initial) Indique que ce ticket a été produit en utilisant le protocole d'AS, et non pas produit sur la base d'un TGT.
        10 (pre-authent) Indique que durant l'authentification initiale, le client a été authentifié par le KDC avant la production d'un ticket.
        11 (hw-authent) Indique que le protocole utilisé pour l'authentification initiale exige l'utilisation d'un matériel.
        12 (transited-policy-checked) Indique que le KDC pour le domaine a vérifié le champ de transit par rapport à une politique définie par le domaine en matière de certificateurs de confiance. Si ce flag est à 0, le serveur d'application doit alors vérifier le champ de transit lui-même, et s'il est incapable de le faire, il doit rejeter l'authentification. Si le flag est à 1, le serveur d'application peut alors s'affranchir de la vérification.
        13 (ok-as-delegate) Indique que le serveur ( et non le client ) spécifié dans le ticket a été déterminé par la politique du domaine comme étant un receveur de délégation convenable. Un client peut utiliser la présence de ce flag pour l'aider à décider de déléguer des accréditifs à ce serveur.
        14-31 (reserved) Réservé

key Ce champ existe dans le ticket et la réponse du KDC et il est utilisé pour passer la clé de session Kerberos au serveur d'application et au client.
crealm Ce champ contient le nom du domaine dans lequel le client est enregistré et dans lequel l'authentification initiale a eu lieu.
cname Ce champ contient la partie nom de l'identifiant de principal du client.
transited Ce champ donne la liste des noms des domaines Kerberos qui ont pris part à l'authentification de l'utilisateur à qui ce ticket a été produit. Il ne spécifie par l'ordre dans lequel les domaines ont été traversés. Quand les noms des CA sont à incorporer dans le champ de transit ( comme spécifié pour certaines extensions au protocole ), les noms X.500 des CA devraient être transposé en éléments dans ce champ en utilisant la transposition définis dans la rfc2253.
authtime Ce champ indique l'heure de l'authentification initiale du principal désigné. C'est l'heure de production du ticket original sur lequel est fondé ce ticket.
starttime Ce champ dans le ticket spécifie l'heure après laquelle le ticket sera valide. Avec le champ endtime, ce champ spécifié la durée de vie du ticket. S'il est absent, le champ authtime devrait alors être utilisé à la place pour déterminer la durée de vie du ticket.
endtime Ce champ contient l'heure après laquelle le ticket ne sera plus honoré.
renew-till Ce champ n'est présent que dans les ticket qui on le flag RENEWABLE mis. Indique l'heure de fin maximum qui peut être incluse dans un renouvellement. Il peut aussi être vu comme l'heure d'expiration absolue pour le ticket, y compris pour les renouvellements.
caddr Ce champ dans un ticket contient zéro (s'il est omis) ou plusieurs adresses d'hôte. Ce sont les adresses à partir desquelles le ticket peut être utilisé. S'il n'y a pas d'adresse, le ticket peut être utilisé à partir de toute localisation. La décision du KDC de produire, ou par le serveur d'extrémité d'accepter des tickets sans adresse est une décision de politique qui est laissée à Kerberos et aux administrateurs de service d'extrémité; ils peuvent refuser de produire ou d'accepter de tels tickets. À cause du large développement de la traduction des adresses réseau, il est recommandé que les politiques permettent la production et l'acceptation de tels tickets.

   Les adresse réseau sont incluses dans le ticket pour rendre plus difficile à un agresseur d'utiliser des accréditifs volés. Comme la clé de session n'est pas envoyée sur le réseau en clair, les accréditifs ne peuvent pas être volés simplement en écoutant le réseau; un agresseur doit gagner l'accès à une clé de session ( peut-être à travers des failles de la sécurité du système d'exploitation ou une session non surveillée d'un utilisateur négligeant) pour utiliser des tickets volés.

   Noter que l'adresse réseau à partir de laquelle une connexion est reçue ne peut pas être déterminée de façon fiable. Même si elle pouvant l'être, un agresseur qui a compromis la workstation du client pourrait utiliser les accréditifs à partir de là Inclure les adresses réseau ne fait que rendre plus difficile, mais pas impossible, à un agresseur de sortir avec des accréditifs volés et de les utiliser ensuite à partir d'un localisation sûre.

authorization-data Ce champ est utilisé pour passer les données d'autorisation du principal au nom duquel un ticket a été produit au service d'application. Si aucune données d'autorisation n'est incluse, ce champ sera laissé de côté. L'expérience nous montre que le nom de ce champ prête à confusion, et un meilleur nom serait "restrictions".

   Ce champ contient des restrictions à toute autorité obtenue sur la base d'une authentification utilisant le ticket. Il est possible à tout principal en possession d'accréditifs d'ajouter des entrées au champ de données d'autorisation car ces entrées prolongent les restrictions qui peuvent être faites avec le ticket. De telles additions peuvent être faites en spécifiant les entrées supplémentaires lorsqu'un nouveau ticket est obtenu durant l'échange TGS, ou elle peuvent être ajoutées durant une délégation chaînée utilisant le champ de données d'autorisation de l'authentifiant.

   Les données dans ce champ peuvent être spécifiques du service d'extrémité; le champ contiendra les noms des objets spécifiques du service, et les droits de ces objets. Bien que Kerberos ne soit pas concerné par le format du contenu des sous-champs, il en porte les information de type (ad-type).

   En utilisant le champ authorization-data, un principal est capable de produire un mandat valide pour un objet spécifique. Par exemple, un client souhaitant imprimer un fichier peut obtenir qu'un mandat de serveur de fichiers soit passé au serveur d'impression. En spécifiant le nom du fichier dans le champ authorization-data, le serveur de fichiers sait que le serveur d'impression peut seulement utiliser les droits du client lorsqu.il accède au fichier particulier à imprimer.

   On peut construire un service séparé qui fournit l'autorisation ou la certification d'appartenance à un groupe en utilisant le champ authorization-data. Dans ce cas, l'entité qui accorde l'autorisation (et non l'entité autorisée) peut obtenir un ticket en son nom propre (par exemple, le ticket est produit au nom d'un serveur privilégié), et cette entité ajoute des restrictions à sa propre autorité et délègue au client l'autorité restreinte à travers un mandataire. Le client présenterait alors cet accréditif d'autorisation au serveur d'application séparément de l'échange d'authentification. Autrement, de tels accréditifs d'autorisation peuvent être incorporés dans le ticket qui authentifie l'entité autorisée, lorsque l'autorisation est authentifiée séparément en utilisant l'élément de données d'autorisation produit par le KDC.

   De même, si on spécifie le champ authorization-data d'un mandataire et qu'on laisse en blanc les adresses d'hôte, le ticket et la clé de session qui résultent peuvent être traités comme une capacité. Le champ authorization-data est facultatif et n'a pas à être inclus dans un ticket.

Spécification pour les échanges AS et TGS

   Ce paragraphe spécifie le format des messages utilisés dans l'échange entre le client et le serveur Kerberos.

Définition de KRB_KDC REQ

   Le message KRB_KDC_REQ n'a pas de numéro d'étiquette d'application par lui-même. Il est incorporé dans KRB_AS_REQ ou KRB_TGS_REQ, qui ont chacune une étiquette d'application, selon que la demande est celle d'un ticket initial ou d'un ticket supplémentaire. Dans les 2 cas, le message est envoyé du client au KDC pour demander des accréditifs pour un service.

Les champs de message sont les suivants:
AS-REQ ::= [APPLICATION 10] KDC-REQ
TGS-REQ := [APPLICATION 12] KDC-REQ
    
KDC-REQ ::= SEQUENCE { -- NOTE: la première étiquette est [1], pas [0]
    pvno    [1] INTEGER (5) ,
    msg-type    [2] INTEGER (10 -- AS -- | 12 -- TGS --),
    padata    [3] SEQUENCE OF PA-DATA OPTIONAL -- NOTE : non vide --,
    req-body    [4] KDC-REQ-BODY
}
    
KDC-REQ-BODY ::= SEQUENCE {
    kdc-options    [0] KDCOptions,
    cname    [1] PrincipalName OPTIONAL -- Ne sert que dans AS-REQ --,
    realm    [2] Realm -- Domaine du serveur et aussi du client dans AS-REQ --,
    sname    [3] PrincipalName OPTIONAL, from [4] KerberosTime OPTIONAL,
    till    [5] KerberosTime,
    rtime    [6] KerberosTime OPTIONAL,
    nonce    [7] UInt32,
    etype    [8] SEQUENCE OF Int32 -- Type de chiffrement dans l'ordre de préférence --,
    addresses    [9] HostAddresses OPTIONAL,
    enc-authorization-data    [10] EncryptedData OPTIONAL -- AuthorizationData --,
    additional-tickets    [11] SEQUENCE OF Ticket OPTIONAL -- NOTE : non vide
}
    
KDCOptions ::= KerberosFlags
        -- reserved(0),
        -- forwardable(1),
        -- forwarded(2),
        -- proxiable(3),
        -- proxy(4),
        -- allow-postdate(5),
        -- postdated(6),
        -- unused7(7),
        -- renewable(8),
        -- unused9(9),
        -- unused10(10),
        -- opt-hardware-auth(11),
        -- unused12(12),
        -- unused13(13),
        -- 15 est réservé pour la canonisation
        -- unused15(15),
        -- 26 n'était pas utilisé dans la rfc 1510
        -- disable-transited-check(26),--
        -- renewable-ok(27),
        -- enc-tkt-in-skey(28),
        -- renew(30),
        -- validate(31)

pvno Inclus dans chaque message de protocole, et spécifie le numéro du protocole. Doit être à 5
msg-type Indique le type d'un message. Il sera presque toujours le même que l'identifiant d'application associé à un message. Il est inclus pour rendre l'identifiant plus facilement accessible à l'application. Pour le message KDC-REQ, ce type sera KRB_AS_REQ ou KRB_TGS_REQ.
padata Contient les données de pré-authentification. Les demandes de tickets supplémentaires ( KRB_TGS_REQ ) doivent contenir un padata de PA-TGS-REQ. Ce champ contient une séquence d'informations d'authentification qui peuvent être nécessaire avant que les accréditifs puissent être produits ou déchiffrés.
req-body Paramètre fictif qui délimite l'extension des champs restants. Si une somme de contrôle est à calculer dur la demande, elle est calculée sur un codage de la séquence KDC-REQ-BODY qui est dans le champ req-body.
kdc-options Ce champ apparaît dans les demandes KRB_AS_REQ et KRB_TGS_REQ et indique les flags que le client veut mettre sur les tickets ainsi que les autres informations qui vont modifier le comportement du KDC. Lorsque c'est approprié, le nom d'une option peut être le même que celui du flag qui est mis par cette option. Bien que dans la plupart des cas le bit dans le champ options soit le même que celui du champ flags, cela n'est pas garanti, aussi il n'est pas acceptable de simplement copier le champ options dans le champ flags. Diverses vérifications doivent être faites avant qu'une option ne soit honorée.

   Le cahmp kdc_options est un champ binaire, où les options choisies sont indiquées par le bit mis, et les option non choisies et les champs réservés ne sont pas mis. La signification des options est la suivante:

        0 (Réserved)
        1 (FORWARDABLE) Indique que le tickest est fournis avec le flag forwardable mis. Ne peut seulement être mis dans la demande initiale, ou dans une sous-demande si le TGT sur lequel il est basé est également forwardable.
        2 (FORWARDED) Seulement spécifié dans une demande au TGS et sera honoré si le TGT dans la demande a le bit FORWARDABLE mis.
        3 (PROXIABLE) Indique que le tickest est fournis avec le flag proxiable mis. Ne peut seulement être mis dans la demande initiale, ou dans une sous-demande si le TGT sur lequel il est basé est également proxiable.
        4 (PROXY) Indique que c'est une demande pour un proxy et sera honoré si le TGT dans la demande a le bit PROXIABLE mis.
        5 (ALLOW-POSTDATE) Indique que le ticket à fournir doit avoir MAY-POSTDATE mis. Ne peut seulement être mis dans la demande initiale, ou dans une sous-demande si le TGT sur lequel il est basé est également MAY-POSTDATE.
        6 (POSTDATED) Indique que c'est une demande pour un ticket post-daté. Sera honoré si le TGT sur lequel il est basé a son MAY-POSTDATE mis. Le ticket résultant aura également le flag INVALID mis.
        7 (RESERVED)
        8 (RENEWABLE) Indique que le ticket à fournir doit avoir son flag RENEWABLE mis. Peut seulement être mis dans la demande initiale, ou dans une sous-demande si le TGT sur lequel il est basé est également renewable
        9 (RESERVED)
        10 (RESERVED)
        11 (RESERVED)
        12-25 (RESERVED)
        26 (DISABLE-TRANSITED-CHECK) Indique au KDC de ne pas vérifier le champ transited
        27 (RENEWABLE-OK) Indique qu'un ticket renouvelable sera acceptable si un ticket avec la durée de vie requise ne peut autrement être fourni, auquel cas un ticket renouvelable peut être produit avec un renew-till égal à l'heure de fin demandée.
        28 (ENC-TKT-IN-SKEY) N'est utilisée que par le TGS. indique que le ticket pour le serveur d'extrémité est à chiffrer avec la clé de session provenant du TGT supplémentaire fourni.
        29 (RESERVED)
        30 (RENEW) N'est utilisé que par le TGS. Indique que la demande est pour un renouvellement. Le ticket fournis est chiffré dans la clé secrète pour le serveur sur lequel il est valide. Ne sera honoré que si le ticket à renouveler a son flag RENEWABLE mis et si renew-till n'est pas passé.
        31 (VALIDATE) N'est utilisé que par le TGS. Indique que la demande est pour un ticket post-daté à valider.

cname et sname Ces champs sont les mêmes que ceux décrits pour le ticket plus haut. Le sname ne peut être absent que lorsque l'option ENC-TGT-IN-SKEY est spécifié. Si le sname est absent, le nom du serveur est tiré du nom du client dans le ticket passé comme ticket supplémentaire.
enc-authorization-data Si présent (et ne peut l'être que sous la forme de TGS_REQ), est un codage des authorizations désirées chiffré avec la sous-clé de session si elle est présent dans l'authentifiant, ou avec la clé de session dans le TGT (l'authentifiant et le TGT viennent tous deux du champ padata dans le KRB_TGS_REQ). La valeur d'utilisation de clé utilisée pour le chiffrement est 5 si une sous-clé de session est utilisée, ou 4 si la clé de session est utilisée.
realm Spécifie la partie domaine de l'identifiant de principal du serveur. Dans l'échange AS, c'est aussi la partie domaine de l'identifiant de principal du client.
from Ce champ est inclus dans les demandes de ticket KRB_AS_REQ et KRB_TGS_REQ lorsque le ticket demandé est à post-dater. Il spécifie l'heure de début de validité pour le ticket demandé. Si omis, le KDC devrait uiliser l'heure en cours.
till Contient la date d'expiration demandée par le client dans une demande de ticket. Il n'est pas facultatif, mais si l'heure de fin demandée est "19700101000000Z", le ticket aura l'heure maximum permise par le KDC.
rtime Ce champ est l'heure de renew-till envoyée au KDC dans une demande de ticket. facultatif.
nonce Fait partie de la demande et de la réponse du KDC. Il est destiné à contenir un nombre aléatoire généré par le client. Si le même nombre est inclus dans la réponse chiffrée provenant du KDC, cela montre à l'évidence que la réponse est fraîche et n'a pas été répétée par un attaquant. Les noms occasionnels ne doivent jamais être réutilisés.
etype Ce champ spécfie l'algorithme de chiffrement désiré à utiliser dans la réponse.
addresses Ce champ est inclus dans la demande de ticket, et il est facultativement inclus dans les demandes de tickets supplémentaire provenant du serveur d'allocation de tickets. Il spécifie les adresse à partir desquelles le ticket demandé doit être valide. Normalement, il inclut les adresse de l'hôte du client. Si un proxy est demandé, ce champ contiendra d'autres adresse. Ce champ est généralement copié par le KDC dans le champ cappr du ticket résultant.
additional-tickets Des tickets supplémentaire peuvent être facultativement inclus dans une demande au TGS. Si l'option ENC-TGT-IN-SKEY a été spécifiée, la clé de session provenant du ticket supplémentaire sera alors utilisée à la place de la clé du serveur pour chiffrer le nouveau ticket. Lorsque l'option ENC-TKT-IN SKEY est utilisée pour l'authentification d'utilisateur à utilisateur, ce ticket supplémentaire peut être un TGT produit par le domaine local ou un TGT inter-domaine produit pour le domaine du KDC en cours par un KDC distant. Si plus d'une option exigeant des tickets supplémentaire a été spécifiée, les tickets supplémentaire sont alors utilisés dans l'ordre spécifié par l'ordre des bits des options bits.

Définition de KRB_KDC_REP

   Le format de message KRB KDC_REP est utilisé pour la réponse du KDC à une demande initiale ( AS ) ou à une demande ultérieure ( TGS ). Il n'y a pas de type de message pour KRB_KDC_REP. Le type sera KRB_AS_REP ou KRB_TGS_REP. La clé utilisée pour chiffrer la partie de texte chifrée de la réponse dépend du type de message. Pour KRB_AS_REP, le texte est chiffré avec la clé secrète du client, et le numéro de version de clé du client est inclus dans le numéro de version de clé pour les données chiffrées. Pour KRB_TGS_REP, et texte est chiffré avec la clé de session provenant du TGT utilisé dans la demande. Dans ce cas, aucun numéro de version ne sera présent dans la séquence EncryptedData.

Les champs de message sont les suivants:
AS-REP ::= [APPLICATION 11] KDC-REP
TGS-REP ::= [APPLICATION 13] KDC-REP
KDC-REP ::= SEQUENCE {
    pvno    [0] INTEGER (5),
    msg-type    [1] INTEGER (11 -- AS -- | 13 -- TGS --),
    padata    [2] SEQUENCE OF PA-DATA OPTIONAL -- NOTE : non vide --,
    crealm    [3] Realm,
    cname    [4] PrincipalName,
    ticket    [5] Ticket,
    enc-part    [6] EncryptedData -- EncASRepPart ou EncTGSRepPart, selon le cas
}
EncASRepPart ::= [APPLICATION 25] EncKDCRepPart
EncTGSRepPar ::= [APPLICATION 26] EncKDCRepPart
EncKDCRepPart ::= SEQUENCE {
    key    [0] EncryptionKey,
    last-req    [1] LastReq,
    nonce    [2] UInt32,
    key-expiration    [3] KerberosTime OPTIONAL,
    flags    [4] TicketFlags,
    authtime    [5] KerberosTime,
    starttime    [6] KerberosTime OPTIONAL,
    endtime    [7] KerberosTime,
    renew-till    [8] KerberosTime OPTIONAL,
    srealm    [9] Realm,
    sname    [10] PrincipalName,
    caddr    [11] HostAddresses OPTIONAL
}
LastReq ::= SEQUENCE OF SEQUENCE {
    lr-type    [0] Int32,
    lr-value    [1] KerberosTime
}

pvno et msg-type Décrits dans KRB_KDC_REQ. msg-type est KRB_AS_REP ou KRB_TGS_REP
padata Décrits dans KRB_KDC_REQ. Une utilisation possible est de coder une chaîne salt à utiliser avec un algorithme de string-to-key. C'est utile pour faciliter les transitions si un nom de domaine doit changer; dans un tel cas, toutes les entrées déduites de mot de passe existantes dans la base de données Kerberos auraient un flag marquant qu'elles ont besoin d'une chaîne salt spécial jusqu'au prochain changement de mot de passe.
crealm, cname, srealm, et sname Décrits dans KRB_KDC_REQ.
ticket C'est le ticket nouvellement produit
enc-part Ce champ est un fourre-tout pour le texte chiffré et les informations qui s'y rapportent, qui forme la partie chiffrée d'un message. La description de la partie chiffrée du message suit chaque apparition de ce champ.

   La valeur d'utilisation de clé pour le chiffrement de ce champ est 3 dans un message AS-REP, en utilisant la clé à long-terme du client ou une autre clé choisie via des mécanismes de pré-authentification. Dans un message TGS-REP, la valeur d'utilisation de clé est 8 si la clé de session TGS est utilisée, ou 9 si une sous-clé d'authentifiant TGS est utilisée.

key Ce champ est le même que celui décrit au paragraphe ticket
last-req Ce champ est retourné par le KDC et spécifie l'heure de la dernière demande d'un principal. Selon les informations disponibles, ce peut être la dernière fois qu'une demande de TGT a été faite, ou la dernière fois qu'une demande fondée sur un TGT a réussi. I peut aussi couvrir tous les serveurs d'un domaine, ou juste un serveur particulier. Certaines implémentations peuvent afficher ces informations à l'utilisateur pour aider à découvrir des utilisations non autorisées d'une identité. C'est d'un esprit similaire à l'affichage de la dernière connexion affichée à la connexion dans les systèmes en tamps partagé.
lr-typeCe champ indique comment interpréter le champ lr-value suivant. Les valeurs négatives indiquent que ces informations n'appartiennent qu'au serveur qui répond. Les valeurs non négatives appartiennent à tous les serveurs pour le domaine. Les valeurs possibles sont:

        0 Aucune information n'est portée par le sous-champ lr-value.
        1 le sous-champ lr-value est l'heure de la dernière demande initiale pour un TGT.
        2 Le sous-champ lr-value est l'heure de la dernière demande initiale.
        3 Le sous-champ lr-value est l'heure de la production du plus récent TGT utilisé
        4 Le sous-champ lr-value est l'heure de la demande du dernier renouvellement
        5 Le sous champ lr-value est l'heure de la dernière demande (de tout type).
        6 Le sous-champ lr-value est l'heure de l'arrivée à expiration du mot de passe.
        7 Le sous-champ lr-value est l'heure de l'arrivée à expiration du compte.

lr-value Ce champ contient l'heure de la dernière demande. L'heure doit être interprété conformément au contenu du sous-champ lr-type qui l'accompagne.
nonce Décrits dans KRB_KDC_REQ.
key-expiration Ce champ fait partie de la réponse du KDC et spécifie l'heure à laquelle la clé secrète du client va arriver à expiration. L'expiration peut être le résultat du vieillissement d'un mot de passe ou de l'expiration d'un compte. S'il est présent, il devrait être réglé au plus tôt de l'expiration de la clé de l'utilisateur et de l'expiration du compte. L'utilisation de ce champ est déconseillé, et le champ last-req devrait être utilisé à la place pour porter ces informations. Ce champ sera normalement laissé en dehors de la réponse TGS car la réponse à une demande de TGS est chiffrée avec une clé de session et aucune information client n'a à être restituée de la base de données du KDC. Il appartient au client d'application ( généralement le programme de connexion) de prendre les mesures appropriées si l'heure d'expiration est imminente.
flags, authtime, starttime, endtime, renew-till et caddr Ces champs sont des duplications de ceux qui figurent dans la portion chiffré du ticket joint, et ils sont fournis pour que le client puisse vérifier qu'ils correspondent à la demande prévue et afin d'aider à une mise en mémoire cache appropriée du ticket. Si le message est du type KRB_TGS_REP, le champ caddr ne sera rempli que si la demande était pour un proxy ou un ticket transmis, ou si l'utilisateur substitue un sous-ensemble des adresses venant du TGT. Si les adresses demandées par le client ne sont pas présentes ou pas utilisées, les adresses contenues dans le ticket devront alors être les mêmes que celles incluses dans le TGT.

Spécifications de message client-serveur

   Ce paragraphe spécifie le format des messages utilisée pour l'authentification du client auprès du serveur d'application.

Définition de KRB_AP_REQ

   Le message KRB_AP_REQ contient le numéro de version du protocole Kerberos, le type de message KRB_AP_REQ, un champ d'options pour indiquer toutes les options utilisée, et le ticket et l'authentifiant eux-mêmes. Le message KRB_AP_REQ est souvent désigné comme un en-tête d'authentification.


AP-REQ ::= [APPLICATION 14] SEQUENCE {
    pvno    [0] INTEGER (5),
    msg-type    [1] INTEGER (14),
    ap-options    [2] APOptions,
    ticket    [3] Ticket,
    authenticator    [4] EncryptedData -- Authentifiant
}
APOptions ::= KerberosFlags
    -- reserved(0),
    -- use-session-key(1),
    -- mutual-required(2)

pvno et msg-type Décrits dans KRB_KDC_REQ. msg-type estKRB_AP_REQ
ap-options Ce champ apparaît dans la demande d'application KRB_AP_REQ et affecte la façon dont la demande est traitée. C'est un champ binaire, où les options choisies sont indiquées par le bis mis, et les options non choisies à 0. La signification des options est la suivante:

        (reserved) 1
        (use-session-key) Indique que le ticket que présente le client à un serveur est chiffré avec la clé de session venant du TGT du serveur. Quand cette option n'est pas spécifiée, le ticket est chiffré avec la clé secrète du serveur. 2
        (mutual-required) Dit au serveur que le serveur exige l'authentification mutuele, et qu'il doit répondre par un message KRB_AP_REP. 3-31
        (reserved)

ticket Ce champ est un ticket authentifiant le client auprès du serveur
authenticator Contient l'authentifiant chiffré, qui inclut le choix d'une sous-clé par le client.

   L'authentifiant chiffré est inclus dans le AP-REQ; il certifie à un serveur que l'envoyeur a une connaissance récente de la clé de chiffrement du ticket d'accompagnement, pour aider le serveur à détecter les répétitions. Il aide aussi au choix d'une vraie clé de session à utiliser dans cette session. Le codage DER de ce qui suit est chiffré avec la clé de session du ticket, avec une valeur d'utilisation de clé de 11 dans les échanges d'application normaux, ou 7 lorsque utilisée comme champ PA-TGS-REQ PA-DATA d'un échange TGS-REQ.


-- Authentifiant non chiffré
Authenticator ::= [APPLICATION 2] SEQUENCE {
    authenticator-vno    [0] INTEGER (5),
    crealm    [1] Realm,
    cname    [2] PrincipalName,
    cksum    [3] Checksum OPTIONAL,
    cusec    [4] Microseconds,
    ctime    [5] KerberosTime,
    subkey    [6] EncryptionKey OPTIONAL,
    seq-number    [7] UInt32 OPTIONAL,
    authorization-data    [8] AuthorizationData OPTIONAL
}

authenticator-vno Spécifie le numéro de version du format de l'authentifiant. Vaut 5
crealm et cname Décrit dans le paragraphe ticket
cksum Contient un checksum des données d'application qui accompagnent le KRB_AP_REQ. calculée en utilisant une valeur d'utilisation de clé de 10 dans les échanges d'application normaux, ou 6 lorsqu'utilisé dans le champ TGS-REQ PA-TGS-REQ AP-DATA
cusec Ce champ contient la partie microsecondes du timestamp du client. sa valeur va de 0 à 999999.
ctime Ce champ contient l'heure en cours sur l'hôte du client
subkey Ce champ contient le choix du client d'une clé de chiffrement à utiliser pour protéger cette session d'application spécifique. Sauf si une application spécifie autre chose, si ce champ est laissé de côté, la clé de session venant du ticket sera utilisée.
seq-number Ce champ optionnel comporte le numéro de séquence initial à utiliser par KRB_PRIV ou KRB_SAFE lorsque les numéros de séquence sont utilisés pour détecter les répétitions.

   Il peut aussi être utilisé par des messages spécifiques de l'application. Lorsqu'il est inclus dans l'authentifiant, ce champ spécifie le numéro de séquence initiale pour les messages du client au serveur. Lorsqu'il est inclus dans le message KRB_PRIV ou KRB_SAFE, il est incrémenté de un après l'envoi de chaque message. Les numéros de séquence sont dans la gamme de 0 à 2^32 -1 puis reviennent à 0.

   Pour que les numéros de séquence prennent adéquatement en charge la détection des répétitions, ils devraient être non-répétitifs, même à travers les frontières de connexion. Le numéro de séquence initiale devrait être aléatoire et uniformément distribué à travers l'espace complet des numéros de séquence possibles, de sorte qu'il ne puisse pas être deviné par un agresseur et de sorte que lui et les numéros de séquence successifs ne répètent pas d'autres séquences. Au cas où plus de 2^32 messages devraient être générés dans une série de message KRB_PRIV ou KRB_SAFE, un changement de clé devrait être effectué avant que les numéros de séquence soient réutilisés avec la même clé de chiffrement.

authorization-data Ce champ est décrit au paragraphe ticket. il est optionnel et n'apparaît que lorsque des restrictions supplémentaires sont à mettre à l'utilisation d'un ticket, au-delà de celles portées par le ticket lui-même.

Définition de KRB_AP_REP

   Le message KRB_AP_REP contient le numéro de version du protocole Kerberos, le type de message, en un timestamp chiffré. Le message est envoyé en réponse à une demande d'application ( KRB_AP_REQ ) pour laquelle l'option d'authentification mutuelle a été choisie dans le champ ap-options.


AP-REP ::= [APPLICATION 15] SEQUENCE {
    vno     [0] INTEGER (5),
    sg-type    [1] INTEGER (15),
    nc-part    [2] EncryptedData -- EncAPRepPart
}
EncAPRepPart ::= [APPLICATION 27] SEQUENCE {
    time    [0] KerberosTime,
    usec    [1] Microseconds,
    ubkey    [2] EncryptionKey OPTIONAL,
    eq-number    [3] UInt32 OPTIONAL
}

nc-part La partie codée EncAPRepPart est chiffrée avec la clé de session partagée du ticket. Le champ de sous-clé facultatif peut être utilisé dans une négociation arrangée par l'application pour choisir une clé de session par association.
pvno et msg-type Décrits dans KRB_KDC_REQ. msg-type estKRB_AP_REP
enc-part Décrits dans KRB_KDC_REQ. Est calculé avec une valeur d'utilisation de clé de 12
ctime Heure courant sur l'hôte du client
cusec partie micro-seconde du timestamp
subkey Contient une clé de chiffrement à utiliser pour protéger cette session d'application spécifique.
seq-number Décrit au paragraphe ticket

Spécification du message KRB_SAFE

   Ce paragraphe spécifie le format d'un message qui peut être utilisé par l'un ou l'autre côté ( client ou serveur ) d'une application pour envoyer un message inaltérable à son homologue. Il suppose qu'une clé de session ait été échangée précédemment. Le message KRB_SAFE contient des données d'utilisateur avec une somme de contrôle à l'épreuve des collisions chiffrée avec la dernière clé de chiffrement négociée via des sous-clés, ou avec la clé de session si aucune négociation n'est intervenue.

Les champs de message sont les suivants:
KRB-SAFE ::= [APPLICATION 20] SEQUENCE {
    pvno    [0] INTEGER (5),
    msg-type    [1] INTEGER (20),
    safe-body    [2] KRB-SAFE-BODY,
    cksum    [3] Checksum
}
KRB-SAFE-BODY ::= SEQUENCE {
    user-data    [0] OCTET STRING,
    timestamp    [1] KerberosTime OPTIONAL,
    usec    [2] Microseconds OPTIONAL,
    seq-number    [3] UInt32 OPTIONAL,
    s-address    [4] HostAddress,
    r-address    [5] HostAddress OPTIONAL
}

pvno et msg-type Décrits dans KRB_KDC_REQ. msg-type est KRB_SAFE
safe-body Ce champ est un fourre tout pour le corps du message KRB_SAFE
cksum Ce champ contient le checksum des données d'application, calculée avec une valeur d'utilisation de clé de 15. La somme de contrôle est calculée sur le codage de la séquence KRB-SAFE. D'abord, le cksum est mis à un type zéro, valeur de longueur zéro, et la somme de contrôle est calculée sur le codage de la séquence KRB-SAFE. Puis la somme de contrôle est réglée au résultat de ce calcul. Finalement, la séquence KRB-SAFE est codée à nouveau.
user-data Ce champ fait partie des messages KRB_SAFE et KRB_PRIV, et contient les données spécifiques de l'application qui sont passées de l'envoyeur au receveur.
timestamp Ce champ fait partie des messages KRB_SAFE et KRB_PRIV. Heure courante le l'émetteur.
usec partie micro-seconde du timestamp
seq-number Ce champ est décrit au paragraphe ticket
s-address Spécifie l'adresse utilisée par l'eméteur du message
r-address Spécifie l'adresse utilisée par le receveur du message. Il peut être omis pour certaines utilisations ( comme les protocoles de diffusion ), mais le receveur peut arbitrairement rejeter de tels messages. Ce champ, avec s-address, peut être utilisé pour aider à détecter des messages qui on été incorrectement ou malicieusement délivrés à un mauvais receveur.

Spécification du message KRB_PRIV

   Ce paragraphe spécifie le format d'un message qui peut être utilisé par un client et un serveur d'application pour envoyer en toute sécurité et confidentialité un message à son homologue. Il suppose qu'une clé de session ait précédemment été échangée (par exemple, en utilisant les message KRB_AP_REQ/KRB_AP_REP. Le message KRB_PRIV contient des données d'utilisateur chiffrées avec la clé de session.

Les champs de messages sont les suivant:
KRB-PRIV ::= [APPLICATION 21] SEQUENCE {
    pvno    [0] INTEGER (5),
    msg-type [1] INTEGER (21), -- NOTE : Il n'y a pas d'étiquette [2]
    enc-part    [3] EncryptedData -- EncKrbPrivPart
}
EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE {
    user-data    [0] OCTET STRING,
    horodatage    [1] KerberosTime OPTIONAL,
    usec    [2] Microseconds OPTIONAL,
    seq-number    [3] UInt32 OPTIONAL,
    s-address    [4] HostAddress -- adresse de l'envoyeur
    r-address    [5] HostAddress OPTIONAL -- adresse du receveur
}

pvno et msg-type Décrits dans KRB_KDC_REQ. msg-type est KRB_PRIV
enc-part Ce champ détient un codage de la séquence EncKrbPrivPart chiffrée avec le clé de session, avec une valeur d'utilisation de clé de 13. Ce codage chiffré est utilisé pour le champ enc-part du message KRB-PRIV
user-data, horodatage, usec, s-address, et r-address Décrits dans KRB_SAFE
seq-number Décrits dans la section ticket

Spécification du message KRB_CRED

   Ce paragraphe spécifie le format d'un message qui peut être utilisé pour envoyer des accréditifs Kerberos d'un principal à un autre. Il est présenté ici pour encourager l'utilisation d'un mécanisme commun par les applications lors de la transmission des tickets ou la fourniture de mandataires aux serveurs subordonnées. Il suppose qu'une clé de session a déjà été échangée, peut-être en utilisant les message KRB_AP_REQ/KRB_AP_REP. Le message KRB_CRED contient une séquence de tickets à envoyer et les informations nécessaires pour utiliser les tickets, comportant la clé de session de chacun. Les informations nécessaires pour utiliser les tickets sont chiffrées avec une clé de chiffrement échangée précédemment ou transférée à l'aide du message KRB_CRED.

Les champs de message sont les suivants:
KRB-CRED ::= [APPLICATION 22] SEQUENCE {
    pvno    [0] INTEGER (5),
    msg-type    [1] INTEGER (22),
    tickets    [2] SEQUENCE OF Ticket,
    enc-part    [3] EncryptedData -- EncKrbCredPart
}
EncKrbCredPart ::= [APPLICATION 29] SEQUENCE {
    ticket-info    [0] SEQUENCE OF KrbCredInfo,
    nonce    [1] UInt32 OPTIONAL,
    timestamp    [2] KerberosTime OPTIONAL,
    usec    [3] Microseconds OPTIONAL,
    s-address    [4] HostAddress OPTIONAL,
    r-address    [5] HostAddress OPTIONAL
}
KrbCredInfo ::= SEQUENCE {
    key    [0] EncryptionKey,
    prealm    [1] Realm OPTIONAL,
    pname    [2] PrincipalName OPTIONAL,
    flags    [3] TicketFlags OPTIONAL,
    authtime    [4] KerberosTime OPTIONAL,
    starttime    [5] KerberosTime OPTIONAL,
    endtime    [6] KerberosTime OPTIONAL,
    renew-till    [7] KerberosTime OPTIONAL,
    srealm    [8] Realm OPTIONAL,
    sname    [9] PrincipalName OPTIONAL,
    caddr    [10] HostAddresses OPTIONAL
}

pvno et msg-type Décrits dans KRB_KDC_REQ. msg-type est KRB_PRIV
tickets Ce sont les tickets obtenus du KDC pour utilisation spécifique par le receveur. Les tickets successifs sont appariés avec la séquence KrbCredInfo correspondante de enc-part du message KRB-CRED
enc-part Ce champ étient un codage de la séquence EncKrbCredPart chiffrée avec la clé de session partagée par l'envoyeur et le receveur prévu, avec une valeur d'utilisation de 14. Ce codage chiffré est utilisé pour le champ enc-part du message KRB-CRED.
nonce Si elle en a la capacité, une application peut exiger l'inclusion d'un nom occasionnel généré par le receveur du message.Si la même valeur est incluse comme nom occasionnel danse le message, cela donne la preuve que le message est frais et n'a pas été répété par un agresseur.
timestamp et usec Ces champs spécifient l'heure à laquelle le message KRB-CRED a été généré. L'heure est utilisée pour fournir l'assurance que le message est frais.
s-address et r-address Décrit dans KRB_SAFE
key Ce champ existe dans le ticket correspondant passé par le message KRB-CRED et est utilisé pour passer la clé de session de l'envoyeur au destinataire prévu.
prealm et pname facultatifs. Nom et domaine de l'entité de principal délégué.
lags, authtime, starttime, endtime, renew-till, srealm, sname, et caddr facultatifs. Ces champs contiennent les valeurs des champs correspondants dans le ticket trouvé dans le champ ticket. Les descriptions des champs sont identiques aux descriptions dans le messages KDC-REP.

Spécification du message KRB_ERROR

   Ce paragraphes spécifie le format du message KRB_ERROR. Les champs inclus dans le message sont destinés à retourner autant d'informations que possible sur l'erreur. On ne s'attend pas à ce que toutes les informations exigées par les champs soient disponibles pour tous.les types d'erreur. Si les informations appropriées ne sont pas disponibles lors de la composition du message, le champ correspondant sera laissé de côté pour ce message. Noter que comme le message KRB_ERROR n'est pas protégé en intégrité, il est assez possible à un attaquant de le synthétiser ou le modifier. En particulier, cela signifie que le client ne devrait pas utiliser ces champs dans ce message pour des besoins critiques pour la sécurité, comme le réglage d'une horloge système ou la génération d'un authentifiant frais. Le message peut cependant être utile pour informer un utilisateur des raisons d'un échec.

Les champs de message sont les suivants:
KRB-ERROR ::= [APPLICATION 30] SEQUENCE {
    pvno    [0] INTEGER (5),
    msg-type    [1] INTEGER (30),
    ctime    [2] KerberosTime OPTIONAL,
    cusec    [3] Microseconds OPTIONAL,
    stime    [4] KerberosTime,
    susec    [5] Microseconds,
    error-code    [6] Int32,
    crealm    [7] Realm OPTIONAL,
    cname    [8] PrincipalName OPTIONAL,
    realm    [9] Realm -- domaine du service --,
    sname    [10] PrincipalName -- domaine du service --,
    e-text    [11] KerberosString OPTIONAL,
    e-data    [12] OCTET STRING OPTIONAL
}

pvno et msg-type Décrits dans KRB_KDC_REQ. msg-type est KRB_ERROR
ctime et cusec Ces champs sont décris dans KRB_AP REP.Si les valeurs de ces champs sont connues de l'entité qui génère l'erreur, ils devraient être remplis dans la KRB-ERROR. Se les valeurs ne sont pas disponibles, ces champs peuvent être omis.
stime Ce champ contient l'heure en cours au serveur. Il est du type KerberosTime.
susec Ce champ contient la partie microseconde du timestamp.
error-code Ce champ contient le code d'erreur retourné par Kerberos ou le serveur.
crealm et cname Ces champs sont décrit au paragraphe ticket. Lorsque l'entité qui génère l'erreur connaît ces valeur, elle devraient être remplies dans le KRB-ERROR. Si les valeurs ne sont pas connues, les champs crealm et cname devraient être omis.
realm et sname Ces champs sont décrits dans le paragraphe ticket
e-text Ce champ contient du texte supplémentaire pour aider à expliquer le code d'erreur associé à l'échec de demande.
e-data Ce champ contient des données supplémentaires sur l'erreur à utiliser par l'application. Si le codes d'erreur est KDC_ERR_PREAUTH_REQUIRED, le champ e-data contiendra alors un odage de la séquence des champs padata, chacun correspondant à une méthode acceptable de pré-authentification et contenant facultativement des données pour la méthode: METHOD-DATA ::= SEQUENCE OF PA-DATA

   Pour les codes d'erreur définis dans le présent document autres que KDC_ERR_PREAUTH_REQUIRED, le format et le contenu du champ e-data sont définis par l'implémentation. De même, pour les codes d'erreur futurs, le format et le contenu du champ e-data sera défini par l'implémentation sauf spécification contraire. Qu'ils soient définis par l'implémentation ou dans un document futur, le champ e-data peut prendre la forme de TYPED-DATA:


TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
    data-type    [0] Int32,
    data-value    [1] OCTET STRING OPTIONAL
}

Tag Number d'application

   Le tableau suivant fait la liste des numéros d'étiquette de classe d'application utilisés par divers type de données définies dans ce paragraphe:

tag Number - (type name) - commentaires
0 non utilisé
1 (Ticket) PDU
2 (Authenticator) non PDU
3 (EncTicketPart) non PDU
4-9 non utilisé
10 (AS-REQ) PDU
11 (AS-REP) PDU
12 (TGS-REQ) PDU
13 (TGS-REP) PDU
14 (AP-REQ) PDU
15 (AP-REP) PDU
16 (RESERVED16) TGT-REQ (d'utilisateur à utilisateur)
17 (RESERVED17) TGT-REQ (d'utilisateur à utilisateur)
18-19 non utilisé
20 (KRB-SAFE) PDU
21 (KRB-PRIV) PDU
22 (KRB-CRED) PDU
23-24 non utilisé
25 (EncASRepPart) non PDU
26 (EncTGSRepPart) non PDU
27 (EncApRepPart) non PDU
28 (EncKrbPrivPart) non PDU
29 (EncKrbCredPart) non PDU
30 (KRB-ERROR) PDU

   Les types ASN.1 marqués ci-dessus comme PDU sont les seuls types ASN.1 perçus comme types de niveau supérieur dans le protocole Kerberos, et sont les seuls types qui peuvent être utilisés comme éléments dans un autre protocoles qui utilise Kerberos.

Noms de domaine

   Bien que les noms de domaine soient codés comme des GeneralStrings et que techniquement un domaine puisse choisir le nom qu'il veut, l'intéropérabilité à travers les frontières de domaine exige un accord sur la façon dont les noms de domaine sont alloués et les informations qu'ils comportent.

   Pour mettre en application ces conventions, chaque domaine doit se conformer aux conventions elles-mêmes, et il doit exiger que tout domaine avec lequel il partage des clés inter-domaine se conforme aussi aux conventions et qu'il exige la même chose de ses voisins.

   Les noms de domaine Kerberos sont sensibles à la casse. Les noms de domaine qui ne diffèrent que par la casse des caractères ne sont pas équivalents. Il y a actuellement 3 styles de noms de domaine: domaine, X500, et autre:

domain: ATHENA.MIT.EDU
X500: C=US/O=OSF
autre: NAMETYPE:rest/of.name=without-restrictions

   Les noms de style domaine doivent ressembler à des noms de domaine: Ils comportent des composants séparés par des points et ils ne contiennent ni ":" ni "/". Bien que les noms de domaine eux-mêmes ne soient pas sensibles à la casse, afin que les domaines correspondent, la casse doit aussi correspondre. Lors de l'établissement d'un nouveau nom de domaine fondé sur un nom de domaine internet, il est recommandé par convention que les caractères soient convertis en majuscules.

   Les noms X.500 contiennent le signe égal et ne peuvent pas contenir ":" avant le signe égal. Les noms de domaine pour les noms X.500 doivent être des représentations de chaîne des noms avec des composants séparés par des barres obliques. Les barres obliques en tête et en queue ne seront pas incluses. Noter que la barre oblique de séparation est cohérente avec les implémentations de Kerberos fondées sur la rfc1510, mais elle est différente du séparateur recommandé dans la rfc2253.

   Les noms qui entrent dans la catégorie autre doivent commencer par un préfixe ne contenant pas de signe égal ou point, et le préfixe doit être suivi par ":" et le reste du nom. Tous les préfixes attendent ceux qui commencent à être utilisés. Actuellement, aucun n'est alloué.

   La catégorie réservée comporte des chaînes qui n'entrent pas dans les 3 premières catégories. Tous les noms de cette catégorie sont réservés. Il est peut vraisemblable que des noms soient alloués dans cette catégorie sauf s'il y a de très forts arguments pour ne pas utiliser la catégorie autre.

   Ces règles garantissent qu'il n'y aura pas de conflit entre les divers styles de nom. Les contraintes supplémentaires suivantes s'appliquent à l'allocation de noms de domaine dans les catégories domaine et X.500: le nom d'un domaine pour les formats domaine ou X.500 doit être utilisé par l'organisation propriétaire d'un nom de domaine Internet ou d'un nom X.500, ou, dans le cas où un tel nom n'est pas enregistré, l'autorité pour utiliser un nom de domaine peut être dérivé de l'autorité du domaine parent. Par exemple, s'il n'y a pas de nom de domaine pour E40.MIT.EDU, l'administrateur du domaine MIT.EDU peut alors autoriser la création d'un domaine de ce nom.

   Ceci est acceptable parce que l'organisation à laquelle le parent est alloué est vraisemblablement aussi l'organisation autorisée à allouer des noms à ses enfants dans les systèmes de nom X.500 et domaine. Si le parent alloue un nom de domaine sans l'enregistrer aussi dans la hiérarchie de nom de domaine ou X.500, il est de la responsabilité du parent de s'assurer qu'à l'avenir il n'existe pas un nom identique au nom de domaine de l'enfant sauf s'il est alloué à la même entité comme nom de domaine.

Noms de principal

   Comme c'est le cas pour les noms de domaine, des conventions sont nécessaires pour s'assurer que tous sont d'accord sur les information impliquées par un nom de principal. Le champ name-type qui fait partie du nom de principal indique le type d'informations impliquées par le nom. Le name-type devrait être traité que comme un conseil pour interpréter la signification d'un nom. Il n'y a pas de sens à lui rechercher une équivalence. Les noms de principal qui ne diffèrent que par le name-type identifient le même principal. Le type de nom ne crée pas une partition de l'espace de nom. En ignorant le type de nom, 2 noms ne peuvent être les mêmes. Les types de nom suivants sont définis:

NT-UNKNOWN (0) Type de nom inconnu
NT-PRINCIPAL (1) Seulement le nom du principal comme dans DCE, ou pour les utilisateurs
NT-SRV-INST (2) Service et autre instance unique (krbtgt)
NT-SRV-HST (3) Service avec nom d'hôte comme instance (telnet, rcommands)
NT-SRV-XHST (4) Service avec hôte comme composants restants
NT-UID (5) ID unique
NT-X500-PRINCIPAL (6) Nom distinctif codé en X.509 [RFC2253]
NT-SMTP-NAME (7) Nom en forme de nom de messagerie électronique SMTP (par exemple,user@example.com)
NT-ENTERPRISE (10) Nom d'entreprise - peut être transposé en nom de principal

   Lorsqu'un nom n'implique pas d'informations autres que son unicité à un moment particulier, le type de nom PRINCIPAL devrait être utilisé pour les utilisateurs, et il peut aussi être utilisé pour un serveur unique. Si le nom est un ID unique généré par la machine qu'il est garanti n'être jamais ré-alloué, le type de nom d'UID devrait alors être utilisé.

   Si le premier composant d'un nom identifie un service et si des composants restants identifient une instance du service d'un manière spécifiée par le serveur, le type de nom de SRV-INST devrait alors être utilisé. Un exemple de ce type de nom est le TGS dont le nom a un premier composant de krbtgt et un second composant identifiant le domaine pour lequel le ticket est valide.

   Si le premier composant d'un nom identifie un service et qu'il y a un seul composant suivant le nom de service qui identifie l'instance comme l'hôte sur lequel fonctionne le serveur, le type de nom SRV-HST devrait être utilisé. Ce type est normalement utilisé pour les services Internet tels que telnet et les commandes R de Berkeley. Si les composants séparés du nom de l'hôte apparaissent comme des composants successifs qui suivent le nom du service, le type de nom SRV-XHST devrait être utilisé. Ce type peut être utilisé pour identifier les serveurs sur des hôtes qui ont des noms X.500, et où "/" pourrait être ambiguë.

   Un type de nom NT-X500-PRINCIPAL devrait être utilisé lorsqu'un nom provenant d'un certificat X.509 est traduit en un nom Kerberos. Le codage du nom X.509 comme un principal de Kerberos doit être conforme aux règles de codage spécifiées dans la rfc2253.

   Un type de nom de SMTP permet à un nom d'être d'un forme qui ressemble à un nom de messagerie électronique SMTP. Ce nom, comportant un @ et un nom de domaine, est utilisé comme premier composant du nom de principal.

   Un type de nom de UNKNOWN devrait être utilisé lorsque la forme du nom n'est pas connue. Lors d'une comparaison des nom, un type de nom UNKNOWN correspondra aux principaux authentifiés avec des noms de tout type. Un principal authentifié avec un type de nom de UNKNOWN ne correspondra cependant qu'à d'autres noms de type UNKNOWN.

   Les noms de tout type avec un composant initial de krbtgt sont réservés pour le TGS.

Nom des principaux de serveur

   L'identifiant de principal pour un serveur sur un hôte sera généralement composé de 2 parties: Le domaine du KDC avec lequel le serveur est enregistré, et un nom à 2 composants NT-SRV-HST, si le nom d'hôte est un nom de domaine Internet, ou un nom multi-composants de type NT-SRV-XHST, si le nom de l'hôte est d'une forme qui permet "/" comme séparateurs. Le premier composant du nom à deux ou plusieurs composants va identifier le service, et les derniers composants vont identifier l'hôte. Lorsque le nom de l'hôte n'est pas sensible à la casse, le nom de l'hôte doit être en minuscule. Si c'est spécifié par le protocole d'application pour des services tels que telnet et les commandes R de Berkeley qui fonctionnent avec des privilèges de système, le premier composant peut être la chaîne host au lieu d'un identifiant spécifique du service.

Types d'adresse d'hôte

   Toutes les valeurs négatives pour le type d'adresse d'hôte sont réservées à une utilisation locale. Toutes les valeurs non négatives sont réservées aux champs et interprétations de type officiellement alloués.

Adresses Internet (IPv4) Les adresses Internet sont des quantités de 32bits codées dans l'ordre MSB. Une adresse IPv4 de bouclage ne devrait pas apparaître dans un PDU Kerberos. Le type des adresses IPv4 est (2)
Adresses Internet (IPv6) Les adresses IPv6 sont des guantités de 128bits codées danfs l'ordre MSB. Le type des adresses IPv6 est (24). Les adresses suivantes ne doivent pas apparaître dans un PDU Kerberos: l'adresse non spécifiée, la loopback, les adresses de lien locaux.

   Ces restrictions s'appliquent à l'inclusion dans les champs d'adresse des PDU, mais pas aux champs d'adresse des paquets qui pourraient porter ces PDU. La restriction est nécessaire parce que l'utilisation d'une adresse d'une portée non mondial pourrait permettre l'acceptation d'un message envoyé à partir d'un nœud qui pourrait avoir la même adresse, mais qui ne serait par l'hôte prévu. Si le type d'adresse local doit être utilisé pour une communication, la restriction d'adresse dans les tickets ne doit pas être utilisée. Les adresses IPv6 transposées en IPv4 doivent être représentées comme adresses de type 2.

Adresses DECnet de Phase IV Les adresses DECnet de Phase IV sont des adresses de 16 bits, codées dans l'ordre LSB. Le type des adresses DECnet de Phase IV est (12).
Adresses Netbios Les adresses Netbios sont des adresses de 16 octets normalement composées de caractères alphanumériques de 1 à 15 et complétées avec le caractère US-ASCII SPC (code 32). Le 16ème octet DOIT être le caractère US-ASCII NUL (code 0). Le type des adresses Netbios est (20)

Adresses directionnelles Inclure l'adresse de l'émetteur dans les messages KRB_SAFE et KRB_PRIV n'est pas souhaitable dans de nombreux environnements parce que les adresses peuvent être changées dans le transport par des traducteurs d'adresse réseau. Cependant, si ces adresses sont retirées les messages peuvent être soumis à une attaque par réflexion dans laquelle un message est répliqué en retour à son origine. Le type d'adresse directionnelle donne le moyen d'éviter les attaques des adresses dans le transport et en réflexion. Les adresses directionnelles sont codées comme des entiers non signés de 4 octets dans l'ordre des octets du réseau. Si le message est généré par la pratie qui envoie le message KRB_AP_REQ original, une adresse de 0 devrait être utilisé. Les applications qui impliquent plusieurs parties peuvent spécifier l'utilisation des autres adresses.

   Les adresses directionnelles doivent être utilisées uniquement pour le champ d'adresse d'envoyeur dans les messages KRB_SAFE ou KRB_PRIV. Elles no doivent pas être utilisées comme adresse de ticket ou dans un message KRB_AP_REQ. Ce type d'adresse devrait être utilisé seulement dans des situations où la partie qui envoie sait que la partie qui reçoit prend en charge le type d'adresse. Cela signifie généralement que les adresses directionnelles ne peuvent être utilisée que quand le protocoles d'application exige leur prise en charge. Les adresses directionnelles dont du type (3)

Échange de messages KDC: transports IP

   Kerberos définis 2 mécanismes de transport IP pour communiquer entre clients et serveurs: UDP/IP et TCP/IP.

UDP/IP

   Les KDC qui prennent en charge les transport IP doivent accepter les demandes UDP et devraient les écouter sur le port 88. Des accès de remplacement peuvent être utilisés quand plusieurs KDC fonctionnent sur plusieurs domaines sur le même hôte.

   Les clients Kerberos qui prennent en charge les transports IP devraient prendre en charge l'envoi des demandes UDP. Les client devraient utiliser la découverte de KDC pour identifier l'adresse et le port IP auquel ils veulent envoyer leur demande.

   Lorsqu'il contacte un KDC pour un KRB_KDC_REQ en utilisant UDP, le client doit envoyer un UDP ne contenant qu'un codage de la demande au KDC. Le KDC répondra avec un datagramme contenant seulement un encodage de la réponse (soi un KRB_ERROR, soit un KRB_KDC_REP) à l'adresse IP de l'envoyeur. La réponse à une demande faite au moyen d'un transport UDP/IP doit aussi utiliser le transport UDP. Si la réponse ne peut être traitée en utilisant UDP (par exemple, parce qu'elle est trop grande), le KDC doit retourner KRB_ERR_RESPONSE_TOO_BIG, forçant le client à réessayer la demande en utilisant le transport TCP.

TCP/IP

   Les KDC qui prennent en charge les transports IP doivent accepter les demandes TCP et devraient les écouter sur le port 88. Les clients doivent prendre en charge l'envoi des demandes TCP, mais peuvent choisir d'essayer une demande en utilisant initialement le transport UDP. Les clients devraient utiliser la découverte de KDC pour identifier l'adresse et le port IP auquel ils enverront leur demande.

   Lorsque le message KRB_KDC_REQ est envoyé au KDC sur un flux TCP, la réponse doit être retournées au client sur le même flux TCP qui était établis pour le demandes. Le KDC peut fermer le flux TCP après avoir envoyé une réponse, mais peut laisser le flux ouvert pendant une durées raisonnable s'il attend une suite. Il faut veiller, dans la gestion des connexions TCP avec le KDC, à empêcher les attaques DOS fondées sur le nombre de connexions TCP ouvertes.

   Le client doit être prêt à voir le flux fermé par le KDC à tout moment après la réception d'une réponse. Une clôture de flux ne devrait pas être traitée comme une erreur fatale. Plutôt, si plusieurs échanges sont exigés (par exemple, par certaines formes de pré-authentification), le client peut avoir besoin d'établir une nouvelle connexion quand il est prêt à envoyer les messages suivants. Un client peut clore le flux après réception d'une réponse, et devrait clore le flux s'il ne prévoit pas d'envoyer de messages de suite.

   Un client peut envoyer plusieurs demandes avant de recevoir des réponses, bien qu'il doive être prêt à traiter la fermeture de la connexion après la première réponse.

   Chaque demande (KRB_KDC_REQ) et réponse (KRB_KDC_REP ou KRB_ERROR) envoyée sur le flux TCP est précédée par la longueur de la demande en 4 octets dans l'ordre des octets du réseau. Le MSB de la longueur est réservé à une expansion future et doit actuellement être mis à zéro. Si un KDC qui ne comprend pas comment interpréter un MSB mis dans le codage de longueur, reçoit une demande avec le MSB mis, il doit retourner un message KRB-ERROR avec l'erreur KRB_ERR_FIELD_TOOLONG et doit clore le flux TCP.

Découverte de KDC sur les réseaux IP

   Les implémentations de client Kerberos doivent fournir un moyen pour que le client détermine la localisation des KDC. Traditionnellement, les implémentations Kerberos mémorisent de telles informations de configuration dans un fichier sur chaque machine cliente. L'expérience a montré que cette méthode de mémorisation des informations de configuration pose des problèmes d'informations périmées et d'évaluation, tout particulièrement lors de l'utilisation de l'authentification inter-domaine.

DNS

   Dans Kerberos, les noms de domaine sont sensibles à la casse. Bien qu'il soit fortement recommandé que tous les noms de domaine soient en majuscule, cette recommandation n'a pas été adoptée par tous les sites. Certains sites utilisent des noms tout en minuscules et d'autres utilisent une casse mélangée. DNS, d'un autre côté, est insensible à la casse pour les interrogations.

Spécification de localisation de KDC avec DNS SRV

   Les informations de localisation de KDC sont à mémoriser en utilisant les DNS RR SRV . Le format de ce RR est le suivant:

  _Service._Proto.Realm TTL Class SRV Priority Weight Port Target

  Le proto peut être udp ou tcp. Si ces enregistrements de SRV doivent être utilisé, les enregistrements upd et tcp doivent tous 2 être spécifiés pour tous les développements de KDC. Le Realm est de domaine Kerberos auquel cet enregistrement correspond. Le domaine doit être un nom de domaine de style domaine. TTL, Class, SRV, Priority, Weight et Target ont la signification standar définis dans la rfc2782.

   Conformément à cette rfc, le numéro de port utilisé pour les enregistrement de SRV "_udp" et "_tcp" devraient être la valeur allouée à "kerberos" par l'IANA: 88, sauf si le KDC est configuré pour écouter sur un autre accès TCP.

Découverte de KDC pour les Realms name stype domaine

   Ce sont des enregistrement DNS pour un domaine Kerberos EXAMPLE.COM. Il y a 2 serveurs Kerberos kdc1.example.com et kdc2.example.con. Les requêtes devraient d'abord être dirigées sur kdc1.example.com conformément à la priorité spécifée. Les pondérations ne sont pas utilisées dans cet échantillons d'enregistrements.

_kerberos._udp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com.
_kerberos._udp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com.
_kerberos._tcp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com.
_kerberos._tcp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com.

Nom du TGS

   L'identifiant de principal du TGS doit être composé de 3 parties: le domaine du KDC qui produit les tickets TGS, et un nom en 2 parties du type NT-SRV-INST, dont la première partie est "krbtgt" et la seconde partie est le nom du domaine qui va accepter le TGT. Par exemple, un TGT produit par le domaine ATHENA.MIT.EDU utilisé pour des tickets du KDC ATHENA.MIT.EDU a un identifiant de principal de "ATHENA.MIT.EDU" (domaine), ("krbtgt", "ATHENA.MIT.EDU") (nom). Un TGT produit par le domaine ATHENA.MIT.EDU utilisé pour obtenir des tickets du domaine MIT.EDU a l'identifiant de principal "ATHENA.MIT.EDU" (domaine), ("krbtgt", "MIT.EDU") (nom).

OID pour Kerberosv5

Cet OID peut être utilisé pour identifier les messages de protocoles Kerberos encapsulés dans d'autres protocoles:
id-krb5 OBJECT IDENTIFIER ::= {
    iso(1) identified-organisation(3) dod(6) internet(1) security(5) kerberosV5(2)
}

Constantes du protocole et valeurs associées

   Les tableaux qui suivent font la liste des constantes utilisées dans le protocole et définissent leur signification. Dans la partie "spécification" sont spécifiés les gammes qui limitent les valeurs des constantes pour lesquelles les valeurs sont définies ici.

Valeurs d'utilisation de clé

   La spécification du chiffrement et de checksum exige en entrée un numéro d'utilisation de clé, pour altérer la clé de chiffrement utilisée dans tout message spécifique afin de rendre plus difficiles certains types d'attaques.

1. timestamp padata AS-REQ PA-ENC-TIMESTAMP, chiffré avec la clé de client
2. Tickets AS-REP et TGS-REP (inclut la clé de session TGS ou la clé de session d'application), chiffrés avec la clé de service
3. Partie chiffrée de AS-REP (inclut la clé de session TGS ou la clé de session d'application), chiffrée avec la clé de client
4. Données d'autorisation TGS-REQ KDC-REQ-BODY, chiffrées avec la clé de session TGS
5. Données d'autorisation TGS-REQ KDC-REQ-BODY, chiffrées avec la sous-clé d'authentifiant TGS
6. Somme de contrôle d'authentifiant AP-REQ de padata TGS-REQ PA-TGS-REQ, frappée avec la clé de session TGS
7. Authentifiant AP-REQ de padata TGS-REQ PA-TGS-REQ (inclut la sous-clé d'authentifiant de TGS), chiffré avec la clé de session TGS
8. Partie chiffrée de TGS-REP (inclut la clé de session d'application), chiffrée avec la clé de session TGS
9. Partie chiffrée de TGS-REP (inclut la clé de session d'application), chiffrée avec la sous-clé d'authentifiant de TGS
10. Somme de contrôle d'authentifiant AP-REQ, frappée avec la clé de session d'application
11. Authentifiant AP-REQ (inclut la sous-clé d'authentifiant d'application), chiffré avec la clé de session d'application
12. Partie chiffrée de AP-REP (inclut la sous-clé de session d'application), chiffré avec la clé de session d'application
13. Partie chiffrée de KRB-PRIV, chiffrée avec une clé choisie par l'application
14. Partie chiffrée de KRB-CRED, chiffrée avec une clé choisie par l'application
15. Somme de contrôle KRB-SAFE, frappé avec une clé choisie par l'application
16-18. Réservés à une utilisation future dans Kerberos et les protocoles qui s'y rapportent.
19. Somme de contrôle AD-KDC-ISSUED (ad-checksum)
20-21. Réservés à une utilisation future dans Kerberos et les protocoles qui s'y rapportent.
22-25. Réservés à une utilisation future dans les mécanismes GSS-API de Kerberos Version 5 [RFC4121].
26-511. Réservés à une utilisation future dans Kerberos et les protocoles qui s'y rapportent.
512-1023. Réservés à des utilisations internes à une mise en œuvre Kerberos.
1024. Chiffrement à usage d'application dans les protocoles qui ne spécifient pas de valeurs d'usage de clés.
1025. Sommes de contrôle à usage d'application dans les protocoles qui ne spécifient pas de valeurs d'usage de clés
1026-2047. Réservé à l'usage d'application.

Types de données de pré-authentification

Padata et type de données (Padata-type) Commentaire
PA-TGS-REQ (1)
PA-ENC-TIMESTAMP (2)
PA-PW-SALT (3)
[reserved] (4)
PA-ENC-UNIX-TIME (5) déconseillé
PA-SANDIA-SECUREID (6)
PA-SESAME (7)
PA-OSF-DCE (8)
PA-CYBERSAFE-SECUREID (9)
PA-AFS3-SALT (10)
PA-ETYPE-INFO (11)
PA-SAM-CHALLENGE (12) sam/otp
PA-SAM-RESPONSE (13) sam/otp
PA-PK-AS-REQ_OLD (14) pkinit
PA-PK-AS-REP_OLD (15) pkinit
PA-PK-AS-REQ (16) pkinit
PA-PK-AS-REP (17) pkinit
PA-ETYPE-INFO2 (19) remplace pa-etype-info
PA-USE-SPECIFIED-KVNO (20)
PA-SAM-REDIRECT (21) sam/otp
PA-GET-FROM-TYPED-DATA (22) incorporé dans typed-data
TD-PADATA (22) incorpore padata
PA-SAM-ETYPE-INFO (23) sam/otp
PA-ALT-PRINC (24) crawdad@fnal.gov
PA-SAM-CHALLENGE2 (30) kenh@pobox.com
PA-SAM-RESPONSE2 (31) kenh@pobox.com
PA-EXTRA-TGT (41) Réservé extra TGT
TD-PKINIT-CMS-CERTIFICATES (101) CertificateSet du CMS
TD-KRB-PRINCIPAL (102) PrincipalName
TD-KRB-REALM (103) Domaine
TD-TRUSTED-CERTIFIERS (104 de PKINIT
TD-CERTIFICATE-INDEX (105) de PKINIT
TD-APP-DEFINED-ERROR (106) spécifique de l'application
TD-REQ-NONCE (107) ENTIER
TD-REQ-SEQ (108) ENTIER
PA-PAC-REQUEST (128) jbrezak@exchange.microsoft.com

Types d'adresse

IPv4 2
Directionnelle 3
ChaosNet 5
XNS 6
ISO 7
DECNET Phase IV 12
AppleTalk DDP 16
NetBios 20
IPv6 24

Types de données d'autorisation

Types de données d'autorisation Valeur de Ad-type
AD-IF-RELEVANT 1
AD-INTENDED-FOR-SERVER 2
AD-INTENDED-FOR-APPLICATION-CLASS 3
AD-KDC-ISSUED 4
AD-AND-OR 5
AD-MANDATORY-TICKET-EXTENSIONS 6
AD-IN-TICKET-EXTENSIONS 7
AD-MANDATORY-FOR-KDC 8
Valeurs réservées 9-63
OSF-DCE 64
SESAME 65
AD-OSF-DCE-PKI-CERTID 66 (hemsath@us.ibm.com)
AD-WIN2K-PAC 128 (jbrezak@exchange.microsoft.com)
AD-ETYPE-NEGOTIATION 129 (lzhu@windows.microsoft.com)

Types de codages de transit

Type de codage traversé Valeur de Tr-type
DOMAIN-X500-COMPRESS 1
Valeurs réservées Toutes les autres

Numéro de version du protocole

pvno (5) Numéro de version en cours du protocole Kerberos

Types de message Kerberos

KRB_AS_REQ (10) Demande d'authentification initiale
KRB_AS_REP (11) Réponse à demande KRB_AS_REQ
KRB_TGS_REQ (12) Demande d'authentification fondée sur un TGT
KRB_TGS_REP (13) Réponse à demande KRB_TGS_REQ
KRB_AP_REQ (14) Demande d'application au serveur
KRB_AP_REP (15) Réponse à KRB_AP_REQ_MUTUAL
KRB_RESERVED16 (16) Réservé à une demande krb_tgt_request d'usager à usager
KRB_RESERVED17 (17) Réservé à une réponse krb_tgt_reply d'usager à usager
KRB_SAFE (20) Message d'application sûr (avec somme de contrôle)
KRB_PRIV (21) Message d'application privé (chiffré)
KRB_CRED (22) Message privé (chiffré) pour transmission d'accréditifs
KRB_ERROR (30) Réponse d'erreur

Types de noms

KRB_NT_UNKNOWN (0) Type de nom inconnu
KRB_NT_PRINCIPAL (1) Juste le nom du principal comme dans DCE, ou pour utilisateurs
KRB_NT_SRV_INST (2) Service et autre instance unique (krbtgt)
KRB_NT_SRV_HST (3) Service avec nom d'hôte comme instance (telnet, rcommands)
KRB_NT_SRV_XHST (4) Service avec hôte comme composants restants
KRB_NT_UID (5) ID unique
KRB_NT_X500_PRINCIPAL (6) Nom distinctif X.509 codé [RFC2253]
KRB_NT_SMTP_NAME (7) Nom en forme de nom de messagerie électronique SMTP (par exemple, user@example.com)
KRB_NT_ENTERPRISE (10) Nom d'entreprise; peut être transposé en nom de principal

Codes d'erreur

KDC_ERR_NONE (0) Pas d'erreur
KDC_ERR_NAME_EXP (1) L'entrée du client dans la base de données a expiré
KDC_ERR_SERVICE_EXP (2) L'entrée du serveur dans la base de données a expiré
KDC_ERR_BAD_PVNO (3) Numéro de version du protocole demandé non accepté
KDC_ERR_C_OLD_MAST_KVNO (4) La clé du client est chiffrée avec la vieille clé maîtresse
KDC_ERR_S_OLD_MAST_KVNO (5) La clé du serveur est chiffrée avec la vieille clé maîtresse
KDC_ERR_C_PRINCIPAL_UNKNOWN (6) Client non trouvé dans la base de données Kerberos
KDC_ERR_S_PRINCIPAL_UNKNOWN (7) Serveur non trouvé dans la base de données Kerberos
KDC_ERR_PRINCIPAL_NOT_UNIQUE (8) Plusieurs entrées du principal dans la de données
KDC_ERR_NULL_KEY (9) Le client ou le serveur a une clé nulle
KDC_ERR_CANNOT_POSTDATE (10) Ticket non éligible au postdatage
KDC_ERR_NEVER_VALID (11) Heure de début demandée postérieure à l'heure de fin
KDC_ERR_POLICY (12) La politique du KDC rejette la demande
KDC_ERR_BADOPTION (13) Le KDC ne peut pas traiter l'option demandée
KDC_ERR_ETYPE_NOSUPP (14) Le KDC ne prend pas en charge le type de chiffrement
KDC_ERR_SUMTYPE_NOSUPP (15) Le KDC n'accepte pas le type de somme de contrôle
KDC_ERR_PADATA_TYPE_NOSUPP (16) Le KDC ne prend pas en charge le type de padata
KDC_ERR_TRTYPE_NOSUPP (17) Le KDC ne prend pas en charge le type transité
KDC_ERR_CLIENT_REVOKED (18) Les accréditifs du client ont été révoqués
KDC_ERR_SERVICE_REVOKED (19) Les accréditifs du serveur ont été révoqués
KDC_ERR_TGT_REVOKED (20) Le TGT a été révoqué
KDC_ERR_CLIENT_NOTYET (21) Client pas encore valide ; réessayer plus tard
KDC_ERR_SERVICE_NOTYET (22) Serveur pas encore valide ; réessayer plus tard
KDC_ERR_KEY_EXPIRED (23) Mot de passe expiré ; changer le mot de passe pour recommencer
KDC_ERR_PREAUTH_FAILED (24) Informations de pré-authentification invalides
KDC_ERR_PREAUTH_REQUIRED (25) Pré-authentification supplémentaire exigée
KDC_ERR_SERVER_NOMATCH (26) Le serveur demandé et le ticket ne correspondent pas
KDC_ERR_DOIIVENT_USE_USER2USER (27) Principal de serveur valide seulement d'usager à usager
KDC_ERR_PATH_NOT_ACCEPTED (28) La politique du KDC rejette le chemin de transit
KDC_ERR_SVC_UNAVAILABLE (29) Un service n'est pas disponible
KRB_AP_ERR_BAD_INTEGRITY (31) Échec de vérification d'intégrité sur le champ déchiffré
KRB_AP_ERR_TKT_EXPIRED (32) Ticket expiré
KRB_AP_ERR_TKT_NYV (33) Ticket pas encore valide
KRB_AP_ERR_REPEAT (34) La demande est une répétition
KRB_AP_ERR_NOT_US (35) Le ticket n'est pas pour nous
KRB_AP_ERR_BADMATCH (36) Ticket et authentifiant ne correspondent pas
KRB_AP_ERR_SKEW (37) Biais d'horloge trop grand
KRB_AP_ERR_BADADDR (38) Adresse réseau incorrecte
KRB_AP_ERR_BADVERSION (39) Discordance de version de protocole
KRB_AP_ERR_MSG_TYPE (40) Type de message invalide
KRB_AP_ERR_MODIFIED (41) Flux de message modifié
KRB_AP_ERR_BADORDER (42) Message pas à son ordre
KRB_AP_ERR_BADKEYVER (44) Version de clé spécifiée non disponible
KRB_AP_ERR_NOKEY (45) Clé de service non disponible
KRB_AP_ERR_MUT_FAIL (46) Échec d'authentification mutuelle
KRB_AP_ERR_BADDIRECTION (47) Direction de message incorrecte
KRB_AP_ERR_METHOD (48) Autre méthode d'authentification exigée
KRB_AP_ERR_BADSEQ (49) Numéro de séquence incorrect dans le message
KRB_AP_ERR_INAPP_CKSUM (50) Type de somme de contrôle inapproprié dans le message
KRB_AP_PATH_NOT_ACCEPTED (51) La politique rejette le chemin de transit
KRB_ERR_RESPONSE_TOO_BIG (52) Réponse trop grosse pour UDP ; ressayer avec TCP
KRB_ERR_GENERIC (60) Erreur générique (description dans e-text)
KRB_ERR_FIELD_TOOLONG (61) Le champ est trop long pour cette mise en œuvre
KDC_ERROR_CLIENT_NOT_TRUSTED (62) Réservé pour PKINIT
KDC_ERROR_KDC_NOT_TRUSTED (63) Réservé pour PKINIT
KDC_ERROR_INVALID_SIG (64) Réservé pour PKINIT
KDC_ERR_KEY_TOO_WEAK (65) Réservé pour PKINIT
KDC_ERR_CERTIFICATE_MISMATCH (66) Réservé pour PKINIT
KRB_AP_ERR_NO_TGT (67) Pas de TGT disponible pour valider USER-TO-USER
KDC_ERR_WRONG_REALM (68) Réservé pour utilisation future
KRB_AP_ERR_USER_TO_USER_REQUIRED (69) Le ticket doit être pour USER-TO-USER
KDC_ERR_CANT_VERIFY_CERTIFICATE (70) Réservé pour PKINIT
KDC_ERR_INVALID_CERTIFICATE (71) Réservé pour PKINIT
KDC_ERR_REVOKED_CERTIFICATE (72) Réservé pour PKINIT
KDC_ERR_REVOCATION_STATUS_UNKNOWN (73) Réservé pour PKINIT
KDC_ERR_REVOCATION_STATUS_UNAVAILABLE (74) Réservé pour PKINIT
KDC_ERR_CLIENT_NAME_MISMATCH (75) Réservé pour PKINIT
KDC_ERR_KDC_NAME_MISMATCH (76) Réservé pour PKINIT

Exigences d'intéropérabilité

   La version 5 du protocole Kerberos accepte une myriade d'options. Parmi celles-ci, plusieurs types de chiffrement et de sommes de contrôle; des schéma de codage de remplacement pour le champ de transit; des mécanismes facultatifs pour la pré-authentification; le traitement de tickets sans adresse; des options pour l'authentification mutuelle; l'authentification d'utilisateur à utilisateur; la prise en change de proxy; le format des noms de domaines; le traitement des données d'autorisation; et la transmission, le post-datage, et le renouvellement de tickets.

   Afin d'assurer l'intéropérabilité des domaines, il est nécessaire de définir une configuration minimale qui doit être prise en charge par toutes les mises en œuvre. Cette configuration minimale est sujette à changement ultérieurs.

Spécification 2

   Ce paragraphe définit la seconde spécification des options. Les implémentations qui sont configurées de cette façon peuvent être considérées comme prenant en charge la spécification 2 de Kerberos v5 (5.2).

Transport Le transport TCP/IP et UDP/IP doivent être pris en charge par les clients et KDC qui revendiquent la conformité à
la spécification 2. Méthodes de chiffrement et de somme de contrôle
Les mécanismes de chiffrement et de somme de contrôle suivants doivent être pris en charge:
Chiffrement: AES256-CTS-HMAC-SHA1-96 [RFC3962]
Somme de contrôle: HMAC-SHA1-96-AES256 [RFC3962]

   Les mises en œuvre devraient aussi accepter d'autres mécanismes, mais les mécanismes supplémentaires ne peuvent être utilisés qu'en communicant avec des principaux connus pour les accepter aussi. Les mécanismes suivants provenant de la [RFC3961] et de la [RFC3962] devraient être pris en charge:

Chiffrement: AES128-CTS-HMAC-SHA1-96, DES-CBC-MD5, DES3-CBC-SHA1-KD
Somme de contrôle: DES-MD5, HMAC-SHA1-DES3-KD, HMAC-SHA1-96-AES128

   Les implémentations peuvent aussi accepter d'autres mécanismes, mais les mécanismes supplémentaires ne peuvent être utilisés qu'en communication avec des principaux connus pour les accepter aussi.

Noms de domaine Toutes les mises en œuvre doivent comprendre la hiérarchie des domaines à la fois dans le domaine Internet et dans le style X.500. Lorsque est demandé un TGT pour un domaine inconnu, le KDC doit être capable de déterminer les noms des domaines intermédiaires entre le domaine du KDC et le domaine demandé.
Codage de champ de transit DOMAIN-X500-COMPRESS doit être pris en charge. D'autres codages peuvent être acceptés, mais ils ne peuvent être utilisés lorsque ce codage est accepté par tous les domaines intermédiaires.
Méthodes de pré-authentification La méthode TGS-REQ doit être prise en charge. Elle n'est pas utilisée sur la demande initiale. La méthode PA-ENC-TIMESTAMP doit être acceptée par les clients, mais savoir si elle est activée par défaut peut être déterminé domaine par domaine. Si la méthode n'est pas utilisée dans la demande initiale et si l'erreur KDC_ERR_PREAUTH_REQUIRED est retournée, spécifiant PA-ENC-TIMESTAMP comme méthode acceptable, le client devrait ressayer la demande initiale en utilisant la méthode de pré-authentification PA-ENC-TIMESTAMP. Les serveurs n'ont pas besoin de prendre en charge la méthode PA-ENC-TIMESTAMP, mais si elle n'est pas acceptée, le serveur devrait ignorer la présence de la pré-authentification PA-ENC-TIMESTAMP dans une demande.
La méthode ETYPE-INFO2 doit être acceptée; cette méthode est utilisée pour communiquer l’ensemble des types de chiffrement acceptés, et les paramètres correspondants de salt et de string-to-key. La méthode ETYPE-INFO devrait être acceptée pour l’interopérabilité avec les mises en œuvre les plus anciennes.
Authentification mutuelle L’authentification mutuelle (via le message KRB_AP_REP) doit être acceptée.
Adresses et flags de ticket Tous les KDC doivent passer les tickets qui ne portent pas d’adresse (c’est-à-dire que si un TGT ne contient pas d’adresse, le KDC retournera des tickets dérivés). Les mises en œuvre devraient par défaut demander des tickets sans adresse, car cela augmente de façon significative l’interopérabilité avec la traduction d’adresse réseau. Dans certains cas, les domaines ou les serveurs d’application peuvent exiger que les tickets aient une adresse.

   Les mises en œuvre devraient accepter le type d’adresse directionnelle pour les messages KRB_SAFE et KRB_PRIV et devraient inclure des adresses directionnelles dans ces messages quand d’autres types d’adresse ne sont pas disponibles. Les tickets mandataires et transmis doivent être acceptés. Les domaines et serveurs d’application individuels peuvent y régler leur propre politique lorsque de tels tickets seront acceptés. Toutes les implémentations doivent reconnaître les tickets renouvelables et postdatés, mais ils n’ont pas besoin de les mettre réellement en œuvre. Si ces options ne sont pas prises en charge, l’heure de début et l’heure de fin dans le ticket devront spécifier l’entière durée de vie utile d’un ticket. Lorsque un ticket postdaté est décodé par un serveur, toutes les mises en œuvre devront rendre visible la présence du flag postdaté pour le serveur appelant

Authentification d’usager à usager La prise en charge de l’authentification d’usager à usager (via l’option ENC-TKT-IN-SKEY KDC) doit être fournie par les mises en œuvre, mais les domaines individuels peuvent décider au titre de leur politique de rejeter de telles demandes principal par principal ou domaine par domaine.
Données d’autorisation Les mises en œuvre doivent passer tous les sous-champs de données d’autorisation des TGT à tout ticket dérivé sauf si ils sont amenés à supprimer un sous-champ au titre de la définition de ce type de sous-champ enregistré. (Il n’est jamais incorrect de passer sur un sous-champ, et actuellement, aucun type de sous-champ enregistré ne spécifie la suppression au KDC.)
Les mises en œuvre doivent rendre disponible le contenu de tout sous-champ de données d’autorisation au serveur lorsque le ticket est utilisé. Les mises en œuvre ne sont pas obligées de permettre aux clients de spécifier le contenu des champs de données d’autorisation.
Gammes de constantes Toutes les constantes du protocole sont contraintes à des valeurs de 32 bits (signés) sauf contraintes supplémentaires provenant de la définition du protocole. Cette limite est donnée pour permettre aux mises en œuvre de faire des hypothèses sur les valeurs maximales qui seront reçues pour ces constantes. Les mises en œuvre recevant des valeurs hors de ces gammes peuvent rejeter la demande, mais elles doivent se récupérer proprement.

Valeurs de KDC recommandées

Durée de vie minimum 5 minutes
Durée de vie maximum renouvelable 1 semaine
Durée de vie maximum de ticket 1 jour
Biais d’horloge admissible 5 minutes
Adresses vides Admis
proxiable, etc. Admis
^
01 juillet 2014

htmlpdflatexmanmd




Kerberos - Formats

Kerberos - Formats

Formats et données diverses

Format de temps supportés

   Le format time_duration est utilisé pour exprimé une durée de temp dans les fichiers de configuration Kerberos est les commandes utilisateur. Les formats permis sont:

Format____Exemple____valeure
h:m[:s]___36:00______36 hours
NdNhNmNs__8h30s______8 hours 30 seconds
N_________3600_______1 hour

   Note: l'interval de temps ne devrait pas excéder 2147483647 secondes.

   Le format getdate_time spécifie une date. Les formats permis sont:


Date___________mm/dd/yy______07/27/12
_______________month dd, yyyy_Jul 27, 2012
_______________yyyy-mm-dd____2012-07-27
Absolute time__HH:mm[:ss]pp__08:30 PM
_______________hh:mm[:ss]____20:30
Relative time__N tt__________30 sec
Time zone______Z_____________EST
_______________z_____________-0400

   Le format absolute_time, rarement utilisé peut être noté selon un des formats suivants:

Format__________________Example_______________Value
yyyymmddhhmmss__________20141231235900________One minute before 2015
yyyy.mm.dd.hh.mm.ss_____2014.12.31.23.59.00
yymmddhhmmss____________141231235900
yy.mm.dd.hh.mm.ss_______14.12.31.23.59.00
dd-month-yyyy:hh:mm:ss__31-Dec-2014:23:59:00
hh:mm:ss________________20:00:00______________8 o’clock in the evening

Types de chiffrement

   Kerberos peut utiliser divers algorithmes de chiffrement pour protéger des données. Un type de chiffrement Kerberos est une combinaison spécifique d'un algorithme de chiffrement avec un algorithme d'intégrité pour fournir la confidentialité et l'intégrité des données. Les clients effectuent 2 types de demandes (KDC-REQ) au KDC: AS-REQ et TGS-REQ. Le client utilise l'AS-REQ pour obtenir des tickets initiaux ( appelés TGT ), et utilisent TGS-REQ pour obtenir des tickets de service. Le KDC utilise 3 types de clé différentes en fournissant un ticket au client.

La clé long-terme du service: Le KDC l'utilise pour chiffrer le ticket de service actuel. Le KDC utilise la première clé long-terme dans le kvno le plus récent.
La clé de session: Le KDC choisis aléatoirement cette clé et place une copie dans le ticket et une autre copie dans la partie chiffrée de la réponse.
La clé de chiffrement de réponse: Le KDC l'utilise pour chiffrer la réponse qu'il envoie au client. Pour les réponses AS, c'est une clé long-terme du client. Pour les réponses TGS, c'est soit la clé de session du ticket authentifiant, ou une clé de sous-session.

   Chaque type de demande permet au client d'envoyer une liste de type de chiffrement qu'il accepte. Pour AS-REQ, cette liste affecte la sélection de la clé de session et la clé de chiffrement de la réponse. Pour TGS-REQ, cette liste affecte uniquement la sélection de la clé de session.

   Compatibilité des types de chiffrement:
   des-cbc-crc_____________weak____all_____›=2000
   des-cbc-md5_____________weak____all__ __›=2000
   arcfour-hmac____________ _______›=1.3___›=2000
   aes128-cts-hmac-sha1-96_ _______›=1.3___›=Vista
   camellia128-cts-cmac____ _______›=1.9___none

Variables d'environnement

KRB5_CONFIG Spécifie l'emplacement de krb5.conf
KRB5_KDC_PROFILE Spécifie l'emplacement de kdc.conf
KRB5_KTNAME Fichier keytab par défaut
KRB5_CLIENT_KTNAME Fichier keytab client par défaut
KRB5CCNAME fichier du cache d'accréditifs par défaut, sous la forme type:residual
KRB5RCACHETYPE Type de cache replay par défaut. (défaut: dfl) none pour le désactiver
KRB5RCACHEDIR Répertoire du cache replay par défaut.
KPROP_PORT port kprop à utiliser. Défaut: 754
KRB5_TRACE Fichier pour les logs.
^
30 juin 2014

htmlpdflatexmanmd




sclient

sclient

Application client exemple

   sclient est une application d'exemple, principalement pour des tests. Il contacte un serveur d'exemple, sserver, et s'authentifie en utilisant un ticket Kerberos, puis affiche la réponse du serveur.

^
30 juin 2014

htmlpdflatexmanmd




kvno

kvno

Acquière un ticket de service pour les principaux spécifiés et affiche les numéros de version de clé pour chaque.

OPTIONS

-c ccache Spécifie le nom du cache d'accréditifs à utiliser
-e etype Spécifie le enctype à demander pour la clé de session de tous les services nommés.
-q Mode silencieux en cas de réussite.
-P Spécifie que les arguments service1 service2 ... sont interprétés comme noms d'hôte, et les principaux de service sont à construire depuis ces nom et le nom de service sname. Les noms d'hôte de service seront canonisés en accord avec les règles pour construire les principaux de service.
-U for_user Spécifie que S4U2Self est utilisé pour obtenir un ticket pour for_user. Si la délégation de contraintes n'est pas requise, le nom de service doit matcher le cache d'accréditifs du principal du client.

Variable d'environnement

KRB5CCNAME peut contenir un nom de cache d'autorisations Kerberos5

fichiers

DEFCCNAME Emplacement par défaut pour le cache d'accréditifs Kerberos 5
^
30 juin 2014

htmlpdflatexmanmd




kswitch

kswitch

Spécifier le cache primaire dans une collection

OPTIONS

-c cachename Spécifie le cache d'accréditifs à rendre primaire
-p principal Recherche un cache contenant des accréditifs pour le principal, dans la collection.

Variable d'environnement

KRB5CCNAME peut contenir un nom de cache d'autorisations Kerberos5

fichiers

DEFCCNAME Emplacement par défaut pour le cache d'accréditifs Kerberos 5
^
30 juin 2014

htmlpdflatexmanmd




krb5-config

krb5-config

Indique quels flags utiliser pour compiler et lier les programmes avec Kerberos

   Krb5-config indique au programmeur d'application quels flags utilisés pour compiler et linker les programmes avec les librairies Kerberos installées.

OPTIONS

--all Affiche la version, vendeur, préfixe, et exec-prefix
--version Affiche le numéro de version de Kerberos
--vendor Affiche le nom du vendeur de l'installation Kerberos
--prefix Affiche le préfixe pour lequel l'installation Kerberos a été construite
--exec-prefix Affiche le préfixe pour les exécutables pour lequel l'installation Kerberos a été construite
--defccname Affiche l'emplacement du cache d'accréditifs par défaut.
--defktname Affiche l'emplacement du keytab par défaut
--defcktname Affiche l'emplacement du keytab client par défaut
--cflags Affiche les flags de compilation utilisés pour construire l'installation Kerberos
--libs [library] Affiche les options du compileur nécessaire pour linkerà la librairie spécifiée. les valeurs permises sont:

        krb5 Kerberos 5 applications (default)
        gssapi GSSAPI applications with Kerberos 5 bindings
        kadm-client Kadmin client
        kadm-server Kadmin server
        kdb Applications qui accèdent à la base Kerberos
^
30 juin 2014

htmlpdflatexmanmd




kpasswd

kpasswd

Changer le mot de passe d'un principal

   Cette commande est utilisée pour changer le mot de passe d'un principal. kpasswd demande d'abord le mot de passe actuel, puis demande à l'utilisateur de rentrer le nouveau mot de passe 2 fois. Si le principal est gouverné par une stratégie qui spécifie la longueur et/ou la complexité, le nouveau mot de passe doit se conformer à cette stratégie.

OPTIONS

principal Change le mot de passe pour le principal Kerberos. Sinon, kpasswd utilise le nom du principal depuis le ccache existant s'il y'en a un, sinon, le principal est dérivé de l'identité de l'utilisateur qui appel kpasswd.
^
30 juin 2014

htmlpdflatexmanmd




ksu

ksu

Version kerberisé de su

   ksu est une version Kerberisé du programme su qui a 2 objectifs: sécuriser les changements d'ID d'utilisateur réel et effctifs, et de pouvoir créer de nouveaux contextes de sécurité.

Authentification

   ksu opère en 2 phases: l'authentification et l'autorisation. Résoudre le nom du principal de la cible est la première étape de l'authentification. L'utilisateur peut soit spécifier sont nom de principal avec -n, ou un nom de principal par défaut sera assigné en utilisant l'heuristique. Le nom de l'utilisateur cible doit être le premier argument du ksu; si non spécifié, root est le défaut. Si . est spécifié, l'utilisateur cible sera l'utilisateur source, Si l'utilisateur source est root ou l'utilisateur cible est l'utilisateur source, aucune authentification est aucune autorisation ne sera effectuée. Sinon, ksu recherche un ticket Kerberos approprié dans le cache de la source.

   Ce ticket peut être soit pour un serveur final, ou un TGT pour le domaine du principal cible. Si le ticket pour le serveur final est déjà dans le cache, il est déchiffré et vérifié. S'il n'est pas dans le cache mais que le TGT l'est, le TGT est utilisé pour obtenir le ticket. Si aucun de cet tickets n'est présent, et ksu est compilé avec GET_TGT_VIA_PASSWD, l'utilisateur devra entrer son mot de passe qui sera ensuite utilisé pour obtenir un TGT. Si l'utilisateur est loggé à distance et n'a pas de canal sécure, le mot de passe peut être exposé. Si ni le ticket ni GET_TGT_VIA_PASSWD ne sont présent, l'authentification échoue.

Autorisation

   Cette section décris l'autorisation de l'utilisateur source quand ksu est appelé sans l'option -e.Une fois l'authentification réussie, ksu vérifie que le principal cible est autorisé pou accéder au compte cible. Dans le home de l'utilisateur cible, ksu tente d'accéder à .k5login et .k5users Pour vérifier les autorisations.

   Si le nom du principal cible est trouvé dans le .k5login, l'utilisateur source, est autorisé à accéder au compte cible. Sinon, ksu recherche le fichier .k5users. Si le nom de principal cible est trouvé sans commandes ou suivi uniquement par *, l'utilisateur source est autorisé. Si les 2 fichiers ne sont trouvés mais qu'aucune entrée appropriée pour le principal cible n'existe, l'accès est refusé. Si les 2 fichiers n'existent pas le principal aura accès au compte en accord avec la règle de mappage aname-›lname. Sinon l'autorisation échoue.

Exécution du shell cible

   Une fois l'autorisation réussie, ksu se comporte comme su. L'environnement n'est pas modifié sauf USER, HOME, et SHELL. Si l'utilisateur cible n'est pas root, USER est l'utilisateur cible. Sinon USER reste inchangé. La variable d'environnement KRB5CCNAME est définie au nom du cache de la cible. L'ID utilisateur réel et effectif sont changés à l'utilisateur cible. Une fois le shell terminé, ksu supprime le cache cible, sauf si -k.

Créer un nouveau contexte de sécurité

   ksu peut être utilisé pour créer un nouveau contexte de sécurité pour le programme cible ( soit le shell, soit la commande spécifiée avec -e). Le programme cible hérite d'un jeu d'accréditifs de l'utilisateur source. Par défaut, ce jeu inclue tous les accréditifs dans le cache source, plus tout type d'accréditifs obtenus durant l'authentification. L'utilisateur source est capable de limiter les accréditifs dans le jeu avec les options -z ou -Z. -z restreins la copie des tickets du cache source dans le cache cible aux seuls tickets où le client == le nom principal cible. -Z fournis à l'utilisateur cible un cache neuf, sans accréditifs. Noter que pour des raisons de sécurité, quand l'utilisateur source est root et l'utilisateur cible non-root, -z est le mode par défaut.

   Note: durant l'authentification, seul les tickets qui pourraient être obtenus sans fournir de mot de passe sont cachés dans le cache source.

OPTIONS

-n target_principal_name Spécifie un nom de principal cible. non spécifié, un nom de principal par défaut est assigné via les cas suivant:

        Cas 1: l'utilisateur source est non-root Si l'utilisateur cible est l'utilisateur source, le nom de principal par défaut est définis au principal par défaut du cache source. Si le cache n'existe pas, le nom de principal par défaut est target_user@local_realm. Si les utilisateurs source et cible sont différent et que .k5users et .k5login n'existent pas, le nom de principal est target_user_login_name@local_realm. Sinon, en commençant avec le premier principal listé ci-dessous, ksu vérifie si le principal est autorisé à accéder au compte cible et s'il y a un ticket pour ce principal dans le cache source.

                a. Principal par défaut du cache source
                b. target_user@local_realm
                c. source_user@local_realm

        Cas 2: l'utilisateur source est root Si l'utilisateur cible est non-root, le nom de principal par défaut est target_user@local_realm. Sinon, si le cache source existe, le nom est un principal par défaut du cache source. Si le cache source n'existe pas, le nom est root\@local_realm.

-c source_cache_name Spécifie le nom du cache source. Non spécifié, utilise KRB5CCNAME, ou définis à krb5cc_‹target uid›.(gen_sym()).
-k Ne supprime pas le cache cible à la sortie du shell ou de la commande.
-d mode debug
-z Restreins la copie de tickets du cache source dans le cache cible aux seuls tickets où client==le nom du principal cible.
-Z Ne copie aucun tickets du cache source dans le cache cible.
-q mode silencieux
-l lifetime (chaîne time_duration) Spécifie la durée de vie pour les tickets demandés. défaut 12 heures.
-r time (chaîne time_duration) spécifie l'option renewable à demander pour les tickets.
-p Spécifie que l'option proxiable devrait être demandé pour le ticket
-f Spécifie que l'option forwardable devrait être demandé pour le ticket
-e command [args ...] Exécute la commande spécifiée au lieu d'exécuter le shell cible.

           Le fichier .k5users a le format suivant: Une seul entrée par ligne qui peut être suivie par une liste de commandes que le principal est autorisé à exécuter. Un nom de principal suivi par un * signifie que l'utilisateur est autorisé à exécuter une commande. Ainsi, l'exemple suivant:

                jqpublic@USC.EDU ls mail /local/kerberos/klist
                jqpublic/secure@USC.EDU *
                jqpublic/admin@USC.EDU

           La première ligne autorise à exécuter ls, mail et klist. La deuxième ligne autorise à exécuter toute commande, et la troisième autorise uniquement à exécuter le shell cible, tout comme la deuxième ligne, mais pas la première.

-a args Spécifie les arguments à passer au shell cible. cette option peut être utilisé pour simuler l'option -e avec: -a -c[command [arguments]].

Instructions d'installation

   ksu peut être compilé avec les flags suivant:

GET_TGT_VIA_PASSWD Si aucun ticket approprié n'est trouvé dans le cache source, demande à l'utilisateur son mot de passe.
PRINC_LOOK_AHEAD Durant la résolution du nom de principal par défaut, permet à ksu de trouver les noms des principaux dans le fichier .k5users.
CMD_PATH Spécifie une liste de répertoires contenant les programmes que les utilisateur sont autorisés à exécuter (via le fichier .k5users)
HAVE_GETUSERSHELL Si l'utilisateur source est non-root, ksu insiste pour que le shell de l'utilisateur invoqué soit un shell légal.

   ksu devrait être possédé par root et avoir le set user bit mis.
^
30 juin 2014

htmlpdflatexmanmd




kinit

kinit

Obtenir un TGT initial

OPTIONS

-v mode verbeux
-l lifetime (Chaîne time_duration) Demande un ticket avec la durée de vie spécifiée (ex: kinit -l 5:30 ou kinit -l 5h30m).
-s start_time (Chaîne time_duration) Demande un ticket post-daté en spécifiant le délai avant que le ticket devienne valide.
-r renewable_life (Chaîne time_duration) Demande des tickets renouvelables, avec la durée de vie totale spécifiée.
-f Demande des tickets forwardable
-F Demande des tickets non-forwardable
-p Demande des tickets proxiable
-P Demande des tickets non-proxiable
-a Demande des tickets restreins aux adresses locales de l'hôte.
-A Demande des tickets non restreins pas des adresses
-C Demande la canonisation du nom du principal, et permet au KDC de répondre avec un principal client différent.
-E  Traite le nom du principal comme un nom d'entreprise
-v Demande que le TGT dans le cache ( avec le flag invalid ) soit passé au KDC pour validation.
-R Demande de renouveler le TGT.
-k [-i | -t keytab_file] Demande un ticket, obtenu depuis un clé dans le keytab de l'hôte. L'emplacement du keytab peut être spécifié avec -t, ou avec -i pour spécifier l'utilisation de keytab du client par défaut. Par défaut, un ticket d'hôte pour l'hôte local est requis, mais tout principal peut être spécifié. Sur le KDC, l'emplacement du keytab spécial KDB: peut être utilisé pour indiquer que kinit devrait ouvrir la base du KDC et rechercher la clé directement. Cela permet aux administrateur d'obtenir des tickets pour tous principal qui supporte l'authentification basé sur les clé.
-n  Demande un traitement anonyme.
-I input_ccache Spécifie le nom du cache d'accréditifs qui contient déjà un ticket. En obtenant ce ticket, si les informations d'obtention de ce ticket sont également présentes dans le cache, ces informations seront utilisées pour affecter l'obtention des nouveaux tickets, incluant les méthodes d'authentification auprès du KDC.
-T armor_ccachef Spécifie le nom du cache d'accréditifs qui contient déjà un ticket. Si supporté par le KDC, ce cache sera utilisé pour protéger la demande, empêchant les attaques par dictionnaire offline et permettant d'utiliser des mécanismes de pré-authentification additionnels.
-c cache_name Utilise le cache spécifié comme cache d'accréditifs au lieu du cache par défaut spécifié par la variable KRB5CCNAME
-S service_name Spécifie un nom de service alternatif à utiliser pour obtenir les tickets initiaux.
-X attribute[=value] Spécifie un attribut/valeur de pré-authentification interprété par les modules de pré-authentification. Les attributs reconnus par PKINIT sont les suivants:

        X509_user_identity=value Spécifie où trouver les informations d'identité X509 de l'utilisateur
        X509_anchors=value Spécifie où trouver les informations de validation X509
        flag_RSA_PROTOCOL[=yes] Spécifie l'utilisation de RSA au lieu de DH

Variables d'environnement

        KRB5CCNAME peut contenir un nom de cache d'autorisations Kerberos5

fichiers

DEFCCNAME Emplacement par défaut pour le cache d'accréditifs Kerberos 5
DEFKTNAME Emplacement par défaut pour le keytab de l'hôte local
^
30 juin 2014

htmlpdflatexmanmd




klist

klist

Lister les principaux et les tickets dans les caches

OPTIONS

-e  Affiche les types de chiffrements de la clé de session et du ticket pour chaque accréditif dans le cache, ou chaque clé dans le fichier keytab
-l Si une collection de cache est disponible, affiche un sommaire des caches présents dans la collection
-A Si une collection de cache est disponible, affiche le contenu de tous les caches présents dans la collection
-c Liste les tickets dans le cache d'accréditifs.
-f Affiche les flags présent dans les accréditifs, en utilisant les abréviations suivante:

        F Forwardable
        f forwarded
        P Proxiable
        p proxy
        D postDateable
        d postdated
        R Renewable
        I Initial
        i invalid
        H Hardware authenticated
        A preAuthenticated
        T Transit policy checked
        O Okay as delegate
        a anonymous

-s Mode silencieux
-a Affiche une liste d'adresses dans les accréditifs
-n  Affiche les adresses numériques au lieu des adresses reverse
-C Liste les données de configuration stockés dans le cache d'accréditifs quand klist les rencontre.
-k Liste les clés dans le keytab
-i avec -k, utilise le keytab du client par défaut au lieu du keytab acceptor, si aucun nom n'est donné.
-t Affiche l'heure d'entrée pour chaque entrée keytab
-K Affiche la valeur de clé de chiffrement dans chaque entrée keytab
-V Affiche la version de Kerberos et quitte.

Variables d'environnement

        KRB5CCNAME peut contenir un nom de cache d'autorisations Kerberos5

fichiers

DEFCCNAME Emplacement par défaut pour le cache d'accréditifs Kerberos 5
DEFKTNAME Emplacement par défaut pour le keytab de l'hôte local
^
30 juin 2014

htmlpdflatexmanmd




kdestroy

kdestroy

Supprimer les caches d'accréditifs

   kdestroy est un utilitaire pour supprimer des tickets d'autorisation Kerberos actifs en supprimant les caches d'accréditifs. Si le cache n'est pas spécifié, le cache par défaut est supprimé.

OPTIONS

-A Supprime tous les caches dans la collection, si une collection de cache est disponible
-q mode silencieux
-c cache_name Supprime le cache spécifié

Notes

   Le cache d'accréditifs par défaut peut varier entre les systèmes. Si la variable d'environnement KRB5CCNAME est définie, sa valeur est utilisée comme cache de tickets par défaut.

  Il est recommandé de placer la commande kdestroy dans le fichier .logout pour supprimer tous les tickets à la deconnexion.

Variable d'environnement

KRB5CCNAME peut contenir un nom de cache d'autorisations Kerberos5

fichiers

DEFCCNAME Emplacement par défaut pour le cache d'accréditifs Kerberos 5
^
29 juin 2014

htmlpdflatexmanmd




.k5identity

.k5identity

Liste de règles pour sélectionner un principal

   Ce fichier, qui réside dans le home d'un utilisateur, contient une liste de règle pour sélectionner un principal client basé sur le serveur accédé. Ces règles sont utilisée pour choisir un cache d'accréditifs dans la collection de cache quand c'est possible. Chaque ligne a la forme

  principal field=value

  Si le principal serveur rencontre toutes les contrainte de champ, le principal est choisi comme principal client. Les champs suivant sont reconnus:

realm Si le domaine du principal du serveur est connus, il est matché avec cette valeur, qui peut être un pattern en utilisant les wildcard shell.
service Si le serveur principal est un principal basé sur l'hôte, son composant service est matché avec la valeur, qui peut être un pattern en utilisant les wildcard shell.
host Si le principal du serveur est un principal basé sur l'hôte, son nom d'hôte est convertis en minuscule et matché avec la valeur, qui peut être un pattern en utilisant les wildcard shell.

   Si le principal du serveur matche plusieurs lignes dans ce fichier, le principal depuis le premier matche est utilisé. Si aucune ligne ne matche, les accréditifs seront sélectionnés d'une autre manière, tel que le realm heuristic ou le cache primaire courant.

L'exemple suivant sélectionne le principal client alice@KRBTEST.COM si le serveur principal est dans ce domaine, le principal alice/root@EXAMPLE.COM si l'hôte serveur est dans un sous-domaine, et le principal alice/mail@EXAMPLE.COM en accédant au service IMAP sur mail.example.com:
alice@KRBTEST.COM realm=KRBTEST.COM
alice/root@EXAMPLE.COM host=*.servers.example.com
alice/mail@EXAMPLE.COM host=mail.example.com service=imap

^
29 juin 2014

htmlpdflatexmanmd




.k5login

.k5login

Liste de principaux Kerberos

   Ce fichier réside dans le home de l'utilisateur, contenant une liste de principaux Kerberos. tous ceux ayant des tickets valide pour un principal dans ce fichier est autorisé à accéder à l'hôte avec l'UID de l'utilisateur dont ce fichier est dans son home. Une utilisation commune est de placer ce fichier dans le home de root, autorisant les administrateurs système à accéder en root à l'hôte via Kerberos.

Exemples

Supposons que l'utilisateur Alice a un fichier .k5login dans son répertoire home contenant la ligne suivante:
bob@FOOBAR.ORG
Celà permet à bob d'utiliser Kerberos tel que SSH, pour accéder au compte Alice, en utilisant les tickets Kerberos de bob.
Supposons qu'Alice est un administrateur système. Alice et les autres administrateurs auront leurs principaux dans le .k5login de root:
alice@BLEEP.COM
joeadmin/root@BLEEP.COM
Cela permet aux administrateurs de se logger en root avec leur tickets.
^
27 juin 2014

htmlpdflatexmanmd




sserver

sserver

Serveur de démonstration

   sserver et sclient sont de simples progammes client/serveur de démonstration. Quand sclient se connecte à sserver, il effectue une authentification Kerberos, et le serveur retourne le principal Kerberos qui a été utilisé. Le nom de service utilisé par sserver et sclient est sample. sserver nécessite que l'entrée sample/hostname.domain.name@REALM.NAME dans le keytab. Ce keytab est généré en utilisant le programme kadmin. L'option -S permet d'utiliser un keytab différent de celui par défaut.

   Vu que sample n'a normalement pas de port définis dans /etc/services, il faut généralement ajouter:

  sample 13135/tcp

  En utilisant sclient, il faut d'abord avoir une entrée dans la base Kerberos, en utilisant kadmin, et obtenir des tickets Kerbeors avec kinit.

Exemple de réponse en utilisant sclient:
sendauth succeeded, reply is:
reply len 32, contents:
You are nlgilman@JIMI.MIT.EDU

^
27 juin 2014

htmlpdflatexmanmd




k5srvutil

k5srvutil


Commandes

list Liste les clé dans un keytab
change Utilise le protocole kadmin pour mettre à jours les clés dans la base Kerberos avec des clés générées aléatoirement, et met à jours les clés dans le keytab. Si un numéro de version de clé ne matche pas le numéro de version dans la base, l'opération échoue. Les anciennes clés sont laissées dans le keytab pour que des tickets existant continuent à fonctionner. Si le flag -i est donné, k5srvutil demande confirmation avant de changer chaque clé. -e permet de spécifier les types de chiffrement et de salt.
delold Supprime les anciennes clé du keytab.
delete Supprime les clés dans le keytab, demande confirmation.

   k5srvutil utilise kadmin pour éditer le keytab.

OPTIONS

-i Demande confirmation pour chaque opération
-f filename Spécifie le fichier keytab
keysalts Spécifie les types de chiffrement et de salt à utiliser.
^
27 juin 2014

htmlpdflatexmanmd




ktutil

ktutil

Utilitaire de gestion de fichiers keytab

Commandes

list Affiche la keylist courante. Alias: l
read_kt keytab Lit le keytab Kerberos v5 dans la keylist courante. Alias: rkt
read_st srvtab Lis le srvtab Kerberos v4 dans la keylist courante. Alias: rst
write_kt keytab Écrit la keylist courant dans le keytab. Alias: wkt
write_st srvtab Écrit la keylist courant dans le srvtab. Alias: wst
clear_list Efface le keylist courante. Alias: clear
delete_entry supprime l'entrée dans le numéro de slot de la keylist courante. Alias: delent
add_entry {-key|-password} -p principal -k kvno -e enctype Ajoute un principal dans la keylist en utilisant une clé ou un mot de passe. Alias: addent
list_requests Affiche une liste des commande disponibles. Alias: lr,?
quit quitte. Alias: exit,q

Exemples


ktutil: add_entry -password -p alice@BLEEP.COM -k 1 -e
    aes128-cts-hmac-sha1-96
Password for alice@BLEEP.COM:
ktutil: add_entry -password -p alice@BLEEP.COM -k 1 -e
    aes256-cts-hmac-sha1-96
Password for alice@BLEEP.COM:
ktutil: write_kt keytab
ktutil:

^
27 juin 2014

htmlpdflatexmanmd




kproplog

kproplog

Affiche le contenu les logs de mise à jours de la base Kerberos

   kproplog affiche le contenu des logs de mise à jours du KDC sur la sortie standard. Il peut être utilisé pour garder une trace des mises à jours incrémental de la base principal. Le fichier de log contient les logs maintenus par le processus kadmind sur le serveur maître, et kpropd sur les serveurs esclaves. Quand une mise à jours se produit, elle est loggée dans ce fichier. kproplog nécessite un accès en lecture à ce fichier, il va afficher uniquement les mises à jours pour le KDC sur lequel il est lancé. Sans options, affiche un sommaire des logs. Si invoqué sur le maître, affiche uniquement un sommaire des mises à jours.

OPTIONS

-R Ré-initialise le fichier de log. Force une re-synchronisation complète. Si utilisé sur un esclave, il va tout synchroniser. Sur un maître, tous les esclaves vont demander une synchronisation complète.
-h Affiche un sommaire des logs. Inclus le numéro de version, l'état de la base, le nombre d'updates, le timestamp du premier et dernier update, et le numéro de version de la première et dernière entrée.
-e num Affiche le num dernières entrées dans le log.
-v Affiche les attributs individuels par update. Exemple de sortie générée pour une entrée:


Update Entry
    Update serial # : 4
    Update operation : Add
    Update principal : test@EXAMPLE.COM
    Update size : 424
    Update committed : True
    Update time stamp : Fri Feb 20 23:37:42 2004
    Attributes changed : 6
        Principal
        Key data
        Password last changed
        Modifying principal
        Modification time
        TL data

Variables d'environnement

KRB5_KDC_PROFILE Spécifie l'emplacement de kdc.conf
^
26 juin 2014

htmlpdflatexmanmd




kpropd

kpropd

Service d'écoute pour la propagation des bases Kerberos

   kpropd tourne sur un serveur esclave et écoute les demandes de mises à jours faites par le programme kprop. Si la propagation incrémentale est activé, il demande périodiquement les mises à jour au maître.

   Quand l'esclave reçoit une demande kprop du maître, kpropd accepte la base du KDC dump et le place dans un fichier, puis lance kdb5_util pour charger la base dumpée dans la base active utilisée par krb5kdc. Quand la propagation incrémentale n'est pas utilisée, kpropd est généralement invoqué par inetd en utilisant:

  kprop stream tcp nowait root /usr/local/sbin/kpropd kpropd

   kpropd peut également être lancé en tant que serveur autonome, il se met en tâche de fond et écoute sur le port 754 par défaut. Ce mode est requis pour la propagation incrémentale. La propagation incrémentale peut être activée avec iprop_enable dans kdc.conf. L'intervalle de propagation incrémentale est déterminé par iprop_slave_poll. Si l'esclave reçoit des mises à jours, kpropd met à jours son fichier de log avec toutes les mises à jours du maître. kproplog peut être utilisé pour voir un sommaire de ces logs. Si la propagation incrémentale est activée, le principal kiprop/slavehostname@REALM doit être présent dans le fichier keytab de l'esclave. kproplog peut être utilisé pour forcer une réplication complète si activé.

OPTIONS

-r realm Spécifie le domaine Kerberos
-f file Fichier à importer
-p Chemin du programme kdb5_util
-d mode debug
-P Port d'écoute
-a acl_file
Chemin du fichier d'acl

Variables d'environnement

KRB5_CONFIG Spécifie l'emplacement de krb5.conf
KRB5_KDC_PROFILE Spécifie l'emplacement de kdc.conf

Fichiers

kpropd.acl chaque entrée est une ligne contenant le principal d'un hôte depuis lequel la machine local va autoriser la propagation de la base Kerberos via kprop.
^
26 juin 2014

htmlpdflatexmanmd




kprop

kprop

Propage le dump de la base Kerberos

   kprop est utilisé pour propager un fichier de dump de la base Kerberos de manière sécurisé, depuis le serveur maître vers un esclave

OPTIONS

-r realm Spécifie le domaine Kerberos
-f file Fichier à propager
-P port Port à utiliser pour contacter le serveur kpropd sur l'hôte distant
-d mode debug
-s keytab Spécifie l'emplacement du fichier keytab

Variables d'environnement

KRB5_CONFIG Spécifie l'emplacement de krb5.conf
^
26 juin 2014

htmlpdflatexmanmd




krb5kdc

krb5kdc

Service d'authentification Kerberos et centre de distribution des clés

OPTIONS

-r realm Spécifie le domaine Kerberos
-d dbname Spécifie le nom sous lequel la base principale peut être trouvée. Ne s'applique pas aux base LDAP
-k keytype Spécifie le type de clé de la clé maître.
-M mkeyname Spécifie le nom du principal pour la clé maître dans la base.
-m Spécifie que le mot de passe maître de la base devrait être lu depuis le clavier au lieu d'un fichier sur disque.
-n  Spécifie que le KDC ne se place pas en tâche de fond.
-P pid_file PID du service
-p portnum Numéros de port UDP d'écoute. Liste séparé par "," Défaut 88,750
-w numworkers Fork le nombre de processus spécifié pour écouter et traiter en parallèle. Le processus parent agit comme superviseur et relai les signaux SIGHUP.

   Note: Sur les OS qui supportent pktinfo, utiliser les sous-processus empêche de KDC d'écouter les paquets UDP sur les interfaces créés après que le KDC ait démarré.

-x nconns=number_of_connections Spécifie le nombre de connexion à maintenir par serveur LDAP
-x host=ldapuri Spécifie le serveur LDAP à contacter
-x binddn=binddn Spécifie le DN de l'objet à utiliser par le serveur d'administration
-x bindpwd=bind_password Mot de passe du binddn
-x debug=level Définis le niveau de verbosité de la librairie cliente OpenLDAP
-T offset Spécifie un offset de temps, en secondes, pendant lequel le KDC va opérer.

Exemples

   Le KDC peut désservir jusqu'à 32 domaines. Les domaines sont listés sur la ligne de commande, les options par domaine peuvent être spécifiés avant chaque domaine:

  krb5kdc -p 2001 -r REALM1 -p 2002 -r REALM2 -r REALM3

Variables d'environnement

KRB5_CONFIG Spécifie l'emplacement de krb5.conf
KRB5_KDC_PROFILE Spécifie l'emplacement de kdc.conf
^
26 juin 2014

htmlpdflatexmanmd




kdb5_ldap_util

kdb5_ldap_util

Utilitaire de maintenance de la base LDAP de Kerberos

OPTIONS

-D user_dn DN de l'utilisateur pour les opérations sur le serveur
-w passwd Mot de passe de l'utilisateur
-H ldapuri URI du serveur LDAP à contacter.

Commandes

create [-subtrees subtree_dn_list] [-sscope search_scope] [-containerref container_reference_dn] [-k mkeytype] [-kv mkeyVNO] [-m|-P password|-sf stashfilename] [-s] [-r realm] [-maxtktlife max_ticket_life] [-maxrenewlife max_renewable_ticket_life] [ticket_flags] Crée un domaine dans l'annuaire.

        -subtrees subtree_dn_list Spécifie la liste des subtrees contenant les principaux d'un domaine, séparés par ":"
        -sscope search_scope Spécifie le scope de recherche pour les principaux sous le subtree (1 - onelevel, 2 - subtree)
        -containerref container_reference_dn DN du conteneur dans lequel les principaux d'un domaine seront créés.
        -k mkeytype Spécifie le type de clé de la clé maître dans la base.
        -kv mkeyVNO Spécifie le numéro de version de la clé maître dans la base; défaut: 1.
        -m Spécifie que le mot de passe maître de la base devrait être lu depuis le clavier au lieu d'un fichier sur disque.
        -P password Spécifie le mot de passe maître.
        -r realm Spécifie le domaine Kerberos
        -sf stashfilename Spécifie le fichier stash pour le mot de passe maître.
        -s Spécifie que le fichier stash est à créer
        -maxtktlife max_ticket_life (chaîne getdate_time) Spécifie la durée de vie max d'un ticket pour les principaux dans ce domaine
        -maxrenewlife max_renewable_ticket_life (chaîne getdate_time) Spécifie la durée de vie max renouvelable pour les principaux dans ce domaine
        ticket_flags Spécifie les flags global de ticket pour le domaine. voir kadmin add_principal.

Exemples
kdb5_ldap_util -D cn=admin,o=org -H ldaps://ldap-server1.mit.edu
    create -subtrees o=org -sscope SUB -r ATHENA.MIT.EDU
Password for "cn=admin,o=org":
Initializing database for realm 'ATHENA.MIT.EDU'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key:
Re-enter KDC database master key to verify:

modify [-subtrees subtree_dn_list] [-sscope search_scope] [-containerref container_reference_dn] [-r realm] [-maxtktlife max_ticket_life] [-maxrenewlife max_renewable_ticket_life] [ticket_flags] Modifie les attributs d'un domaine.

        -subtrees subtree_dn_list Spécifie la liste des subtrees contenant les principaux d'un domaine, séparés par ":"
        -sscope search_scope Spécifie le scope de recherche pour les principaux sous le subtree (1 - onelevel, 2 - subtree)
        -containerref container_reference_dn DN du conteneur dans lequel les principaux d'un domaine seront créés.
        -r realm Spécifie le domaine Kerberos
        -maxtktlife max_ticket_life (chaîne getdate_time) Spécifie la durée de vie max d'un ticket pour les principaux dans ce domaine
        -maxrenewlife max_renewable_ticket_life (chaîne getdate_time) Spécifie la durée de vie max renouvelable pour les principaux dans ce domaine
        ticket_flags Spécifie les flags global de ticket pour le domaine. voir kadmin add_principal.

Exemples
shell% kdb5_ldap_util -D cn=admin,o=org -H
    ldaps://ldap-server1.mit.edu modify +requires_preauth -r
    ATHENA.MIT.EDU
Password for "cn=admin,o=org":
shell%

view [-r realm] Affiche les attribut d'un domaine. -r spécfie le domaine Kerberos de la base

Exemples
kdb5_ldap_util -D cn=admin,o=org -H ldaps://ldap-server1.mit.edu
    view -r ATHENA.MIT.EDU
Password for "cn=admin,o=org":
Realm Name: ATHENA.MIT.EDU
Subtree: ou=users,o=org
Subtree: ou=servers,o=org
SearchScope: ONE
Maximum ticket life: 0 days 01:00:00
Maximum renewable life: 0 days 10:00:00
Ticket flags: DISALLOW_FORWARDABLE REQUIRES_PWCHANGE

destroy [-f] [-r realm] Supprime un domaine existant. -f ne demande pas confirmation, -r spécifie de domaine de la base.

Exemples
shell% kdb5_ldap_util -D cn=admin,o=org -H
    ldaps://ldap-server1.mit.edu destroy -r ATHENA.MIT.EDU
Password for "cn=admin,o=org":
Deleting KDC database of 'ATHENA.MIT.EDU', are you sure?
(type 'yes' to confirm)? yes
OK, deleting database of 'ATHENA.MIT.EDU'...
shell%

list Liste le nom des domaines

Exemples
shell% kdb5_ldap_util -D cn=admin,o=org -H
    ldaps://ldap-server1.mit.edu list
Password for "cn=admin,o=org":
ATHENA.MIT.EDU
OPENLDAP.MIT.EDU
MEDIA-LAB.MIT.EDU
shell%

stashsrvpw [-f filename] servicedn Permet à un administrateur de stocker un mot de passe pour un objet service dans un fichier pour que le KDC et le serveur d'administration puissent l'utiliser pour s'authentifier auprès du serveur LDAP. -f filename est le chemin complet du fichier, servicedn est le DN de l'objet service.

Exemples
kdb5_ldap_util stashsrvpw -f /home/andrew/conf_keyfile
    cn=service-kdc,o=org
Password for "cn=service-kdc,o=org":
Re-enter password for "cn=service-kdc,o=org":

create_policy [-r realm] [-maxtktlife max_ticket_life] [-maxrenewlife max_renewable_ticket_life] [ticket_flags] policy_name Crée une stratégie de ticket dans l'annuaire.

        -r realm Spécifie le domaine Kerberos
        -maxtktlife max_ticket_life (chaîne getdate_time) Spécifie la durée de vie max d'un ticket pour les principaux dans ce domaine
        -maxrenewlife max_renewable_ticket_life (chaîne getdate_time) Spécifie la durée de vie max renouvelable pour les principaux dans ce domaine
        ticket_flags Spécifie les flags global de ticket pour le domaine. voir kadmin add_principal.
        policy_name Nom de la stratégie de ticket

Exemples
kdb5_ldap_util -D cn=admin,o=org -H ldaps://ldap-server1.mit.edu
    create_policy -r ATHENA.MIT.EDU -maxtktlife "1 day"
    -maxrenewlife "1 week" -allow_postdated +needchange
    -allow_forwardable tktpolicy
Password for "cn=admin,o=org":

modify_policy [-r realm] [-maxtktlife max_ticket_life] [-maxrenewlife max_renewable_ticket_life] [ticket_flags] policy_name Modifie les atributs d'une stratégie de ticket. Les options sont les même que pour create_policy

Exemples
kdb5_ldap_util -D cn=admin,o=org -H
    ldaps://ldap-server1.mit.edu modify_policy -r ATHENA.MIT.EDU
    -maxtktlife "60 minutes" -maxrenewlife "10 hours"
    +allow_postdated -requires_preauth tktpolicy
Password for "cn=admin,o=org":

view_policy [-r realm] policy_name Affiche les attributs d'une stratégie de ticket. policy_name est le nom de la stratégie

Exemples
kdb5_ldap_util -D cn=admin,o=org -H ldaps://ldap-server1.mit.edu
    view_policy -r ATHENA.MIT.EDU tktpolicy
Password for "cn=admin,o=org":
Ticket policy: tktpolicy
Maximum ticket life: 0 days 01:00:00
Maximum renewable life: 0 days 10:00:00
Ticket flags: DISALLOW_FORWARDABLE REQUIRES_PWCHANGE

destroy_policy [-r realm] [-force] policy_name Détruit une stratégie de ticket. -force ne demande pas confirmation.

Exemples
kdb5_ldap_util -D cn=admin,o=org -H ldaps://ldap-server1.mit.edu
    destroy_policy -r ATHENA.MIT.EDU tktpolicy
Password for "cn=admin,o=org":
This will delete the policy object 'tktpolicy', are you sure?
(type 'yes' to confirm)? yes
** policy object 'tktpolicy' deleted.

list_policy [-r realm] Liste les stratégie de ticket dans le domaine.

Exemples
kdb5_ldap_util -D cn=admin,o=org -H ldaps://ldap-server1.mit.edu
    list_policy -r ATHENA.MIT.EDU
Password for "cn=admin,o=org":
tktpolicy
tmppolicy
userpolicy

^
25 juin 2014

htmlpdflatexmanmd




kdb5_util

kdb5_util

Utilitaire de maintenance de la base Kerberos

   kdb5_util permet à un administrateur d'effectuer des procédures de maintenance dans la base Kerberos. Les base peuvent être crées, détruites, et dumpé/chargé vers/depuis un fichier. kdb5_util peut créer un fichier stash pour le clé maître Kerberos. Quand kdb5_util est lancé, il tente de récupérer la clé maître et d'ouvrir la base. Cependant, l'exécution continue sans s'occuper de savoir s'il a réussi, parce que la base peut ne pas exister ou le fichier stash peut être corrompus. Noter que certains module KDC ne supportent pas cette commande.

OPTIONS

-r realm Spécifie le domaine Kerberos
-d dbname Spécifie le nom de la base de données Kerberos principale.
-k mkeytype Spécifie le type de clé de la clé maître dans la base.
-kv mkeyVNO Spécifie le numéro de version de la clé maître dans la base; défaut: 1.
-M mkeyname Nom du principal pour la clé maître dans la base,
-m Spécifie que le mot de passe maître de la base devrait être lu depuis le clavier au lieu d'un fichier sur disque.
-sf stash_file Spécifie le fichier stash pour le mot de passe maître.
-P password Spécifie le mot de passe maître.

Commandes

create [-s] Crée une nouvelle base de données. -s créé également le fichier stash.
destroy [-f] Supprime une base de données. -f ne demande pas confirmation à l'utilisateur.
stash [-f keyfile] Stocke la clé du principal maître dans un fichier stash. -f écrase le keyfile dans kdc.conf
dump [-b7|-ov|-r13] [-verbose] [-mkey_convert] [-new_mkey_file mkey_file] [-rev] [-recurse] [filename [principals...]] Dumps la base courante et la base KADM5 dans un fichier ASCII. Par défaut, la base est dumpé dans le format courant.

        -b7 Dump dans le format Kerberos 5 beta 7
        -ov Dump au format ovsec_adm_export
        -r13 Dump au format Kerberos 5 1.3.
        -r18 Dump au format Kerberos 5 1.8.
        -verbose Affiche le nom de chaque principal et stratégie tel que dumpés
        -mkey_convert Demande pour une nouvelle clé maître. Cette clé est utilisé pour re-chiffrer la clé principal dans le dump
        -new_mkey_file mkey_file Nom du fichier stash.
        -rev dump dans l'ordre inverse. Permet de récupérer des principaux qui ne se dump pas normalement.
        -recurse Dump la base récursivement.

load [-b7|-ov|-r13] [-hash] [-verbose] [-update] filename [dbname] Charge un dump dans la base. Sans option pour déterminer le format du dump, le format est détecté automatiquement. Sauf avec l'option -udpate, load créé une nouvelle base contenant uniquement les données dans le dump.

        -b7 Spécifie que le dump est au format Kerberos 5 Beta 7
        -ov Spécifie que le dump est au format ovsec_adm_import
        -r13 Spécifie que le dump est au format Kerberos 5 1.3
        -r18 Spécifie que le dump est au format Kerberos 5 1.8
        -hash La base est stockée comme hash. Non spécifiée, la base est stockée comme un btree. Non recommandé.
        -verbose Affiche le nom de chaque principal et stratégie tel que dumpés
        -update Ajoute le dump à une base existante.

ark [-e enc:salt,...] principal Ajoute de nouvelles clé aléatoire au principal. -e spécifie la liste de type de chiffrement et de salt à utiliser.
add_mkey [-e etype] [-s] Ajoute une nouvelle clé maître, mais ne la marque par active. -e spécifie la liste de type de chiffrement et de salt à utiliser. -s place la clé dans le fichier stash (créé s'il n'existe pas)
use_mkey mkeyVNO [time] Définis le temps d'activation de la clé maître spécifiée par mkeyVNO. Une fois une clé maître active, elle sera utilisé comme nouvelle clé principal. si time n'est pas spécfié, l'heure courante est utilisée. time est au format getdate_time
list_mkeys Liste toutes les clés maître, de la plus récente à la plus ancienne.
purge_mkeys [-f] [-n] [-v] Supprime les clé maître non utilisée pour protéger un principal.

        -f Ne demande pas confirmation
        -n  Dry run, affiche les clé maître qui serait supprimées, mais ne les supprime pas.
        -v mode verbeux

        update_princ_encryption [-f] [-n] [-v] [princ-pattern] Met à jours les enregistrements de principal (ou ceux qui matchent le princ-pattern) pour re-chiffrer le clés en utilisant la clé maître active, si elle sont chiffrée en utilisant une autre version, et donne un compteur du nombre de principaux mis à jours. -f ne demande pas confirmation. -v traite chaque principal listé. -n simule l'action.
^
25 juin 2014

htmlpdflatexmanmd




kadmind

kadmind

Serveur d'administration Kerberos

   kadmind lance le serveur d'administration Kerberos. kadmind est généralement lancé sur le serveur maître. Si la base du KDC utilise le module LDAP, le serveur d'administration et le KDC n'ont pas besoin d'être sur la même machine. kadmind accepte les demandes distantes depuis les programmes kadmin et kpasswd pour administrer les informations dans la base.

   Une fois le serveur lancé, il se place lui-même en tâche de fond. kadmind peut être configuré pour la propagation incrémentale de la base, qui permet aux esclaves de recevoir les principaux et les stratégie incrémentalement au lieu d'un dump complet. La propagation incrémentale nécessite le principal kiprop/MASTER\@REALM où MASTER est le nom d'hôte canonique du KDC maître et REALM est le domaine.

OPTIONS

-r realm Spécifie le domaine Kerberos
-m Demande le mot de passe maître au lieu d'un fichier sur le disque.
-nofork Ne met pas le serveur en tâche de fond
-port port-number Port d'écoute du serveur
-P pid_file Spécifie le PID du processus
-p kdb5_util_path Spécifie de chemin de la commande kdb5_util pour dumper le KDC en réponse à une re-synchronisation complète que iprop est activé
-K kprop_path Spécifie le chemin vers la commande kprop pour envoyer des dumps complets en réponse à une re-synchonisation complète.
-F dump_file Spécifie le chemin à utiliser pour dumper le KDB en réponse à une re-synchonisation complète
-x db_args Spécifie les argument spécfique à la base.

        -x nconns=number_of_connections Spécifie le nombre de connexion à maintenir par serveur LDAP
        -x host=ldapuri Spécifie le serveur LDAP à contacter
        -x binddn=binddn Spécifie le DN de l'objet à utiliser par le serveur d'administration
        -x bindpwd=bind_password Mot de passe du binddn
        -x debug=level Définis le niveau de verbosité de la librairie cliente OpenLDAP
^
25 juin 2014

htmlpdflatexmanmd




kadmin

kadmin

Interface CLI pour l'administration de Kerberos

   kadmin et kadmin.local sont des interfaces en ligne de commande pour le système d'administration de Kerberos. Ils fonctionnent de manière similaire à l'exception que kadmin.local communique directement avec le fichier de base de données.

   Le client distant kadmin utilise Kerberos pour s'authentifier auprès de kadmind en utilisant le principal de service kadmin/ADMINHOST, où ADMINHOST est le fqdn du serveur d'administration, ou kadmin/admin. Si le cache d'accréditifs contient un ticket pour un de ces principaux, et que l'option -c est spécifié, ce ticket est utilisé pour s'authentifier à kadmind. Sinon les options -p et -k sont utilisés pour spécifier le nom du principal client utilisé pour s'authentifier. Une fois que kadmin a déterminé le nom du principal, il demande un ticket de service au KDC, et l'utilise pour s'authentifier à kadmind.

OPTIONS

-r realms Utilise de domaine spécifié par défaut
-p principal Utilise le principal spécifié pour s'authentifier. Sinon, kadmin va ajouter /admin au nom de principal primaire du ccache par défaut, la valeur de la variable d'environnement USER, ou le username obtenu par getpwuid, dans cet ordre.
-k Utilise un keytab pour déchiffrer la réponse du KDC au lieu de demander un mot de passe. Dans ce cas, le principal par défaut sera host/hostname. S'il n'y a par de keytab spécifié avec l'option -t, le keytab par défaut sera utilisé.
-t keytab Utilise keytab pour déchiffrer la réponse du KDC. Peut seulement être utilisé avec l'option -k
-n  Demande un traitement anonyme. 2 types de principaux anonyme sont supportés. Pour l'anonymité complète, configurer PKINIT et utiliser l'option -n avec un principal sous la forme @REALM. Si permis par le KDC, un ticket anonyme sera retourné. Une seconde forme est supportée, et cache l'identité du client mais pas le domaine du client. Pour ce mode, utiliser kinit -n avec un principal normal. Si supporté par le KDC, le principal, mais pas le domaine, sera remplacé par le principal anonymous.
-c credentials_cache Utile de cache d'accréditifs spécifié. Le cache devrait contenir un ticket de service pour kadmin/ADMINHOST ou kadmin/admin. Si non spéifié, kadmin demande un nouveau ticket au KDC et le stocke dans son propre cache temporaire.
-w password Utilise le mot de passe au lieu de le demander
-q query Effectue le requête spécifiée et quitte.
-d dbname Spécifie le nom de la base KDC. Ne s'applique par au module de base LDAP
-s admin_server[:port] Spécifie le serveur d'administration à contacter
-m Avec kadmin.local, demande le mot de passe maître de la base au lieu de chercher un fichier stash
-e “enc:salt...” Définis la liste keysalt à utiliser pour toute nouvelle clé créée.
-O Force l'utilisation de l'ancienne authentification AUTH_GSSAPI
-N Empêche l'utilisation de l'ancienne authentification AUTH_GSSAPI
-x db_args Spécifie les arguments spécifique à la base. les options supportée pour le module de base LDAP sont:

        -x host=hostname Spécifie le serveur LDAP à contacter
        -x binddn=bind_dn DN de l'objet à utiliser par le serveur d'administration pour le bind ldap.
        -x bindpwd=bind_password Mot de passe pour le binddn
        -x debug=level Niveau de verbosité pour le client OpenLDAP.

Commandes

   En utilisant le client distant, les commandes disponible peuvent être restreins en accord avec les privilèges dans kadm5.acl.

add_principal

   Crée le principal spécifié, en demandant 2 fois le mot de passe. Si aucune stratégie de mot de passe n'est spécifiée, la stratégie nommée default est assignée au principal si elle existe. Cependant, créer une stratégie default ne va pas assigner automatiquement ce stratégie aux principaux déjà existant. Cette stratégie peut être supprimée avec l'option -clearpolicy

        -expire expdate (chaîne getdate_time) Date d'expiration du principal
        -pwexpire pwexpdate (chaîne getdate_time) Date d'expiration du mot de passe
        -maxlife maxlife (chaîne getdate_time) Durée de vie de ticket max pour le principal
        -maxrenewlife maxrenewlife (chaîne getdate_time) Durée de vie de renouvellement max des tickets
        -kvno kvno Numéro de version de clé initial
        -policy policy Stratégie de mot de passe utilisé par ce principal.
        -clearpolicy Empêche l'assignation automatique d'une stratégie si non spécifiée par -policy
        {-|+}allow_postdated Droit d'obtenir des tickets post-datés
        {-|+}allow_forwardable Droit d'obtenir des tickets forwardable
        {-|+}allow_renewable Droit d'obtenir des tickets renouvelable
        {-|+}allow_proxiable Droit d'obtenir des tickets proxiable
        {-|+}allow_dup_skey Droit d'effectuer une authentification user-to-user
        {-|+}requires_preauth force le principal à ce pré-authentifier
        {-|+}requires_hwauth Utiisation d'un hardware pour la pré-authentification
        {-|+}ok_as_delegate flag okay as delegate dans les tickets fournis avec ce principal en tant que service.
        {-|+}allow_svr Droit de délivrer des tickets de service pour ce principal
        {-|+}allow_tgs_req Droit d'obtenir un TGS pour un ticket de service pour ce principal
        {-|+}allow_tix Droit d'obtenir un ticket pour ce principal
        {-|+}needchange Force le changement de mot de passe à la prochaine authentification
        {-|+}password_changing_service Marque ce principal comme principal de service de changement de mot de passe
        {-|+}ok_to_auth_as_delegate Droit d'obtenir des tickets forwardable à soi-même depuis des utilisateurs arbitraires
        {-|+}no_auth_data_required Droit d'ajouter des données PAC ou AD-SIGNEDPATH
        -randkey Définis la clé du principal à une valeur aléatoire
        -nokey Crée un principal sans clé
        -pw password Définis de mot de passe pour ce principal
        -e enc:salt,... Utilise la liste de keysalt pour les clés de ce principal.
        -x db_princ_args Options spécifique à la base:

                -x dn=dn Spécifie l'objet LDAP qui va contenir le principal Kerberos à créer
                -x linkdn=dn Spécifie l'objet LDAP pour lequel le nouveau principal Kerberos va pointer
                -x containerdn=container_dn Spécifie le conteneur sous lequel le principal Kerberos est créé
                -x tktpolicy=policy Associe une stratégie de ticket au principal Kerberos

Note

   Les options containerdn et linkdn ne peuvent pas être spécifiés avec l'option dn. Si ces options ne sont pas spécifiées, les principaux sont créés sous le conteneur principal configurés dans le domaine. Ces options devraient pointer dans les sous-arborescences ou le conteneur principal configurés dans le domaine.

Exemple
kadmin: addprinc jennifer
WARNING: no policy specified for "jennifer@ATHENA.MIT.EDU";
defaulting to no policy.
Enter password for principal jennifer@ATHENA.MIT.EDU:
Re-enter password for principal jennifer@ATHENA.MIT.EDU:
Principal "jennifer@ATHENA.MIT.EDU" created.
kadmin:

modify_principal

   Modifie le principal spécifié, en changeant les champs spécifiés. Les options de add_principal s'appliquent également à cette commande, excepté -randkey, -pw et -e. Cette commande nécessite les privilège modify. Alias: modprinc

        -unlock Débloque un principal.

rename_principal

   Renomme l'ancien principal avec le nouveau principal. Demande configuration sauf si -force est donné. Nécessite les privilèges add et delete. Alias: renprinc

delete_principal

   Supprime le principal spécifié de la base. emande configuration sauf si -force est donné. Nécessite les privilèges delete. Alias: delprinc

change_password

   Change le mot de passe du principal. Demande un nouveau mot de passe si -randkey ou -pw ne sont pas spécifiés. Nécessite les privilège changepw, ou que le principal qui lance ce programme est le même que le principal à changer. Aliar: cpw

        -randkey Définis la clé du principal à une valeur aléatoire
        -pw password Définis de mot de passe pour ce principal
        -e enc:salt,... Utilise la liste de keysalt pour les clés de ce principal.
        -keepold Conserve les clés existantes dans la base.

Exemple
kadmin: cpw systest
Enter password for principal systest@BLEEP.COM:
Re-enter password for principal systest@BLEEP.COM:
Password for systest@BLEEP.COM changed.
kadmin:

purgekeys

   Purge les anciennes clé du principal. Si -keepkvno est spécifié, alors seul les clés avec des kvno inférieur sont purgés. Si -all est spécifié, purge toutes les clés. Nécessite le privilège modify

get_principal

   Récupère les attributs du principal. L'option -terce affiche les champs en tant que chaîne séparés par des tabulations. Nécessite le privilège inquire, ou que le principal utilisant le programme soit le même que le principal cible. Alias: getprinc

Exemple
kadmin: getprinc tlyu/admin
Principal: tlyu/admin@BLEEP.COM
Expiration date: [never]
Last password change: Mon Aug 12 14:16:47 EDT 1996
Password expiration date: [none]
Maximum ticket life: 0 days 10:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Mon Aug 12 14:16:47 EDT 1996 (bjaspan/admin@BLEEP.COM)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 2
Key: vno 1, DES cbc mode with CRC-32, no salt
Key: vno 1, DES cbc mode with CRC-32, Version 4
Attributes:
Policy: [none]
    
kadmin: getprinc -terse systest
systest@BLEEP.COM 3 86400 604800 1
785926535 753241234 785900000
tlyu/admin@BLEEP.COM 786100034 0 0
kadmin:

list_principal

   Récupère des noms de principal. L'expression est une expression glob qui peut contenir les caractères *, ? et []. Tous les noms de principaux qui matche l'expression sont affichés. Sans expression, liste tous les principauix. Si l'expression ne contient pas un caractère @, ce caractère est ajouté avec le domaine local à l'expression. Nécessite le privilège list. Alias: listprincs, get_principals, get_princs

Exemple
kadmin: listprincs test*
test3@SECURE-TEST.OV.COM
test2@SECURE-TEST.OV.COM
test1@SECURE-TEST.OV.COM
testuser@SECURE-TEST.OV.COM
kadmin:

get_strings

   Affiche les attributs chaîne dans le principal. Nécessite le privilège inquire. Alias: getstr

set_strings

   Définis un attribut chaîne dans le principal. Les attributs chaîne sont utilisés pour fournir une configuration par principal au KDC et certaine modules du KDC. Nécessite le privilège modify. Alias setstr. Les attributs suivants sont reconnus par le KDC:

        session_enctypes Spécifie les types de chiffrement supportés pour les clés session quand le principal est authentifié en tant que serveur.

del_strings

   Supprime un attribut chaîne du principal. Nécessite le privilège delete. Alias: delstr

add_policy

   Ajoute une stratégie de mot de passe à la base. Nécessite le privilège add. Alias: addpol

        -maxlife time (chaîne getdate_time) Définis la durée de vie max d'un mot de passe
        -minlife time (chaîne getdate_time) Définis la durée de vie min d'un mot de passe
        -minlength length Définis la longueur maximum d'un mot de passe
        -minclasses number Définis le nombre minimum de classes de caractères requis dans un mot de passe. Les 5 classes sont: minuscule, majuscule, nombres, ponctuation et espaces blancs.
        -history number Définis le nombre de clé à conserver pour un principal. Non supporté avec le module LDAP
        -maxfailure maxnumber Définis le nombre d'échec d'authentification avant que le principal soit bloqué. 0 le désactive.
        -failurecountinterval failuretime (chaîne getdate_time) Définis le temps permis entre les échecs d'authentification.
        -lockoutduration lockouttime (chaîne getdate_time) Définis la durée pour lequel le principal est bloqué. 0 signifie que le compte est bloqué jusqu'à ce qu'un administrateur le débloque.
        -allowedkeysalts Spécifie les tuples key/salt supportés pour les clés à long terme en définissant ou en changeant un mot de passe de principal. Les tuples doivent être séparés par une virgule. Pour enlever le tuple de la stratégie, utiliser "-"

Exemple
kadmin: add_policy -maxlife "2 days" -minlength 5 guests
kadmin:

modify_policy

   Modifie la stratégié de mot de passe spécifiée. Les options sont les même que pour add_policy. Nécessite le privilège modify. Alias: modpol

delete_policy

   Supprime la stratégie de mot de passe spécifiée. Demande confirmation. Échoue si la stratégie est utilisée par un principal. Nécessite le privilège delete. Alias: delpol

Exemple
kadmin: del_policy guests
Are you sure you want to delete the policy "guests"?
(yes/no): yes
kadmin:

get_policy

   Affiche les valeurs de la stratégie spécifiées. -terse affiche les champs séparés par des tabulations. Nécessite le privilège inquire. Alias: getpol

Exemple
kadmin: get_policy admin
Policy: admin
Maximum password life: 180 days 00:00:00
Minimum password life: 00:00:00
Minimum password length: 6
Minimum number of password character classes: 2
Number of old keys kept: 5
Reference count: 17
    
kadmin: get_policy -terse admin
admin 15552000 0 6 2 5 17
kadmin:

list_policies

   Liste des stratégie basée sur l'expression. Nécessite le privilège list. Alias: listpols, get_policies, getpols

Exemple
kadmin: listpols
test-pol
dict-only
once-a-min
test-pol-nopw
    
kadmin: listpols t*
test-pol
test-pol-nopw
kadmin:

ktadd

   Ajoute un principal, ou tous les principaux matchant l'expression de l'option glob, à chaque fichier keytab. Chaque clé de principal est randomisé dans le processus. Nécessite les privilèges inquire et changepw. pour utiliser -glob, nécessite le privilège list.

        -k[eytab] keytab Utilise le fichier keytab spécifié
        -e enc:salt,... Utilise la liste keysalt spécifiée
        -q mode silencieux
        -norandkey Ne randomise pas les clé. Ne peut pas être utilisé avec -e.

Exemple
kadmin: ktadd -k /tmp/foo-new-keytab host/foo.mit.edu
Entry for principal host/foo.mit.edu@ATHENA.MIT.EDU with kvno 3,
    encryption type aes256-cts-hmac-sha1-96 added to keytab
    FILE:/tmp/foo-new-keytab
kadmin:

ktremove

   Supprime des entrées pour le principal spécifié du keytab. Ne nécessite aucune permission. Si all est spéficié, toutes les entrées pour le principal sont supprimés; si old est spécifié, toutes les entrée sauf le kvno le plus récent sont supprimés. Si kvno est spécifié, supprime les entrées avec ce kvno.

        -k[eytab] keytab Utilise le fichier keytab spécifié
        -q mode silencieux

Exemple
kadmin: ktremove kadmin/admin all
Entry for principal kadmin/admin with kvno 3 removed from keytab
    FILE:/etc/krb5.keytab
kadmin:

lock

   Bloque la base. Ne fonctionne qu'avec le module DB2

unlock

   Réactive la base après un lock

list_requests

   Liste les demandes kadmin disponible. Alias lr, ?

quit

   Quitte le programme. Alias exit,q
^
20 juin 2014

htmlpdflatexmanmd




kadm5.acl

kadm5.acl

Fichier acl pour kadmind

   Kadmind utilise un fichier d'acl pour gérer les droits d'accès à la base Kerberos. Pour les opérations qui affectent les principaux, le fichier d'acl contrôle également quels principaux peuvent opérer sur quels autres principaux. L'emplacement par défaut est LOCALSTATEDIR/krb5kdc/kadm5.acl ou la variable acl_file dans kdc.conf.

Syntaxe

   Les lignes vides ou commençant par # sont ignorées. les lignes contenant une entrée acl a le format suivant:

  principal permissions [target_principal [ restrictions] ]

  Note: l'ordre des lignes est importante. La première entrée correspondante va contrôler l'accès pour un acteur principal sur un principal cible.

principal (Nom de principal complet ou partiel) Spécifie le principal dont les permissions sont définies
permissions Spécifie quels opérations peuvent être effectuées ou non par le principal. C'est une chaîne d'un ou plusieurs caractères ou leur opposé majuscule qui désactive cette permission:

        a ajout de principaux ou stratégies
        c changer les mots de passe pour les principaux
        d suppression de principaux ou stratégies
        i demandes de renseignements concernant les principaux et stratégies
        l lister les principaux ou stratégies
        m modification de principaux ou stratégies
        p propagation de la base de principaux
        s paramétrage explicite des clés pour un principal
        x raccourci pour admcil. Tous les privilèges

target_principal (Optionnel. Nom de principal complet ou partiel) Spécifie le principal sur lequel les permissions s'appliquent. chaque composant du nom peut être wildcarded (*). Peut également inclure des référence au principal, dans lequel *number matche le wilcard correspondant dans principal
restrictions (optionnel) Une chaîne de flags. Les restrictions permises sont:

        {+|-}flagname flag est forcé à la valeur indiquée. Les flags permissifs sont les même que les flags + et - pour les commandes add_principal et modify_principal de kadmin.
        -clearpolicy La stratégie est forcée à être vide
        -policy pol La stratégie est forcée à pol
        -{expire, pwexpire, maxlife, maxrenewlife} time (chaîne de temps getdate) la valeur associée est forcée à MIN(time, valeur demandée)

           Ces flags agissent comme restriction sur toute opération d'ajout ou de modification qui sont permis dans la ligne d'ACL.

   Attention: si le fichier d'acl est modifié, kadmind doit être redémarré pour prendre en compte les modifications.

Exemple

Exemple de fichies kadm5.acl:
*/admin@ATHENA.MIT.EDU    *    
joeadmin@ATHENA.MIT.EDU ADMCIL
joeadmin/*@ATHENA.MIT.EDU il    */root@ATHENA.MIT.EDU
*/root@ATHENA.MIT.EDU cil    *1@ATHENA.MIT.EDU
*/*@ATHENA.MIT.EDU i
*/admin@EXAMPLE.COM x    *    -maxlife 9h -postdateable

ligne 1 Tout principal dans le domaine ATHENA.MIT.EDU avec une instance admin a tous les privilèges administratifs
ligne 2 et 3 L'utilisateur joeadmin a toutes les permissions avec son instance admin, joeadmin/admin@ATHENA.MIT.EDU (matche de la ligne 1), il n'a aucune permission avec son instance joeadmin@ATHENA.MIT.EDU (matche de la ligne 2). Ses instances root et autre non admin ont les permissions de lister et demander avec tout principal qui a l'instance root (macthe de la ligne 3).
ligne 4 Tout principal root dans ATHENA.MIT.EDU peut demander, lister ou changer les mots de passe de leur instance nul, mais pas les autres instance null.
ligne 5 Tout principal dans ATHENA.MIT.EDU (sauf joeadmin@ATHENA.MIT.EDU comme mentionné plus haut) a les privilèges demander.
ligne 6 Finallement, tout principal avec une instance admin dans EXAMPLE.COM a toutes les permissions, mais tout principal qu'ils créent ou modifient ne seront par capable d'obtenir de tickets post-datés ou avec une durée de vie supérieur à 9 heures.
^
20 juin 2014

htmlpdflatexmanmd




kdc.conf

kdc.conf

Fichier de configuration des services Kerberos

   Ce fichier est un supplément à krb5.conf et est utilisé uniquement dans les KDC. Normalement, kdc.conf se trouve dans le répertoire d'état du KDC, LOCALSTATEDIR/krb5kdc mais peut être changé dans la variable KRB5_KDC_PROFILE. Noter qu'il faut redémarrer les services kdc pour prendre en comptes les changements.

Structure

   Les noms de sections sont entre crochets, chaque section peut contenir 0 ou plusieurs relations, sous la forme:

  foo = bar

  

Sections

   Le fichier kdc.conf peut contenir les sections suivantes:

[kdcdefaults] Valeurs par défaut pour le fonctionnement du KDC
[realms] Configuration et paramètres de base de données spécifique au domaine
[dbdefaults] Paramètres de base de données par défaut
[dbmodules] Paramètres par base de données
[logging] Contrôle les logs des services Kerberos

[kdcdefaults]

   À une exception près, les relations dans cette section spécifient les valeur par défaut pour les variable du domaine à utiliser si la sous-section [realms] ne contient par de relation pour le tag.

host_based_services
kdc_ports
kdc_tcp_ports
no_host_referral
restrict_anonymous_to_tgt
kdc_max_dgram_reply_size Spécifie la taille de packet maximum que peut être envoyé en UDP. Défaut: 4096

[realms]

   Chaque tag dans cette section est le nom d'un domaine Kerberos. La valeur du tag est une sous-section où les relations définissent les paramètres du KDC pour ce domaine. L'exemple suivant montre comment définir un paramètre pour le domaine ATHENA.MIT.EDU:


[realms]
    ATHENA.MIT.EDU = {
        max_renewable_life = 7d 0h 0m 0s
    }

acl_file (chaîne). Emplacement du fichier d'acl que kadmind utilise pour déterminer quels principaux ont un accès privilégié à la base. Défaut: LOCALSTATEDIR/krb5kdc.acl
database_module (chaîne). Indique le nom de la section de configuration sous [dbmodules] pour les paramètres spécifiques à la base utilisé par la librairie. Défaut: le nom du domaine.
database_name (chaîne, déprécié) Spécifie l'emplacement de la base Kerberos pour ce domaine, si DB2 est utilisé et que la section de configuration [dbmodules] ne spécifie par un nom de base. Défaut: LOCASTATEDIR/krb5kdc/principal
default_principal_expiration (chaîne, temps absolu). Spécifie le temps d'expiration par défaut des principaux créés dans ce domaine. Défaut: 0 qui signifie aucune expiration.
default_principal_flags (Chaîne) Spécifie les attributs par défaut des principaux crées dans ce domaine. Le format est une liste de flags séparés par une ",", avec un "+" avant chaque flag à ajouter, et "-" à enlever. Défaut: les flag suivant sont permis postdateable, forwardable, tgt-based, renewable, proxiable, dup-skey, allow-tickets, et service. Les flags possibles sont:

        allow-tickets Le KDC va fournir de tickets pour ce principal
        dup-skey permet au principal d'obtenir une clé de session pour un autre utilisateur.
        forwardable Permet au principal d'obtenir des tickets forwardable
        hwauth Le principal doit utiliser un périphérique hardware pour la pré-authentification
        no-auth-data-required Empêche les données PAC et AD-SIGNEDPATH d'être ajoutés au ticket de service pour le principal
        ok-as-delegate Indique au client que les accréditifs peuvent et devraient être délégués en s'authentifiant auprès du service
        ok-to-auth-as-delegate Permet au principal d'utiliser des tickets S4USelf
        postdateable Permet au principal d'obtenir des tickets post-datés.
        preauth Le principal doit de pré-authentifier auprès du KDC avant de recevoir un ticket. Pour un principal de service, cela signifie que les tickets de service pour ce principal seront uniquement fournis aux clients avec un TGT qui a le bit preauthenticated mis.
        proxiable Permet au principal d'obtenir des tickets proxy
        pwchange Force le changement de mot de passe pour ce principal
        pwservice Marque ce principal comme service de changement de mot de passe. Devrait être utilisé uniquement dans des cas spéciaux, par exemple, si le mot de passe de l'utilisateur a expiré, alors l'utilisateur doit obtient des tickets pour ce principal sans passer par une authentification normal par mot de passe pour pouvoir changer le mot de passe.
        renewable Permet au principal d'obtenir des tickets renouvelable.
        service Permet au KDC de fournir des tickets de service pour ce principal
        tgt-based Permet au principal d'obtenir des tickets basés sur un TGT au lieu de répéter le process d'authentification utilisé pour obtenir ce TGT.

dict_file (chaîne) Emplacement du fichier dictionnaire contenant les chaînes non permises pour un mot de passe.
host_based_services (liste séparée par des espaces ou des virgules) Liste des services qui vont obtenir un traitement des référants basés sur l'hôte même si le principal du serveur n'est pas marqué comme basé sur l'hôte par le client.
iprop_enable (bool) Spécifie si la propagation incrémentale de la base est permise. Défaut: false.
iprop_master_ulogsize (entier) Spécifie le nombre max d'entrées de log à retenir pour la propagation incrémentale. max: 2500, défaut: 1000
iprop_slave_poll (chaîne de temps delta) Spécifie la fréquence des mises à jours les esclaves auprès du maître. Défaut: 2m (minutes)
iprop_port (numéro de port) Spécifie le numéro de port à utiliser pour la propagation incrémentale. Requis dans les configuration des maître et esclaves.
iprop_resync_timeout (chaîne de temps delta). Spécifie le temps d'attente pour une propagation complète. Optionnel et est utilisé par les esclaves uniquement. Défaut: 5m.
iprop_logfile (Nom de fichier) Spécifie où se situe le fichier de log des mises à jours. Par défaut, utilise database_name.ulog
kadmind_port (numéro de port) Port d'écoute du service kadmind. Défaut: 749
key_stash_file (chaîne) Spécifie l'emplacement du fichier stash. Défaut: LOCALSTATEDIR/krb5kdc/.k5.REALM.
kdc_ports (liste séparée par des espaces ou des virgules) Liste de ports d'écoute du serveur Kerberos pour les requêtes UDP. Défaut: 88,750
kdc_tcp_ports (liste séparée par des espaces ou des virgules) Liste de ports d'écoute du serveur Kerberos pour les requêtes TCP (Défaut: 88).
master_key_name (chaîne) Spécifie le nom du principal associé avec la clé maître. Défaut: K/M
master_key_type (Chaîne de type de clé) Spécifie le type de clé maître. Défaut: aes256-cts-hmac-sha1-96.
max_life (chaîne de temps) Spécifie le temps maximum pour lequel un ticket peut être valide dans le domaine. Défaut: 24heures.
max_renewable_life (chaîne de temps) Spécifie le temps maximum durant lequel un ticket valide peut être renouvelé dans ce domaine. Défaut: 0
no_host_referral (liste séparée par des espaces ou des virgules) Liste
des_crc_session_supported (bool) À true, le KDC assume que les principaux de service supportent des-cbc-crc pour les type de clé de session. Défaut: true.
reject_bad_transit (bool) À true, le KDC vérifie la liste des domaines de transit pour les tickets inter-domaines avec le chemin de transit calculé depuis les noms des domaines et la section capaths de son fichier krb5.conf; si le chemin dans le ticket contient un domaine qui n'est pas dans le chemin calculé, le ticket ne sera pas délivré. Si cette valeur est à false, de tels tickets seront toujours émis. si le flag disable-transited-check est mis dans la requête entrante, cette vérification n'est pas effectuée. L'option reject_bad_transit force de telles requête à être toujours rejetées. Défaut: true
restrict_anonymous_to_tgt (bool) À true, le KDC rejète les demandes de tickets pour des principaux anonymes au principaux de service autre que le domaine du TGS. Cette option permet les PKINIT anonymes pour les tickets FAST sans autoriser l'authentification anonyme aux services. Défaut: false.
supported_enctypes (liste de key:salt) Spécifie les combinaisons key/salt par défaut des principaux pour ce domaine. Tout principal créé via kadmin aura des clé de ce type. Défaut: aes256-cts-hmac-sha1-96:normal aes128-cts-hmac-sha1-96:normal des3-cbc-sha1:normal arcfour-hmac-md5:normal.

[dbdefaults]

   Cette section spécifie les valeur par défaut pour certains paramètres de base, à utiliser si la sous-section dbmodules ne contient pas de relation pour ce tag.

ldap_kerberos_container_dn
ldap_kdc_dn
ldap_kadmind_dn
ldap_service_password_file
ldap_servers
ldap_conns_per_server

[dbmodules]

   Cette section contient des paramètres utilisés par les bases du KDC et les modules. Chaque tag dans cette section est le nom d'un domaine Kerberos ou un nom de section spécifié par le paramètre database_module du domaine. L'exemple suivant montre comment définir un paramètre de base pour le domaine ATHENA.MIT.EDU:

[dbmodules]
    ATHENA.MIT.EDU = {
        disable_last_success = true
    }

database_name Ce tag spécifique à db2 indique l'emplacement de la base dans le système de fichier. Défaut: LOCALSTATEDIR/krb5kdc/principal
db_library Indique le nom du module de base à charger. peut être db2 ou kldap
disable_last_success À true, supprime les mises à jours KDC du champ "last successful authentication" des entrées de principal nécessitant une pré-authentification. Positionner ce flag peut améliorer les performances. (Les entrées de principal qui ne nécessitent par de pré-authentification ne mettent jamais ce champ)
disable_lockout À true, supprime les champs "last failed authentication" et "failed password attempts" des entrées de principal nécessitant une pré-authentification. peut améliorer les performances.
ldap_conns_per_server Indique le nombre de connexios à maintenir par serveur LDAP
ldap_kadmind_dn Indique le bind DN par défaut pour le service kadmind. Cet objet devrait avoir les droits de lire et écrire dans la base Kerberos dans la base LDAP.
ldap_kdc_dn Indique le bind DN par défaut pour le service krb5kdc. Cet objet devrait avoir les droits de lire dans la base Kerberos dans la base LDAP et d'écrire les données sauf si disable_lockout et disable_last_success sont à true.
ldap_kerberos_container_dn Indique le DN de l'objet conteneur où les objets de domaine sont localisés.
ldap_servers Liste les serveur LDAP à contacter.
ldap_service_password_file Indique le fichier contenant les mots de passe stashed (créés par kdb5_ldap_util stashsrvpw) pour les objets ldap_kadmind_dn et ldap_kdc_dn.
db_module_dir contrôle l'emplacement les modules de base de données. devrait être un chemin absolu. Ce tag pour être spécifié directement dans la section dbmodules.

[logging]

   Cette section indique comment krb5kdc et kadmind effectuent les logs. Les clés dans cette section sont les noms des services, qui peut être un parmi:

admin_server Spécifie comment kadmind effectue les logs
kdc Spécifie comment krb5kdc effectue les logs
default Spécifie comment les 2 services effectuent les logs.

   Les valeurs sont sous la forme suivante:

FILE=filename ou FILE:filename Log les messages dans le fichier spécifié. si la 1ère forme est utilisée, le fichier est écrasé.
STDERR Log les message sur stderr
CONSOLE Log les messages dans la console
DEVICE=‹devicename› Log les messages dans le périphérique spécifié
SYSLOG[:severity[:facility]] Los les messages dans syslog

Dans l'exemple suivant, les messages du KDC vont dans la console et dans syslog. Les messages de kadmind vont dans /var/adm/kadmin.log et dans le périphérique /dev/tty04
[logging]
    kdc = CONSOLE
    kdc = SYSLOG:INFO:DAEMON
    admin_server = FILE:/var/adm/kadmin.log
    admin_server = DEVICE=/dev/tty04

[otp]

   Chaque sous-section de [opt] est le nom du type de token OTP. Les tags dans la sous-section définis la configuration requise pour forwarder une requête OTP au serveur radius. Pour chaque type de token, les tags suivants peuvent être spécifiés:

server Serveur où envoyer les requêtes RADIUS. Peut être un nom d'hôte et un port optionnel, une adresse IP ou un socket UNIX. Défaut LOCALSTATEDIR/krb5kdc/‹name›.socket
secret Indique le fichier qui peut être relatif à LOCALSTATEDIR/krb5kdc contenant le secret utilisé pour chiffré les packets RADIUS. Le secret devrait apparaître sur la première ligne du fichier. Si server indique un socket unix, ce tag est optionnel.
timeout Entier qui spécifie le temps en secondes durant lequel de KDC devrait attendre pour contacter le serveur RADIUS. Ce tag est le temps total entre toutes les tentatives et devrait être inférieur au temps de validité de l'OTP. Défaut: 5 secondes
retries Nombre de re-tentatives auprès du serveur RADIUS. Défaut: 3
strip_realm À true, le principal sans le domaine sera passé au serveur RADIUS, sinon le domaine est inclus. Défaut: true.

Dans l'exemple suivant, les requêtes sont envoyées à un serveur distant via UDP:
[otp]
    MyRemoteTokenType = {
        server = radius.mydomain.com:1812
        secret = SEmfiajf42$
        timeout = 15
        retries = 5
        strip_realm = true
    }

Un token par défaut implicite nommé DEFAULT est définis pour les type de token non spécifiés. Sa configuration est décrite ci-dessous.
[otp]
    DEFAULT = {
        strip_realm = false
    }

Options PKINIT

   Cet valeurs peuvent être spécifiées dans [kdcdefaults] comme valeur par défaut, ou dans une sous-section de [realms]. Noter qu'une valeur spécifique à un domaine remplace, n'ajoute pas, une spécification kdcdefaults. L'ordre de recherche est:

1. sous-section de [realms]:
    [realms]
        EXAMPLE.COM = {
            pkinit_anchors = FILE:/usr/local/example.com.crt
        }

2. Valeur générique dans la section [kdcdefaults]:
    [kdcdefaults]
        pkinit_anchors = DIR:/usr/local/generic_trusted_cas/

pkinit_anchors Spécifie l'emplacement des certificats de confiance racine que le client utilise pour signer les certificats KDC. Peut être spécifié plusieurs fois.
pkinit_dh_min_bits Taille de la clé Diffie-Hellman que le client va tenter d'utiliser. les valeur acceptable sont 1024, 2048 (défaut), et 4096.
pkinit_allow_upn Spécifie que le KDC est prêt à accepter les certificats client avec un SAN UPN. Défaut: false. Sans cette option, le KDC accepte uniquement les certificats avec id-pkinit-san comme définis dans la rfc4556. Il n'y a actuellement aucune option pour désactiver la vérification SAN dans le KDC.
pkinit_eku_checking spécifie quelle valeur d'Extended Key Usage le KDC est prêt à accepter dans les certificats client. Les valeurs reconnues sont:

        kpClientAuth C'est la valeur par défaut et spécifie que les certificats client doivent avoir le id-pkinit-KDKdc EKU comme définis dans la rfc4556.
        scLogin Les certificats client avec id-ms-sc-logon seront acceptés
        none Les certificats client ne seront pas vérifiés pour un EKU acceptable.

pkinit_identity Spécifie l'emplacement des information d'identité X.509 du KDC. Cette option est requise si pkinit est supportée par le KDC
pkinit_kdc_ocsp Spécifie l'emplacement de l'OCSP du KDC
pkinit_mapping_file Spécifie le nom du fichier de mappage d'acl pkinit. Ce fichier map les principaux aux certificats qu'ils utilisent.
pkinit_pool Spécifie l'emplacement des certificats intermédiaires qui peuvent être utilisés par le KDC pour compléter le chaîne. Peut être spécifiée plusieurs fois
pkinit_revoke Spécifie l'emplacement de la CRL. Peut être spécifié plusieurs fois
pkinit_require_crl_checking Spécifie que la vérification de révocation est requise.

Types de chiffrement

des-cbc-crc DES cbc mode avec CRC-32 (weak)
des-cbc-md4 DES cbc mode avec RSA-MD4 (weak)
des-cbc-md5 DES cbc mode avec RSA-MD5 (weak)
des-cbc-raw DES cbc mode raw (weak)
des3-cbc-raw Triple DES cbc mode raw (weak)
des3-cbc-sha1 des3-hmac-sha1 des3-cbc-sha1-kd Triple DES cbc mode avec HMAC/sha1
des-hmac-sha1 DES avec HMAC/sha1 (weak)
aes256-cts-hmac-sha1-96 aes256-cts AES-256 CTS mode avec 96-bit SHA-1 HMAC
aes128-cts-hmac-sha1-96 aes128-cts AES-128 CTS mode avec 96-bit SHA-1 HMAC
arcfour-hmac rc4-hmac arcfour-hmac-md5 RC4 avec HMAC/MD5
arcfour-hmac-exp rc4-hmac-exp arcfour-hmac-md5-exp Exportable RC4 avec HMAC/MD5 (weak)
camellia256-cts-cmac camellia256-cts Camellia-256 CTS mode avec CMAC
camellia128-cts-cmac camellia128-cts Camellia-128 CTS mode avec CMAC
des Fammille DES: des-cbc-crc, des-cbc-md5, and des-cbc-md4 (weak)
des3 Famille triple DES: des3-cbc-sha1
aes Famille AES: aes256-cts-hmac-sha1-96 and aes128-cts-hmac-sha1-96
rc4 Famille RC4: arcfour-hmac
camellia Famille Camellia: camellia256-cts-cmac and camellia128-cts-cmac

   La chaîne DEFAULT peut être utilisé pour les type de jeu par défaut pour les variables en question. Les types ou familles peuvent être supprimées de la liste courante en les préfixant avec un "-". Les types ou familles peuvent être préfixés avec un "+" pour la symétrie; il a la même signification que simplement lister le type ou la famille. Par exemple, DEFAULT -des sera le jeu de chiffrement par défaut avec les types DES supprimés, et des3 DEFAULT sera le jeu de chiffrement par défaut avec triple DES supprimé.

   Alors que aes128-cts et aes256-cts sont supportés pour toutes les opérations Kerberos, ils ne sont pas supportés par d'anciennes versions de l'implémentation GSS-API.

Listes de keysalt

   Les clés Kerberos pour les utilisateurs sont généralement dérivés des mots de passe. Les commandes et les paramètres de configuration Kerberos qui affectent la génération de clés prennent la liste des paires enctype-salttype, appelés "liste keysalt". Chaque paire keysalt est un nom de type de chiffrement suivi par un nom de salttype, dans le format enc:salt. Par exemple:

  kadmin -e aes256-cts:normal,aes128-cts:normal

  va lancer kadmin pour qu'il génère par défaut des clé dérivés pour les types de chiffrement aes256-cts et aes128-cts, en utilisant un salt normal.

   Pour s'assurer que les gens qui utilisent le même mot de passe n'aient pas la même clé, Kerberos 5 incorpore plus d'informations dans la clé en utilisant un salt. Les types de salt supportés sont les suivant:

normal Défaut pour Kerberos v5
v4 Utilisé uniquement par Kerberos v4 (pas de salt)
norealm Idem au défaut, sans utiliser d'information de domaine.
onlyrealm Utilise seulement les information de domaine comme salt
afs3 AFS version 3, utilisé uniquement pour la compatibilité avec Kerberos v4
special Génère un salt aléatoire.

Exemple

Exemple de fichier de configuration kdc.conf
[kdcdefaults]
    kdc_ports = 88
    
[realms]
    ATHENA.MIT.EDU = {
        kadmind_port = 749
        max_life = 12h 0m 0s
        max_renewable_life = 7d 0h 0m 0s
        master_key_type = des3-hmac-sha1
        supported_enctypes = des3-hmac-sha1:normal des-cbc-crc:normal des-cbc-crc:v4
        database_module = openldap_ldapconf
    }
    
[logging]
    kdc = FILE:/usr/local/var/krb5kdc/kdc.log
    admin_server = FILE:/usr/local/var/krb5kdc/kadmin.log
    
[dbdefaults]
    ldap_kerberos_container_dn = cn=krbcontainer,dc=mit,dc=edu
    
[dbmodules]
    openldap_ldapconf = {
        db_library = kldap
        disable_last_success = true
        ldap_kdc_dn = "cn=krbadmin,dc=mit,dc=edu"
        ldap_kadmind_dn = "cn=krbadmin,dc=mit,dc=edu"
        ldap_service_password_file = /etc/kerberos/service.keyfile
        ldap_servers = ldaps://kerberos.mit.edu
        ldap_conns_per_server = 5
    }
^
18 juin 2014

htmlpdflatexmanmd




krb5.conf

krb5.conf

Fichier de configuration Kerberos

   Ce fichier contient la configuration Kerberos, incluant l'emplacement des serveurs KDC et admin pour les domaines Kerberos, les valeurs par défaut pour le domaine courant et pour les applications kerberos, et les mappages de nom d'hôte dans les royaumes Kerberos. Normallement, ce fichier est dans /etc mais son emplacement peut être spécifié dans la variable KRB5_CONFIG.

Structure

   Les noms de sections sont entre crochets, chaque section peut contenir 0 ou plusieurs relations, sous la forme:

  foo = bar

  

ou:
fubar = {
    foo = bar
    baz = quux
}

   Placer un * à la fin d'une ligne indique que c'est la valeur final pour le tag. Cela signifie que ni le reste du fichier de configuration, ni un autre fichier de configuration ne sera vérifié pour une autre valeur pour ce tag.

Par exemple, les lignes suivantes:
foo = bar*
foo = baz
Alors la seconde valeur ne sera jamais lue.

Le fichier krb5.conf peut inclure d'autres fichiers en utilisant une des directives suivantes au début d'une ligne:
include FILENAME
includedir DIRNAME

   FILENAME et DIRNAME doivent être des chemin absolus. Le fichier ou le répertoire nommé doit exister et lisible. Inclure un répertoire inclue tous les fichiers dans le répertoire dont le nom consiste uniquement de caractères alphanumériques, "-" ou "_". Les fichiers de profils sont syntaxiquement indépendants de leurs parent, donc chaque fichier inclus doit commencer avec un en-tête de section. Le fichier krb5.conf peut spécifier que la configuration devrait être obtenue depuis un module chargeable, au lieu du fichier lui-même, en utilisant le directive suivante au début de la ligne avant toute section headers:

  module MODULEPATH:RESIDUAL

  MODULEPATH peut être relatif au chemin de librairies de l'installation de krb5, ou peut être un chemin absolus. RESIDUAL est fournis au module à l'initialisation. Si krb5 utilise une directive module, kdc.conf devrait également l'utiliser.

Sections

   krb5.conf peut contenir les sections suivantes:

[libdefaults] Paramètres utilisés par la libraire Kerberos v5
[realms] information et paramètres de contact spécifique au domaine
[domain_realm] Map les noms d'hôte serveur à des domaines Kerberos
[capaths] Chemins d'authentification pour les inter-domaines non-hiérarchiques
[appdefaults] Paramètres utilisés par certaines applications Kerberos
[plugins] Contrôle l'enregistrement des plugins

   Additionnellement, krb5.conf peut inclure une des relations décrites dans kdc.conf, mais n'est pas une pratique recommandée.

[libdefaults]

allow_weak_crypto à false (défaut), les type de chiffrements faibles seront exclus des listes default_tgs_enctypes, default_tkt_enctypes, et permitted_enctypes.
ap_req_checksum_type Un entier qui spécifie le type de checksum AP-REQ à utiliser dans l'authentifiant. Doit être non définis pour le checksun approprié pour la clé de chiffrement soit utilisé.
canonicalize A true (défaut: false), la requête du ticket initial va demander la canonicalisation du nom du principal, et que répondre avec des principaux du client différent du principal demandé sera accepté.
ccache_type Détermine le format du cache d'accéditifs créés par kinit ou autre. défaut: 4, qui représente le format le plus courant.
clockskew Définis la quantité maximum permise de décalage d'horloge en seconde que la librairie va tolérer. Défaut: 300.
default_ccache_name Cette relation spécifie le nom du cache d'accréditifs par défaut. Défaut: DEFCCNAME.
default_client_keytab_name Cette relation spécifie le nom du keytab par défaut pour obtenir les accréditifs du client. Défaut: DEFCKTNAME.
default_keytab_name Cette relation spécifie le nom du keytab par défaut à utiliser par les serveurs d'application tels que sshd. Défaut: DEFKTNAME.
default_realm Identifie le domaine Kerberos par défaut pour le client. Si non définis, un domaine doit être spécifié avec tout principar Kerberos en invoquant un programme tel que kinit
default_tgs_enctypes Identifie la liste supportée de type de chiffrement de clé de session que le client devrait demander dans un TGS-REQ, par ordre de préférence. Défaut: aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 des3-cbc-sha1 arcfour-hmac-md5 camellia256-cts-cmac camellia128-cts-cmac des-cbc-crc des-cbc-md5 des-cbc-md4
default_tkt_enctypes Identifie la liste supportée de type de chiffrement de clé de session que le client devrait demander dans un AS-REQ, par ordre de préférence. Défaut: aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 des3-cbc-sha1 arcfour-hmac-md5 camellia256-cts-cmac camellia128-cts-cmac des-cbc-crc des-cbc-md5 des-cbc-md4
dns_canonicalize_hostname Indique si la recherche de noms sera utilisée pour canoniser les noms d'hôte à utiliser dans les nom principal de service. Définis ce flag à false pour améliorer la sécurité en réduisant le dépendance à DNS. Défaut: true.
dns_lookup_kdc Indique si les enregistrements DNS SRV dervaient pour localiser le KDC et d'autre serveurs pour un domaine, s'il ne sont pas listés par krb5.conf. (noter que l'entrée admin_server doit être dans krb5.conf pour pouvoir contacter kadmin, parce que l'implémentation DNS pour kadmin est incomplète).
extra_addresses Permet à un ordinateur d'utiliser plusieurs adresses locales, pour permettre à Kerberos de travailler dans un réseau qui utilise le NAT. Les adresses devraient être listée séparées par une virgule. n'a pas d'effet si noaddresses est à true.
forwardable À true, les tickets initiaux ne seront pas forwardable par défaut, si permis par le KDC. Défaut: false
ignore_acceptor_hostname En acceptant les contextes de sécurité GSSAPI ou krb5 pour les principaux de service basés sur l'hôte, ignore tout nom d'hôte passé par l'application appelante, et permet aux clients d'authentifier tout principal de service dans le keytab correspondant au nom du service et au nom du domaine. peut compromettre la sécurité des environnements d'hôte virtuels. Défaut: false.
k5login_authoritative À true, les principaux doivent listés dans le fichier k5login de l'utilisateur pour avoir un accès login, si un fichier .k5login existe. Si ce flag est à false, un principal peut avoir l'accès login au travers d'autre mécanismes même si un k5login existe mais ne liste pas le principal. Défaut: true.
k5login_directory Si définis, la librairie va rechercher le fichier k5login de l'utilisateur local dans le répertoire spécifié, avec un nom de fichier correspondant au nom de l'utilisateur local. Sinon, recherche un fichier nommé .k5login dans le home de l'utilisateur. Pour des raisons de sécurité, .k5login doit être possédé par l'utilisateur local ou par root.
kdc_req_checksum_type Un entier qui spécifie le type de checksum à utilise pour les demande KDC, pour la compatibilité avec de vieille version de KDC.
noaddresses À true, les demandes pour les tickets initiaux ne seront pas faites avec des jeux de restriction d'adresse, permettant aux tickets d'être utilisés via les NAT. Défaut: true.
permitted_enctypes Identifie tous les types de chiffrement permis pour le chiffrement de clé de session. Défaut: aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 des3-cbc-sha1 arcfour-hmac-md5 camellia256-cts-cmac camellia128-cts-cmac des-cbc-crc des-cbc-md5 des-cbc-md4
plugin_base_dir Répertoire de base où se trouvent les plugins krb5. Défaut: krb5/plugins
preferred_preauth_types Permet de définir le type de pré-authentification préféré du client. Défaut: "17, 16, 15, 14" qui force libkrb5 à utiliser PKINIT si supporté.
proxiable À true, les tickets initiaux seront mandatables, si permis par le KDC. Défaut: false
rdns À true, la recherche de noms inversée sera utilisée en plus de la recherche de nom pour canoniser les nom d'hôte à utiliser dans les noms de principaux de service. Si dns_canonicalize_hostname est à false, ce flag n'a pas d'effet. défaut: true.
realm_try_domains Indique si les composants de domaine des hôte devraient être utilisés pour déterminer de domaine Kerberos de l'hôte. La valeur de cette variable est un entier: -1 signifie ne pas rechercher, 0 tente le domaine de l'hôte, 1 tente le domaine immédiatement parent, etc. Le mécanisme usuel de la librairie pour localiser les domaines Kerberos est utilisé pour déterminer si un domaine est un domaine valide, qui peut impliquer de consulter DNS si dns_lookup_kdc est mis. Défaut: -1
renew_lifetime Définis la durée de vie de renouvellement pour les demandes de tickets initiaux. Défaut: 0
safe_checksum_type Un entier qui spécifie le type de checksum à utiliser pour les demandes KRB-SAFE. Défaut: 8 (RSA MD5 DES). Ce champ est ignoré quand ça valeur est incompatible avec le type de clé de session.
ticket_lifetime Durée de vie par défaut pour les demandes de tickets initiaux. Défaut: 1 jour
udp_preference_limit En envoyant un message au KDC, la librairie tente d'utiliser TCP avant UDP si la taille du message est supérieur à udp_preference_limit.
verify_ap_req_nofail À true, une tentative de vérifier des accréditifs initiaux va échouer si la machine client n'a pas de keytab. Défaut: false

[realms]

   Chaque tag dans cette section est le nom d'un domaine Kerberos. La valeur du tag est une sous-section qui définis les propriétés de ce domaine. Pour chaque domaine, les tags suivants peuvent être spécifiés dans la sous-section:

admin_server Identifie l'hôte où le serveur d'administration réside. Typiquement, c'est le serveur maître. Ce tag doit avoir une valeur pour permettre la communication avec le serveur kadmind
auth_to_local Permet de définir un règle générale pour le mappage des noms des principaux aux nom des utilisateurs locaux. Est utilisé s'il n'y a pas de mappage explicite pour le nom principal. Les valeurs possible sont:

        RULE:exp Le nom local sera formulé depuis exp. Le format est [n:string](regexp)s/pattern/replacement/g. L'entier n indique combien de composants le principal cible devrait avoir. Si cela matche, alors un chaîne sera formée depuis string, en substituant le domaine du principal pour $0 et le n-ième composant du principal pour $n ( exemple, si le principal était johndoe/admin alors [2:$2$1foo] va résulter dans la chaîne adminjohndoefoo). Si la chaîne matche regexp, alors la substitution de commande s//[g] ne va jamais parcourir la chaîne. le g optionnel matche toutes les occurences.
        DEFAULT Le nom du principal sera utilisé tel que le nom d'utilisateur. Si le principal a plus d'un composant ou n'est pas le domaine par défaut, cette règle n'est pas applicable et la conversion va échouer.


        Par exemple:
[realms]
    ATHENA.MIT.EDU = {
        auth_to_local = RULE:[2:$1](johndoe)s/^.*$/guest/
        auth_to_local = RULE:[2:$1;$2](^.*;admin$)s/;admin$//
        auth_to_local = RULE:[2:$2](^.*;root)s/^.*$/root/
        auto_to_local = DEFAULT
    }

           va résulter en tout principal sans root ou admin comme second composant à traduire avec la règle par défaut. Un principal avec un second composant admin va devenir son premier composant. root sera utilisé comme nom local pour tout principal avec un second composant root. L'exception à ces règles sont tout principal johndoe/* qui sera toujours le nom local guest.

auth_to_local_names Cette sous-section vous permet de définir explicitement des mappages de noms de principaux à des noms locaux. Le tag est le nom mappé, et la valeur est l'utilisateur local
default_domain Ce tag spécifie le domaine utilisé pour étendre les noms d'hôte en traduisant les principaux Kerberos v4 en principaux v5.
kdc Le nom ou l'adresse d'un hôte hébergeant un KDC pour ce domaine. Un numéro de port optionnel peut être inclus. Si le nom ou l'adresse contient des ":", utiliser des crochets pour distinguer le ":" de l'adresse du numéro de port. Pour que la machine puisse communiquer avec le KDC, ce tag doit être donné, ou il doit y avoir des enregistrements DNS SRV.
kpasswd_server Pointe vers le serveur où tous les changements de mot de passe sont effectués. S'il n'y a pas de telles entrées, le port 464 de l'hôte admin_server sera tenté.
master_kdc Identifie le KDC maître. Actuellement, ce tag est utilisé dans un cas: si la tentative d'obtention des accréditifs échoue à cause d'un mot de passe invalide, le client va tenter de contacter le KDC maître, dans le cas où le mot de passe de l'utilisateur vient juste d'être changé.

[domain_realm]

   Cette section fournis une traduction depuis un nom de domaine ou un nom d'hôte en un nom de domaine Kerberos. Le nom du tag peut être un nom d'hôte ou un nom de domaine, où les noms de domaine sont identifiés par un préfixe point (.). La valeur est le nom de domaine Kerberos pour un hôte ou un domaine particulier. Une relation de nom d'hôte fournis implicitement la relation de nom de domaine correspondante, sauf si une relation de nom de domaine explicite est fournie. Le domaine Kerberos peut être identifié soit dans la section realm ou en utilisant les enregistrements DNS SRV. Les noms d'hôte et domaine devraient être en minuscules. Par exemple:

[domain_realm]
    crash.mit.edu = TEST.ATHENA.MIT.EDU
    .dev.mit.edu = TEST.ATHENA.MIT.EDU
    mit.edu = ATHENA.MIT.EDU

   mappe l'hôte crash.mit.edu dans le domaine Kerberos TEST.ATHENA.MIT.EDU. La seconde entrée map tous les hôtes sous le domaine dev.mit.edu dans le domaine Kerberos TEST.ATHENA.MIT.EDU sauf l'hôte dev.mit.edu qui est mappé au domaine ATHENA.MIT.EDU.

   Si aucune traduction ne s'applique au nom d'hôte utilisé pour un principal de service pour une demande de ticket de service, la librairie va tenter d'obtenir un référant au domaine approprié depuis le KDC du domaine du client. Si cela échoue, le domaine de l'hôte est considéré être la portion de domaine du nom d'hôte convertit en majuscules, sauf le paramètre realm_try_domains dans la section libdefaults qui force un domaine parent différent à utiliser.

[capaths]

   Pour pouvoir effectuer une authentification inter-domaine directe ( non hiérarchique ), une configuration est nécessaire pour déterminer les chemins d'authentification entre les domaines.

   Un client va utiliser cette section pour trouver le chemin d'authentification entre son domaines et le domaine du serveur. Le serveur va utiliser cette section pour vérifier le chemin d'authentification utilisé par le client, en vérifiant le champ transited.

   Il y a un tag pour chaque domaine client participant, et chaque tag a des sous-tags pour chaque domaine serveur. La valeur des sous-tags est un domaine intermédiaire qui peuvent participer dans l'authentification inter-domaine. Les sous-tags peuvent être répétés s'il y a plus d'un domaine intermédiaire. Une valeur "." signifie que le 2 domaines partagent les clés directement, et aucun intermédiaire ne devrait être autorisé à participer.

   Seul ces entrées qui sont nécessaire dans le client ou le serveur doivent être présent. Un client a besoin d'un tag pour son domaine local avec des sous-tags pour tous les domaines des serveurs auquel il aura besoin de s'authentifier. Un sereur a besoin d'un tag pour chaque domaine des clients qu'il désert, avec un sous-tag pour chaque domaine serveur.

   Par exemple, ANL.GOV, PNL.GOV et NERSC.GOV veulent utiliser le domaine ES.NET comme domaine intermédiaire. ANL a un sous-domaine TEST.ANL.GOV qui va s'authentifier avec NERSC.GOV mais pas PNL.GOV. La section capaths pour les systèmes ANL.GOV ressembleraient à:


[capaths]
    ANL.GOV = {
        TEST.ANL.GOV = .
        PNL.GOV = ES.NET
        NERSC.GOV = ES.NET
        ES.NET = .
    }
    TEST.ANL.GOV = {
        ANL.GOV = .
    }
    PNL.GOV = {
        ANL.GOV = ES.NET
    }
    NERSC.GOV = {
        ANL.GOV = ES.NET
    }
    ES.NET = {
        ANL.GOV = .
    }

La section capaths du fichier de configuration utilisé dans les systèmes NERSC.GOV ressembleraient à:
    [capaths]
        NERSC.GOV = {
            ANL.GOV = ES.NET
            TEST.ANL.GOV = ES.NET
            TEST.ANL.GOV = ANL.GOV
            PNL.GOV = ES.NET
            ES.NET = .
        }
        ANL.GOV = {
            NERSC.GOV = ES.NET
        }
        PNL.GOV = {
            NERSC.GOV = ES.NET
        }
        ES.NET = {
            NERSC.GOV = .
        }
        TEST.ANL.GOV = {
            NERSC.GOV = ANL.GOV
            NERSC.GOV = ES.NET
        }

   Quand un sous-tag est utilisé plus d'une fois dans un tag, les clients utilisent l'ordre des valeurs pour déterminer le chemin. L'ordre des valeurs n'est pas important pour les serveurs.

[appdefault]

   Chaque tag dans cette section nomme une application Kerberos v5 ou un option qui est utilisé par certaines applications Kerberos v5. La valeur du tag définis le fonctionnement par défaut pour cette application.

par exemple:
[appdefaults]
    telnet = {
        ATHENA.MIT.EDU = {
            option1 = false
        }
    }
    telnet = {
        option1 = true
        option2 = true
    }
    ATHENA.MIT.EDU = {
        option2 = false
    }
    option2 = true

   Les 4 manières présentées de spécifier la valeur d'une option sont affichés dans l'ordre de précédence descendante. Dans cet exemple, si telnet fonctionne dans le domaine EXAMPLE.COM, il devrait, par défaut, avoir option1 et option2 à true. Cependant, un programme telnet dans le domaine ATHENA.MIT.EDU devrait avoir l'option1 à false et option2 à true. Tout autre programme dans ATHENA.MIT.EDU devrait avoir l'option2 à false par défaut. Tout programme fonctionnant dans d'autre domaine devraient avoir option2 à true.

   La liste d'options spécifiable pour chaque application peut être trouvée dans les man des applications.

[plugins]

   Les tags dans cette section peuvent être utilisées pour enregistrer les modules dynamique et pour activer/désactiver les modules. Tous les interface activable n'utilisent pas cette section. Celles qui l'utilise sont documentées ici. Chaque interface pluggable correspond à une sous-section. Toutes les sous-sections supportent les même tags:
   [SECTION]
   [SECTION] name="-" table="paragraphes" imbrication="0"
   Ce tag peut avoir plusieurs valeurs. S'il y a des valeur pour ce tag, alors les modules nommés seront désactivés pour l'interface pluggable.
   Ce tag peut avoir plusieurs valeurs. S'il y a des valeur pour ce tag, alors les modules nommés seront activés pour l'interface pluggable.
   Ce tag peut avoir plusieurs valeurs. Chaque valeur est une chaîne sous la forme modulename:pathname. chaque module est enregistré comme module dynamique pour l'interface pluggable. Si pathname n'est pas un chemin absolus, il est considéré relatif à plugin_base_dir.

   Pour les interfaces pluggable où l'ordre des modules est importante, les modules enregistrés avec un tag module viennent en premier, dans l'ordre qu'il sont enregistrés. Si enable_only est utilisé, alors l'ordre de ces tags remplace l'ordre des modules normal.

  Les sections suivantes sont actuellement supportées dans la section plugins.

interface ccselect

   La sous-section ccselect contrôle les modules pour la sélection du cache d'accréditifs dans une collection de cache. En plus des modules dynamique enregistrés, les modules embarqués suivant existent:

        k5identity Utilise un fichier .k5identity dans le home de l'utilisateur pour sélectionner un principal
        realm Utilise le domaine de service pour deviner un cache approprié depuis la collection.

interface pwqual

   Cette sous-section contrôle les modules pour l'interface de qualité de mot de passe, qui est utilisé pour rejeter les mots de passe faibles lors des changements de mot de passe. Les modules embarqués suivant existent pour cette interface:

        dict Vérifie avec un fichier dictionnaire du domaine
        empty Rejète les mots de passe vide
        hesiod Vérifie avec les informations utilisateurs stockés dans Hesiod ( seulement si Kerberos est construit avec le support de Hesiod )
        princ Vérifie avec les composant du nom du principal

interface kadm5_hook

   Fournis des plugins avec des informations sur la création de principaux, la modification, changement de mot de passe et suppression. Cette interface peut être utilisée pour écrire un plugin pour synchroniser Kerberos MIT avec celui de Microsoft.

interface clpreauth et kdcpreauth

   Ces interfaces permettent aux modules de fournir des mécanisme de pré-authentification au client et au KDC. Les modules intégrés suivant existent pour ces interfaces:

        pkinit Implémente le mécanisme de pré-authentification pkinit
        encrypted_challenge Implémente FAST
        encrypted_timestamp Implément le mécanisme de timestamp chiffré

interface hostrealm

   Cette section contrôle les modules pour l'interface host-to-realm, qui affecte le mappage locale des noms d'hôte et le choix du domaine par défaut. Les module intégré suivant existent pour cette interface:

        profile Consulte la section [domain_realm] du profile pour les mappages host-to-realm autoritatifs, et la variable default_realm pour le domaine par défaut.
        dns Recherche les enregistrements DNS pour les mappages et le domaine par défaut. n'opère que si dns_lookup_realm est à true.
        domain Applique de l'heuristique pour les mappages host-to-realm. Implémente la variable realm_try_domains, et utilise le domaine parent en majuscule du nom d'hôte si cela ne produit pas de résultat.

interface localauth

   Contrôle les modules pour l'interface d'autorisation local, qui affecte la relation entre les principaux Kerberos et les comptes système locaux. Les modules intégrés suivant existent pour cette interface:

        default Implémente le type DEFAULT pour les valeurs auth_to_local
        rule Implémente le type RULE pour les valeur auth_to_local
        names Recherche un mappage auth_to_local_names pour le nom du principal
        k5login Autorise un principal à un compte local en accord avec le .k5login du compte
        an2ln Autorise un principal à un compte local si le nom du principal se mappe au nom local

Options PKINIT

   Les options suivante sont spécifique à PKINIT. Ces valeur peuvent être spécifiées dans [libdefaults] comme valeurs globales par défaut, ou dans une sous-section spécifique au domaine, ou peuvent être spécifiés comme valeurs spécifique au domaine dans la section [realms]. Les valeurs spécifique au domaine écrase, n'ajoutent pas à une spécification libdefaults par défaut. L'ordre de recherche est:

1. sous-section spécifique au domaine de [libdefaults]
[libdefaults]
    EXAMPLE.COM = {
        pkinit_anchors = FILE:/usr/local/example.com.crt
    }

2. Valeurs spécifique au domaine dans [realms]
[realms]
    OTHERREALM.ORG = {
        pkinit_anchors = FILE:/usr/local/otherrealm.org.crt
    }

3. Valeur générique dans [libdefaults]
[libdefaults]
    pkinit_anchors = DIR:/usr/local/generic_trusted_cas/

Spécifier les informations d'identité PKINIT

  

FILE:filename[,keyfilename] Cette option est dépendante du contexte.

           Dans pkinit_identity ou pkinit_identities, filename spécifie le nom d'un fichier PEM contenat le certificat de l'utilisateur. Si Keyfilename n'est pas spécifié, la clé privée de l'utilisateur est attendue dans filename.

           Dans pkinit_anchors ou pkinit_pool, filename est assumé être le nom d'un fichier ca-bundle style OpenSSL.

DIR:dirname Cette option est dépendante du contexte.

           Dans pkinit_identity ou pkinit_identities, dirname spécifie un répertoire avec des fichiers .crt et .key.

           Dans pkinit_anchors ou pkinit_pool, dirname est assumé être un répertoire CA hashé style OpenSSL où chaque certificat CA est stocké dans un fichier nommé hash-of-ca-cert.#

PKCS12:filename filename est le nom d'un pkcs#12, contenant le certificat de l'utilisateur en la clé privée.
PKCS11:[module_name=]modname[:slotid=slot-id][:token=token-label][:certid=cert-id][:certlabel=cert-label] Tous les mots clé sont optionnels. modname spécifie l'emplacement de la librairie PKCS#11. Si une valeur est rencontrée sans mot clé, il est assumé être le modname. Si aucun nom de module n'est spécifié, le défaut est opensc-pkcs11.so. slotid= et/ou token= peuvent être spécifiés pour forcer l'utilisation d'un lecteur de carte ou un token spécifique. certid= et/ou certlabel peuvent être utilisés pour forcer la sélection d'un certificat particulier sur un périphérique.
ENV:envvar envvar spécifie le nom d'une variable d'environnement qui a été définie à une valeur se conformant à une des valeur précédente. Par exemple, ENV:X509_PROXY où la variable d'environnement X509_PROXY a été définie à FILE:/tmp/my_proxy.pem

options krb5.conf pour PKINIT

pkinit_anchors Spécifie l'emplacement des certificats de confiance racine que le client utilise pour signer les certificats KDC. Peut être spécifié plusieurs fois.
pkinit_cert_match Spécifie les règles de correspondance que le certificat client doit matcher avant d'être utilisé pour l'authentification PKINIT. Peut être spécifié plusieurs fois. Tous les certificats sont vérifiés avec chaque règle jusqu'à ce qu'un certificat matche. La comparaison de chaîne Issuer et Subject sont des représentations chaîne rfc2253 des valeurs Issuer DN et Subject DN du certificat. La syntaxe de la règle est [relation-operator]component-rule ... où:

        relations-operator peut être soit && signifiant toutes les composantes des règles doivent matcher, ou || signifiant que seul un composant de règle doit matcher. Défaut: &&
        component-rule Peut être un des suivant. Noter qu'il n'y a pas de ponctuation ou d'espace blanc entre les composantes de règle:

                ‹SUBJECT› regular-expression
                ‹ISSUER› regular-expression
                ‹SAN› regular-expression
                ‹EKU› extended-key-usage-list
                ‹KU› key-usage-list

                   extended-key-usage-list est une liste de valeurs Extended Key Usage. Toutes les valeurs dans la liste doivent être présents dans le certificat. Les valeurs sont:

                        pkinit
                        msScLogin
                        clientAuth
                        emailProtection

                   key-usage-list est une liste de valeurs requises Key Usages. Toutes les valeurs dans la liste doivent être présentes dans le certificat. Les valeurs sont:

                        digitalSignature
                        keyEncipherment


                exemple:
pkinit_cert_match = ||‹SUBJECT›.*DoE.*‹SAN›.*@EXAMPLE.COM
pkinit_cert_match = &&‹EKU›msScLogin,clientAuth‹ISSUER›.*DoE.*
pkinit_cert_match = ‹EKU›msScLogin,clientAuth‹KU›digitalSignature

pkinit_eku_checking spécifie quelle valeur d'Extended Key Usage le certificat KDC présenté au client doit contenir. (Noter que si le certification du KDC a le pkinit SubjectAlternativeName encodé comme nom Kerberos TGS, la vérification EKU n'est pas nécessaire vu que la CA fournie a certifié cela comme certificat KDC). Les valeurs reconnues sont:

        kpKDC C'est la valeur par défaut et spécifie que le KDC doit avoir le id-pkinit-KDKdc EKU comme définis dans la rfc4556.
        kpServerAuth Un certificat KDC avec le id-kp-serverAuth EKU tel qu'utilisé par Microsoft sera accepté
        none Le certificat du KDC ne sera pas vérifié pour savoir s'il a un EKU acceptable.

pkinit_dh_min_bits Taille de la clé Diffie-Hellman que le client va tenter d'utiliser. les valeur acceptable sont 1024, 2048 (défaut), et 4096.
pkinit_identities Spécifie les emplacements à utiliser pour trouver les information d'identité X.509 du client. Peut être spécifié plusieurs fois. Ces valeur ne sont pas utilisées si l'utilisateur spécifie X509_user_identity sur la ligne de commande.
pkinit_kdc_hostname La présence de cette option indique que le client est prêt à accepter un certificat KDC avec un dNSName SAN au lieu de nécessiter de id-pkinit-san comme définis dans la rfc4556. peut être spécifié plusieurs fois.
pkinit_longhorn À true, on parle au KDC Longhorn
pkinit_pool Spécifie l'emplacement des certificats intermédiaires qui peuvent être utilisés par le client pour compléter la validation de la chaîne. Peut être spécifié plusieurs fois.
pkinit_require_crl_checking Vérifie les informations de révocation.
pkinit_revoke Spécifie l'emplacement de la CRL à utiliser pour vérifier les informations de révocations.
pkinit_win2k Spécifie si le domaine cible est supporte l'ancienne version, pré-rfc, de Kerberos
pkinit_win2k_require_binding À true, le KDC cible attendu est patché pour retourner une réponse avec un checksum. Défaut: false

Expansion de paramètres

   De nombreuses variables, telles que default_keytab_name, permettent d'étendre les paramètres:

%{TEMP} Répertoire temporaire
%{uid} User ID réel ou Windows SID
%{euid} User ID effectif ou Windows SID
%{USERID} Idem à %{uid}
%{null} Chaîne vide
%{LIBDIR} Répertoire d'installation des librairies
%{BINDIR} Répertoire d'installation des binaires
%{SBINDIR} Répertoire d'installation des binaires administratifs
%{username} nom de l'utilisateur unix ou user ID effectif
%{APPDATA} (Windows) Roaming application data for current user
%{COMMON_APPDATA} (Windows) Application data for all users
%{LOCAL_APPDATA} (Windows) Local application data for current user
%{SYSTEM} (Windows) Windows system folder
%{WINDOWS} (Windows) Windows folder
%{USERCONFIG} (Windows) Per-user MIT krb5 config file directory
%{COMMONCONFIG} (Windows) Common MIT krb5 config file directory

Exemple de fichier krb5.conf


[libdefaults]
    default_realm = ATHENA.MIT.EDU
    default_tkt_enctypes = des3-hmac-sha1 des-cbc-crc
    default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc
    dns_lookup_kdc = true
    dns_lookup_realm = false
    
[realms]
    ATHENA.MIT.EDU = {
        kdc = kerberos.mit.edu
        kdc = kerberos-1.mit.edu
        kdc = kerberos-2.mit.edu:750
        admin_server = kerberos.mit.edu
        master_kdc = kerberos.mit.edu
        default_domain = mit.edu
    }
    EXAMPLE.COM = {
        kdc = kerberos.example.com
        kdc = kerberos-1.example.com
        admin_server = kerberos.example.com
    }
    
[domain_realm]
    .mit.edu = ATHENA.MIT.EDU
    mit.edu = ATHENA.MIT.EDU
    
[capaths]
    ATHENA.MIT.EDU = {
         EXAMPLE.COM = .
    }
    EXAMPLE.COM = {
         ATHENA.MIT.EDU = .
    }

^
18 juin 2014

htmlpdflatexmanmd




Kerberos - Installer les KDC

Kerberos - Installer les KDC

Introduction à la configuration initiale des KDC

   En implémentant Kerberos dans un environnement de production, il est préférable d'avoir plusieurs KDC esclave avec un KDC maître pour s'assurer de la disponibilité continue des service kerberisés. Chaque KDC contient une copie de la base de donnée Kerberos. Le KDC maître contient la copie modifiable de la base, qui est répliquée au esclaves à intervalle régulier. Tous les changements de base sont faites sur le maître. Les esclave fournissent les services TGS, mais pas d'administration de la base, quand le KDC maître n'est pas disponible. Le MIT recommande d'installer tous les KDC pour être en mesure de fonctionner soit en tant que maître ou un esclave. Celà permet de facilement basculer un esclave en maître si nécessaire.

Attention

   Le système Kerberos s'appuyent du la disponibilité des informations de temps correcte, assurez vous que le maître et les esclaves ont une horloge synchronisée correctement. Il est préférable d'installer les KDC sur du hardware dédié et sécurisé avec un accès limité.

Installer et configurer le KDC maître

Dans ce document, nous utilisons les noms suivants:
kerberos.mit.edu____-_master KDC
kerberos-1.mit.edu__-_slave KDC
ATHENA.MIT.EDU______-_realm name
.k5.ATHENA.MIT.EDU__-_stash file
admin/admin_________-_admin principal

Éditer les fichiers de configuration du KDC

   Modifier les fichiers de configuration, krb5.conf et kdc.conf, pour refléter les informations telles que le mappage domain-realm et les noms des serveurs kerberos. Beaucoup de tags dans la configuration ont des valeurs par défaut qui sont adéquat à la plupart des sites. Les variables KRB5_CONFIG et KRB5_KDC_PROFILE permettent de spécifier les fichiers altérnatifs:


export KRB5_CONFIG=/yourdir/krb5.conf
export KRB5_KDC_PROFILE=/yourdir/kdc.conf

krb5.conf

   Si vous n'utilisez pas les enregistrements DNS TXT, vous devez spécifier le default_realm dans la section [libdefault]. Si vous n'utilisez par les enregistrements DNS SRV, vous devez inclure le tag kdc pour chaque realm dans la section [realms]. Pour communiquer avec le serveur kadmin dans chaque realm, le tag admin_server doit être définis dans la section [realms].

Exemple de fichier krb5.conf
[libdefaults]
    default_realm = ATHENA.MIT.EDU
    
[realms]
    ATHENA.MIT.EDU = {
        kdc = kerberos.mit.edu
        kdc = kerberos-1.mit.edu
        admin_server = kerberos.mit.edu
    }

kdc.conf

   Ce fichier peut être utilisé pour contrôler les ports d'écoute du KDC en de kadmind, et les paramètres par défaut spécifique au realm, le type de base et son emplacement et le logging.

Exemple de fichier kdc.conf
[kdcdefaults]
    kdc_ports = 88,750

[realms]
    ATHENA.MIT.EDU = {
        kadmind_port = 749
        max_life = 12h 0m 0s
        max_renewable_life = 7d 0h 0m 0s
        master_key_type = aes256-cts
        supported_enctypes = aes256-cts:normal aes128-cts:normal
        # If the default location does not suit your setup,
        # explicitly configure the following values:
        #    database_name = /var/krb5kdc/principal
        #    key_stash_file = /var/krb5kdc/.k5.ATHENA.MIT.EDU
        #    acl_file = /var/krb5kdc/kadm5.acl
    }

[logging]
    # By default, the KDC and kadmind will log output using
    # syslog. You can instead send log output to files like this:
    kdc = FILE:/var/log/krb5kdc.log
    admin_server = FILE:/var/log/kadmin.log
    default = FILE:/var/log/krb5lib.log

   Remplacer ATHENA.MIT.EDU et kerberos.mit.edu avec le nom de votre domaine et serveur Kerberos, respectivement.

  Note: vous devez avoir les droits d'écriture sur les répertoires cibles ( et doivent exister ) utilisés par database_name, key_stash_file, et acl_file.

Créer la base KDC

   Il faut utiliser la commande kdb5_util sur le KDC maître pour créer la base Kerberos et le fichier optionnel stash.

  Note: Si vous choisissez de ne pas installer un fichier stash, le KDC va vous demander la clé maître chaque fois qu'il démarre.

   kdb5_util va vous demander le mot de passe maître pour la base Kerberos. L'exemple suivant montre comment créer une base Kerberos et le fichier stash sur le KDC maître.


shell% kdb5_util create -r ATHENA.MIT.EDU -s
    
Initializing database '/usr/local/var/krb5kdc/principal' for realm 'ATHENA.MIT.EDU',
master key name 'K/M@ATHENA.MIT.EDU'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key: ‹= Type the master password.
Re-enter KDC database master key to verify: ‹= Type it again.
shell%

   Cela va créer 5 fichiers dans LOCALSTATEDIR/krb5kdc ( ou l'emplacement spécifié dans kdc.conf ):

        - 2 fichiers de base de données, principal et principal.ok
        - Le fichier de base de données administrative, principal.kadm5
        - Le fichier de lock de la base administrative, principal.kadm5.lock
        - Le fichier stash, dans cet exemple .k5.ATHENA.MIT.EDU. utiliser l'option -s pour ne pas générer ce fichier.

Ajouter les administrateurs au fichier d'ACL

   Ensuite, vous devez créer un fichier d'acl et y placer le principal Kerberos d'au moins un administrateur. Ce fichier est utilisé par kadmind pour contrôler quel principaux peuvent voir et effectuer des modifications privilégiées dans les fichiers de base Kerberos. Le nom du fichier d'acl est déterminé par la variable acl_file dans kdc.conf ( défaut: LOCALSTATEDIR/krb5kdc/kadm5.acl )

Ajouter les administrateurs à la base kerberos

   Vous devez ajouter les principaux administratifs à la base de données Kerberos. Vous devez ajouter au moins un principal pour permettre la communication entre kadmind et kadmin sur le réseaux. Pour cela, utiliser l'utilitaire kadmin.local sur le KDC maître. Il est conçus pour être lancé sur un KDC maître sans utiliser d'authentification Kerberos. Vous devez avoir un accès en lecture/écriture à la base Kerberos.

   Les principaux administratifs que vous créez devraient être ceux ajoutés dans le fichier d'acl.

Dans l'exemple suivant, le principal administratif admin/admin est créé:
shell% kadmin.local
    
kadmin.local: addprinc admin/admin@ATHENA.MIT.EDU
    
WARNING: no policy specified for "admin/admin@ATHENA.MIT.EDU";
assigning "default".
Enter password for principal admin/admin@ATHENA.MIT.EDU: ‹= Enter a password.
Re-enter password for principal admin/admin@ATHENA.MIT.EDU: ‹= Type it again.
Principal "admin/admin@ATHENA.MIT.EDU" created.
kadmin.local:

Démarrer le service Kerberos sur le KDC maître

À ce point, vous êtes prêt à démarrer le KDC (krb5kdc) et les services administratifs sur le KDC maître:
shell% krb5kdc
shell% kadmind

   Chaque service va se forker en tâche de fond.

Vous pouvez vérifier qu'ils sont lancés correctement en vérifiant les messages de démarrage dans les emplacement le logging spécifiés dans krb5.conf:
shell% tail /var/log/krb5kdc.log
Dec 02 12:35:47 beeblebrox krb5kdc[3187](info): commencing operation
shell% tail /var/log/kadmin.log
Dec 02 12:35:52 beeblebrox kadmind[3189](info): starting

En vérification additionnelle, vérifier si kinit réussit avec les principaux administratifs:
shell% kinit admin/admin@ATHENA.MIT.EDU

Installer les KDC esclave

   Maintenant vous être prêt à configurer les KDC esclaves.

  Note: en assumant que vous paramètrez le KDC de manière à facilement basculer le maître avec un des esclaves, vous devriez effectuer chaque étape sur de maître sur les esclaves, sauf les ces instructions spécifient le contraire.

Créer les keytabs pour les KDC esclave

   Chaque KDC a besoin d'un clé host dans la base Kerberos. Ces clés sont utilisée pour l'authentification mutuelle lors de la propagation des dump de la base de donnée depuis le maître.

   Sur le KDC maître, se connecter à l'interface administrative et créer le principal de l'hôte pour chaque service host des KDC. Par exemple, si le maître s'appel kerberos.mit.edu, et l'esclave s'appel kerberos-1.mit.edu:


shell% kadmin
kadmin: addprinc -randkey host/kerberos.mit.edu
NOTICE: no policy specified for "host/kerberos.mit.edu@ATHENA.MIT.EDU"; assigning "default"
Principal "host/kerberos.mit.edu@ATHENA.MIT.EDU" created.
    
kadmin: addprinc -randkey host/kerberos-1.mit.edu
NOTICE: no policy specified for "host/kerberos-1.mit.edu@ATHENA.MIT.EDU"; assigning "default"
Principal "host/kerberos-1.mit.edu@ATHENA.MIT.EDU" created.

   Il n'est pas nécessaire d'avoir le maître dans la base Kerberos, mais peut être nécessaire si vous souhaitez basculer le maître en esclave. Ensuite, extraire chaque clé host pour tous les KDC participants et les stocker dans chaque fichier keytab de l'hôte. Idéalement, vous devriez extraire chaque keytab localement dans son propre KDC. Si cela n'est pas faisable, vous devriez utiliser une session chiffrée pour les envoyer sur le réseau. Pour extraire un keytab sur un serveur esclave:


kadmin: ktadd host/kerberos-1.mit.edu
Entry for principal host/kerberos-1.mit.edu with kvno 2, encryption
    type aes256-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab.
Entry for principal host/kerberos-1.mit.edu with kvno 2, encryption
    type aes128-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab.
Entry for principal host/kerberos-1.mit.edu with kvno 2, encryption
    type des3-cbc-sha1 added to keytab FILE:/etc/krb5.keytab.
Entry for principal host/kerberos-1.mit.edu with kvno 2, encryption
    type arcfour-hmac added to keytab FILE:/etc/krb5.keytab.

Configurer les KDC esclave

   La propagation de la base de données copie le contenu de la base du maître, mais ne propage pas les fichiers de configuration, les fichiers stash, ou le fichier d'acl. Les fichiers suivants doivent être copiés à la main pour chaque esclave:

        - krb5.conf
        - kdc.conf
        - kadm5.acl
        - master key stash file

   Déplacer les fichiers copiés dans leur répertoires appropriés, exactement comme sur le KDC maître. La base est propagée du maître vers les esclaves via le service kpropd. Vous devez explicitement spécifier les principaux qui sont autorisé à fournir les mises à jours Kerberos sur les esclaves avec une nouvelle base de données. Créer un fichier nommé kpropd.acl dans le répertoire d'état KDC contenant les principaux host pour chaque KDC:


host/kerberos.mit.edu@ATHENA.MIT.EDU
host/kerberos-1.mit.edu@ATHENA.MIT.EDU

   Note: si vous souhaitez que le maître et l'esclave puis être inversés, listez les principaux hôtes depuis tous les KDC participants dans les fichiers kpropd.acl dans tous les KDC. Sinon, vous avez seulement besoin de lister le principal de l'hôte du KDC maître dans kpropd.acl des KDC esclaves.

Ensuite, ajoutez la ligne suivante dans /etc/inetd.conf dans chaque KDC:
krb5_prop 754/tcp # Kerberos slave propagation

   Redémarrez inetd. Alternativement, démarrer kpropd comme service standalone. Cela est nécessaire quand la propagation incrémental est activé.

   Maintenant que le KDC est capable d'accepter la propagation de la base, vous avez besoin de propager la base depuis le maître. Note: Ne pas démarrer le KDC esclave avant d'avoir une copie du maître.

Propager la base à chaque esclave

Premièrement, créer un fichier dump de la base sur le maître:
shell% kdb5_util dump /usr/local/var/krb5kdc/slave_datatrans
Puis, propager manuellement la base à chaque esclave:
shell% kprop -f /usr/local/var/krb5kdc/slave_datatrans kerberos-1.mit.edu
Database propagation to kerberos-1.mit.edu: SUCCEEDED

   Vous aurez besoin d'un script pour dumper et propager la base. voici un exemple de script shell. Rappelez vous que vous avez besoin de remplacer /usr/local/var/krb5kdc avec le nom du répertoire d'état KDC.


#!/bin/sh
    
kdclist = "kerberos-1.mit.edu kerberos-2.mit.edu"
    
kdb5_util dump /usr/local/var/krb5kdc/slave_datatrans
    
for kdc in $kdclist
do
    kprop -f /usr/local/var/krb5kdc/slave_datatrans $kdc
done

Vous avez besoin du définir un cron pour lancer ce script à intervalle régulier. Maintenant que l'esclave a une copie de la base Kerberos, vous pouvez démarrer krb5kdc:
shell% krb5kdc

Erreurs de propagation

kprop: No route to host while connecting to server
Assurez vous que le nom d'hôte de l'esclave est correct et que les firewalls entre le maître et l'esclave autorisent le port 754.
kprop: Connection refused while connecting to server
Si l'esclave tente de lancer kpropd via inetd, assurez vous que inetd est configuré pour accepter les connections krb5_prop. inetd a besoin de relire sa configuration pour qu'un changement soit pris en compte.
kprop: Server rejected authentication (during sendauth exchange) while authenticating to server
assurez vous que:

        1. L'heure est synchonisée
        2. Le fichier stash du maître a été copié sur l'esclave à l'emplacement attendu
        3. L'esclave a un fichier keytab contenant un principal host pour le nom d'hôte de l'esclave.

Ajouter des principaux à la base

   Une fois les KDC définis et fonctionnels, vous êtes prêt à utiliser kadmin pour charger les principaux pour vos utilisateurs, hôtes, et autres services dans la base kerberos. Vous pouvez occasionnellement utiliser un des esclaves comme maître. Cela peut se produire si vous mettez à jour le maître, ou si le maître crash.

Basculer de maître et d'esclave

   Si le KDC maître fonctionne, effectuez les étapes suivantes sur l'ancien maître:

        1. Tuer kadmind
        2. Désactiver le job cron qui propage la base
        3. Lancer le script de propagation manuellement, pour s'assurer que tous les esclaves ont la dernière copie de la base.

   Sur le nouveau maître:

        1. Démarrer Kadmind
        2. Définir un cron pour propager la base
        3. Bascules les CNAME de l'ancien vers le nouveau maître. Si vous ne pouvez pas le faire, vous aurez besoin de changer le fichier krb5.conf sun chaque client dans le domaine kerberos.