>>>>> "Jim" == Jim Schaad <[email protected]> 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.
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
