[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Ecrit] Joint Meeting with the 3GPP
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>, 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
scenario where a PSAP is handing out signed LOs, there wouldn't even
really be an RM in the distribution process. The PSAP would be the LG,
the access network would be the LS, and the endpoint would be the LR.
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.
Third, the RM is not necessarily an entity that specifies elements in a
PIDF-LO. 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. 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.
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.
This is the correct result, since the new LO actually wasn't signed by
the PSAP!
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