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.
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.
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.
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?
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)?
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.
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.
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.
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).
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.
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?
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, replay-protection, authentication and integrity).
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.
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.
Section 4.7
[BA] If dialstrings are going to be used as identifiers, I think you also
need to supply the
context.
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?
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?
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)?
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.
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?
-----Original Message-----
From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf
Of Alissa Cooper
Sent: Tuesday, February 02, 2010 2:57 PM
To: geopriv@ietf.org
Subject: Re: [Geopriv] WGLC: draft-ietf-geopriv-held-identity-extensions
Fixed the error in the subject line.
On Feb 2, 2010, at 10:51 PM, Alissa Cooper wrote:
> 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
