Re: R: R: a question about IETF draft location conveyance 09

James,

I do believe that the intent of Ted (as well as others in
the GEOPRIV 
working group, including myself) is that if a UAC specifies

"recipient=endpoint" then a compliant proxy will
not 'read' the location 
body. In particular, "recipient=endpoint"
indicates that a SIP proxy in 
the signaling path does not have permission to store the
location (or 
any derived information) for longer than is necessary to
forward the SIP 
message and does not have permission to send the location to
any third 
party (for any reason including location-based routing)
other than the 
next-hop SIP proxy. That is, the intent of
"recipient=endpoint" that if 
a call requires location-based routing in order to succeed,
then the 
call should fail.

Personally, I believe (and I think this is a point Ted was
trying to 
make) that a UAC must have a way to indicate that a location
is to be 
read by the endpoint and no one else. This goes back to RFC
3693 which 
dictates that a target must have a way of articulating
privacy rules and 
that using protocols must enforce those rules. In
particular, see 
requirements 7, 10 and 11 in RFC 3693. (Note that RFC 3693
explicitly 
makes an exception for the emergency case, and so this
discussion is in 
the context of non-emergency conveyance of location
information ... e.g. 
Pizza Hut.)

(Also note: there is always the issue that a malicious proxy
might not 
obey the wishes expressed by the UAC, but SIP is an
architecture in 
which there is implicit trust by the UAC that the proxy
acting on his 
behave properly and comply with all relevant specifications.

Implications of the SIP trust model are a topic for another
thread ... 
See for example:  
http://www1.ietf.org/mail-archive/web/sip/current
/msg20319.html)

Clearly, there are many mechanisms that satisfy the
desideratum that a 
target be able to indicate that its location is to be read
only by the 
SIP endpoint. For example, this desire could be encoded as a
privacy 
rule within the PIDF-LO and each SIP proxy could parse the
privacy rules 
in a PIDF-LO to determine the target's intent.
Alternatively, a 
location-by-value could be encrypted end-to-end; or location
could be 
conveyed by-reference using an LIS with certificate-based
access 
controls. The GEOPRIV working group discussed various
mechanisms last 
May (See the thread beginning with: 
http://www1.ietf.org/mail-archive/web/geopriv
/current/msg03521.html) and 
I believe there was rough consensus that the
"recipient=endpoint" 
mechanism described in the current conveyance draft was the
best 
mechanism for achieving the above desideratum.

This seems to leave us with three options going forward:

1) Deny the UAC the opertunity to indicate that location is
to be read 
only by the SIP endpoint. (That is, declare that SIP is not
a GEOPRIV 
using protocol in sense of RFC 3693).

2) Revisit the mechanism discussion and attempt to reach
consensus on a 
better mechanism for indicating that location is to be read
only by the 
SIP endpoint.

3) Craft text explaining that when the
"recipient=endpoint" parameter is 
used that a compliant SIP proxy is not to 'read' the
location 
information. (Note that this text should also indicate that
when 
"recipient=endpoint" is used that calls requiring
location-based routing 
will fail, and thus should only be used when call failure is
preferred 
over disclosure of location information to a routing
entity.)

- Matt Lepinski


James M. Polk wrote:

