Subject: SAML CB strawman (was RE: Speaking in support of Scott's SAML proposal)

From: "Scott Cantor" <[email-masked]>
Date: Fri, 13 Aug 2010 14:02:51 -0400

> The outcome of authentication signal itself needs to be authenticated,
> implicitly or explicitly.  Specifically, it must be impossible for an
> MITM to make a client think authentication succeeded when the real
> server thought it failed.

Yeah, I thought that's what you meant. I think that the goal here is to
implicitly do it through the IdP, which is why we have to sign the
AuthnRequest coming from the RP and get the CB into that. Often in SAML the
request isn't signed but I was leaning towards requiring it anyway in rev of
my draft, because without the web as the context, there's no location-based
authentication of URLs occurring.

> Does the client get an indication from the IdP as to whether the CB
> check passed?  Presumably the IdP won't issue the assertion if the CB
> fail to match!  Assuming that, then, yes, your approach works.

Yes, that's the indication. (And of course, the client probably
authenticates the IdP via TLS, unfortunately, it's still turtles all the way
down. I doubt that's news to anybody.)

> The RP doesn't have to check the CB data at this point if it trusts the
> IdP to have done it.  And if the client doesn't independently pass CB
> data to the RP then there's nothing the RP can do but trust that the IdP
> did it.

The reason I want it in the assertion regardless is so that the RP knows
that the client didn't manufacture an unsigned request without the CB data
and get the IdP to issue the assertion without any regard for that step.
 
> I believe your strawman stands.

If so, there are two main choices for capturing it, SubjectConfirmation and
Conditions. SC is somewhat elegant for this, although if the client isn't
sending the CB data to the RP at the end, it isn't really "confirming"
itself with it. Plus that would formally alter the underlying SAML profiles,
which assume bearer.

Using a new Condition is probably just as good and composes with the SAML
profiles well.

I need to read the RFC(s) to understand the types of TLS CB and get a handle
on how to represent them in the XML, but I think we might have an answer.

Thanks,
-- Scott

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 13 Aug 2010 13:28:36 -0500

On Fri, Aug 13, 2010 at 02:02:51PM -0400, Scott Cantor wrote:
> AuthnRequest coming from the RP and get the CB into that. 

Yes, that works.

>                                                           Often in SAML the

It's almost certainly better to do that, yes.

> authenticates the IdP via TLS, unfortunately, it's still turtles all
> the way down. I doubt that's news to anybody.)

Heh.  But here's the thing: if you reduce the number of places where we
rely on TLS' PKI to just user/device enrolment, then you've greatly
reduced the scope for attack.

> and get the IdP to issue the assertion without any regard for that step.

Oh, sure, I see your point.  Of course, a single bit from the IdP
indicating that it checked the CBs and they matched will do.

> on how to represent them in the XML, but I think we might have an answer.

You should represent them as a two item tuple: {CB type, CB data}.  The
CB data are opaque, binary data.

RFCs 5056 and 5929 are the relevant RFCs here.

Typically I think you'll find that getting at the 'tls-server-end-point'
CB is easier than 'tls-unique' because TLS APIs will give you access to
the server's cert and you can compute the CB data from that (well, with
a bit of effort).

Nico
--

---

From: "Scott Cantor" <[email-masked]>
Date: Fri, 13 Aug 2010 14:38:12 -0400

> reduced the scope for attack.

Right. Leap-of-faith works very well here also, since a users IdPs are few,
and stable.

> indicating that it checked the CBs and they matched will do.

A Condition without any data in it is the SAML equivalent of a bit. This is
XML, after all, tens of Unicode characters where a single bit will do.
 
> RFCs 5056 and 5929 are the relevant RFCs here.

Yes, thanks.

> the server's cert and you can compute the CB data from that (well, with

I'm assuming the relevant pieces I'm defining are agnostic about it (thus
the encoding of the type with the data).

-- Scott

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 13 Aug 2010 13:47:20 -0500

> Right. Leap-of-faith works very well here also, since a users IdPs are few,

Exactly.

> the encoding of the type with the data).

They must be.