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

[Simon Josefsson <simon at josefsson.org>]

<Pasi.Eronen at nokia.com> writes:

> Simon Josefsson wrote:
>
>> > 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.
>
> BTW, I'd be interested to know why, and what you consider
> to be the advantages? 

That's a good question... since this was my gut reaction, I'm not sure
if I can put words on it easily, but I suspect that some of the reason
includes variations of these concerns:

1) Adding an extension for GSS-API works with all ciphersuites, and
makes the use of GSS-API orthogonal to the ciphersuite used.  That
makes it possible to define, e.g., a new public-key algorithm in TLS
and have existing extensions, such as a GSS-API or EAP extensions,
apply to it directly.

2) Let's say we create new ciphersuites for both GSS-API and EAP.
What's saying that someone don't want to use both GSS-API and EAP at
the same time?  Should there be TLS_RSA_WITH_AES128_CBC_SHA_GSSAPI_EAP
ciphersuites?  What about if SASL authentication is also supported?
If GSS-API, EAP, and possibly SASL, were negotiated as a separate (or
possibly the same) TLS extension, this would not be a problem.  At
least if the design of the extension(s) were done properly.

3) Simplify TLS analysis.  If GSS-API or EAP is tightly mixed into the
TLS protocol, e.g. the TLS state machine, it becomes harder to analyse
TLS for correctness.  If we can prove that TLS with the extension
mechanism is secure today, that analysis would hold for TLS + GSS-API
too.

4) Simplify implementations.  At least in GnuTLS, adding a new TLS
extension is simple, and it doesn't have much effect on the core part
of the library.  It thus leads to more easily modularized code.
Adding a new ciphersuite is not as easy to modularize.

> <snip>
>> 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.
>
> So would your suggestion be to use the GSS-API channel binding
> (in GSS_Init/Accept_sec_context) instead of GSS_GetMIC/GSS_Wrap? 

Perhaps.  Some more thinking on this choice may be useful.

One problem with this approach is that if the GSS-API channel binding
negotiation fails, for some reason, the implementation typically
doesn't know that the cause was the failed channel binding.

That was a concern in the SASL GS2 mechanism, where one peer may set a
channel bindings that refer to a security channel that the other end
does not know about.  For example, your MUA might not be aware of a
IPSEC channel, and thus might not be able to set the correct IPSEC
channel binding.  Therefor, we chose to use GSS_Wrap instead of
GSS_Init_sec_context channel binding concept, with a fallback to an
identity function if the GSS-API mechanism did not support GSS_Wrap.

(And yes, the fallback open up for a MITM vulnerability, but other
people in the SASL WG thought this was acceptable, possibly reasoning
that the GSS-API mechanism was already too weak to provide anything
better.  Which may be reasonable, although it leads to complexity.)

I don't think this needs to be a concern for TLS though.  If the
GSS-API channel binding fails, things probably should fail.

> Is there any danger that this could allow replaying GSS tokens
> from a different context where the acceptor ignores the channel 
> bindings (see RFC 4121, Section 7)? Or can this be addressed
> by some other means?

Yes, I think there are such concerns.

Further, I suspect there are GSS-API mechanisms out there that ignore
the channel binding field, but I'll let those with more experience
from non-standard GSS-API mechanism fill in the details here.

Since this is often only a problem with particular GSS-API mechanisms,
one could leave this as a security consideration: 'This TLS GSS-API
extension assumes that the negotiated GSS-API mechanism use the
channel binding data properly, which at least includes that
authentication cannot succeed without both ends supplying the same
channel binding, and that successful replay of the tokens is not
possible.'

/Simon

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