Subject: RE: [Sip] Location header

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

Hannes,

I went back and re-read those requirements.  My problem here is that the
arguments for one approach versus another are not always covered by
those requirements.  In other words, a requirement is being inferred
from the general requirement "do privacy".  So, if someone argues that X
is not good enough because it doesn't meet Y, and Y is not a
requirement, then the argument is baseless.

Much of the debate surrounds assumptions about topology and trust
relationships (or not) between various nodes.

Disagreement on assumptions/requirements -> Disagreement on solutions.

Mike

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: Friday, July 14, 2006 10:20 AM
> To: Michael Hammer (mhammer)
> Cc: James Polk (jmpolk); [email-masked]; Henning Schulzrinne
> Subject: Re: [Sip] Location header
> 
> 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: Hannes Tschofenig <[email-masked]>
Date: Fri, 14 Jul 2006 10:49:47 -0400

Hi Mike,

I agree that the current document does not cover all the requirements 
and does not go into a deep discussion of the security/privacy aspects. 
I am happy to discuss these.

Maybe you could restate your requirements again in more details.

Ciao
Hannes

Michael Hammer (mhammer) wrote:
>>>>>>>>but can inFrom [email-masked] Fri Jul 14 11:18:09 2006
Date: Fri, 14 Jul 2006 10:49:47 -0400
From: Hannes Tschofenig <[email-masked]>
To: "Michael Hammer (mhammer)" <[email-masked]>
Subject: Re: [Sip] Location header
Cc: [email-masked], "James Polk \(jmpolk\)" <[email-masked]>,
	Henning Schulzrinne <[email-masked]>

Hi Mike,

I agree that the current document does not cover all the requirements 
and does not go into a deep discussion of the security/privacy aspects. 
I am happy to discuss these.

Maybe you could restate your requirements again in more details.

Ciao
Hannes

Michael Hammer (mhammer) wrote:
>>>the charactduce loops if changed in mid-stream and 
>>
>>incurs another 
>>