Kerberized Credential Translation Olga Kornievskaia Peter Honeyman Bill Doster Kevin Coffman Center for Information Technology Integration University of Michigan, Ann Arbor

Two worlds u Kerberos is a widely used authentication mechanism u login, AFS, mail, LDAP u SSL is used to establish secure connections on the Web u https, SSL-enabled Telnet u Need interoperability mechanisms

Webs Access Control u Example: access AFS content via the Web u AFS is Kerberos protected, not SSL u Web Server needs user’s Kerberos creds u Candidate solutions u World-readable files u file://afs/citi.umich.edu/u/... u Other problems requiring web access control u Kerberized X.500 directory via Web u Kerberized IMAP/POP mail servers via Web

Existing solutions and related work u Accessing Kerberized services via the Web u Send id and password (securely) to the Web Server u Grants Web Server broad powers to impersonate the user u Kerberos authentication in TLS with support for delegation u Not supported by browsers u No mechanism for fine-grained delegation u Perform access control at the Web Server

The best of both worlds u Leverage Kerberos to solve PKI key management problem u Use strong authentication over the Web u Provide Web Interface for Kerberized services through the Web Server u Use existing infrastructures

Design Components u KX.509 creates short-lived certificates u Web Server acquires Kerberos credentials on client’s behalf u Kerberized Credential Translator (KCT): u Translates client’s PK credentials to Kerberos u WebAFS prototype

KX.509 (junk keys) u Client acquires a service ticket for KCA u Then generates a public-private key pair u And sends the public key to KCA for signing u Service ticket, public key, MAC sk (PK) u KCA generates a certificate u Uses X.500 to map client identification u Expiry of the certificate is set to that of the Kerberos creds u KCA sends the certificate back to the client u X.509 cert, MAC sk (cert)

KX.509 u Client stores certificate in Kerberos ticket cache u Netscape manages its own certificates and is unaware of KX.509 certs u Added a cryptographic module to Netscape u Netscape calls our module when SSL client authentication is requested

Web Server u Authenticates client with SSL u Records transcript of SSL handshake u Sends SSL transcript to KCT u Receives and caches Kerberos credentials u Authenticates to a backend service (say, AFS) with received credentials

Kerberized Credential Translator u Kerberos authenticates the Web Server u Receives and verifies an SSL transcript u Verifies client/server certs u Verifies client’s signature in CLIENT_VERIFY u Matches server identities in server cert and server ticket u Assures freshness of the transcript u Issues a service ticket for the client to the Web Server

KCT u Requires access to KDC database u Needs the same physical security u In practice, runs on the same machine u Avoids challenge of consistent replication u Achieves physical security requirement

Performance u End-to-end delays u 133 MHz Pentium, Red Hat 6.2 (2.2 kernel) First access to index.html s Subsequent access to server s Accesses within a page (e.g, images) s

Summary u A solution for Web Access Control u KX.509 provides single sign-on capability u Illustrated how an SSL handshake can be used as a delegation mechanism u Introduced a new mechanism to translate PK credentials to Kerberos

Any questions?

Extra slides from here on….

Discussion u KX.509 u anonymous certificates u KCT u More powerful authorization model u Different (not KX.509) PK – Kerberos identity mapping u Extensions u Any SSL-enabled server (telnet): no more passwords

Overview of Kerberos u Initial authentication u Request for a Ticket Granting Ticket u Request for a service ticket u Authentication to a Kerberized server

Overview of SSL u Provides secure connections u Entity authentication u Public key challenge-response protocol + X.509 certs u RSA, DH, Fortezza u Message confidentiality u DES, 3DES, RC2, RC4, IDEA u Message integrity u MD5, SHA u Consists of 2 protocols: record and handshake

SSL handshake ClientHello Certificate ClientKeyExchange CertificateVerify Finished ServerHello Certificate CertificateRequest ServerHelloDone Finished

Inside SSL handshake  ClientHello u version, timestamp, random, session id, cipher suite  Certificate u X.509 certificate, CA chain  ClientKeyExchange u [Key material] WSPK (in RSA)  ClientVerify u [HMAC MK (handshake msgs)] CPR

Important in SSL handshake u Timestamp serves as a nounce u Used as a replay guard u SSL renegotiation establishes a new key u Session ID allows for reuse of previously established session keys u Partial handshakes improve performance

Implementation issues u Netscape starts with an SSLv2 ClientHello u Requires an SSL renegotiation or a request to KCT for a nounce u Chose to renegotiate u SSLv3 ClientVerify uses master secret u Must reveal the secret to KCT u Requires an SSL renegotiation

Performance piece by piece u Components delays 1 handshake1.252 s 2 handshakes2.495 s TGT/KCT_TKT0.029 s KCT request0.255 s Partial handshake0.022 s