Subject: RE: [Sip] Location header

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

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
Set of nodes that have permitted "need to know" location versus not

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.
 
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

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 14 Jul 2006 14:03:11 -0400

Hi Mike,

> 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.

> ahead of the immediate issues.
I will write a longer mail that describes the scenario I can see.

Ciao
Hannes