Subject: RE: [Sip] Location header

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

Yeah, trust is fuzzy.  

But it all boils down to whether two parties have a means to pass
information securely to each other, while excluding others.  

The trust part is that party A gives it to party B "knowing" that B can
see it.  
A has to "trust" the B will do the right thing with the information.

Mike

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: Friday, July 14, 2006 2:03 PM
> To: Michael Hammer (mhammer)
> Cc: James Polk (jmpolk); [email-masked]; Henning Schulzrinne
> Subject: Re: [Sip] Location header
> 
> Hi Mike,
> 
> Michael Hammer (mhammer) wrote:
> > I wouldn't call them my requirements per se, I was just 
> trying to read 
> > between the lines of the discussion and extract why some folks were 
> > arguing for or against based on a statement or 
> requirement/assumption.
> > 
> > The inclusion v. reference and header v. body arguments aside, it 
> > seemed as though there were two dimensions here:
> > 
> > Set of nodes with which the Client has trust relationship versus not
> 
> I don't like the term trust since it is too fuzzy.
> Furthermore, we have multiple entities playing a role here: 
> Target, SIP Proxy, Location Recipient
> 
> > Set of nodes that have permitted "need to know" location versus not
> 
> I agree with this one.
> 
> > 
> > 1) Relationship + need to know
> > 2) No Relation + need to know
> > 3) Relationship + no need to know
> > 4) No Relation + need to know
> > 
> > I thought each of the above needed to be addressed.  But, my 
> > suggestion for 4) based on overlapping trust groups seemed to be 
> > deemed jumping ahead of the immediate issues.
> I will write a longer mail that describes the scenario I can see.
> 
> Ciao
> Hannes
> 
> >  
> > Mike
> > 
> > 
> > 
> >>-----Original Message-----
> >>From: Hannes Tschofenig [mailto:[email-masked]]
> >>Sent: Friday, July 14, 2006 10:50 AM
> >>To: Michael Hammer (mhammer)
> >>Cc: James Polk (jmpolk); [email-masked]; Henning Schulzrinne
> >>Subject: Re: [Sip] Location header
> >>
> >>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:
> >>
> >>>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