Subject: [AAA-DOCTORS] FW: Evaluation: draft-ietf-geopriv-radius-lo-23.txt to Proposed Standard

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 14 Apr 2009 17:39:49 +0200

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
IESG Secretary
Sent: Tuesday, April 14, 2009 6:26 PM
To: Internet Engineering Steering Group
Subject: Evaluation: draft-ietf-geopriv-radius-lo-23.txt to Proposed
Standard 

--------

Evaluation for draft-ietf-geopriv-radius-lo-23.txt can be found at
https://datatracker.ietf.org/cgi-bin/idtracker.cgi?command=view_id&dTag=
12340&rfc_flag=0 

Last Call to expire on: 2009-04-07

        Please return the full line with your position.

                      Yes  No-Objection  Discuss  Abstain
Jari Arkko           [ X ]     [   ]     [   ]     [   ]
Ron Bonica           [   ]     [   ]     [   ]     [   ]
Ross Callon          [   ]     [ X ]     [   ]     [   ]
Ralph Droms          [   ]     [   ]     [   ]     [   ]
Lisa Dusseault       [   ]     [   ]     [   ]     [   ]
Lars Eggert          [   ]     [   ]     [ X ]     [   ]
Pasi Eronen          [   ]     [   ]     [   ]     [   ]
Adrian Farrel        [   ]     [   ]     [   ]     [   ]
Russ Housley         [   ]     [ X ]     [ . ]     [   ]
Cullen Jennings      [ X ]     [   ]     [   ]     [   ]
Alexey Melnikov      [   ]     [   ]     [   ]     [   ]
Tim Polk             [   ]     [ X ]     [ . ]     [   ]
Dan Romascanu        [   ]     [ X ]     [ . ]     [   ]
Robert Sparks        [   ]     [   ]     [   ]     [   ]
Magnus Westerlund    [   ]     [ X ]     [   ]     [   ]

"Yes" or "No-Objection" positions from 2/3 of non-recused ADs, with no
"Discuss" positions, are needed for approval.

DISCUSSES AND COMMENTS:
======================
Jari Arkko:

Comment [2008-07-17]:
I have reviewed the specification and the last call discussion, and I
believe the document is ready to be approved. I think the authors have
struck the right balance between keeping the location information opaque
vs. allowing servers to make authorization decisions IF they need to do
it.

A few minor comments. Section 4.7:

   The numerical value representing FUTURE_REQUESTS indicates that
   the RADIUS client MUST provide future Access-Requests with the
   same information as returned in the initial Access-Request
   message.

To avoid confusion, please change s/future Access-Requests/future
Access-Requests for the same session/

Security Considerations say:

   Confidentiality protection is not only a property
   required by this document, it is also required for the transport
   of keying material in the context of EAP authentication and
   authorization.  Hence, this requirement is, in many environments,
   already fulfilled.

Heh. Or at least the requirement is already present for other reasons in
many environments. Fulfillment is another question...

I'm not asking for any change here.

Lars Eggert:

Discuss [2008-07-11]:

Section 4.7., paragraph 8:
>    If the RADIUS server does not send a Requested-Location-Info
>    Attribute then the RADIUS client MUST NOT attach location
information
>    to messages towards the RADIUS server, unless an out-of-band
>    agreement is in place.

  Discuss-discuss: I may be missing something here, but why is it useful
  to allow an out-of-band agreement to override protocol semantics? If
  there's an agreement that this information is to always be exchanged,
  the server should simply always send Requested-Location-Info and then
  the client should include it.

Section 8.1., paragraph 6:
>    Requests to IANA for a new value for a Namespace ID will be
approved
>    by Expert Review.  The Designated Expert Reviewer team for these
>    requests is the current Operations Area Director and the RADEXT
>    working group chairs or the working group chairs of a designated
>    successor working group.

  Discuss: It is up to the IESG to appoint designated experts, not a
  published RFC. (The appointment may change over time.) The same issue
  exists for other registries, and some have a related issue where it's
  claimed that the OPS ADs appoint experts.

Section 11.2., paragraph 5:
>    [I-D.ietf-radext-rfc3576bis]
>               Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
>               Aboba, "Dynamic Authorization Extensions to Remote
>               Authentication Dial In User  Service (RADIUS)",
>               draft-ietf-radext-rfc3576bis-13 (work in progress),
>               October 2007.

  Discuss: The way this (now published as RFC5176) is used in Section
  3.3 and Section 8 makes me think this needs to be a normative
  reference. But it's an Informational RFC, which would make this a
  DOWNREF.

Comment [2008-07-11]:

Section 4.1., paragraph 17:
>        Example: anyisp.example.com

  Suggest to move this example down to the description of the REALM
  namespace, because it's specific to it. (It confused me on first
  reading to see the example and then read about namespaces where it
  isn't valis.) It might also be good to add one example to each of the
  other namespaces.

Section 4.2., paragraph 2:
>    The Location-Information Attribute provides meta-data about the
>    location information, such as sighting time, time-to-live, location
>    determination method, etc.  Implementations SHOULD treat this
>    attribute as undistinguished octets, like the Location-Data
Attribute
>    to which it refers.

  Why is this a SHOULD and not a MUST? Under what conditions may
  implementations interpret the attribute? (The same comment applies to
  other attributes below.)

Section 4.4., paragraph 19:
>      Note Well (variable):
>        This field contains a URI that points to human readable
>        privacy instructions. The data type of this field is string.

  The APP ADs should look at this. I'm not an i18n expert, but it seems
  pretty important to transport a URI here that points to something a
  user can understand.

