Subject: [Geopriv] WGLC: draft-ietf-geopriv-identity-extensions

From: Alissa Cooper <[email-masked]>
Date: Tue, 2 Feb 2010 22:51:33 +0000

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".

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 2 Feb 2010 22:56:54 +0000

Fixed the error in the subject line.

On Feb 2, 2010, at 10:51 PM, Alissa Cooper wrote:

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv
>

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 2 Feb 2010 22:01:27 -0800

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. 

      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: [email-masked] [mailto:[email-masked]] On Behalf
Of Alissa Cooper
Sent: Tuesday, February 02, 2010 2:57 PM
To: [email-masked]
Subject: Re: [Geopriv] WGLC: draft-ietf-geopriv-held-identity-extensions

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 9 Feb 2010 07:43:49 +0800

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_qIyNDMyODcxNzQtYmY2Yy00MDI0LThkNTEtNWMyMTJkOWMzNDA5&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

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Bernard Aboba
> Sent: Wednesday, 3 February 2010 5:01 PM
> To: 'Alissa Cooper'; [email-masked]

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.

> target of the request.  Right now the terminology does not make that

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.

> 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.

> 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.

> 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>

> 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.

> 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).

> 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.

> suggest including support for other types of MAC addresses (e.g. 64-

Done.  I think that length is enough to distinguish the two;
however, is an explicit indicator commonplace elsewhere?

> in Section 1 that the document only deals with the issue of

I've removed this.  This was an oversight in the edits out of the
Hiroshima meeting.

> 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.

> confidentiality, re play-protection, authentication and
>integrity).

Done.  This actually simplifies the text, thanks.

> not possible to have two simultaneously connected users with the same

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.

> 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.

> [BA] If dialstrings are going to be used as identifiers, I think you

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.

> 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.

> [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;

> 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.

> flexible choice would be to require support for HTTP

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.

> Is it possible to consolidate these sections?

That is hard to do without altering the document structure.

--Martin

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 10 Feb 2010 17:54:29 +0800

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: [email-masked] [mailto:[email-masked]] On Behalf Of Thomson, Martin
Sent: Tuesday, 9 February 2010 10:44 AM
To: Bernard Aboba; 'Alissa Cooper'; [email-masked]
Subject: Re: [Geopriv] WGLC: draft-ietf-geopriv-held-identity-extensions

Hi Bernard,

Cheers,
Martin

Section 1, OLD:

NEW:

Section 1.1, OLD:

Section 4.2, REMOVE:

Section 1.1, NEW:

Section 2, NEW:

Section 3.1, OLD:

OLD: (above)
NEW:

I'll fix the example.

Section 4.4, NEW:

Section 5, OLD:

Section 5.1, OLD:
   (above)
NEW:

Section 5.1, OLD:
   (above)
NEW:

Section 6, OLD:

--Martin

---

From: <[email-masked]>
Date: Wed, 10 Feb 2010 11:49:30 +0100

I have read the document and I think it's ready to go.
Laura

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dawson, Martin
> Sent: Wednesday, February 10, 2010 10:54 AM
> To: Thomson, Martin; Bernard Aboba; 'Alissa Cooper'; [email-masked]
> 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
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Thomson, Martin
> Subject: Re: [Geopriv] WGLC: 
> draft-ietf-geopriv-held-identity-extensions
> 
> Hi Bernard,
> 
> <https://docs.google.com/uc?id=0B8H10P2T_qIyNDMyODcxNzQtYmY2Yy
00MDI0LThkNTEtNWMyMTJkOWMzNDA5&export=download&hl=en>
> > concerns about the fuzziness of the text relating to 
> authentication and
> > the
> > not.  Given this, whose responsibility is it to enforce the 
> MUST?  Is
> > this
> > [BA] This is not just an issue for third party requests -- 
> it can and
> > does
> > you probably should just define the security requirements 
> generically
> > (e.g.
> > per-packet
> > 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.
> 
> > [BA] Why would the "return routability" considerations not 
> apply to a
> > LIS
> > [BA]  This section seems like it covers much the same 
> ground as Section
> > 5.1.
> >

---

From: [email-masked]
Date: Wed, 10 Feb 2010 13:42:19 +0000

> I have read the document and I think it's ready to go.

Likewise here, except for minor nits:

intro - s/addresses/addressed/

§1 - s/,or/,nor/ how that third-party is authenticated...

§3.1, paragraph 4 - indented para, or quote?

§3.1.1, line 1 - s/requests/request/
     paragraph 3 - s/it's/its/
     also more indented paragraphs

§3.2.2, paras 1 and 3 - shouldn't these read "device" element instead of 
"target"?

§4.1.1, para 2 - s/eitehr/either/

§5, para 6 - indented paragraph

§5.2, para 1 - s/agree/agreed/

On the indented paragraphs I'm simply not sure if this is a formattting 
error, or if you're attempting to make these the sort of "sidebar" 
explanatory note sometimes seen in text books.  IMHO, that simply doesn't 
work in plain ASCII text.

kind regards,

Ray

-- 
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211

---

From: "STARK, BARBARA H (ATTLABS)" <[email-masked]>
Date: Fri, 12 Feb 2010 11:07:35 -0500

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).

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. 

Recommend rewording: 
      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.  
In cases where privacy for the Device or Target is legally mandated,
regulated, or otherwise important, it is critical that these issues be
resolved before permitting a third-party request. A pre-arranged
contract between the third-party, a Rule Maker and the LIS operator may
be necessary to guarantee appropriate privacy is provided when device
identifiers are used in this fashion. It is recommended that such a
contract 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.
Automated mechanisms to ensure privacy constraints are also 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.

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."

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.

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 15 Feb 2010 05:26:04 +0000

Just a reminder that this WGLC ends on Tuesday, 16 February. Please  
send comments if you have not already.

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 15 Feb 2010 13:36:20 +0800

Hi Barbara,

Thanks for the feedback.  I've made the minor corrections that you've requested.

I've responded inline to each below.

> Behalf Of STARK, BARBARA H (ATTLABS)
> Sent: Saturday, 13 February 2010 3:08 AM
> To: [email-masked]
> Subject: Re: [Geopriv] WGLC: draft-ietf-geopriv-identity-extensions
> 
> -----------------------------------------------------------------------

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.
 
> 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.

> 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.

> only if this IP address matches the source IP address of the HELD

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.

> 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

---

From: "STARK, BARBARA H (ATTLABS)" <[email-masked]>
Date: Mon, 15 Feb 2010 09:13:59 -0500

Thanks. I'm fine with all of your responses.
Barbara

> From: Thomson, Martin [mailto:[email-masked]]
> Sent: Monday, February 15, 2010 12:36 AM
> To: STARK, BARBARA H (ATTLABS); [email-masked]
> Subject: RE: [Geopriv] WGLC: draft-ietf-geopriv-identity-extensions
> 
> Hi Barbara,
> 
> 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:
> identifiers must not be used unless specific measures are taken to
> prevent spoofing.
> 
> > 2. Section 1.1
> 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:
> 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.
> 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
> 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
> > for legal, regulatory, or other reasons, an organization that
> provides
> > a
> 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".
>

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 16 Feb 2010 13:30:12 +0000

A couple of comments inline with my individual contributor hat on...

>   identifiers to retrieve location information about a particular

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.

>   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.

>   mechanisms employed for the identifier.

Just for clarity, I think the last sentence should say, "Return  
routability may also not apply. . ."

>   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

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 16 Feb 2010 13:31:06 +0000

A few more individual contributor comments inline...

On Feb 15, 2010, at 5:36 AM, Thomson, Martin wrote:

> 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:
> 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.

> location request, the location request can be authorized under the  
> LCP policy (see Section 5.1); otherwise, the request MUST have been  

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:

> location request, the location request can be authorized under the  
> LCP policy (see Section 5.1). Otherwise, the request must be treated  

> 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".
>

+1

Alissa

---

From: <[email-masked]>
Date: Tue, 16 Feb 2010 17:24:42 -0500

Hi,

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

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 17 Feb 2010 08:44:36 +0800

Thanks for the input, Alissa.  I've made these changes, but I've a few (unimportant) questions below.

> On Feb 8, 2010, at 11:43 PM, Thomson, Martin wrote:
...
> 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
> 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.
 
...
> 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

I think that Device is a better choice than Target, but it's a point well made.  Thanks.

Cheers,
Martin

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 17 Feb 2010 08:50:58 +0800

Hi Alissa,

One minor clarifying question below...

> Otherwise it sounds like a statement of fact.

Sure - it's a fine line to walk.

>   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

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 16 Feb 2010 17:16:31 -0800

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. 

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:[email-masked]] 
Sent: Monday, February 08, 2010 3:44 PM
To: Bernard Aboba; 'Alissa Cooper'; [email-masked]
Subject: RE: [Geopriv] WGLC: draft-ietf-geopriv-held-identity-extensions

