Kerberized Credential Translation Olga Kornievskaia Peter Honeyman Bill Doster
Download
Report
Transcript Kerberized Credential Translation Olga Kornievskaia Peter Honeyman Bill Doster
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