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
