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

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

Eric,

Thank you for your review and feedback.  I provide responses to your feedback below.

  
—
 
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, 10:02 AM, "Eric Rescorla" <[e-mail]> wrote:

    Eric Rescorla 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:
    ----------------------------------------------------------------------
    
    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).

JG - "An Allocation Token should be considered secret information by the client and should be protected at rest and in transit." can be changed to "An Allocation Token should be considered secret information by the client and SHOULD be protected at rest and MUST be protected in transit."
   
    
    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------
    
    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.

JG - RFC 5731 includes support for an authorization info (<domain:authInfo>) that is an existing credential stored in the server at the time of the create command, which can be updated with an update command, that is used by the gaining client (registrar) to authorize a transfer request.  The registrant should have access to the authorization info from their sponsoring registrar to pass to the gaining registrar to authorize the transfer request.  The Allocation Token is not meant to replace the RFC 5731 authorization info, but is meant as an additional credential to authorize the "allocation" of the domain name.  A registry may hold premium domain names that have an authorization info value, and leverage the transfer command for use in allocation with the use of the additional allocation token.  Let me know if you need any additional clarification on this.  
    
    
    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?

JG - Are you requesting normative language such as "The definition of the Allocation Token SHOULD be defined outside of this mapping".  There are cases when the allocation token is a non-complex string value that does not require formal definition, so the normative SHOULD seems most appropriate here.  Do you agree?    
    
    
    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"?
    
JG - An unsigned code is a non-complex string that the server generates and stores with the domain name, which can be later validated during allocation.