Subject: RE: [TLS] Review of draft-santesson-tls-gssapi-00
From: <[email-masked]>
To: <[email-masked]>
Date: Fri, 9 Mar 2007 12:49:11 +0200
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>

Eric Rescorla wrote:

> >> 2) The extended roundtrips is an un-escapable consequence.  If
> >> necessary I believe we can define an upper boundary of the number
> >> of roundtrips.
> 
> Well, any number >2 is a radical change in the TLS state machine.

I agree; however, there are several ways to do the roundtrips,
and some of them might be slightly less radical than the one
current proposed in draft-santesson-tls-gssapi-01.

Here's one sketch of how this could work:

   ClientHello
   (ciphersuite TLS_RSA_GSSAPI_WITH_AES128_CBC_SHA, 
   gss_api extension with OID list)
                                -------->
                                                   ServerHello
                             (gss_api extension with OID list)
                                                   Certificate
                                <--------      ServerHelloDone
   ClientKeyExchange 
   (just like in normal RSA ciphersuites)
   ChangeCipherSpec
   Finished                     -------->
                                              ChangeCipherSpec
                                <--------             Finished

Then we'd have the GSSAPI exchange:

   ContentType=GSSAPI 
   ("token", gss token data)    -------->
 
                                            ContentType=GSSAPI
                                <--- ("token", gss token data)
 
            (........ repeat 0..N times ..........)

   ContentType=GSSAPI
   ("complete", 
   gss_wrap(channel binding info)) ----->
                                            ContentType=GSSAPI
                                                  ("complete", 
                               gss_wrap(channel binding info))

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

Here "channel binding info" would be something similar as in
draft-williams-on-channel-binding-01. Using a different content type
and channel binding would avoid the need to feed stuff from GSS-API 
to TLS record layer/handshake layer/key calculations (which AFAIK 
was one thing Eric objected to in IETF67).

(In addition to TLS_RSA_GSSAPI_WITH_*, we could also have
TLS_DHE_GSSAPI_WITH_* ciphersuites, if we need to support
servers without a certificate.)

Comments? 

Best regards,
Pasi

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