Glen Zorn writes... > 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". I've offered similar comments early on in the review of this document. The authors explained to me that the attributes used in this document are based upon the PDUs of other protocols. Unfortunately, the PDUs of those other protocols are not suitable for direct encapsulation as "opaque" RADIUS Attributes. Instead, they required slight modifications in order to be suitable for the current purpose. For that reason, the document under review outlines the format and layout of the attributes as if they were not opaque. In fact, they are only partially opaque. Strictly speaking, for a RADIUS Attribute to be "opaque" in the way that the RADIUS Design Guidelines anticipates, it should be merely an encapsulation of a data element defined in another (typically non-RADIUS) document. What we have here is as example of re-use (with minor adaptation) rather than simple encapsulation. I think this fails to meet the spirit, if not the letter, of the RADIUS Design Guidelines. However, after substantial discussion on this point, it became clear that there were no better alternatives that met the needs of the authors of this document. This may be as good as its going to get. > OK. As you noted above, the Design Guidelines say > > If the RADIUS Server simply passes the contents of an attribute to > some non-RADIUS portion of the network, then the data is opaque, and > SHOULD be defined to be of type String. A concrete way of judging > this requirement is whether or not the attribute definition in the > RADIUS document contains delineated fields for sub-parts of the data. > If those fields need to be delineated in RADIUS, then the data is not > opaque, and it SHOULD be separated into individual RADIUS attributes. 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. > But section 4.7 of the draft under review says > > 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: > > 1. If the RADIUS client sends the requested information then the > RADIUS server can process the location-based attributes. > > 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? This is where the delineation gets fuzzy. We presume that any information carried in RADIUS messages is related to authentication or authorization. Yes, RADIUS can be (ab)used as a generic transport or all sorts of unrelated information, but that isn't the case in this instance. The use of a "back-end" or "plug-in" module to parse opaque data in a RADIUS Attribute and provide the results back to the RADIUS Server for use in the authentication and authorization decision making process is well established. Certainly that's what the EAP server does for RADIUS EAP-Message Attributes. > Of course, "process" can mean many things and if these attributes are > opaque then "process" might mean just writing the data to a file or > forwarding it over some unspecified interface to another entity. It could mean that. > 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. Something has to do this work. It could be the RADIUS Server, or it could be the Location Policy Server, acting as a back-end service to the RADIUS Server. This is all a matter of implementation, and has nothing to do with the on-the-wire protocol. > Remember that this check for the requested information takes place > before the RADIUS server processes the data; this suggests to me that > these fields "need to be delineated in RADIUS" and therefore > "the data is not opaque, and it SHOULD be separated into individual > RADIUS attributes". I think that is a very reasonable design choice, and one that would be in compliance with the RADIUS Design Guidelines. However, we've had that discussion and the consensus seemed to be that it was too much of a change, too late in the development cycle for this document. > Further, section A.2.2 of the Design Guidelines > asks the (how I wish it was a musical ;-) question: > > Does the attribute define a complex data type for purposes other than > authentication or security? If so, this data type SHOULD be replaced > with simpler types, as discussed above in Section A.2.1. > > Neither the Location-Information nor the Location-Data Attributes seem > to be used for authentication (authorization != authentication) or > security. Yes, but I believe that this section of text was arrived at after the document under review had completed its WGLC. There is an issue of timing here. If the RADIUS Design Guidelines document had matured more quickly, it may have had a greater impact on the RADIUS Location Attributes document. I had argued along similar lines, but there was resistance to change late on in the development cycle. > Section A.1.3 of the same document says (WRT Attributes > encapsulating complex data types): > > Does the attribute encapsulate an existing data structure defined > outside of the RADIUS specifications? Can the attribute be treated > as opaque data by RADIUS servers (including proxies?) If both > questions can be answered affirmatively, a complex structure MAY be > used in a RADIUS specification. > > The specification of the attribute SHOULD define the encapsulating > attribute to be of type String. The specification SHOULD refer to an > external document defining the structure. The specification SHOULD > NOT define or describe the structure[...] > > However, section 4.2 of draft-ietf-geopriv-radius-lo describes the > structure of the Location-Information Attribute in detail; the question > of opacity was dealt with above. > > 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'. Yes, if this work were to be started today, one would expect a much greater level of compliance with the RADIUS Design Guidelines document. _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf