Subject: [Geopriv] Updating 3693

From: Andrew Newton <[email-masked]>
Date: Wed, 13 Sep 2006 11:45:20 -0400

All,

Is there any general interest for an update to RFC 3693 (and please notice 
that I said "update" not "obsolete")?

For starters, I think we have evolved different terminology than that of RFC 
3693, in some cases opting for newer terms that are clearer than what 3693 
defines.  For instance, we talk about location configuration protocols and 
not "sighting" protocols.  Those two things are different.  For "using 
protocol", we usually mean "inter-domain conveyance," etc....

Comments?

-andy

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

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 13 Sep 2006 11:00:46 -0500

I think that this is very worthwhile.
I think that we have to clarify these interfaces state and state what
their characteristics and behaviours are.

> -----Original Message-----
> From: Andrew Newton [mailto:[email-masked]]
> Sent: Thursday, 14 September 2006 1:45 AM
> To: [email-masked]
> Subject: [Geopriv] Updating 3693
> 
> All,
> 
> For starters, I think we have evolved different terminology than that
of
> RFC

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 13 Sep 2006 13:23:55 -0500

At 11:00 AM 9/13/2006 -0500, Winterbottom, James wrote:
>I think that we have to clarify these interfaces

Interfaces??  In the IETF?

>state and state what

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 13 Sep 2006 13:48:31 -0500

At 11:45 AM 9/13/2006 -0400, Andrew Newton wrote:
>Those two things are different.  For "using protocol", we usually mean 
>"inter-domain conveyance," etc....

does this intend to let LoST and HTTP off the hook of being a "using 
protocol", meaning all security and privacy requirements for "using 
protocols" stated in 3693 which are communicated intra-domain are allowed 
to be avoided? Effectively meaning as long as the communication transaction 
including location is intra-domain, it can be in cleartext without respect 
for distribution and retention rules/flags set by a rulemaker (which can be 
the user)?

---

From: Andrew Newton <[email-masked]>
Date: Wed, 13 Sep 2006 15:28:42 -0400

James M. Polk wrote:
> protocols" stated in 3693 which are communicated intra-domain are 
> allowed to be avoided? Effectively meaning as long as the communication 
> transaction including location is intra-domain, it can be in cleartext 
> without respect for distribution and retention rules/flags set by a 
> rulemaker (which can be the user)?

This illustrates part of the confusion and the reason for my message.  We 
have also been living by two rules: 1) exceptions are made for emergency use 
cases, and 2) location without identity does not pose as big a privacy risk. 
  Hence, LoST.

I certainly was not intending to let anyone/thing off of any hooks, but we 
have made certain decisions in this working group that are not 
straightforwardly understood when somebody looks at 3693.  Inter-domain vs 
intra-domain conveyance explains PIDF-LO vs. DHCP.

-andy

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 13 Sep 2006 16:13:27 -0400

> > allowed to be avoided? Effectively meaning as long as the 
> > communication transaction including location is 
> intra-domain, it can 
> > be in cleartext without respect for distribution and retention 
> > rules/flags set by a rulemaker (which can be the user)?
> 
> This illustrates part of the confusion and the reason for my 
> message.  We have also been living by two rules: 1) 
> exceptions are made for emergency use cases, and 2) location 
> without identity does not pose as big a privacy risk. 
>   Hence, LoST.

When did we accept the emergency use case is an exception to 3693?  I see
some proposal for such, but haven't witnessed consensus.

-Marc-

> 
> I certainly was not intending to let anyone/thing off of any 
> hooks, but we have made certain decisions in this working 
> group that are not straightforwardly understood when somebody 
> looks at 3693.  Inter-domain vs intra-domain conveyance 
> explains PIDF-LO vs. DHCP.
> 
> -andy
> 
>

---

From: Andrew Newton <[email-masked]>
Date: Wed, 13 Sep 2006 16:26:22 -0400

> some proposal for such, but haven't witnessed consensus.

And now you know why I'm asking the overall question about updating 3693.

