[secdir] secdir review of draft-ietf-v6ops-mobile-device-profile-04

Simon Josefsson <simon@josefsson.org> Sat, 31 August 2013 21:21 UTC

Return-Path: <simon@josefsson.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4BA611E8191; Sat, 31 Aug 2013 14:21:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jw28yTo0qEaL; Sat, 31 Aug 2013 14:21:31 -0700 (PDT)
Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) by ietfa.amsl.com (Postfix) with ESMTP id D93F811E8190; Sat, 31 Aug 2013 14:21:30 -0700 (PDT)
Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id r7VLLQQ1026585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 31 Aug 2013 23:21:28 +0200
Date: Sat, 31 Aug 2013 23:21:25 +0200
From: Simon Josefsson <simon@josefsson.org>
To: secdir@ietf.org, iesg@ietf.org, draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org
Message-ID: <20130831232125.19f0ceb6@latte.josefsson.org>
X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.97.8 at duva.sjd.se
X-Virus-Status: Clean
Subject: [secdir] secdir review of draft-ietf-v6ops-mobile-device-profile-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
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: Sat, 31 Aug 2013 21:21:31 -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 (informational) document list a set of features a 3GPP device is
supposed to be compliant with.  The document contain pointers to other
protocols/specifications which contains the real security
considerations for those protocols.  As such, I don't think there could
be any significant security issue with this document.  Hence my take
is that the document is Ready with nits (see below).

A notable point is that there is no discussion or references to IPSec
in the document, nor any of the IPv6 "bugs" (e.g., RFC 5722 and RFC
6946).  There may be other document that could be referenced that would
lead to improved security, but it is hard to list them all.

This document seems related to draft-ietf-v6ops-rfc3316bis which
describe another IPv6 profile for 3GPP hosts.  The utility of having
two different IPv6 profiles for 3GPP hosts could be discussed, but it
is only a security issue in the marginal sense that complexity often
leads to poor security.

The security considerations of this document is only pointers to
the security considerations of RFC3316bis, RFC6459, and RFC6092 which
feels underwhelming to me -- especially since the RFC3316bis security
consideration is for the particular profile that RFC3316bis defines.
The security considerations of RFC3316bis wouldn't automatically apply
to the profile defined by draft-ietf-v6ops-mobile-device-profile since
the profiles are different.

Other notes:

* The document uses RFC 2119 language "for precision", although I don't
  understand what it means for an Informational document to contain
  MUST languages.

* The document really really should reference RFC 2460.

* The security consideration contains normative text (REQ#34) that
  typically go into the core part of a document.

* I found REQ#32 a bit too generalized.  I believe it is common for
  applications to be aware of whether connections are over IPv4 or IPv6
  and behave differently.
   >REQ#32:  Applications MUST be independent of the underlying IP
   >       address family. This means applications must be IP version
   >       agnostic.

/Simon