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

[Simon Josefsson <simon at josefsson.org>]

<Pasi.Eronen at nokia.com> writes:

> Simon Josefsson wrote:
>> > Here's one sketch of how this could work:
>> >
>> >    ClientHello
>> >    (ciphersuite TLS_RSA_GSSAPI_WITH_AES128_CBC_SHA, 
>> >    gss_api extension with OID list)
>> 
>> I like this approach better, although I don't understand why you need
>> special GSSAPI ciphersuites, could you explain?  Wouldn't it be
>> possible to do this with an extension, to enable the extra roundtrips,
>> without touching the ciphersuites?
>
> I'm not sure if we really need special GSSAPI ciphersuites either...
> But at least it would allow the client to say "I want to do
> RSA+GSS-API, not plain RSA" in a way that would be correctly
> understood by existing servers (that don't do GSS-API).

Ok.  I believe it would be a considerable advantage to avoid requiring
new ciphersuites for GSS-API negotiation.

>> Using gss_wrap to wrap additional information, such as channel
>> bindings, has some similarities with the SASL GS2 mechanism.  Note
>> that it doesn't seem to work with authentication-only GSS-API
>> mechanisms that doesn't support GSS_Wrap.
>
> Hmm... possibly it should be GSS_GetMIC instead of GSS_Wrap?
> Are there any important GSS-API mechanisms that support neither?

I'm working on a HMAC-SHA-256 based GSS-API mechanism that only
supports authentication right now... ;-)

When GSS-API mechanisms are used in protected channels (such as TLS,
possibly using a double-handshake mechanism together with channel
bindings in the authentication) I don't see any cryptographic need for
the authentication mechanism to also provide message security
services.  Designing messages security services is quite complicated,
so if possible I would want to avoid it.

/Simon

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