[regext] Benjamin Kaduk's Discuss on draft-ietf-regext-allocation-token-09: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-regext-allocation-token-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-regext-allocation-token/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

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


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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