Brian
On 9/17/09 1:29 PM, "Marc Linsner" <mlinsner@cisco.com> wrote:
> So, this begs the question. Has NENA examined which protocol is suitable
> for their task and made a choice?
>
> -Marc-
>
>
> On 9/17/09 1:15 PM, "Brian Rosen" <br@brianrosen.net> wrote:
>
>> Correct. They would be needed if the LIS wished to use HELD as opposed to
>> presence.
>>
>> Presence is a good example of OBO with appropriate privacy considerations
>> handled. The presence server is an LS, it requires appropriate
>> authentication and it must enforce the rules. The resulting PIDF would
>> include the rules.
>>
>> Brian
>>
>>
>> On 9/17/09 12:39 PM, "Marc Linsner" <mlinsner@cisco.com> wrote:
>>
>>> That doesn't necessarily require identity extensions. A subscribe/notify to
>>> tel-number@esinet-lis.com will provide the same function.
>>>
>>> -Marc-
>>>
>>>
>>> On 9/17/09 12:31 PM, "Brian Rosen" <br@brianrosen.net> wrote:
>>>
>>>> NENA has a use case for identity extensions.
>>>>
>>>> When a legacy TDM wireline network is transitioned to an IP based, ecrit
>>>> compatible emergency response systems (we call that an Emergency Services
>>>> IP
>>>> network or ESInet), the identifier for location remains as it is today, a
>>>> telephone number. The LIS stores location keyed by telephone number, and
>>>> the emergency call specific function of the gateway that connects the
>>>> legacy
>>>> wireline network to the ESInet must query the LIS using the telephone
>>>> number
>>>> to get location to put on the SIP call following the rules in -phonebcp.
>>>> The gateway is a trusted entity, it is the UA (although it's not really the
>>>> target) and this is the emergency case, so the ruleset doesn't apply.
>>>>
>>>> Brian
>>>>
>>>>
>>>> On 9/17/09 11:20 AM, "Marc Linsner" <mlinsner@cisco.com> wrote:
>>>>
>>>>> Richard,
>>>>>
>>>>> In the context of identity-extensions, for the use case of a target
>>>>> discovering it's location (TDIL), which is a better descriptor than LCP,
>>>>> the
>>>>> same functions of authenticate and authorize MUST be deployed before the
>>>>> release of location information as is employed with the third-party or OBO
>>>>> use cases. The actual mechanism for authentication might differ, but none
>>>>> the less, just because the TDIL policy is clear and well-understood does
>>>>> not
>>>>> negate the need to authenticate the requestor, no matter how difficult
>>>>> that
>>>>> task may be. You can't apply policy until you know who you are talking
>>>>> to.
>>>>> IOW, from a trust relationship pov, the LS/LIS is simply stating, 'Sure
>>>>> Mr.
>>>>> Target, you can have your location information as soon as I verify you are
>>>>> indeed Mr. Target'.
>>>>>
>>>>> To create any mechanism with a lesser degree of
>>>>> authentication/authorization
>>>>> is sacrificing the security of the privacy for the end-user that this work
>>>>> group was created to protect.
>>>>>
>>>>> I also find zero motivation to solve these issues with threats that if we
>>>>> don't do it someone else will. This threat has always existed.
>>>>>
>>>>> I'm also not sure that NENA is asking for third-party/OBO, I believe it's
>>>>> SPs asking for it. NENA simply wants location included with call setup.
>>>>>
>>>>> -Marc-
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 9/16/09 9:20 PM, "Richard Barnes" <rbarnes@bbn.com> wrote:
>>>>>
>>>>>> (Reposting under the correct thread)
>>>>>>
>>>>>> <individual-hat xmlns="urn:ietf:params:xml:ns:hats">
>>>>>>
>>>>>> I'm going to try to frame this debate a little bit.
>>>>>>
>>>>>> Let's start from the assumption that identity extensions are necessary
>>>>>> for third-party/OBO queries. My impression is that people are OK with
>>>>>> the case where identifiers are included in queries from specific,
>>>>>> authenticated, authorized entities (e.g., public safety authorities).
>>>>>>
>>>>>> Now, we want to make sure that these extensions are not abused to gain
>>>>>> unauthorized access to location. So if we were to put forward a
>>>>>> document defining identity extensions for third-party queries. We would
>>>>>> then have two options:
>>>>>> 1. Forbid the use of identifiers in LCP requests, or
>>>>>> 2. Assume that LCP usage is inevitable and require verification
>>>>>>
>>>>>> Consider case (2) first. The recommendation that we would want to make
>>>>>> is for the LS to verify that the identifier actually corresponds to the
>>>>>> target. However, the identifiers in question will necessarily not be
>>>>>> IP-layer identifiers (or else there would be no problem). That means
>>>>>> that we can't define an Internet-standard mechanism for this
>>>>>> verification -- mechanisms will have to be network-specific. So we're
>>>>>> left making a vague statement that has to be re-interpreted for each
>>>>>> network (or type of network). Not very satisfying, but basically all
>>>>>> that can be done.
>>>>>>
>>>>>> Now, in case (1), we have to come up with some standards language to
>>>>>> accomplish this prohibition. Following our general goal, we would want
>>>>>> something like, "The LS MUST authenticate requestors and apply
>>>>>> authorization policy to requests containing identity extensions."
>>>>>> However, what I've been calling the LCP Policy -- "For every location
>>>>>> object, the Target of that LO is authorized" -- is a valid policy. (You
>>>>>> might even be able to express it in common-policy, if you had one entry
>>>>>> per LO.) And that puts us back into case (2).
>>>>>>
>>>>>> This argument seems to me to imply that if we are to enable support for
>>>>>> the third party requests that the emergency services community is
>>>>>> requesting, then we will be stuck with the LCP usage as well, for which
>>>>>> we can write recommendations that are unsatisfactory, but possibly clear
>>>>>> enough for implementors to understand. If one accepts this implication,
>>>>>> we're left with a choice:
>>>>>> 1. Provide support for third party requests and do our best on LCP use
>>>>>> 2. Do nothing at all
>>>>>>
>>>>>> My impression is that if we follow course (2) and do nothing, then the
>>>>>> parties that are asking for us to do something (NENA, NICC, etc.) will
>>>>>> invent something anyway. Following course (1) would then not create
>>>>>> anything that wouldn't be created anyway, and it would have the
>>>>>> potential benefits of increasing interoperability and allowing this
>>>>>> group to have some say over the privacy constraints.
>>>>>>
>>>>>> So, to sum all that up, I think we should aim for some recommendations
>>>>>> and privacy constraints on LCP usage of identifiers and move on.
>>>>>>
>>>>>> --Richard
>>>>>>
>>>>>> </individual-hat>
>>>>>>
>>>>>>
>>>>>> Alissa Cooper wrote:
>>>>>>> All,
>>>>>>>
>>>>>>> In an effort to generate discussion and progress a bit more efficiently
>>>>>>> in the WG, Richard and I would like to experiment with something we're
>>>>>>> calling "working group second-to-last call" (WG2LC). We think the
>>>>>>> existing structures that set deadlines for comment (WGLC, IETF LC, etc.)
>>>>>>> are rather effective at motivating people to take a look at documents of
>>>>>>> interest, so we'd like to extend that concept a bit further. WG2LC is
>>>>>>> what it sounds like: an informal call for comments with a deadline,
>>>>>>> preceding the issuance of an official WGLC. The idea is to air some
>>>>>>> discussion about a document before it reaches the point of being ready
>>>>>>> for WGLC.
>>>>>>>
>>>>>>> As a first experiment for WG2LC, consider this a working group
>>>>>>> second-to-last call for comments on
>>>>>>>
>>>>>>> draft-ietf-geopriv-held-identity-extensions-00.txt
>>>>>>>
>>>>>>> Please send your comments about this document to the list by 23
>>>>>>> September 2009.
>>>>>>>
>>>>>>> Alissa
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Geopriv mailing list
>>>>>>> Geopriv@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/geopriv
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Geopriv mailing list
>>>>>> Geopriv@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/geopriv
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Geopriv mailing list
>>>>> Geopriv@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/geopriv
>>>>
>>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Geopriv mailing list
>> Geopriv@ietf.org
>> https://www.ietf.org/mailman/listinfo/geopriv
>
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
