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

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 01 Dec 2010 13:52:02 -0500

--On Monday, November 15, 2010 01:27:13 PM +0100 Simon Josefsson 
<[email-masked]> wrote:

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

This doesn't actually bind the channel in the eyes of the client, because 
the client has no way to tell whether the verification in step 4 succeeded. 
I think I like Scott's approach better, where both the client and SP 
provide signed copies of the CB data to the IdP, and the IdP compares them. 
This does require a secure channel between the client and IdP, but securing 
that channel is not really up to the GSS/SASL mechanism.

-- Jeff

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 1 Dec 2010 17:25:43 -0800

On Dec 1, 2010, at 10:52 AM, Jeffrey Hutzelman wrote:

> This does require a secure channel between the client and IdP, but securing that channel is not really up to the GSS/SASL mechanism.

Perhaps I'm overreacting, but that kind of statement makes me nervous.  I hope someone has ensured:  a) that the external dependence does not create circular or unresolvable dependencies in practice.  I don't feel qualified to make that judgement ATM.  b) external dependancies tend to make practical deployments harder, though I believe Scott had some evaluation of that.

---

From: "Cantor, Scott E." <[email-masked]>
Date: Thu, 2 Dec 2010 15:02:57 +0000

> > This does require a secure channel between the client and IdP, but
> securing that channel is not really up to the GSS/SASL mechanism.
> 
> Perhaps I'm overreacting, but that kind of statement makes me nervous.  I
> hope someone has ensured:  a) that the external dependence does not
> create circular or unresolvable dependencies in practice.  I don't feel qualified
> to make that judgement ATM.  b) external dependancies tend to make
> practical deployments harder, though I believe Scott had some evaluation of
> that.

If I understand your concern, there is no way around securing that hop explicitly. If you don't, SAML falls apart in the majority of cases, because once you allow for a MITM there, most of the MITM mitigations in the majority of three actor (client/RP/IdP) profiles fall apart. Most of them are predicated on knowing that the MITM might be between the client and the RP but NOT between the client and the IdP. If it's between both, you're generally sunk.

There is no circular dependence on that assumption to achieve the addition of CB. I've defined all that already for ECPv2 [1] and I don't see any holes yet, though obviously it needs expert eyeballs.

-- Scott

[1] http://wiki.oasis-open.org/security/SAML2EnhancedClientProfile