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

From: "Stefan Santesson" <[email-masked]>
Date: Mon, 6 Nov 2006 08:51:03 -0000

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

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Martin Rex <[email-masked]>
Date: Mon, 6 Nov 2006 21:32:32 +0100 (MET)

>     is always protected under the public key obtained from the

What do you mean by "GSS encrypt" -- gss_wrap?

I don't quite understand what you're proposing, but there might
a problem with this:

At the gss-api level, when SPNEGO is used, then message protection
facilities are *NOT* available until after the security context
establishment has completed successfully, i.e. GSS_C_FLAG_PROT_READY
is incompatible with the use of SPNEGO.

One of the reasons why GSS_C_FLAG_PROT_READY is incompatible with
SPNEGO is the sequencing protection of protected messages in
GSS-API.  SPNEGO uses a regular "gss_getmic()" call to create a
MIC for the handshake.  The use of message protection facilities
before the handshake is complete would interfere with SPNEGOs
use for the very same facilities to protect the handshake.

-Martin