Kerberized Credential Translation
Olga Kornievskaia
Peter Honeyman
Bill Doster
Kevin Coffman
Center for Information Technology Integration
University of Michigan, Ann Arbor
Two worlds

Kerberos is a widely used authentication
mechanism


SSL is used to establish secure connections
on the Web


login, AFS, mail, LDAP
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


Kerberos authentication in TLS with support for
delegation



Grants Web Server broad powers to impersonate the
user
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


KCA generates a certificate



Service ticket, public key, MACsk(PK)
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
First access to
index.html
Subsequent access to
server
4.040 s
Accesses within a page
(e.g, images)
0.022 s
1.252 s
133 MHz Pentium, Red Hat 6.2 (2.2 kernel)
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


KCT



anonymous certificates
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 service ticket


Request for a Ticket Granting 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


Message confidentiality


DES, 3DES, RC2, RC4, IDEA
Message integrity


RSA, DH, Fortezza
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


Certificate


X.509 certificate, CA chain
ClientKeyExchange


version, timestamp, random, session id, cipher
suite
[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 delays
1 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