[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Ecrit] Joint Meeting with the 3GPP
Richard
]I want to first say this isn't an attack on you, and I have no
internal tone in this, or past, responses. Just to be clear]
comments in-line below
At 09:41 PM 5/14/2008, Richard Barnes wrote:
>James,
>
>(Let me note that I'm not advocating a solution, just saying that
>it's one way you could do things that's allowed by the specs. I
>don't really think it's a particularly good one, since it doesn't
>offer a significant advantage over just using LoST validation when
>necessary. In fact, LoST is probably faster in a lot of cases than
>cert validation!)
>
>I agree that signing a whole LO is a clumsy way of providing
>assurance about LI; it would be much preferable to have a selective
>signature over just the <location-info>,
to me, it would be preferable to have a PKI and there be a trust
relationship between the PSAP and the LG, but that's another leap of faith ;-)
Just doing this over the <location-info> is better than over the
PIDF-LO, but this has the problem of deciding for the Target (which
is at least involved in the RM process) which <location-info>
elements are included in the message. There are frequently going to
be times where where the LG/Target doesn't include <location-info>
elements it knows (i.e., could have included) for various
reasons. Perhaps the Target didn't want to include the seat number
it was at in the cube it was in, but include the floor on up...
>or even just a signed GML document. However, the concept of signed
>location is not inimical to the GEOPRIV model. Let me try to clarify
>a few misconceptions:
>
>First, there is not a requirement in 3693 that the Target be a Rule
>Maker, only that the Location Server respect the rules specified by
>the Location Generator (in the Location Object) and by the RM.
In the LbyV delivery of location, nearly all of the time, I believe
the UAC to be the LG
>In the scenario where a PSAP is handing out signed LOs, there
>wouldn't even really be an RM in the distribution process.
I think that is violating the 3693 process, one in which the RM makes
the policy decisions as to who gets what <location-info> about a
Target. What you describe here is a scenario in which both the
Target *and* the SP are not the RM. This was not envisioned in 3693.
>The PSAP would be the LG, the access network would be the LS, and
>the endpoint would be the LR.
I think this makes the PSAP the tail that wags the location dog for
all location usages. Do you agree?
>Second, in the PSAP-signed-location scenario, it's OK that there's
>no access controls, because the signed LOs are "raw" LOs -- they
>don't have any identity information, since the PSAP doesn't know who
>the LS is going to send them to. And it's a long-held GEOPRIV tenet
>that location information by itself (without identity) doesn't need
>the protections provided by privacy rules.
I'm not sure what you mean by ""raw" LOs", unless you mean raw
<location-info> for a given Target. To me that's just another form of
LI, making the delivery system to the Target another LCP (which is
not defined yet).
>Third, the RM is not necessarily an entity that specifies elements
>in a PIDF-LO.
oh, I think it is.
The RM decides who gets what location from an LG (on behalf of a
Target, if the Target is not the LG itself). I think this is the
short definition for an RM.
>Rules are propagated in two ways in the 3693 model, within the
>PIDF-LO (from the LG), and directly from the RM to the LS.
I think you're missing the part where the RM gets to decide the
policy of whether or not the Location Seeker even gets a response
(i.e., who gets location at all, and if a Seeker gets location, which
parts of the Target's location do they get). I think you are leaving
this (important) part out in your analysis.
>So the RM (or the Target acting as an RM) could specify access
>controls on a signed LO, but could not specify rules that would
>modify the LO returned.
This is broken IMO. The Target was and is always part of the RM
process, although they might not have final say over all the pieces
of the RM process.
In other words, there might be a SP rule that nothing below
street/street number be allowed in any location given out by the LG
(because that entity might not want too precise a location given out
for whatever reason). Yet, the SP generally wouldn't have a clue
about any individuals the Target has blacklisted. Both of these are
RM policies, yet I read that you don't want the RM to be either the
Target or SP (or enterprise?)...
I don't happen to agree with that model. It places complete control
for all location in the hands of PSAPs, and omits how large the
location universe will be that doesn't involve emergency services.'
Again, PSAPs shouldn't wag the location dog, IMO.
>Fourth, the Target can always use the signed LO to create a new LO
>with whatever location and privacy rules it wants -- it just can't
>then claim that the results were signed just because the original LO
>was signed.
I'm not sure yet what you mean by "it just can't then claim that the
results were signed", because in all scenarios other than what you're
talking about here, no one would be making any such claim -
principally because there's no means of informing in a SIP or PIDF-LO
element or header. This <claiming-to-be-valid> element doesn't exist
in the PIDF-LO, and it isn't defined in any SIP header either.
>This is the correct result, since the new LO actually wasn't signed
>by the PSAP!
But they aren't signed in any architecture either...
color me confused by your message
>Cheers,
>--Richard
>
>
>
>
>
>
>
>
>James M. Polk wrote:
>>At 08:35 PM 5/13/2008, Richard Barnes wrote:
>>>Certainly. I wasn't claiming that that was the recommendation of the
>>>IETF in any way, just that it was allowed. Using signed location in
>>>that way is not inconsistent with either location-conveyance or
>>>framework/phonebcp; it's one option that a jurisdiction could employ to
>>>assure the validity of static civic location information.
>>I believe you are advocating (explicit) in your solution here to
>>only that which disallows the UAC to modify a single XML element
>>within the PIDF-LO message body. Though, at the moment I don't
>>believe location-conveyance says this must be possible, I believe
>>this is likely mandatory (at least in spirit of Geopriv docs) but
>>for the mere fact that the owner of the UAC (i.e., the target)
>>needs to be a rulemaker (but not necessarily the only one) and
>>set/enter/include some of the elements (at least) such as <method>,
>><retransmission-allowed>, and <retention-expiry> - each of which
>>wouldn't be allowed if the whole PIDF-LO had a signature covering
>>it. Yet, these are not necessarily, and often cannot be known to
>>the LIS or PSAP at the time of the LCP response initially sending
>>the PIDF-LO to the UAC (DHCP client in this case).
>>What am I missing?
>>
>>>--RLB
>>>
>>>
>>>
>>>hannes.tschofenig at nsn.com wrote:
>>>>We did not agree todo anything close to (2).
>>>>
>>>>>-----Original Message-----
>>>>>From: ext Richard Barnes [mailto:rbarnes at bbn.com]
>>>>>Sent: 13 May, 2008 20:37
>>>>>To: fmenard at xittelecom.com
>>>>>Cc: Tschofenig Hannes (NSN - FI/Espoo); ecrit at ietf.org
>>>>>Subject: Re: [Ecrit] Joint Meeting with the 3GPP
>>>>>
>>>>>Francois,
>>>>>
>>>>>Let me answer your question in three parts:
>>>>>
>>>>>1. The spec allows the LbyV to be digitally signed. The
>>>>>location is carried as a MIME body in the SIP message, and
>>>>>thus can also be included in S/MIME form, signed, encrypted,
>>>>>or both. See Appendix B of
>>>>>draft-ietf-sip-location-conveyance-10 for an example.
>>><http://tools.ietf.org/html/draft-ietf-sip-location-conveyance->>
>>>10#appendix-B>
>>>>>2. The signer does not necessarily have to be the PSAP (though
>>>>>this is definitely allowed). In the model described in
>>>>>framework/phonebcp, the endpoint gets its location from a
>>>>>server in the access network to which it's connected, so when
>>>>>we talk about location signing, I usually imagine that it's
>>>>>signed by the access network's location server.
>>>>>However, if a PSAP wanted to, it could provide signed location
>>>>>objects to access networks in its jurisdiction that could then
>>>>>be handed out to endpoints, who would then send them back to the PSAP:
>>>>>
>>>>>+------------+
>>>>>| PSAP |<------(3)--------+
>>>>>+------------+ |
>>>>> | |
>>>>> (1) |
>>>>> | |
>>>>> V |
>>>>>+------------+ +----------+
>>>>>| Access Net |----(2)----->| Endpoint |
>>>>>+------------+ +----------+
>>>>>
>>>>>3. The IETF has not defined anything directly analogous to the
>>>>>MSAG, in the sense of a consolidated database (in fact, I
>>>>>believe that the NENA
>>>>>i3 architecture does away with the MSAG entirely). However,
>>>>>there is a location validation function provided by the LoST protocol:
>>>>><http://tools.ietf.org/html/draft-ietf-ecrit-lost-09#section-8.3.5>
>>>>>There is no current standard way for a location to be marked
>>>>>as valid (this could be hard, since notions of validity vary
>>>> >from place to place), but a PSAP could easily verify that a
>>>>>location is valid using LoST.
>>>>>
>>>>>Cheers,
>>>>>--Richard
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>Francois Menard wrote:
>>>>>>Does the spec calls for digitally signing the LbyV by the PSAP, such
>>>>>>that the PSAP can recognize an LbyV as being signed by itself as
>>>>>>dispatch-able (i.e. MSAG-VALID), msag=master street address guide.
>>>>>>
>>>>>>F.
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Richard Barnes [mailto:rbarnes at bbn.com]
>>>>>>Sent: 13 mai 2008 07:39
>>>>>>To: Francois Menard
>>>>>>Cc: <hannes.tschofenig at nsn.com>; ecrit at ietf.org
>>>>>>Subject: Re: [Ecrit] Joint Meeting with the 3GPP
>>>>>>
>>>>>>Francois,
>>>>>>
>>>>>>I don't have a complete list, but to answer your specific question,
>>>>>>location is transmitted by value from the endpoint to the
>>>>>PSAP in the
>>>>>>SIP INVITE message using the mechanism described in
>>>>>>draft-ietf-sip-location-conveyance.
>>>>>>
>>>>>>--Richard
>>>>>>
>>>>>>
>>>>>>
>>>>>>Francois Menard wrote:
>>>>>>>So that we may come prepared to this meeting, could you
>>>>>provide links
>>>>>>>to the latest specs, particularly the transmission of location by
>>>>>>>value from the end-point to the PSAP.
>>>>>>>
>>>>>>>F.
>>>>>>>
>>>>>>>
>>>>>>>On 13-May-08, at 2:58 AM, <hannes.tschofenig at nsn.com>
>>>>>><hannes.tschofenig at nsn.com
>>>>>>> > wrote:
>>>>>>>
>>>>>>>>Hi all,
>>>>>>>>
>>>>>>>>We would like to inform you that we are currently planning to
>>>>>>>>organize a meeting with the 3GPP around August 2008. The
>>>>>main topic
>>>>>>>>for our discussion is the harmonization of the 3GPP and the IETF
>>>>>>>>emergency services architecture.
>>>>>>>>
>>>>>>>>We will distribute more details as soon as they are available.
>>>>>>>>
>>>>>>>>Ciao
>>>>>>>>Hannes & Marc
>>>>>>>>
>>>>>>>>_______________________________________________
>>>>>>>>Ecrit mailing list
>>>>>>>>Ecrit at ietf.org
>>>>>>>>https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>--
>>>>>>>Francois Menard
>>>>>>>fmenard at xittelecom.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>_______________________________________________
>>>>>>>Ecrit mailing list
>>>>>>>Ecrit at ietf.org
>>>>>>>https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>
>>>>>>
>>>
>>>_______________________________________________
>>>Ecrit mailing list
>>>Ecrit at ietf.org
>>>https://www.ietf.org/mailman/listinfo/ecrit
>>_______________________________________________
>>Ecrit mailing list
>>Ecrit at ietf.org
>>https://www.ietf.org/mailman/listinfo/ecrit
_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www.ietf.org/mailman/listinfo/ecrit