Subject: Re: [TLS] Interest in TLS authorization?

From: Nicolas Williams <[email-masked]>
Date: Tue, 7 Apr 2009 16:40:33 -0500

On Tue, Mar 24, 2009 at 06:12:50PM -0500, Nicolas Williams wrote:
> The only things missing then would be:
> 
>  - how to put SAML/whatever authorization elements into Kerberos V
>    tickets and PKIX certificates
> 
>  - how to use SASL in TLS
> 
> The latter is a variant of "how to use the GSS-API inside TLS", and that
> has been controversial and has never progressed within the TLS WG.  IIRC
> the controversy arises from the fact that the GSS-API supports
> arbitrary round trips, and the same is true of SASL -- so you're likely
> to run into the same issue.
> 
> However, I think we might be able to do something about that: ride some
> of the SASL/GSS-API messages in TLS handshake extensions and complete
> the SASL/GSS-API authentication exchange after the TLS exchange
> completes if the SASL/GSS-API mechanism requires further round-trips.
> Such a protocol would only be usable by applications that support such a
> protocol as that'd not be "TLS" -- but consider how many SASL apps run
> over TLS.

Though, I should point out, this would be negotiable as it's merely an
optional round-trip optimization for the application protocol.  It's
only applicable when it is safe to defer integrity protection for inital
application protocol messages.  This extension that I'm proposing is a
therefore a bit more general than TLS+SASL or TLS+GSS-API.

So I see several documents:

1) An extension to TLS client and server hello and handshake messages
   for carrying application protocol messages that can safely have
   integrity protection delayed.

2) A document describing how to use (1) with SASL and the new SASL/GSS
   bridge to get SASL and GSS-API authentication in TLS applications in
   a round-trip optimized fashion.

5) A document describing a Kerberos V authorization-data element by
   which clients and KDCs can transport SAML assertions.

4) A document describing a PKIX certificate extension for carrying SAML
   assertions.  Combined with PKU2U (a GSS-API mechanism based on PKIX)
   you'd get both, CA- and client-asserted SAML assertions.  (Yes, using
   PKU2U over TLS would be wasteful, but you'd do it once and use
   session resumption.  Also, it's a small price to pay for an
   unencumbered protocol.

> A bit roundabout.  But I don't see how there could exist patents that
> cover this, short of submarine patents by really clever people or
> submarine patents filed by someone who overheard early discussions of
> putting SAML into Kerberos some three or so years ago.

Also, IIRC Martin Rex and I discussed something like the above in a
jabber room for one or more WGs several IETF meetings ago.  I.e., there
have been descriptions of this idea in IETF fora, which ought to
preclude patents covering it (but IANAL).

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 8 Apr 2009 00:21:51 -0500

> therefore a bit more general than TLS+SASL or TLS+GSS-API.

I missed a problem: channel binding can't be done through the normal GSS
(and now SASL) method because the channel binding data will not be
available at that time.  Channel binding can still be done using MIC
tokens, but this adds between 1/2 and 1 round-trip (and this is tricky
to do with SASL).  Not fatal, but any proposal needs to address this.

Nico
--

---

From: Sean Shen <[email-masked]>
Date: Wed, 08 Apr 2009 15:35:38 +0800

Hi, Nicolas,  

>> The latter is a variant of "how to use the GSS-API inside TLS", and 
>> that has been controversial and has never progressed within the TLS 
>> WG.  IIRC the controversy arises from the fact that the GSS-API 
>> supports arbitrary round trips, and the same is true of SASL -- so 
>> you're likely to run into the same issue.
>> 
>> However, I think we might be able to do something about that: ride 
>> some of the SASL/GSS-API messages in TLS handshake extensions and 
>> complete the SASL/GSS-API authentication exchange after the TLS 
>> exchange completes if the SASL/GSS-API mechanism requires 
>further round-trips.
>> Such a protocol would only be usable by applications that 
>support such 
>> a protocol as that'd not be "TLS" -- but consider how many SASL apps 
>> run over TLS.
>
>Though, I should point out, this would be negotiable as it's 
>merely an optional round-trip optimization for the application 
>protocol.  It's only applicable when it is safe to defer 
>integrity protection for inital application protocol messages. 
> This extension that I'm proposing is a therefore a bit more 
>general than TLS+SASL or TLS+GSS-API.
>

Does this mean to have more rounds before [ChangeCipherSpec]? In this way,
as you said, it would not be "TLS" anymore, and certainly definitions of new
messages are needed besides extensions.
If extra rounds are finished after [ChangeCipherSpec]，these messages will
have integrity protection, in this case, it's the application data which are
defered. Or did I misunderstand something?

Sean

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 10 Apr 2009 14:53:58 -0500

> Does this mean to have more rounds before [ChangeCipherSpec]? In this way,

No, it does not!

> messages are needed besides extensions.

It is not a new protocol, actually.  It's just an optimization of the
application's app-layer authentication round-trips.

> defered. Or did I misunderstand something?

Correct.

I just posted an individual I-D for this extension:

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

(it will be there shortly; I forgot to include important text in -00 so
I'm re-submitting momentarily).

It allows the application to do the SASL mechanism negotiation in the
first TLS round trip and then the first round trip of the selected SASL
mechanism in the next TLS round trip.  With the new SASL/GS2 mechanism
family we also get support for GSS-API mechanisms.

If the application negotiates the use of the Kerberos V GSS-API
mechanism through the SASL/GS2 bridge, which requires one round trip,
then it will complete the TLS and SASL authentication in just two
round-trips instead of four.

There is one odd sleight of hand, but I think it's OK.  Can you find it?
Is it acceptable?

I think we should call this "TLS/SA" -- "SA" for the Simple
Authentication half of SASL (we don't need the Security Layers half).

Through these SASL and GSS-API mechanisms and the GSS-API "naming"
extensions we'll get support for authorizations in TLS, and in a
patent-free way (since all these things have been discussed publicly to
some degree over the last few years, as I mentioned earlier, and I have
no knowledge of any patents or patent applications covering any of the
components of this proposal nor the proposal as a whole -- that does not
mean there can't be applicable patents or patent applications though,
and remember, IANAL).

Comments?

Nico
--