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

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 18 Jul 2006 08:59:13 -0400

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

_______________________________________________
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: Tue, 18 Jul 2006 15:18:26 +0200

I have to agree with Henning here.

You can sign the PIDF-LO, encode it and then put it into the data URI.

Even if you do not sign the PIDF-LO in the header it makes no difference 
since that's what you accomplish by sending a location reference (in the 
header) as well.

The argument that you can use authorization policies to decide who is 
allowed to resolve the reference to the location object is a bit 
misleading. Where do these policies come from?

Ciao
Hannes

Henning Schulzrinne wrote:
> 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
> 
>> assurance that the PIDF, and specifically the retention and other  policy
>> protection for a body.  It's probably okay to use TLS per hop to  provide
>> 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
>>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 18 Jul 2006 09:38:15 -0400

I find this discussion somewhat strange, given that draft-ietf-sip- 
location-conveyance-03 expends significant wording to detail all the  
cases where security (of any kind) is *not* to be used.  To pick just  
one

UAC-9  A UAC MUST be capable of transmitting a SIP request without
           protecting the PIDF-LO message body.  It is RECOMMENDED this
           not be the default configuration of any UA.  This requirement
           is orthogonal to the use of TLS or IPSec hop-by-hop between
           SIP elements.

I probably missed it, but I didn't see a 'MUST use S/MIME' or 'MUST  
use TLS or S/MIME for by-reference' in the document. Indeed, another  
message regarding this draft explicitly allowed HTTP as a retrieval  
mechanism, with no mention of HTTPS, S/MIME or other security wrapper.

The closest I see is

SIP endpoints SHOULD implement S/MIME to encrypt
    the PIDF-LO message body (part) end-to-end.

It then continues

    The SIPS-URI from [RFC3261] MUST be implemented for message  
protection (message
    integrity and confidentiality) and SHOULD be used when S/MIME is not
    used.

Once SIPS is used, there is no technical difference between by-value  
(without XML-DSIG), by-attachment and by-reference that I can find.

The draft leaves unexplained such details as to what key or even  
which crypto mechanisms the UAs should use to give proxies a chance  
to get at the data. It is also rather vague on whether  
"protecting" (in req. UAC-9) means encryption or integrity.

Thus, we should at least be consistent: If we don't want unsigned and/ 
or unencrypted location information, ever, the draft should state  
that. We can then discuss which mechanisms are appropriate in each of  
the delivery mechanisms (attachment, by value, by reference) and how  
we can get intermediaries access to this information. Just waving the  
S/MIME flag is no more useful than pulling out the "just do IPsec"  
security section template.

In summary: All three delivery mechanisms allow exactly equivalent  
security properties; the current draft does not mandate the use of  
such mechanisms for the two it specifies.

Henning

On Jul 18, 2006, at 9:18 AM, Hannes Tschofenig wrote:

> Even if you do not sign the PIDF-LO in the header it makes no  
> difference since that's what you accomplish by sending a location  
> reference (in the header) as well.
>
> The argument that you can use authorization policies to decide who  
> is allowed to resolve the reference to the location object is a bit