Laura
> -----Original Message-----
> From: geopriv-bounces@ietf.org
> [mailto:geopriv-bounces@ietf.org] On Behalf Of Dawson, Martin
> Sent: Wednesday, February 10, 2010 10:54 AM
> To: Thomson, Martin; Bernard Aboba; 'Alissa Cooper'; geopriv@ietf.org
> Subject: Re: [Geopriv] WGLC:
> draft-ietf-geopriv-held-identity-extensions
>
> I think with Bernard's suggested changes and Martin's
> proposed amendments this document should be ready to go to the IESG.
>
> Cheers,
> Martin
>
> -----Original Message-----
> From: geopriv-bounces@ietf.org
> [mailto:geopriv-bounces@ietf.org] On Behalf Of Thomson, Martin
> Sent: Tuesday, 9 February 2010 10:44 AM
> 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:
>
> <https://docs.google.com/uc?id=0B8H10P2T_qIyNDMyODcxNzQtYmY2Yy
00MDI0LThkNTEtNWMyMTJkOWMzNDA5&export=download&hl=en>
>
> 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
> _______________________________________________
> 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
