Subject: [abfab] EAP naming attribute document

From: "Jim Schaad" <[email-masked]>
Date: Wed, 17 Aug 2011 16:37:46 -0700

Ok - let's try this again - only without the big mistake from last time.

1.  Republish the document even if it has no changes  so it can be found on the working group page.

2.  SAML attributes are named by a naming type and a name value, but they may also be thought of as being named by the issuing authority.  In the event a urn such as urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress is used, then the meaning is (hopefully) well understood and common to all authorizes.  However if a string such as "Major" is used, the meaning and set of values may be highly dependent on the issuing authority.

3.  Traveling all the way back to Beijing, I believe it was stated that we would only ever have a single SAML assertion that is transported from the IDP to the service, however it could contain nested statements.  Is this still a working assumption for the group.  Note: I do not believe that this has ever been explicitly stated in any documents.  What happens if AAA transports back two different SAML statements?

4.  For SAML attributes - What happens if there are multiple values for a single attribute.  These could be multiple values within a single SAML assertion (i.e. two different <Attribute> clauses with the same name but with different values such as two different email names (which would be required to be transported as two different attributes). Or they could be given by two different SAML statement issuers, but the items are nested.  In this case the values could be either the same or different, but the issuer name for the attribute would be different.  In this case should they be treated as alternate values for a single attribute or as different attributes which are scoped by the issuer name.

5.  Are we defining a property in the GSS EAP namespace that can contain the set of attributes that the service wants to have returned by the IDP?  This could take the value of the SAML Request to be sent to the IDP.

6.  I don't understand how an independent check could be made on any SAML assertions without pulling out the total SAML assertion, checking it and then pulling the attributes from it.  How could one check the value of a single attribute (per last sentence of section 5.2 para 2 - An implementation MAY  apply local policy checks to this assertion and discard it if it is  unacceptable according to these checks.)

7.  I am not sure what section 5.3 is saying - Is  this just a to be written place holder?

8.  We are establishing a new registry in this document.  What are the rules we are going to define for this.  I assume we want expert review but I don't remember there ever being a discussion.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 17 Aug 2011 20:22:05 -0400

>>>>> "Jim" == Jim Schaad <[email-masked]> writes:

    Jim> 2.  SAML attributes are named by a naming type and a name
    Jim> value, but they may also be thought of as being named by the
    Jim> issuing authority.  In the event a urn such as
    Jim> urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress is used,
    Jim> then the meaning is (hopefully) well understood and common to
    Jim> all authorizes.  However if a string such as "Major" is used,
    Jim> the meaning and set of values may be highly dependent on the
    Jim> issuing authority.

True.
Keep in mind that  the name attribute is in the context  of a name.
In the case of gss-eap, the realm in which the name is interpreted
should be reasonably obvious from the name.
For SAML EC, it may be a bit more tricky, but honestly, if you use a
non-globally-unique name attribute you may run into trouble.

    Jim> 3.  Traveling all the way back to Beijing, I believe it was
    Jim> stated that we would only ever have a single SAML assertion
    Jim> that is transported from the IDP to the service, 

I don't remember that so much as saying that was what we are specifying
now.

    Jim> however it
    Jim> could contain nested statements.  Is this still a working
    Jim> assumption for the group.  Note: I do not believe that this has
    Jim> ever been explicitly stated in any documents.  What happens if
    Jim> AAA transports back two different SAML statements?

I'm confused: I thought an assertion was a kind of statement.
If we have multiple assertions, I would expect that
draft-ietf-gss-eap-naming would not really apply or would only apply to
the core-/main assertion.
I'd expect other assertions would typically have a different context.

    Jim> 4.  For SAML attributes - What happens if there are multiple
    Jim> values for a single attribute.  These could be multiple values
    Jim> within a single SAML assertion (i.e. two different <Attribute>
    Jim> clauses with the same name but with different values such as
    Jim> two different email names (which would be required to be
    Jim> transported as two different attributes). Or they could be
    Jim> given by two different SAML statement issuers, but the items
    Jim> are nested.  In this case the values could be either the same
    Jim> or different, but the issuer name for the attribute would be
    Jim> different.  In this case should they be treated as alternate
    Jim> values for a single attribute or as different attributes which
    Jim> are scoped by the issuer name.

GSS naming extensions does not really support this; I'd say the behavior
should be undefined until GSS has a story for this.

    Jim> 5.  Are we defining a property in the GSS EAP namespace that
    Jim> can contain the set of attributes that the service wants to
    Jim> have returned by the IDP?  This could take the value of the
    Jim> SAML Request to be sent to the IDP.

It's my understanding we are not currently doing that.
I'd prefer to have someone say that they would implement before we spend
energy specifying this.

    Jim> 6.  I don't understand how an independent check could be made
    Jim> on any SAML assertions without pulling out the total SAML
    Jim> assertion, checking it and then pulling the attributes from it.
    Jim> How could one check the value of a single attribute (per last
    Jim> sentence of section 5.2 para 2 - An implementation MAY apply
    Jim> local policy checks to this assertion and discard it if it is
    Jim> unacceptable according to these checks.)

Someone wants to log in as root.
Your local policy doesn't believe they should be authorized to do so.

    Jim> 7.  I am not sure what section 5.3 is saying - Is this just a
    Jim> to be written place holder?

I think it's a TBD.

    Jim> 8.  We are establishing a new registry in this document.  What
    Jim> are the rules we are going to define for this.  I assume we
    Jim> want expert review but I don't remember there ever being a
    Jim> discussion.

Are you talking about the URN registry?
If so, I'd assume ietf consensus or standards action.
It's just a URI registry; you shouldn't need ours unless you're
publishing our documents.
If you are on your own, use your own.

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

---

From: "Cantor, Scott" <[email-masked]>
Date: Thu, 18 Aug 2011 03:08:55 +0000

>I'm confused: I thought an assertion was a kind of statement.

An assertion is (most of the time) a set of zero or more statements by an
issuer about a subject. If they're attribute statements, all the
statements are essentially just the same thing, and the attributes they
contain can be pooled together. The syntax of multiple statements is
notational, but there are no semantics to having 3 attributes in one
statement and 2 in another. You wouldn't generally see it, and if you did,
it doesn't mean anything different than one statement with 5 attributes.

Multiple assertions by one issuer are therefore similarly poolable if
they're referring to the same subject, apart from any distinct conditions
they might have or other content that would limit or influence their
validity.

Multiple assertions by different issuers are of course a wholly different
animal. That means exactly the messy, complex thing you would expect it to
mean.

One of the important things is to determine whether all the assertions, if
there can in fact by more than one, must all refer to the same principal.
And if they do, does that imply that all the Subjects must be identical?
Or is the surrounding protocol providing a guarantee that whatever
identifiers appear in the subjects, even if different, refer to the same
principal.

Some people will argue strongly that unless the Subjects match
identically, it's impossible for a relying party to treat them as
referring to one principal. I don't share that view, I think that's
something that can be defined by the protocol as a whole.

-- Scott

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 17 Aug 2011 23:24:57 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Sam Hartman
> Sent: Wednesday, August 17, 2011 5:22 PM
> To: Jim Schaad
> Cc: [email-masked]; 'Sam Hartman'
> Subject: Re: [abfab] EAP naming attribute document
> 
> In the case of gss-eap, the realm in which the name is interpreted should
be
> reasonably obvious from the name.
> For SAML EC, it may be a bit more tricky, but honestly, if you use a non-
> globally-unique name attribute you may run into trouble.

So your claim is that knowledge of the REALM of the IDP is sufficient to
determine what, if any, interpretation of the name should be.  We should
probably state this in the document.

> If we have multiple assertions, I would expect that
draft-ietf-gss-eap-naming
> would not really apply or would only apply to the core-/main assertion.

My bad - I meant to type  -- What happens if AAA transports back two
different SAML assertions.  I am still getting statement and assertion
confused.

What I am looking at is draft-howlett-radius-saml-attr, it is currently
documented as saying that all of the data bytes of all of the Radius packets
in a AAA message are concatenated together.  This means that it is not
possible for two SAML assertions to be returned (successful) in that the
second one would be appended to the first one and you would basically have
two XML constructs concatenated.  One could either modify that draft or
modify the XML parsing code to deal with two SAML assertions being returned
but that is not presently stated.  Thus I believe that only one (the first)
would be successfully found and parsed under today's specifications.

However (Scott please help me here), in Beijing I was informed that for the
use case that I had it would be possible for the IDP to next a SAML
assertion from a different issuer within its own assertion.  I don't know
the syntax that would be expected to ensue (but I really do want to know).

> should be undefined until GSS has a story for this.

So I would expect that current GSS behavior would be to say randomly return
one of them rather than fail.  An issue to potentially raise on kitten.

> I'd prefer to have someone say that they would implement before we spend

Plasma is probably going to want this as soon as we start implementations.
The current concept is that the service is going to ask the IdP for the set
of attributes that it needs to evaluate the set of policies applied to a
message.  The expectation is that one would not wish to send all attributes
that might be needed to evaluate random policies in generation.
Additionally it is expected that SAML assertion issues might map statements
from their space onto the service providers space.  Thus this is something
that should become important to me quickly.

> Your local policy doesn't believe they should be authorized to do so.

Ok - I misunderstood this.  My assumption was not that this statement was
dealing with how local policy is applied to the attributes in the course of
making a local policy decision about a request from the client.  But was
about the question of if the local policy server thought that the IdP was
competent to make the attribute statement and if there was sufficient
checking on the SAML assertion that it could be used.

> It's just a URI registry; you shouldn't need ours unless you're publishing
our
> documents.

Yes I was looking at the URN registry established by this document.  So I
would be happy with IETF consensus as an addition rule.

Jim

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

---

From: Josh Howlett <[email-masked]>
Date: Thu, 18 Aug 2011 08:44:45 +0000

>something that can be defined by the protocol as a whole.

+1. An identifier is semantically a special purpose attribute statement.
It's reasonable (and often desirable) for different issuers to know the
same subject by different identifiers. That may not be convenient for
relying parties where identifier equivalence is clearly convenient; but if
it causes problems they can fix it at the business level.

Josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG

---

From: Josh Howlett <[email-masked]>
Date: Thu, 18 Aug 2011 09:24:45 +0000

>different SAML assertions.  I am still getting statement and assertion

A statement is basically a strongly typed value. An assertion is an
envelope for >0 statements that provides the rest of the context; who does
those statements describe, who is making the claim, how long is this claim
valid for, etc.

>would be successfully found and parsed under today's specifications.

draft-howlett-radius-saml-attr transports SAML protocol messages. A single
protocol message can certainly contain >1 assertion.

>the syntax that would be expected to ensue (but I really do want to know).

It's certainly possible to do that using the <Advice> element (see 2.6.1
of SAMLCore). I don't know whether it makes sense for your use case.

>that might be needed to evaluate random policies in generation.

You can trivially specify the required attributes in an <AttributeQuery>
message issued by the RP to the IdP, using draft-howlett-radius-saml-attr.

(The Moonshot GSS EAP implementation doesn't currently support an
application to signal its attribute requirements, mainly because as Sam
implies (I think) the GSS API doesn't currently support this; but a local
AAA proxy that knew the application's requirement could inject this. I
believe it would be better for the application to do this, though)

>that should become important to me quickly.

I think that's an implementation issue.

(FYI, the Moonshot implementation supports this; one of the benefits of
using Scott's SP)

Josh.

---

From: Luke Howard <[email-masked]>
Date: Thu, 18 Aug 2011 10:07:08 +0000

> one of them rather than fail.  An issue to potentially raise on kitten.

GSS naming extensions does support multiple valued attributes.

-- Luke

---

From: Sam Hartman <[email-masked]>
Date: Thu, 18 Aug 2011 08:49:35 -0400

>>>>> "Luke" == Luke Howard <[email-masked]> writes:

    >>> GSS naming extensions does not really support this; I'd say the
    >>> behavior should be undefined until GSS has a story for this.
    >> 
    >> So I would expect that current GSS behavior would be to say
    >> randomly return one of them rather than fail.  An issue to
    >> potentially raise on kitten.

    Luke> GSS naming extensions does support multiple valued attributes.

I don't think it's reasonable to use that support if different values
come from different issuers.

---

From: Luke Howard <[email-masked]>
Date: Thu, 18 Aug 2011 13:02:31 +0000

Right you are.

--
Luke Howard / [email-masked]
www.padl.com / www.lukehoward.com

---

From: Leif Johansson <[email-masked]>
Date: Thu, 18 Aug 2011 15:18:43 +0200

>> come from different issuers.

+1 that actually sounds like something that should go into a security
considerations text somewhere.

	Cheers Leif

---

From: Sam Hartman <[email-masked]>
Date: Thu, 18 Aug 2011 13:37:39 -0400

OK.

1) I think we should say somewhere that you shouldn't send back multiple
assertions unless it's appropriate to just combine them together.
I.E. assertions from the same IDP about the same subject are probably
OK, at least until we figure out what we want to do in those cases.

2) It sounds like we should start doing design work on the case of
attributes coming from multiple sources at least enough to support your
use cases.  My personal suspicion is that I want a bit more AAA framing
than we do for the single issuer case.  I don't have a problem doing
that standardization now. However I want to make sure that is not
mandatory-to-implement and that a RP can easily tell if a situation
it does not implement is happening.

