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
