Subject: [TLS] Optimizing use of SASL/GS2 over TLS

From: Nicolas Williams <[email-masked]>
Date: Fri, 10 Apr 2009 17:06:39 -0500

[Note: SASL and KITTEN WGs are Bcc'ed.]

I've submitted an I-D describing how to reduce the number of round trips
needed for SASL/GS2 mechanism negotiation and authentication when
running over TLS:

    draft-williams-tls-app-sasl-opt-01.txt

This can be seen as a variant of the TLS/GSS proposal from a while back
as it achieves the same result: you can use the GSS-API for
authentication _and_ TLS for session protection without having to pay a
round trip penalty.  But it does it in a slightly different and simpler
way.

I'm hoping this proposal will be less controversial than the TLS/GSS
proposal.

Comments?

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 11 Apr 2009 12:05:28 +0200

> I'm hoping this proposal will be less controversial than the TLS/GSS

Interesting work!  I think it is worthwhile to continue explore this
approach.  I'm interested in helping with the draft and implement it if
appears to meet more approval than TLS/GSS.  I'd be interested in
hearing comments from people working on the TLS/GSS effort.

Some comments:

* The SaslSML message is not explained?  I assume it contains the normal
  list of SASL mechs supported by the server, separated with SPC?  That
  needs to be defined.

* The second paragraph of 2.1 doesn't work: I assume you meant that the
  SASL mechanism name plus NUL is sent in the first message from the
  client at all times?

* The server needs the ability to reject client-chosen mechanism and the
  client should be able to recover.  This argues for using a separate
  message type for the mechanism-selection (and success/failure?)
  packets.

* The somewhat ugly all-set four-byte token with additional application
  information could probably also better be sent using a separate
  message type.

* 2^16-1.. please use 2^32-1 instead, even 2^24-1 are on short size when
  considering authorization information.

* How would EXTERNAL work?  If requested, the TLS channel hasn't been
  set up yet, so it may be premature to decide whether to honor it or
  not.  It would work if there has already been a TLS handshake, though.

Architecturally, I'm not convinced involving SASL is required.  It seems
you can achieve the same goals by defining your protocol directly
against GSS-API.  SCRAM will be usable as a GSS-API mechanism, covering
one of the two use cases (Kerberos V5 being the other).  But it may be
an easier upgrade path for application writers who are already familiar
with TLS and SASL.  So that is OK by me.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 14 Apr 2009 13:12:27 -0500

> hearing comments from people working on the TLS/GSS effort.

Excellent!  That is good news.

>   list of SASL mechs supported by the server, separated with SPC?  That

I'm adding more text in -02, which I'll submit today.  Yes, SaslSML is
the server's SASL mechanism list.

>   SASL mechanism name plus NUL is sent in the first message from the

Yes.

>   message type for the mechanism-selection (and success/failure?)

It can now: just send the outcome of authentication message immediately
and then the optimization ends, at which point the application protocol
starts as if nothing had happened (except that there's now no need to
list the server mechanisms) and the client can re-try SASL
authentication in the normal application protocol.

>   information could probably also better be sent using a separate

No need: by that time we're clearly in the "Application Data" phase of
the TLS protocol, and defining a new message type would seem like too
much of a change to me.

>   considering authorization information.

I know that 2^16-1 is small, but that comes from the limit on Hello
extensions.  I wasn't sure that handshake messages could be longer.
I'll check into that.

>   not.  It would work if there has already been a TLS handshake, though.

-02 will clarify that this extension is applicable only to SASL/GS2
mechanisms.  The server mechanism list can contain other SASL
mechanisms, but if the client wishes to select one of those then it
needs to do it in the normal application protocol.

> with TLS and SASL.  So that is OK by me.

Doing mechanism negotiation the SASL way is, IMO, part of what makes it
possible to build this extension in a way that should pass muster with
the TLS WG (unlike TLS/GSS).  You're correct that this does not mean
that this extension should be in SASL terms as opposed to GSS-API terms.
However: a) it ought to be possible to optimize SASL apps this way, b)
it ought to be possible to optimize GSS-API apps this way, c) with
SASL/GS2 we get (a) and (b) at once, therefore using SASL seems like the
best way to go.

Thanks so much for your comments!

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 14 Apr 2009 14:46:51 -0500

I've posted -02:

http://www.ietf.org/internet-drafts/draft-williams-tls-app-sasl-opt-02.txt

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 17 Apr 2009 14:38:15 -0500

I've submitted -03, with a large simplification over earlier versions.

The only thing in this I-D that can be thought of as a state machine
change is the option to allow the application to send application data
before the server's Finished message is received (but, of course, after
the client's Finished message is sent).

Nico
--