Subject: [abfab] Comments on draft-ietf-abfab-aaa-saml

From: Sam Hartman <[email-masked]>
Date: Thu, 07 Nov 2013 11:27:28 -0500

Section 4:
The following text does not parse
   The RADIUS SAML binding defined by this binding Section 5 uses two
   attributes to convey SAML assertions and protocol messages
   [OASIS.saml-core-2.0-os] respectively.  

I think it would be more clear if we move the reference after
respectively.
I don't think it's right to say that more and reserved are ignored.
More for example will be set often and reserved should be handled as in
RFC 6929.

Section 5:
"A SAML Responder that refuses to perform a message exchange with the
SAML requester MUST silently discard the request"

Please clarify we mean ignore the attribute, not drop the entire RADIUS
packet on the floor.
It may well be that we generate an access reject as a result, but silent
discard at the radius level is not really what we want.

Section 5.3.1

Isn't the AAA server a SAML consumer of an authentication request?
If so, it seems like it's more realistic for it to apply policy based on
the NAS identity rather than the NAI realm as described in the text.
I wonder whether requester and responder might be better than issuer and
consumer in this section.

old:
A digitally signed request alone is not sufficient.
new:
A digitally signed request alone is not sufficient.  A AAA entity can
include a SAML message that it observes that is never intended by the
issuing SAML entity for this AAA session.

How exactly would one include a realm identifier in metadata?  That is,
is there well defined way to name a realm in SAML?

