Subject: Re: [Geopriv] I-D Action:draft-ietf-geopriv-radius-lo-19.txt

From: "James M. Polk" <[email-masked]>
Date: Fri, 01 Feb 2008 11:26:55 -0600

At 01:06 AM 2/1/2008, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>Hi Peter,
>
>This document does not support the case where 
>the location determination technique (e.g., GPS 
>receiver) is available at the end host.

Should it?

Or is this not a valid case?

(I'm not arguing one way of the other)

>Ciao
>Hannes
>
> > -----Ursprüngliche Nachricht-----
> > Von: ext Peter J. Cranstone [mailto:[email-masked]]
> > Gesendet: Donnerstag, 31. Januar 2008 19:39
> > An: [email-masked]
> > Betreff: RE: [Geopriv] I-D Action:draft-ietf-geopriv-radius-lo-19.txt
> >
> > How do you support encryption of users location data?
> >
> > For example - real time GPS data is obtained from the device and then
> > encrypted to preserve user privacy. It can then be
> > transmitted to a location
> > server. How does the current spec support multiple encryption schemes?
> >
> > Peter
> > _________________________________________________________
> > Peter J. Cranstone
> > CEO
> > 5o9, Inc.
> > Boulder, CO  USA
> >
> > Mobile Phone Numbers:
> > 1:    303.809.7342 | GMT -7
> > 2:    720.318.4620 | GMT -7
> > Skype:    Cranstone
> > Email:     [email-masked]
> > Blog:       http://petercranstone.blogspot.com
> >
> > Enterprise software that makes supporting mobile users as
> > easy as 1-2-3
> > Web site: www.5o9inc.com
> >
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Thursday, January 31, 2008 5:50 AM
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: [Geopriv] I-D Action:draft-ietf-geopriv-radius-lo-19.txt
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > This draft is a work item of the Geographic Location/Privacy
> > Working Group
> > of the IETF.
> >
> >
> >       Title           : Carrying Location Objects in RADIUS
> > and Diameter
> >       Author(s)       : H. Tschofenig, et al.
> >       Filename        : draft-ietf-geopriv-radius-lo-19.txt
> >       Pages           : 63
> >       Date            : 2008-01-31
> >
> > This document describes procedures for conveying access
> > network ownership
> > and location information based on a civic and geospatial
> > location format in
> > Remote Authentication Dial In User Service
> > (RADIUS) and Diameter.
> >
> > The distribution of location information is a privacy sensitive task.
> > Dealing with mechanisms to preserve the user's privacy is
> > important and
> > addressed in this document.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-
> > lo-19.txt
> >
> > To remove yourself from the I-D Announcement list, send a message to
> > [email-masked] with the word unsubscribe in
> > the body of the
> > message.
> > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> > to change your subscription settings.
> >
> > Internet-Drafts are also available by anonymous FTP. Login
> > with the username
> > "anonymous" and a password of your e-mail address. After
> > logging in, type
> > "cd internet-drafts" and then
> >       "get draft-ietf-geopriv-radius-lo-19.txt".
> >
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html or
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> > Internet-Drafts can also be obtained by e-mail.
> >
> > Send a message to:
> >       [email-masked].
> > In the body type:
> >       "FILE /internet-drafts/draft-ietf-geopriv-radius-lo-19.txt".
> >
> > NOTE:   The mail server at ietf.org can return the document in
> >       MIME-encoded form by using the "mpack" utility.  To use this
> >       feature, insert the command "ENCODING mime" before the "FILE"
> >       command.  To decode the response(s), you will need "munpack" or
> >       a MIME-compliant mail reader.  Different MIME-compliant
> > mail readers
> >       exhibit different behavior, especially when dealing with
> >       "multipart" MIME messages (i.e. documents which have been split
> >       up into multiple messages), so check your local documentation on
> >       how to manipulate these messages.
> >
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> >
> >
> >
> > _______________________________________________
> > Geopriv mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/geopriv
> >
>_______________________________________________
>Geopriv mailing list
>[email-masked]
>http://www.ietf.org/mailman/listinfo/geopriv

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

---

From: "Peter J. Cranstone" <[email-masked]>
Date: Fri, 1 Feb 2008 10:38:01 -0700

Think about it from this perspective - you have a mobile device with a GPS
onboard (or connected via Bluetooth). It grabs the location data and then
sends it encrypted to a web server.(could be done via HTTP by embedding it
inside the outgoing HTTP Request headers).

To preserve consumer privacy you encrypt it at the source - it then arrives
at the destination, could be a general purpose web server of some
description, once there it can be decrypted and "mashed" out for various
services.

Privacy is really the determining factor here. I don't believe it's wise to
have people's "location" data moving around in the clear unless they've
expressly authorized it.

Peter

-----Original Message-----
From: James M. Polk [mailto:[email-masked]] 
Sent: Friday, February 01, 2008 10:27 AM
To: Tschofenig, Hannes (NSN - FI/Espoo); ext Peter J. Cranstone;
[email-masked]
Subject: Re: [Geopriv] I-D Action:draft-ietf-geopriv-radius-lo-19.txt

Should it?

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 1 Feb 2008 21:57:16 +0100

RADIUS does not start at the end host. Hence, one would have to define a protocol that carries location information from the end host to the NAS (=RADIUS client). 

I don't want to work on it -- someone else can do it. 

Ciao
Hannes 

> Von: ext James M. Polk [mailto:[email-masked]] 
> Gesendet: Freitag, 1. Februar 2008 19:27
> An: Tschofenig, Hannes (NSN - FI/Espoo); ext Peter J. 
> Cranstone; [email-masked]
> Betreff: Re: [Geopriv] I-D Action:draft-ietf-geopriv-radius-lo-19.txt
> 
> > > Betreff: RE: [Geopriv] I-D 
> Action:draft-ietf-geopriv-radius-lo-19.txt
> > >
> > > You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 1 Feb 2008 21:58:15 +0100

With this document the RADIUS security mechanisms are used. 
It just does not support the GPS case. 

Ciao
Hannes

> Gesendet: Freitag, 1. Februar 2008 19:38
> An: 'James M. Polk'; Tschofenig, Hannes (NSN - FI/Espoo); 
> [email-masked]

---

From: "Peter J. Cranstone" <[email-masked]>
Date: Fri, 1 Feb 2008 14:01:24 -0700

Fair enough. Although I think it's important to think about. The location
data will always come from a device - and while the data is on the wire and
when it gets to whatever destination, it has to be protected from a Privacy
standpoint.

Cheers

Peter

-----Original Message-----
From: Tschofenig, Hannes (NSN - FI/Espoo) [mailto:[email-masked]]

Sent: Friday, February 01, 2008 1:58 PM
To: ext Peter J. Cranstone; James M. Polk; [email-masked]
Subject: AW: [Geopriv] I-D Action:draft-ietf-geopriv-radius-lo-19.txt

Ciao
Hannes

---

From: "Carl Reed" <[email-masked]>
Date: Sun, 3 Feb 2008 14:02:39 -0700

I believe that much of the standards work done by the Open Mobile Alliance 
handles authorization/authentication issues related to application level use 
of location, such as being sampled from a GPS enabled phone. There is a 
privacy manifesto that guides all of the privacy related requirements for 
the standards work in OMA.

As an aside, the location encodings used in the OMA MLP API is GML, although 
an earlier version of GML than is used in PIDF-LO.

Regards

Carl

----- Original Message ----- 
From: "Peter J. Cranstone" <[email-masked]>
To: "'Tschofenig, Hannes (NSN - FI/Espoo)'" <[email-masked]>; 
"'James M. Polk'" <[email-masked]>; <[email-masked]>
Sent: Friday, February 01, 2008 2:01 PM
Subject: Re: [Geopriv] I-D Action:draft-ietf-geopriv-radius-lo-19.txt

---

From: "Peter J. Cranstone" <[email-masked]>
Date: Mon, 4 Feb 2008 08:11:41 -0700

It's not a bad document - after reading it I wonder how many people will
actually follow it? There is a lot of coding required to pull all of it off
- and I suspect it will require a client side application. I can't imagine
an OS vendor allowing a service to query a device API over the Web - and
therein lies the problem - JavaScript can't read disk and com ports. In
addition a best practice would be to encrypt all data leaving the consumers
device.

Peter

-----Original Message-----
From: Carl Reed [mailto:[email-masked]] 
Sent: Sunday, February 03, 2008 2:03 PM
To: Peter J. Cranstone; 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'James M.
Polk'; [email-masked]

Regards

Carl

---

From: Richard Barnes <[email-masked]>
Date: Wed, 06 Feb 2008 22:39:33 -0500

Peter,

I think you're mis-understanding how this is expected to be used.  The 
client in RADIUS is not an end device, but a Network Access Server, 
which is a component of the network to which the device is connecting. 
Notice that in all the diagrams in Section 3 of the document, the User 
(i.e., the User's device) is only sends/receives authentication 
messages, which are some other protocol, not RADIUS.

Imagine you're wandering around with your laptop to a bunch of Starbucks 
location in the US.  At each WAP that you connect to, you're 
authenticating to the network over a web interface (that's the User part 
of the diagrams in Section 3).  RADIUS is what the authentication 
servers use on the back end:

+------+          +-----+            +---------------+
| User |--(HTTP)--| NAS |--(RADIUS)--| RADIUS Server |
+------+          +-----+            +---------------+

Thus, the purpose of RADIUS-LO would be to move location between the NAS 
and the RADIUS server: This could be used to deliver information about 
the user's location to the NAS (which could then deliver it to the user 
in *another* protocol), or for the NAS to report to the RADIUS Server 
that a user is trying to connect at a given location (as part of the 
authorization process).

Hope this helps,
--Richard

---

From: "Peter J. Cranstone" <[email-masked]>
Date: Thu, 7 Feb 2008 08:28:52 -0700

Richard,

Thanks for such a thoughtful response. While your approach below does work
with the scenario laid out I would offer the following thoughts.

+------+          +-----+            +---------------+
+----------------------+
| User |--(HTTP)--| NAS |--(RADIUS)--| RADIUS Server |--(HTTP)--| Starbucks
Web Server |
+------+          +-----+            +---------------+
+----------------------+

How does the Starbucks server know to query the Radius server to see if
there is location information there? I may have authenticated to the Radius
server which in turn allows me access to the Internet, however I'm now free
to surf the Web and visit any Web site. How then does that particular Web
site become aware that I even have location information to share then in
turn get pointed to the correct LOS to get that information?

What about this approach?

Simply embed the Location Information (Lat, Long, Alt, Heading, Speed)
inside the HTTP request headers. You can encrypt them to ensure that they
are safe from prying eyes. They are only sent to certain www addresses
(think about your favorites being "location aware" favorites). Now in the
illustration below I authenticate to the Web via the NAS and RADIUS servers.
I then surf around and end up on Starbucks home page. As Starbucks is one of
my location aware favorites, my browser embeds my current location
information in the outgoing HTTP Request header. The Starbucks Web server
receives this and then with a simple filter parses the information, decrypts
it and the hands it back to a script in the cgi-bin that can hand it over to
any Web service that needs it.

+------+          +-----+            +---------------+
+----------------------+
| User |--(HTTP)--| NAS |--(RADIUS)--| RADIUS Server |--(HTTP)--| Starbucks
Web Server |
+------+          +-----+            +---------------+
+----------------------+

When I log off the Starbucks site my location data disappears and I continue
on my way. In addition there is never any of my location data sitting on any
NAS, RADIUS or LO server. This ensures customer privacy.

This approach uses all existing standard internet protocols and doesn't
require any behavioral changes at either end of the ecosystem. Add a browser
plug-in and add a ISAPI filter on the server. Both are standard accepted
ways of doing things. The rest is nothing more than leveraging RFC2616
section 12.1

Cheers,

Peter

Mobile Phone Numbers:
1:    303.809.7342 | GMT -7 
2:    720.318.4620 | GMT -7
Skype:    Cranstone

Enterprise software that makes supporting mobile users as easy as 1-2-3
Web site: www.5o9inc.com 

-----Original Message-----
From: Richard Barnes [mailto:[email-masked]] 
Sent: Wednesday, February 06, 2008 8:40 PM
To: Peter J. Cranstone
Cc: 'Carl Reed'; 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'James M. Polk';
[email-masked]

Peter,

Hope this helps,
--Richard

---

From: Richard Barnes <[email-masked]>
Date: Thu, 07 Feb 2008 10:59:43 -0500

Peter,

First, I think it's imporatant to note that the use case you describe is 
not within the scope of the RADIUS-LO draft.  RADIUS-LO is purely about 
moving location information between RADIUS elements within a network, 
and doesn't specify how those elements use the location.

However, RADIUS-LO could be used to ENABLE the sort of things you're 
talking about, with some extra work on either end.  In the scenario you 
pose below, the NAS could embed the location it acquires through RADIUS 
in its HTTP response to the user, and the user could then use that 
location to request a location-based service.  The message flow would 
look something like the following:

User           NAS            RADIUS         SBUX Web
  |              |             Server          Server
  | HTTP Req.    |               |               |
  |------------->| RADIUS Req.   |               |
  |              |-------------->|               |
  |              | RADIUS w/LO   |               |
  | HTTP w/LO    |<--------------|               |
  |<-------------|               |               |
  |              HTTP Request w/LO               |
  |--------------------------------------------->|
  |          HTTP Response based on LO           |
  |<---------------------------------------------|

(Note: There is no current standard mechanism for embedding location in 
HTTP requests or responses)

So RADIUS-LO is a component in the overall solution.  It enables a NAS 
that might not be able to compute locations to acquire those locations 
via RADIUS.  The NAS can then distribute those locations to users, who 
would use them to request location-based services.

--Richard

---

From: "Peter J. Cranstone" <[email-masked]>
Date: Thu, 7 Feb 2008 11:37:04 -0700

Richard,

Thanks for the clarification. While I understand the purpose of the
RADIUS-LO server what concerns me are two things. Privacy and Dynamic data.
For example I have a mobile phone with a GPS enabled. I transmit my location
information to the RADIUS-LO server as part of my authentication. Assuming
for the moment that the data is protected on the server how does it get
updated? I suppose it could send a request back to my mobile device every
few minutes asking for an update, but this is cumbersome and not only adds
to network traffic flow, but causes all kinds of issues with "data
freshness". In your diagram below I believe it will work as advertised -
however I'm left with the feeling that it creates unnecessary traffic flow. 

User           NAS            RADIUS         SBUX Web
  |              |             Server          Server
  | HTTP Req.    |               |               |

The bottom part of the diagram makes the most sense. Make the HTTP request
with LO. To add it to the outgoing HTTP request header is fairly
straightforward - Mozilla have a page on their developer site that shows a
standard API that allows you to add your own request header. 

The elegance of this method is that it preserves privacy as the device is
the one pushing the data rather than the server requesting it, the extra few
bytes of location data don't add any significant overhead and the issue of
data freshness disappears as each time the request is made the updated data
is simply there. 

Cheers

Peter

-----Original Message-----
From: Richard Barnes [mailto:[email-masked]] 
Sent: Thursday, February 07, 2008 9:00 AM
To: Peter J. Cranstone
Cc: 'Carl Reed'; 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'James M. Polk';
[email-masked]

Peter,

User           NAS            RADIUS         SBUX Web
  |              |             Server          Server
  | HTTP Req.    |               |               |

--Richard