Re: [TLS] Fwd: I-D Action:draft-bmoeller-tls-falsestart-00.txt

[Nicolas Williams <[e-mail]>]

Huh, I independently proposed a something similar, though I call it
early_start, in April 2009, in draft-williams-tls-app-sasl-opt-03.

draft-williams-tls-app-sasl-opt-03 was a bit confused because I hadn't
removed all references to a handshake message I had proposed in earlier
versions of the same I-D.  I've -04 ready to go, but since I've missed
the cut-off for the upcoming IETF meeting, I can't submit it at this
time.  I've posted the -04 to the KITTEN WG list:

http://www.ietf.org/mail-archive/web/kitten/current/msg01877.html

I believe that this "false start" or "early start" approach, with
SASL/GSS-API and channel binding, is ideal for optimizing the number of
round-trips needed by applications to do authentication above TLS.

In my proposal a Hello extension is used for SASL/GS2 mechanism
negotiation, and another Hello extension is used to negotiate "early
start" of the selected SASL/GSS-API mechanism.

Mechanisms that would be immediately available for use in this way
include:

 - SCRAM [RFC5802] (DIGEST-MD5's successor)
 - Kerberos V5 [RFC4120] via RFCs 5801, 4121 and 1964.

and soon enough probably also IAKERB (Kerberos but with KDC
communications proxied by the acceptor) and Kerberos user-to-user
authentication.

For background: "GS2" [RFC5801] is a very simple bridge that allows
GSS-API [RFC2743] mechanisms to be used as SASL [RFC4422] mechanisms.

Nico
--