Subject: [abfab] Comments on abfab-gss-eap-naming-02

From: "Jim Schaad" <[email-masked]>
Date: Fri, 16 Mar 2012 10:33:18 -0700

Sam & Josh,

This document looks good, only a couple of issues most of which are probably
not too contentious.  In terms of tone, I am making the assumption that
there is nothing in the naming that prevents a set as well as a get for many
of the properties.  I am not sure that it makes any sense to do a set for
SAML Attributes and maybe Name Identifiers, just the entire SAML statement.
That could potentially be done via the RADIUS attribute and just say that
all of the fed-saml-* names are read-only names.  I don't know if this is a
GSS-API concept or not.

Jim

Major:

1.  In section 5 - I believe the following text should be added to the last
paragraph.  "If more than one attribute for the name exists in the packet, a
multi-valued value is returned."

2. In section 5 - What text do we need to put in here about the temporal
nature of the values?  I assume, but don't know, that all of the values
would be wiped out and a new set of values would be populated when, and if,
a new RADIUS response is received.  An alternative would be to state that
only some values are over-written - either a specific set or those with new
values.  I do not believe that we generally want to always just append
values together.  This would lead to possibly n State attribute values, one
for every RADIUS message pair exchanged.

3. In section 5 - Is there a need for the Code of the last packet to be
retrievable from the GSS-API interface?  This is not currently doable. 

4.  In section 5/6.1 - There is a restriction on getting the SAML assertion
via the fed-saml-assertion name.  Does the same restriction exist if the
value is retrieved via the radius-attr name?

5. In section 6 - Is there a need to distinguish between the an empty
AttributeValue and a Nil AttributeValue.  There is text in 2.7.3.1 of
SAML-CORE-2.0 that does so, but it is not reflected in section 6.2.
Minor:

1.  In section 4 para #5 - I think that s/MUST not/MUST NOT/  - however -
how would that GSS-API code be able to possibly enforce the requirement?

---

From: Sam Hartman <[email-masked]>
Date: Fri, 16 Mar 2012 13:53:24 -0400

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

I think it's up to an implementation whether it chooses to let you set
them.
For most of these I would not expect setting to work.
What affect would you expect setting the RADIUS name to have?

    Jim> Major:

    Jim> 1.  In section 5 - I believe the following text should be added
    Jim> to the last paragraph.  "If more than one attribute for the
    Jim> name exists in the packet, a multi-valued value is returned."

Agreed.

    Jim> 2. In section 5 - What text do we need to put in here about the
    Jim> temporal nature of the values?  I assume, but don't know, that
    Jim> all of the values would be wiped out and a new set of values
    Jim> would be populated when, and if, a new RADIUS response is
    Jim> received.  An alternative would be to state that only some
    Jim> values are over-written - either a specific set or those with
    Jim> new values.  I do not believe that we generally want to always
    Jim> just append values together.  This would lead to possibly n
    Jim> State attribute values, one for every RADIUS message pair
    Jim> exchanged.

OK. So with regard to SAML things I think the text for this belongs in
draft-ietf-abfab-aaa-saml.
For the RADIUS attributes, I think the answer belongs in this draft and
should be that only attributes in an access-accept are expected to be in
the name.

    Jim> 3. In section 5 - Is there a need for the Code of the last
    Jim> packet to be retrievable from the GSS-API interface?  This is
    Jim> not currently doable.

What do you mean code?
access-accept?
Again, my assumption was that you'd really only look at the initiator
name after gss_accept_sec_context returned success.

    Jim> 4.  In section 5/6.1 - There is a restriction on getting the
    Jim> SAML assertion via the fed-saml-assertion name.  Does the same
    Jim> restriction exist if the value is retrieved via the radius-attr
    Jim> name?

What restriction are you talking about?

    Jim> 5. In section 6 - Is there a need to distinguish between the an
    Jim> empty AttributeValue and a Nil AttributeValue.  There is text
    Jim> in 2.7.3.1 of SAML-CORE-2.0 that does so, but it is not
    Jim> reflected in section 6.2.  Minor:

