[TLS] Re: Review of draft-santesson-tls-gssapi-00
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



<Pasi.Eronen at nokia.com> writes:

> Yoav Nir wrote:
>
>> > We certainly have to complete the authentication (including GSS-API)
>> > before we let application data through. In my proposal, that would
>> > happen after the channel binding messages (not immediately after the
>> > finished messages).
>> 
>> This would change the same state machine which you reference in RFC  
>> 2246. That figure makes it clear that application data immediately  
>> follows the Finished message. Inserting more handshake messages  
>> between the Finished message and the application data is just as big  
>> a change as is inserting them before the Finished message.
>
> In my proposal, the GSS-API messages would use a new content type, not
> handshake; so the state machine for TLS handshake message processing
> would not be changed.
>
> IMHO this is a smaller change (but I admit that judging the size of
> these changes is somewhat subjective).

I like your proposal better too, since it seems like a good compromise
here, but I believe one of the problems with it is termination: if the
TLS handshake Finished messages doesn't complete a TLS handshake, from
a key-management point of view (which is what some applications wants
from TLS), when should the TLS session terminate?  With your proposal
it finishes after TLS Finished and after GSS_Init/Accept_sec_context
terminates with success.  That's not a generic termination condition
that fits well with how EAP looks at TLS negotiation.

A generic "user authentication" mechanism like the TLS Inner
Application extension, enhanced with support for GSS-API, may be
better.  It would provide a framework to tell applications using TLS
for key-management when the TLS negotiations have finished, instead of
having them wait for TLS Finished and then wait for GSS success.

Anyway, I'd be interested to hear EKR and Stefan's thoughts on your
proposal, and what (if any) disadvantages they believe it have.

/Simon

_______________________________________________
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.