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

David Mandelberg <david+work@mandelberg.org> Tue, 31 July 2018 19:44 UTC

Return-Path: <david+work@mandelberg.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5694F130E5F for <secdir@ietfa.amsl.com>; Tue, 31 Jul 2018 12:44:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.7
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDnvy3IjNnHL for <secdir@ietfa.amsl.com>; Tue, 31 Jul 2018 12:44:35 -0700 (PDT)
Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3827130E6C for <secdir@ietf.org>; 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: smtp01.rcn.cmh.synacor.com smtp.mail=david+work@mandelberg.org; spf=neutral; sender-id=neutral
Authentication-Results: smtp01.rcn.cmh.synacor.com header.from=david+work@mandelberg.org; sender-id=neutral
Authentication-Results: smtp01.rcn.cmh.synacor.com smtp.user=dseomn@rcn.com; auth=pass (LOGIN)
Received-SPF: neutral (smtp01.rcn.cmh.synacor.com: 209.6.43.168 is neither permitted nor denied by domain of mandelberg.org)
Received: from [209.6.43.168] ([209.6.43.168:54208] helo=uriel.mandelberg.org) by smtp.rcn.com (envelope-from <david+work@mandelberg.org>) (ecelerity 3.6.25.56547 r(Core:3.6.25.0)) with ESMTPSA (cipher=DHE-RSA-AES256-GCM-SHA384) id 5D/81-48830-F1CB06B5; Tue, 31 Jul 2018 15:44:31 -0400
Received: from [192.168.1.152] (DD-WRT [192.168.1.1]) by uriel.mandelberg.org (Postfix) with ESMTPSA id CD14F1C6093; Tue, 31 Jul 2018 15:44:30 -0400 (EDT)
To: "Gould, James" <jgould@verisign.com>, "draft-ietf-regext-allocation-token.all@ietf.org" <draft-ietf-regext-allocation-token.all@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
References: <2e0dddb7-539c-7a80-6cdc-39fbb2d42c28@mandelberg.org> <DFD055B4-1140-4CC3-890F-38C1650BF4DF@verisign.com>
From: David Mandelberg <david+work@mandelberg.org>
Message-ID: <cb45b438-bbf4-d9d4-fc20-67f6a192d657@mandelberg.org>
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: <DFD055B4-1140-4CC3-890F-38C1650BF4DF@verisign.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/uyTpTjAPdpC98d-h8xbuckQBg40>
Subject: Re: [secdir] secdir review of draft-ietf-regext-allocation-token-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=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" <david+work@mandelberg.org> 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/