Subject: Re: [kitten] Channel binding requirements.

From: "William J. Mills" <[email-masked]>
Date: Fri, 1 Apr 2011 16:44:45 -0700 (PDT)

I've been thinking about your last paragraph and I don't see how a DH key exchange is useful without some form of endpoint validation.  I can MITM a DH key exchange by doing my own with you, if I am truly a MITM.   I think the most commonly understood way would be some form of validation using the public key of the endpoint, and I'm really not sure I want to build in a PKI requirement here.

________________________________
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.

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: Jeffrey Hutzelman <[email-masked]>
Date: Sat, 02 Apr 2011 06:36:25 +0200

On Fri, 2011-04-01 at 16:44 -0700, William J. Mills wrote:
> I've been thinking about your last paragraph and I don't see how a DH
> key exchange is useful without some form of endpoint validation.  I
> can MITM a DH key exchange by doing my own with you, if I am truly a
> MITM.   I think the most commonly understood way would be some form of
> validation using the public key of the endpoint, and I'm really not
> sure I want to build in a PKI requirement here.
> 
> 
OK; I'll try to explain.  Bear in mind that what I'm describing here is
a design process, not an algorithm to include in every mechanism.  Also
bear in mind that in the name of simplicity, I'm going to talk as if
we're adding lots of round trips to this thing, when in reality most of
them can usually be collapsed away by doing multiple things in the same
message.

So, assume that we start with some underlying authentication technology
that, at the end of its exchange, proves the identity of each
participant to the other.  Of course, you can use something that only
proves the initiator's identity to the acceptor, but that's less
interesting, because it doesn't provide any protection from a MitM
attack.  However, it can still be useful, combined with TLS, server cert
validation, _and_ channel binding.

Now, if the authentication scheme produces as one of its outputs some
secret that is known only to the client and server, we can add an
exchange to negotiate an RFC3961 enctype, use the shared secret to key
that enctype, at which point we can build channel bindings on an RFC3961
checksum, and do gss_getmic and gss_wrap as described in RFC4121 and PRF
as described in RFC4402; that is, exactly as for Kerberos.

If the authentication scheme does not provide a shared secret but does
provide a PRF, we can use _that_ to derive a secret key for the purpose
of keying an RFC3961 checksum, which we then use for CB, mic, and wrap.
In addition, in this case, the GSS-API-layer PRF ends up being a
perturbation of the underlying one, so that no input provided by a
caller can result in the same key we use to provide the other services.

Unfortunately, if all the underlying mechanism provides is a MIC
function or some other form of integrity protection, then we need to try
a bit harder.  In this case, we perform a DH exchange, which we protect
using the provided MIC.  This results in a shared secret, which we can
use to key PRF and wrap.  CB and gss_getmic can be provided using the
new key or directly using the built-in MIC capability.

Finally, if CB is _all_ you get, that's fine, because CB is basically
one-time MIC that is computed and verified as part of the authentication
exchange.  We can use this to protect the aforementioned DH exchange, if
we do the DH exchange before the rest of the authentication.  Note that
you can protect both the DH exchange and the actual underlying channel
identity, by producing a composite "channel binding" value which
contains both; this is what GS2 does to protect SASL-specific bits of
its exchange.

Of course, a DH exchange is expensive both computationally and in terms
of protocol complexity.  But, it can be done, provided the underlying
authentication method provides something we can build on.

Of course, if the underlying authentication technology provides none of
these capabilities, then we are stuck.  We can't pull an authenticated
cryptographic context out of thin air.

-- Jeff

---

From: Greg Hudson <[email-masked]>
Date: Sat, 02 Apr 2011 10:40:16 -0400

On Sat, 2011-04-02 at 00:36 -0400, Jeffrey Hutzelman wrote:
> Of course, you can use something that only

Why is channel binding needed if you have TLS with server cert
validation?

I realize that in practice, TLS server cert validation is often omitted
by the app, circumvented by the user, or reliant on a huge network of
potentially subvertable CAs.  But it sounds like you're asserting an
attack on client-only authentication which works even if it takes place
on a server-authenticated secure channel.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Sat, 02 Apr 2011 17:22:14 -0400

Nico Williams <[email-masked]> wrote:

>On Apr 2, 2011 9:40 AM, "Greg Hudson" <[email-masked]> wrote:
>>
>You still need to make sure that the name of the GSS acceptor
>corresponds to
>the name of the server.  The only simple way to do that is to specify
>the
>server's name to both libraries and hope it all works out (and forget,
>too,
>about the service name).  And what if the TLS server cert validation
>PKI is
>crap?  CB makes these issues go away.  But I will grant that SASL/GSS
>over
>TLS w/o CB is not altogether a security catastrophe... it works
>reasonably
>well quite often - just not always.
>
>Nico
>--

No, that argument doesn't hold in the case I was talking about, where the underlying mech doesn't prove acceptor identity.  I believe I mentioned CB there because without it, the server has no protection against replay of credentials previously exposed by a stupid client.  But in fact, whether that's a problem depends on the underlying mech.

---

From: Nico Williams <[email-masked]>
Date: Sat, 2 Apr 2011 17:36:23 -0500

> as described in RFC4402; that is, exactly as for Kerberos.

Note that there's no reason to use any part of Kerberos for this other
than spec and code reuse (a great reason, to be sure, but we don't to
scare anyone away, which is why i mention it :).

