[secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05

Yaron Sheffer <yaronf.ietf@gmail.com> Fri, 16 May 2014 14:05 UTC

Return-Path: <yaronf.ietf@gmail.com>
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 987531A0069; Fri, 16 May 2014 07:05:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id itHnb9YPiwVE; Fri, 16 May 2014 07:05:35 -0700 (PDT)
Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09CD21A0062; Fri, 16 May 2014 07:05:34 -0700 (PDT)
Received: by mail-wi0-f175.google.com with SMTP id f8so1018265wiw.2 for <multiple recipients>; Fri, 16 May 2014 07:05:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=afHPPkbKw9ZvT8N/1dzhmAQ5nzRqfY6zSanuYjMSVhk=; b=G4/IDteERd+Jz0sHl3aYUtKouLlmb4w0L0m7dlQVxbqP9iBWrj4MoTmyBdEFugxFk+ 7eVcalw8anfgvLo8HXbtylyu2XOHSKQJfl1D8GcPXmjbRQnLBt/q200+BSV5cK//IIIc ICz8lsziqdavQV60xv7BdWf0aR/BABgtlBFj6n9y3Th4WN9PV8DBnme9iPMMy2iTPpVe 5JT/oeawAgJWy5zKecLCFgIb7q3ovMQ4Bdnl+XQr3PRzdBPmmKgq3Cp4j4wlOGE45QPJ 5eAGu30/UCDw4jXjOB+t0gPRtkRqXZh7zT8/mhw0ENI6Gr4dn8VAYOdwXaZCilk4vh8v cd0Q==
X-Received: by with SMTP id dv1mr14017749wib.37.1400249126531; Fri, 16 May 2014 07:05:26 -0700 (PDT)
Received: from [] (bzq-79-179-142-94.red.bezeqint.net. []) by mx.google.com with ESMTPSA id fs5sm3532089wic.22.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 16 May 2014 07:05:25 -0700 (PDT)
Message-ID: <53761B24.1060501@gmail.com>
Date: Fri, 16 May 2014 17:05:24 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: IETF Security Directorate <secdir@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/k2FkFJmfQ7EYZfmaVVE8ExtQwz4
Subject: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05
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: Fri, 16 May 2014 14:05:36 -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.

This document proposes to add cryptographic authentication to LDP "all
routers" Hello messages, which are transported as unicast UDP.


The document may be ready to publish, but this reviewer has major
issues with the selected solution.


• The main issue is that only a symmetric crypto option is defined.
IMHO, adding a public-key based scheme would be invaluable. Public keys
do not necessarily imply certificates, and can be used with little added
complexity compared to the current proposal. As far as I can see, the 
current use is not so performance constrained to preclude public key 
operations. And public keys would enable much easier and more secure 
deployment in many cases:
	∘ Different organizations can accept messages from one another, without 
needing to share the same keys. So even if groups keys are used (which 
is certainly not the best practice), public keys have an advantage.
	∘ Revocation is much simpler: to be able to revoke each individual 
sender (e.g. when a router is decomissioned), you need N**2 SAs in the 
symmetric case, vs. N keys when public keys are used.
• Managing the 32-bit SAID manually in a large network is extremely 
onerous. So in practice keys would be rarely on never changed.

• 2.2: the authentication algorithm and the authentication key are not
"independent", because the algorithm normally determines the key length.

• 2.2: the various time values included in the SA essentially require
(rough) time synchronization between the nodes. If this is the case, 
time values could have been used for replay protection, which would have 
been much simpler to implement than the 64-bit sequence number which 
needs to persist across reboots.

• 5.1: Redefining HMAC (RFC 2104) is an extremely bad idea. This 
reviewer does not have the appropriate background to critique the 
proposed solution, but there must be an overwhelming reason to reopen
cryptographic primitives.

• 7: 128-bit keys are OK (or overkill) for some algorithms, but too
short for others. In general, the recommended key length is not
constant. It depends on the algorithm.

• "The mechanism described herein is not perfect and does not need to be
perfect." This is kind of vague, and would be better replaced by your
security goals.