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

From: Peter Williams <[email-masked]>
Date: Mon, 6 Nov 2006 07:42:29 -0800

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 +0000From: [email-masked]: [email-masked]: 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
_________________________________________________________________
Check the weather nationwide with MSN Search: Try it now!
http://search.msn.com/results.aspx?q=weather&FORM=WLMTAG

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

---

From: Ari Medvinsky <[email-masked]>
Date: Mon, 6 Nov 2006 08:25:41 -0800

Peter, the point of Stefan's proposal is not about WS security - the primary motivation is to solve the shortcomings of RFC2712 (krb under tls) - RFC2712 assumes that the TLS client has connectivity to the KDC (this is a problem for most corp. deployments).  doing SPNEGO in TLS will solve this problem (via forwarding of AS_REQ to the server).

________________________________

From: Peter Williams [mailto:[email-masked]]
Sent: Mon 11/6/2006 7:42 AM
To: Stefan Santesson; tls mailing list
Subject: 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.

________________________________

	Date: Mon, 6 Nov 2006 08:51:03 +0000
	From: [email-masked]
	To: [email-masked]
	CC: 
	Subject: [TLS] SPNEGO over TLS - proposed new work item

	    Server cert. 

	 

	Outline:

	   Client                                               Server

	      ClientHello

	                                                      ServerHello

	                                                      Certificate

	      ClientKeyExchange

	      CertificateVerify*

	      [ChangeCipherSpec]

	      Finished                     -------->

	                                               [ChangeCipherSpec]

	                                   <--------             Finished

	Challenges:

	 

	 

	Stefan Santesson

	Senior Program Manager

________________________________

Try the next generation of search with Windows LiveT Search today! Try it now! <http://search.live.com/>  
_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls