Subject: [TLS] Scope of draft-rescorla-tls-extractor

From: Martin Rex <[email-masked]>
Date: Wed, 5 Dec 2007 16:33:24 +0100 (MET)

The currently proposed scope of draft-rescorla-tls-extractor seems to
be similar to the gss_prf approach in GSS-API.

I believe, however, that a wider scope would be better.
When combining TLS channel protection with other authentication
technologies (like GSS-API authentication), one should have
a means to "mix" entropy from one (cryptographic) protocol
exchange into the session key of the other that is used
for protection of the communication in order to provide
a cryptographically secure channel binding.

It would be the duty of the upper protocol layers using such
a mix-in-entropy functionality in TLS to do it synchronously
at both ends of the secure TLS communication channel.

Ultimately the eap authentication for TLS should use this path
as well, rather than messing with the TLS handshake protocol
and TLS state engine.

-Martin

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 05 Dec 2007 18:19:55 +0100

> at both ends of the secure TLS communication channel.

Have you seen
<http://tools.ietf.org/id/draft-rescorla-tls-opaque-prf-input-00.txt>?

I agree with your observation, and believe that the problem can be
solved by using both these drafts together.  The application framework
still have to specify the details though.

Still, adding more discussions to both of these drafts on the
applicability and the intended use cases would be a good idea.

/Simon

---

From: Martin Rex <[email-masked]>
Date: Thu, 6 Dec 2007 19:41:33 +0100 (MET)

> <http://tools.ietf.org/id/draft-rescorla-tls-opaque-prf-input-00.txt>?

No, I haven't.  Thanks for the pointer (the document expired on june 16,2007,
but my local I-D mirror still has it). 

It's not quite what I was looking for.  As far as I understand that
proposal, it's a Hello extension and all application supplied data travels
in the first handshake roundtrip and in cleartext.

I was looking for a means to synchronously modify the keying material
(Master Secret) at a time when the communication channel is already
encrypted.  This is can not be done through a simple hello extension
and will require, admittedly, a change of the TLS handshake and
state engine by itself.  Moving it behind the TLS hanshake
(after the finished messages) should be possible, but then
require some thought because of the impact on session cache management.

-Martin