Subject: Re: [Geopriv] Last Call: draft-ietf-geopriv-radius-lo (Carrying Location Objects in RADIUS and Diameter) to Pr

From: "David B. Nelson" <[email-masked]>
Date: Tue, 29 Apr 2008 13:45:21 -0400

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.

_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 5 May 2008 13:45:39 -0700

David B. Nelson <[email-masked]> scribbled on Tuesday, April
29, 2008 10:45 AM:

...

> 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".

>> 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.

>> these fields "need to be delineated in RADIUS" and therefore "the
>> data is not opaque, and it SHOULD be separated into individual RADIUS
>> attributes".
> 
> 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?  

...

---

From: "David B. Nelson" <[email-masked]>
Date: Tue, 6 May 2008 09:48:46 -0400

Glen Zorn writes...

> distinct from RADIUS.

We're talking about EAP messages tunneled in RADIUS Attributes.  That's what
qualifies for the "opaque blob" exception.

> We're talking about RADIUS attributes here, and the document states that
> the RADIUS server bases a decision upon these attributes.

Yes, I tend to agree with you.  The consensus position, as I understand it,
is that these are "semi-opaque blobs" because the contents are derived from
a separate protocol (a DHCP option, I think, but I may be mistaken).

> There isn't anything I can find in the draft that even suggests the
> existence of some "plug-in".

Nor would I expect you to.  That would be one of those infamous
"implementation specific details".

> on-the-wire protocol.

Eh?

> don't really care but 'fuzziness' has no place in standards, IMHO.

The "fuzziness" I was talking about was the applicability of the "opaque
blob" exception in the RADIUS Attribute Design Guidelines. It is claimed to
apply in this case, and I, like you, don't quite buy it.  However, the
consensus position of the GEOPRIV and RADEXT WGs (from WGLC) is that it does
apply.

> practices until they have an RFC number?

No.  I'm simply saying that two dissenting opinions do not a rough consensus
break.  :-)