GSS-API based Authentication and Key Establishment in TLS

1
GSS-API based Authentication and Key
Establishment in TLS

• Stefan Santesson
• Microsoft

2
Problem statement

• A standard solution to use Kerberos for Client
  authentication and key establishment is highly
  desirable
• Client can be remote (not on KDC network)
• Proper protection of sensitive authentication and
  key exchange data
• Minimum overhead
• Transparent and generic to accommodate multiple
  authentication modes and protocols

3
What we have doesnt work

• RFC 2712
• Requires the client to have a Kerberos service
  ticket for the TLS server
• Not usable when client is remote
• Need solution where the client can obtain the
  service ticket within the TLS handshake exchange
• Not generic

4
Principles of the proposal

• Based on GSS-API (RFC 2743)
• Solution valid for any authentication method with
  a valid GSS-API profile such as RFC 4121 for
  Kerberos.
• New CipherSuites for GSS-API based key
  establishment
• Ex. TLS_GSSAPI_WITH_AES_128_CBC_SHA
• New TLS extension for negotiating GSS exchange
  profile
• Client present list of OIDs
• Server Picks OID or decline GSS exchange by
  omitting extension

5
GSS-API exchange

• n Roundtrips of SupplementalData handshake
  messages (RFC 4680)
• Each message contains a GSS-API token
• According to selected CipherSuite
• According to GSS profile selected through TLS
  Extensions
• Possibly adding control bytes for status
  signaling such as Final message

6
Key derivation

• Use GSS PRF output as TLS pre-master secret
• Conclude standard TLS key derivation
• Done

7
Flow

•    Client                                     
       Server
•  
•       ClientHello
•        / CipherSuite TLS_GSSAPI_AES_SHA256,...
•           Extensions GSSAPI (OID list) / -----gt
•  
•                                                   
      ServerHello
•                             / CipherSuite
  TLS_GSSAPI_AES_SHA256
•                                       Extensions
  GSSAPI (OID) /
•                                                   
      Certificate
•                                      lt--------   
  ServerHelloDone
•  
•             lt---------   SupplementalData 
  --------gt
•           / multiple iterations with GSS-API
  tokens /
•  
•       ClientKeyExchange
•       CertificateVerify
•       ChangeCipherSpec
•       Finished                     --------gt

8
Identified issues

• No finite number of roundtrips
• Should never exceed 5 handshake messages with
  GSS-API tokens, but hard to specify due to the
  generic approach.
• Multiple roundtrips of SupplementalData
• Compliance with RFC 4680?
• Number of roundtrips
• Placement in the protocol flow
• Do we need a new handshake message?

9
Next steps

• A first draft will be provided soon after this
  meeting
• Authors
• Stefan Santesson
• Jeffery Altman
• Protocol open for design proposals and
  improvements
• Decision by TLS group to take on this work