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

[Jeffrey Altman <jaltman at secure-endpoints.com>]

The intent of the original proposal was to replace RFC 2712 with a
revised mechanism that would be extensible and permit Kerberos to
be used for mutual authentication bound with an appropriate binding to
the TLS session.  One significant reason for selecting the use of the
GSS-API Kerberos mechanism in place of raw Kerberos is for ease of
implementation on operating systems that do not export raw Kerberos.
(Solaris, Microsoft Windows, among others.) 

The model that I had in mind was SSH gssapi-keyex where the GSS-API
is used to perform mutual authentication and generate key data that
can be used by the encapsulating protocol which in this case would
be TLS.   The GSS-API PRF provides a method of generating key data
that is independent of the negotiated Kerberos session keys.

I am very mindful of the concerns raised by EKR.  Pasi's proposal
looks very much like what was developed for Telnet START-TLS and
AUTH KRB5 binding many years ago except that instead of establishing
an TLS session with an ADH cipher and then binding the TLS finished
messages to a mutual Kerberos 5 authentication at the application
layer, the new ContentType exchange would be performed prior to
the completion of the TLS session establishment.

I believe this approach is workable but I would like to hear how
EKR would propose performing the GSS-API exchange first within
the context of the TLS session establishment.  It is important
that the solution be entirely encompassed within the TLS session
establishment in order for the result to be a transparent replacement
for the existing deployed utilization of RFC 2712.  The goal of
the original proposal was to start TLS, negotiate GSS, and then
bind the result of the GSS exchange to TLS for the completion of
the TLS state machine.  If EKR has a method of accomplishing this
which he would accept, then I would be most eager to consider it.

Thanks.

Jeffrey Altman


Stefan Santesson wrote:
> 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 at networkresonance.com]
>> Sent: den 9 mars 2007 16:25
>> To: Pasi.Eronen at nokia.com
>> Cc: tls at ietf.org
>> Subject: Re: [TLS] Review of draft-santesson-tls-gssapi-00
>>
>> <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
>
> _______________________________________________
> TLS mailing list
> TLS at lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/tls

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

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