> -----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 them. > For most of these I would not expect setting to work. > 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. > > 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. 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. > > 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? There is a local policy check on assertions - It would be on attributes and name ids and might be on the entire SAML assertion. > > 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. 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 _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
