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

Pasi,

Thanks for this interesting proposal.
Let me clarify that I'm personally in no way locked on the current proposal in term of selected architecture.
As long as we can achieve the same goal.

Your proposal is interesting as an alternative that we definitely should consider.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: EKR [mailto:ekr@networkresonance.com]
> Sent: den 9 mars 2007 16:25
> To: Pasi.Eronen@nokia.com
> Cc: tls@ietf.org
> Subject: Re: [TLS] Review of draft-santesson-tls-gssapi-00
>
> <Pasi.Eronen@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@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/tls

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