11-Protocoles Authentification 2

Authentification mutuelle
Protocoles dauthentification
Utilis pour convaincre les parties de

lidentit lune de lautre et pour changer
des cls de session
Protocole mutuel
Faire attention
la confidentialit protection des cls de

session
Au paramtre de temps empcher le rejeu
Protocoles dauthentification - 2
Approche symtrique
comme discut prcdemment, on peut employer

une hirarchie deux niveaux des clefs
Approche symtrique
Transfert confidentiel de donnes

Transfert confidentiel de cl
Needham-Schroeder
protocole de distribution de cl avec un tiers mdiateur

pour une session entre A et B, ngoci par le KDC
1.
A KDC : IDA || IDB || N1
habituellement avec un centre de distribution de

cl (KDC)
2.
3.
KDC A : EKa[Ks || IDB || N1 || EKb [Ks || IDA]]

A B : EKb[Ks||IDA]
Chaque partie partage une cl principale avec le KDC

Le KDC produit des clefs de session utilises pour les
communications entre les parties
Les cls principales sont utilises pour distribuer ces cls
de session aux parties
4.
B A : EKs[N2]
5.
A B : EKs[f(N2)]
Approche par cl publique
Approche symtrique
utilis pour distribuer srement une nouvelle cl de

session entre A et B
mais est vulnrable une attaque par rejeu si une
vieille cl de session a t compromise
Rejeu du message 3 qui convainc B que A communique

avec lui
Timestamp (Denning 81)
Employer un nonce supplmentaire (Neuman 93)
Ncessit de s'assurer que les clefs publiques dont

on dispose correspondent aux bonnes personnes
Utilisation d'un serveur central d'authentification
(AS)
modifications pour contrer ce risque :
On dispose de diffrentes alternatives bases sur

l'utilisation du chiffrement cl publique
(plutt que KDC puisque plus responsable de la

distribution des cls)
Divers protocoles existent utilisant des horodateurs

ou des nonces
Denning :
1. A KDC :
IDA||IDB
2. KDC A :
EKa[Ks||IDB||T||EKb[Ks||IDA||T]]
3. A B :
EKb[Ks||IDA||T]
4. B A :
EKs[N1]
5. A B :
EKs[f(N1)]
Attention la synchronisation des horloges.

1. A B :
IDA||Na
2. B KDC :
IDB||Nb||EKb[IDA||Na||Tb]
3. KDC A :
EKa[IDB||Na||Ks||Tb]||EKb[IDA||Ks||Tb]||Nb
4. A B :
EKb[IDA||Ks||Tb]||EKs[Nb]
Authentification par passage unique
Protocole de Denning utilisant un AS :
A AS : IDA || IDB
AS A : EKRas[IDA||KUa||T] || EKRas[IDB||KUb||T]
A B : EKRas[IDA||KUa||T] || EKRas[IDB||KUb||T] || EKUb[EKRas[Ks||T]]
Remarques :
la clef de session est choisie par A, par consquent, il nest pas

ncessaire de faire confiance lAS pour la protger
les horodateurs empchent le rejeu mais exigent des horloges
synchronises
Solution pour la dsynchronisation [Woo & Lam 92]: (on fonctionne avec des certificats)
A KDC :
KDC A :
EKRauth[IDB||KUb]
AB:
EKUb[Na||IDA]
B KDC :
IDB||IDA || EKUauth[Na]
ID1||IDB
EKRauth[IDA||KUa] || EKUb[EKRauth[Na || Ks || IDB]]
KDC B :
BA:
EKUa[EKRauth[Na||Ks||IDB]||Nb]
AB:
EKs[Nb]
Renforcement [WOO & LAM 92]

1. A KDC :
IDA||IDB
2. KDC A :
EKRauth[IDB||KUb]
3. A B :
EKUb[Na||IDA]
4. B KDC :
IDB||IDA||EKUauth[Na]
5. KDC B :
EKRauth[IDA||KUa] || EKUb[EKRauth[Na||Ks||IDB]]
6. B A :
EKUa[EKRauth[Na||Ks||IDA||IDB]||Nb]
7. A B :
EKs[Nb]
requis quand l'expditeur et le rcepteur ne sont

