[secdir] Secdir review of draft-ietf-mif-problem-statement-07

"Joseph Salowey (jsalowey)" <jsalowey@cisco.com> Mon, 23 August 2010 20:09 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 CC4013A6AE9; Mon, 23 Aug 2010 13:09:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.188
X-Spam-Status: No, score=-110.188 tagged_above=-999 required=5 tests=[AWL=0.411, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id 7vlUpQsM2+Zr; Mon, 23 Aug 2010 13:09:34 -0700 (PDT)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com []) by core3.amsl.com (Postfix) with ESMTP id 13A463A6AD2; Mon, 23 Aug 2010 13:09:34 -0700 (PDT)
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEALNyckyrR7H+/2dsb2JhbACgOnGiG5t+hTcEhDWILg
X-IronPort-AV: E=Sophos;i="4.56,259,1280707200"; d="scan'208";a="244074475"
Received: from sj-core-2.cisco.com ([]) by sj-iport-5.cisco.com with ESMTP; 23 Aug 2010 20:10:07 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com []) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7NKA375017025; Mon, 23 Aug 2010 20:10:07 GMT
Received: from xmb-sjc-225.amer.cisco.com ([]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Aug 2010 13:10:05 -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, 23 Aug 2010 13:10:03 -0700
Message-ID: <AC1CFD94F59A264488DC2BEC3E890DE50B4CFB04@xmb-sjc-225.amer.cisco.com>
Thread-Topic: Secdir review of draft-ietf-mif-problem-statement-07
Thread-Index: ActC/yvgoazSCrxeTxmIJOll6YW/jQ==
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: <iesg@ietf.org>, <secdir@ietf.org>, <draft-ietf-mif-problem-statement.all@tools.ietf.org>
X-OriginalArrivalTime: 23 Aug 2010 20:10:05.0092 (UTC) FILETIME=[2D195640:01CB42FF]
Subject: [secdir] Secdir review of draft-ietf-mif-problem-statement-07
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: Mon, 23 Aug 2010 20:09: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 discusses a problem statement about a single host
supporting multiple interfaces and configuration associated with those
interfaces.   The document does have a security considerations section,
however I think it could benefit from more security discussion.  Here
are a few suggestions:

1) Lower layer authentication and encryption

It's possible that some interfaces may have link layer or IP layer
encryption and authentication.  Its possible that this characteristic
might be used in determining how configuration parameters are processed.
Some connection managers may already do this to a certain extent.  I
think this should be listed as a consideration in the appropriate
sections of the document (3.1, 3.6,5)

2) I think the security considerations can be expanded

It discusses that information may be leaked from one network to another
which seems to be talking about generic data.  This is true, but it
seems that would be worthwhile to talk specifically about the
information discussed in the document.  For example it seems that it is
at least possible for one interface to send configuration parameters
that will cause a denial of service on another interface.  It may also
be possible for one host to set configuration parameters which cause
certain traffic to be forwarded to an attacker.  

The last paragraph is also not very clear.  What I think you are trying
to say is that the information that is used by the connection manager
may be vulnerable to spoofing and forgery if it is unprotected.  In
general its not possible to protect this information in all cases, so it
is not clear what you are recommending.