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