Re: [regext] WGLC: https://datatracker.ietf.org/doc/draft-ietf-regext-allocation-token

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

Scott,

Thanks 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 1/18/18, 1:57 PM, "regext on behalf of Hollenbeck, Scott" <[e-mail] on behalf of [e-mail]> wrote:

    > -----Original Message-----
    > From: regext [mailto:[e-mail]] On Behalf Of James Galvin
    > Sent: Friday, January 12, 2018 8:33 AM
    > To: Registration Protocols Extensions <[e-mail]>
    > Subject: [EXTERNAL] [regext] WGLC: https://datatracker.ietf.org/doc/draft-
    > ietf-regext-allocation-token
    > 
    > The document editors have indicated that the following document is ready
    > for submission to the IESG to be considered for publication as a Proposed
    > Standard:
    > 
    > Allocation Token Extension for the Extensible Provisioning Protocol
    > (EPP)
    > https://datatracker.ietf.org/doc/draft-ietf-regext-allocation-token-05
    
    Comments:
    
    Abstract:
    
1. The text says that "This document describes an Extensible Provisioning Protocol (EPP) extension for including an allocation token or for allocating an object like a domain name to the client", but I have no idea what an "allocation token" is based on reading the abstract. I think it would be better to say something like "This document describes an Extensible Provisioning Protocol (EPP) extension for including a <insert text here>, otherwise known as an "allocation token", or for allocating an object like a domain name to the client".

Alex had similar feedback.  Based on Alex’s feedback that abstract is being changed to:

This document describes an Extensible Provisioning Protocol (EPP) extension for including an Allocation Token in query and transform commands. The Allocation Token is used as a credential that authorizes a client to request the allocation of a specific object from the server, using one of the EPP transform commands including create, update, and transfer.

Does this abstract meet your needs?
    
    2. Please change "MAY" to "may" in the abstract.

You and Alex are on the same page.  The MAY has been removed in the revised abstract above.  
    
    Introduction: same comment re: definition of "allocation token".

Based on Alex’s feedback, similar language in the abstract is used in the revised introduction along with a definition of allocation.  
    
    "It is up to server policy which EPP transform commands and which objects support the allocation token"
    
    How does a client learn which commands and objects are supported?

This would be defined out-of-band or within a future Registry Mapping policy extension.  
    
    Section 2.1 (and 4.1): "The exact format of the Allocation Token is up to server policy."
    
    After reading this text I looked at the schema in Section 4.1 to see how it defined the allocationToken element. What I saw in 4.1 confused me a bit. The schema describes the allocationTokenType as an extension of the XML Schema "token" type, but it doesn't include any extensions or restrictions. So why not just do this?
    
    <element name="allocationToken" type="token"/>
   
    Having said that, without restrictions like minLength or maxLength I see the potential for some client-server interoperability issues. What, for example, is meant by a zero-length token? It's syntactically valid, but meaningless (I think). Might it not be better to have a minLength of 1 and some sufficiently long maxLength?

I believe that there is no reason for a zero length allocationToken element, so we can set the minimum length to 1 as in: 

  <simpleType name="allocationTokenType">
    <restriction base="token">
      <minLength value="1"/>
    </restriction>
  </simpleType>

    
    Section 5.1: The title of this section is "XML Namespace", but it seems to be conflating a registration request for an XML namespace and the XML Schema described in Section 4. I'm going to recommend registering both the namespace and the schema in the same way it's done in, for example, RFC 5731.

I revised the IANA Considerations section to match RFC 5731 and draft-ietf-regext-launchphase.
    
    Section 7: These allocation tokens feel like they should be protected in some way. They're retrieved using an <info> command, so they get TLS privacy protection while in transit -- good. What, though, should a client do to protect them while they're sitting around waiting to be used in subsequent EPP commands? At a minimum, I think some text needs to be added here to note that there are risks associated with tokens sitting in some client-side data store. Similarly, are tokens designed to be used for only a single operation? Are there risks associated with reuse? Do they expire? If not, why?
    
    Please consider these questions about the tokens as just a sample of the kinds of topics that should be addressed in Section 7.

Since draft-ietf-regext-allocation-token is a conduit for allocation tokens that are considered credentials and are defined elsewhere, I can add some considerations for defining the allocation tokens to the Security Considerations section.  The use of EPP ensures that the Allocation Token is secure in transit between the client and the server.  Considerations can include:

1. An Allocation Token SHOULD be considered secret information by the client and should be protected at rest and in transit.  
2. An Allocation Token SHOULD be single use, meaning it should be unique per object and per allocation operation.
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.
5. An Allocation Token SHOULD leverage digital signatures to confirm its authenticity if generated by a trusted 3rd party.  
6. An Allocation Token that is signed XML SHOULD be encoded (e.g., base64) to mitigate server validation issues. 
 
Are there other considerations that should be added to the list or should any of these be modified?
   
    Scott
    
    _______________________________________________
    regext mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/regext