-----Original Message-----
From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
Behalf Of Marc Linsner
Sent: Friday, 18 September 2009 3:29 AM
To: Brian Rosen
Cc: GEOPRIV
Subject: Re: [Geopriv] WG2LC:
draft-ietf-geopriv-held-identity-extensions-00.txt
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
------------------------------------------------------------------------------------------------
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]
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
