Pkinit vs MD5

P a s c a l G a c h e t –E I V D
pascal.gachet@eivd.ch
mai 2002
 Résumé
Ce document décrit les différences qui interviennent au niveau protocolaire entre une
version de kerberos 5 standard et une version mettant en œuvre Pkinit, dans le cas
très concret de Microsoft Windows 2000 serveur. Ce document est prévu pour des
lecteurs qui ont déjà une bonne connaissance de protocole Kerberos.

Pkinit

Un des principaux objectifs du standard Pkinit est de permettre une interaction entre
une infrastructure à clés publique PKI et le protocole de gestion de clé Kerberos.
Les utilisateurs du domaine seront en mesure de s’authentifier auprès du KDC
Microsoft 2000 en utilisant un certificat x509 à la place du classique login et mot de
passe.

Le protocole Pkinit ne modifie pas la procédure de Kerberos permettant d’obtenir le

ticket TGT1 , mais il modifie uniquement le mécanisme d’authentification auprès du
service d’authentification AS 2 de Kerberos.

Dans un système conventionne l n’utilisant pas Pkinit, la procédure

d’authentification de Kerberos suit les étapes suivantes :

AS_Req
AS
AS_Rep

TGS

Client
W2K KDC

Le client désirant obtenir un ticket TGT pour le serveur TGS 3, doit en premier lieu
s’authentifier après du service d’authentification AS.
Cette authentification s’effectue dans le message AS_req. La méthode
d’authentification peut varier suivant les implémentations du protocole, les différentes
alternatives sont décrites dans le RFC 1510.

1
Ticket Granting Ticket
2
Autentication Service
3
Ticket Granting Service
De manière générique, l’authentification suit le déroulement suivant. Le message
AS_req contient deux informations : d’une part le nom de l’utilisateur et le nom du
service auquel il désire accéder, dans ce cas il s’agit du TGS ; et d’autre part une
information qui permet au AS de s’assurer que le client connaît son mot de passe.

Un champ de pré-authentification est prévu pour transporter le mot de passe

utilisateur. Le mot de passe n’est pas transmis en clair, mais le champ pré-
authentification contient un identificateur chiffré avec la master key, la master key
étant générée à l’aide d une fonction de hachage MD5 sur le mot de passe utilisateur.

Le AS connaît le mot de passe du client, il peut donc générer la même fonction de

hachage sur le mot de passe et donc s’assurer que le client est bien celui qu’il prétend
être en déchiffrant l’identificateur.

Le protocole Pkinit ne modifie que les messages contenus dans les champs pré-
authentification des messages échangés entre le client et le service d’authentification
AS.
Dans un système Pkinit, le mécanisme d’authentification suit le déroulement
suivant :
Le client envoie toujours un message AS-Req au serveur AS, ce message contient
dans le champ pré-authentification une liste de certificats de confiance, un
authentificateur signé (avec sa clé privée), et le certificat client.
L’authentificateur dépend de l’implémentation de kerberos, il contient généralement
le nom du KDC, une estampille temporelle et un Nonce.
Le serveur AS répond par un message AS-rep, ce message contient dans le champ
pré-authentification, le certificat serveur, une clé utilisée pour déchiffrer la partie
chiffrée du message AS-req, cette clé de déchiffrement étant bien entendu chiffrée
avec la clé publique du client.

Le client est alors en mesure de déchiffrer le message, ce message contient le ticket

TGT qui permettra de s’authentifier auprès du TGS.

Si en apparence le protocole Kerberos n’a été que peu affecté par la modification de la
procédure d’authentification, le mécanisme profond de contrôle de Kerberos est
passablement modifié. La politique de contrôle pour obtenir les credentials ne se base
plus sur un chiffrage symétrique et donc sur une connaissance des mots de passe
utilisateur, mais l’authentification intègre tous les mécanismes de contrôle PKI
nécessaires à une vérification en règle des certificats présentés, c’est-à-dire
vérification de la signature, et contrôle des CRL, mécanismes qui interviennent dans
une architecture à tiers de confiance.