pas en communication en mme temps (p.e. email)
L'en-tte est en clair, ainsi il peut tre compris par
le systme d'email
On souhaite que le contenu du corps du texte soit
protg et que l'expditeur soit authentifi
Approche symtrique
Raffinement de l'utilisation de KDC :

1. A KDC :
IDA || IDB || N1
2. KDC A :
EKa[Ks || IDB || N1 || EKb[Ks||IDA]]
3. A B :
EKb[Ks||IDA] || EKs[M]
Plusieurs alternatives ont dj t prsentes
Si la confidentialit est le souci principal :
A B: EKUb[Ks] || EKs[M]
Garanti un certain niveau dauthentification
Ne protge pas du rejeu
On pourrait utiliser des timestamps mais les dlais des

mails rendent ce systme problmatique
La cl de session est chiffre avec la cl publique de B, le

message est chiffr avec cette cl de session
Si lauthentification est importante : utiliser une

signature numrique avec un certificat numrique :
AB: M || EKRa[H(M)] || EKRas[T||IDA||KUa]
message, signature, certificat sont fournis
Kerberos
Kerberos
systme de serveur de distribution de cl propos

par le MIT
fournit un authentification centralise cl prive
dans un rseau distribu
permet l'accs pour les utilisateurs aux services distribus propos

par le rseau
sans devoir faire confiance tous les postes de travail
mais plutt en
d'authentification
faisant
confiance
un
serveur
central
deux versions en service : 4 et 5
11
Conditions remplir
Kerberos 4 vue gnrale
Conditions remplir :
scurit
fiabilit
transparence
scalabilit
utilise un protocole d'authentification bas sur

Needham-Schroeder
Schma dauthentification basique utilisant un tiers

de confiance
Le KDC
Dispose dun serveur dauthentification (AS)
Les utilisateurs ngocient avec lAS pour sidentifier
AS fournit un ticket dauthentification non corruptible (Ticket

Granting Ticket - TGT)
Dispose dun serveur de ticket (Ticket Granting Server

TGS)
Les utilisateurs demandent un accs des services proposs

par le TGS sur base de leur TGT
Messages changs
4
3
5
6
1. L'utilisateur se logge sur poste de travail et demande un service lAS.
KC : cl calcule partir du mot de passe de C
2. LAS vrifie les droits d'accs de l'utilisateur dans la base de donnes, cre
un ticket (TGT) et une cl de session. Ces rsultats sont chiffrs en utilisant
une cl drive du mot de passe de l'utilisateur.
Kc,tgs : est chiffre par KC (chiffrement DES) et donc seul C peut la lire
3. Le poste de travail demande le mot de passe de lutilisateur et lutilise pour

dchiffrer le message venant du serveur, puis il envoie le TGT et un
authentificateur qui contient le nom de l'utilisateur, l'adresse rseau du poste
de travail et un horodateur au TGS.
4. Le TGS dchiffre le ticket et l'authentificateur, vrifie la demande, puis cre
le ticket pour le serveur (service) demand.
5. Le poste de travail envoie ce ticket et l'authentificateur au serveur concern.
6. Le serveur vrifie que ce ticket et l'authentificateur correspondent et accorde
alors l'accs au service. Si l'authentification mutuelle est exige, le serveur
renvoie un authentificateur.
Domaines Kerberos
un environnement Kerberos se compose de :
un serveur de Kerberos
un certain nombre de clients, tout inscrits au serveur
serveurs d'application, partageant des cls avec le serveur
est appel domaine Kerberos (realm)
Typiquement un domaine dadministration simple
si on a des domaines Kerberos multiples, les

