RE: [TLS] Review of draft-santesson-tls-gssapi-00
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [TLS] Review of draft-santesson-tls-gssapi-00
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
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.