Subject: [Geopriv] Re: Review of draft-ietf-geopriv-radius-lo-04.txt

From: Bernard Aboba <[email-masked]>
Date: Fri, 26 Aug 2005 17:43:14 -0700 (PDT)

In thinking about the problem of capabilities negotiation within the 
RADIUS-GEOPRIV document, it is not clear to me that it is necessary for a 
NAS to advertise location support. 

Instead, the NAS can be set by default not to send location attributes 
unless the server asks for them.  The problem then reduces to how the 
server communicates its needs to the NAS. 

There are several cases of interest: 

1) The RADIUS server REQUIRES the NAS to provide location
in the Access-Request (e.g. it implements location-based access control).
In this case the RADIUS server can send an Access-Reject with an 
Error-Cause attribute with a value of "Location Required". 
Alternatively if the authentication mechanism (e.g. EAP) supports 
Access-Challenges, the RADIUS server can place a "Send 
location" attribute in the Challenge.  On receiving either of these 
indications, the NAS includes location attributes in the Access-Request. 
Note that the server's decision is not influenced by whether the client 
has advertised location support, only by the inclusion of location 
attributes in the Access-Request.

2) The RADIUS server does not require location in the Access-Request,
but would like location attributes to be included in Accounting packets, 
if available.  In this case, the RADIUS server sends an Access-Accept
including a "Send location" attribute, perhaps specifying more details on
how location should be provided (e.g. Accounting-Stop only, interim
records, civil/geographic, etc.).

Since the RADIUS server does not require location attributes, a legacy NAS 
can ignore the "send location" attribute with no ill effects.  This is how 
legacy NAS implementations behave, and the "Issues and
Fixes" document indicates that this is in fact the correct behavior.
If the NAS does understand the "send location" attribute then it will
send location in the Accounting packets as requested.

Am I missing something, or is the problem really this simple? 

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

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 26 Aug 2005 22:13:53 -0700 (PDT)

>   Also, this use of Access-Reject is closer to the semantics for
> Access-Challenge.  I would prefer to use that, instead.  i.e. An
> Access-Request MAY be responded to with an Access-Challenge containing
> Error-Cause, For authentication methods that normally expect
> request/ack, receipt of an Access-Challenge would indicate that they
> add the relevant data, and re-send the Access-Request without
> prompting the user for more information.

If the RADIUS authentication mechanism doesn't already utilize an 
Access-Challenge, this will not work. 

>   That requirement would make it clear that the NAS *does* have to
> maintain state, but that it does not have to tell the user about the
> re-authentication.

But we can't impose that requirement retroactively. 

>   Yes.
> ...
>   Yes.
>   It would appear so.
>   Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 26 Aug 2005 23:02:13 -0700 (PDT)

> would seem that this proposal may work for non-location-aware proxies.

Yes, I think the problem is with the NAS, not proxies.  

> For non-location-aware NASes, the RFC's already require
> implementations to treat unexpected Access-Challenges as
> Access-Rejects, so this idea would appear to be fail-safe there, too.

Yes, Section 4.4 of RFC 2865 states:

"     If the NAS does not support challenge/response, it MUST treat an
      Access-Challenge as though it had received an Access-Reject
      instead."

So a RADIUS server can always send a Challenge with an Error-Cause value 
as well as a "send location" attribute.  Where the NAS does not expect a 
Challenge, it will treat it as an Access-Reject.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 26 Aug 2005 23:13:17 -0700 (PDT)

>   Can there be multiple Error-Causes?  That would seem to be efficient.

Off the top of my head, I don't see why not.  RFC 3576 allows 0+ 
Error-Cause attributes in a NAK, so I'd assume that it also would 
be allowed in an Access-Challenge or Access-Reject. 

> An Access-Request MAY be responded to with an Access-Challenge 
> containing Error-Cause, For authentication methods that normally expect

Where an Access-Challenge is expected, this works.  Where it is 
unexpected, RFC 2865 Section 4.4 requires that the NAS treat the 
Access-Challenge as an Access-Reject. 

> maintain state, but that it does not have to tell the user about the

I think that it's possible to make this work without changing existing 
Access-Challenge behavior.  If an Access-Challenge would be sent anyway, a 
"send location" attribute can be piggybacked on it.  If it is unexpected, 
the Access-Challenge will be treated as an Access-Reject and 
re-authentication will be required. 

> > Am I missing something, or is the problem really this simple? 

Based on this discussion, I think it is even simpler than I had thought -- 
Access-Challenge, Error-Cause and a "send location" attribute appear to 
solve the problem with no need for any capability advertisements.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 26 Aug 2005 23:34:56 -0700 (PDT)

> > > Am I missing something, or is the problem really this simple? 

The "server-driven" approach also provides a mechanism to address RADEXT 
Issue 27 (Who's Location). 

One of the major problems with the RADIUS-GEOPRIV document is that it 
does not support user location determination, only  NAS location. 

This is a problem for vendors who are shipping APs with built-in 
location support that enables APs to pinpint the location of associated 
stations.  At least one RADIUS server implementation now supports 
"location-based access control".  Why can't the RADIUS-GEOPRIV 
specification be used to send user as well as NAS location? 

This basic problem with the document was pointed out in November 2004, but 
has still not been fixed in August 2005, 9 months later.  

However, using the "server-driven" approach, the problem would  
not be hard to address.  In the "send location" attribute included by the 
server, the server can specify what type of location data it is looking 
for - user or NAS.  

Note that layer 2 standards such as IEEE 802.11k already enable this 
distinction.  In IEEE 802.11k a station can ask either for its own 
location or the location of the AP.

---

From: "Alan DeKok" <[email-masked]>
Date: Sat, 27 Aug 2005 01:01:40 -0400

Yes.

...

  Yes.

  It would appear so.

  Alan DeKok.

---

From: "Alan DeKok" <[email-masked]>
Date: Sat, 27 Aug 2005 01:40:13 -0400

> Access-Challenge, this will not work. 

  On the other hand, if the NAS is updated to include location
information, it may be acceptable to add additional requirements such
as this.

  For simple password-style authentication methods such as PAP or
CHAP, adding another step would be relatively easy.  For methods
already involving Access-Challenge, your previous suggestion would
apply.

> But we can't impose that requirement retroactively. 

  I agree.

  However, RADIUS proxies already pass Access-Challenge packets back
and forth for protocols they don't understand.  (e.g. EAP).  So it
would seem that this proposal may work for non-location-aware proxies.

  Alan DeKok.