On Feb 8, 2010, at 11:43 PM, Thomson, Martin wrote:
> Section 1, OLD:
> ... The scope of an LCP is limited to the interaction between
> a Device and a LIS, and LCPs can guarantee the identity of
> Devices without additional authorization checks. Neither of
> these is true for HELD with identity extensions. Furthermore,
> identity extensions allow authorized third-party location
> recipients (LRs) to make requests that include identifiers to
> retrieve location information about a particular Device.
>
> NEW:
> ... The scope of an LCP is limited to the interaction between a
> Device and a LIS, and LCPs can guarantee the identity of
> Devices without additional authorization checks. A LIS
> identifies the Device making the LCP request using the source
> addressing on the request packets, using return routability to
> ensure that these identifiers are not spoofed.
>
> HELD with identity extensions allows a requester to explicitly
> provide identification details in the body of a location
> request. This means that location requests can be made by
> requesters other than the Device. Third-party location
> recipients (LRs) are able to make requests that include
> identifiers to retrieve location information about a particular
> Device.
I think your re-write loses the point about the case of a Device
requesting its own location, but the LIS still needing some check
other than return routability. I suggest the following tweak to the
second paragraph:
HELD with identity extensions allows a requester to explicitly
provide identification details in the body of a location
request. This means that location requests can be made in cases
where additional Device identity checks are necessary, and in cases
where the requester is not the Device itself.
> Section 3.1, OLD:
> Use of any identifier MUST only be allowed if it identifies a
> single Device at a particular time.
> NEW:
> Use of any identifier MUST only be allowed if it identifies a
> single Device at the time that location is determined. The LIS
> is responsible for ensuring that location information is
> correct for the Device, which includes ensuring that the Device
> is correctly identified. </t>
I think this would make more sense if the last sentence said:
The LIS
is responsible for ensuring that location information is
correct for the Device, which includes ensuring that the identifier
uniquely identifies the Device.
>
> Section 5, OLD:
> The security and privacy considerations of the base HELD
> protocol [HELD] are applicable, except as they relate to return
> routability.
> NEW:
> The security and privacy considerations of the base HELD
> protocol [HELD] are applicable. However, the considerations
> relating to return routability do not apply to third-party
> requests. Return routability might not apply to requests from
> Targets for their own location depending on the anti-spoofing
> mechanisms employed for the identifier.
Just for clarity, I think the last sentence should say, "Return
routability may also not apply. . ."
>
>> For example, it is not appropriate to provide Targets with their
>> own locations under these terms where a requester is
>> authenticated
>> by NAI and the supplied Device identity is a MAC address, even
>> if
>> that MAC address is currently registered with the network under
>> the given NAI. In this case, the requester might be requesting
>> from a different MAC address registered under the same NAI. The
>> correct way of gaining authorization is to establish a policy
>> that
>> permits this particular request as a third party request.
>>
>> [BA] Would this same statement be true in a network that only
>> allows a
>> single
>> simultaneous logon (such as WiMAX)?
>
> No, I'll have to make that clearer. I think that the new wording
> is better.
>
> Section 5.1, OLD:
> (above)
> NEW:
> It might be possible in some networks to establish multiple
> concurrent sessions using the same credentials. For instance,
> Devices with different MAC addresses might be granted
> concurrent access to a network using the same NAI. It is not
> appropriate to provide Targets with their own locations based
> on NAI in this case. Neither is it appropriate to authenticate
> a requester using NAI and allow that requester to provide an
> unauthenticated MAC address as a Device identifier, even if the
> MAC address is registered to the NAI.
>
Since this is about the Target-requesting-its-own-location case, I
think the last sentence above needs to say that explicitly:
Neither is it appropriate to authenticate a Target using NAI and allow
that Target to provide an unauthenticated MAC
address as its own Device identifier, even if the MAC address
is registered to the NAI.
Aliss
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