diffrents serveurs Kerberos doivent partager des
cls et se faire confiance
1. C AS :
IDc || IDtgs || TS1
2. AS C :
EKc[Kc,tgs|| IDtgs || TS2 || Lifetime2 || Tickettgs]
3. C TGS :
IDtgsrem || Tickettgs || Authenticatorc
4. TGS C :
EKc,tgs[Kc,tgsrem || IDtgsrem || TS4 || Tickettgsrem]
5. C TGSrem :
IDvrem || Tickettgsrem ||Authenticatorc
6. TGSrem C :
EKc,tgsrem[Kc,vrem || IDvrem || TS6 || Ticketvrem]
7. C Vrem :
Ticketvrem || Authenticatorc
Kerberos Version 5
dvelopp dans le milieu des annes 90
fournit des amliorations de v4
corrige des imperfections environnementales
et des insuffisances techniques
alg de chiffrage, protocole rseau, ordre de byte, temps de vie du

ticket, transfert d'authentification, authentification inter-domaines
double chiffrement , mode non-STD, clefs de session, attaques de
mot de passe
Repris dans la RFC 1510
(1)
Realm : indique le domaine de lutilisateur
Options : utilis pour demander que certains flags soient positionns dans le
ticket obtenu en retour
Times : permet de prciser les balises de dure de vie du ticket : from, till, rtime
Nonce : valeur alatoire assurant de la fracheur de linformation obtenue
(5)
Subkey : proposition du client pour lutilisation dune cl de chiffrement utiliser
les informations qui transiteront dans cette session. Si le paramtre est omis,
cest Kc,v qui sera utilise
Squence number : prcise le numro de squence partir duquel seront
numrots les messages changs pendant la session (vite les rejeux)
Comparaisons des menaces sur le Web
Scurit WEB - Rseaux
Intgrit
Menaces
Consquences
Contre-mesures
modification des
donnes utilisateur
Perte
Checksum
cryptographiques
Cheval
compromise
de Troie
Modification
de la
mmoire
Confidentialit
coute
Vol
sur le net
dinformations
dinformation
Machine
Vulnrabilits
aux
autres menaces
perte dinformation Chiffrement,

proxies internet
dintimit
Perte
(client, serveur,
configuration du
rseau, )
21
Comparaisons des menaces sur le Web

Dni de service
Menaces
Consquences
Contremesures
destruction des
threads
utilisateurs
Interruption
Difficile
empcher
Flooding
de
machines,
Saturation
Empche
le travail
Localisation de la scurit
effectif
Ralentissement
de
disques
Authentification
Mascarade
Fabrication/
modification
dinformations
mauvaise
prsentation de
lutilisateur
Techniques
cryptographiques
Utilisation
dinformations fausses
SSL (Secure Socket Layer)
Applications dauthentification
SSL
Service de scurit de la couche transport
Dvelopp l'origine par Netscape
Protocole : SSL
Norme : TLS (Transport Layer Security)
Utilisations de TCP pour fournir un service bout

bout fiable
25
Objectifs
SSL Architecture
Authentifier un serveur SSL et un client SSL

(optionnel)
Echanger une cl de session
Etablir une session confidentielle et intgre au sein
de laquelle plusieurs connexions pourront avoir
lieu.
Ce protocole est compos de 2 sous-couches :

Une couche qui dfinit la faon dont seront traites les donnes
chiffrer
Une couche qui gre ltablissement de la connexion scurise
et la ngociation des paramtres de la session
SSL - Architecture
SSL Record Protocol
Session SSL
association entre le client et le serveur
cr par le handshake protocol
dfinit un ensemble de paramtres cryptographiques
peut tre partag par des connexions SSL multiples
Fournit 2 services :
Connexion SSL
liaison peer to peer
lie 1 session de SSL
confidentialit
Via un chiffrement symtrique avec une clef secrte partage

