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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf