Subject: [abfab] SAML binding attack (thanks Jim Schaad)

From: Sam Hartman <[email-masked]>
Date: Mon, 29 Jul 2013 08:53:07 -0400

Jim was reviewing some notes Josh and I are exchanging about
abfab-aaa-saml.

Consider what happens if a signed SAML request is included  in  an
access request.

Assume that the AAA server/SAML IDP validates the signature against
metadata and applies policy based on the entity ID in the SAML request.

If the response (especially assertions) is encrypted to a key associated
with that  entity from metadata, then everything is fine.

Similarly if metadata contains some indication that binds this
particular RADIUS NAS to the entity ID, everything is also fine.

However, without that binding, the IDP only knows that at some point the
entity generated this authentication request.
In the SAML Web SSO profile, the assertion is going to be sent to a URI
from metadata (as I understand it) so the IDP knows the assertion is
being sent to the correct RP.

However, for our RADIUS binding, we're planning on returning the
assertion in an access-accept.
Under the assumptions so far we know that the SAML entity generating the
request is entitled to be treated as described by the metadata.  We know
according to assumptions Josh and I propose to add to the RADIUS binding
that the NAS claims to be that SAML entity.
However, we don't know if this claim is credible.

The NAS may have captured the SAML request from somewhere.
We may be about to release attributes to the NAS that the NAS is not
entitled to receive.

I find this interesting, because so far I've generally assumed that if
you get a signed SAML request you could apply the policy you'd use if
you got the same request in the web SSO profile.
However that appears not to be the case.

--Sam

---

From: "Cantor, Scott" <[email-masked]>
Date: Mon, 29 Jul 2013 13:43:10 +0000

>being sent to the correct RP.

Typically, but it's not uncommon to rely on request signing as a
substitute for explicitly checking. But the difference, I guess, is that
if you request a response for a web site you don't control, you obviously
aren't going to get much out of it.

>We may be about to release attributes to the NAS that the NAS is not

That window on capture ought to be a few minutes.

>However that appears not to be the case.

I don't think there's really a major difference. It comes down to
freshness and replay.

-- Scott

---

From: Sam Hartman <[email-masked]>
Date: Mon, 29 Jul 2013 10:14:07 -0400

>>>>> "Cantor," == Cantor, Scott <[email-masked]> writes:

    >> The NAS may have captured the SAML request from somewhere.  We
    >> may be about to release attributes to the NAS that the NAS is not
    >> entitled to receive.

    Cantor,> That window on capture ought to be a few minutes.

Sure, but it takes a lot less than a few minutes to generate an HTTP
request.

Consider for example an attacker who runs a development IDP somewhere in
a set of SAML metadata.  Cant't that attacker go ask random websites to
send SAML requests?
In the SAML ECP gss mechanism is the SAML request sent directly to the
IDP or is it sent to the client?
If client, then the attacker can get SAML requests from many RPs.

So, I don't see how making the window short helps much.
It seems like there are important classes of attacker who can easily get
fresh new requests.
Or am I missing something?

--Sam

---

From: "Cantor, Scott" <[email-masked]>
Date: Mon, 29 Jul 2013 14:29:47 +0000

>a set of SAML metadata.  Cant't that attacker go ask random websites to

Yes, but in the browser case, they'll be signed with that IdP's endpoint
location in them, and be useless to send anywhere else. That's what you're
missing here, I expect (and is also missing in ECP).

In the ECP case, the issue is more the weakness of replayable
authentication, but the attacker does have to compromise both legs of
communication. If all you do is get between the client and RP, then the
protection is, as mentioned, encryption, or the use of CB to detect that
the client talking to the IdP is talking to a different TLS endpoint than
the one owned by the actual SP that signed the request.

That's why I was interested in adding CB to the underlying profile, GSS
aside.

But if you compromise both legs, it's game over unless the client/IdP
exchange is mutual TLS or something like that.

>IDP or is it sent to the client?

The client.

>If client, then the attacker can get SAML requests from many RPs.

That's true, modulo the above.

But in ECP, if you really, really care about the confidentiality, you can
always omit the attributes and do queries for them, the same as Shibboleth
did in the SAML 1.1 days.

It's one trust fabric for me, so I can mix and match.

-- Scott

---

From: Sam Hartman <[email-masked]>
Date: Mon, 29 Jul 2013 11:17:08 -0400

So, if I'm understanding correctly.

A moonshot RP could take an ECP SAML request and forward to a moonshot
IDP+AAA combination.
If this was a fresh request then the SAML request might not correspond
to the AAA RP.

A Moonshot RP that can intercept SAML requests towards an interesting
IDP and suppress them from getting to the IDP can do the same for web
SSO.
(I don't consider this particularly interesting)

ECP can protect itself against this  because the client potentilaly
evaluate the request before forwarding to the IDP.

Do I have it right now?

---

From: "Cantor, Scott" <[email-masked]>
Date: Mon, 29 Jul 2013 15:34:56 +0000

>If this was a fresh request then the SAML request might not correspond

I think that's true, yes.

>evaluate the request before forwarding to the IDP.

Possibly. There are a variety of spots where problems can be prevented,
including channel binding, but also including the use of the field
normally used to identify the web site URL to identify the GSS acceptor
(in the GSS case with something like SSH that lacks channel binding).

So for example if you open a connection to service@host, that goes in the
SAML request and would be checked against metadata by the IdP to ensure
the signing key used is authorized for use by that identity.

The mutual flag in GSS depends on signing the request, and obviously in
the absence of encryption an IdP probably shouldn't be sending sensitive
data for delivery to requester it can't verify.

-- Scott

---

From: "Cantor, Scott" <[email-masked]>
Date: Mon, 29 Jul 2013 17:12:11 +0000

>the signing key used is authorized for use by that identity.

Strike that, that really doesn't prevent the attack you're talking about.
If there's no CB, then the attacker can just relay messages and the IdP
can't help the client much.

So the real answer is, yes, it's an issue that bugged me adapting ECP to
non-web, and the best solution I came up with was channel binding. But
there's not much I can do about first-contact SSH, no. There's XML
encryption and/or use of queries, that's about it.

-- Scott

---

From: Nico Williams <[email-masked]>
Date: Mon, 29 Jul 2013 12:30:44 -0500

Regarding SSH, maybe we should:

a) add a new userauth type that does use CB,

b) ditto key exchange.

---

From: "Cantor, Scott" <[email-masked]>
Date: Mon, 29 Jul 2013 17:39:17 +0000

>a) add a new userauth type that does use CB,

There would have to be a CB type defined for SSH also, of course, but in
any case I'm just noting current state.

It's worth reviewing my security text for the next draft I'm doing for
sure, but that's a topic for kitten, not here.

-- Scott

---

From: Nico Williams <[email-masked]>
Date: Mon, 29 Jul 2013 12:49:54 -0500

> any case I'm just noting current state.

Oh, maybe I misunderstood.  The CB for SSHv2 connections is not
defined, but quite obviously the session ID works; it is not available
until *after* initial key exchange completes.  So if you need to use
it you'd not be able to use it in GSS key exchange, but you could
create a new key exchange alg that uses something else.