Subject: [Sip] Location header

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 12 Jul 2006 19:19:52 -0400

To follow up on the discussion in the SIP group. I think there are  
roughly three options for the content of Location:

(1) Point to content in the body  --> can't be modified and cannot be  
inserted by proxies (and may not be inspectable by proxies if encrypted)

(2) Point to external location --> can be modified, can be added, but  
can induce loops if changed in mid-stream and incurs another failure  
mode (and possible security risks if the reference is generally  
accessible)

(3) Point to data URL (RFC 2397) as in

Location: data:application/pidf+xml;base64,<base-64 version of PIDF-LO)

Disadvantage: about 30% larger than as body; can't be encrypted  
separately (except as XML-DSIG)

Advantages: can be inserted/modified by proxies (similar to (2)), but  
avoids difficulty of external reference

I think these three methods all have different time-space-flexibility  
trade-offs and thus I suspect they all serve a need.

Henning

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 12 Jul 2006 19:36:24 -0400

Hi Henning,

I like your idea of using the data URL.
It would work nicely for PIDF-LO and SAML assertions.

Ciao
Hannes

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 13 Jul 2006 17:55:16 -0500

Right now, the ID lists options 1 and 2 as the only options, and this keeps 
things simple.  There have been a couple of comments here in Montreal that 
adding a data URL isn't really wanted.

One reason given is the inability to encrypt it (easily).  A message  body 
can be encypted using S/MIME, and a URI can have the server posessing the 
PIDF-LO configured to challenge a dereference request - including 
responding with an encrypted PIDF-LO.  Both these senarios have the PIDF-LO 
being able to be encrypted.  I'm not so sure encrypting the data URL is so 
straightforward, or deployable.  Others, please inform me and the list if 
this is untrue.

Cannot the ID proceed as is (in this respect), and once someone wants to 
extend this doc (once it's an RFC), propose that extention as a separate ID?

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 13 Jul 2006 19:08:51 -0400

I think as long as the location information is used for routing (the  
only reason to have a Location header at all), the encryption  
argument is of dubious utility. I don't see any realistic possibility  
that the UAC can predict the public key of some intermediary router -  
by definition, by making routing dependent on location, you don't  
know where the request will end up. If you did, you'd put that  
address in the request-URI and only the UAS would have to know  
location (in which case we don't need the location header).

Henning

On Jul 13, 2006, at 6:55 PM, James M. Polk wrote:

> Right now, the ID lists options 1 and 2 as the only options, and  
> this keeps things simple.  There have been a couple of comments  
> here in Montreal that adding a data URL isn't really wanted.
>
> One reason given is the inability to encrypt it (easily).  A  
> message  body can be encypted using S/MIME, and a URI can have the  
> server posessing the PIDF-LO configured to challenge a dereference  
> request - including responding with an encrypted PIDF-LO.  Both  
> these senarios have the PIDF-LO being able to be encrypted.  I'm  
> not so sure encrypting the data URL is so straightforward, or  
> deployable.  Others, please inform me and the list if this is untrue.
>
> Cannot the ID proceed as is (in this respect), and once someone  
> wants to extend this doc (once it's an RFC), propose that extention  
> as a separate ID?
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 13 Jul 2006 19:25:02 -0400

Hi James,

please explain me the difference (from a security point of view) between
* adding a location object into the header that is not encrypted, and
* adding a reference to a location object to the header that can be 
resolved into a location object by everyone that knows the reference?

Ciao
Hannes

James M. Polk wrote:
> Right now, the ID lists options 1 and 2 as the only options, and this 
> keeps things simple.  There have been a couple of comments here in 
> Montreal that adding a data URL isn't really wanted.
> 
> One reason given is the inability to encrypt it (easily).  A message  
> body can be encypted using S/MIME, and a URI can have the server 
> posessing the PIDF-LO configured to challenge a dereference request - 
> including responding with an encrypted PIDF-LO.  Both these senarios 
> have the PIDF-LO being able to be encrypted.  I'm not so sure encrypting 
> the data URL is so straightforward, or deployable.  Others, please 
> inform me and the list if this is untrue.
>

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 14 Jul 2006 00:28:47 -0500

>resolved into a location object by everyone that knows the reference?

The server which has the by-referenced PIDF-LO can challenge whoever asks 
for the PIDF-LO.  The header URI allows for each intermediary to ask for 
the dereference, but only those that have permission, surviving the 
challenge(s), get the PIDF-LO.  This means not all dereference attempts 
learn the UAC's location.  This cannot be accomplished in a header.

>>including responding with an encrypted PIDF-LO.  Both these senarios have 
>>the PIDF-LO being able to be encrypted.  I'm not so sure encrypting the 
>>data URL is so straightforward, or deployable.  Others, please inform me 
>>and the list if this is untrue.

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 14 Jul 2006 09:39:07 -0400

Hi James,

James M. Polk wrote:
> The server which has the by-referenced PIDF-LO can challenge whoever 
> asks for the PIDF-LO.  The header URI allows for each intermediary to 
> ask for the dereference, but only those that have permission, surviving 
> the challenge(s), get the PIDF-LO.  This means not all dereference 
> attempts learn the UAC's location.  This cannot be accomplished in a 
> header.
This would assume that the entity that created the location object has a 
  relationship with the final location recipient (and to share some 
credential with them).

I think that this is a totally unrealistic assumption.

Ciao
Hannes

>>> have the PIDF-LO being able to be encrypted.  I'm not so sure 
>>> encrypting the data URL is so straightforward, or deployable.  
>>> Others, please inform me and the list if this is untrue.
>>> Cannot the ID proceed as is (in this respect), and once someone wants 
>>> to extend this doc (once it's an RFC), propose that extention as a 
>>> separate ID?

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 14 Jul 2006 09:24:54 -0400

For the purposes of routing, such challenges are unlikely to be  
feasible or even plausible. Are you going to give a special secret to  
all possible carriers, PSAPs, E-CSCFs in the world, for every single  
individual? Good luck...

On Jul 14, 2006, at 1:28 AM, James M. Polk wrote:

>> * adding a reference to a location object to the header that can  
>> be resolved into a location object by everyone that knows the  
>> reference?
>
> The server which has the by-referenced PIDF-LO can challenge  
> whoever asks for the PIDF-LO.  The header URI allows for each  
> intermediary to ask for the dereference, but only those that have  
> permission, surviving the challenge(s), get the PIDF-LO.  This  
> means not all dereference attempts learn the UAC's location.  This  
> cannot be accomplished in a header.
>
>
>> Ciao
>> Hannes
>>
>> James M. Polk wrote:
>>> posessing the PIDF-LO configured to challenge a dereference  
>>> wants to extend this doc (once it's an RFC), propose that  
>>> extention as a separate ID?