3) I agree we should add a statement about non-unique name attributes to
the draft.

4) I agree the comments about policy should be clarified.

5) I agree the IANA section needs all the standard things including a
registration process.

--Sam

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 18 Aug 2011 16:05:26 -0700

> From: Sam Hartman [mailto:[email-masked]]
> Sent: Thursday, August 18, 2011 10:38 AM
> To: Jim Schaad
> I.E. assertions from the same IDP about the same subject are probably OK,
at
> least until we figure out what we want to do in those cases.
> 
attributes
> coming from multiple sources at least enough to support your use cases.
My
> personal suspicion is that I want a bit more AAA framing than we do for
the
> single issuer case.  I don't have a problem doing that standardization
now.
> However I want to make sure that is not mandatory-to-implement and that a
> RP can easily tell if a situation it does not implement is happening.

As long as they come back, I don't think that I need any more support (other
than query).  My expectation is that we are just going to extract the entire
SAML assertion intact and process it w/o the aid of GSS.

Jim

---

From: Sam Hartman <[email-masked]>
Date: Thu, 18 Aug 2011 22:58:43 -0400

OK. If the advice element is good enough for you then I agree nothing
needs doing.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 18 Aug 2011 23:00:21 -0400

Also, Josh implied that GSS doesn't have a way to ask the IDP for
attributes.

