Subject: [Geopriv] Comments on draft-ietf-geopriv-radius-lo-23.txt

From: "Glen Zorn" <[email-masked]>
Date: Tue, 10 Mar 2009 12:22:35 -0700

In section 3.2, first paragraph, please change 
   If the RADIUS client provides a Location-Capable Attribute in the
   Access-Request, then the RADIUS server MAY request the RADIUS client
   for location information if it requires that information for
   authorization, and location information was not provided in Access-
   Request.  
to
   If the RADIUS client provides a Location-Capable Attribute in the
   Access-Request, then the RADIUS server MAY request location information 
   from the RADIUS client if that information is required for authorization
   and it was not provided in the Access-Request message.   

There are still complex attributes which don't need to be (Operator-Name,
Basic-Location-Policy-Rules), apparently just to flaunt the RADIUS design
guidelines.

In a less anal-retentive vein ;-), there still doesn't appear to be any way
to enable RFC 5176 dynamic authorization w/o also turning on the inclusion
of location data in RADIUS accounting messages.

In section 7.1, please change "the lack dynamic key management" to "the lack
of dynamic key management".  BTW, I'm not sure who raised these alleged
concerns WRT dynamic key management between RADIUS entities, but I guess
that that is irrelevant.

In the same section it says "Mutual authentication MUST be provided between
neighboring RADIUS entities to prevent man-in-the-middle attacks."
Unfortunately, this MUST is impossible to fulfill in the context of IPsec,
since the entities authenticated by IKE, et al. are IP addresses (i.e.,
interfaces), not RADIUS entities.  

What is a RADIUS "eco-system"?

~gwz

Play assigns meaning to human activity--work erases it.
  -- P.L. Wilson

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 10 Mar 2009 21:59:22 +0200

Hi Glen, 

... Quick feedback. 

>   and it was not provided in the Access-Request message.   

Editorial change; I can make that. 

>
>There are still complex attributes which don't need to be 
>(Operator-Name, Basic-Location-Policy-Rules), apparently just 
>to flaunt the RADIUS design guidelines.

We discussed this on the list already and I feel that we both will not come
to an agreement on this aspect. 

>
>In a less anal-retentive vein ;-), there still doesn't appear 
>to be any way to enable RFC 5176 dynamic authorization w/o 
>also turning on the inclusion of location data in RADIUS 
>accounting messages.

I have to check that. 

>
>In section 7.1, please change "the lack dynamic key 
>management" to "the lack of dynamic key management".  BTW, I'm 
>not sure who raised these alleged concerns WRT dynamic key 
>management between RADIUS entities, but I guess that that is 
>irrelevant.

Editorial change; I can make that. 

I will not go into the crypto aspects of RADIUS as this is hot topic by
itself ... 

>
>In the same section it says "Mutual authentication MUST be 
>provided between neighboring RADIUS entities to prevent 
>man-in-the-middle attacks."
>Unfortunately, this MUST is impossible to fulfill in the 
>context of IPsec, since the entities authenticated by IKE, et 
>al. are IP addresses (i.e., interfaces), not RADIUS entities.  

IKE (and IKEv2 for that matter) allows authentication of all sorts of
entities despite the fact that it runs between two IP addresses. 
In IKEv2 the IDi / IDr payloads are used to carry these identities that are
then subject of authentication. 

>What is a RADIUS "eco-system"?

RADIUS infrastructure. The context in which this was mentioned referred to
the Location Object leaving the AAA infrastructure towards the outside
world. 

Ciao
Hannes

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