Subject: [kitten] SAML attributes and assertions for naming extensions

From: Sam Hartman <[email-masked]>
Date: Tue, 18 Oct 2011 17:57:17 -0400

Hi. 

As a recollection while working on draft-hartman-gss-eap-naming which
became draft-ietf-abfab-gss-eap-naming I introduced the concept of a
naming extensions context. The idea is that two attributes are different
depending on some broad context of their interpretation. The idea is for
example that Kerberos attributes in an enterprise context probably want
to be interpreted differently than SAML attributes in a federated
context.

Since then this concept has been worked into the core naming extensions
document. (Perhaps some day we'll publish that)

However, now it's time to align things between GSS-EAP and SAML ECP and
other things.

I think we're talking about basically the same context in both
mechanisms for the SAML assertion and attributes. We're talking about
what I'll call the basic federated context. Attributes are asserted by a
party associated with the authentication of the subject. The attributes
are integrity protected and their origin authenticated.  That is in EAP,
if the RADIUS integrity protection fails we won't get this far. In SAML
ECP, if we don't trust metadata for the IDP or if the SAML assertion is
not signed, we won't make it this far.

It's probably OK in this context to include attributes asserted by a
third party that are re-asserted or otherwise vouched for by the IDP.

It's probably a different context if you have third-party assertions
including attribute query results or somehow multiple authentication
statements.

The key distinguisher of the context is that the IDP and acceptor are in
different trust domains but thet IDP and attributes are in the same
trust domains.

First, have I got the context right?

Second, what URN do we want to use.  The current
URNurn:ietf:params:gss-eap:saml-aaa-assertion has gss-eap and aaa in it
both of which are wrong.

Comments welcome.

---

From: "Cantor, Scott" <[email-masked]>
Date: Wed, 19 Oct 2011 00:01:39 +0000

>to be interpreted differently than SAML attributes in a federated

And I think the proposal is that the context appear inside the naming
extension attribute name as a modifier?

>including attribute query results or somehow multiple authentication

My current implementation of that doesn't distinguish that case (the
attributes end up in the same bucket), but it's an easy fix.

https://issues.shibboleth.net/jira/browse/SSPCPP-399

>First, have I got the context right?

Much of the time the use of third party sources tends to be for "local"
sources associated with the domain of the application, but I agree in
principle with the need to distinguish that. I suppose in that sense the
cases I've seen would match what you were referring to for Kerberos, the
enterprise scenario.

>URNurn:ietf:params:gss-eap:saml-aaa-assertion has gss-eap and aaa in it

Is it necessary that the value be fixed? If the application-specific names
of the attributes themselves aren't fixed, do the contexts have to be?

-- Scott

---

From: Sam Hartman <[email-masked]>
Date: Tue, 18 Oct 2011 20:17:50 -0400

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

    Cantor,> On 10/18/11 5:57 PM, "Sam Hartman" <[email-masked]> wrote:
    >> became draft-ietf-abfab-gss-eap-naming I introduced the concept
    >> of a naming extensions context. The idea is that two attributes
    >> are different depending on some broad context of their
    >> interpretation. The idea is for example that Kerberos attributes
    >> in an enterprise context probably want to be interpreted
    >> differently than SAML attributes in a federated context.

    Cantor,> And I think the proposal is that the context appear inside
    Cantor,> the naming extension attribute name as a modifier?

Right.

    >> It's probably a different context if you have third-party
    >> assertions including attribute query results or somehow multiple
    >> authentication statements.

    Cantor,> My current implementation of that doesn't distinguish that
    Cantor,> case (the attributes end up in the same bucket), but it's
    Cantor,> an easy fix.

Well, note that anything coming out of attribute mapping in your SP is
    completely separate and is unprefixed; the administrator is assumed
    to know their own policy.

I'm not sure the most intuitive ECP implementation on top of Shibboleth
SP would expose this at all. I'd encourage people to do so; see below.

    >> First, have I got the context right?

    Cantor,> Much of the time the use of third party sources tends to be
    Cantor,> for "local" sources associated with the domain of the
    Cantor,> application, but I agree in principle with the need to
    Cantor,> distinguish that. I suppose in that sense the cases I've
    Cantor,> seen would match what you were referring to for Kerberos,
    Cantor,> the enterprise scenario.

right.

    >> URNurn:ietf:params:gss-eap:saml-aaa-assertion has gss-eap and aaa
    >> in it both of which are wrong.

    Cantor,> Is it necessary that the value be fixed? If the
    Cantor,> application-specific names of the attributes themselves
    Cantor,> aren't fixed, do the contexts have to be?

So, I think there are two cases here.  The first and probably more
common is that an administrator uses some mechanism like your attribute
mapping mechanism to map attributes.  We don't care much about that case
in the IETF.

The second case is that someone is specifying a protocol--either in the
IETF, or some community, where you do want the attributes to be
standardized.

To refer to an attribute in a protocol  you need   to know its context
and name.

I do think there are some realistic cases for this, although not many
involve SAML attributes:

1) I want those RADIUS attributes. For example there is a draft for SNMP
over ssh and another draft for RADIUS SNMP authorization. It seems
entirely reasonable to me to want to implement that draft for gss-eap
and in that case to want to access the specific RADIUS attributes that
the RADIUS mapping draft says to use.

2) It seems entirely reasonable to want to ask for the raw assertion
from your GSS EAP or ECP mechanism to go do something with it with your
own SAML library.

So, I'd prefer the context be fixed. I think we need it to be fixed for
GSS-EAP. If the use cases for ECP are going to be different then we
should consider that. However it would be valuable if you could plug one
in case of the other.

