Subject: [kitten] WGLC on draft-ietf-kitten-sasl-saml-02

From: Shawn M Emery <[email-masked]>
Date: Thu, 31 Mar 2011 02:12:45 -0600

This message officially starts the Kitten Working Group Last Call for
the following document:

A SASL and GSS-API Mechanism for SAML
http://tools.ietf.org/html/draft-ietf-kitten-sasl-saml-02

The Working Group Last Call for this document starts today on Thursday,
March 31st and will end on Thursday, April 14th.

Please send any comments to the Kitten mailing list or directly to the
chairs.  Feed-back from reviews that found no issues are also welcome.

Thank you,

Shawn.
--

---

From: "William J. Mills" <[email-masked]>
Date: Thu, 31 Mar 2011 10:59:09 -0700 (PDT)

I asked this before but I did not see an answer.  Is message integrity in the mechanism a requirement for correct support of channel binding?  I believe the answer to this is yes, because an intelligent MITM can simply modify the channel binding payload in flight otherwise, and this would be undetectable to the endpoints.

I ask because I am trying to determine how to correctly allow for CB in the OAuth mechanism.

Thanks,

-bill

---

From: Nico Williams <[email-masked]>
Date: Thu, 31 Mar 2011 13:07:36 -0500

On Thu, Mar 31, 2011 at 12:59 PM, William J. Mills <[email-masked]> wrote:
> I asked this before but I did not see an answer.  Is message integrity in
> the mechanism a requirement for correct support of channel binding?  I
> believe the answer to this is yes, because an intelligent MITM can simply
> modify the channel binding payload in flight otherwise, and this would be
> undetectable to the endpoints.
>

You need something akin to integrity protection.  If you have
integrity protection, that will do.  If you have any sort of key
exchange then you can either add integrity protection OR mix the CB
into the key derivation for the key exchange.

OTOH, if you have no key exchange whatsoever, and no keying material
of any sort (e.g., as we do in SCRAM, where we derive a key from a
password, salt and iteration count), then you may not be able to do CB
(I'm thinking though that if you have trusted third parties that can
validate CB for you, then you can; presumably you'd be using TLS to
authenticate the trusted third party).

Nico
--

---

From: "William J. Mills" <[email-masked]>
Date: Thu, 31 Mar 2011 11:16:05 -0700 (PDT)

OK, this makes sense.  Some of the OAuth profiles within this mechanism have a shared secret and sign the messages.  In those cases we can perform correct channel binding.  I'll put that language into the mechanism draft spec.  Thank you.

-bill

________________________________
From: Nico Williams <[email-masked]>
To: William J. Mills <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: Thursday, March 31, 2011 11:07 AM
Subject: Re: [kitten] Channel binding requirements.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 01 Apr 2011 00:32:51 +0200

On Thu, 2011-03-31 at 10:59 -0700, William J. Mills wrote:
> I asked this before but I did not see an answer.  Is message integrity
> in the mechanism a requirement for correct support of channel binding?
> I believe the answer to this is yes, because an intelligent MITM can
> simply modify the channel binding payload in flight otherwise, and
> this would be undetectable to the endpoints.

You need some means of providing integrity protection for channel
bindings.  This does not mean you need to provide the GSSAPI message
integrity service or a SASL security layer, both of which require you to
be able to integrity-protect traffic carried afgter context
establishment is complete.  So, for example, a public-key-signature
mechanism which includes channel bindings in the data it signs during
context establishment would provide channel bindings, but not
necessarily the message integrity service.

It is most desirable to provide channel bindings, PRF, message
integrity, and message confidentiality; various existing GSS-API
applications depend on each of these.  However, given any of the first
three (or a shared, session-specific secret), we can show you how to
derive the rest (however, if the thing you start with is not PRF or a
key, then the derivation will likely involve a key exchange protocol
like DH, which can be expensive).

-- Jeff

---

From: "William J. Mills" <[email-masked]>
Date: Thu, 31 Mar 2011 21:19:05 -0700 (PDT)

In some cases I'll have a shared secret, but not in all cases.

________________________________
From: Jeffrey Hutzelman <[email-masked]>
To: William J. Mills <[email-masked]>
Cc: [email-masked]; "[email-masked]" <[email-masked]>
Sent: Thursday, March 31, 2011 3:32 PM
Subject: Re: [kitten] Channel binding requirements.

-- Jeff