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

David Mandelberg <> Tue, 31 July 2018 19:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5694F130E5F for <>; Tue, 31 Jul 2018 12:44:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.7
X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tDnvy3IjNnHL for <>; Tue, 31 Jul 2018 12:44:35 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E3827130E6C for <>; Tue, 31 Jul 2018 12:44:32 -0700 (PDT)
X_CMAE_Category: , ,
X-CNFS-Analysis: v=2.2 cv=Jaj+lgCV c=1 sm=1 tr=0 a=OXtaa+9CFT7WVSERtyqzJw==:117 a=OXtaa+9CFT7WVSERtyqzJw==:17 a=KGjhK52YXX0A:10 a=IkcTkHD0fZMA:10 a=NTnny0joGdQA:10 a=R9QF1RCXAYgA:10 a=bmmO2AaSJ7QA:10 a=BTUBnpS-AAAA:8 a=OWztEDCSwSlAc_ImmsgA:9 a=QEXdDO2ut3YA:10 a=pblkFgjdBCuYZ9-HdJ6i:22
X-CM-Score: 0
X-Scanned-by: Cloudmark Authority Engine
X-Authed-Username: ZHNlb21uQHJjbi5jb20=
Authentication-Results:; spf=neutral; sender-id=neutral
Authentication-Results:; sender-id=neutral
Authentication-Results:; auth=pass (LOGIN)
Received-SPF: neutral ( is neither permitted nor denied by domain of
Received: from [] ([] by (envelope-from <>) (ecelerity r(Core: with ESMTPSA (cipher=DHE-RSA-AES256-GCM-SHA384) id 5D/81-48830-F1CB06B5; Tue, 31 Jul 2018 15:44:31 -0400
Received: from [] (DD-WRT []) by (Postfix) with ESMTPSA id CD14F1C6093; Tue, 31 Jul 2018 15:44:30 -0400 (EDT)
To: "Gould, James" <>, "" <>, "" <>, "" <>
References: <> <>
From: David Mandelberg <>
Message-ID: <>
Date: Tue, 31 Jul 2018 15:44:28 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [secdir] secdir review of draft-ietf-regext-allocation-token-08
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 31 Jul 2018 19:44:36 -0000

On 07/31/2018 03:34 PM, Gould, James wrote:
> On 7/31/18, 2:53 PM, "David Mandelberg" <> 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.