[secdir] Secdir review of draft-ietf-mip4-generic-notification-message-09

"Joseph Salowey (jsalowey)" <jsalowey@cisco.com> Tue, 08 September 2009 04:32 UTC

Return-Path: <jsalowey@cisco.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id A447328C126; Mon, 7 Sep 2009 21:32:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.587
X-Spam-Status: No, score=-6.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id MWS5MfSkXxg6; Mon, 7 Sep 2009 21:32:11 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com []) by core3.amsl.com (Postfix) with ESMTP id C30A53A6A76; Mon, 7 Sep 2009 21:32:11 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAKd6pUqrR7PE/2dsb2JhbADCE4hDAY59BYQYgVk
X-IronPort-AV: E=Sophos;i="4.44,350,1249257600"; d="scan'208";a="238483432"
Received: from sj-dkim-4.cisco.com ([]) by sj-iport-1.cisco.com with ESMTP; 08 Sep 2009 04:32:38 +0000
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com []) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n884Wc0a002521; Mon, 7 Sep 2009 21:32:38 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com []) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n884WcAu006763; Tue, 8 Sep 2009 04:32:38 GMT
Received: from xmb-sjc-225.amer.cisco.com ([]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Sep 2009 21:32:37 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 07 Sep 2009 21:32:36 -0700
Message-ID: <AC1CFD94F59A264488DC2BEC3E890DE508AF8EC8@xmb-sjc-225.amer.cisco.com>
Thread-Topic: Secdir review of draft-ietf-mip4-generic-notification-message-09
Thread-Index: AcowPWQqcdrJ6bOkQLWdQhZupDz2Lg==
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: secdir@ietf.org, iesg@ietf.org, draft-ietf-mip4-generic-notification-message@tools.ietf.org, mip4-chairs@tools.ietf.org
X-OriginalArrivalTime: 08 Sep 2009 04:32:37.0902 (UTC) FILETIME=[64FE82E0:01CA303D]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2398; t=1252384358; x=1253248358; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20<jsalowey@ci sco.com> |Subject:=20Secdir=20review=20of=20draft-ietf-mip4-generic- notification-message-09 |Sender:=20; bh=aoUhVqGsyp+Wb5gdl+Y3K28WaX86IFiSX+JXHYnMgRM=; b=fAoGZUw85GQWE9n4ykVtBHjyqzRHwa8oYo7BnXb23YGJns6A4CtsRQCQNZ k+FXDlUd8jfIKImApfYEQKZRybcIcB+SSiIamnq54WaPA4UdANGjs18wQA3b PcYKbcc387;
Authentication-Results: sj-dkim-4; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; );
Subject: [secdir] Secdir review of draft-ietf-mip4-generic-notification-message-09
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: Tue, 08 Sep 2009 04:32:12 -0000

 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.

I have primarily focused on the security considerations section in this
document.  I also quickly reviewed the rest of the document.  Based on
my review I have the following comments:

1. In section 4.1, Identification

It states "nonces" are optional.  Nonces are not mentioned in the rest
of the document.  This option should be removed.  

2. Section 4.1, extensions

I found this section confusing as to when the AE is required.  It seems
the document states that the AE is always required, however it also uses
optional.   For example its not clear to me what is required in the case
given is section 3.2.

3. Section 4.2, extensions

Shouldn't the AE be required for GNAM?

4. Security considerations Section 8

It also wasn't quite clear to me when the AE is optional and mandatory.

5. Section 8.1

There are several places in the document where different replay
mechanisms are alluded to, included this section.  This section states
that nodes must agree on the mechanism used.  However there appears to
be no way to signal what mechanism is in use.  Is this assumed to be
pre-configured in each node, or is there another mechanism for this?  Is
this realistic for deployments? 

6. Section 8.1.1

NTP RFC 1305 needs to be included in the normative references.

Why is it important "those bits which are not available from a time
source SHOULD be generated from a good source of randomness" ? (it seems
that you don't really want bits to be random since you want to enforce

This section also talks very briefly about clock synchronization.  It
seems there could be security implications here.  One node may be able
to poison a clock to an in appropriate value.  There probably should be
more discussion here.  

7. Section 8.2 

This section makes a statement but does not describe how impacts the
security of the system.  Since authentication is not performed can you
use the extension defined in the document in this case?  What is the
effect of the lack of authentication.