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 doesn’t 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) */ -----> ServerHello /* CipherSuite: TLS_GSSAPI_AES_SHA256 Extensions GSSAPI (OID) */ Certificate < ServerHelloDone < SupplementalData > /* multiple iterations with GSS-API tokens */ ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished > [ChangeCipherSpec] < Finished Application Data < > Application Data

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