> provide a PRF, we can use _that_ [...]

If you have a PRF with shared state you almost certainly have a shared
secret key...

> new key or directly using the built-in MIC capability.

Huh?  If the mech gives you a MIC, well, use it!  Just exchange MICs
of the CB :)

---

From: Nico Williams <[email-masked]>
Date: Sat, 2 Apr 2011 17:36:45 -0500

You still need to make sure that the name of the GSS acceptor
corresponds to the name of the server.  The only simple way to do that
is to specify the server's name to both libraries and hope it all
works out (and forget, too, about the service name).  And what if the
TLS server cert validation PKI is crap?  CB makes these issues go
away.  But I will grant that SASL/GSS over TLS w/o CB is not
altogether a security catastrophe... it works reasonably well quite
often - just not always.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Sat, 2 Apr 2011 17:39:18 -0500

[resend]

> No, that argument doesn't hold in the case I was talking about, where the underlying mech doesn't prove acceptor identity.  I believe I mentioned CB there because without it, the server has no prot…

Sure, that's true.  But I do want to make clear that just having TLS
server certs does not provide a very good  binding of the app-layer
authentication to TLS.

---

From: Martin Rex <[email-masked]>
Date: Tue, 5 Apr 2011 03:31:24 +0200 (MEST)

> on a server-authenticated secure channel.

You want to be really sure that the authentication exchange that the
server sees through TLS is actually from an authentication handshake
of the client that does not use TLS (or is with a different server).

This is the type of problem that rfc-4559 HTTP Negotiate without
channel bindings is suffering from.

And when the authentication is password-based, you may have the problem
that humans often reuse passwords for different targets.

-Martin

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 09 Apr 2011 22:50:12 +0100

Shawn M Emery wrote:

> 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.

While some of the generic issues are the same for this document and for 
the OpenID one, this draft is in a better shape, IMHO. At least I think 
this is actually implementable without relying on some abstract 
definition of a browser.

Below are some specific comments:

1.  Introduction

   Security Assertion Markup Language (SAML) 2.0
   [OASIS.saml-core-2.0-os] is a modular specification that provides
   various means for a user to be identified to a relying party (RP)
   through the exchange of (typically signed) assertions issued by an
   identity provider (IdP).  It includes a number of protocols, protocol
   bindings [OASIS.saml-bindings-2.0-os], and interoperability profiles
   [OASIS.saml-profiles-2.0-os] designed for different use cases.

Is any protocol binding mandatory-to-implement for interoperability?

   The SAML mechanism described in this memo aims to re-use the
   available SAML deployment to a maximum extent and therefore does not
   establish a separate authentication, integrity and confidentiality
   mechanism.  The mechanisms assumes a security layer, such as
   Transport Layer Security (TLS), to protect against some attacks.

An Informative reference to TLS is needed here.

3.  Applicability for non-HTTP Use Cases

   2.  The RP sends an HTTP redirect as described in Section 10.3 of
       [RFC2616] to the browser to the Identity Provider (IdP) or an IdP
       discovery service with an authentication request that contains
       the name of resource being requested, some sort of a cookie and a
       return URL,

"URL" needs a reference.

   3.  The Relying Party transmits an authentication request encoded
       using a Universal Resource Identifier (URI) as described in RFC
       3986 [RFC3986] and a redirect to the IdP corresponding to the
       domain

Is this always an HTTP/HTTPS URI?

   7.  The IdP will convey information about the success or failure of
       the authentication back to the the RP in the form of an
       Authentication Statement or failure, using a indirect response
       via the client browser or the handler.  This step happens out of
       band from SASL.

I think we need a mandatory to implement SAML protocol mapping here,
otherwise this is not really implementable on the server side.

Also, the document should be clear that the SASL server (==RP) needs to 
be able
to talk HTTP/HTTPS.

   Please note: What is described here is the case in which the client
   has not previously authenticated.  If the client can handle SAML
   internally it is possible that the client already holds a valid SAML
   authentication token so that the user does not need to be involved in
   the process anymore, but that would still be external to SASL.

Would the client need to talk to RP using an HTTP/HTTPS connection?
I think a bit more details here would help.

Later in this section: I think an explicit statement about the need to 
correlate
the original TCP connection with the SAML authentication is needed.
Also explaining how this is done in the section with an XMPP example 
would help as well.

6.  Channel Binding

   The "gs2-cb-flag" MUST use "n" because channel binding data cannot be
   integrity protected by the SAML negotiation.  FIXME: Transfer channel
   binding in SAML assertion?

Yes, this needs to be decided before the document goes to IETF LC.

8.1.  Man in the middle and Tunneling Attacks

   This mechanism is vulnerable to man in the middle and tunneling
   attacks unless a client always verify the server identity before
   proceeding with authentication.  Typically TLS is used to provide a
   secure channel with server authentication.

Should this  provide some details on TLS server identity verification, 
e.g. via an RFC 6125 reference?

10.1.  Normative References

I think this section need a Normative reference to HTTPS.

---

From: "Cantor, Scott E." <[email-masked]>
Date: Sat, 9 Apr 2011 22:01:03 +0000

> this is actually implementable without relying on some abstract

Then that's a difference in text, not reality. There's nothing whatsoever that constrains a browser-based interface to a SAML IdP.

> otherwise this is not really implementable on the server side.

The reference needs to be to the SAML Browser SSO profile (given the goal of reusing that implementation).

-- Scott