[secdir] sector review of draft-ietf-pcp-server-selection-07

Chris Inacio <inacio@cert.org> Sun, 04 January 2015 06:56 UTC

Return-Path: <inacio@cert.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 83B361A6FEF; Sat, 3 Jan 2015 22:56:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.901
X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 4sfXZxn5IRmx; Sat, 3 Jan 2015 22:56:48 -0800 (PST)
Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7E8C1A6FEE; Sat, 3 Jan 2015 22:56:48 -0800 (PST)
Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu []) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id t046ulBU008816; Sun, 4 Jan 2015 01:56:47 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1420354607; bh=j7IBLFvCbUrnqsYF5HSs0n0i0vXIme1llXakV8u+Kgg=; h=From:To:Subject:Date:Message-ID:Content-Type:Content-ID: Content-Transfer-Encoding:MIME-Version:Sender:Reply-To:Cc: In-Reply-To:References; b=L3h2WkSAaEvIB+bp+IT3Oc/Oeoae7dozxWRejeBlEdpV4GJjg1RdcZk2XFZrxstpx T02WPvPyP806gkDyQT05YlHbjF6hzg8daFS0vFtfzafZm2mFlnud1zuYYTTvgmoUBc IvC8rLNWEuSTiAYNK2aG/m64mcH39XvwOEo24wAk=
Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu []) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1456) with ESMTP id t046v00f005364; Sun, 4 Jan 2015 01:57:00 -0500
Received: from MARATHON.ad.sei.cmu.edu ([]) by CASCADE.ad.sei.cmu.edu ([]) with mapi id 14.03.0210.002; Sun, 4 Jan 2015 01:56:46 -0500
From: Chris Inacio <inacio@cert.org>
To: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-pcp-server-selection.all@tools.ietf.org" <draft-ietf-pcp-server-selection.all@tools.ietf.org>
Thread-Topic: sector review of draft-ietf-pcp-server-selection-07
Thread-Index: AQHQJ+uaAUxKUQpnyUK05uEkCW52tA==
Date: Sun, 4 Jan 2015 06:56:46 +0000
Message-ID: <0FD1DF78-8EEC-44F2-B715-9CD7405C07D6@cert.org>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <D7D84FE7BABA8C40B1799D89D9FC1330@sei.cmu.edu>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/aOzZ8bsFDPtjohqophyRRmo67_w
Subject: [secdir] sector review of draft-ietf-pcp-server-selection-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Sun, 04 Jan 2015 06:56:50 -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 with the intent of improving security requirements and considerations in IETF drafts.  Comments not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.

Generally the document is in good shape, and I would like to see one minor issue at least commented upon.

I have a single security related comment on this draft; the last sentence of section 3:

> For efficiency, the PCP client SHOULD use the same Mapping Nonce for
>   requests sent to all IP addresses belonging to the same PCP server.

Normally, I would simply say this is a crazy recommendation.  But after looking a little into what the Nonce is used for in the PCP protocol, I am slightly less distraught.  This Nonce does not appear to necessarily provide any huge amount of security except allowing the client to generate a unique token per PCP server.  Presumably there is a general MITM attack on the PCP protocol related to the Nonce as a transaction ID which is prevented by using other security protocols, TLS, etc.  (And another well known attack with the THIRD_PARTY option and lack of authentication…) Therefore, this Nonce is critical as a synchronization point between the client and the potential PCP server.  It would be nice (assuming all that is correct) to make that clear in the document, especially with a recommendation to reuse the Nonce.


In Figure 1, the lines are not aligned to the “+” on the diagrams.

In Figure 3, “rtr1” is missing a “+” on the right side connection from the top.

Chris Inacio