Subject: [Sip] RE: [Geopriv] Location-by-value in a SIP Location Header

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Wed, 19 Jul 2006 13:35:49 +0100

(As SIP WG chair)

Just to set some limits to this discussion, let me state where we are in the progression of this work item. Remember it is now being classed as urgent and we need to get an RFC out of the door, and the SIP chairs are working with the GEOPRIV chairs as to the quickest way to do this:

1)	The requirements in the document have been approved by the SIPPING group (a long time ago) and therefore we should not be inventing new requirements without a clear use case that has clear agreement.

2)	The SIP group have already identified that two mechanisms to support these requirements should be documented (e.g. the location by value in a body, and the location by reference in a header. These two mechanisms appear to support all the current requirements. In other words, SIP have agreed the technical solution, and we are in the stage of trying to document it.

3)	Using a data URL appears to add a third mechanism, if only because it will at least need to have a different set of security considerations documented for it. 

We should only be adding a third mechanism if:

a)	the existing mechanism can be shown not to meet all the requirements; or
b)	the use case where it offers advantages is clearly identified; and
c)	the compatibility issues are addressed (i.e. does the UAS need to support all of what is now three mechanisms or is there some other support requirement); and
d)	this can be shown as impossible to be discussed as a future extension.

Could I also suggest (in addition to the above) that if people want to proceed with this discussion, it would be appropriate to submit an i-d targeted at the SIP WG identifying the technical solution proposed (with as much completeness as is possible). And remember if you think this discussion is needed, it needs to occur quickly. 

regards

Keith

> -----Original Message-----
> From: Thomson, Martin [mailto:[email-masked]]
> Sent: 19 July 2006 00:15
> To: Rosen, Brian; Henning Schulzrinne
> Cc: [email-masked]; [email-masked]
> Subject: RE: [Geopriv] Location-by-value in a SIP Location Header
> 
> 
> If you want technically feasible, I can post a URI to the 
> list that includes a complete PIDF-LO with DSig.  It's a 
> little long though.
> 
> I'm not suggesting that this a good idea, but I see no reason 
> to prevent it.
> 
> > -----Original Message-----
> > From: Rosen, Brian [mailto:[email-masked]]
> > Sent: Tuesday, 18 July 2006 11:07 PM
> > To: Henning Schulzrinne
> > Cc: [email-masked]; [email-masked]
> > Subject: RE: [Geopriv] Location-by-value in a SIP Location Header
> > 
> > Perhaps some enlightenment is in order.  It's not clear to 
> me how you
> > dsig a Data uri in a Location header (or maybe you mean 
> dsig the pidf-lo
> > and put both the pidf-lo and the signature in the Data URI) somehow?
> > Are there some examples of this kind of thing elsewhere?
> > 
> > If we are ignoring technical arguments (as opposed to use 
> cases), it's
> > out of forgetfulness, and not willfulness.  What were you 
> referring to?
> > 
> > Brian
> > 
> > 
> > 
> > -----Original Message-----
> > From: Henning Schulzrinne [mailto:[email-masked]]
> > Sent: Tuesday, July 18, 2006 8:59 AM
> > To: Rosen, Brian
> > Cc: [email-masked]; [email-masked]
> > Subject: Re: [Geopriv] Location-by-value in a SIP Location Header
> > 
> > Brian, James:
> > 
> > this is simply false. If desired, XML-DSIG is a well-known and
> > accepted mechanism to achieve integrity. Such specification is no
> > longer than the MUST NOT that you propose. You are also willfully
> > ignoring the other technical arguments made as part of this 
> discussion.
> > 
> > Henning
> > 
> > On Jul 18, 2006, at 8:48 AM, Rosen, Brian wrote:
> > 
> > > There was a desire expressed by Hannes to provide a way 
> for a proxy to
> > > insert location-by-value.  He had proposed a SIP Location header
> > > specific way.  In IETF66, Henning suggested just using a data URI.
> > >
> > > Doing this may run afoul of the geopriv location privacy concerns,
> > > because there is no way for the user to sign the header to provide
> > > assurance that the PIDF, and specifically the retention and other
> > > policy
> > > bits are preserved.  Note that S/MIME provides sufficient 
> integrity
> > > protection for a body.  It's probably okay to use TLS per hop to
> > > provide
> > > privacy, but not integrity protection.  The authors 
> believe that there
> > > is no really compelling use case for this feature, and 
> the effort to
> > > define acceptable security mechanisms for location data 
> in a header
> > > would be a significant effort, further delaying the draft.
> > >
> > > We propose, therefore, to state in sip-location-conveyance, that a
> > > Data
> > > URI MUST NOT be used in the Location header until a 
> standards track
> > > RFC
> > > defines a suitable security mechanism to protect the PIDF in the
> > > header.
> > >
> > > Brian and James
> > >
> > > _______________________________________________
> > > Geopriv mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/geopriv
> > 
> > 
> > _______________________________________________
> > Geopriv mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/geopriv
> 
> --------------------------------------------------------------
> ----------------------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information.  
> If you have received it in error, please notify the sender
> immediately and delete the original.  Any unauthorized use of
> this email is prohibited.
> --------------------------------------------------------------
> ----------------------------------
> [mf2]
> 