Hi Bernard,

Cheers,
Martin

Section 1, OLD:

NEW:

Section 1.1, OLD:

Section 4.2, REMOVE:

Section 1.1, NEW:

Section 2, NEW:

Section 3.1, OLD:

OLD: (above)
NEW:

I'll fix the example.

Section 4.4, NEW:

Section 5, OLD:

Section 5.1, OLD:
   (above)
NEW:

Section 5.1, OLD:
   (above)
NEW:

Section 6, OLD:

--Martin

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 17 Feb 2010 14:11:26 +0800

Thanks Bernard,

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:

<https://docs.google.com/uc?id=0B8H10P2T_qIyNjJhYzZiOTEtYjEwNS00MGQzLThjNjAtOGM5MjY4MWJmNGM0&export=download&hl=en>

> From: Bernard Aboba [mailto:[email-masked]]
> Sent: Wednesday, 17 February 2010 12:17 PM
> To: Thomson, Martin; [email-masked]
> [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.
 
> [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.
> 

That is more correct, yes.

> [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. :)

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 16 Feb 2010 22:49:23 -0800

NEW:

[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. 

[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.

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 24 Feb 2010 13:28:16 +0800

I'm sorry, this one slipped the net.

Inline...

> Sent: Wednesday, 17 February 2010 5:49 PM
>    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 :) 

> [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

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 24 Feb 2010 13:31:23 +0800

> 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.

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.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 24 Feb 2010 16:42:11 -0700

On 2/23/10 10:31 PM, Thomson, Martin wrote:
>>> a U-label?  Also, I don't think you want to allow an FQDN that is
>>> a mixture of U-labels and A-labels.
>> 
>> right, U-label is what we're looking for.  The fact that you _can_
>> mix label types, doesn't mean that you should.
> 
> 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. 

Good catch.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Alissa Cooper <[email-masked]>
Date: Sun, 28 Feb 2010 21:20:32 +0000

On Feb 17, 2010, at 12:44 AM, Thomson, Martin wrote:
> Thanks, I assume that you are OK with keeping my last sentence, or  
> did you intend to have that disappear as well?
>

I did not intend for it to disappear.

> "might" rather than "may" to avoid confusion with normative text, or  
> is this an intentional shading of meaning?
>

"Might" is better, agreed.

Alissa

---

From: Alissa Cooper <[email-masked]>
Date: Sun, 28 Feb 2010 21:30:12 +0000

(Apologies for being slow on these replies...)

On Feb 17, 2010, at 12:50 AM, Thomson, Martin wrote:
> 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?