To your specific question: the original proposal dates back a couple of 
years when Brian and John Morris presented a draft to the GEOPRIV working 
group.  It met with no opposition.  That draft never became an RFC because 
the authors never formally asked for it to be a working group item, probably 
because they didn't feel it was necessary. (this working group has had many 
drafts before it that are intended to serve as discussion items and not 
necessarily RFC candidates)

Since then, this rule has been brought up many times in discussions, with no 
opposition.  Just last month it was brought up on this very mailing list, 
again meeting no opposition.

It is time we codify such things.

-andy

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 13 Sep 2006 22:37:15 +0200

Hi James,
Hi all,

I don't understand what you mean by "let LoST and HTTP off the hook".

A LoST query does not carry an identity in the query because it does not 
need one. We have the security threats draft to address security aspects 
and there are things to consider. I never got the impression that we are 
not going to address them in the ECRIT working group.

Ciao
Hannes

  James M. Polk schrieb:
>> Is there any general interest for an update to RFC 3693 (and please 
>> notice that I said "update" not "obsolete")?
>>

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 13 Sep 2006 17:12:49 -0400

Andy,

The issue we're talking about is basically giving emergency services a high
status wrt to end host location information, bypassing any/all
privacy/security dictated by the location owner.

1) I doubt this would even begin to be accepted in the IESG.
2) It directly flies in the face of RFC2804
3) This is easily handled by the service provider in customer agreements,
this does NOT require a protocol action to enforce.  (E.g.  'Mr. Newton, as
part of this agreement, you agree to lose all privacy rights to your
location information to any/all emergency services entities.')

This, by itself, does not require any action wrt 3693 (imo, of course)

-Marc-

> Sent: Wednesday, September 13, 2006 4:26 PM
> To: Marc Linsner
> Cc: 'James M. Polk'; [email-masked]
> Subject: Re: [Geopriv] Updating 3693 - protocols off the hook?
> 
> Marc Linsner wrote:
> > 
> > When did we accept the emergency use case is an exception 
> to 3693?  I 
> > see some proposal for such, but haven't witnessed consensus.
> 
> To your specific question: the original proposal dates back a 
> couple of years when Brian and John Morris presented a draft 
> to the GEOPRIV working group.  It met with no opposition.  
> That draft never became an RFC because the authors never 
> formally asked for it to be a working group item, probably 
> because they didn't feel it was necessary. (this working 
> group has had many drafts before it that are intended to 
> serve as discussion items and not necessarily RFC candidates)
> 
> Since then, this rule has been brought up many times in 
> discussions, with no opposition.  Just last month it was 
> brought up on this very mailing list, again meeting no opposition.
>

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 13 Sep 2006 16:15:25 -0500

>I don't understand what you mean by "let LoST and HTTP off the hook".

this was clearly a catalyst remark, wanting discussion about it.  But to 
that point, I have only witnessed SIP fall into the "using protocol" 
category, having to (in its proposal to justify becoming a Geopriv using 
protocol) state how it meets 3693 requirements.