I actually think we can set an attribute on the acceptor credential's
name to indicate what we want to query the IDP for.

---

From: Josh Howlett <[email-masked]>
Date: Fri, 19 Aug 2011 15:44:46 +0000

>OK, at least until we figure out what we want to do in those cases.

I think we need to be circumspect how we choose to constrain the protocol.
If we need it for technical interoperability, fine. Otherwise I'd prefer
to leave anything to do with the semantics of the messages to the
application to worry about. I don¹t think its the business of the
transport or framing to dictate that.

>it does not implement is happening.

I agree. However I think we already partially support the case of
assertions from multiple issuers within a single transaction, where a AAA
server has aggregated assertions from multiple IdPs and is sending them
along to the AAA client. That's just a bunch of assertions in a single
SAML response message over the AAA response. We don't support the case
where the client needs to specify to the AAA server which statements it
needs from which IdPs.

However, we also need to consider the case where the AAA client is
aggregating assertions from multiple AAA servers. In the general case,
this is my preferred aggregation strategy. We've touched on this in the
past, but not really taken it anywhere.

Josh.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 19 Aug 2011 12:25:22 -0400

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

    >> 1) I think we should say somewhere that you shouldn't send back
    >> multiple assertions unless it's appropriate to just combine them
    >> together.  I.E. assertions from the same IDP about the same
    >> subject are probably OK, at least until we figure out what we
    >> want to do in those cases.

    Josh> I think we need to be circumspect how we choose to constrain
    Josh> the protocol.  If we need it for technical interoperability,
    Josh> fine. Otherwise I'd prefer to leave anything to do with the
    Josh> semantics of the messages to the application to worry about. I
    Josh> don¹t think its the business of the transport or framing to
    Josh> dictate that.