Scott?

    Jim> 1.  In section 4 para #5 - I think that s/MUST not/MUST NOT/ -
    Jim> however - how would that GSS-API code be able to possibly
    Jim> enforce the requirement?

Well, the reason to include the normative language here is so
applications know what they can assume.
However, I think the same restriction needs to be repeated in
draft-ietf-abfab-aaa-saml about putting  SAML messages in those specific
RADIUS attributes.
I.E. new attributes will be required for a new context.

In terms of how you implement it, things like Moonshot's freeradius SAML
integration should only use the attributes defined in aaa-saml for
federated context assertions from the IDP unless the RADIUS server is
configured to re-assert/vouch for these attributes.

---

From: "Cantor, Scott" <[email-masked]>
Date: Fri, 16 Mar 2012 18:17:31 +0000

>    Jim> reflected in section 6.2.  Minor:

The current text in 6.2 talks about whether the value is "simple" AND "is
a text node or nodes". I suspect the simplest way to address this is to
tweak the text to say:

"If the value is not simple or is empty, then..."

That will result in the serialization just capturing the element, and
since I don't know of any use cases for "nil" anyway, that avoids any
extra work to handle that case.

-- Scott

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 16 Mar 2012 11:27:39 -0700

> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]]
> Sent: Friday, March 16, 2012 10:53 AM
> To: Jim Schaad
> Cc: [email-masked]; [email-masked]
> Subject: Re: Comments on abfab-gss-eap-naming-02
> 
them.
> What affect would you expect setting the RADIUS name to have?

Probably nothing good.  Your right which elements one can set need to be
setup on a case by case basis.  The problem is that one kind of needs a
blanket statement for every RADIUS attribute that the code does not know
about.

> OK. So with regard to SAML things I think the text for this belongs in
draft-
> ietf-abfab-aaa-saml.
should
> be that only attributes in an access-accept are expected to be in the
name.

That would be reasonable (for SAML), but you don't have any reference in
that direction or (I think) back in this direction.

Saying that you only have access to the attributes in the access-accept
message partly solves this question.  It depends on if you think that
secondary conversations can occur after the EAP wrapper message.  For
example, if the RP wanted to send an updated SAML request, would you expect
that it goes via the GSS-API or should a direct AAA interface be used.

I think that one might also set some RAIDUS attributes before the message is
sent out to the AAA side in order to control specific things.  They might be
vender specific.  A SAML AuthnRequest might be one.  Also I don't know how
one would affect the AAA logic selection rules but that might be a third
area that could be treated in this manner.

> Again, my assumption was that you'd really only look at the initiator name
> after gss_accept_sec_context returned success.
> 

There is a local policy check on assertions - It would be on attributes and
name ids and might be on the entire SAML assertion.

> Well, the reason to include the normative language here is so applications
> know what they can assume.
> However, I think the same restriction needs to be repeated in draft-ietf-
> abfab-aaa-saml about putting  SAML messages in those specific RADIUS
> attributes.
federated
> context assertions from the IDP unless the RADIUS server is configured to
re-
> assert/vouch for these attributes.

I would feel more comfortable if this statement as a protocol restriction
were placed in the main document then.  To say that the names must not be
used for attributes issued by a party other than on closely associated with
the source of credentials would appear to make it something that the GSS-API
code on my side should be able to enforce.  I do not believe that it has any
ability to do anything but assume that this was done by the IdP/AAA server
side and assign the names willy-nilly.  You description above would support
that assertion.

jim

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 16 Mar 2012 11:37:52 -0700

> From: Cantor, Scott [mailto:[email-masked]]
> Sent: Friday, March 16, 2012 11:18 AM
> To: Sam Hartman; Jim Schaad
> Cc: [email-masked]
> Subject: Re: [abfab] Comments on abfab-gss-eap-naming-02
> 
a
> text node or nodes". I suspect the simplest way to address this is to
tweak
> the text to say:
since I
> don't know of any use cases for "nil" anyway, that avoids any extra work
to
> handle that case.

This sounds very reasonable to me.

Jim

---

From: Sam Hartman <[email-masked]>
Date: Fri, 16 Mar 2012 15:16:31 -0400