I have not, however, seen other protocol efforts (post 3693's publication) 
that carry such text, nor have I seen any of those efforts officially 
blessed by Geopriv, which I think ought to happen.  I'm not sure what form 
this blessing ought to happen in, but I think there needs to be a "Geopriv 
stamp of approval to carry location" without some other WG saying "well... 
if identification is not in the message, it doesn't apply to Geopriv's 
rules" because that is not written in a Geopriv RFC, and might be part of 
what Andy's attempting to get to.

>need one.

The ECRIT folks (and I'm one of them) say this is so, but I haven't read 
any Geopriv consensus on this position.

Remember, this message is in the Geopriv WG, not ECRIT, and it shouldn't be 
cross polinated with implied approvals.

>We have the security threats draft to address security aspects and there 
>are things to consider. I never got the impression that we are not going 
>to address them in the ECRIT working group.

Fair, but Geopriv (not ECRIT) should think about something stating:

- if location is carried point-2-point at the application layer, it needs 
to be encapsulated to protect it, and the receiving end MUST obey the 
geopriv rules.

- If location is carried point-2-point other than in a PIDF-LO, but still 
at the application layer, it needs to be encapsulated to protect it, and 
have geopriv rules indicated in the message

- If location is carried hop-by-hop at the application layer, it needs to 
be encapsulated to protect it, and geopriv rules MUST be included and 
adhered to by all elements viewing the location information.

- If location is carried at a lower layer, in which the identity of the 
user of the endpoint in which the location implies is not included in the 
message, this communication MUST be intra-domain, and SHOULD be point-2-point

...that is, if 3693 is updated

>>to be avoided? Effectively meaning as long as the communication

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 13 Sep 2006 16:22:12 -0500

Apparently if we claim that it is for emergency usage we can.
Isn't that what is stated in 3693 and what is used in the SIP conveyance
draft if security fails?

> From: James M. Polk [mailto:[email-masked]]
> Sent: Thursday, 14 September 2006 4:49 AM
> To: Andrew Newton; [email-masked]
allowed
> transaction
> for distribution and retention rules/flags set by a rulemaker (which
can
> be

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 13 Sep 2006 17:25:23 -0400

> I have not, however, seen other protocol efforts (post 3693's 
> publication) that carry such text, nor have I seen any of those efforts 
> officially blessed by Geopriv, which I think ought to happen.  I'm not 
> sure what form this blessing ought to happen in, but I think there needs 
> to be a "Geopriv stamp of approval to carry location" without some other 
> WG saying "well... if identification is not in the message, it doesn't 
> apply to Geopriv's rules" because that is not written in a Geopriv RFC, 
> and might be part of what Andy's attempting to get to.

I'm not sure which way you are arguing. Are you suggesting that we 
should haul Google, Yahoo and Mapquest in front of the GEOPRIV court 
since they don't have a license to transmit anonymous location 
information as part of a protocol across the network?

A POST or GET request with & arguments is, after all, no less a protocol 
than sticking a header into a HTTP request or a body into a SIP request. 
To boot, they don't even use PIDF-LO - how dare they!

> - if location is carried point-2-point at the application layer, it 
> needs to be encapsulated to protect it, and the receiving end MUST obey 
> the geopriv rules.
> 
> - If location is carried point-2-point other than in a PIDF-LO, but 
> still at the application layer, it needs to be encapsulated to protect 
> it, and have geopriv rules indicated in the message
> 
> - If location is carried hop-by-hop at the application layer, it needs 
> to be encapsulated to protect it, and geopriv rules MUST be included and 
> user of the endpoint in which the location implies is not included in 
> the message, this communication MUST be intra-domain, and SHOULD be 
> point-2-point
> 

Good luck on talking to Google, Mapquest and kin about these rules...

I'm sorry, but I think this is getting a bit silly.

Henning

---

From: Andrew Newton <[email-masked]>
Date: Wed, 13 Sep 2006 17:30:50 -0400

> Isn't that what is stated in 3693 and what is used in the SIP conveyance

Of course, that is a SHOULD in 3693.  And section 8.3 could use 
clarification, at the very least not confusing authorization with 
authentication.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Wed, 13 Sep 2006 17:33:25 -0400

> privacy/security dictated by the location owner.

Excuse my gross generalization, but I certainly didn't mean "if emergency, 
scribble LI on bathroom walls and post it to newsgroups".  I meant it more 
in the vain of "if exceptions need to be made, there is latitude to do so if 
no alternatives can be found."

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 13 Sep 2006 17:39:54 -0400

We have, for a while, made two points to geopriv about the emergency case:
1) Because we do location based routing, we needed hop-by-hop security
rather than end to end security
2) We want to fail safe.  That means fall back to no security, and accept
the implications of a downgrade attack.

I'm not sure we really need any other deviation from the requirements of
3693.  The specific issue of legal requirements trumping user preferences is
not confined to the emergency case.

I believe we have always had broad acceptance of these points.

Brian

> Sent: Wednesday, September 13, 2006 5:33 PM
> To: Marc Linsner
> Cc: [email-masked]

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 13 Sep 2006 17:40:51 -0400

And the emergency exception presumably does not mean "every PSAP can 
track any citizen at any time, at their convenience (and their sense of 
what the current administration will let them get away with)".

Andrew Newton wrote:
> Excuse my gross generalization, but I certainly didn't mean "if 
> emergency, scribble LI on bathroom walls and post it to newsgroups".  I 
> meant it more in the vain of "if exceptions need to be made, there is 
> latitude to do so if no alternatives can be found."
> 
> -andy
> 
>

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 13 Sep 2006 16:48:39 -0500

>I'm sorry, but I think this is getting a bit silly.

I don't believe 3693 needs to be updated, but if folks are thinking about 
it, there be dragons in there

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 13 Sep 2006 18:23:03 -0500

> some proposal for such, but haven't witnessed consensus.

Allowances for emergency are made in RFC 3693, to a degree:

      15.3)     The protocol SHOULD allow a bypass if authentication
      fails in an emergency call.

However - this seems to highlight a problem in sip-location-conveyance:

         ... TLS protection of location SHOULD be used, however, if
   establishment of the TLS connection fails, the call set-up
   operation, including location conveyance, MUST be retried without
   TLS.

Nothing is mentioned in RFC 3693 regarding using in-the-clear protocols, just authentication.  Relaxing the requirement on S/MIME is reasonable, but TLS should still be used to provide the privacy.  An update to RFC 3693 can then permit clear-text protocols in the case of failure.

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 13 Sep 2006 18:56:20 -0500

>    operation, including location conveyance, MUST be retried without

asking directly to this, do you want location-conveyance to change the MUST 
to SHOULD in this case?

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 13 Sep 2006 19:21:29 -0500

I'm not sure that a SHOULD is necessary.  Perhaps the problem is that sip-location-conveyance is breaking new ground - we need to decide if this is acceptable and document this as permissible...

   15.4)   The protocol MAY allow a bypass of encryption if an encrypted session fails.

However, I'm not sure that this is necessary; TLS is mandatory to implement so everyone is going to have it, at least to some basic level.  Perhaps someone can enlighten me otherwise.   RFC 3693 talks of authentication, so what you perhaps should say in location-conveyance is that for emergency calls, authentication checks (like the validation of the server-side certificate) SHOULD not cause the session establishment to fail.

Does that help?

> Sent: Thursday, 14 September 2006 9:56 AM
> To: Thomson, Martin; Marc Linsner; Andrew Newton
> Cc: [email-masked]
> Subject: RE: [Geopriv] Updating 3693 - and conveyance
>

---

From: [email-masked]
Date: Thu, 14 Sep 2006 06:37:58 -0400 (EDT)

Just an  FYI and somewhat related and for what it is worth. There is a
simple model for encoding location and embedding that location content
into an RSS message. Check out www.georss.org and www.georss.org/1 . No
worries about privacy as everything is opt in in the RSS world :-)

Microsoft is implementing (has implemented) GeoRSS as part of their new
release of Virtual Earth, Local, and other related applications. They are
using the GML serialization of the GeoRSS info model. Most of the examples
are using Atom - another IETF RFC.

The interesting point is that folks are already implementing georss for
alerting applications and there is talk of using the same GML profile in a
variety of other emergency notification standards.

Cheers

Carl

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 14 Sep 2006 08:44:20 -0400

Thanks for the interesting pointer. I can only marvel at the  
simplicity and compactness of the "Simple GeoRSS" format. Gets the  
job done without 600 bytes of XML verbiage to convey 32 bits of  
information... Allowing this format as part of our efforts would be  
highly beneficial.

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 14 Sep 2006 16:33:43 +0200

Hi Henning,

I pushed the GEOPRIV group for a long time to work on the PIDF-LO 
profile. In the first versions of the draft we had a punch of examples 
in there that showed quickly where the complexity is: complex shape 
types (arc bands, spheres, ...).

I think that we should put the shape descriptions into the PIDF-LO draft 
again because they are extremely helpful for the developer. Furthermore, 
we should evaluate whether we really need many of the shape types. Sure, 
many things are possible and maybe used in some networks throughout the 
world. I do wonder, however, there isn't a room for simplification here.

