Issue 271: IETF Last Call Comments on RADIUS GEOPRIV Document

[Bernard Aboba <aboba@internaut.com>]

In order to make forward progress on resolving the RADIUS GEOPRIV IETF 
Last Call comments, I am reposting Glen's original review to the RADEXT WG 
list. 

Suggested text changes to resolve these comments are welcome.  

=======================================================================
Issue 271: Review
Submitter name: Glen Zorn
Submitter email address: gzorn@arubanetworks.com
Date first submitted: April 27, 2008
Reference: http://www.ietf.org/mail-archive/web/ietf/current/msg51649.html
Document: LOCATION-09
Comment type:  Technical
Priority: S
Section:  Various
Rationale/Explanation of issue:

In the description of the Operator-Name Attribute (section 3.1), the
discussion of the encoding of a name in the "REALM" namespace is
incomplete, at best. First, there is no discussion of the steps (if
any) to be taken if the toASCII conversion fails in the case of a realm
name containing non-ASCII characters. In any case, however, it is not
possible to encapsulate a maximum-length FQDN in a RADIUS attribute
because the maximum length of a RADIUS Attribute data payload is 253
octets, while the maximum length of an ASCII FQDN is 255 octets.
Furthermore, due to the addition of the ACE prefix(es) as a result of
the toASCII conversion process, the actual length of a converted realm
name may be considerably less than 253 octets. The conventional way to
deal with type of problem in RADIUS would be to split the offending
string up into multiple attributes; however, the formatting of the
Operator-Name attribute into distinct sub-fields would seem to preclude
the use of that technique. I suggest that (in order of preference)
a) the Operator-Name Attribute be split into separate
Operator-Namespace and Operator-Name Attributes with instructions
included on handling too-long FQDNs
b) the attribute be redefined in terms of the new Extended
RADIUS Attributes
(http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attribut
es-03.txt)
or at the least
c) text be added noting the actual restrictions on realm name
length

Section 3.3, paragraph 2 doesn't make a lot of sense to me: suggest
rewriting it in less florid if more precise language. For example,
something like this: "In order to enable the on-demand mid-session
location delivery method, the RADIUS server MUST return an instance of
the Requested-Location-Info Attribute with the 'FUTURE_REQUESTS' flag
set and instances of the Basic-Location-Policy-Rules and
Extended-Location-Policy-Rules Attributes in the Access-Accept message
for the session. Upon receipt of a CoA-Request message containing a
Service-Type Attribute with value "Authorize Only" for the same session,
the NAS MUST include location information and echo the previously
received Basic-Location-Policy-Rules and Extended-Location-Policy-Rules
Attributes in the subsequent Access-Request message."

Section 4.2 says:

Length:

>= 21

String:

This field is at least two octets in length, and the format
is shown below. The data type of this field is string.

Suggestion: change "at least two" to "at least 19". Later in the same
section, it says:

Method (variable):

Describes the way that the location information was
determined. The values are registered with the 'method' Tokens
registry by RFC 4119. The data type of this
field is a string.

Does "registered with the 'method' tokens" mean "along with the token
values in the same registry" or something else? I _think_ that what the
authors are trying to say is "This field MUST contain the value of
exactly one IANA-registered 'method' token [RFC4119]." If so, maybe
they should.

Section 4.2.1 says "The location format is based on the encoding format
defined in Section 3.1 of [RFC4776] whereby the first 3 octets (i.e.,
the code for this DHCP option, the length of the DHCP option, and the
'what' element are not included) are not put into the Location field of
the above-described RADIUS Location-Data Attribute." I don't really
understand: does this mean that 'the location format is identical to
that defined in RFC 4776 with the exception that the first three octets
are omitted'? In any case, RFC 4776 say in the last paragraph of
section 1:

The DHCPv4 long-options mechanism described in RFC 3396 [8] MUST be
used if the civic address option exceeds the maximum DHCPv4 option
size of 255 octets.

My comments on are similar to those on the Operator-Name Attribute
above; this case is a little more complicated, due to the use of the
Index field to associate this attribute with the corresponding
Location-Information attribute (there seems to be an implicit assumption
that these always come in pairs).