In principle I'd agree with you.  However in practice I think it is very
difficult for the application to understand these semantics in an
interoperable manner (something we very much need applications to do)
unless the framing explains that to the application.  I have no problem
introducing a semantics code or purpose code or something so we can
define new semantics in the future and reuse the framing.  However the
semantics fairly clearly need to be nailed down well enough to
understand whether we can use the naming context implied in
draft-ietf-gss-eap-naming.
That context today only deals with attributes and SAML messages that are
about the subject of the authentication vouched for by an IDP
sufficiently tied into the authentication process that the RP need not
care about the distinction.

If you throw in an assertion about someone else, or from someone else,
we don't know how an application should interpret it; we won't be able
to write interoperable applications in that case. Also, even if you
throw in an unrelated SAML message, we won't know how to process it.
Even if in some cases such information could be distinguished with
careful application of metadata, it's far easier for the sender to
explain what the sender is doing than for the recipient to try and
interoperably infer it.

--Sam

---

From: Josh Howlett <[email-masked]>
Date: Fri, 19 Aug 2011 16:40:11 +0000

I think that's a perfectly compelling argument from technical
interoperability.

Josh.

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 19 Aug 2011 14:48:44 -0700

> From: Josh Howlett [mailto:[email-masked]]
> Sent: Friday, August 19, 2011 8:45 AM
> To: Sam Hartman; Jim Schaad
together.
> If we need it for technical interoperability, fine. Otherwise I'd prefer
to leave
> anything to do with the semantics of the messages to the application to
> worry about. I don¹t think its the business of the transport or framing to
> dictate that.