dfinie dans le Handshake Protocol
IDEA, RC2-40, DES-40, DES, 3DES, Fortezza, RC4-40, RC4-128
Compression du message avant chiffrement
intgrit de message
utilisation d'un MAC avec la clef secrte partage
semblable HMAC mais avec un padding diffrent
SSL Record Protocol
SSL Record Protocol
Calcul du MAC :
Hash (MAC_write_secret || pad_2 || hash (MAC_write_secret || pad_1 ||

seq_num || SSLCompressed.type || SSLCompressed.length ||
SSLCompressed.fragment))
Format du SSL Record :
Fragmentation : chaque message est fragment en blocs de 214 bytes ou moins.
Calcul du MAC :
Compression : optionnel : doit tre sans pertes et ne doit pas augmenter la taille
du contenu de plus de 1024 bytes
MAC_write_secret : la cl secrete partage
MAC : on utilise une cl secrte partage des 2 parties (voir page suivante)
Pad_1 : byte 0x36 (0011 0110) rpt 48 fois (384 bits) pour le MD5 et 40 fois
pour le SHA-1
Chiffrement : symtrique : ne doit pas augmenter la longueur du contenu de plus

de 1024 bytes et donc la longueur totale ne doit pas excder 214 + 2048 bytes.
Les algorithmes permis sont : DES, 3DES, IDEA,
Hash : algorithme MD5 ou SHA-1
Pad_2 : byte 0x5C (0101 1100) rpt 48 fois pour le MD5 et 40 fois pour le
SHA-1
Padding : aprs le mac
Seq_num : numro de squence pour ce message
Le header contient :
SSLCompressed.type : le protocole de haut niveau utilis pour manipuler ce

fragment
Content type (8 bits) : le protocole utilis pour manipuler le fragment :

change_cipher_spec, alert, handshake, application_data
SSLCompressed.length : longueur du fragment compress

SSLCompressed.fragment : le fragment compress
Major version (8 bits) : version ssl utilise : souvent 3

Minor version (8 bits) : si sslv3 : valeur = 0
Compressed length (16 bits) : longueur du fragment de texte clair
Algorithme similaire HMAC except que les paddings sont concatns ici et
pas manipuls par le biais dun XOR
SSL Change Cipher Spec Protocol
SSL Alert Protocol
Lanc au cours du handshake
transmet des alertes connexes SSL
But : synchroniser les stratgies de chiffrement utilises par

le client et le serveur.
svrit
Etapes :
Au cours du handshake, les paramtres de chiffrement sont

ngocis et calculs
A lenvoi du message Change_cipher_specs, les nouveaux
paramtres sont copis dans la stratgie courante pour tre
directement utiliss par la couche SSL Record
alerte spcifique
Ces nouveaux paramtres constituent une stratgie temporaire
avertissement ou fatal e
message inattendu, mauvais MAC, chec de dcompression, chec

de handshake, paramtre illgal
la fin annoncent, aucun certificat, mauvais certificat, certificat non
support, certificat rvoqu, certificat a expir, certificat inconnu
comprim et chiffr comme toutes les donnes de SSL
SSL Handshake Protocol
permet au serveur et au client de :
SSL Handshake Protocol
s'authentifier
ngocier les algorithmes de chiffrement et de MAC
ngocier les cls cryptographiques employer
comporte 4 phases dchanges de messages
Etablissement des possibilits en matire de scurit.

Cette phase dtermine entre autres :
La version, la session, les algorithmes de chiffrement et

compression, des nombres alatoires
Authentification du serveur et change de cl

Authentification du client et change de cl
Clture
Phase 1 : hello
Phase 1 : hello
Lors du dmarrage de ce protocole, les paramtres

de chiffrement sont initialiss 0 (c--d pas
dalgorithme de chiffrement, de hash, de signature
dfinis)
Client_hello contient la combinaison des algorithmes

cryptographiques supports par le client, par ordre
dcroissant de prfrence.
Client_hello est compos de :
N de version SSL (2 ou 3)
N alatoire du client
N de session (optionnel) (permet de rcuprer les paramtres de

scurit dune connexion antrieure)
Liste des stratgies de chiffrements supportes, par ordre
dcroissant de prfrence ( DES, 3DES, IDEA, )
Algorithmes de compression supports. (MD5, SHA-1, )
Server_hello contient la mthode dchange de cl et les

