Re: [secdir] secdir review of draft-ietf-regext-allocation-token-08

[David Mandelberg <[e-mail]>]

On 07/31/2018 03:34 PM, Gould, James wrote:
> On 7/31/18, 2:53 PM, "David Mandelberg" <[e-mail]> wrote:
> 
>      I have reviewed this document as part of the security directorate's
>      ongoing effort to review all IETF documents being processed by the
>      IESG.  These comments were written primarily for the benefit of the
>      security area directors.  Document editors and WG chairs should treat
>      these comments just like any other last call comments.
>      
>      The summary of the review is Ready with nits.
>      
>      Section 2.1 says "The server MUST have the Allocation Token for each
>      object to match against the Allocation Token passed by the client to
>      authorize the allocation of the object." Does it make sense for a server
>      to have salted+hashed tokens instead of the tokens themselves? Or to
>      otherwise cryptographically verify tokens without storing the tokens?
>      
> JG - That sentence was modified based on the feedback from Adam Roach to change the MUST to a MAY, since draft-ietf-regext-allocation-token does not predefine the makeup of the allocation token (e.g., pre-generated or not).  There are many approaches that may be taken with the generation and validation of the allocation token, where draft-ietf-regext-allocation-token provides the conduit to pass them over EPP.

Sounds good.


>      I think there's a typo in section 7, bullet 6, and I'm not sure what the
>      intent of that sentence is.
>   
> JG - Adam Roach also caught this.  The first "should" needs to be changed to a "that", so it reads " An Allocation Token that is signed XML should be encoded (e.g., base64 [RFC4648]) to mitigate server validation issues".  This correction will be reflected in draft-ietf-regext-allocation-token-10.

That makes more sense.

-- 
https://david.mandelberg.org/