Section 4.4., paragraph 21:
>    retransmission-allowed:
>       When the value of this field is to zero (0), then the recipient
of
>       this Location Object is not permitted to share the enclosed
>       location information, or the object as a whole, with other
>       parties.

  Are there any protocol or encoding mechanisms in place to prevent this
  sharing, or do we simply trust the other end to conform to our wishes?
  (Same issue applies to "retention-expires".)

Section 4.6., paragraph 1:
>    A RADIUS server SHOULD NOT
>    challenge for location information unless the Location-Capable
>    Attribute has been sent to it.

  Why is this a SHOULD NOT? When is it permissible to challenge?

Section 6., paragraph 2:
>                                      |    |     |SHLD| MUST|    |

  s/SHLD/SHOULD/ (don't abbreviate RFC2119 terms)

Section 8.1., paragraph 3:
>   |   0x31   | REALM              | IETF O&M Area Directors
|
>   |          |                    | ([email-masked])
|

  The ADs are at [email-masked].

Section 8.2., paragraph 6:
>    No mechanism to mark entries as "deprecated" is
>    envisioned.  Based on expert approval it is possible to delete
>    entries from the registry.

  It's usually much safer to deprecate registry entries or to make them
  historic, compared to simply removing them. Is there a particular
  reason for this choice? (Same comment applies to other registries.)

Section 9., paragraph 1:
>    We would like to thank Bernhard Aboba for the numerous
contributions
>    to this document.

  It's a bit unusual to thank a co-author, but hey :-)

Dan Romascanu:

Comment [2008-11-07]:

This COMMENT is based on the AAA-Doctor review by David Nelson. 

I have cleared a previous DISCUSS that was raising a number of concerns.

1. One of them was mentioning that this document needs at the very least
an IESG Note calling attention to the fact that certain of the RADIUS
attributes fail to meet either the letter or spirit of the RADIUS Design
Guidelines as to what may properly constitute an "opaque" attribute.
Opaque attributes are those that are carried in RADIUS, but not parsed
or directly acted upon by a RADIUS server.

The revised text that addresses this issue is as follows:

4.  Attributes

   It is important to note that the location specific parts of the
   attributes defined below are not meant to be processed by the RADIUS
   server.  Instead, a location server specific component used in
   combination with the RADIUS server is responsible for receiving,
   processing and further distributing location information (in
   combination with proper access control and privacy protection).  As
   such, from a RADIUS server point of view location information is
   treated as opaque data.

This text does not reference the Design Guidelines, but rather simply
declares that the attributes in question are to be considered opaque.  I
think this is a bit superficial, but probably suffices to address the
issue.

2. A second issue is whether RADIUS servers are expected to be able to
parse and act upon these various defined "string" data sets.  In the
IETF Last Call discussion, these seemed to be some confusion as to
whether this document required RADIUS servers (at least those
implementing these
attributes) to be "location aware" i.e. to be able to parse and act
intelligently upon the content of the location information.   

The added text of Section 4 addresses this issue, too.

While I have some lingering concerns that the attribute design style of
this document may be viewed as a model for future work, as there is no
explicit acknowledgement that it diverges from the Design Guidelines, I
think that the added text is sufficient to close the DISCUSS.

^L
---- following is a DRAFT of message to be sent AFTER approval ---
From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>,
    RFC Editor <[email-masked]>, 
    geopriv mailing list <[email-masked]>, 
    geopriv chair <[email-masked]>
Subject: Protocol Action: 'Carrying Location Objects in RADIUS 
         and Diameter' to Proposed Standard 

The IESG has approved the following document:

- 'Carrying Location Objects in RADIUS and Diameter '
   <draft-ietf-geopriv-radius-lo-23.txt> as a Proposed Standard

This document is the product of the Geographic Location/Privacy Working
Group. 

The IESG contact persons are Cullen Jennings and Jon Peterson.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-23.txt

Technical Summary

 This document specifies RADIUS attributes for conveying access  network
location information, in both civic and geospatial location  formats,
along with access network ownership.  The distribution of  location
information is a privacy sensitive task.  Dealing with  mechanisms to
preserve the user's privacy is important and is  addressed throughout,
for various scenarios of location information  function within AAA.

WG Summary

 The WG reached solid consensus to advance this document after  a number
of iterations.  The WG had initial hesitation about  taking on the work,
because the RFC 4119 pidf_lo object could  not be used within RADIUS
attribute size constraints.  The  WG concerns were met with an eventual
functional compromise,  providing a mandated attribute with the pidf_lo
policy markers,  and opaque attributes pointing to the geopriv location
formats developed for DHCP which had constraints similar
 to RADIUS.   

 This document is a Critical Requirement for 3GPP.  Both the  GSM
Association and the ITU have specified Operator Namespace  Tokens for
use in this protocol.  (The document has customers).

Document Quality

 The protocol was reviewed in depth by both the GEOPRIV and  RADEXT
Working Groups.  RADEXT's formal issues list was  cleared.  GEOPRIV and
RADEXT had some overlapping  issues, especially location information
design,  and scenario evaluation.  The conclusion that location-  aware
AAA systems need to be able to implement the  formats and processing
found in the GEOPRIV documents  was very useful, because it meant that
GEOPRIV did not  have to intercept or anticipate any enhancements of the
RADIUS data model. 

 The document is especially careful in projecting GEOPRIV's  paranoia
towards exposing location information.  Section
 8.3 contains a detailed review against the previously  defined
requirements related to this, and the Security  Considerations details
the use of security services  RADIUS provides as the using protocol to
meet requirements.

Note to RFC Editor
 
 None

IESG Note

   None  

IANA Note

 None