1 / 9

GSS-API based Authentication and Key Establishment in TLS

This document presents a proposal for addressing the limitations of traditional Kerberos authentication in TLS environments, specifically for remote clients. By implementing a GSS-API-based solution, our approach ensures secure client authentication and key establishment while minimizing overhead. We outline the method of integrating new cipher suites and extensions within the TLS handshake, allowing clients to obtain service tickets dynamically. This proposal is open for design enhancements and aims to establish robust, flexible authentication mechanisms across different protocols.

chance
Télécharger la présentation

GSS-API based Authentication and Key Establishment 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. 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 ClientServer       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

More Related