[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Ecrit] Joint Meeting with the 3GPP
I think it depends on precisely what is trying to be secured.
I have indicated several times what I believe needs to be secured at
least by the location provider, and I include the method parameter in
this. The <retention-expires> and <retransmission-allowed> elements are
policy that are ultimately set by the Target and not by the LIS, though
the LIS can provide guidance, consequently I don't see these as needing
to be included in the validation component of the location information
itself.
At this point I have only seen one proposal on the table for location
signing, so I can't comment on what other proposals may be capable of
addressing.
Cheers
James
> -----Original Message-----
> From: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org] On Behalf
Of
> James M. Polk
> Sent: Thursday, 15 May 2008 10:05 AM
> To: ecrit at ietf.org
> Subject: Re: [Ecrit] Joint Meeting with the 3GPP
>
> 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
------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.
If you have received it in error, please notify the sender
immediately and delete the original. Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www.ietf.org/mailman/listinfo/ecrit