David B. Nelson <dnelson@elbrysnetworks.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@ietf.org
https://www.ietf.org/mailman/listinfo/ietf