Subject: Re: [kitten] sasl saml and sasl openID

From: "Klaas Wierenga (kwiereng)" <[email-masked]>
Date: Mon, 15 Nov 2010 14:51:10 +0100

Ehm, I was thinking of computing a key with the saml authn req and the key
material from tls as input, would that work?

Klaas

P.s sorry for the format, typing on my phone

Simon Josefsson <[email-masked]> wrote:

Klaas Wierenga <[email-masked]> writes:

> well, yes, not having to touch the IdP is a design goal. But I think we
> all would like to see the overall security of the solution improve. So
> if IdPs do support CB why not use it, so I would be happy to have an
> optional CB.

Agreed.

>> One unpleasant aspect of this is that the client needs to be able to
>> insert its local channel binding into the SAML AuthN request received
>> from the server, so that the SP (and IdP) can check that the CB is
>> correct, and/or also be able to parse the SAML AuthN request to extract
>> the CB used by the server, so the client can check that the CB is
>> correct.  This will be possible to implement, but requires some SAML
>> knowledge to the otherwise SAML-unaware SASL implementation.
>
> Hmm yes. Does the CB data have to be inside the AuthN Request? Can it
> not be concatenated to it instead? I.e. can the client not treat the
> SAML request as a blob?

The problem then is how is the CB data cryptographically bound to the
SAML authentication?

For sake of thinking about it, consider if the TLS session between
client and server are anonymous and there is a MITM on it.  One way to
detect the MITM is to verify CB on the client and server side.  You
can't trust the TLS channel to provide data integrity of the CB data,
because of the MITM.

Putting the CB in the SAML negotiation is one obvious out-of-band (as
far as the TLS session is concerned) way to verify the CB.

I'm not saying there is no other way, just that I'm not seeing it.

Wild ideas could include deriving a key from the SAML authentication,
and using that to integrity check the CB.  However, since the client
presumably has no SAML knowledge, achieving that seems difficult.

Here is how it could work, in more detail:

1) The server adds the CB data in a SAML tag in the SAML AuthN request.

2) The client verify that the CB data is the same as it has locally.

   (Note, here a MITM could have replaced the CB data with something
   else, but that will detected later.)

3) The client sends the AuthN request off to the IdP, which copies the
   CB data into the SAML AuthN Statement.

4) The server verify that the CB data is the same as it sent.

   (This step will detect of there were a MITM.)

There is one potential problem with this: if the MITM is ALSO sitting
between the client and the IdP, it could replace the CB data, and
everything would look fine to both the client and server.  Thus, the
security considerations of this mechanism should describe this attack
and there should be a requirement that TLS with proper server
certificate validation MUST be used by the browser talking to the IdP.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 15 Nov 2010 23:12:30 +0100

> material from tls as input, would that work?

I don't see how -- both the saml authn req a client receives and
anything derived from the TLS channel is potentially known by the
attacker.  At least a simple approach like Key = HMAC(SAML-AuthN-Req,
CB), and then sending some data signed (HMAC-wise) with that key,
wouldn't work because the attacker can replace it.

However, here is a one way to reduce the SAML parsing knowledge the
client needs to have:

1) The server constructs the AuthN request, with a CB field populated
with a nonce string that is unique within the authn request.

2) The server sends to the client two fields: the authn request and the
nonce.

3) The client searches for the nonce within the authn request, replaces
it with its local CB data.

4) The client spawns the browser with the newly constructed authn
request and completes authentication in the browser.

5) The server retrieves that authn request+statement (are both possible
to get?) and checks that the authn request was identical to what it
sent, except for the s/nonce/CB/ substitution.  If everything looks
fine, the server accepts the client.

6) The client trusts the server to detect any MITMs with the CB data.

Again, security considerations needs to state that client<->IdP
communication MUST be server authenticated, to avoid attackers doing
MITM on both the client<->server and client<->IdP communication and
replacing CB in both channels.

Please tell me what I'm missing. :-)

/Simon

---

From: "Scott Cantor" <[email-masked]>
Date: Mon, 15 Nov 2010 17:19:22 -0500

> it with its local CB data.

If the request is signed, you just broke it. It also adds far more parsing
to the client than you need.

> replacing CB in both channels.

Assuming that's in play (as it is in EC), then you can do something similar
to what I'm doing. Just have the SP sign its CB into its AuthnRequest, and
have the client add its CB to the message to the IdP (you'd need a new
browser binding for this, essentially extending HTTP-Redirect).

The IdP authenticates both parties, compares the CB, and either fails the
request or fulfills it.

It's less structured than the EC version, which uses SOAP headers to carry
all the CB data and signaling, but it's analagous.

-- Scott

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 16 Nov 2010 10:51:24 +0100

> to the client than you need.

Ouch.  It might be useful to add a example with a signed AuthN request
to SAML20/SAML20EC to illustrate this, other readers may be as
SAML-illiterate as I am.

> all the CB data and signaling, but it's analagous.

This approach seems easy to implement but it requires a modified IdP.
Both the client and server is trusting the IdP to verify CB here, but
maybe that is good-enough.

/Simon

---

From: "Scott Cantor" <[email-masked]>
Date: Tue, 16 Nov 2010 09:55:41 -0500

> to SAML20/SAML20EC to illustrate this, other readers may be as

We would probably want to note that clients that have to handle the requests
need to take care not to modify them.

> This approach seems easy to implement but it requires a modified IdP.

There is no approach to any of this that doesn't modify the IdP somehow. You
pick your modification. The reason for my forked thread was that I think the
more relevant trade-offs are in the client experience before we worry about
what to modify.
 
> maybe that is good-enough.

It turns out to be convenient, but there are probably other options in the
EC case once a key is involved. In the browser case, I think you'd be hard
pressed to come up with anything since you can add something to the initial
request to the browser from the SASL mech, but basically you have no control
afterwards.

-- Scott