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

"Gould, James" <jgould@verisign.com> Tue, 31 July 2018 19:34 UTC

Return-Path: <jgould@verisign.com>
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 805A8130E2A; Tue, 31 Jul 2018 12:34:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Level:
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com
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 5-Pc5fxvZf9e; Tue, 31 Jul 2018 12:34:39 -0700 (PDT)
Received: from mail5.verisign.com (mail5.verisign.com [69.58.187.31]) (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 165ED130DF7; Tue, 31 Jul 2018 12:34:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=2796; q=dns/txt; s=VRSN; t=1533065679; h=from:to:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=Y1qz3cISa0TUvmmXDMmtEvoGvLaEZbaHlUlbEdKNgjU=; b=KdWJIfm2jSqR2I4OgjlWQmqp2O1EMPUXi36UKhbUGQXxjatCnOiqmXQC Pqc+rD6g+q7Q+gf5Satlm8ACcr7ShQjih8sxp3LUUMJh+MfTB/9Ofpr3q wWhxSYccK//Q+i+FfZ2ml2Vch34HgcAz3dlqmA8IYCJ+gF9hcZTdYOpX+ eYC8xrSIlfow7zd9eNcGCp/lT2uEg/yZ2HiUcrGLJWOzV7PqXloKsCkIe dXDL0FoDeUykSLkiM5TsKIc+AwE2lV+pLzBtOEVQ7wCbQLRXPU3mha327 C8zU+yT+L7bKLZha+VXmKl8H46BMPKAwTf9cj6jKWGTRvwGwLUSS22TFx Q==;
X-IronPort-AV: E=Sophos;i="5.51,428,1526356800"; d="scan'208";a="5230043"
IronPort-PHdr: =?us-ascii?q?9a23=3AiwOqWRIsJJzNZi5yhdmcpTZWNBhigK39O0sv0rFi?= =?us-ascii?q?tYgXKPX9rarrMEGX3/hxlliBBdydt6oazbKO+4nbGkU4qa6bt34DdJEeHzQksu?= =?us-ascii?q?4x2zIaPcieFEfgJ+TrZSFpVO5LVVti4m3peRMNQJW2aFLduGC94iAPERvjKwV1?= =?us-ascii?q?Ov71GonPhMiryuy+4ZLebxlJiTanfb9+MAi9oBnMuMURnYZsMLs6xAHTontPde?= =?us-ascii?q?RWxGdoKkyWkh3h+Mq+/4Nt/jpJtf45+MFOTav1f6IjTbxFFzsmKHw65NfqtRbY?= =?us-ascii?q?UwSC4GYXX3gMnRpJBwjF6wz6Xov0vyDnuOdxxDWWMMvrRr0yRD+s7bpkSAXwhS?= =?us-ascii?q?kHKTA37X3XhMJzgqJVoh2uqR1/zJLbbo6aL/d+YrjSfdYGSWZdRMtcVSpMCZ68?= =?us-ascii?q?YYsVCOoBOP5Vo4f8qVsJsBu+ARSjCPvywTFMnHD22LM10/8vHQrb2wEgHd0OsH?= =?us-ascii?q?PJrNXxKagfSv61w7fSzTXCdPNW2Dj96I7Sfh89pvGMWKt9fMzMwkchEAPFi0+f?= =?us-ascii?q?qY3jPz6NyOQCrXKb7+t7VeKuhG4nrQBxoj6zycs2lobJgYcVxkjB9SpjxoY6OM?= =?us-ascii?q?O3SEpgbtG6CptQuDuWN4xsQsMtRWxjpSU0yqUetJKmYCQG0okryhzRZvCdboSF?= =?us-ascii?q?4hzuWPyeLDp8nH5pZa6ziwyv/UWi1uHwTNS43VlJoyZfj9XBtWgB1xLN5cWEVv?= =?us-ascii?q?dw+0Ks1iyM2g3X8e5JJE45mbTGJJMgx7M/jZ4evEXBEyLzlkj7gq2beVgi9+O1?= =?us-ascii?q?8eroeK/mqYWZN4JsjwH+NbkhldKnDOQjNwgOQ3Cb+eOh1L3/5UH5QKtFjvkxkq?= =?us-ascii?q?TBrZ3UOdwVqrO5DAFN3Ygs6gqzAym83NQGgXYHK0hFeAqdg4fzJl7COu74De2k?= =?us-ascii?q?g1Sqijtk2/fGPrj5DpXMKHjMjqvhcK5g50JA0gY/0NJS6pxOBr0cIP/+VFX9ud?= =?us-ascii?q?PcAxMhNgy72efnCNFz1oMEXmKPB7eUMKHdsV+P++IvJ/SDaZQLuDnjMfgl5uXu?= =?us-ascii?q?jX42mV8bZ6WmwZwXaHWgEvR8P0qZeWbsgssGEWoSowUxVvLqiFyfXjJUaXeyWL?= =?us-ascii?q?g85jIgBYKjF4jDQJ2ij6KF3CigAJJWfG9GBkqLEXfyeIWOQ+0MZz6KIs99jjwE?= =?us-ascii?q?UqCsRJI71R60ug/616NrLuvK9S0Eu5LvzcJ16PPclR4s+j10E92R3HuJT2FwmW?= =?us-ascii?q?MHWyU53Lx+oUx6zFePyLR4g/tbFdNN4fNFSB01NZrYz+FhCtD9RB7BftmTRFah?= =?us-ascii?q?WNWmDik7TsgtzN8Wf0Z9B9KigwjC3yW0GL8VmKeGBJ0q/aLA0Xj9PcF9y2zJ1K?= =?us-ascii?q?M5lVkpXtNPNXG6hq547wXTHJDGnFmEmKarb6QRxy/N+3mfzWqApk1YVxRwUaqW?= =?us-ascii?q?FUwYM2ffs9X1rmbLSbOjDb4qKAQJncKLNKpGKcLul1ZuQf7lNNnaaW+rlCG3Hx?= =?us-ascii?q?negvvGYJDjdXlY3SjBBg0eng8e7WrDPAw6ASyov2PZCnlyElHiZQXl9e1WqX6n?= =?us-ascii?q?QAkz1Q7AJxltzbO75lsUiOCSDuke0b8UpGIorzFzF1+h3tXQTsaHpAdnOqxYZf?= =?us-ascii?q?s87UtJk2XDuFo5dtahIrttrl8TbwoxuFnhnV0jC4hbnuAroW8kig1oJvTcmBla?= =?us-ascii?q?ejiU3IrYO7DLJC/15h/lI/rN11rS0cy++6oT5rI/sVq17y+zEU93uVpgzt1Zlz?= =?us-ascii?q?O+75DHF0BaBZD+VVsz+zBkqqvbeSgy4cXf0ng6Yvr8iSPLx998XLht8R2nZdoK?= =?us-ascii?q?aK4=3D?=
X-IPAS-Result: =?us-ascii?q?A2HaCQA6uWBb/zGZrQpYAx0BAQUBCwGEMYEnCoN0ljODYZI?= =?us-ascii?q?cgT87CxMMD4ECgzwCF4M2NhYBAgEBAQEBAQIBAQKBBQyCNSIRSy8IATEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBCAIIByQjARoGIxFVAgEIGgI?= =?us-ascii?q?mAgICMBUQAgQBEoMgAa94gS6KS4ELiBCBQj6BEicME4JMhGgWFwomgjoxgiQCm?= =?us-ascii?q?hUDBgKGFYsujACKU4RZAYJnAgQCBAUCFIFIDIF4cBVlAYI+CYV4hRSFPm8NJI0?= =?us-ascii?q?jK4EBgRsBAQ?=
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1466.3; Tue, 31 Jul 2018 15:34:37 -0400
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%5]) with mapi id 15.01.1466.003; Tue, 31 Jul 2018 15:34:37 -0400
From: "Gould, James" <jgould@verisign.com>
To: David Mandelberg <david+work@mandelberg.org>, "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>
Thread-Topic: [EXTERNAL] secdir review of draft-ietf-regext-allocation-token-08
Thread-Index: AQHUKP/RrhuIExg0xUi9EzDFrK4PqKSpuQiA
Date: Tue, 31 Jul 2018 19:34:37 +0000
Message-ID: <DFD055B4-1140-4CC3-890F-38C1650BF4DF@verisign.com>
References: <2e0dddb7-539c-7a80-6cdc-39fbb2d42c28@mandelberg.org>
In-Reply-To: <2e0dddb7-539c-7a80-6cdc-39fbb2d42c28@mandelberg.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.e.1.180613
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="utf-8"
Content-ID: <3D63D79AC5AA06478A2CBC8A3ED6D9A3@verisign.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/s5qiWWEHBQNrOJ_v2KQYls2oIw0>
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:34:42 -0000

David,

Thank you for your review and feedback.  My responses are included below.  

  
—
 
JG



James Gould
Distinguished Engineer
jgould@Verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/> 

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.  

    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.
   
    -- 
    https://david.mandelberg.org/