<http://escholarship.org/uc/item/0rp834wf>
--Martin
P.s. I've emailed the authors to rectify the little misunderstanding about what an LCP is. :)
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Title : Discovering the Local Location Information Server (LIS)
Author(s) : M. Thomson, J. Winterbottom
Filename : draft-ietf-geopriv-lis-discovery-14.txt
Pages : 18
Date : 2010-02-28
Discovery of the correct Location Information Server (LIS) in the
local access network is necessary for devices that wish to acquire
location information from the network. A method is described for the
discovery of a LIS in the access network serving a device. Dynamic
Host Configuration Protocol (DHCP) options for IP versions 4 and 6
are defined that specify a domain name. This domain name is then
used as input to a URI-enabled NAPTR (U-NAPTR) resolution process.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-lis-discovery-14.txt
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
On Feb 17, 2010, at 12:50 AM, Thomson, Martin wrote:
>
>
>>> If this IP address matches the source IP address of the HELD
>>> location request, the location request can be authorized under the
>>> LCP policy (see Section 5.1); otherwise, the request MUST have been
>>> authorized as a third-party request.
>>
>> It seems a bit odd to place a normative requirement on something that
>> happened in the past ("MUST have been"). It's not clear that you need
>> to be normative at all since you're talking about an authorization
>> check that already happened. Here's a suggestion:
>>
>> If this IP address matches the source IP address of the HELD
>> location request, the location request can be authorized under the
>> LCP policy (see Section 5.1). Otherwise, the request must be treated
>> as a third-party request.
>
> Again, a good point. So few people have the ability to change the
> past.
>
> Are we back to using lowercase "must" for any particular reason? Is
> there a particular reason that you didn't choose to use "MUST"?
The first sentence of the paragraph says, "The AAA server consults
network policy and if the request is permitted, . . .." So I don't
really know that it makes sense to later be normative about the
decision that the server has to make, since it already checked if the
request was permitted. Does that make sense?
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
I did not intend for it to disappear.
>>> Just for clarity, I think the last sentence should say, "Return
>> routability may also not apply. . ."
>
> "might" rather than "may" to avoid confusion with normative text, or
> is this an intentional shading of meaning?
>
"Might" is better, agreed.
Alissa
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
You can find this draft at:
http://www.ietf.org/internet-drafts/draft-thomson-geopriv-relative-location-
00.txt
I draw your attention to the editor's note in Section 5 starting on the
bottom of page 7.
The author team is eager to discuss your comments on this draft, which we
all feel will provide a useful capability for many systems.
Brian
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Thanks, Cullen & Robert
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Good catch.
Peter
--
Peter Saint-Andre
https://stpeter.im/
This document is not ready for publication. The complaint is not so much a technical one as it is an incompleteness one. The document claims to define XML, but does not.
I sent the following email, which includes the details, to the GEOPRIV WG list last week:
<http://www.ietf.org/mail-archive/web/geopriv/current/msg08321.html>
--Martin
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
- 'Prefix elements for Road and House Numbers in PIDF-LO '
<draft-ietf-geopriv-prefix-00.txt> as an Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2010-03-10. Exceptionally,
comments may be sent to iesg@ietf.org instead. In either case, please
retain the beginning of the Subject line to allow automated sorting.
The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-prefix-00.txt
IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=19543&rfc_flag=0
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
- 'Filtering Location Notifications in the Session Initiation Protocol
(SIP) '
<draft-ietf-geopriv-loc-filters-09.txt> as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2010-03-10. Exceptionally,
comments may be sent to iesg@ietf.org instead. In either case, please
retain the beginning of the Subject line to allow automated sorting.
The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-loc-filters-09.txt
IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14539&rfc_flag=0
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Title : Use of Device Identity in HTTP-Enabled Location Delivery (HELD)
Author(s) : J. Winterbottom, et al.
Filename : draft-ietf-geopriv-held-identity-extensions-03.txt
Pages : 29
Date : 2010-02-23
When a Location Information Server receives a request for location
information (using the locationRequest message), described in the
base HTTP Enabled Location Delivery (HELD) specification, it uses the
source IP address of the arriving message as a pointer to the
location determination process. This is sufficient in environments
where the location of a Device can be determined based on its IP
address.
Two additional use cases are addressed by this document. In the
first, location configuration requires additional or alternative
identifiers from the source IP address provided in the request. In
the second, an entity other than the Device requests the location of
the Device.
This document extends the HELD protocol to allow the location request
message to carry Device identifiers. Privacy and security
considerations describe the conditions where requests containing
identifiers are permitted.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-held-identity-extensions-03.txt
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--Martin
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Whoops, let me correct that after a sixth read. IDNA distinguishes between U-label and NR-LDH-label. If we only allow U-label, we can't use simple domain names like "example.com". The text becomes:
This <xref target="I-D.ietf-idnabis-defs">IDN-aware domain name slot</xref> is formed from any sequence of valid U-labels or NR-LDH-labels.
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Inline...
> -----Original Message-----
> From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]
> Sent: Wednesday, 17 February 2010 5:49 PM
> To: Thomson, Martin; geopriv@ietf.org
> Subject: RE: [Geopriv] WGLC: draft-ietf-geopriv-held-identity-
> extensions
>
> NEW:
> A LIS can authorize location configuration requests using a policy
> that allows Devices to acquire their own location (see Section 4.1).
> If an unauthorized third-party falsifies addressing on request packets
> to match the provided Device identity, the request might be erroneously
> authorized under this policy. Requests containing Device identity must
> not be authorized using this policy unless specific measures are taken
> to prevent this type of attack.
>
> [BA] Since in HELD return routability is presumed to ensure against IP
> address spoofing of HTTP over TCP requests, I'm assuming that this is
> not the address falsification being referred to here, right? I guess
> that leaves MAC address and the cellular identifiers.
That's correct. I don't know how much more detail is really helpful in the introduction. I want to strike a balance between getting the statements accurate and avoiding unnecessary detail.
However, this statement is also correct for IP addresses. We already have the "specific measures"; that is: return routability, as described in HELD :)
> This IDN-aware domain name slot [I-D.ietf-idnabis-defs] MAY be
> formed
> from any sequence of valid labels (A-label, U-labels or NR-LDH-
> label). Binary or bit string labels cannot be represented in this
> domain name slot.
>
> [BA] If the domain slot is IDN-aware, wouldn't it make sense to prefer
> a U-label? Also, I don't think you want to allow an FQDN that is a
> mixture of U-labels and A-labels.
I've read the relevant sections 5 times now. I think that you are right, U-label is what we're looking for. The fact that you _can_ mix label types, doesn't mean that you should.
--Martin
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
The webcast (and full list of witnesses) should be available here: http://energycommerce.house.gov/index.php?option=com_content&view=article&id=1901:energy-and-commerce-joint-subcommittee-hearing-on-the-collection-and-use-of-location-information-for-commercial-purposes&catid=122:media-advisories&Itemid=55
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Yes, I think that would cover all my issues.
Many thanks,
Adrian
----- Original Message -----
From: "Thomson, Martin" <Martin.Thomson@andrew.com>
To: "Adrian Farrel" <Adrian.Farrel@huawei.com>; <iesg@ietf.org>
Cc: <geopriv@ietf.org>
Sent: Friday, February 19, 2010 2:24 AM
Subject: RE: DISCUSS and COMMENT: draft-ietf-geopriv-lis-discovery
> Hi Adrian,
>
> I had a discussion on this point some time back with our WG chair. He had
> exactly the same comment.
>
> This issue can be complicated. Using DDDS with DNS can produce multiple
> results. The means of discriminating between DDDS results is the same as
> for DNS. It just that this happens at a different layer. Note also that
> choices occur at multiple stages of the iterative process, not just the
> terminal stage.
>
> If multiple values are provided in DNS, load distribution seems to be the
> most common reason. Any algorithm that advocates "going around for
> another try" is only going to make this worse by having clients hit every
> server, especially for "notLocatable" responses.
>
> The good news is that a DDDS implementation should hide this complexity
> and produce only one answer. If you accept the above, altering DDDS
> resolver behaviour is probably unnecessary.
>
> My conclusion was that this sort of detail is more likely to do harm than
> good. Instead, relying on an understanding of U-NAPTR and DDDS would be
> preferable. I did prepare some text for this case, as follows:
>
>>>
>
> OLD:
> Diagram (step 3, N goes to step 1)
> NEW:
> Diagram (step 3, N goes to step 2)
>
> Section 4, between two paragraphs after the figure, ADD:
> U-NAPTR resolution might produce multiple results from each iteration of
> the algorithm. Order and preference values determine which value is
> chosen. A device MAY attempt to use alternative choices if the first
> choice is not successful. However, if a request to the resulting URI
> produces a HELD "notLocatable" response, or equivalent, the device SHOULD
> NOT attempt to use any alternative choices from the same domain name.
>
> <<
>
> Thanks for the text suggestion, that's much clear. I'll fix the nits.
>
> --Martin
>
>> -----Original Message-----
>> From: Adrian Farrel [mailto:adrian.farrel@huawei.com]
>> Sent: Friday, 19 February 2010 12:56 AM
>> To: iesg@ietf.org
>> Cc: geopriv-chairs@tools.ietf.org; draft-ietf-geopriv-lis-
>> discovery@tools.ietf.org
>> Subject: DISCUSS and COMMENT: draft-ietf-geopriv-lis-discovery
>>
>> Discuss:
>> A relatively small Discuss that I hope will cause you no trouble.
>>
>> It might be valuable to note that there could be more than one LIS
>> for any access network and that the device makes the choice based on
>> local policy.
>>
>> In particular, in step 2 of figure 1 the result may be more than one
>> URI. Or the "N" path from step 3 should return to step 2.
>>
>> Comment:
>> Section 2.2 begins
>>
>> A Device MUST avoid performing LIS discovery over a VPN network
>> interface unless discovery on other interfaces is unsuccessful. A
>> LIS discovered in this way is unlikely to have the information
>> necessary to determine an accurate location.
>>
>> I find this use of RFC 2119 a little vague. In trying to parse it, I
>> think I concluded...
>>
>> A device MUST NOT attempt LIS discovery over a VPN network interface
>> until it has attempted and failed to perform discovery on all other
>> non-VPN interfaces. A device MAY perform discovery over a VPN
>> network
>> interface if it has first attempted discovery on non-VPN interfaces,
>> but a LIS discovered in this way is unlikely to have the information
>> necessary to determine an accurate location.
>>
>> Note s/Device/device/
>>
>> ---
>>
>>
>> Nits:
>>
>> Section 1
>>
>> for providing that location information to devices with an access
>> network. The LIS uses knowledge of the access network and its
>>
>> This is hard to parse and it is only when we get to the definitions
>> later that we discover it means:
>>
>> for providing that location information to devices with attached
>> access networks used to provide Internetr access. The LIS uses
>> knowledge of the access network and its
>>
>>
>> ---
>>
>> Section 1.1
>> The bulk of DHCP information is largely static
>>
>> That looks like a double vagueness :-)
>> Either
>> The bulk of DHCP information is static
>> Or
>> The DHCP information is largely static
>
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
There is an open issue that I think has been forgotten:
<http://www.ietf.org/mail-archive/web/geopriv/current/msg07475.html>
The document claims to define XML, but does not. I apologise for not reminding the editor during WGLC. I forgot to check, assuming that changes had been made after the above response.
I also have a minor comment to add. The document structure is strange. The two top level sections are entitled "Terminology" and "References". All the actual content is found in subsections of the "Terminology" section. I note that Hannes' WGLC comment makes the same point.
--Martin
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
I had a discussion on this point some time back with our WG chair. He had exactly the same comment.
This issue can be complicated. Using DDDS with DNS can produce multiple results. The means of discriminating between DDDS results is the same as for DNS. It just that this happens at a different layer. Note also that choices occur at multiple stages of the iterative process, not just the terminal stage.
If multiple values are provided in DNS, load distribution seems to be the most common reason. Any algorithm that advocates "going around for another try" is only going to make this worse by having clients hit every server, especially for "notLocatable" responses.
The good news is that a DDDS implementation should hide this complexity and produce only one answer. If you accept the above, altering DDDS resolver behaviour is probably unnecessary.
My conclusion was that this sort of detail is more likely to do harm than good. Instead, relying on an understanding of U-NAPTR and DDDS would be preferable. I did prepare some text for this case, as follows:
>>
OLD:
Diagram (step 3, N goes to step 1)
NEW:
Diagram (step 3, N goes to step 2)
Section 4, between two paragraphs after the figure, ADD:
U-NAPTR resolution might produce multiple results from each iteration of the algorithm. Order and preference values determine which value is chosen. A device MAY attempt to use alternative choices if the first choice is not successful. However, if a request to the resulting URI produces a HELD "notLocatable" response, or equivalent, the device SHOULD NOT attempt to use any alternative choices from the same domain name.
<<
Thanks for the text suggestion, that's much clear. I'll fix the nits.
--Martin
> -----Original Message-----
> From: Adrian Farrel [mailto:adrian.farrel@huawei.com]
> Sent: Friday, 19 February 2010 12:56 AM
> To: iesg@ietf.org
> Cc: geopriv-chairs@tools.ietf.org; draft-ietf-geopriv-lis-
> discovery@tools.ietf.org
> Subject: DISCUSS and COMMENT: draft-ietf-geopriv-lis-discovery
>
> Discuss:
> A relatively small Discuss that I hope will cause you no trouble.
>
> It might be valuable to note that there could be more than one LIS
> for any access network and that the device makes the choice based on
> local policy.
>
> In particular, in step 2 of figure 1 the result may be more than one
> URI. Or the "N" path from step 3 should return to step 2.
>
> Comment:
> Section 2.2 begins
>
> A Device MUST avoid performing LIS discovery over a VPN network
> interface unless discovery on other interfaces is unsuccessful. A
> LIS discovered in this way is unlikely to have the information
> necessary to determine an accurate location.
>
> I find this use of RFC 2119 a little vague. In trying to parse it, I
> think I concluded...
>
> A device MUST NOT attempt LIS discovery over a VPN network interface
> until it has attempted and failed to perform discovery on all other
> non-VPN interfaces. A device MAY perform discovery over a VPN
> network
> interface if it has first attempted discovery on non-VPN interfaces,
> but a LIS discovered in this way is unlikely to have the information
> necessary to determine an accurate location.
>
> Note s/Device/device/
>
> ---
>
>
> Nits:
>
> Section 1
>
> for providing that location information to devices with an access
> network. The LIS uses knowledge of the access network and its
>
> This is hard to parse and it is only when we get to the definitions
> later that we discover it means:
>
> for providing that location information to devices with attached
> access networks used to provide Internetr access. The LIS uses
> knowledge of the access network and its
>
>
> ---
>
> Section 1.1
> The bulk of DHCP information is largely static
>
> That looks like a double vagueness :-)
> Either
> The bulk of DHCP information is static
> Or
> The DHCP information is largely static
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
3958 uses the _input_ to DDDS to validate the authenticated identity of the server, even if the server is at a different domain.
LoST specifically states that the name in the _output_ of DDDS is used to validate server identity. This makes a lot of sense for LoST because an N-to-1 deployment arrangement is expected. But there's a problem with 3958 that isn't clear.
The vagueness in Sec8 should be fixed, but the problem is thus - I can build a discovery element, then take the output of that and feed it to an HTTP stack. Normally, the only input the HTTP client takes is a URL. The server is authenticated against the domain name in the URL. While it is possible in some implementations to provide your own server authentication logic, very many implementations do not allow this. Given the current implementations of HELD clients, I am aware of maybe only one (a Java-based client) that could possibly authenticate based on a different name than what was in the URL.
The 3958 choice was also going to place some cumbersome restrictions on those deploying a LIS into an ISP. Small businesses and home customers are expected to rely on ISP-provided location infrastructure. For the ISP, this could mean that adding new customers requires that they add new names to the subjectAltName of their LIS certificate. The alternative is that the customers report the name of the ISP in their DHCP options, which is probably easier, but less friendly to those people; in most cases depends on access to the new option.
If the IESG believes that the 3958 approach is best, then I'm happy to accept that conclusion. I would prefer to retain the existing mechanism. It is my view that - while the choice made for 3958 is the "most secure" - it's the least practical.
--Martin
> -----Original Message-----
> From: Pasi Eronen [mailto:pasi.eronen@nokia.com]
> Sent: Thursday, 18 February 2010 9:46 PM
> To: iesg@ietf.org
> Cc: geopriv-chairs@tools.ietf.org; draft-ietf-geopriv-lis-
> discovery@tools.ietf.org
> Subject: DISCUSS and COMMENT: draft-ietf-geopriv-lis-discovery
>
> Discuss:
> I have reviewed draft-ietf-geopriv-lis-discovery-13, and have one
> concern that I'd like to discuss before recommending approval of the
> document:
>
> While relying on DHCP seems unavoidable here, normally HTTPS does not
> rely on DNS to work securely. I'd like to see a better rationale for
> ignoring important security advice from the NAPTR specifications (most
> of Section 8 of RFC 3958). "More compatible with existing HTTP client
> software" seems rather vague, especially considering we're talking
> about new HELD client software, and not e.g. existing web browsers.
>
> LoST (RFC 5222) did use this approach, too, but only after concluding
> that the approach recommended in RFC 3958 would not have worked well
> in that particular context (where large number of inputs map to a
> very small number of LoST servers, and the LoST server is not even
> aware of all the possible inputs). Here the situation seems quite
> different: the location server needs to be aware of the access networks
> that have delegated to it (in order to properly determine the
> location).
>
> Comment:
> The regexp in Section 4 is wrong; "*." should be ".*"
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
[BA] Since in HELD return routability is presumed to ensure against IP address spoofing of HTTP over TCP requests, I'm assuming that this is not the address falsification being referred to here, right? I guess that leaves MAC address and the cellular identifiers.
So, since IDNA-aware applications and protocols, the three forms can appear together, I've qualified the statement:
This IDN-aware domain name slot [I-D.ietf-idnabis-defs] MAY be formed
from any sequence of valid labels (A-label, U-labels or NR-LDH-
label). Binary or bit string labels cannot be represented in this
domain name slot.
[BA] If the domain slot is IDN-aware, wouldn't it make sense to prefer a U-label? Also, I don't think you want to allow an FQDN that is a mixture of U-labels and A-labels.
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
I've updated the draft based on these comments.
I'm not available tomorrow, but I'll try to address any further comments on Friday. Here's the draft so far, with all the discussed changes:
> -----Original Message-----
> From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]
> Sent: Wednesday, 17 February 2010 12:17 PM
> To: Thomson, Martin; geopriv@ietf.org
> Subject: RE: [Geopriv] WGLC: draft-ietf-geopriv-held-identity-
> extensions
>
> A few additional comments on the (new) version.
>
> Section 1.1
>
> Information other than IP might
>
> s/IP/IP address/
>
> Due to the risk that an identifier might be spoofed by a Device,
> identifiers MUST NOT be used unless specific measures are taken to
> prevent spoofing.
>
> [BA] I am not sure what "spoofing" means here, exactly. Earlier,
> you've said that the Device identifier refers to the target.
> How does "spoofing" differ from a third party request where the
> requester and the target are different entities? I'm thinking
> that the normative statement doesn't apply to the requester, but rather
> to the LIS, who is required to properly authorize the
> request so as to make sure that location information is only provided
> to requesters that are authorized to receive it.
Let's avoid "spoofing" altogether and be explicit. My only concern here is that this duplicates later information. The only consolation is that this is important information for this application.
OLD:
Due to the risk that an identifier might be spoofed by a Device, identifiers must not be used unless specific measures are taken to prevent spoofing.
NEW:
A LIS can authorize location configuration requests using a policy that allows Devices to acquire their own location (see Section 4.1). If an unauthorized third-party falsifies addressing on request packets to match the provided Device identity, the request might be erroneously authorized under this policy. Requests containing Device identity must not be authorized using this policy unless specific measures are taken to prevent this type of attack.
> Unless anti-spoofing measures are used, these identifiers MUST only be
> used in third-party requests.
>
> [BA] You might rephrase this to require that the LIS MUST treat the
> request as a third-party request unless it is able to
> determine that the device identity and the requester are one and the
> same. I think this makes the MUST more actionable.
That's a good idea. Continuing the theme from above:
OLD:
This document describes measures that limit spoofing for the network access identifier (NAI) for use in WiMAX networks. Anti-spoofing measures are not described for any other identifier. Unless anti-spoofing measures are used, these identifiers are only intended for use in third-party requests.
NEW:
This document describes a mechanism that provides assurances that the requester and included Device identity are the same for the network access identifier (NAI) in a WiMAX network. The LIS MUST treat requests containing other identifiers as third-party requests, unless it is able to ensure that the provided Device identity is uniquely attributable to the requester.
> This document does not describe how a third-party acquires an
> identifier for a Device, or how that third-party is
> authenticated by a LIS.
>
> [BA] Doesn't section 6 describe a mandatory-to-implement authentication
> mechanism (HTTP digest) that is used to
> Authenticate the requester? Maybe you mean "how that third-party is
> authorized by a LIS."
That is more correct, yes.
> Section 4.4.1
>
> This request containing a
>
> s/containing a/includes an/
>
> Section 4.6
>
> This domain name slot....
>
> [BA] Question: Are you expecting a U-Label or A-Label here?
After reading the latest IDNA docs, and the exhaustive taxonomy of label types, I came to the conclusion that it doesn't matter...much. It can be a U- or A-label, as long as it can be represented in XML.
For context, IDNA-unaware applications treat all LDH-labels as valid
for appearance in DNS zone files and queries. IDNA-aware
applications permit only A-labels and NR-LDH-labels to appear in zone
files and queries. U-labels can appear, along with the other two, in
presentation and user interface forms, and in protocols that use IDNA
forms but that do not involve the DNS itself.
Specifically, for IDNA-aware applications, the three allowed
categories are A-label, U-label, and NR-LDH-label. Of the reserved
LDH labels (R-LDH-labels) only A-labels are valid for IDNA use.
-- <http://tools.ietf.org/html/draft-ietf-idnabis-defs-13#page-13>
So, since IDNA-aware applications and protocols, the three forms can appear together, I've qualified the statement:
This IDN-aware domain name slot [I-D.ietf-idnabis-defs] MAY be formed
from any sequence of valid labels (A-label, U-labels or NR-LDH-
label). Binary or bit string labels cannot be represented in this
domain name slot.
Trying to implement the restrictions for IDN in schema turns out to be a little difficult, so I didn't try that. :)
> Section 6.1
>
> Identifier transience of can lead
>
> s/of can/can/
>
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Section 1.1
Information other than IP might
s/IP/IP address/
Due to the risk that an identifier might be spoofed by a Device,
identifiers MUST NOT be used unless specific measures are taken to prevent spoofing.
[BA] I am not sure what "spoofing" means here, exactly. Earlier, you've said that the Device identifier refers to the target.
How does "spoofing" differ from a third party request where the requester and the target are different entities? I'm thinking
that the normative statement doesn't apply to the requester, but rather to the LIS, who is required to properly authorize the
request so as to make sure that location information is only provided to requesters that are authorized to receive it.
Unless anti-spoofing measures are used, these identifiers MUST only be used in third-party requests.
[BA] You might rephrase this to require that the LIS MUST treat the request as a third-party request unless it is able to
determine that the device identity and the requester are one and the same. I think this makes the MUST more actionable.
This document does not describe how a third-party acquires an identifier for a Device, or how that third-party is
authenticated by a LIS.
[BA] Doesn't section 6 describe a mandatory-to-implement authentication mechanism (HTTP digest) that is used to
Authenticate the requester? Maybe you mean "how that third-party is authorized by a LIS."
Section 4.4.1
This request containing a
s/containing a/includes an/
Section 4.6
This domain name slot....
[BA] Question: Are you expecting a U-Label or A-Label here?
Section 6.1
Identifier transience of can lead
s/of can/can/
-----Original Message-----
From: Thomson, Martin [mailto:Martin.Thomson@andrew.com]
Sent: Monday, February 08, 2010 3:44 PM
To: Bernard Aboba; 'Alissa Cooper'; geopriv@ietf.org
Subject: RE: [Geopriv] WGLC: draft-ietf-geopriv-held-identity-extensions
Hi Bernard,
Thanks for the detailed review. I agree that on a lot of these
points a little better clarification is required. I'll propose
text for each of these below (or explain why I don't think changes
are necessary).
I'm sorry that this reply took so long; I tried to get back to
this sooner, but I wanted to double-check everything. I have a
revised draft here:
I've included a lot of text changes below, but I believe they are
largely editorial in nature - getting closer to what the WG agreed
to in previous discussions. Your review has highlighted a few
places where my original text is weak or confusing; hopefully, the
changes I am proposing make things clearer.
Cheers,
Martin
> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of Bernard Aboba
> Sent: Wednesday, 3 February 2010 5:01 PM
> To: 'Alissa Cooper'; geopriv@ietf.org
> Subject: Re: [Geopriv] WGLC: draft-ietf-geopriv-held-identity-
> extensions
>
> I have reviewed draft-ietf-geopriv-held-identity extensions.
>
> Overall, I think that the document needs additional work before it
> would be
> ready for publication. While much of this work is in the area of
> terminology cleanup and editorial issues, I do have some more serious
> concerns about the fuzziness of the text relating to authentication and
> the
> chosen mandatory-to-implement security mechanism (mutual TLS).
>
>
> Here are my detailed comments:
>
> "Section 1
>
> Location configuration: A Device can use these parameters to
> identify itself to a LIS. Identification information other than
> IP might be needed to determine the location of a Device.
>
> Due to the risk that an identifier might be spoofed by a Device,
> identifiers MUST NOT be used unless specific information is
> provided for that identifier describing how the identifier is
> used
> and what measures are used to prevent spoofing.
>
> This document provides this information for the network access
> identifier (NAI) for use in WiMAX networks.
>
> [BA] Section 4.2 provides the information for MAC addresses as well.
This was a big point of contention in the discussions in
Hiroshima. If the LIS is able to see the MAC address of the
requester (the anti-spoofing mechanism described in 4.2), then
there is no point in having an explicit deviceIdentity parameter
in the request. A straight HELD request works fine.
Our open source LIS implementation can actually use this for
IP-MAC mappings. The HELD request establishes an entry in the ARP
table of the host, which the LIS then checks.
This is made worse by the confusion over where identifiers come
from: either explicitly in the payload, or inherent in the return
addressing at different layers. You point out below that this
needs to be clearer; I've made a small attempt to address that in the
introduction:
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.
The section you reference could be made clearer and more concise.
It currently implies that use of explicit device identity cannot
be used for location configuration, which we cannot police. I've
changed this to make it clear that anti-spoofing is important and
that we only describe measures for NAI in WiMAX:
Section 1.1, OLD:
Due to the risk that an identifier might be spoofed by a
Device, identifiers MUST NOT be used unless specific
information is provided for that identifier describing how the
identifier is used and what measures are used to prevent
spoofing.
This document provides this information for the network access
identifier (NAI) for use in WiMAX networks. All other
identifiers described are solely for use in third-party
requests.
NEW:
Due to the risk that an identifier might be spoofed by a
Device, identifiers MUST NOT be used unless specific measures
are taken to prevent spoofing.
This document describes measures that limit spoofing for the
network access identifier (NAI) for use in WiMAX networks.
Anti-spoofing measures are not described for any other
identifier. Unless anti-spoofing measures are used, these
identifiers MUST only be used in third-party requests.
Then, the bit in the description of the MAC address doesn't really
help. Of course, matching the explicit identifier to an
identifier in the request packets is a pretty good anti-spoofing
measure, but it's redundant. We decided in Hiroshima not to
encourage this particular usage, base HELD should be sufficient.
Section 4.2, REMOVE:
A LIS that operates on the same layer 2 segment as a Device
sees the MAC address of the Device and can authenticate the
device in that fashion. If a router is interposed between LIS
and Device, other means of authentication are required.
> All other identifiers
> described are solely for use in third-party requests."
>
> [BA] This sentence seems to contradict the second paragraph above. If
> anti-spoofing
> mechanisms are required and supplied, then presumably the target
> identifier
> can be
> confirmed to be that of the requester. In that case, why would those
> identifiers
> be solely for use in third-party requests?
>
> Overall, I think this section needs to make a clear distinction between
> the identifiers present in the packet (which relate to the requester)
> and the application-layer identifiers, which presumably relate to the
> target of the request. Right now the terminology does not make that
> clear.
Does this (in addition to the above) address your concerns?
Section 1.1, NEW:
This document defines a means to explicitly include Device
identity information in the body of a HELD location request.
This identity information is used to identify the Device that
is the subject (or Target) of the location request. If device
identity is present, the identity of the requester is not used
to identify the subject of the request.
> This document does not describe how a third party acquires an
> identifier for a Device, or how that third-party is authenticated
> by a LIS. These issues MUST be resolved before permitting a
> third-party request.
>
> [BA] This seems like an invitation to non-interoperability as the
> protocol
> is extended to fill the holes addressed in the above paragraph.
> At a minimum, I'd suggest that this document enable HELD extension
> implementations to support HTTP authentication.
I have no strong preference either way. TLS was chosen
arbitrarily. If you'd prefer HTTP digest, then we can switch.
Key management and distribution is always going to be a problem,
no matter what authentication scheme you choose.
> Section 2
>
> The term Device is used specifically as the subject of an LCP,
> consistent with [I-D.ietf-geopriv-http-location-delivery]. This
> document also uses the term Target to refer to any entity that might
> be a subject of the same location information. Target is used in a
> more general sense, including the Device, but also any nearby
> entity,
> such as the user of a Device. A Target has a stake in setting
> authorization policy on the use of location information. Both
> Device
> and Target are defined in [I-D.ietf-geopriv-arch].
>
> [BA] What is the terminology used to indicate the source of a request
> in a third-party request? This is not the Device if an LCP is not
> involved, and it's not the Target either. So what do we call it?
We're both already using "requester", so I'll formalize it:
Section 2, NEW:
The term "requester" is used in this document to refer to the
entity making a HELD request.
> Section 3.1
>
> Use of any identifier MUST only be allowed if it identifies a single
> Device at a particular time.
>
> [BA] Some identifiers (such as the NAI) may or may not identify a
> single
> device, depending on the policy of the operator. For example, if only
> a single simultaneous logon is permitted, then the NAI is unique,
> otherwise
> not. Given this, whose responsibility is it to enforce the MUST? Is
> this
> a requirement on the LIS (e.g. which must check the request to make
> sure
> that the target is uniquely identified)?
Assigning responsibility for this "MUST" seems reasonable. How
about:
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>
> It is tempting for a LIS implementation to allow alternative
> identifiers for convenience or some other perceived benefit.
> However, care needs to be taken to ensure that the binding
> between
> the indicated identifier and the identifier that is used for
> location determination is unique and not subject to attacks.
>
> [BA] Not sure what "indicated identifier" and "identifier used for
> location determination" mean here. I'd suggest that these be defined
> in the terminology section.
Or, this could be rephrased to avoid ambiguous terms like this:
OLD: (above)
NEW:
...benefit. The LIS is responsible for ensuring that the
identifier used in the request does not refer to a Device other
than the one for which it determines location.
> Identifiers can have a different meaning to different entities on a
> network. An identifier in one network context might have a
> completely different meaning in a different context. Errors in
> perspective arise in both topology (all network entities have a
> subjective view of the network) and time (the network changes over
> time).
>
> [BA] I find this paragraph hard to understand. It does not make sense
> to say that an NAI or a MAC address has a different meaning to
> different
> entities in a network. Different entities may be able to do different
> things with those identifiers, but that isn't the same thing as saying
> that their fundamental meaning changes. I'd suggest that this
> paragraph
> be rewritten to sharpen the meaning.
My intent was to convey the sorts of things described in:
<http://tools.ietf.org/html/draft-carpenter-behave-referral-object-01>
This would probably benefit from an RFC 2101 reference, and some
allowance for identifiers that are truly globally unique.
Some identifiers are always uniquely attributable to a single
Device. However, other identifiers can have a different
meaning to different entities on a network. This is especially
true for IP addresses [RFC2101], but this can be true for other
identifiers to varying degrees. Non-uniqueness arises from
both topology (all network entities have a subjective view of
the network) and time (the network changes over time).
> Section 3.1.1
>
> For instance, a LIS might operate within a network that uses a
> private address space, with NAT between that network and other
> networks. A third-party request that originates in an external
> network with an IP address from the private address space might
> not be valid - it could be identifying an entity within another
> address space. The LIS can be configured to reject such
> requests,
> unless it knows by other means that the request is valid.
>
> [BA] This is not just an issue for third party requests -- it can and
> does
> come up with respect to HELD when used as an LCP.
Indeed. But this is only an illustrative example. What was your
intent with this comment? I don't think that an equivalent LCP
example would be especially interesting, given the set of
identifiers that we have available.
> Section 4.2
>
> [BA] This section seems like it only supports 48-bit MAC addresses.
> I'd
> suggest including support for other types of MAC addresses (e.g. 64-
> bit).
Done. I think that length is enough to distinguish the two;
however, is an explicit indicator commonplace elsewhere?
> A LIS that operates on the same layer 2 segment as a Device sees the
> MAC address of the Device and can authenticate the device in that
> fashion. If a router is interposed between LIS and Device, other
> means of authentication are required.
>
> [BA] This paragraph makes sense, but it is contradicted by earlier
> statements
> in Section 1 that the document only deals with the issue of
> authentication/spoofing
> for NAIs.
I've removed this. This was an oversight in the edits out of the
Hiroshima meeting.
> Section 4.3
>
> This section seems to assume some kind of shared-address scheme.
> However,
> those
> schemes are based on port ranges, not just individual ports. Is the
> idea to
> use
> a single port to identify a port range? Since these schemes are for
> use in
> IPv4 only, why is an IPv6 addressed used in the example?
Yes, the intent is to identify the range; the third-party need
only see one flow and might not have knowledge of ranges.
I'll fix the example.
> Section 4.4
>
> [BA] The WiMAX specifications define operation over both RADIUS and
> Diameter. So
> you probably should just define the security requirements generically
> (e.g.
> per-packet
> confidentiality, re play-protection, authentication and
>integrity).
Done. This actually simplifies the text, thanks.
> You might say a word or two about why NAIs are unique in WiMAX
> networks.
> For example,
> device NAIs refer to a single device and user NAIs are either
> provisioned
> into the
> device or can be transferred between devices (e.g. on a SIM), so that
> it's
> typically
> not possible to have two simultaneously connected users with the same
> NAI.
That's not exactly as I understand it. An NAI identifies either a
device or a service subscription. It took a little digging
(my familiarity with WiMAX is superficial at best), but I've
determined that it is not possible to have multiple active
sessions for the same NAI. I've included the following text:
Section 4.4, NEW:
An NAI in WiMAX is uniquely attributable to a single device at
any one time. An NAI eitehr identifies a Device or a service
subscription, neither of which can have multiple active
sessions.
> Section 4.6
>
> [BA] The term hostname typically refers to a non-fully qualified domain
> name. Yet here,
> I think we're only talking about FQDNs, right? If so, then the text
> (and
> section heading)
> should probably make that clear.
It's FQDN, certainly. I've made that change. Also, after reading
the latest IDNA docs, it makes sense to accept U-labels (after
all, the URI syntax allows them), so I've added a note regarding
them too.
> Section 4.7
>
> [BA] If dialstrings are going to be used as identifiers, I think you
> also
> need to supply the
> context.
Given that tel: URIs do the same job and provide mechanisms for
providing context, this section isn't actually adding value. It's
been removed.
> Section 5
>
> The security and privacy considerations of the base HELD protocol
> [I-D.ietf-geopriv-http-location-delivery] are applicable, except as
> they relate to return routability.
>
> [BA] Why would the "return routability" considerations not apply to a
> LIS
> receiving a request from a source on the same LAN segment, if a MAC
> address
> is used as the identifier?
See above. Explicit Device identity is not required in that case.
We should encourage people to not use identity in that case.
It always helps to be clear, so:
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.
> Section 5.1
>
> Verification that depends on
> return routability can only provide weaker assurances than those
> provided by return routability;
>
> [BA] I don't understand this statement. Is this a typo?
I just re-read that and you're right, I think that maybe you have
to know what it says before you read it...
Section 5.1, OLD:
(above)
NEW:
Any multi-stage verification process that includes a return
routability test cannot provide any stronger assurance than
return routability alone;
> 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. The MAC address
potentially identifies a different Device to the one that is
making the request. The correct way of gaining authorization
is to establish a policy that permits this particular request
as a third-party request.
> Section 6
>
> All HELD requests containing identity MUST be authenticated by the
> LIS. How authentication is accomplished and what assurances are
> desired is a matter for policy.
>
> The base HELD protocol uses return reachability of an IP address
> implied by the requester being able to successfully complete a TCP
> handshake. It is RECOMMENDED that any means of authentication
> provide at least this degree of assurance. For requests that
> include
> Device identity, the LIS MUST support authentication of TLS clients.
>
> [BA] This is effectively requiring that HELD extension clients support
> mutual TLS
> and be provisioned with certificates. Is this reasonable? A more
> flexible choice would be to require support for HTTP
>authentication.
Since authentication in either form needs to be the subject of
prior negotiation, neither choice is ideal. I don't think that it
really matters either way. HTTP authentication is proving to be a
little more flexible, so maybe this is a reasonable request.
As far as I'm aware, mutual TLS is in the specs
that rely on HELD, but it's not widely implemented at this stage;
HTTP digest would certainly be easier to implement.
Section 6, OLD:
... For requests that include Device identity, the LIS MUST
support authentication of TLS clients.
NEW:
... For requests that include Device identity, the LIS MUST
support HTTP digest authentication. Unauthenticated location
requests containing Device identity can be challenged with an
HTTP 401 (Unauthorized) response or rejected with an HTTP 403
(Forbidden) response.
> Section 6.2
>
> [BA] This section seems like it covers much the same ground as Section
> 5.1.
>
> Is it possible to consolidate these sections?
That is hard to do without altering the document structure.
--Martin
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
One minor clarifying question below...
> > use Device identifiers in this fashion. This contract includes how
> > the request is authenticated and the set of identifiers (and types
> > of identifiers) that the third-party is authorized to use in
> requests.
>
> I think it would make more sense to say "This contract must
> include" (lower case) rather than "This contract includes . . .."
> Otherwise it sounds like a statement of fact.
Sure - it's a fine line to walk.
> > If this IP address matches the source IP address of the HELD
> > location request, the location request can be authorized under the
> > LCP policy (see Section 5.1); otherwise, the request MUST have been
> > authorized as a third-party request.
>
> It seems a bit odd to place a normative requirement on something that
> happened in the past ("MUST have been"). It's not clear that you need
> to be normative at all since you're talking about an authorization
> check that already happened. Here's a suggestion:
>
> If this IP address matches the source IP address of the HELD
> location request, the location request can be authorized under the
> LCP policy (see Section 5.1). Otherwise, the request must be treated
> as a third-party request.
Again, a good point. So few people have the ability to change the past.
Are we back to using lowercase "must" for any particular reason? Is there a particular reason that you didn't choose to use "MUST"?
--Martin
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
> A couple of comments inline with my individual contributor hat on...
>
> On Feb 8, 2010, at 11:43 PM, Thomson, Martin wrote:
>
> > NEW:
...
> >
> > 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.
Thanks, I assume that you are OK with keeping my last sentence, or did you intend to have that disappear as well?
...
> > NEW:
... 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.
That's a little more specific, which is good. "identifier uniquely identifies" is less elegant, but I can't think of a more concise statement that is this accurate. It will suffice.
...
> > 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. . ."
"might" rather than "may" to avoid confusion with normative text, or is this an intentional shading of meaning?
...
> > NEW:
> > ... 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.
I think that Device is a better choice than Target, but it's a point well made. Thanks.
>
> Aliss
>
Cheers,
Martin
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
> DISCUSS: This discuss can probably be cleared up quickly. I'm
> surprised to see a DHCPv4/6 option standardized out of GEOPRIV. Has
> the DHC WG reviewed this?
The -05 draft was discussed extensively with DHC; -06 and -07 were the product of that discussion. It's changed a little since then, and we haven't gone back (an oversight on my part).
> What if I have multiple access interfaces connected to multiple
> operators, all of which operate LIS servers that satisfy the criteria
> for use? According to the outlined procedure, I'd only ever use one
> of
> them. Does it truly not matter which LIS I use? How does this
> procedure intersect with what the MIF WG is doing?
If the goal is to get location information, then it is considered that any information is enough. The source does matter, but not enough to have us describe more complicated procedures. The text purposefully avoids "MUST" to allow implementations to use other logic if that suits. If you believe that the "SHOULD" needs further clarification, I can add:
This approach ensures that the device obtains location information as fast as possible. An implementation MAY use other algorithms if it has other goals or if it has better information about the different access networks it uses.
(...reads MIF charter and PS...) This is certainly pertinent to the work in MIF. The problems that they discuss are the reason that this text is in here.
> Nit: s/probablity/probability/
Fixed.
Thanks,
Martin
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
I've reviewed the -03 version of the draft that was made available on the list by Martin Thompson last week and provided my wordsmithing comments directly to the authors.
I've also reviewed comments provided by other reviewers and responses provided so far, which seem non-controversial.
As such, I think the document is ready to proceed.
Thanks,
Guy
-----Message d'origine-----
De : geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] De la part de Alissa Cooper
Envoyé : 15 février 2010 00:26
À : geopriv@ietf.org
Objet : Re: [Geopriv] WGLC: draft-ietf-geopriv-held-identity-extensions
Just a reminder that this WGLC ends on Tuesday, 16 February. Please
send comments if you have not already.
> This is a GEOPRIV Working Group Last Call for comments on
>>
>
> draft-ietf-geopriv-held-identity-extensions-02.txt
>
> Please send your comments to the list by 16 February 2010. As
> always, please remember to send a note in if you've read the
> document and have no other comments other than "its ready to go" -
> we need those as much as we need "I found a problem".
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> 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
On Feb 15, 2010, at 5:36 AM, Thomson, Martin wrote:
>> 2. Section 1.1
>> "This document does not describe how a third party acquires an
>> identifier for a Device, or how that third-party is
>> authenticated
>> by a LIS. These issues MUST be resolved before permitting a
>> third-party request. A pre-arranged contract between the third-
>> party, a Rule Maker and the LIS operator is necessary to use
>> device identifiers in this fashion. This contract MUST include
>> how the request is authenticated and the set of identifiers
>> (and
>> types of identifiers) that the third-party is authorized to use
>> in
>> requests.
>>
>> Note that this is not intended to preclude the definition of
>> mechanisms that replace this requirement with automated means of
>> establishing these constraints."
>>
>> Comment: This use of normative language to attempt to mandate legally
>> binding contracts for access to location information of wheelchairs
>> in
>> hospitals, cattle on farms, and all other possible uses of this
>> protocol
>> is, IMO, unacceptable. Especially here in this introductory section.
>> This is trying to mandate policy that is not only external to the
>> protocol, but is also external to the LIS that operates the protocol.
>> As
>> such, it has no business being normative.
>
> I've discussed the implications of this in more detail below. The
> inviolate rights of cattle notwithstanding, the role of Rule Maker
> in this case can be trivially assumed by the farmer, who indicates
> his grant of authorization by installing a tracking device on the
> animal; or the person who installs the LIS, who assumes this role
> when they turn the LIS on.
>
> I've removed the normative language, which didn't really add
> anything in this case, as you can see. I've also taken your text
> for the final statement, but I don't believe that the conditional
> language is necessary.
>
> Section 1.1, CHANGED:
> This document does not describe how a third party acquires an
> identifier for a Device, nor how that third-party is authenticated
> by a LIS. It is critical that these issues are resolved before
> permitting a third-party request. A pre-arranged contract between
> the third-party, a Rule Maker and the LIS operator is necessary to
> use Device identifiers in this fashion. This contract includes how
> the request is authenticated and the set of identifiers (and types
> of identifiers) that the third-party is authorized to use in requests.
I think it would make more sense to say "This contract must
include" (lower case) rather than "This contract includes . . .."
Otherwise it sounds like a statement of fact.
>> 4. Section 4.4.1
>> "The AAA server consults network policy and if the request is
>> permitted, the response includes the IP address that is currently
>> assigned to the Device. If this IP address matches the source IP
>> address of the HELD location request, the location request is
>> permitted; otherwise, the request is rejected."
>>
>> Comment: Per the 2nd paragraph in this section, the restrictions in
>> the
>> 2nd sentence are only true if the request is being treated as a
>> location
>> configuration request, and not if the request is already
>> authenticated
>> as a third-party request. Recommend rewording the 2nd sentence to "If
>> this is an unauthenticated request that is being treated as a
>> location
>> configuration request, then the location request is permitted if and
>> only if this IP address matches the source IP address of the HELD
>> location request."
>
> Bernard had a similar comment, but I couldn't think of the right
> response. I think that the right thing to say here is:
>
> Section 4.4.1, OLD:
> If this IP address matches the source IP address of the HELD
> location request, the location request is permitted; otherwise, the
> request is rejected.
> NEW:
> If this IP address matches the source IP address of the HELD
> location request, the location request can be authorized under the
> LCP policy (see Section 5.1); otherwise, the request MUST have been
> authorized as a third-party request.
It seems a bit odd to place a normative requirement on something that
happened in the past ("MUST have been"). It's not clear that you need
to be normative at all since you're talking about an authorization
check that already happened. Here's a suggestion:
> If this IP address matches the source IP address of the HELD
> location request, the location request can be authorized under the
> LCP policy (see Section 5.1). Otherwise, the request must be treated
> as a third-party request.
>
>> 5. Section 5.2
>> "An organization that provides a LIS that allows third party
>> requests
>> must provide a means for a Rule Maker to specify authorization
>> policies as part of the LIS implementation (e.g, in the form of
>> access control lists). Authorization must be established before
>> allowing third party requests for the location of any Target.
>> Until
>> an authorization policy is established, the LIS MUST reject
>> requests
>> by third parties (that is, the default policy is "deny all")."
>>
>> Comment: Organizations must only do this if they are legally bound to
>> do
>> this. Not because the IETF says so. Such organizational policy is
>> external to the protocol and the LIS. The "musts" in these sentences
>> are
>> non-normative (which is good), but I think there needs to be some
>> additional disclaimers. I recommend "In cases where privacy is
>> mandated
>> for legal, regulatory, or other reasons, an organization that
>> provides
>> a
>> LIS..." and then the 2nd sentence is "In such cases, authorization
>> must
>> be established..." The last sentence is good, as a default LIS
>> policy.
>
> I'm sure that organizations could find reasons other than legal ones
> to protect privacy.
>
> But the main point is that this doesn't prevent anything. The
> process of gaining authorization can be a simple one. And the role
> of Rule Maker is an easy one to assume. Given that the LIS operator
> chooses who to recognize as Rule Maker, if there are no applicable
> regulations, the LIS operator can assume the role and set any rule
> they want.
>
> The intent here is not to set a rule, but to identify "harm" to
> privacy and highlight the role that is taken on when the "send"
> button is pressed. I'm pretty sure that we're not trying to say
> prevent this on the strength of "the IETF said so".
>
> I'd prefer not to make these statements conditional.
+1
Alissa
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
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
> -----Original Message-----
> From: Thomson, Martin [mailto:Martin.Thomson@andrew.com]
> Sent: Monday, February 15, 2010 12:36 AM
> To: STARK, BARBARA H (ATTLABS); geopriv@ietf.org
> Subject: RE: [Geopriv] WGLC: draft-ietf-geopriv-identity-extensions
>
> Hi Barbara,
>
> Thanks for the feedback. I've made the minor corrections that you've
> requested.
>
> I've responded inline to each below.
>
> > -----Original Message-----
> > From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> > Behalf Of STARK, BARBARA H (ATTLABS)
> > Sent: Saturday, 13 February 2010 3:08 AM
> > To: geopriv@ietf.org
> > Subject: Re: [Geopriv] WGLC: draft-ietf-geopriv-identity-extensions
> >
> > I've sent the authors my editorial nits (misspellings and grammatical
> > errors).
> >
> > I have the following 5 comments, but if others don't want changes
> from
> > these comments, I'm willing to withdraw any or all of them. My
> comments
> > don't impact the requirements for the protocol or the LIS, and I'd
> like
> > to see this document move forward.
> > Barbara
> > ---------------------------------------------------------------------
> --
> > 1. Section 1.1 (under the Introduction)
> > "Due to the risk that an identifier might be spoofed by a
> Device,
> > identifiers MUST NOT be used unless specific information is
> > provided for that identifier describing how the identifier is
> > used
> > and what measures are used to prevent spoofing."
> >
> > Comment: The use of normative language in this introductory section
> is
> > awkward. Given that the same requirement effectively exists in
> Section
> > 5.1, I would prefer that it not be duplicated here. Make this "must
> > not"
> > (lower case letters).
>
> You are quite right in pointing out that it's not necessary to use
> normative language, especially in the introduction.
>
> In response to Bernard's review, this paragraph is already different.
> I'll take your suggestion and change "MUST NOT" to lowercase. The new
> text becomes:
>
> Section 1.1, CHANGED:
> Due to the risk that an identifier might be spoofed by a Device,
> identifiers must not be used unless specific measures are taken to
> prevent spoofing.
>
> > 2. Section 1.1
> > "This document does not describe how a third party acquires an
> > identifier for a Device, or how that third-party is
> authenticated
> > by a LIS. These issues MUST be resolved before permitting a
> > third-party request. A pre-arranged contract between the
> third-
> > party, a Rule Maker and the LIS operator is necessary to use
> > device identifiers in this fashion. This contract MUST include
> > how the request is authenticated and the set of identifiers
> (and
> > types of identifiers) that the third-party is authorized to use
> > in
> > requests.
> >
> > Note that this is not intended to preclude the definition of
> > mechanisms that replace this requirement with automated means
> of
> > establishing these constraints."
> >
> > Comment: This use of normative language to attempt to mandate legally
> > binding contracts for access to location information of wheelchairs
> in
> > hospitals, cattle on farms, and all other possible uses of this
> > protocol
> > is, IMO, unacceptable. Especially here in this introductory section.
> > This is trying to mandate policy that is not only external to the
> > protocol, but is also external to the LIS that operates the protocol.
> > As
> > such, it has no business being normative.
>
> I've discussed the implications of this in more detail below. The
> inviolate rights of cattle notwithstanding, the role of Rule Maker in
> this case can be trivially assumed by the farmer, who indicates his
> grant of authorization by installing a tracking device on the animal;
> or the person who installs the LIS, who assumes this role when they
> turn the LIS on.
>
> I've removed the normative language, which didn't really add anything
> in this case, as you can see. I've also taken your text for the final
> statement, but I don't believe that the conditional language is
> necessary.
>
> Section 1.1, CHANGED:
> This document does not describe how a third party acquires an
> identifier for a Device, nor how that third-party is authenticated by a
> LIS. It is critical that these issues are resolved before permitting a
> third-party request. A pre-arranged contract between the third-party,
> a Rule Maker and the LIS operator is necessary to use Device
> identifiers in this fashion. This contract includes how the request is
> authenticated and the set of identifiers (and types of identifiers)
> that the third-party is authorized to use in requests.
> Automated mechanisms to ensure privacy constraints are respected are
> possible.
>
> > 3. Section 4.4.1 [editorial comment]
> > "After receiving a location request that includes an NAI, the LIS
> > sends a "Location-Requestor-Authentication-Protocol" access
> request
> > message to the Authentication, Authorization and Accounting (AAA)
> > server."
> >
> > Comment: Please provide a reference here as to where the
> > Location-Requestor-Authentication-Protocol is defined.
>
> This reference is already provided in the first paragraph of the
> section (as you guessed), but it's probably not clear enough that the
> WiMAX Forum reference applies to the whole section.
>
> Section 4.4.1, OLD:
> In a WiMAX network, an IP address is not sufficient information for
> a LIS to locate a Device. The procedure in [WiMAX-T33-110-R015v01-B]
> relies on an NAI to identify the Device.
> NEW:
> In a WiMAX network, an IP address is not sufficient information for
> a LIS to locate a Device. The following procedure, described in more
> detail in [WiMAX-T33-110-R015v01-B], relies on an NAI to identify the
> Device.
>
> > 4. Section 4.4.1
> > "The AAA server consults network policy and if the request is
> > permitted, the response includes the IP address that is currently
> > assigned to the Device. If this IP address matches the source IP
> > address of the HELD location request, the location request is
> > permitted; otherwise, the request is rejected."
> >
> > Comment: Per the 2nd paragraph in this section, the restrictions in
> the
> > 2nd sentence are only true if the request is being treated as a
> > location
> > configuration request, and not if the request is already
> authenticated
> > as a third-party request. Recommend rewording the 2nd sentence to "If
> > this is an unauthenticated request that is being treated as a
> location
> > configuration request, then the location request is permitted if and
> > only if this IP address matches the source IP address of the HELD
> > location request."
>
> Bernard had a similar comment, but I couldn't think of the right
> response. I think that the right thing to say here is:
>
> Section 4.4.1, OLD:
> If this IP address matches the source IP address of the HELD
> location request, the location request is permitted; otherwise, the
> request is rejected.
> NEW:
> If this IP address matches the source IP address of the HELD
> location request, the location request can be authorized under the LCP
> policy (see Section 5.1); otherwise, the request MUST have been
> authorized as a third-party request.
>
> > 5. Section 5.2
> > "An organization that provides a LIS that allows third party
> > requests
> > must provide a means for a Rule Maker to specify authorization
> > policies as part of the LIS implementation (e.g, in the form of
> > access control lists). Authorization must be established before
> > allowing third party requests for the location of any Target.
> > Until
> > an authorization policy is established, the LIS MUST reject
> requests
> > by third parties (that is, the default policy is "deny all")."
> >
> > Comment: Organizations must only do this if they are legally bound to
> > do
> > this. Not because the IETF says so. Such organizational policy is
> > external to the protocol and the LIS. The "musts" in these sentences
> > are
> > non-normative (which is good), but I think there needs to be some
> > additional disclaimers. I recommend "In cases where privacy is
> mandated
> > for legal, regulatory, or other reasons, an organization that
> provides
> > a
> > LIS..." and then the 2nd sentence is "In such cases, authorization
> must
> > be established..." The last sentence is good, as a default LIS
> policy.
>
> I'm sure that organizations could find reasons other than legal ones to
> protect privacy.
>
> But the main point is that this doesn't prevent anything. The process
> of gaining authorization can be a simple one. And the role of Rule
> Maker is an easy one to assume. Given that the LIS operator chooses
> who to recognize as Rule Maker, if there are no applicable regulations,
> the LIS operator can assume the role and set any rule they want.
>
> The intent here is not to set a rule, but to identify "harm" to privacy
> and highlight the role that is taken on when the "send" button is
> pressed. I'm pretty sure that we're not trying to say prevent this on
> the strength of "the IETF said so".
>
> I'd prefer not to make these statements conditional.
>
> --Martin
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv