Subject: RE: [Geopriv] Location-by-value in a SIP Location Header

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 18 Jul 2006 09:06:31 -0400

Perhaps some enlightenment is in order.  It's not clear to me how you
dsig a Data uri in a Location header (or maybe you mean dsig the pidf-lo
and put both the pidf-lo and the signature in the Data URI) somehow?
Are there some examples of this kind of thing elsewhere?

If we are ignoring technical arguments (as opposed to use cases), it's
out of forgetfulness, and not willfulness.  What were you referring to?

Brian

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Tuesday, July 18, 2006 8:59 AM
To: Rosen, Brian
Cc: [email-masked]; [email-masked]
Subject: Re: [Geopriv] Location-by-value in a SIP Location Header

Brian, James:

this is simply false. If desired, XML-DSIG is a well-known and  
accepted mechanism to achieve integrity. Such specification is no  
longer than the MUST NOT that you propose. You are also willfully  
ignoring the other technical arguments made as part of this discussion.

Henning

On Jul 18, 2006, at 8:48 AM, Rosen, Brian wrote:

> There was a desire expressed by Hannes to provide a way for a proxy to
> insert location-by-value.  He had proposed a SIP Location header
> specific way.  In IETF66, Henning suggested just using a data URI.
>
> Doing this may run afoul of the geopriv location privacy concerns,
> because there is no way for the user to sign the header to provide
> assurance that the PIDF, and specifically the retention and other  
> policy
> bits are preserved.  Note that S/MIME provides sufficient integrity
> protection for a body.  It's probably okay to use TLS per hop to  
> provide
> privacy, but not integrity protection.  The authors believe that there
> is no really compelling use case for this feature, and the effort to
> define acceptable security mechanisms for location data in a header
> would be a significant effort, further delaying the draft.
>
> We propose, therefore, to state in sip-location-conveyance, that a  
> Data
> URI MUST NOT be used in the Location header until a standards track  
> RFC
> defines a suitable security mechanism to protect the PIDF in the  
> header.
>
> Brian and James
>
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 18 Jul 2006 09:57:07 -0400

Brian,

a four-step process:

- take any PIDF-LO
- wrap in XML-DSIG as specified by the relevant W3C recommendation
- convert to base-64
- make into a data URL, as in the example I gave in an earlier message

   data:application/pidf+xml;base64,<base64-data>

Or did I miss the point of your question?

See http://en.wikipedia.org/wiki/Data:_URL for additional data URL  
examples, btw.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 18 Jul 2006 16:27:20 -0400

James M. Polk wrote:
> Henning
> 
> Remind us what the unique use-case is for a data URL, where neither a 
> by-reference URI nor a by-value PIDF-LO can be used?

The use case is proxy-inserted location, where the proxy does not have 
access to a globally-accessible HTTP server where it can deposit this 
information. This could be a proxy behind a (corporate) firewall or NAT, 
for example.

> 
> In other words, why is this needed, and what would it be used for that 
> every element necessary couldn't use one of the two methods of Location 
> Conveyance already specified in the doc?

See above. The incremental complexity is essentially zero.

> 
> Complexity is an issue in location conveyance - especially during 
> emergency calling, but I've heard you state this isn't an issue with a 
> data URL.  Are you sure?  Are others sure?

I don't get your complexity point. The complexity of a data URL is 
likely to be significantly lower than

- setting up a custom web server outside the security or NAT perimeter
- that allows remote writes by the proxy server
- using a proxy-to-webserver protocol that isn't standardized
- using a webserver-to-proxy protocol (to get the object identifier 
back) that isn't standardized, either
- automatically cleaning up location state just at the right time (not 
too early to avoid resolution problems and not too late to avoid 
exposure and denial-of-service problems where the attacker uses bogus 
SIP INVITEs to create lots of location entries)
- and hoping that the server is always accessible, so that emergency 
calls don't fail

The data URL solution is self-contained; the reference solution is 
basically of the "and then magic happens" kind, where the proposed 
solution only provides a tiny part of what's needed to actually build a 
real system.

Henning

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 18 Jul 2006 14:54:43 -0500

Henning

Complexity is an issue in location conveyance - especially during emergency 
calling, but I've heard you state this isn't an issue with a data URL.  Are 
you sure?  Are others sure?

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 18 Jul 2006 15:59:59 -0500

>information. This could be a proxy behind a (corporate) firewall or NAT, 

ok, but how would a UA know it's behind a corporate NAT/FW, instead of at a 
home using the SP's LIS beyond the NAT/FW, to know to use a data URL 
instead of by-value or by-reference PIDF-LO?

>I don't get your complexity point.

We're talking about all SIP elements that understand this extension now, if 
we do as you and Hannes are suggesting, include a third 
representation.  That's more code for every UA to include, and every 
location aware SIP server.

I hear your arguments below essentialling meaning location by-reference is 
a woefully underspecified user-case, and that it is the one that ought to 
be the one that may be dropped from the list within this extension proposal 
(because there is not enough there).  Are you going down that path here?

>The complexity of a data URL is likely to be significantly lower than
>
>- using a webserver-to-proxy protocol (to get the object identifier back) 
>that isn't standardized, either
>- automatically cleaning up location state just at the right time (not too 
>early to avoid resolution problems and not too late to avoid exposure and 
>denial-of-service problems where the attacker uses bogus SIP INVITEs to 
>create lots of location entries)
>- and hoping that the server is always accessible, so that emergency calls 
>don't fail
>

should by-reference be taken out as an incomplete piece to an 
underspecified solution, IYO?

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 18 Jul 2006 17:27:26 -0400

>> The use case is proxy-inserted location, where the proxy does not have 
                    ^^^^^^^^^^^^^^

I'm assuming that the proxy knows whether it has access to a web server 
or not. The UA really wouldn't know or care in that case.

> ok, but how would a UA know it's behind a corporate NAT/FW, instead of 
> at a home using the SP's LIS beyond the NAT/FW, to know to use a data 
> URL instead of by-value or by-reference PIDF-LO?

I would expect a UA to always use by-attachment unless it used an L7 
location mechanism that provided a reference to an object on a LIS 
somewhere. (This, by the way, raises some additional issues; how can the 
  UA know that the pointer it got from the LIS is accessible, by policy, 
to a random third party?)

> We're talking about all SIP elements that understand this extension now, 
> if we do as you and Hannes are suggesting, include a third 

I generally share concerns about code complexity, but we're talking 
pretty trivial code here. In a PHP-like language, it would be something like

if (url['scheme'] == 'http') {
   $fd = fopen($url);
   $lo = fread($fd);
} elseif (url['scheme'] == 'data') {
   $u = split(',', $url);
   $lo = base64_decode($u[1]);
}

Only the last elseif is data-specific. In other words, not exactly a big 
deal.

> 
> I hear your arguments below essentialling meaning location by-reference 
> is a woefully underspecified user-case, and that it is the one that 
> ought to be the one that may be dropped from the list within this 
> extension proposal (because there is not enough there).  Are you going 
> down that path here?

There may well be deployments where by-reference is valuable (such as 
where the LIS already provides by-reference location information to the 
proxy), but I fear that if we only do S/MIME attachments, the practical 
outcome is going to be lots of SBCs modifying SIP bodies.

> underspecified solution, IYO?

I believe it is currently underspecified; I won't go as far as 
suggesting it be taken out as noted above.

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 18 Jul 2006 18:14:30 -0500

If you want technically feasible, I can post a URI to the list that includes a complete PIDF-LO with DSig.  It's a little long though.

I'm not suggesting that this a good idea, but I see no reason to prevent it.

> From: Rosen, Brian [mailto:[email-masked]]
> Sent: Tuesday, 18 July 2006 11:07 PM
> To: Henning Schulzrinne
> Subject: RE: [Geopriv] Location-by-value in a SIP Location Header
> 

------------------------------------------------------------------------------------------------
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: Andrew Newton <[email-masked]>
Date: Thu, 20 Jul 2006 10:43:12 -0400

>   data:application/pidf+xml;base64,<base64-data>

Here's a rather naive question... what's the point of XML-DSIG?

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 20 Jul 2006 21:08:38 -0400

Somebody asked how you could use integrity checking in a data header;  
this was the answer. Whether integrity checking is useful is a  
separate question (and presumably independent of the mechanism).