Re: [abfab] EAP naming attribute document

["Jim Schaad" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Sam Hartman
> Sent: Wednesday, August 17, 2011 5:22 PM
> To: Jim Schaad
> Cc: [e-mail]; 'Sam Hartman'
> Subject: Re: [abfab] EAP naming attribute document
> 
> >>>>> "Jim" == Jim Schaad <[e-mail]> 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.

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.

> 
>     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.

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).

> 
> 
>     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.

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.

> 
> 
>     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.

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.


> 
>     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.

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.

> 
> 
>     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.

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

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