paramtres de chiffrement slectionns parmi ceux
proposs par le client.
Phase 1 : hello
Mthodes dchange de cl
Server_hello comporte :
N de version SSL (en fonction de celui support par le client)
N alatoire du serveur
N de session (soit ancien, soit nouveau)
Stratgie de chiffrement choisie (en fonction de celles du client)
Algorithme de compression choisi (en fonction de ceux du client)
bases sur une version de lalgorithme DiffieHellman et/ou du RSA
Remarque : si le serveur accepte de rutiliser une session

antrieure, il renvoie le mme session ID au client et le
protocole de handshake se termine automatiquement.
DH anonyme : il sagit de lalgorithme de base.
Il est sujet lattaque man-in-the-middle car les paramtres DH

ne sont pas authentifis
DH fix : les paramtres de DH sont fixs une fois pour

toutes et publis au moyen dun certificat.
contre lattaque man-in-the-middle mais pas une attaque par force

brute
Phase 2 : authent. serveur et change de cl
Mthodes dchange de cl
DH phmre :
les paramtres DH peuvent changer dune session lautre.
Les paramtres DH sont en plus signs grce la cl RSA prive

de lexpditeur pour contrer lattaque man-in-the-middle.
rend une attaque par force brute bien plus difficile raliser.
implique que lexpditeur dispose dune paire de cl RSA
RSA :
Remarque : les changes concernant les certificats sont

directement lis aux paramtres cryptographiques de
lchange de cl.
Certificate envoie le certificat au client.
La cl secrte est chiffre grce la cl publique du receveur.
Cela implique quun certificat du receveur soit disponible afin dobtenir

sa cl publique de faon fiable.
Cette mthode assure la confidentialit des cls mais nassure pas

lauthentification de lexpditeur mais ce nest pas le but
Il nest pas envoy sil sagit dun DH anonyme.

Il contient aussi les paramtres de la cl publique DH sil sagit
dun DH fix.
Pour lenvoi des paramtres, utilisation dune signature :

Sign = hash(ClientHello.random || ServerHello.random || ServerParams)
Phase 2 : authent. serveur et change de cl
Server_key_exchange envoie
relatifs la cl de session.
paramtres
Nest pas envoy si DH fix (car dj fournis dans le

certificat) ou RSA sont utiliss
Certificate_request demande le certificat du client.
les
Phase 3 : authent. client et change de cl
Certificate : le client vrifie dabord le certificat du serveur

sil la reu ensuite envoie son certificat au serveur si celuici la demand
Client_key_exchange est similaire Server_key_exchange.

En fonction du mcanisme dchange de cl utilis, le client
gnre une cl matresse primaire (PMK) (Nbre alatoire de
48 bytes) et lenvoie au serveur.
Ne sera pas envoy si un DH anonyme est utilis.
Server_hello_done marque la fin de la phase de

hello pour le serveur
! La mthode dchange choisie
PMK (pre master key) : 48 bytes : cette pmk est utilise pour calculer la cl de
session (master key)
Phase 3 : authent. client et change de cl
Client_certificate_verify est envoy aprs la

gnration de la cl matresse de session (MK).
Il ne sera pas envoy si un DH fix est utilis.
Ce message est utilis par le client pour prouver

quil dispose de la cl prive associ au certificat.
Gnration des cls
Valeur de 48 bytes gnre pour la session
2 tapes :
Echange dune cl pre

-
Calcul de la master key (MK)
Echange de la PMK
master (PMK)
RSA : chiffrement dune cl avec la cl publique du

serveur
DH : change de cl publique DH
Gnration des cls calcul de MK
X : ClientHello.random
Y : ServerHello.random
MK =
Phase 4 : finish
MD5( PMK || SHA ( A || PMK || X || Y ))

|| MD5( PMK || SHA ( BB || PMK || X || Y ))
|| MD5( PMK || SHA ( CCC || PMK || X || Y ))
Change_cipher_spec fait partie du protocole

Cipher Spec. Il a pour but de transformer la
stratgie temporaire en stratgie courante.
Le message Finished vrifie que lchange de cl
et les processus dauthentification se sont
correctement drouls.
Phase 4 : finish
TLS (Transport Layer Security)
Il sagit galement des premiers messages utilisant

