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

From: "Glen Zorn" <[email-masked]>
Date: Tue, 29 Apr 2008 23:16:18 +0700

[email-masked] <> scribbled on Tuesday, April 29, 2008
12:02 AM:

>> Last but not least, this draft fairly universally violates several
>> of the guidelines given in
>> http://www.ietf.org/internet-drafts/draft-ietf-radext-design-02.txt,
>> in particular those regarding the use of tags to associate different
>> attributes (called "Index" in this document) and the creation of
>> "complex" attributes. 
> 
> The issue of "complex attributes" was extensively discussed on
> the RADEXT WG mailing list,  and the Design Guidelines are
> based on the WG consensus that was derived from the review
> of this document.
> 
> In particular, Section 2.1.3 of the Design Guidelines document
> specifically calls out the distinction between complex
> attributes which are interpreted by RADIUS, as opposed to
> "opaque data" which is treated as a string by RADIUS, and
> interpreted out of band:
> 
> 
>   The only other exception to the recommendation against complex types
>   is for types that can be treated as opaque data by the
> RADIUS server.
>   For example, the EAP-Message attribute, defined in [RFC3579] Section
>   3.1 contains a complex data type that is an EAP packet.  Since these
>   complex types do not need to be parsed by the RADIUS server, the
>   issues arising from policy language limitations do not arise.
>   Similarly, since attributes of these complex types can be configured
>   on the server using a data type of String, dictionary
> limitations are
>   also not encountered.  Section A.1 below includes a series of
>   checklists that may be used to analyze a design for RECOMMENDED and
>   NOT RECOMMENDED behavior in relation to complex types.
> 
>   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. 

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 realize that the RADIUS design guidelines document is just an
>> Internet-Draft, but it is a radext WG document & has been under
>> construction for some period of time.
> 
> The Design Guidelines document text was specifically crafted
> based on this particular draft, based on extensive discussion
> within the RADEXT WG.
> 
>> More important than
>> the standardization status of the document is the question of whether
>> the guidelines make sense;
> 
> The Design Guidelines document has completed RADEXT WG last
> call with only minor comments outstanding.  If you had any
> concerns about whether the document "makes sense" you should
> have raised them long ago -- but you did not.

I wasn't referring to myself: I've reviewed that document several times
and have yet to find anything to complain about ;-).  I do not, however,
pretend to know the opinions of your co-authors or even your own, for
that matter: AFAIK, it's not mandatory for a WG Chair to like all of the
WG documents, just to ensure that they reflect WG consensus.

> 
>> if so, then it may not be such a good idea to so completely ignore
>> them;
> 
> Far from ignoring the Design Guidelines, this document has
> actually been one of the primary motivations for creating them
> -- and the text in Design Guidelines has been specifically
> crafted to deal with this particular case.
> 
>> If not, then maybe radext should rethink this  work item (especially
>> since a co-chair of that WG is also a co-author of  the document
>> under review).
> 
> Given the extensive discussion on the RADEXT WG list relating
> to this document and Design Guidelines, I have personally
> spent quite a bit of time with Hannes, Avi and others working
> on improving the compatibility of this document with the
> Design Guidelines.
> I did not ask to be named as an author -- the other authors
> suggested this to me.

I don't think that I suggested that you had -- in fact I noted the
(perhaps over ;-) enthusiastic appreciation of your efforts by your
co-authors in my first message.

> 
> Given that, I have no particular interest in this document,
> other than ensuring that it does as little violence to the
> RADIUS protocol as possible.
> 
> So if you have particular concerns relating to the handling of
> this document, 

I don't think suggested that, either...

> or can provide specific instances in which this
> document violates "Design Guidelines" (applying the tests in
> Appendix A, for example), please put them on the table.

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.

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?   It doesn't have to because "[i]f the RADIUS
client sends the requested information then the RADIUS server can
process the location-based 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.  So maybe the RADIUS server is making the
decision based just upon the fact that it received a
Location-Information/Location-Data pair in the new Access-Request (along
with the echoed Attributes).  The problem is that the RADIUS server
didn't request just any old location data; it requested a very specific
set of data (in the example later in section 4.7 it is the civic
location of the user).  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.  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".  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.  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-attribute
s-03.txt'.

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

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 29 Apr 2008 11:25:56 -0700

> >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".....
>> 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.
 
I think the key question here is whether a RADIUS server would need to 
explicitly parse these attributes in order to carry out the requirements in
the document.  If so, then the attributes could not be classified as
"opaque", because RADIUS server code would need to change.  
> > 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:
 
The question is whether the RADIUS server makes this 
determination based on the presence/absence of an attribute, or
based on parsing its contents.  If it's the latter, then the data can't
be classified as "opaque". 
> > 1. If the RADIUS client sends the requested information then the> > RADIUS server can process the location-based attributes.
 
For the RADIUS server to determine whether the client sent the 
set of location information that was requested previously 
(as opposed to just whether the client send an attribute that may
or may not correspond to what was requested), it would seem 
that parsing would be required.
> > 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?
 
If the RADIUS server can make the determination purely based on the
presence/absence of the attribute, then it wouldn't need to understand
the contents.  However, if parsing is required (which seems to be implied
by the term "requested information"), then I'd agree that the attribute
is not really "opaque". 
> > 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.> 
If the goal is to determine exactly what kind of information was sent, and
whether the requirements were met (as opposed to just determining if
an attribute was present or not), then I'd agree. 
 
> > Neither the Location-Information nor the Location-Data Attributes seem> > to be used for authentication (authorization != authentication) or> > security. 
Yup.  An exception can't be granted based on that criteria.
 > > 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'.
 
The question here is whether the Index field is actually related to grouping
or not.