Summary: Has 2 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.
(I agree with Ekr's DISCUSS about these being bearer tokens and am happy to see the discussion on improving the text there.) There are a couple of other things that I seek discussion on: The document itself does very little to motivate the addition of the allocation token, from a security point of view. In what security model is there a security advantage from having this sort of single-use authorization token as opposed to using existing authentication and authorization methods? The use case of a premium domain-name auction that came up in Ekr's ballot thread is actually quite enlightening, in that the token allows for the authorization to be granted to the winner of an auction even in the case where the winning bidder and the current registration owner do not have any common authentication or authorization infrastructure (other than for the auction and its payment itself). Some generalization of these considerations into a model that matches the generalized functionality in the draft would be a quite helpful addition. This could also be leveraged in the discussion of why the allocation token is not needed in the various commands for which its usage is not provided (mentioned in my COMMENT). I also request changes to the examples (or the discussion surrounding them). Using "abc123" as the example allocation token is probably unwise, as that value provides none of the properties we desire from allocation tokens. If you don't want to use an actual random-looking (e.g., self-encrypted server-generated) or signed value because it makes the examples too long, at least provide some text indicating that "abc123" is a placeholder and real tokens should have a different structure. Similarly, the passwords used in the examples hardly have enough entropy to be considered secure by modern standards.
(section-by-section) Section 1 A client MUST pass an Allocation Token known to the server to be authorized to use one of the supported EPP transform commands. It is up to server policy which EPP transform commands and which objects require the Allocation Token. The language could probably be tightened up for greater clarity about when the MUST applies, and perhaps be consistent about "supported" vs. "require" between sentences. Section 1.1 represents lines returned by a protocol server. Indentation and white space in examples are provided only to illustrate element relationships and are not a REQUIRED feature of this protocol. It would be nice to rephrase this so that "NOT REQUIRED" could be together/majuscule. Maybe, "to illustrate element relationships and implementations are NOT REQUIRED to adhere to such whitespace and formatting"? The XML namespace prefix "allocationToken" is used for the namespace "urn:ietf:params:xml:ns:allocationToken-1.0", but implementations MUST NOT depend on it and instead employ a proper namespace-aware XML parser and serializer to interpret and output the XML documents. Maybe I'm misunderstanding, but isn't this kind-of inviting sloppy implementations that don't check? Sometimes we say things like "this prefix is used in the examples for concision but actual usage is expected to vary between fully scoped and shortened versions". Section 3.1.1 2. If an object requires an Allocation Token and the Allocation Token does not apply to the object or an object does not require an Allocation Token, then the server SHOULD return the availability status as unavailable (e.g., "avail" attribute is "0" or "false"). It's really unclear why these two cases are not distinguished in a machine-readable way (i.e., not the text of the reason). (Also in 3.2.4, etc.) Section 3.1.2 [...] Authorized clients MAY retrieve the Allocation Token (Section 2.1) along with the other object information using the <allocationToken:info> element. [...] The causality here is a bit weird; it seems like the client is requesting to retrieve the token by including <allocationToken:info> in its request so that the server knows to include it in the response (where it is retrieved from an <allocationToken:allocationToken> element). If the query was successful, the server replies with an <allocationToken:allocationToken> element, as described in Section 2.1. Section 2.1 describes the contents of the element, not how the server replies with it. Maybe, "interpreted as described in" would be better? Section 3.1.3 It would probably be good to have some discussion of why the <transfer> query command (as opposed to transform command) does not benefit from having this additional authorization-checking mechanism. Section 3.2.1 The EPP <create> command provides a transform operation that allows a client to create an instance of an object. In addition to the EPP command elements described in an object mapping like [RFC5731], the command MUST contain a child <allocationToken:allocationToken> This MUST is only for the cases when an allocation token is to be used, right? (Similarly in 3.2.4, etc.) element for the client to be authorized to create and allocate the object. If the Allocation Token does not apply to the object, the server MUST return an EPP error result code of 2201. nit: Maybe "supplied Allocation Token"? Section 3.2.2, 3.2.3, 3.2.5 Similarly to for Section 3.1.3, some text on why the additional authorization is not useful would be helpful. Section 4.1 <annotation> <documentation> Extensible Provisioning Protocol v1.0 Allocation Token Extension. </documentation> </annotation> nit: are this many line breaks needed? I also question the minLength of 1 for an allocation token value. Why couldn't it be more like 16 or even 32? I would put this in the DISCUSS section but maybe there are mitgating circumstances I'm unaware of.
Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3061 These are bearer tokens and therefore I believe transport encryption needs to be required in S 7, not just listed as should (which isn't even normative in this context).
S 3.2.4. > like [RFC5731], the command MUST contain a child > <allocationToken:allocationToken> element for the client to be > authorized to transfer and allocate the object. The authorization > associated with the Allocation Token is in addition to and does not > replace the authorization mechanism defined for the object's > <transfer> request command. If the Allocation Token is invalid or I'm having trouble processing this statement. Can you explain in more detail what the two access control checks are here. S 7. > specifications apply to this specification as well. > > The mapping acts as a conduit for the passing of Allocation Tokens > between a client and a server. The definition of the Allocation > Token is defined outside of this mapping. The following are security > considerations in the definition and use of an Allocation Token: Do you want to use normative language here? S 7. > 3. An Allocation Token should have a limited life with some form of > expiry in the Allocation Token if generated by a trusted 3rd > third party, or with a server-side expiry if generated by the > server. > 4. An Allocation Token should use a strong random value if it is > based on an unsigned code. What is an "unsigned code"?
Substantive Comments: - General: As far as I can tell, the document doesn't explain what an Allocation Token _is_. It talks about how it is used and what it contains, but I'm not sure what one represents semantically, or how it gets created, destroyed, etc. I see Section 7 mentions that Allocation Tokens are defined elsewhere; is there something that can be referenced? If not, would it be reasonable to add a high level summary to the introduction? §3.1.1: "Availability of allocation.example and allocation2.example domain names are based on the Allocation Token ’abc123’" I'm confused by this, since the example shows a "mismatch" result for allocation.example. §3.2.1, 2nd paragraph: I'm confused by the idea of a token mismatch for an object that has not yet been created. (Please see my general comment; some discussion of the lifecycle of allocation tokens would be helpful.) Editorial Comments: §1.1, last paragraph: The "REQUIRED" seems like a statement of fact. §3.1.1: "If an object requires an Allocation Token and the Allocation Token does not apply to the object or an object does not require an Allocation Token..." That's hard to parse. Please consider separate cases for "required but does not apply" and "not required".
BCP 14 can be referenced in the usual way, it doesn't need a URL reference.
I agree with Ben and Alexey (and others) that it would be helpful for the document to be clearer in the introduction about the motivations (what and why) this is being done. Also, thanks to Al Morton for the OpsDir review.
Two quick questions (and I'm really no expert here, so these questions might be stupid): 1) Why should the check return 'unavailable' if the object does not require an Allocation Token but the check is send with an Allocation Token (sec 3.1.1)? Is that obvious to everybody else but me or should that maybe be further explained in the doc? And inline with that, why is it not a MUST to return 'unavailable' if a Token is required but the sent token doesn't match? 2) Why is this mechanism not applied to delete, renew, and update?
I am looking forward to reading answers to Mirja's questions. I think the Introduction section can be improved in explaining how allocation token is used and why it is needed.