la stratgie de chiffrement ngocie au cours du
handshake .
Aprs le message Finished, le client et le serveur
schangent des messages venant des couches
applicatives sur base des paramtres contenus
dans ltat de la session.
standard IETF (RFC 2246) semblable SSLv3
avec des diffrences mineures
dans le nombre de version de format d'enregistrement
utilisations HMAC pour le calcul de MAC
une fonction pseudo

- alatoire intervient dans le calcul de
cl
codes alertes additionnels
changements des chiffrements supports
changements des ngociations de certificat
changements dans lutilisation du padding

Secure Electronic Transactions (SET)
Applications dauthentification
SET
ouvrir les spcifications de chiffrage et de scurit
pour protger des transactions lies aux cartes de crdit sur

Internet
dvelopp en 1996 par Mastercard, visa etc..
pas un systme de paiement
plutt un ensemble de protocoles et de formats de scurit
Communications scurise entre les parties
Utilisation des certificats X.509v3
intimit en restreignant linformation ceux qui en ont besoin
51
Spcification dtaille dans 3 livres (voir www.setco.org)
SET vue gnrale (contraintes)
Fournir la confidentialit des paiements et des

informations lies
Assurer lintgrit des donnes transfres
Fournir lauthentification permettant de vrifier la
lgitimit de lutilisateur dune carte
SET vue gnrale (points importants)
Confidentialit de linformation
Intgrit des donnes
Fournir lauthentification du marchand
Chiffrement DES, seule la banque peut lire le n de carte

Signatures digitales RSA, SHA
- 1+ HMAC
Authentification du propritaire de la carte
Certificat X.509v3 + signatures RSA
Authentification du marchand
Protection optimale de toutes les parties de la

transaction
Indpendant des protocoles, plate-formes, OSs,
choix des algorithmes impos
Certificat X.509v3 + signatures RSA
SET Transaction
SET composants
1.
le client ouvre le compte
2.
le client reoit un certificat
3.
les ngociants ont leurs propres certificats
4.
le client passe une commande
5.
le ngociant est vrifi
6.
l'ordre et le paiement sont envoys
7.
le ngociant demande l'autorisation de paiement
8.
le ngociant confirme l'ordre
9.
le ngociant fournit des marchandises ou le service
10.
le ngociant demande le paiement

Signature duale
Fonctionnement dune signature duale
le client cre les messages duaux
l'information de commande (OI) pour le ngociant
l'information de paiement (PI) pour la banque
ni l'une ni l'autre partie n'a besoin des dtails de

lautre
mais doit savoir qu'ils sont lis
employer une signature duale pour ceci
Signature des condenss enchans d'OI et de PI
Fonctionnement du paiement
Commande - client
Nombreuses transactions possibles (voir tables)
Principales :
Commande
Autorisation de paiement
Capture du paiement
Commande marchand (vrification)
Commande - Autorisation marchand

1. Vrifie des certificats de dtenteur de carte en utilisant des
signatures de CA
2. Vrifie la signature duale en utilisant la clef publique de
signature du client pour sassurer que la commande n'a
pas t manipule pendant son transit et quelle a t
signe en utilisant la clef prive de signature du dtenteur
de la carte
3. Fait suivre l'information de paiement au gateway de
paiement pour l'autorisation (dcrite plus tard) et effectue
la commande
4. Envoie une rponse d'achat au dtenteur de carte
Autorisation du gateway de paiement
Paiement
1. Vrifie tous les certificats

2. Dchiffre l'enveloppe numrique du bloc d'autorisation pour
obtenir la clef symtrique et dchiffre alors le bloc
d'autorisation
3. Vrifie la signature du ngociant sur le bloc d'autorisation
4. Dchiffre l'enveloppe numrique du bloc de paiement pour
obtenir la clef symtrique et dchiffre alors le bloc de
paiement
5. Vrifie la signature duale sur le bloc de paiement
6. Vrifie que lidentificateur de transaction reu du marchand
correspond celui reu (indirectement) dans le PI du client
7. Demande et reoit une autorisation de lissuer
8. Renvoie la rponse d'autorisation au ngociant
1. le ngociant envoie gateway de paiement une

