Download - Kerberized Credential Translation
Kerberized Credential TranslationOlga KornievskaiaPeter HoneymanBill DosterKevin Coffman
Center for Information Technology Integration
University of Michigan, Ann Arbor
Two worlds
Kerberos is a widely used authentication mechanism login, AFS, mail, LDAP
SSL is used to establish secure connections on the Web https, SSL-enabled Telnet
Need interoperability mechanisms
Webs Access Control
Example: access AFS content via the Web AFS is Kerberos protected, not SSL Web Server needs user’s Kerberos creds Candidate solutions
World-readable files file://afs/citi.umich.edu/u/...
Other problems requiring web access control Kerberized X.500 directory via Web Kerberized IMAP/POP mail servers via Web
Existing solutions and related work
Accessing Kerberized services via the Web Send id and password (securely) to the Web
Server Grants Web Server broad powers to impersonate the
user Kerberos authentication in TLS with support for
delegation Not supported by browsers No mechanism for fine-grained delegation
Perform access control at the Web Server
The best of both worlds
Leverage Kerberos to solve PKI key management problem
Use strong authentication over the Web Provide Web Interface for Kerberized
services through the Web Server Use existing infrastructures
Design Components
KX.509 creates short-lived certificates Web Server acquires Kerberos credentials
on client’s behalf Kerberized Credential Translator (KCT):
Translates client’s PK credentials to Kerberos
WebAFS prototype
KX.509 (junk keys)
Client acquires a service ticket for KCA Then generates a public-private key pair And sends the public key to KCA for
signing Service ticket, public key, MACsk(PK)
KCA generates a certificate Uses X.500 to map client identification Expiry of the certificate is set to that of the
Kerberos creds KCA sends the certificate back to the client
X.509 cert, MACsk(cert)
KX.509
Client stores certificate in Kerberos ticket cache
Netscape manages its own certificates and is unaware of KX.509 certs Added a cryptographic module to
Netscape Netscape calls our module when SSL
client authentication is requested
Web Server
Authenticates client with SSL Records transcript of SSL handshake Sends SSL transcript to KCT Receives and caches Kerberos credentials Authenticates to a backend service (say,
AFS) with received credentials
Kerberized Credential Translator
Kerberos authenticates the Web Server Receives and verifies an SSL transcript
Verifies client/server certs Verifies client’s signature in CLIENT_VERIFY Matches server identities in server cert and
server ticket Assures freshness of the transcript
Issues a service ticket for the client to the Web Server
KCT
Requires access to KDC database Needs the same physical security In practice, runs on the same machine
Avoids challenge of consistent replication Achieves physical security requirement
Performance
End-to-end delays
133 MHz Pentium, Red Hat 6.2 (2.2 kernel)
First access to index.html
4.040 s
Subsequent access to server
1.252 s
Accesses within a page (e.g, images)
0.022 s
Summary
A solution for Web Access Control KX.509 provides single sign-on capability Illustrated how an SSL handshake can be
used as a delegation mechanism Introduced a new mechanism to translate
PK credentials to Kerberos
Any questions?
Extra slides from here on….
Discussion
KX.509 anonymous certificates
KCT More powerful authorization model Different (not KX.509) PK – Kerberos identity mapping
Extensions Any SSL-enabled server (telnet): no more passwords
Overview of Kerberos
Initial authentication Request for a Ticket Granting Ticket
Request for a service ticket Request for a service ticket
Authentication to a Kerberized server
Overview of SSL Provides secure connections
Entity authentication Public key challenge-response protocol + X.509 certs
RSA, DH, Fortezza Message confidentiality
DES, 3DES, RC2, RC4, IDEA Message integrity
MD5, SHA Consists of 2 protocols: record and
handshake
SSL handshake
ClientHello
Certificate
ClientKeyExchange
CertificateVerify
Finished
ServerHello
Certificate
CertificateRequest
ServerHelloDone
Finished
Inside SSL handshake
ClientHello version, timestamp, random, session id,
cipher suite Certificate
X.509 certificate, CA chain ClientKeyExchange
[Key material]WSPK (in RSA) ClientVerify
[HMACMK(handshake msgs)]CPR
Important in SSL handshake
Timestamp serves as a nounce Used as a replay guard
SSL renegotiation establishes a new key Session ID allows for reuse of previously
established session keys Partial handshakes improve performance
Implementation issues
Netscape starts with an SSLv2 ClientHello Requires an SSL renegotiation or a request to
KCT for a nounce Chose to renegotiate
SSLv3 ClientVerify uses master secret Must reveal the secret to KCT
Requires an SSL renegotiation
Performance piece by piece
Components delays1 handshake 1.252 s
2 handshakes 2.495 s
TGT/KCT_TKT 0.029 s
KCT request 0.255 s
Partial handshake 0.022 s