Re: [Geopriv] Location-by-value in a SIP Location Header

From: Hannes Tschofenig ^lt;Hannes.Tschofenig@gmx.net>
Date: Wed Jul 19 2006 - 08:59:51 EDT

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.

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

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:Martin.Thomson@andrew.com] Sent: 19 July 2006 00:15 To:
>> Rosen, Brian; Henning Schulzrinne Cc: sip@ietf.org;
>> geopriv@ietf.org 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:Brian.Rosen@neustar.biz] Sent: Tuesday, 18 July 2006
>>> 11:07 PM To: Henning Schulzrinne Cc: sip@ietf.org;
>>> geopriv@ietf.org 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:hgs@cs.columbia.edu] Sent: Tuesday, July 18, 2006 8:59 AM
>>> To: Rosen, Brian Cc: sip@ietf.org; geopriv@ietf.org 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 Geopriv@ietf.org
>>>> https://www1.ietf.org/mailman/listinfo/geopriv
>>>
>>>
>>> _______________________________________________ Geopriv mailing
>>> list Geopriv@ietf.org
>>> 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]
>>
>
>
> _______________________________________________ Geopriv mailing list
> Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv
>
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Wed, 19 Jul 2006 14:59:51 +0200

This archive was generated by hypermail 2.1.8 : Wed Jul 19 2006 - 09:22:56 EDT