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

[Eric Rescorla <[e-mail]>]

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


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


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?


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