Subject: [abfab] Significant concerns about aaa-saml presentation

From: Sam Hartman <[email-masked]>
Date: Thu, 24 Jul 2014 09:35:32 -0400

hi.
I was very surprised to hear Rhys's presentation on
draft-ietf-abfab-aaa-saml today, because Josh proposed to solve a
different problem than we've been working on over the last year.
Also, I do not feel very comfortable about the proposed solution.

As I understand it, in the case where we're not using SAML metadata, and
where we're relying on the AA trust fabric, we make the requirement that
the AAA entities correspond to the SAML entities.
So, we don't need to constrain the SAML naming because  the AAA entities
are making the assertions that the SAML names also correspond to the AAA
names.

In the case where we're trusting SAML metadata or policy, the issue is
that we need to avoid a cut&paste attack where a SAML message intended
for one party is intended for another party.  The issue we are trying to
solve is how to indicate in SAML messages or metadata that a particular
AAA endpoint was a valid destination for a binding or entity.

This issue is handled in the web profile by having the IDP redirect back
to the service provider.  We have more complexity because rather than
sending the message directly over HTTPS, the home AAA server sends the
message back over AAA.  we need to make sure that the home AAA server is
not man-in-the-middling the IDP--being a legitimate SP towards the IDP,
getting an assertion, and then using that assertion to give one of its
users access.

We've had a lot of discussion on this already, and I am fairly sure we
already rejected the approach of constraining the entity identifiers of
the SAML endpoints.

The approach proposed today is one that I prefer less well than
approaches Josh, Rhys and I have discussed offline.

---

From: Josh Howlett <[email-masked]>
Date: Thu, 24 Jul 2014 15:41:12 +0000

Hi Sam,

> where we're relying on the AA trust fabric, we make the requirement that the
> AAA entities correspond to the SAML entities.

Yes, but I believe that we also need to constrain SAML naming to the extent that SAML entities are making claims about their names to other entities in a way that is consistent with the underlying AAA system.

For example, in a model where AAA trust is assumed sufficient, a relying party could consume the same SAML name from two entities. This isn't a problem if a relying party is just interested in consuming the rest of the assertion (attributes, etc.) that relate to an authenticated principal but, for example, it would impede a subsequent SAML exchange where all the requestor has is a SAML name for an entity whose semantics say nothing about how to reach it using AAA.
 
> In the case where we're trusting SAML metadata or policy, the issue is that
> we need to avoid a cut&paste attack where a SAML message intended for
> one party is intended for another party.  The issue we are trying to solve is
> how to indicate in SAML messages or metadata that a particular AAA
> endpoint was a valid destination for a binding or entity.

Ah yes, the slides were not explicit about this, sorry. The assertion would be scoped to an <Audience> (the valid destination) using the proposed format, signed by the issuer, and use a standard SAML entity identifier to identify itself. The recipient, having validated the signature against the metadata, could validate itself as the intended <Audience>.

Josh.

Janet(UK) is a trading name of Jisc Collections and Janet Limited, a 
not-for-profit company which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238

---

From: Leif Johansson <[email-masked]>
Date: Thu, 24 Jul 2014 17:54:31 +0200

> Hi Sam,

(not speaking as chair)

> Yes, but I believe that we also need to constrain SAML naming to the extent that SAML entities are making claims about their names to other entities in a way that is consistent with the underlying…

Fair enough but I believe your cure is much worse than the affliction of
having to deal with SAML metadata.

	Cheers Leif

---

From: Josh Howlett <[email-masked]>
Date: Thu, 24 Jul 2014 16:03:36 +0000

Hi Leif,

> having to deal with SAML metadata.

Could you elaborate?

Josh.

---

From: "Cantor, Scott" <[email-masked]>
Date: Thu, 24 Jul 2014 16:04:31 +0000

On 7/24/14, 11:41 AM, "Josh Howlett" <[email-masked]> wrote:
>
>Ah yes, the slides were not explicit about this, sorry. The assertion
>would be scoped to an <Audience> (the valid destination) using the
>proposed format, signed by the issuer, and use a standard SAML entity
>identifier to identify itself. The recipient, having validated the
>signature against the metadata, could validate itself as the intended
><Audience>.

I'm not sure what your threat model is, but that doesn't really prevent a
MITM. The binding-level protections in SAML are not Audience, but
Destination/Recipient attributes, because those are actual network
endpoints. Audience is like a message-level constraint on the very end of
the chain of hops, but it can't limit the chain of hops.

If I understand the point of Sam's comment, he's concerned about the same
problem I can't really solve in SAML-EC, which is that the client is
essentially driving the bus here, and not the IdP, so there isn't any way
to control what endpoint(s) the message can be delivered to.

The only fix for me was channel binding as a backstop to prevent MITM
attacks, because in my model the IdP is the one validating the channel
binding for the two parties trying to communicate.

(If I'm not talking about the same problem, just dismiss my comment.)

-- Scott

---

From: Leif Johansson <[email-masked]>
Date: Thu, 24 Jul 2014 18:17:30 +0200

>> having to deal with SAML metadata.

I think you are hoping for a way to establish canonical names for
AAA-SAML entities based on properties of the endpoint that makes the
name unique.

I believe that will be ultimately a fruitless exercise and I believe
the practice of SAML metadata management doesn't introduce enough pain
to warrant introducing a complex naming scheme for endpoints to avoid
it (if that is indeed your proposal).

The normal approach for a SAML binding would be to define a Binding URI
for the new endpoint. The signature on SAML metadata would provide
name2key binding between the entityID and the Binding element. This
approach requires a URI representation of EAP endpoints but I assume
that wouldn't be hard.

What is wrong with that approach and what (if any) problems remain if
we choose to go that way for ABFAB?

	Cheers Leif

---

From: Leif Johansson <[email-masked]>
Date: Thu, 24 Jul 2014 18:18:57 +0200

> approach requires a URI representation of EAP endpoints but I assume

s/name2key//g

---

From: Sam Hartman <[email-masked]>
Date: Fri, 25 Jul 2014 11:40:11 -0400

So, What I think we need to say in the SAML is:

In an assertion:

1) I expect the foo.bar.example.com IDP realm to interact with this
message.

2) Possibly/probably I expect the baz.example.net RP realm to receive
this message eventually.

I'm happy to let the RP evaluate the trust of the AAA fabric between the
IDP and RP and to evaluate whether the fabric in use provides sufficient
trust for the IDP.  I think it's important make sure the message was
intended to be handed to the given IDP and probably/possibly/I'm not
100% sure to make sure the message was destined for the given RP.  It's
clear that we need to make sure the destination of the message at the
SAML layer, but possibly not at the AAA layer.  However, we definitely
care about the injection point into the AAA layer because that may be
the only AAA name towards the IDP that the RP knows and can validate.

--Sam