Advanced ClientServer Authentication in TLS

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_at_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,
  clients 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.
Heres my reseller license. I have a credit card.
But prove you are member of Better Business
Bureau first.
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
TLS Handshake Protocol using RSA Key Exchange
13
TLS Handshake Protocol
Hello messages
14
TLS Handshake Protocol
Server certificate
15
TLS Handshake Protocol
Client certificate
16
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
TNT Protocol
Hello messages
25
TNT Protocol
Server certificate
26
TNT Protocol
Client certificate
27
TNT Protocol
Negotiation
28
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
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

36
(No Transcript)