Matt
in-line
At 04:06 PM 11/26/2007, 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.
Why isn't the message body not encrypted to make sure the Proxy doesn't?
What about the situation in which there are multiple proxies between
Alice and Bob, but only one will do anything good with the
location. What is "recipient=" set to, to ensure only the good proxy
reads the location body, and the no-so-good proxies obey the
parameter and don't look at the location?
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.
The RFC4119 defined PIDF-LO <retransmission-allowed> element (section
2.2.2) covers this already, for any proxy that reads the message
body. Why does this also need to be in a SIP header parameter?
What you describe above is a proxy that receives a SIP request, uses
location (without sending it to anywhere else) to determine its next
SIP hop, and forwards the message. Yet, this isn't the scenario you
want, is it?
That is, the intent of "recipient=endpoint" that if a call requires
location-based routing in order to succeed, then the call should fail.
With what error?
-09 defines lots of errors, but not one for this type of error - in
which the UAC knows how to correct it in a subsequent message it
doesn't want to fail for the same reason.
What is the SIP response, for that matter? It is not a timeout
message, and it is not a server refusal message. Is it simply a 400?
That said, if there is not a Geolocation-Error code, the UAC is blind
as to what to do.
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.
See, I think this is covered by SIP with the use of message body
encryption, or in 4119 with a <retransmission-allowed> element set to "no".
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.
-09 states the usage-rules of 3693 are to be maintained, and the
<retransmission-allowed> element set to "no" addresses this, IMO.
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.)
fair, but know that I'm a co-author of 3693, and I'm the one who put
in the exception for the emergency case text in that RFC.
(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.
yeah, encryption ensure this, a header parameter doesn't.
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.
that has been discussed previously, and is the URI that is in the
optional "ruleset-reference" element, that's within section 2.2.2 of RFC 4119.
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 is something that the SIP WG needed to be in on, since this is
not a Geopriv header parameter, it is a SIP header parameter. Given
that one SIP WG chair has already said this mechanism is doubtful to
work, there needs to be a more thorough discussion in SIP about this.
This seems to leave us with three options going forward:
Exactly who is "us" in the above?
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).
encryption of the message body does this, all of which is already
defined in SIP (RFC 3261), so this option is not really a choice
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.
How doesn't encryption do this?
BTW - the discussion needs to be in the Using Protocol's WG, where
the expertise is for that Using protocol.
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.)
This option is only satisfied when there is an agreeable SIP response
with Geolocation-Error code indication that informs the UAC why this
failure occurred, so it can make an informed decision about what the
next step is.
- 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:[EMAIL PROTECTED]
> 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: [EMAIL PROTECTED]
> ----------------------------------
>
>
>
> -----Messaggio originale-----
> Da: Dean Willis [mailto:[EMAIL PROTECTED]
> 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://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
_______________________________________________
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
