1 / 36

Advanced Client/Server Authentication in TLS

Advanced Client/Server Authentication in TLS. Adam Hess, Jared Jacobson, Hyrum Mills, Ryan Wamsley, Kent E. Seamons, Bryan Smith Internet Security Research Lab Brigham Young University http://isrl.cs.byu.edu seamons@cs.byu.edu Network and Distributed System Security Symposium

tburpee
Download Presentation

Advanced Client/Server Authentication in TLS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Advanced Client/Server Authentication in TLS Adam Hess, Jared Jacobson, Hyrum Mills, Ryan Wamsley, Kent E. Seamons, Bryan Smith Internet Security Research Lab Brigham Young University http://isrl.cs.byu.edu seamons@cs.byu.edu Network and Distributed System Security Symposium February 7-8, 2002 San Diego, CA

  2. Overview • Motivation • Trust negotiation • Trust negotiation protocol vs. strategy • TLS client/server authentication • Trust negotiation in TLS (TNT) protocol • Future work • Conclusions

  3. Motivation: Trust Establishment • Trust establishment between strangers in open system. • The client and server are not in the same security domain. • Identity is irrelevant to the access control decision. • Access control is often based on attributes of the client or server other than identity. • Examples: citizenship, clearance, job classification, group memberships, licenses, client’s role within an organization, etc.

  4. Digital Credentials • A credential is the vehicle for carrying attribute information reliably. • A credential contains attributes of the credential owner asserted by the issuer (attribute authority). • Credentials may contain sensitive information and should be treated as protected resources.

  5. Access Control Policies • The disclosure of a sensitive credential is governed by an access control policy that specifies credentials that must be received from another party prior to disclosing the sensitive credential to that party. • Policies themselves may be disclosed so that the participants can discover the requirements for establishing trust. • Policies may be sensitive. • Support for sensitive policies using a policy graph (Seamons et al., NDSS 2001).

  6. Trust Negotiation • The iterative exchange of digital credentials between two negotiation participants in order to gradually establish trust. • Begin by exchanging less sensitive credentials. • Build trust gradually in order to exchange more sensitive credentials.

  7. Trust Negotiation Example Show me your reseller license along with your credit card number or your CPN member card. Here is my Better Business Bureau Certificate. You are qualified to be exempt from sales tax. I request to be exempt from sales tax. Here’s my reseller license. I have a credit card. But prove you are member of Better Business Bureaufirst. Here is my credit card number. Landscape Designer Champaign Prairie Nursery

  8. Negotiation Protocol vs. Strategy • Protocol – defines the ordering of messages and the type of information messages contain. • Strategy – controls the exact contents of messages. • Which credentials to disclose and when to disclose them • Which credentials to request and when to request them • When to terminate a negotiation • Goal: a single trust negotiation protocol capable of supporting multiple, interoperable negotiation strategies (Yu et al., CCS 2001). • Negotiation strategy family - all strategies within a negotiation strategy family can interoperate.

  9. TrustBuilder Trust Negotiation Architecture TrustBuilder TrustBuilder NegotiationStrategy NegotiationStrategy NegotiationStrategy NegotiationStrategy NegotiationStrategy NegotiationStrategy TrustBuilder Protocol TrustBuilder Protocol HTTPS TNT HTTPS TNT

  10. Trust Negotiation Protocol Requirements • Exchange credentials and policies • Confidential communication to safeguard contents from an eavesdropper • Verify credential contents • Prove ownership of private keys

  11. Trust Negotiation in TLS (TNT) • TLS-based protocol for trust negotiation • Result from an analysis of the SSL/TLS handshake protocol for its suitability as a protocol for trust negotiation. • TLS provides an option for client/server authentication using certificates • Goal: extend TLS client/server authentication to support trust negotiation

  12. Client Server ClientHello ServerHello Certificate CertificateRequest ServerHelloDone Certificate ClientKeyExchange CertificateVerify ChangeCipherSpec Finished ChangeCipherSpec Finished TLS Handshake Protocol using RSA Key Exchange

  13. Client Server ClientHello ServerHello TLS Handshake Protocol Hello messages:

  14. Client Server Certificate CertificateRequest ServerHelloDone TLS Handshake Protocol Server certificate:

  15. Client Server Certificate ClientKeyExchange CertificateVerify TLS Handshake Protocol Client certificate:

  16. Client Server ChangeCipherSpec Finished ChangeCipherSpec Finished TLS Handshake Protocol Conclusion:

  17. Limitations in TLS Authentication • TLS client/server authentication has limitations for use in establishing trust between strangers. • Certificates are exchanged in plain text, allowing an eavesdropper access to sensitive certificates. • The client and server each disclose a single certificate chain to each other. • The server specifies a list of distinguished names of certifying authorities that the server trusts. In contrast, the client has no such opportunity.

  18. Limitations in TLS Authentication • The server discloses its certificates before the client discloses a certificate. • The client always receives a certificate from the server before it must disclose a certificate. However, server certificate ownership is not established when the client certificate is disclosed. • There is no facility for requesting additional certificates from the client or server during the handshake.

  19. Extend TLS Authentication to Support Trust Negotiation • Extend the TLS handshake protocol to function as a trust negotiation protocol. • TNT leverages existing and proposed features of the TLS handshake protocol. • Client hello and server hello extensions • TLS rehandshake • Session resumption

  20. TLS Hello Message Extensions • Currently, there is a proposal to the IETF to extend the hello messages such that a TLS client and server can communicate new capabilities to each other. • TNT makes use of these extensions to indicate support for trust negotiation and to specify the trust negotiation strategy family to be used during the negotiation. • The client submits a list of possible negotiation strategy families, and the server responds with a single selection.

  21. TLS Rehandshake • In the context of an encrypted TLS session, either the client or the server may initiate a rehandshake. • The server desires further certificates from the client for purposes of authentication or authorization. • Cipher suite upgrading • Replenishment of keying material • Trust negotiations involving sensitive credentials and policies must be conducted over a secure channel in order to remain confidential. The initial TLS handshake is not confidential. • TNT is designed to occur in the context of a TLS rehandshake.

  22. TLS Session Resumption • Session resumption is an optimization that allows a client and server to resume a session without repeating expensive cryptographic operations. • The server maintains a cache of SSL session IDs and the master secret used to generate keying material. • In TNT, once a trust negotiation succeeds during a rehandshake, the client and server conclude using the session resumption optimization, thus avoiding the need to establish a new master secret. • This same approach should be adopted in the TLS standard for any TLS rehandshake.

  23. TNT Protocol Client Server HelloNegotiationRequest ClientHello ServerHello Certificate * Overview: CertificateVerify Policy * ServerTurnDone + Certificate * CertificateVerify Policy * ClientTurnDone NegotiationDone ChangeCipherSpec Finished ChangeCipherSpec Finished

  24. Client Server HelloNegotiationRequest ClientHello ServerHello TNT Protocol Hello messages:

  25. Client Server Certificate CertificateVerify * Policy ServerTurnDone * TNT Protocol Server certificate:

  26. Client Server Certificate CertificateVerify * Policy ClientTurnDone * TNT Protocol Client certificate:

  27. Client Server Certificate Certificate CertificateVerify * CertificateVerify * Policy Policy + ServerTurnDone * ClientTurnDone * TNT Protocol Negotiation:

  28. Client Server NegotiationDone ChangeCipherSpec Finished ChangeCipherSpec Finished TNT Protocol Conclusion:

  29. TNT Protocol Client Server HelloNegotiationRequest ClientHello ServerHello Overview: Certificate * CertificateVerify Policy * ServerTurnDone + Certificate * CertificateVerify Policy * ClientTurnDone NegotiationDone ChangeCipherSpec Finished ChangeCipherSpec Finished

  30. Overcoming TLS Limitations • TNT overcomes the limitations in TLS client/server authentication for use in establishing trust between strangers. • TNT is conducted within the scope of an encrypted TLS rehandshake. • The client and server can exchange multiple certificate chains during each round of a negotiation. • The TNT protocol allows either the client or server to disclose certificates first.

  31. Overcoming TLS Limitations • The client and server have equal opportunity to disclose policies to one another to specify their trust requirements. • The client and server both send certificate verify messages to one another after disclosing a certificate to establish certificate ownership. • Client and server may request multiple certificates from each other.

  32. TNT Implementation • A prototype of TNT has been developed for the TrustBuilder architecture. • TNT implementation is an extension to the Java PureTLS toolkit developed by Eric Rescorla (see http://www.rftm.com/). • Policy language and compliance checker is built using the IBM Trust Establishment system developed at the IBM Haifa Research Lab (RSA Security Conference 2001).

  33. PureTLSServer RMI a d,e TrustBuilder b,c d,e IBM Trust Establishment Module Policies Services Certificates TNT Implementation Architecture PureTLSClient TNT Key ( a ) Remote Certificates / Policies ( b ) Remote Certificates / Local Policies ( c ) Local Certificates / Remote Policies ( d ) Unlocked Local Certificates/ Policies ( e ) Authorization Decision RMI a d TrustBuilder b,c d IBM Trust Establishment Module

  34. Conclusions • TNT Trust Negotiation Protocol • TNT protocol extends the TLS handshake protocol to support trust negotiation, overcoming limitations in the current TLS handshake for establishing trust between strangers • Support for confidential trust negotiation, credential verification, and verification of credential ownership • Straightforward to implement by extending existing TLS implementations • Provides robust experimental testbed for trust negotiation strategies • Potential technology transfer path for trust negotiation

  35. Future Work • Interoperable trust negotiation strategies • Trust Negotiation Protocol • HTTPS-based protocol using web servlet architecture • TLS handshake • IPsec authentication • Client-initiated trust establishment • Out-of-band trust negotiation architecture

More Related