>> -----Original Message----- From: Sam Hartman
    >> [mailto:[email-masked]] Sent: Friday, March 16,
    >> 2012 10:53 AM To: Jim Schaad Cc: [email-masked];
    >> [email-masked] Subject: Re: Comments on abfab-gss-eap-naming-02
    >> 
    Jim> them.
    >> For most of these I would not expect setting to work.  What
    >> affect would you expect setting the RADIUS name to have?

    Jim> Probably nothing good.  Your right which elements one can set
    Jim> need to be setup on a case by case basis.  The problem is that
    Jim> one kind of needs a blanket statement for every RADIUS
    Jim> attribute that the code does not know about.

Well, no, I mean even more basic than that.
You set a RADIUs attribute.
Are you expecting the code to do something with that like send it to the
RADIUS server?

I'd expect that it would go via the GSS-API.
I'd prefer to leave behavior regarding that undefined in this document
because we don't have enough experience with it to specify behavior
today.

    >> 
    >> What do you mean code?  access-accept?  Again, my assumption was
    >> that you'd really only look at the initiator name after
    >> gss_accept_sec_context returned success.
    >> 
    >> What restriction are you talking about?

    Jim> There is a local policy check on assertions - It would be on
    Jim> attributes and name ids and might be on the entire SAML
    Jim> assertion.

I'd assume the RADIUS attribute would still be present even if this
check failed.
However I'd prefer not to mandate that here.

    >> applications know what they can assume.  However, I think the
    >> same restriction needs to be repeated in draft-ietf-
    >> abfab-aaa-saml about putting SAML messages in those specific
    >> RADIUS attributes.  I.E. new attributes will be required for a
    >> new context.
    >> 
    >> In terms of how you implement it, things like Moonshot's
    >> freeradius SAML integration should only use the attributes
    >> defined in aaa-saml for
    Jim> federated
    >> context assertions from the IDP unless the RADIUS server is
    Jim> re-
    >> assert/vouch for these attributes.

    Jim> I would feel more comfortable if this statement as a protocol
    Jim> restriction were placed in the main document then.  To say that
    Jim> the names must not be used for attributes issued by a party
    Jim> other than on closely associated with the source of credentials
    Jim> would appear to make it something that the GSS-API code on my
    Jim> side should be able to enforce.  I do not believe that it has
    Jim> any ability to do anything but assume that this was done by the
    Jim> IdP/AAA server side and assign the names willy-nilly.  You
    Jim> description above would support that assertion.

So, I think if we add text to aaa-saml  about the attribute use  then
this text  makes sense.
(I assume by main document you're talking about aaa-saml not gss-eap.)

I'd like to keep the text here as well as in aaa-saml because:

1) I think that a saml-ec implementation is in a position to enforce
this in GSS-API

2) I think that this restriction is important for future GSS specs
considering whether these attributes are appropriate

3) If we get right text into aaa-saml it's easy for a GSS EAP
implementation to enforce this by only mapping the right RADIUS
attributes.

Thoughts?

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 16 Mar 2012 12:39:43 -0700

> Sent: Friday, March 16, 2012 12:17 PM
> To: Jim Schaad
> because we don't have enough experience with it to specify behavior today.
> 

That is fine, I was just looking at various things.  I am happy with
allowing the precise behavior to slide at the moment.  However I think that
if we ever expect to have multiple of something over time that behavior
should at least be said as unspecified at this time.

> I'd assume the RADIUS attribute would still be present even if this check
> failed.

That is fine.  I was more worried about the opposite case - i.e. that the
RADIUS attribute SHOULD be hidden. 

> So, I think if we add text to aaa-saml  about the attribute use  then this
text
> makes sense.

No I was talking about gss-eap since it would be applicable for both RADIUS
attributes and SAML attributes.

> 1) I think that a saml-ec implementation is in a position to enforce this
in GSS-
> API
considering
> whether these attributes are appropriate
> 
implementation to
> enforce this by only mapping the right RADIUS attributes.
> 
> Thoughts?

Other than I think that would should state the same thing in GSS-EAP if it
is not already there, I would agree that this is fine.

Jim