> -----Original Message----- > From: Sam Hartman [mailto:[email protected]] > Sent: Friday, March 16, 2012 12:17 PM > To: Jim Schaad > Cc: [email protected]; [email protected] > Subject: Re: Comments on abfab-gss-eap-naming-02 > > >>>>> "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. >
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. > >> > 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. That is fine. I was more worried about the opposite case - i.e. that the RADIUS attribute SHOULD be hidden. > > >> > 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.) No I was talking about gss-eap since it would be applicable for both RADIUS attributes and SAML attributes. > > 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? 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 _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