I tend to agree with Sam here.  Given that different subject values could
refer to the same subject, there is no way for the service to know which
SAML statements would be for the client and which are extraneous without
such a constraint being stated.

> >mandatory-to-implement and that a RP can easily tell if a situation it
> >does not implement is happening.
> 
assertions
> from multiple issuers within a single transaction, where a AAA server has
> aggregated assertions from multiple IdPs and is sending them along to the
> AAA client. That's just a bunch of assertions in a single SAML response
> message over the AAA response. We don't support the case where the client
> needs to specify to the AAA server which statements it needs from which
> IdPs.
> 
this is
> my preferred aggregation strategy. We've touched on this in the past, but
> not really taken it anywhere.

I don't understand your usage case here.  I can understand the case of the
AAA server at the IdP aggregating multiple statements together based on a
SAML query that came with the EAP message, however having the AAA client
doing this  functionality I don't understand.   How it would take place?
Are you suggesting that the server ought to be able to send multiple SAML
queries through the AAA client to get multiple statements?  Or are you
saying that GSS-EAP should somehow do this?

Jim

> 
> Josh.
> 
> 
> 
> JANET(UK) is a trading name of The JNT Association, a company limited by
> guarantee which is registered in England under No. 2881024 and whose
> Registered Office is at Lumen House, Library Avenue, Harwell Oxford,
Didcot,
> Oxfordshire. OX11 0SG

---

From: Josh Howlett <[email-masked]>
Date: Sat, 20 Aug 2011 13:16:35 +0000

>such a constraint being stated.

I don't think we disagree, we're just saying slightly different things.

I think Sam was saying that - as a baseline - we should constrain the
protocol so that the service can assume that assertions with different
claimed subjects refer to the same principal (note that that doesn't
require, at the payload level, that two or more assertions must have the
same subject value). I was saying that service should be free to ignore
the subject value claimed by the system, and infer the use of another
value on the basis of other characteristics of the protocol or payload
context, for its own purposes (whatever they might be).

The original intent was to use SAML's model, where scenario-specific
constraints are defined separately from the transport and framing
"Binding" specifications within "Profile" specifications. While this
provides a separation of concerns and other good stuff, it's also a lot of
work and I don't think we've had a motivating use-case until now. It could
be that we need to look at this again so that we can, as Sam says, "define
new semantics in the future and reuse the framing".

>queries through the AAA client to get multiple statements?

Yes; there was some mail about the use of the Authorize-Only facility
previously:

http://www.ietf.org/mail-archive/web/abfab/current/msg00366.html

I don't think we resolved whether this was a reasonable use of this
facility in that the Authorize-Only request isn't going to the original
authentication server, but another AAA server. I've been meaning to ask
Alan to seek his opinion...

Josh.