[secdir] SecDir review of draft-ietf-dna-simple-11

Yaron Sheffer <yaronf@checkpoint.com> Wed, 18 November 2009 17:56 UTC

Return-Path: <yaronf@checkpoint.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 825B93A6AB0; Wed, 18 Nov 2009 09:56:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.554
X-Spam-Level:
X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=1.044, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBafr0mD2T2f; Wed, 18 Nov 2009 09:56:15 -0800 (PST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id A02393A6920; Wed, 18 Nov 2009 09:56:14 -0800 (PST)
Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nAIHuAGo001970; Wed, 18 Nov 2009 19:56:10 +0200 (IST)
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 18 Nov 2009 19:56:17 +0200
From: Yaron Sheffer <yaronf@checkpoint.com>
To: secdir <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-dna-simple.all@tools.ietf.org" <draft-ietf-dna-simple.all@tools.ietf.org>
Date: Wed, 18 Nov 2009 19:56:15 +0200
Thread-Topic: SecDir review of draft-ietf-dna-simple-11
Thread-Index: AcpoeGxYXUdrY+VLRKuuzZmGkUkAXA==
Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF888AD7B@il-ex01.ad.checkpoint.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF888AD7Bilex01adche_"
MIME-Version: 1.0
Subject: [secdir] SecDir review of draft-ietf-dna-simple-11
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Wed, 18 Nov 2009 17:56:18 -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 provides a simple procedure (for some value of "simple") to detect whether an IPv6 node is reconnecting into a network it's previously seen.

I should prefix these comments by a big disclaimer re: my very basic IPv6 expertise.

Security

The Security Considerations are focused on one specific aspect, namely the use of SEND. I think we should make clear here that none of the DNA operations by themselves add any measure of security, unless SEND is actually used. Specifically, I suggest to add the text: "The DNA procedure does not in itself provide positive, secure authentication of the router(s) on the network, or authentication of the network itself, as e.g. would be provided by mutual authentication at the link layer. Therefore when such assurance is not available, the host MUST NOT make any security-sensitive decisions based on the DNA procedure. In particular, it MUST NOT decide it has rejoined a network known to be physically secure, and proceed to abandon cryptographic protection."

Other Comments

4.1: DUID - is this the host's DUID or the router's? Per RFC 3315, both have such a value.
4.3: "all currently configured IP addresses" - but only for this physical interface, right?
4.8: why is no DAD performed? Someone else might have joined the network while I was disconnected, and has a duplicate of my address.