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

["Gould, James" <[e-mail]>]

Benjamin,

Thank you for the review and feedback.  My responses to your feedback are embedded below with a "JG - " prefix.

  
—
 
JG



James Gould
Distinguished Engineer
[e-mail]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/> 

On 8/15/18, 12:01 PM, "Benjamin Kaduk" <[e-mail]> wrote:

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

JG - There are many use cases where draft-ietf-regext-allocation-token can be used to contain an allocation token to authorize allocation of a domain name.  There was similar feedback from the WG, which was addressed by the addition of the second paragraph in the Introduction, which was to list the known use cases for allocation via the Allocation Token.  The purpose of draft-ietf-regext-allocation-token is to be the conduit to support the currently known allocation and yet to be defined allocation use cases.  We don't want to have the protocol overly prescribe a specific use case, since it fills a critical role of enabling the tokens to be passed over EPP in an explicit manner without attempting to override the authorization info mechanism defined in RFC 5731.  As noted in my response to Eric's feedback, the initial auction use case was the catalyst for draft-ietf-regext-allocation-token, but other use cases came up where draft-ietf-regext-allocation-token met the need like pre-eligibility validation and founders program registrations.  
    
    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.
    
JG - I can add a paragraph to the "Conventions Used in This Document" section that indicates that the "abc123" token value is used as a placeholder value in the examples.  The server MUST support token values that follow the Security Considerations.     
    
    ----------------------------------------------------------------------
    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.
    
JG - This pretty much says that the client MUST pass an Allocation Token to the server that the server supports and can validate.  The "to be authorized..." portion of the sentence can be removed, since that is covered by the second sentence.  Does it tighten it up by stating "A client MUST pass an Allocation Token to the server that the server supports and can validate" in the first sentence?    

    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"?
   
JG - How about "Indentation and white space in the examples are provided only to illustrate element relationships and are NOT REQUIRED in the protocol."?
 
       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".

JG - I believe this disallows sloppy implementations by using the normative MUST NOT depend on the "allocationToken" prefix.  If an implementation is dependent on the use of the "allocationToken" XML namespace prefix, it would not be compliant with the protocol, which mitigates a sloppy implementation.    
    
    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.)

JG - I don't understand what you mean by "in a machine-readable way".  The cases for the check response cover the expected value of the "avail" flag in the check response in RFC 5731, when applying the Allocation Token in the check command, which is the key machine-readable attribute returned to the client.  The  <domain:reason> is human-readable and not discussed in the two cases, since it should not drive client-side logic.  
    
    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).

JG - That is correct, querying for the allocation token is explicit by the inclusion of the empty <allocationToken:info> element in the info command.  There is no need for the server to return it if the client does not need it.  
    
       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?

JG - Maybe this can be rephrased similar to the info response description in RFC 8334 as "If the query was successful, the server replies with an <allocationToken:allocationToken> element along with the regular EPP <resData>.  The <allocationToken:allocationToken> element is described in section 2.1."  Is this 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.

JG - This is consistent language to other EPP extensions, where the extension defines explicitly what commands don't apply and doesn't attempt to cover why they don't apply.  See section 3.6 and 3.7 in RFC 8334, or section 5.1.1, 5.1.3, 5.2.2, and 5.2.3 in RFC 5910.
    
    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.)

JG - Yes, that is correct.  This is consistent with other EPP extensions, where the normative language applies to when the extension is needed or used.  
    
       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"?

JG - Ok, I can change "If the Allocation Token does not apply..." to "If the supplied Allocation Token does not apply...".  
  
  
    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.

JG - This is consistent language to other EPP extensions, where the extension defines explicitly what commands don't apply and doesn't attempt to cover why they don't apply.  See section 3.6 and 3.7 in RFC 8334, or section 5.1.1, 5.1.3, 5.2.2, and 5.2.3 in RFC 5910. 
    
    Section 4.1
    
         <annotation>
           <documentation>
             Extensible Provisioning Protocol v1.0
             Allocation
             Token Extension.
           </documentation>
         </annotation>
    
    nit: are this many line breaks needed?
    
JG - This can be fixed.  
    
    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.

JG - The makeup of the token itself it not defined by draft-ietf-regext-allocation-token, so the only requirement that draft-ietf-regext-allocation-token needs to apply is that the <allocationToken:allocationToken> element is not empty.