> This also gets back to one of my original points, does
SIP expect a 
> UAC to understand the topology of a message's path to
the ultimate 
> destination?
>
> Is Ted's intent of the "recipient=endpoint"
parameter to prevent 
> proxies from reading location in a message *and* a
"recipient=server" 
> parameter to prevent endpoints from reading location in
a message?
>
> Does the UAC always know that there are only proxies
between it and 
> the destination UAS?
>
> Does the UAC always understand a particular message
does or does not 
> need to be routed based on the location within the
request?
>
> Emergency services is an example of, always allow proxy
routing when 
> the UAC knows this is an emergency request.  But will
this be true for 
> all applications of location conveyance in the
(relatively near-term) 
> future?  I'm not so sure.
>
> The UAC has a mechanism for making location not
readable by proxies if 
> it doesn't want them to, use encryption e2e.  But this
has interesting 
> properties in at least one case, the a user calls the
nearest Pizza Hut.
>
> A UAC can encrypt its location in the first INVITE, but
if Pizza Hut 
> has a national or regional number, that routes on the
location of the 
> caller, the message will probably return a 493
(undecipherable).
>
> Does the UAC then send location to PizzaHut.com
unencrypted, knowing 
> this is required to get the INVITE to the right store?
>
> There are other usages of this, other than Pizza Hut.
>
> Does anyone have a suggestion for informative text that
can address 
> each of these two (or more) situations?
>
> At the moment, all text around "recipient="
is suggestive, and not 
> definitive, because of what Dean says below.
>
> That said, I could put something in like "unless a
future standards 
> track RFC says otherwise, the use of
"recipient=" parameter within any 
> locationValue is informative in nature", thus
leaving the door open 
> for ECRIT's phoneBCP doc to refine usage in the
emergency context, as 
> well as any other service defining document to do the
same type of 
> refinement.
>
> James
>
> At 08:28 AM 11/26/2007, DRAGE, Keith (Keith) wrote:
>
>> This just seems to me to be an inappropriate change
of RFC 2119 
>> language.
>>
>> If we really mean either of these, then we should
be specifying that 
>> the message is encrypted in the first place.
>>
>> What we probably mean is something informative
(because we cannot 
>> make a normative statement on what applications do
with the data), 
>> stating that usage of the message so tagged is
inappropriate because 
>> the sender did not intend it to be used for this
purpose.
>>
>> Regards
>>
>> Keith
>>
>> > -----Original Message-----
>> > From: daniel grotti [mailto:daniel.grottiunibo.it]
>> > Sent: Saturday, November 24, 2007 11:38 AM
>> > To: Dean Willis
>> > Cc: IETF SIP List; James M. Polk
>> > Subject: R: R: R: [Sip] a question about IETF
draft location
>> > conveyance 09
>> >
>> > I know.
>> > May be SHOULD NOT instead MUST NOT could be
better.
>> >
>> > daniel
>> >
>> >
>> > ----------------------------------
>> >        Daniel  Grotti
>> > D.E.I.S. - University of Bologna
>> > ----------------------------------
>> >        Via Venezia, 52
>> >   47023 Cesena (FC) - ITALY
>> > ----------------------------------
>> > e-mail: daniel.grottiunibo.it
>> > ----------------------------------
>> >
>> >
>> >
>> > -----Messaggio originale-----
>> > Da: Dean Willis [mailto:dean.willissoftarmor.com]
>> > Inviato: sab 24/11/2007 2.32
>> > A: daniel grotti
>> > Cc: Hannes Tschofenig; IETF SIP List; James M.
Polk
>> > Oggetto: Re: R: R: [Sip] a question about IETF
draft location
>> > conveyance 09
>> >
>> >
>> > On Nov 22, 2007, at 12:08 PM, daniel grotti
wrote:
>> >
>> > > Hi all,
>> > > so why don't emphasize this point in the
next draft, saying :
>> > > "Proxy server MUST not read messages
with "recipient=endpoint"
>> > > paramenter setted".
>> > > This is my point of you.
>> > >
>> > >
>> >
>> >
>> > because from a security standpoint, this
prohibition is meaningless.
>> > Intermediate nodes can and will read anything
that's in
>> > plaintext, and SOMEBODY will come up with a
rationale, in
>> > some context or another, for doing so.
>> >
>> > And has been pointed out, doing so does not
appear to create
>> > a compatibility problem. It doesn't break the
protocol. It
>> > might defeat security-through-obscurity. It
might be rude, or
>> > otherwise socially unacceptable. But those
don't qualify for
>> > a MUST level protocol prohibition.
>> >
>> > --
>> > Dean
>> >
>> >
>> >
>> >
>> >
_______________________________________________
>> > Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
>> > This list is for NEW development of the core
SIP Protocol Use
>> > sip-implementorscs.columbia.edu for
questions on current sip
>> > Use sippingietf.org for new
developments on the application of sip
>> >
>
>
>
> _______________________________________________
> Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP
Protocol
> Use sip-implementorscs.columbia.edu for
questions on current sip
> Use sippingietf.org for new developments on the
application of sip
>




_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

Matt Lepinski wrote:
> James,
> 
> I do believe that the intent of Ted (as well as others
in the GEOPRIV
> working group, including myself) is that if a UAC
specifies
> "recipient=endpoint" then a compliant proxy
will not 'read' the location
> body. In particular, "recipient=endpoint"
indicates that a SIP proxy in
> the signaling path does not have permission to store
the location (or
> any derived information) for longer than is necessary
to forward the SIP
> message and does not have permission to send the
location to any third
> party (for any reason including location-based routing)
other than the
> next-hop SIP proxy. That is, the intent of
"recipient=endpoint" that if
> a call requires location-based routing in order to
succeed, then the
> call should fail.

RFC 2119 defines MUST NOT. It says:

6. Guidance in the use of these Imperatives

   Imperatives of the type defined in this memo must be used
with care
   and sparingly.  In particular, they MUST only be used
where it is
   actually required for interoperation or to limit behavior
which has
   potential for causing harm (e.g., limiting
retransmisssions)  For
   example, they must not be used to try to impose a
particular method
   on implementors where the method is not required for
   interoperability.

7. Security Considerations

   These terms are frequently used to specify behavior with
security
   implications.  The effects on security of not
implementing a MUST or
   SHOULD, or doing something the specification says MUST
NOT or SHOULD
   NOT be done may be very subtle. Document authors should
take the time
   to elaborate the security implications of not following
   recommendations or requirements as most implementors will
not have
   had the benefit of the experience and discussion that
produced the
   specification

I can't see any failure of interoperability that results if
a proxy
"reads" the location body in violation of the
user's preference
described by "recipient=endpoint". I can also see
application scenarios
(ex: emergency) where applications can be assured of not
operating
unless the proxy violates this prohibition. So we've missed
the #6
guidance on "MUST NOT".

Can we justify a "MUST NOT" based on security
considerations? Given (as
in emergency) that there are applications in which the
application MUST
read the location, I don't think so.

What we really have is guidance that says, in normal
operation, proxies
don't include the location in application logic when
recipient=endpoint
is specified by the user, because in general this indicator
means that
the user is asking the proy to NOT include the location in
application
logic by attaching this modifier.

So we're at the level of a "SHOULD NOT", not a
"MUST NOT" as described
by RFC 2119. And even then I suspect the discussion of this
requirement
needs careful elucidation as to the problems resulting (or
likely to
result) if a proxy violates this requirement.

--
Dean



_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip