Re: [TLS] Negotiation in draft-santesson-tls-gssapi

[Bodo Moeller <bmoeller at acm.org>]

On Fri, Jul 20, 2007 at 01:54:25AM +0200, Martin Rex wrote:

>>> If you coalesce the first GSS-API context establishment roundtrip
>>> onto the TLS finished messages you have the same amount of roundtrips
>>> for a TLS+rfc-1964 kerberos authentication than for a plain TLS
>>> handshake.   

> I just noticed, that technically implementations like OpenSSL have
> implemented the exchange of the Finished messages in a half-duplex
> fashion.  I don't know whether this is strict requirement from the
> protocol or whether it is because it is easier to implement and
> it wouldn't be a good idea to let the client application send data
> before the server's finished message was received and verified.

To protect the application data, generally you wouldn't want to start
sending anything before having verified the server's Finished message.
Usually, certificate-based authentication ensures that the client
knows that it is talking to the proper server, i.e. only the server
will have the same symmetric key material -- but still an adversary
could have attacked the TLS handshake to manipulate the negotiation
process.  So you might be using a symmetric cipher that is less secure
than intended, or even an authentication-only cipher (NULL encryption).
Verifying the other party's Finished message allows both parties to
detect such attacks, provided that the ciphersuite and keys in use
at least do provide sufficiently strong authentication.

If you don't worry about the confidentiality of the data that you are
sending immediatly after encryption has started, then there is no
security need to delay sending this data until having received and
verified the server's Finished message.  But this is an exception.
A general-purpose TLS library that doesn't know anything about the
application data that it has to protect really needs to wait for the
Finished message.

Bodo


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