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 u SSL is used to establish secure connections on the Web u u login, AFS, mail, LDAP https, SSL-enabled Telnet Need interoperability mechanisms
Webs Access Control u Example: access AFS content via the Web u u u AFS is Kerberos protected, not SSL Web Server needs user’s Kerberos creds Candidate solutions World-readable files u file: //afs/citi. umich. edu/u/. . . u u Other problems requiring web access control u u Kerberized X. 500 directory via Web 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 u Grants Web Server broad powers to impersonate the user Kerberos authentication in TLS with support for delegation Not supported by browsers u No mechanism for fine-grained delegation u u Perform access control at the Web Server
The best of both worlds u u 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 u u u KX. 509 creates short-lived certificates Web Server acquires Kerberos credentials on client’s behalf Kerberized Credential Translator (KCT): u u Translates client’s PK credentials to Kerberos Web. AFS prototype
KX. 509 (junk keys) u u u Client acquires a service ticket for KCA Then generates a public-private key pair And sends the public key to KCA for signing u u KCA generates a certificate u u u 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 u X. 509 cert, MACsk(cert)
KX. 509 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 u
Web Server u u u 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 u u Kerberos authenticates the Web Server Receives and verifies an SSL transcript u u u 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 u u u Requires access to KDC database Needs the same physical security In practice, runs on the same machine u u Avoids challenge of consistent replication Achieves physical security requirement
Performance u End-to-end delays First access to index. html Subsequent access to server 1. 252 s Accesses within a page (e. g, images) u 4. 040 s 0. 022 s 133 MHz Pentium, Red Hat 6. 2 (2. 2 kernel)
Summary u u 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 u KX. 509 u u KCT u u u anonymous certificates More powerful authorization model Different (not KX. 509) PK – Kerberos identity mapping Extensions u Any SSL-enabled server (telnet): no more passwords
Overview of Kerberos u Initial authentication u u Request for a service ticket u u Request for a Ticket Granting Ticket Request for a service ticket 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 u Message confidentiality u u DES, 3 DES, RC 2, RC 4, IDEA Message integrity u u RSA, DH, Fortezza MD 5, SHA Consists of 2 protocols: record and handshake
SSL handshake Client. Hello Certificate Client. Key. Exchange Certificate. Verify Finished Server. Hello Certificate. Request Server. Hello. Done Finished
Inside SSL handshake u Client. Hello u u Certificate u u X. 509 certificate, CA chain Client. Key. Exchange u u version, timestamp, random, session id, cipher suite [Key material]WSPK (in RSA) Client. Verify u [HMACMK(handshake msgs)]CPR
Important in SSL handshake u Timestamp serves as a nounce u u u Used as a replay guard SSL renegotiation establishes a new key Session ID allows for reuse of previously established session keys u Partial handshakes improve performance
Implementation issues u Netscape starts with an SSLv 2 Client. Hello u Requires an SSL renegotiation or a request to KCT for a nounce u u Chose to renegotiate SSLv 3 Client. Verify uses master secret u Must reveal the secret to KCT u Requires an SSL renegotiation
Performance piece by piece u 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
Скачать презентацию Kerberized Credential Translation Olga Kornievskaia Peter Honeyman Bill
091c34facd43c0cf10445918171fd80f.ppt