Location Configuration Extensions for Policy Management
draft-ietf-geopriv-policy-uri-07

[Ballot comment]
- Just adding 32 random bits to the mix might not be enough if you have
~ 2^32 clients. Worth noting?

- 2^(N/2)/T is likely to be error-prone. One more set of parenthesis
would be good.

(used to be discuss point #8 but shouldn't have been)
Why not acually define a good policy URI generation function rather
than give all these partial hints? I don't even necessarily mean as a
MTI but rather as a good example of how to do it.

[Ballot discuss]
#1 Intro para 2 says that the deref protocol provides a PEP, but just
having read it, it doesn't, except for in that very very limited sense
of supporting authorization-by-possession. So the claim seems wrong.
I'd say just removing the claim is easiest.

(I guess I agree with Tobias' Apps area review points being a discuss,
so... I've broken the overall points down into a number of specific
things below, hopefully that'll help get 'em sorted quicker.)

#2 Why even allow HTTP URIs? Why not insist on HTTPS for this?
geopriv-deref does (almost correctly) insist on use of TLS so it seems
illogical for this to be more open. In any case, the same choices would
be best for both of these specs I think wrt TLS usage.

#3 For the case where a policy URI is a "shared secret," what TLS
server auth settings are required to be used? Would it be good to say
the client MUST NOT offer TLS_*_anon_* ciphersuites in the client
hello?

#4 Saying the policy server SHOULD allow all requests (3.1 2nd para)
seems unwise. It may be reasonable to allow for the URI-is-secret
model, but I don't get why you want to prevent anything more? (That's
how I interpret the SHOULD.) Saying (at the end of section 3) that a
new policy URI MUST be generated whenever a new location URI set if
generated also seems to work against any other (better;-) kind of
authorization.

#5 Assuming URIs remain secret seems problematic. Is there evidence
that the confidentiality of these URIs can be maintained really?

#6 Describing the policy URI as a shared secret doesn't seem to be
enough. I think you need to say that it MUST be a practically
unguessable shared secret, even if I have seen many such URIs. The DHCP
option in 4.2 means that anyone can I guess get the server to emit
loads of policy URI values.

