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

[Eric Rescorla <[e-mail]>]

On Wed, Aug 15, 2018 at 7:42 AM, Gould, James <[e-mail]> wrote:

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

Yes, this seems like the minimum.


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


Why is this just true for transfer and not the other commands?


>     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?
>

I think you probably want this, yes.




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

Where can I find a reference for this?

-Ekr