From: Stefan Santesson <stefans@microsoft.com>
To: EKR <ekr@networkresonance.com>, "Pasi.Eronen@nokia.com"
 <Pasi.Eronen@nokia.com>
Date: Mon, 12 Mar 2007 16:20:49 +0000
Subject: RE: [TLS] Review of draft-santesson-tls-gssapi-00
Thread-Topic: [TLS] Review of draft-santesson-tls-gssapi-00
Thread-Index: AcdiX0SBS7Cr6696RXanIPgS688y5ACYoDkw
Message-ID: <A15AC0FBACD3464E95961F7C0BCD1FF01EEDFC74@EA-EXMSG-C307.europe.corp.microsoft.com>
References: <20070122202751.CCBC45C01E@laser.networkresonance.com>
 <A15AC0FBACD3464E95961F7C0BCD1FF01EEDF5A8@EA-EXMSG-C307.europe.corp.microsoft.com>
 <86mz2nr65m.fsf@raman.networkresonance.com>
 <B356D8F434D20B40A8CEDAEC305A1F2403DE97E4@esebe105.NOE.Nokia.com>
 <86odn2e8y3.fsf@delta.rtfm.com>
In-Reply-To: <86odn2e8y3.fsf@delta.rtfm.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "tls@ietf.org" <tls@ietf.org>
Precedence: list
Errors-To: tls-bounces@lists.ietf.org

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 co=
nsider.


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=3DGSSAPI
> >    ("token", gss token data)    -------->
> >
> >                                             ContentType=3DGSSAPI
> >                                 <--- ("token", gss token data)
> >
> >             (........ repeat 0..N times ..........)
> >
> >    ContentType=3DGSSAPI
> >    ("complete",
> >    gss_wrap(channel binding info)) ----->
> >                                             ContentType=3DGSSAPI
> >                                                   ("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