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
