Subject: Re: [Sip] Location header

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 14 Jul 2006 10:19:41 -0400

Hi Mike,

Michael Hammer (mhammer) wrote:
> Hannes,
> 
> If you are right, then you are saying that symmetric secret keys are out
> of the question.  That leaves some sort of public/private key type of
> operation.

The problem is not only the authentication but the authorization.

Virtually everyone could be location recipient.

> 
> Contrary to what Jon suggested earlier, there are ways of passing an
> encrypted object to multiple recipients, namely by using a secret key to
> encrypt the LO, then adding the secret key enrypted by the public key of
> the intended recipient as an object for each recipient.

We haven't even come to the problem of multiple recipient with a single 
message.

... and: S/MIME does not provide these capabilities.

   This also has
> the characteristic that down-stream nodes upon learning of additional
> recipients, can add new Pu(secret) objects for those new recipients as
> needed.  That does assume a chain of trust among those given access to
> the secret.
> 
> Is that practical?  I think so, but others may have their opinion.
> 

This is just an optimization of encrypting location objects to 
individual recipients. I am not sure we are even closen to optimizations.

> BTW, can someone re-summarize what the requirements are?

Requirements for what exactly? Most of the requirements are listed in 
the document provided by James & Brian.

> It must be modifiable -> must be a header not body
> It must provide confidentiality -> encrypted or selectively handed out
> (by ref)
> Downstream recipient unknown to UAC must have access -> ???
> ...
What is 'it'?

Ciao
Hannes

> 
> Mike
> 
> 
> 
>>-----Original Message-----
>>From: Hannes Tschofenig [mailto:[email-masked]] 
>>Sent: Friday, July 14, 2006 9:39 AM
>>To: James Polk (jmpolk)
>>Cc: [email-masked]; Henning Schulzrinne
>>Subject: Re: [Sip] Location header
>>
>>Hi James,
>>
>>James M. Polk wrote:
>>
>>>At 07:25 PM 7/13/2006 -0400, Hannes Tschofenig wrote:
>>>
>>>
>>>>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?
>>
>>>
>>>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
>>
>>
>>>
>>>>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.
>>>>>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?
>>>>>At 07:19 PM 7/12/2006 -0400, Henning Schulzrinne wrote:
>>>>>
>>>>>
>>>>>>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
>>>>>
>>>>>
>>>>>_______________________________________________
>>>>>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
>>>
>>>
>>>
>>
>>_______________________________________________
>>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
>>
> 
> 
> 

_______________________________________________
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: Henning Schulzrinne <[email-masked]>
Date: Fri, 14 Jul 2006 10:19:56 -0400

On Jul 14, 2006, at 10:05 AM, Michael Hammer ((mhammer)) wrote:

> the intended recipient as an object for each recipient.  This also has

I suspect there are multiple deployment scenarios, so it is probably  
impossible to say that it is (or not), in general. However, we might  
take two location-based routing scenarios that we have discussed:

(1) emergency calling

(2) calling for towing service

For either, I'm having a really hard time picturing how the sender  
(or the originating VSP) can know the credentials or even identity of  
the proxies that are on the signaling path. My VSP is located in  
Germany; it is unlikely to have any relationship with the Montreal  
fire department or, more importantly, the routing model of the  
emergency calling network in Canada. I think the model that has been  
discussed is that there might be a province/state proxy, which routes  
to a county proxy which routes to a city proxy. Only the first one  
would be visible in LoST, so the caller has no way to determine the  
identity or public key of the other two.

Clearly, there are going to be cases where such multiple-destination  
encryption is feasible, but this has no bearing on the value vs.  
reference discussion, since you can do the kind of thing you  
mentioned either way.

> It must be modifiable -> must be a header not body

Right.

> It must provide confidentiality -> encrypted or selectively handed out

I would qualify this as saying that it must be able to do this in  
some cases. Like other routing-related information (To, caller  
preferences, etc.), it's unlikely to be common, given your last  
requirement.

Assuming you use TLS, the extra encryption of the information offers  
almost no value, since all those that are destinations for a TLS  
session also need to inspect the Location information. This is why we  
don't encrypt the From/To header, Route header and other similar  
routing/policy information, either.

By the way, an interesting model is to split the routing from the end  
system information, if they need different degrees of precision: The  
routing-related information may only need city-level precision, for  
example, and the end-to-end information would have house-level  
precision. This doesn't help much with emergency calling since the  
caller won't know the destination public key ahead of time, as far as  
I can tell. (Unless all PSAPs in a state, say, share the same public/ 
private key pair.)

> Downstream recipient unknown to UAC must have access -> ???

Indeed, with the minor qualification of "recipient*s*", i.e., there  
might be several.

Henning

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Fri, 14 Jul 2006 10:05:36 -0400

Hannes,

Mike

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 14 Jul 2006 22:08:41 -0400

inline.

Henning Schulzrinne wrote:

> For either, I'm having a really hard time picturing how the sender  (or 
> the originating VSP) can know the credentials or even identity of  the 
> proxies that are on the signaling path. My VSP is located in  Germany; 
> it is unlikely to have any relationship with the Montreal  fire 
> department or, more importantly, the routing model of the  emergency 
> calling network in Canada. 

True. Whats interesting is that, as Jon and others have said, 
location-by-reference allows the owner of the location to apply many 
different types of authorization policies.

One type of authorization policy could simply be 'anyone on the path of 
this request is allowed to access the data for the duration of the 
dialog'. To provide this, as long as each hop was encrypted ala sips, if 
  a proxy inserted an HTTP URI with a crypto-random URI, the proxy would 
grant access to the location information as long as the dialog is still 
active.

Of course, you can always use traditional white lists if you happen to 
be in an environment where there is a pre-arranged relationship between 
parties. Location by reference allows both parties.

I do think, though, that Henning raises a good point, which is that, if 
you do specify location by reference, you need to be very crisp on how 
long the entity is expected to cache the data, and whether it can change 
it.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 15 Jul 2006 09:50:34 -0400

> One type of authorization policy could simply be 'anyone on the  
> path of this request is allowed to access the data for the duration  
> of the dialog'. To provide this, as long as each hop was encrypted  
> ala sips, if  a proxy inserted an HTTP URI with a crypto-random  
> URI, the proxy would grant access to the location information as  
> long as the dialog is still active.

That's essentially the same security model offered by the location-by- 
value approach, as far as I can tell.

I agree that location-by-reference offers other security models; I  
never claimed that this is an either-or model; we can easily support  
both without changes in the header definition. After all, they are  
all URLs.

The trade-off is that for the simple on-path-can-read, the by- 
reference approach incurs significant overhead, as the location  
provider has to be able to maintain an HTTP server that is accessible  
by any potential destination of the call. For the case of end-system  
inserted location, this now means another configuration option since  
the UA or proxy has to have write access to an HTTP server, which  
isn't even standardized right now. (HTTP PUT? XCAP? WebDAV? ftp? some  
other special protocol?) For proxy-inserted, that server has to be  
outside a NAT and globally reachable.

In other words, for the common case you stipulate, by-reference only  
adds complexity and failure modes, with no increase in security or  
efficiency. (Actually, by reference is likely to be less efficient  
for the outbound-proxy inserts case, as multiple downstream proxies  
all have to open (TLS) connections to the server holding the  
location, each at several hundred or thousand bytes of traffic to get  
a 60-byte location object.)

>
> Of course, you can always use traditional white lists if you happen  
> to be in an environment where there is a pre-arranged relationship  
> between parties. Location by reference allows both parties.

I'm not disagreeing and don't think I've ever said that location-by- 
reference is not useful in some circumstances. There's just no point  
paying the complexity and reliability cost when there is no  
functional difference.

I think the basic design principle holds: simple things should be  
simple to do.

Henning

---

From: "James M. Polk" <[email-masked]>
Date: Sat, 15 Jul 2006 16:52:57 -0500

Ok, let's bubble back up to use cases.

What's the use case for a data URL giving Location in a header here, and 
does that function have to be solved/addressed now, in this document?

I might add that just because something is possible, doesn't mean it needs 
to be specified every time.  Reducing complexity means not taking on more 
than is necessary for the expected uses of a new protocol or extension to 
that protocol.

If, in the future, that additional capability is needed, a new document can 
be written as an extension to this one.  This allows, at least, for an 
implementation to be in 100% compliance with the earlier spec and choose 
not to do the additional function, which that implementation chooses not to 
offer.  Again, this reduces complexity to where it is needed, yet allows 
any implementation to add functionality by incorporating additional spec(s).

At 09:50 AM 7/15/2006 -0400, Henning Schulzrinne wrote:
>The trade-off is that for the simple on-path-can-read, the by- reference 
>approach incurs significant overhead, as the location