>>>>> "Jim" == Jim Schaad <[email protected]> writes:
>> -----Original Message----- From: Sam Hartman
>> [mailto:[email protected]] Sent: Friday, March 16,
>> 2012 10:53 AM To: Jim Schaad Cc: [email protected];
>> [email protected] Subject: Re: Comments on abfab-gss-eap-naming-02
>>
>> >>>>> "Jim" == Jim Schaad <[email protected]> writes:
>>
>>
>> I think it's up to an implementation whether it chooses to let
>> you set
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.
>>
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> 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.
>>
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
Jim> federated
>> context assertions from the IDP unless the RADIUS server is
>> configured to
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?
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