_______________________________________________
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, 19 Jul 2006 14:59:51 +0200

Hi Keith,

Drage, Keith (Keith) wrote:
> (As SIP WG chair)
> 
> Just to set some limits to this discussion, let me state where we are
> in the progression of this work item. Remember it is now being
> classed as urgent and we need to get an RFC out of the door, and the
> SIP chairs are working with the GEOPRIV chairs as to the quickest way
> to do this:
> 
> 1)	The requirements in the document have been approved by the SIPPING
> group (a long time ago) and therefore we should not be inventing new
> requirements without a clear use case that has clear agreement.

At that time when the requirements were written we weren't even close to 
understand how the VoIP emergency service solutions would look like.

> 
> 2)	The SIP group have already identified that two mechanisms to
> support these requirements should be documented (e.g. the location by
> value in a body, and the location by reference in a header. These two
> mechanisms appear to support all the current requirements. In other
> words, SIP have agreed the technical solution, and we are in the
> stage of trying to document it.

Actually, as James pointed out the document supports implicitly three 
mechanisms:
* Location by Value in the Body (by end host)
* Location by Reference in the Header (by end host and by the proxy)
* Location by Reference in the Body (by end host)

In my scenario mail I wanted to point out that it is necessary to 
describe these 3 mechanisms and to discuss the difference between an end 
host and a proxy doing the processing.

> 
> 3)	Using a data URL appears to add a third mechanism, if only because
> it will at least need to have a different set of security
> considerations documented for it.

As I argued in my long list of scenarios I don't believe that the 
security properties are different compared to the approach where 
Location by Reference (with the reference being added by the proxy) is used.

> a)	the existing mechanism can be shown not to meet all the
> requirements; or b)	the use case where it offers advantages is
> clearly identified; and c)	the compatibility issues are addressed
> (i.e. does the UAS need to support all of what is now three
> mechanisms or is there some other support requirement); and d)	this
> can be shown as impossible to be discussed as a future extension.

Within the emergency work we got the feedback that a number of folks are 
interested in attaching location information per value by a SIP proxy.
I don't want them to do it without having us to look at the implications.

The 3GPP architecture wasn't quite detailed enough on this subject to 
judge whether they are one of the potential consumers. Are they? You 
know it better than I do. We still need to have a discussion on some of 
these issues in ECRIT. Ted provided excellent meeting minutes.

> 
> Could I also suggest (in addition to the above) that if people want
> to proceed with this discussion, it would be appropriate to submit an
> i-d targeted at the SIP WG identifying the technical solution
> proposed (with as much completeness as is possible). And remember if
> you think this discussion is needed, it needs to occur quickly.

Sure, we can do this.

Still, I believe it also helps the solutions offered in the current 
document if we discuss the security aspects. I am interested to have a 
good location conveyance document that covers a discussion about these 
issues.

In GEOPRIV we had a long discussion about the security aspects of 
retrieving location information from the access network using a layer 7 
protocol. If we ignore the details then there is a lot of similarity.

> regards

Ciao
Hannes

> 
> Keith
> 
> 
>> -----Original Message----- From: Thomson, Martin
>> [mailto:[email-masked]] Sent: 19 July 2006 00:15 To:
>> Rosen, Brian; Henning Schulzrinne Cc: [email-masked];
>> [email-masked] Subject: RE: [Geopriv] Location-by-value in a SIP
>> Location Header
>> 
>> 
>> If you want technically feasible, I can post a URI to the list that
>> includes a complete PIDF-LO with DSig.  It's a little long though.
>> 
>> I'm not suggesting that this a good idea, but I see no reason to
>> prevent it.
>> 
>> 
>>> -----Original Message----- From: Rosen, Brian
>>> [mailto:[email-masked]] Sent: Tuesday, 18 July 2006
>>> 11:07 PM To: Henning Schulzrinne Cc: [email-masked];
>>> [email-masked] Subject: RE: [Geopriv] Location-by-value in a
>>> SIP Location Header
>>> 
>>> and put both the pidf-lo and the signature in the Data URI)
>>> somehow? Are there some examples of this kind of thing elsewhere?
>>> 
>>> 
>>> -----Original Message----- From: Henning Schulzrinne
>>> [mailto:[email-masked]] Sent: Tuesday, July 18, 2006 8:59 AM
>>>  To: Rosen, Brian Cc: [email-masked]; [email-masked] Subject: Re:
>>> [Geopriv] Location-by-value in a SIP Location Header
>>> 
>>> Brian, James:
>>> 
>>>  longer than the MUST NOT that you propose. You are also
>>> willfully ignoring the other technical arguments made as part of
>>> this
>> 
>> discussion.
>> 
>>> Henning
>>> 
>>>> insert location-by-value.  He had proposed a SIP Location
>>>> header specific way.  In IETF66, Henning suggested just using a
>>>> data URI.
>>>> 
>>>> Doing this may run afoul of the geopriv location privacy
>>>> concerns, because there is no way for the user to sign the
>>>> header to provide assurance that the PIDF, and specifically the
>>>> retention and other policy bits are preserved.  Note that
>>>> S/MIME provides sufficient
>> 
>> integrity
>> 
>>>> protection for a body.  It's probably okay to use TLS per hop
>>>> to provide privacy, but not integrity protection.  The authors
>>>> 
>> 
>> believe that there
>> 
>>>> We propose, therefore, to state in sip-location-conveyance,
>>>> that a Data URI MUST NOT be used in the Location header until a
>>>> 
>> 
>> standards track
>> 
>>>> RFC defines a suitable security mechanism to protect the PIDF
>>>> in the header.
>>>> 
>>>> Brian and James
>>>> 
>>>> _______________________________________________ Geopriv mailing
>>>> list [email-masked] 
>>> _______________________________________________ Geopriv mailing
>>> list [email-masked] 
>> ---------------------------------- This message is for the
>> designated recipient only and may contain privileged, proprietary,
>> or otherwise private information. If you have received it in error,
>> please notify the sender immediately and delete the original.  Any
>> unauthorized use of this email is prohibited. 
>> ---------------------------------- [mf2]
>> 
> 
> 
> _______________________________________________ Geopriv mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/geopriv
> 
>

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 19 Jul 2006 09:32:15 -0400

Keith,

A couple of issues with your statements below:

- As you point out in #2, the SIP group has identified two mechanisms,
location by value in the body and location by reference in the header.  The
issue stems from the fact that location by reference is yet to be a
mechanism.  This has been mired down with technical discussions in GeoPriv
for a long time.

- Your list of reasons needs to be expanded to include 'the identified
mechanism has no technical solution'.

As you express, there are many reasons to complete this work quickly, but to
have a total solution it is important to examine these alternatives
mechanisms.  Like you, I certainly hope this comes to a resolution very
soon.

Thanks,

-Marc-

> 
> (As SIP WG chair)
> 
> Just to set some limits to this discussion, let me state 
> where we are in the progression of this work item. Remember 
> it is now being classed as urgent and we need to get an RFC 
> out of the door, and the SIP chairs are working with the 
> GEOPRIV chairs as to the quickest way to do this:
> 
> 1)	The requirements in the document have been approved by 
> the SIPPING group (a long time ago) and therefore we should 
> not be inventing new requirements without a clear use case 
> that has clear agreement.
> 
> 2)	The SIP group have already identified that two 
> mechanisms to support these requirements should be documented 
> (e.g. the location by value in a body, and the location by 
> reference in a header. These two mechanisms appear to support 
> all the current requirements. In other words, SIP have agreed 
> the technical solution, and we are in the stage of trying to 
> document it.
> 
> 3)	Using a data URL appears to add a third mechanism, if 
> only because it will at least need to have a different set of 
> security considerations documented for it. 
> 
> requirements; or
> c)	the compatibility issues are addressed (i.e. does the 
> UAS need to support all of what is now three mechanisms or is 
> there some other support requirement); and
> Could I also suggest (in addition to the above) that if 
> people want to proceed with this discussion, it would be 
> appropriate to submit an i-d targeted at the SIP WG 
> identifying the technical solution proposed (with as much 
> completeness as is possible). And remember if you think this 
> discussion is needed, it needs to occur quickly. 
> 
> regards
> 
> Keith
> 
> > > > policy bits are preserved.  Note that S/MIME provides sufficient
> > integrity
> > > > provide privacy, but not integrity protection.  The authors
> > believe that there
> > > > Data URI MUST NOT be used in the Location header until a
> > standards track
> > > > RFC
> > This message is for the designated recipient only and may contain 
> > privileged, proprietary, or otherwise private information.
> immediately 
> > and delete the original.  Any unauthorized use of this email is 
> > prohibited.