I wonder how many of them really get used. Using points or something 
similar is pretty straight forward.

Ciao
Hannes

Henning Schulzrinne schrieb:
> Thanks for the interesting pointer. I can only marvel at the simplicity 
> and compactness of the "Simple GeoRSS" format. Gets the job done without 
> 600 bytes of XML verbiage to convey 32 bits of information... Allowing 
> this format as part of our efforts would be highly beneficial.
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 14 Sep 2006 16:35:03 +0200

Hi Carl,

I wonder whether there is still a chance to put some basic privacy rules 
into this work. This is obviously something that is quite important for us.

Ciao
Hannes

---

From: Andrew Newton <[email-masked]>
Date: Thu, 14 Sep 2006 11:20:54 -0400

> into this work. This is obviously something that is quite important for us.

Since RSS/Atom are public information, I don't know how useful it would be. 
  However, there have been people in the past who have suggested 
authenticated and encrypted RSS/Atom streams, so at that point such 
semantics might be useful.  Though, I don't think authenticated/encrypted 
RSS/Atom is used much at all.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Thu, 14 Sep 2006 11:17:32 -0400

> this format as part of our efforts would be highly beneficial.

Actually, if you dig down they do go further with lines and polygons and 
boxes.  Using our civilLoc schema in RSS/Atom would also be interesting.

Beginning with Andrew Davial's work, we have discussed publishing location 
information in HTML and HTTP.  RSS and Atom are along the same lines of 
HTML.  Though the work was never pursued because the authors did not have 
the time, but we did reach conclusions of approach on these matters.  To 
summarize that conclusion: 1) putting LI in HTTP headers was considered 
harmful in that web clients might unknowingly hand LI to web servers 
unbeknownest to the user, and 2) putting LI in HTML seems reasonable as it 
is normally intended as public information and understood by web masters, etc...

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 14 Sep 2006 21:46:38 -0400

I certainly agree with simplification and reduction to actual use  
cases. It's easy to add things later, but hard to take things away,  
since one never knows who might be using a particular feature.

On Sep 14, 2006, at 10:33 AM, Hannes Tschofenig wrote:

> profile. In the first versions of the draft we had a punch of  
> examples in there that showed quickly where the complexity is:  
> complex shape types (arc bands, spheres, ...).
>
> I think that we should put the shape descriptions into the PIDF-LO  
> draft again because they are extremely helpful for the developer.  
> Furthermore, we should evaluate whether we really need many of the  
> shape types. Sure, many things are possible and maybe used in some  
> networks throughout the world. I do wonder, however, there isn't a  
> room for simplification here.
>
> I wonder how many of them really get used. Using points or  
> something similar is pretty straight forward.
>
> Ciao
> Hannes
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 14 Sep 2006 21:13:01 -0500

I can assure you that all of the shape types included in the geoShapes
draft are used today. Assuming a point for any of these shapes is a
really BAD compromise. Arcbands for example are very common in GSM and
GRPS networks and at high TA values can cover a huge area, picking an
arbitrary point with no indication of uncertainty is simply culpable.

It was decided at the last IETF that the GeoShapes draft was out of
scope for the IETF, and that the OGC should pick it up. I am not sure
how far this has progressed, but I am not in favour of redefining these
shapes in PIDF-LO profile. If they are important to GeoPriv and we want
define them then the geoShapes draft should be reinstated and referred
to (I still think this is the best option). Or if we want to use them
but don't want to define them, then we should refer to an OGC document.
We should not try to define shape types in PIDF-LO profile.

Please tell me I have misunderstood what is being proposed.

Cheers
James

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Friday, 15 September 2006 11:47 AM
> To: Hannes Tschofenig
> Cc: GEOPRIV
> Subject: Re: [Geopriv] FYI - somewhat related to Updating 3693 -
> protocolsoff the hook?
>

---

From: [email-masked]
Date: Fri, 15 Sep 2006 01:23:33 -0400 (EDT)

Hannes -

As one of the original GeoRSS collaborators (anyone can join in), I will ask.

Cheers

Carl