--Sam

---

From: "Cantor, Scott" <[email-masked]>
Date: Wed, 19 Oct 2011 01:10:29 +0000

>to know their own policy.

That's generally true, but it's still desirable for applications sitting
on top to be able to distinguish between a piece of data from one source
vs. another.

>should consider that. However it would be valuable if you could plug one

I guess the way I look at it is that as a consumer of the GSS naming
extensions, I'd be physically ill shipping code that hardcoded any names,
so I see it all as a config time question.

But then I'm also accused of designing systems that are too complex.

-- Scott

---

From: Nico Williams <[email-masked]>
Date: Tue, 18 Oct 2011 21:17:31 -0500

> But then I'm also accused of designing systems that are too complex.

We should want to not hard-code mechanism OIDs, for example, but we
have little choice but to hard-code things whose semantics must be
embedded in the application.  For example: name types.

We've added mechanism attributes as a way to avoid hard-coding
mechanism OIDs: hard-code the semantics you want rather than the
mechanisms you know at that time support those semantics.  We could do
that with mechanisms, but name-types seem to basic a unit for further
decomposition.  Ditto, I think, naming attributes, though perhaps not
because they are so basic as because there's too much left to run-time
interpretation.  Fortunately, I think we'll be able to make some types
of authorization operations configurable so that naming attributes
need not be hard-coded but configurable (e.g., group-membership-like
attributes).

That said, I don't yet understand what Sam means by "context" here.

Nico
--

---

From: Gabriel López <[email-masked]>
Date: Wed, 19 Oct 2011 09:40:52 +0200

Hi

> IETF, or some community, where you do want the attributes to be
Both alternatives can be implemented and can work together. The use of
standardized attributes is the most desirable scenario but you can find
also something like eduroam, where institutions manage attributes like
"urn:....:entitlement:student", "urn:...:rol:estudiante",
"urn:...:diritto:studente", etc.

regards, Gabi
>
> --Sam
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

-- 
----------------------------------------------------------------
Gabriel Lpez Milln
Departamento de Ingeniera de la Informacin y las Comunicaciones
University of Murcia
Spain
Tel: +34 868888504
Fax: +34 868884151
email: [email-masked]

---

From: Sam Hartman <[email-masked]>
Date: Wed, 19 Oct 2011 08:34:08 -0400

Cantor,> On 10/18/11 8:17 PM, "Sam Hartman" <[email-masked]> wrote:
    >> completely separate and is unprefixed; the administrator is
    >> assumed to know their own policy.

    Cantor,> That's generally true, but it's still desirable for
    Cantor,> applications sitting on top to be able to distinguish
    Cantor,> between a piece of data from one source vs. another.

    >> So, I'd prefer the context be fixed. I think we need it to be
    >> fixed for GSS-EAP. If the use cases for ECP are going to be
    >> different then we should consider that. However it would be
    >> valuable if you could plug one in case of the other.

    Cantor,> I guess the way I look at it is that as a consumer of the
    Cantor,> GSS naming extensions, I'd be physically ill shipping code
    Cantor,> that hardcoded any names, so I see it all as a config time
    Cantor,> question.

Right and with my IETF hat on I'd be physicall ill shipping a spec that
didn't nail that down. If you leave it to configuration you don't get
interop.

We need to support both models.

So, any hints on a URN you'd like?

---

From: "Cantor, Scott" <[email-masked]>
Date: Wed, 19 Oct 2011 14:43:22 +0000

>So, any hints on a URN you'd like?

I actually prefer urn:oid: because arguments over names are endless and
non-terminating.

As a second choice, maybe urn:ietf:kitten:something?

-- Scott

---

From: Nico Williams <[email-masked]>
Date: Wed, 19 Oct 2011 10:07:14 -0500

> I actually prefer urn:oid: because arguments over names are endless and

We have names because OIDs were too inconvenient...  :)

> As a second choice, maybe urn:ietf:kitten:something?

I don't think we want WG names in there.  Something like
urn:ietf:security:nattr:...?

Nico
--

---

From: "Cantor, Scott" <[email-masked]>
Date: Wed, 19 Oct 2011 15:50:23 +0000

>We have names because OIDs were too inconvenient...  :)

I know, and there's a high degree of overlap between the people who
complain about them and the people who bitch endlessly at whatever name
you pick. I care little for either set.

>urn:ietf:security:nattr:...?

Given that it's explicitly meant as a GSS-API naming extension, maybe just
use gssapi in the name.

-- Scott

---

From: Nico Williams <[email-masked]>
Date: Wed, 19 Oct 2011 10:56:10 -0500

> you pick. I care little for either set.

I am neutral on this.  I'd be just as happy to throw out all the OIDs
and replace them with strings in a new version of the API.  But you're
right about one thing: OIDs represent a psychological barrier to
addition of new constants, which might then encourage people to use
the entities that exist rather than invent new ones with semantics
equal or similar to existing ones.

> Given that it's explicitly meant as a GSS-API naming extension, maybe just

Can such attributes be useful outside the GSS context?  But, sure,
urn:ietf:security:gss:nattr:...

---

From: Sam Hartman <[email-masked]>
Date: Wed, 19 Oct 2011 12:05:17 -0400

OK.
I'll attempt to propose something.

1) We're not going to use an OID  for a lot of reasons including we
don't have an OID arc to use for this and we already had that discussion
as Nico points out.

2) the URNs proposed so far are not consistent with the IETF's
namespace.