#7 Why is it reasonable to have a default of making location available
(to possessor's of the URI)? Couldn't that be dangerous in conjunction
with some other defaults (e.g. some other protocol might default to
including a location URI in a message), or is there somewhere in
geopriv where it says that the overall default is that location
information has to be denied by default?

#8 cleared see comment

#9 What is the argument that 2^32 unique policy URIs is a big enough
number?

#10 (2^(N/2))/T is meant to restrict an unlimited attacker to one
successful guess per T seconds? Is that correct and the intent?  Be
better to explain your logic there. If that is the intent, I don't see
why its considered a good thing. (Be fun to sse if my arithmetic is
screwed up there or not;-)

#11 What are the likely values of T that will be used? It seems odd to
only introduce a lifetime value like this at this point.  Maybe you
mean that T is some value derived from system behaviour rather than a
parameter? If the former, then is it reasonable to expect the rate
limiting enforcement function to have that number available to it?

[Ballot comment]
I'm with Stephen and Jari on this one and definitely support Stephen's discuss.  This really feels like security through obscurity, but if I let you see mine then you can be me for while.

[Ballot discuss]
I will probably clear this after some discussion in the IESG tonight, and let Stephen hold his Discuss (item #5 in particular).

However, I am concerned that the document provides an authorization-by-possession model for clients to access their policies, delivers the policy URLs in the same DHCP and XML structures as other location URLs, and also acknowledges that there is a legitimate need for other entities to access policies:

  This document does not describe
  how policy might be provided to entities other than for location
  configuration, for example, in responses to dereferencing requests
  [I-D.ietf-geopriv-deref-protocol] or requests from third parties
  [RFC6155].

I predict that policy URLs will be leaked, intentionally, to those who need them, and that this will lead to security issues down the road. Is there something that we could do about this?

[Ballot discuss]
idnits reports a Normative downref to the Informational RFC 2818.  It
doesn't appear that the downref was announced in the IETF last call.

[Ballot comment]
I concur with the DISCUSS position of Stephen Farrell.

Why does this specification use the term "Internet host" instead of the term "Target" from RFC 3693? Consistency across this suite of documents would be good.

It would be helpful to cite RFC 3693 and RFC 5808 in Section 2.

In Section 4.1, the schema references "urn:ietf:params:xml:ns:geopriv:held:policy" but that namespace is never used in the schema definition.

In the examples, it would be helpful to point to the specifications that define the various data structures (i.e., the "urn:ietf:params:xml:ns:geopriv:held", "urn:ietf:params:xml:ns:common-policy", and "urn:ietf:params:xml:ns:geolocation-policy" namespaces).

The second block of XML in Section 5.3 never defines the gp: prefix (i.e., you need to add xmlns:gp="urn:ietf:params:xml:ns:geolocation-policy" to the root  element).

[Ballot comment]
Please consider the review of Tobias Gondrom . I will defer to the expertise of the Security ADs to consider whether the issues he points out are worthy of DISCUSSion, but I have not seen a public reply to his message.

[Updated to add:]
I note from the writeup that there are no implementations of this. I also note that geopriv-policy is given as an example of what might be used as a policy document in addition to the others. Is my suspicion correct that, in fact, down the road geopriv-policy will be the *predominant* use of this URI? If so, is it not worth holding this document until that one is completed? I suspect it will end up a lot shorter if it could talk in terms of an actual GEOPRIV policy document and use the others only as examples. (I see no need to hold a DISCUSS position on this, as I think there is no harm in publishing this first, but I would like to hear from the authors/chair/WG as to what the reasoning was.)

[Ballot comment]
- Just adding 32 random bits to the mix might not be enough if you have
~ 2^32 clients. Worth noting?

- 2^(N/2)/T is likely to be error-prone. One more set of parenthesis
would be good.

[Ballot discuss]
#1 Intro para 2 says that the deref protocol provides a PEP, but just
having read it, it doesn't, except for in that very very limited sense
of supporting authorization-by-possession. So the claim seems wrong.
I'd say just removing the claim is easiest.

(I guess I agree with Tobias' Apps area review points being a discuss,
so... I've broken the overall points down into a number of specific
things below, hopefully that'll help get 'em sorted quicker.)

#2 Why even allow HTTP URIs? Why not insist on HTTPS for this?
geopriv-deref does (almost correctly) insist on use of TLS so it seems
illogical for this to be more open. In any case, the same choices would
be best for both of these specs I think wrt TLS usage.

#3 For the case where a policy URI is a "shared secret," what TLS
server auth settings are required to be used? Would it be good to say
the client MUST NOT offer TLS_*_anon_* ciphersuites in the client
hello?

#4 Saying the policy server SHOULD allow all requests (3.1 2nd para)
seems unwise. It may be reasonable to allow for the URI-is-secret
model, but I don't get why you want to prevent anything more? (That's
how I interpret the SHOULD.) Saying (at the end of section 3) that a
new policy URI MUST be generated whenever a new location URI set if
generated also seems to work against any other (better;-) kind of
authorization.

#5 Assuming URIs remain secret seems problematic. Is there evidence
that the confidentiality of these URIs can be maintained really?

#6 Describing the policy URI as a shared secret doesn't seem to be
enough. I think you need to say that it MUST be a practically
unguessable shared secret, even if I have seen many such URIs. The DHCP
option in 4.2 means that anyone can I guess get the server to emit
loads of policy URI values.

#7 Why is it reasonable to have a default of making location available
(to possessor's of the URI)? Couldn't that be dangerous in conjunction
with some other defaults (e.g. some other protocol might default to
including a location URI in a message), or is there somewhere in
geopriv where it says that the overall default is that location
information has to be denied by default?

#8 Why not acually define a good policy URI generation function rather
than give all these partial hints? I don't even necessarily mean as a
MTI but rather as a good example of how to do it.

#9 What is the argument that 2^32 unique policy URIs is a big enough
number?

#10 (2^(N/2))/T is meant to restrict an unlimited attacker to one
successful guess per T seconds? Is that correct and the intent?  Be
better to explain your logic there. If that is the intent, I don't see
why its considered a good thing. (Be fun to sse if my arithmetic is
screwed up there or not;-)

#11 What are the likely values of T that will be used? It seems odd to
only introduce a lifetime value like this at this point.  Maybe you
mean that T is some value derived from system behaviour rather than a
parameter? If the former, then is it reasonable to expect the rate
limiting enforcement function to have that number available to it?

[Ballot comment]
Please consider the review of Tobias Gondrom . I will defer to the expertise of the Security ADs to consider whether the issues he points out are worthy of DISCUSSion, but I have not seen a public reply to his message.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Location Configuration Extensions for Policy Management) to Proposed Standard


The IESG has received a request from the Geographic Location/Privacy WG
(geopriv) to consider the following document:
- 'Location Configuration Extensions for Policy Management'
  as a Proposed Standard

This is a second last call to verify a change in intended status from Informational to Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-12-12. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Current location configuration protocols are capable of provisioning
  an Internet host with a location URI that refers to the host's
  location.  These protocols lack a mechanism for the target host to
  inspect or set the privacy rules that are applied to the URIs they
  distribute.  This document extends the current location configuration
  protocols to provide hosts with a reference to the rules that are
  applied to a URI, so that the host can view or set these rules.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-geopriv-policy-uri/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-geopriv-policy-uri/


No IPR declarations have been submitted directly on this I-D.

One of the IANA Actions in this document is dependent on the approval of
another document.

IANA understands that, upon approval of this document, there are three
actions which IANA must complete.

First, in the namespaces registry of the IANA XML registry located at:

http://www.iana.org/assignments/xml-registry/ns.html

a new registration will be added as follows:

ID: held
URI: urn:ietf:params:xml:ns:geopriv:held:policy
Registration Template: [ as provided in Section 6.1 of the approved
document ]
Reference: [ RFC-to-be ]

Second, in the schema registry of the IANA XML registry located at:

http://www.iana.org/assignments/xml-registry/schema.html

a new registration will be added as follows:

ID: held:policy
URI: urn:ietf:params:xml:schema:geopriv:held:policy
Filename: [ as provided in Section 4.1 of the approved document ]
Reference: [ RFC-to-be ]

Third, the document requests that a value to the LuriTypes registry.  It
appears that the Luritypes registry has not yet been created but would
be upon approval of the following document:

draft-ietf-geopriv-dhcp-lbyr-uri-option

Upon approval of both that document and the current document, a new
registration would be added to the new Luritypes registry as follows:

+------------+----------------------------------------+--------------+
|  LuriType  |  Name                                | Reference    |
+------------+----------------------------------------+--------------+
|    TBD*    |  Policy-URI                          | [ RFC-to-be ]|
+------------+----------------------------------------+-----------+--+

IANA understands that these are the only actions required to be
completed upon approval of this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Location Configuration Extensions for Policy Management) to Informational RFC


The IESG has received a request from the Geographic Location/Privacy WG
(geopriv) to consider the following document:
- 'Location Configuration Extensions for Policy Management'
  as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-10-25. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Current location configuration protocols are capable of provisioning
  an Internet host with a location URI that refers to the host's
  location.  These protocols lack a mechanism for the target host to
  inspect or set the privacy rules that are applied to the URIs they
  distribute.  This document extends the current location configuration
  protocols to provide hosts with a reference to the rules that are
  applied to a URI, so that the host can view or set these rules.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-geopriv-policy-uri/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-geopriv-policy-uri/


No IPR declarations have been submitted directly on this I-D.

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

The document shepherd for this document is Alissa Cooper. I have personally reviewed this version of the document and believe that it is ready for publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The document has had reviews from several working group participants, experts from the RAI and APP areas, and from an OGC participant. I do not have any concerns about the level of review.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

I do not believe that any particular further reviews are necessary.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

I have no major concerns. The WG thoroughly discussed issues around authorization and security related to this document, and I believe the resulting outcome is sound. There have been no IPR disclosures filed.


(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is consensus behind this document among the members that do the majority of the work in this WG. It is a small extension to the core work of the group.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

I am not aware of any threat of appeal.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

The document satisfies all ID nits. The document does not require any formal reviews.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

The references are appropriately split into normative and informative. The only non-RFC normative reference is to draft-ietf-geopriv-dhcp-lbyr-uri-option, which is in IESG review. There are no downward references.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

The IANA considerations section is consistent with the body of the document. The section appropriately registers a new URN sub-namespace, an XML schema, and a DHCP LuriType. The document does not require new registries or expert review.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

I have checked that all of the XML correctly validates.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

Current location configuration protocols are capable of provisioning
an Internet host with a location URI that refers to the host's
location. These protocols lack a mechanism for the target host to
inspect or set the privacy rules that are applied to the URIs they
distribute. This document extends the current location configuration
protocols to provide hosts with a reference to the rules that are
applied to a URI, so that the host can view or set these rules.

Working Group Summary
Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?

This document was uncontroversial. It fills a gap in the location configuration architecture.

Document Quality
Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?

At this time there are no known implementations, nor are there any reviewers or experts that merit a special mention.