Section 4.3 says: "Implementations SHOULD treat this attribute as
undistinguished octets." In context, this statement doesn't make sense
in at least two ways. First, I have no idea how any implementation can
treat an entire attribute as undistinguished octets, since at least the
Type and Length fields have to be distinguished. Maybe the authors mean
that the String field of the attribute should be treated in this way,
but that doesn't seem reasonable, either, because that field is itself
formatted into two distinct fields.

Section 4.4 says "The Basic-Location-Policy-Rules Attribute MAY be sent
in an Access-Request, Access-Accept, an Access-Challenge, an
Access-Reject, a Change-of-Authorization and in an Accounting-Request
message." but RFC 2865 says (section 2, paragraph 7) "If any condition
is not met, the RADIUS server sends an "Access-Reject" response
indicating that this user request is invalid. If desired, the server
MAY include a text message in the Access-Reject which MAY be displayed
by the client to the user. No other Attributes (except Proxy-State) are
permitted in an Access-Reject." This being the case, it seems like
there should be an "Updates: 2865" in the first page header of the
draft.

The Location-Capable (section 4.6) attribute can take only a "True"
value (presumably the lack of client ability would be signified by the
absence of the Location-Capable Attribute in the Access-Request). This
puzzles me a bit: isn't it possible that a NAS might be capable of
discovering (& therefore, communicating) one or a few type of location
data and not others? For example, it seems rather likely that a dial-up
NAS might be capable of conveying its own civic location but not the
geospatial location of the remote node. I guess what I'm asking is if
there isn't a need for a little greater granularity here.

The discussion of the Requested-Location-Info Attribute in section 4.7
is remarkably soft and fluffy, attributing such things as "wants" and
"desires" to servers and clients. To the best of my knowledge, software
does not (yet) display needs, let alone desires. This would just be a
little annoying except that the warm fuzziness spills over into the
actual specification of what are presumably requirements. For example:

If the RADIUS server wants to dynamically decide on a per-request
basis to ask for location information from the RADIUS client then the
following cases need to be differentiated. If the RADIUS client and
the RADIUS server have agreed out-of-band to mandate the transfer of
location information for every network access authentication request
then the processing listed below is not applicable.

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

In the case of #1, "the RADIUS server can process the location-based
attributes". This seems fairly obvious, but just because it _can_
doesn't mean that it _will_; it might not (presumably based upon its
"desires" ;-). Must the server process the location information? If
so, the document should say so. Similarly in case #2, "the RADIUS
server may respond with an Access-Reject message with an Error-Cause
Attribute (including the "Location-Info-Required" value)." If it "may"
then it may also not; just guessing (since there are supposedly only two
cases and the information is stated to be required in order to process
the authorization request) it seems to me that the authors really mean
"MUST" in both cases but that is not clear at all.

o If the RADIUS server would like location information in the
Accounting-Request message but does not require it for computing
an authorization decision then the Access-Accept message MUST
include a Required-Info Attribute. This is typically the case
when location information is used only for billing. The RADIUS
client SHOULD attach location information, if available, to the
Accounting-Request (unless authorization policies dictate
something different).

Once again the server exhibits desire, but this paragraph begs another
question: if the data referred to by the Requested-Location-Info
Attribute is actually required and the Required-Info Attribute signifies
data that is optional, why are they named the way they are?

Change "8.3. New Registry: Location Capable Attribute" to "8.3. New
Registry: Location-Capable Attribute".

Many references are out of date or incorrect.
Given that Bernard is a co-author, it may be a bit excessive to mention
him (thrice!) in the Acknowledgements section _and_ in the Contributors
section as well ;-).

In section A.1, paragraph 1 change "This section discusses the privacy
implication for making location information available to other
entities." to "This section discusses the privacy implications of making
location information available to other entities."

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. 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. More important than
the standardization status of the document is the question of whether
the guidelines make sense; if so, then it may not be such a good idea to
so completely ignore them; 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).

[BA] Can you provide specific instances in which this
document violates "Design Guidelines" (applying the tests in
Appendix A?.

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-attributes-03.txt'.

Additional discussion is available here:
http://www.ietf.org/mail-archive/web/ietf/current/msg51657.html
http://www.ietf.org/mail-archive/web/ietf/current/msg51686.html
http://www.ietf.org/mail-archive/web/ietf/current/msg51691.html

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>