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
