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

David Mandelberg <david+work@mandelberg.org> Tue, 31 July 2018 18:53 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 9605C130E60 for <secdir@ietfa.amsl.com>; Tue, 31 Jul 2018 11:53:48 -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 g74jfHVHLNtc for <secdir@ietfa.amsl.com>; Tue, 31 Jul 2018 11:53:47 -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 007C3130E73 for <secdir@ietf.org>; Tue, 31 Jul 2018 11:53:45 -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=GVRjdqUUgS0A:10 a=IkcTkHD0fZMA:10 a=NTnny0joGdQA:10 a=R9QF1RCXAYgA:10 a=bmmO2AaSJ7QA:10 a=BTUBnpS-AAAA:8 a=iiazv-oawmH03g7Men8A: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 header.from=david+work@mandelberg.org; sender-id=neutral
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 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:54196] 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 E7/9D-48830-830B06B5; Tue, 31 Jul 2018 14:53:44 -0400
Received: from [192.168.1.152] (DD-WRT [192.168.1.1]) by uriel.mandelberg.org (Postfix) with ESMTPSA id D01A71C6093; Tue, 31 Jul 2018 14:53:43 -0400 (EDT)
To: draft-ietf-regext-allocation-token.all@ietf.org, iesg@ietf.org, secdir@ietf.org
From: David Mandelberg <david+work@mandelberg.org>
Message-ID: <2e0dddb7-539c-7a80-6cdc-39fbb2d42c28@mandelberg.org>
Date: Tue, 31 Jul 2018 14:53:41 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/-urUSGJC6ZjfgyMposfZFe9rOp4>
Subject: [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 18:53:49 -0000

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?

I think there's a typo in section 7, bullet 6, and I'm not sure what the 
intent of that sentence is.

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