David B. Nelson <dnelson(_at_)elbrysnetworks(_dot_)com> scribbled on Tuesday,
April
29, 2008 10:45 AM:
...
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.
Doesn't seem to be particularly fuzzy to me...
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.
There's just one big difference: EAP is, in fact, a separate protocol,
distinct from RADIUS. We're talking about RADIUS attributes here, and
the document states that the RADIUS server bases a decision upon these
attributes. There isn't anything I can find in the draft that even
suggests the existence of some "plug-in".
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,
No, the document states that it is 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.
Very little about the operation of a RADIUS server has to do with the
on-the-wire protocol. I could write a RADIUS server that accepted
requests & simple returned Access-Accept message with exactly the same
attributes to every request but that would be a very poor RADIUS server.
This "all a matter of implementation" stuff is just a cop-out: this
document needs to clearly specify all the entities involved, however
skeletal that specification may be: if the RADIUS server gets the
location information from another server which subsequently validates
the response, that's fine. If the RADIUS server does it, that's fine; I
don't really care but 'fuzziness' has no place in standards, IMHO.
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.
As I understand the development cycle of an Internet-Draft, there's no
such thing as 'too late to make a change'. The following text appears
in every single I-D published: "Internet-Drafts are draft documents
valid for a maximum of six months and may be updated, replaced, or
obsoleted by other documents at any time." Seems pretty clear to me.
I'm sure that someone will mention at this point that 3GPP87 or some
such has already implemented this draft; fortunately, this is pretty
much taken care of by the next sentence (that also appears in every
single I-D): "It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
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.
So are you saying that good design practices aren't good design
practices until they have an RFC number?
...
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf