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

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:

> 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
>> 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 protected]
>>> 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 protected] for questions on current sip
>> Use [email protected] 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 protected] for questions on current sip
Use [email protected] for new developments on the application of sip