Section 7.3.1`:
Is this request in the initial access-accept?  Every access-accept?

Section 7.3.3:
Wait.  You're saying that my RADIUS server MUST look inside the SAML
message and if a certain attribute is present go change my EAP state
machine?

I don't think anyone will ever implement that.
Also, how does it interact with semi-long-term elements like Kerberos
TGTs or TEAP tickets?

Section 7.3.4:

Is the simple system model inside or outside the scope of this profile?
This also (and more importantly) applies to the requirements for the
response.

Ah, I see that this is handled later.

There are still a lot of todos.

---

From: "Cantor, Scott" <[email-masked]>
Date: Thu, 7 Nov 2013 17:22:38 +0000

>is there well defined way to name a realm in SAML?

No, not really. Historically we took some plains to not tie SAML entities
to DNS domains because in a lot of cases what we were really doing was
deciding whether to go along with the rest of the planet and conflate
email address with identity.

There are a bunch of things surrounding this notion that overlap with IdP
discovery (which can be realm based, like in edugain, but is that really
not just email address? And if not, do users understand the difference?)
and with how you do filtering of attributes.

At the end of the day, Shibboleth is the only implementation that really
ever leveraged anything like a "Realm" and we called it "Scope" and
defined a metadata extension for it that allows an IdP to have a many to
one relationship with a set of Scopes. Which in practice are domains,
though not by definition.

-- Scott

---

From: "Cantor, Scott" <[email-masked]>
Date: Thu, 7 Nov 2013 18:04:30 +0000

>No, not really. Historically we took some plains to not tie SAML entities

That should have been "we took some pains". ;-)

-- Scott

---

From: Sam Hartman <[email-masked]>
Date: Thu, 07 Nov 2013 13:10:37 -0500

OK.
So, we're telling people that they should confirm  that the realm
portion of the NAI is in the response or metadata for the IDP, but we
have no way to express that name in either interoperably?

That's possibly OK, but might need to be called out.

---

From: "Cantor, Scott" <[email-masked]>
Date: Thu, 7 Nov 2013 18:24:49 +0000

>That's possibly OK, but might need to be called out.

Or define something, yes. There are reasons to think something's going to
be needed. Realm-based discovery seems likely to be the path forward in
other areas.

-- Scott

---

From: Leif Johansson <[email-masked]>
Date: Thu, 07 Nov 2013 22:32:40 +0100

> be needed. Realm-based discovery seems likely to be the path forward in
I would't be surprised to see people asking to overloading Scope for
this as it gets deployed.

---

From: "Cantor, Scott" <[email-masked]>
Date: Thu, 7 Nov 2013 23:11:10 +0000

>this as it gets deployed.

Almost certainly, which I think is not a good fit. But I don't fully grasp
the requirements involved here. I know that Scope is not a direct fit for
doing domain-based discovery though.

The problem is that it will *usually* be a fit, which for too many people
means "good enough".

-- Scott

---

From: Leif Johansson <[email-masked]>
Date: Fri, 08 Nov 2013 00:39:57 +0100

> doing domain-based discovery though.
agreed
> The problem is that it will *usually* be a fit, which for too many people
I predict it will be a match about as often as Scope matches the email
domain which is increasingly the case.

There are several technology trends that tend to push orgs to less
complex domain structure and this will make it more likely that Scope ==
Realm == maildomain over time.

> -- Scott
>
>
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

---

From: David Chadwick <[email-masked]>
Date: Fri, 08 Nov 2013 05:24:13 +0000

> and with how you do filtering of attributes.

The attributes issue, of how the SP's required set is indicated to the 
IDP(s) and to the user, and user consent and choice (if alternatives 
exist) is a much bigger issue than the naming of realms. In fact I would 
say they are orthogonal. It would be nice to address both in ABFAB

David

---

From: Sam Hartman <[email-masked]>
Date: Fri, 08 Nov 2013 16:03:40 -0500

>>>>> "David" == David Chadwick <[email-masked]> writes:

    David> The attributes issue, of how the SP's required set is
    David> indicated to the IDP(s) and to the user, and user consent and
    David> choice (if alternatives exist) is a much bigger issue than
    David> the naming of realms. In fact I would say they are
    David> orthogonal. It would be nice to address both in ABFAB

Naming of realms is important because if you don't handle it correctly
significant security attacks exist where one RP can get attributes
intended for another or one users attributes can be substituted for
another.

---

From: David Chadwick <[email-masked]>
Date: Sun, 10 Nov 2013 21:47:17 +0000

Sam

there are at least two issues here

1. Ensuring that a claimed name really belongs to the claimant
2. Not having similar names that can confuse users

which are you most concerned with?

David

---

From: Leif Johansson <[email-masked]>
Date: Sun, 10 Nov 2013 22:52:08 +0100

> 2. Not having similar names that can confuse users
We're talking about names for entities so 1.

---

From: David Chadwick <[email-masked]>
Date: Sun, 10 Nov 2013 21:55:55 +0000

In a PKI this is the responsibility of the CA. In the case of ABFAB, its 
the responsibility of the trust router.

---

From: Leif Johansson <[email-masked]>
Date: Sun, 10 Nov 2013 23:17:31 +0100

On 11/10/2013 10:55 PM, David Chadwick wrote:
> In a PKI this is the responsibility of the CA. In the case of ABFAB,
> its the responsibility of the trust router.
The latter statement doesn't make sense. There is no trust router when
you use SAML metadata to manage trust in abfab which is what this
discussion is about.

---

From: David Chadwick <[email-masked]>
Date: Mon, 11 Nov 2013 07:21:03 +0000

Here is the rationale for my answer

1. the user types in the name of the remote realm to the RP
2. the RP trusts the trust router to set up the DH keys with some remote 
entity that purports to answer for this realm
3. This remote entity authenticates the user and sends the answer to the 
RP along with unsigned SAML assertions about the same user in a Radius 
response
4. Since the SAML assertions are unsigned the RP has no PKI to rely on. 
It only has the trust router. Consequently it is the responsibility of 
the trust router (admin) to check that this remote entity:
a) is the correct one to answer requests for this realm
b) does authenticate it users correctly
c) does issue correct SAML assertions for its users, regardless of the 
IDP name that accompanies the assertion

This implies that the trust router (admin) should publish the IDP name 
that is used by the realm when issuing its SAML assertions i.e. the 
trust router publishes realm name to IDP name mappings. An RP can then 
use this information to compare the names in SAML metadate.

regards

David

---

From: Gabriel López <[email-masked]>
Date: Mon, 11 Nov 2013 13:25:53 +0100

Hi,
 
    some comments

> Isn't the AAA server a SAML consumer of an authentication request?

section 1.4.5 in draft-ietf-abfab-arch-08 says that:
"The RP sends ...., and it may send a SAML Attribute Request in a AAA
attribute.  The AAA network checks that the identity claimed by the RP
is valid."

I guess the draft (arch-08) should say SAML AuthNRequest and,
optionally, AttributeRequest, if what the RP is waiting for is an
authentication statement, and optionally, attribute statements.
In general, the exchange of SAML messages between RP and IdP is not
clear in the drafts.
> Also, how does it interact with semi-long-term elements like Kerberos

What your concern is about? RADIUS server looking inside SAML sentences?
or changing EAP state machine?
The first one is necessary if the RADIUS server has to take into account
things such as LoA specified by the RP
Although I suppose an independent RADIUS module is in charge of the SAML
stuff.

Regards, Gabi.
> There are still a lot of todos.

- -- 
- --------------------------------------------------------------
Gabriel López Millán
Departamento de Ingeniería de la Información y las Comunicaciones
University of Murcia
Spain
Tel: +34 868888504
Fax: +34 868884151
email: [email-masked]

---

From: Leif Johansson <[email-masked]>
Date: Mon, 11 Nov 2013 17:57:56 +0100

On 11/11/2013 08:21 AM, David Chadwick wrote:
> 2. the RP trusts the trust router to set up the DH keys with some
> remote entity that purports to answer for this realm
We are not talking about trust router on this mailinglist at this time.

We're talking about using SAML metadata for abfab.

Do you have comments about name-to-key binding in that context?

---

From: David Chadwick <[email-masked]>
Date: Mon, 11 Nov 2013 17:35:14 +0000

I dont understand what your trust model is, if you dont have a PKI or a 
trust router, then how can an RP trust any SAML metadata that it has 
obtained from anywhere? It has to get this from a trustworthy source. I 
thought that the trustrouter (admin) was this TTP. If not, then who is? 
The federation authority was to my mind the trust router administrator, 
and was responsible for mapping the IDP name to realm name.

The name of a SAML IDP is irrelevant if you dont have a trustworthy 
source for this information. Similarly an unsigned key is also worthless 
from a trust perspective unless you get it face to face from the owner.

regards

david

---

From: Leif Johansson <[email-masked]>
Date: Mon, 11 Nov 2013 18:40:16 +0100

On 11/11/2013 06:35 PM, David Chadwick wrote:
> I dont understand what your trust model is, if you dont have a PKI or
> a trust router, then how can an RP trust any SAML metadata that it has
> obtained from anywhere? It has to get this from a trustworthy source.
> I thought that the trustrouter (admin) was this TTP. If not, then who
> is? The federation authority was to my mind the trust router
> administrator, and was responsible for mapping the IDP name to realm
> name.
Typically trust in SAML metadata done using signatures or some other
form of authentication of the metadata.

---

From: Josh Howlett <[email-masked]>
Date: Tue, 12 Nov 2013 01:48:01 +0000

>More for example will be set often and reserved should be handled as in

I meant ignored in the sense of not depicted within the table, but happy
with your change as it is less ambiguous.

>Please clarify we mean ignore the attribute, not drop the entire RADIUS

Yes, this needs clarifying.

>the NAS identity rather than the NAI realm as described in the text.

Your following correction cleans this up, I think.

>consumer in this section.

Yes, you're right. I think those bullets now read correctly.

>issuing SAML entity for this AAA session.

The new clarifying text is good.

>is there well defined way to name a realm in SAML?

Nope. I'll respond in the other thread.

>Is this request in the initial access-accept?  Every access-accept?

On your first question, this is unspecified because I don't think we need
to be prescriptive. On your second question, the profile is explicitly
defined as a profile of the SAML authentication request protocol, and that
would not permit that kind of message exchange. Happy to include
clarifying text on both counts.

>message and if a certain attribute is present go change my EAP state

Where are you reading that? The text says "establish the identity [...]
using RADIUS authentication"

>I don't think anyone will ever implement that.

Agreed, but that's not the intent!

>Also, how does it interact with semi-long-term elements like Kerberos

Out of scope. That's a problem at the RADIUS authentication level.

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: Sam Hartman <[email-masked]>
Date: Mon, 11 Nov 2013 20:53:16 -0500

Josh, since minutes have not been sent out:

1) Everyone seems to think the force authentication text reads as I do
and forces ignoring re-authentication state etc.
I seem to be the only one who has a concern so I'm in the rough.

Also, Alan and I believe that we should say to include the SAML request
in the first message. (Discussed in the WG session).

---

From: Josh Howlett <[email-masked]>
Date: Tue, 12 Nov 2013 02:13:16 +0000

>be needed. Realm-based discovery seems likely to be the path forward in

Having reflected on this some more, I'm now a bit ambivalent about the
whole discussion in 5.3.2. The text is assuming a particular SAML
deployment model (policy & configuration in signed and trusted metadata)
that will be true of some deployments but not others (e.g., a SAML proxy
infrastructure).

I am pretty sure that rewriting this text for the general case would yield
text amounting to "use technical methods to validate that names claimed by
other SAML entities are true, to whatever standard constitutes true for
you". This is implicit in the text in 5.3.1 for validating AAA names
(where the "technical method" is whatever AAA technology you have elected
to use), and so I am tempted to apply a similar model for the SAML case.

Josh.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 11 Nov 2013 21:48:50 -0500

>>>>> "Josh" == Josh Howlett <[email-masked]> writes:

    >>> 
    >>> OK.  So, we're telling people that they should confirm that the
    >>> realm portion of the NAI is in the response or metadata for the
    >>> IDP, but we have no way to express that name in either
    >>> interoperably?
    >>> 
    >> Or define something, yes. There are reasons to think something's
    >> going to be needed. Realm-based discovery seems likely to be the
    >> path forward in other areas.

    Josh> Having reflected on this some more, I'm now a bit ambivalent
    Josh> about the whole discussion in 5.3.2. The text is assuming a
    Josh> particular SAML deployment model (policy & configuration in
    Josh> signed and trusted metadata) that will be true of some
    Josh> deployments but not others (e.g., a SAML proxy
    Josh> infrastructure).

    Josh> I am pretty sure that rewriting this text for the general case
    Josh> would yield text amounting to "use technical methods to
    Josh> validate that names claimed by other SAML entities are true,
    Josh> to whatever standard constitutes true for you". 

Unfortunately, I think the above is a compelling argument why we need
something reasonably specific.
Because in your restatement you've lost the essential security issue.

It's not enough that we claim that SAML entities names are true.
That's actually not addressed by my reading of 5.3.2.The tricky issue is
making sure that when SAML entities produce messages, they intend to
allow the AAA entities discussed in 5.3.1 to use those messages.
This is more of an issue of GSS-API channel binding than it is SAML
naming.

Ultimately the SAML naming is a convenience for associating policy with
a SAML message.  I don't think it does more than that except in so far
as names are also attribute-like.

Section 5.3.2 is attempting to discuss the importance of making sure the
policy is appropriate for this channel as well as appropriate for the
named SAML entities however that's handled.

--Sam

---

From: Josh Howlett <[email-masked]>
Date: Tue, 12 Nov 2013 03:15:48 +0000

>This is more of an issue of GSS-API channel binding than it is SAML

Yes, you're right. The current text conflates the two issues of the issuer
authorising the presenter, versus the consumer identifying the issuer. I
think the right way to do this is at the binding level using the
response's Recipient attribute, which needs to name the NAS. If Scott
agrees (and if my brain does not implode in the interim) I'll propose some
text. I think we'll probably also want to extend the NAI Name Identifier
Format to accommodate naming the NAS, and use this name form within the
recipient attribute.

Josh.

---

From: "Cantor, Scott" <[email-masked]>
Date: Tue, 12 Nov 2013 04:22:47 +0000

>>This is more of an issue of GSS-API channel binding than it is SAML

I haven't yet been able to relate the text there to my understanding
(limited that it is) of channel binding.

I'll just note that if the requirement is really to carry GSS-API CB data,
there's already a slot for that in a SAML protocol extension I defined.

But what's the CB data here? All I know of is TLS-based CB.

>response's Recipient attribute, which needs to name the NAS.

I thought the goal was to relate the AAA entity sending the message to the
SAML entity issuing it, and that wouldn't be Recipient.

If you're trying to target the message to a receiving identity that
certainly could be Recipient, but if you're not signing, I don't see the
relevance of populating that as a security measure.

-- Scott

---

From: Josh Howlett <[email-masked]>
Date: Tue, 12 Nov 2013 06:52:04 +0000

>SAML entity issuing it, and that wouldn't be Recipient.

Sigh, I got the Requester and Presenter the wrong way around. Is this then
best tackled using subject confirmation? If so, would it be too much of a
stretch to use Holder of Key where the KeyInfo contains a KeyName naming
the AAA entity?

Josh.

---

From: "Cantor, Scott" <[email-masked]>
Date: Tue, 12 Nov 2013 07:24:10 +0000

>stretch to use Holder of Key where the KeyInfo contains a KeyName naming

That only works in one direction, and I think you need both here.

If this is *really* channel binding, literally, then there's already an
extension for that, but I don't think it's technically CB, just
conceptually similar.

You have two AAA peers exchanging messages and you want to bind the names
of those endpoints to the names in the messages. That's not CB per se,
it's name association..

And more to the point, you're not signing the messages, so nothing you put
into them is trusted above and beyond the AAA exchange already is. If your
requirement is to prevent a AAA entity from subverting the exchange by
misusing a message, you need something else to vouch for the relationship.
That's metadata, or the equivalent.

It can't be in the message. That only works if you're signing them
independently of the AAA channel so that you can mutually authenticate the
SAML layer. Then you might have channel binding for real because you can
bind the channel from the authentication of the exchange on top of it.

At least that's my read of it.

-- Scott

---

From: Josh Howlett <[email-masked]>
Date: Tue, 12 Nov 2013 11:16:39 +0000

>That only works in one direction, and I think you need both here.

Not for the specific issue -- of the AAA entity demonstrating its
authority to wield the assertion to the RP -- that Sam highlighted.

>of those endpoints to the names in the messages. That's not CB per se,

That's the other issue that I previously conflated. I don't believe that
is channel binding either (although I think the one above definitely is).
The SAML name is (as Sam said) essentially an attribute of the assertion
against which policy can be applied. As you say, the level of trust that
you have in that name is contingent on your trust in the AAA layer.

Josh.

---

From: "Cantor, Scott" <[email-masked]>
Date: Tue, 12 Nov 2013 16:56:52 +0000

On 11/12/13, 3:16 AM, "Josh Howlett" <[email-masked]> wrote:
>>>
>>>Sigh, I got the Requester and Presenter the wrong way around. Is this
>>>then best tackled using subject confirmation? If so, would it be too
>>>much of a

If it's acting as the entity being authenticated by the assertion, then
that would be subject confirmation of some kind, yes. Holder of key can be
interpreted pretty generally if it's desired.

But I don't see how that entity is really acting as the attesting entity.
It's not acting on behalf of the subject of the assertion, is it?

-- Scott

---

From: Sam Hartman <[email-masked]>
Date: Wed, 20 Nov 2013 07:05:30 -0500

>>>>> "David" == David Chadwick <[email-masked]> writes:

    David> I dont understand what your trust model is, if you dont have
    David> a PKI or a trust router, then how can an RP trust any SAML
    David> metadata that it has obtained from anywhere? It has to get
    David> this from a trustworthy source. I thought that the
    David> trustrouter (admin) was this TTP. If not, then who is? 

draft-ietf-abfab-aaa-saml talks about two trust models.

The first, AAA trust, is discussed in section 2.1 of
draft-ietf-abfab-arch-08 and  section 5.3.1 of
draft-ietf-abfab-aaa-saml-08.
You're correct that Moonshot plans to use trustrouter to instantiate
that trust model and currently we are mostly focused around that trust
model.

It's possible that someone will want to use an existing SAML federation
with its own existing trust model (probably based on signed SAML
metadata) and send SAML messages over RADIUS.  I'm not working on any
deployments of that, and I don't know of anyone in the Moonshot
community who is going out of their way to make that possible.  However
the Shibboleth SP already comes with the majority of code you need for
that.  So,  it's probably relatively easy to make that possible.

It turns out there are security implications when you give a barrer
token like a SAML assertion to a third party.  There are several ways of
looking at the problems that can result.  I've chosen to look at it is
confirming the party who gave you the assertion was intended to receive
it by someone you trust.
Section 5.3.2 of draft-ietf-abfab-aaa-saml, tries to discuss this.

We've found  it to be a complex discussion.

Does this help clarify what's going on?

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Wed, 20 Nov 2013 07:12:31 -0500

I think Scott's desire for a symmetric solution is strongly desirable.

The issue (which is conceptually similar to CB but is not technically
related to CB) appears in both directions.

The RP needs to demonstrate that it SAML message should be presented by
the RP's AAA entity.
-
The IDP needs to demonstrate to the RP that its assertion should come
via the expected AAA realm.

Both issues matter, and a symmetric solution seems like a win.