|
> >I'm quite aware of that & if, in fact, the attributes were opaque > data that passage would certainly cover it. However, it doesn't > appear that either the Location-Information nor the Location-Data > Attribute is actually "opaque"..... > > Strictly speaking, since the attribute contents are framed by field > delimiters defined only in the attribute definition, and not in another > protocol document, these attributes don't meet the definition of "opaque" as > currently used in the RADIUS Design Guidelines. I think the key question here is whether a RADIUS server would need to explicitly parse these attributes in order to carry out the requirements in the document. If so, then the attributes could not be classified as "opaque", because RADIUS server code would need to change. > > o If the RADIUS server requires location information for computing > > the authorization decision and the RADIUS client does not provide > > it with the Access-Request message then the Requested-Location- > > Info Attribute is attached to the Access-Challenge with a hint > > about what is required. Two cases can be differentiated: The question is whether the RADIUS server makes this determination based on the presence/absence of an attribute, or based on parsing its contents. If it's the latter, then the data can't be classified as "opaque". > > 1. If the RADIUS client sends the requested information then the > > RADIUS server can process the location-based attributes. For the RADIUS server to determine whether the client sent the set of location information that was requested previously (as opposed to just whether the client send an attribute that may or may not correspond to what was requested), it would seem that parsing would be required. > > 2. If the RADIUS server does not receive the requested > > information in response to the Access-Challenge (including the > > Requested-Location-Info Attribute) then the RADIUS server may > > respond with an Access-Reject message with an Error-Cause > > Attribute (including the "Location-Info-Required" value). > > > > The RADIUS server "requires location information for computing the > > authorization decision". How can it make a decision based upon data > > that it cannot understand? If the RADIUS server can make the determination purely based on the presence/absence of the attribute, then it wouldn't need to understand the contents. However, if parsing is required (which seems to be implied by the term "requested information"), then I'd agree that the attribute is not really "opaque". > > AFAICT, the only way that the RADIUS server can tell if it has > > actually received the information it requested is to examine the > > Code and Entity sub-fields of the returned Location-Information > > Attribute and check that there is an associated instance of the > > Location-Data Attribute by matching the Index fields of the Attributes. > If the goal is to determine exactly what kind of information was sent, and whether the requirements were met (as opposed to just determining if an attribute was present or not), then I'd agree. > > Neither the Location-Information nor the Location-Data Attributes seem > > to be used for authentication (authorization != authentication) or > > security. Yup. An exception can't be granted based on that criteria. > > WRT the Index fields of the Location-Information and Location-Data > > Attributes, the fact that they are both mandatory and large avoids many > > of the drawbacks mentioned WRT tags in the Design Guidelines document, > > nevertheless that document does state 'new attributes SHOULD use the > > grouping method described in http://www.ietf.org/internet-drafts/draft- > > ietf-radext-extended-attributes-03.txt'. The question here is whether the Index field is actually related to grouping or not. |