demande de paiement
2. Le gateway vrifie la demande

3. Effectue le transfert de fond vers le compte du
ngociant
4. informe le ngociant du transfert
Questions
Rfrences
Protocoles dauthentification
Approche symtrique, cls publiques
Kerberos
SSL
SET
[Stallings] ch 13,14,17
www.setco.org
http://web.mit.edu/kerberos/www/
http://rambit.qc.ca/plamondon/crypto.htm
http://www.cryptography.com/resources/researchlin
ks.html#ssl
http://www.openssl.org/

11-Protocoles Authentification 2

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

11-Protocoles Authentification 2

Uploaded by

Copyright:

Available Formats

Authentification mutuelle

Utilis pour convaincre les parties de

la confidentialit protection des cls de

comme discut prcdemment, on peut employer

Transfert confidentiel de donnes

protocole de distribution de cl avec un tiers mdiateur

A KDC : IDA || IDB || N1

habituellement avec un centre de distribution de

KDC A : EKa[Ks || IDB || N1 || EKb [Ks || IDA]]

Chaque partie partage une cl principale avec le KDC

Approche par cl publique

utilis pour distribuer srement une nouvelle cl de

Rejeu du message 3 qui convainc B que A communique

Timestamp (Denning 81)

Employer un nonce supplmentaire (Neuman 93)

Ncessit de s'assurer que les clefs publiques dont

modifications pour contrer ce risque :

On dispose de diffrentes alternatives bases sur

(plutt que KDC puisque plus responsable de la

Divers protocoles existent utilisant des horodateurs

Attention la synchronisation des horloges.

Approche par cl publique

Authentification par passage unique

Protocole de Denning utilisant un AS :

A B : EKRas[IDA||KUa||T] || EKRas[IDB||KUb||T] || EKUb[EKRas[Ks||T]]

la clef de session est choisie par A, par consquent, il nest pas

EKRauth[IDA||KUa] || EKUb[EKRauth[Na || Ks || IDB]]

Renforcement [WOO & LAM 92]

requis quand l'expditeur et le rcepteur ne sont

Approche par cl publique

Raffinement de l'utilisation de KDC :

EKa[Ks || IDB || N1 || EKb[Ks||IDA]]

Plusieurs alternatives ont dj t prsentes

Si la confidentialit est le souci principal :

Garanti un certain niveau dauthentification

Ne protge pas du rejeu

On pourrait utiliser des timestamps mais les dlais des

La cl de session est chiffre avec la cl publique de B, le

Si lauthentification est importante : utiliser une

AB: M || EKRa[H(M)] || EKRas[T||IDA||KUa]

message, signature, certificat sont fournis

systme de serveur de distribution de cl propos

permet l'accs pour les utilisateurs aux services distribus propos

deux versions en service : 4 et 5

Kerberos 4 vue gnrale

utilise un protocole d'authentification bas sur

Schma dauthentification basique utilisant un tiers

Dispose dun serveur dauthentification (AS)

Les utilisateurs ngocient avec lAS pour sidentifier

AS fournit un ticket dauthentification non corruptible (Ticket

Dispose dun serveur de ticket (Ticket Granting Server

Les utilisateurs demandent un accs des services proposs

1. L'utilisateur se logge sur poste de travail et demande un service lAS.

KC : cl calcule partir du mot de passe de C

3. Le poste de travail demande le mot de passe de lutilisateur et lutilise pour

un environnement Kerberos se compose de :

un certain nombre de clients, tout inscrits au serveur

serveurs d'application, partageant des cls avec le serveur

est appel domaine Kerberos (realm)

Typiquement un domaine dadministration simple

si on a des domaines Kerberos multiples, les

IDc || IDtgs || TS1

EKc[Kc,tgs|| IDtgs || TS2 || Lifetime2 || Tickettgs]

IDtgsrem || Tickettgs || Authenticatorc