RE: [TLS] SPNEGO over TLS - proposed new work item

I don't thing this is the right architecture for the worldwide internet: putting the ws-security (i.e. ws-conversation) handshakes (a SPNEGO profile) into the TLS message handling layer. The right place for ws-conversation is in the http redirect/post handlers, where one can hook arbitrary levels of security protocol engines above the http messaging layer (as SAML2 has shown the world, so effectively, standardizing over 11 security state machines that accomplish everything the SSL ever did). Id agree that most of the handshake mechanisms that TLS 1.x standardizes can then simply be re-written as ws-conversation flows, and that is the proper architectural relationship between we-security and TLS. WS-conversation flows can of course add more security semantics than TLS can ever accomplish by its linkage to TCP/IP, being able to orchestrate store-and forward security protocols.

One can easily imagine now an httpws:// that properly orchestrates what role a reliable transport channel such as TLS plays when supporting ws-conversation flows at the http layer, much like https orchestrated how hypermedia multiplexing, certificates and website naming at the http layer interplayed with SSL protocol engines.

SO, it should be SPNEGO OVER TLS, not SPNEGO in TLS.

Date: Mon, 6 Nov 2006 08:51:03 +0000
From: stefans@xxxxxxxxxxxxx
To: tls@xxxxxxxx
CC:
Subject: [TLS] SPNEGO over TLS - proposed new work item

I would like the TLS group to consider a new work to provide a framework for GSS-API based authentication and key establishing methods. I have requested a spot at the TLS meeting to discuss this.

In Microsoft we have investigated many ways to use Kerberos as means of client authentication and key establishment over TLS but the task offers several challenges that current specification does not solve.

The most important challenge is to allow a full Kerberos negotiation including initial AS-request to the KDC server when the client resides outside the local network of the KDC server.

The proposal is to provide a generic and transparent solution by enabling SPNEGO (RFC 4178) within a TLS handshake.

The advantage of allowing SPNEGO under TLS is that it provides a lot of flexibility as new mechanisms can be added under SPNEGO (e.g., WS security), given the reliance on the SPNEGO for auth package negotiation, without further amendments to TLS.

Deliverables and highlights:

- Define new ciphersuites that use SPNEGO for key exchange

- Define new TLS client/server extension for agreement upon

    which SPNEGO mechanism to use (e.g. Kerberos)

- The server always sends its certificate

- The server never sends certificate request message

- The client never sends its certificate

- ClientKeyExchange message: After GSS initialize Security

    context call is done, the client calls GSS encrypt message

    to encrypt the premaster secret. NOTE: the ClientKeyExchange

    is always protected under the public key obtained from the

    Server cert.

- Ideally use Supplementary data messages to carry gss payloads

Outline:

   Client                                               Server

      ClientHello

       /* CipherSuite: SPNEGO_AES_SHA256,...

          Extensions SPNEGO (Kerb,WS-Sec,NTLM,..) */ ----->

                                                      ServerHello

                                /* CipherSuite: SPNEGO_AES_SHA256

                                      Extensions SPNEGO (Kerb) */

                                                      Certificate

                                     <--------    ServerHelloDone

            <---------   SupplementalData -------->

         /* multiple iterations with SPNEGO payload */

      ClientKeyExchange

      CertificateVerify*

      [ChangeCipherSpec]

      Finished                     -------->

                                               [ChangeCipherSpec]

                                   <--------             Finished

      Application Data             <------->     Application Data

Challenges:

The SPNEGO negotiation does not have a predefined number of iterations. This exchange of messages has to be allowed go on until finished. Conventions need to be defined for how to detect completion as well as success and failure of this negotiation.

Ideally we would use the Supplemental data handshake message to carry the SPNEGO payloads. However, it must be determined that it is allowed.

Alternative solutions considered:

As alternative solutions to this proposal we have considered defining Kerberos specific payloads for transport in TLS extensions and handshake messages as well as basing a solution on TLS PSK.

The name field in TLS PSK could contain a Kerberos ticket, but it would not provide the necessary means to provide an initial AS-request. The AS-request has a need for protection which has to be provided by the TLS handshake, possibly through double handshake. Such solution is not very generic and double handshake is not always usable in environments where this could be used, especially in high latency networks.

In the end, no alternatives considered have in our view been able to provide a clean and generic solution.

Stefan Santesson

Senior Program Manager

Windows Security, Standards

Try the next generation of search with Windows LiveT Search today! Try it now!