Re: [TLS] Review of draft-santesson-tls-gssapi-00

[EKR <ekr at networkresonance.com>]

<Pasi.Eronen at nokia.com> writes:

> 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? 

So, basically, you're suggesting TLS would provide a content type
for an out-of-band channel that other protocols could use for their
negotiation without it winding up in the app layer? This certainly
seems better than the current proposal.

An alternative proposal that seems even cleaner is to simply
do the GSS first and then couple it to TLS with PSK.

-Ekr


_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls