Re: [secdir] secdir Review of draft-ietf-v6ops-3gpp-eps

jouni korhonen <jouni.nospam@gmail.com> Thu, 25 August 2011 10:49 UTC

Return-Path: <jouni.nospam@gmail.com>
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 5467321F85EC; Thu, 25 Aug 2011 03:49:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.199
X-Spam-Level:
X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.560, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1]
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 IE69-F-gl+kf; Thu, 25 Aug 2011 03:49:04 -0700 (PDT)
Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id A820021F85C0; Thu, 25 Aug 2011 03:49:04 -0700 (PDT)
Received: by yie12 with SMTP id 12so1931805yie.31 for <multiple recipients>; Thu, 25 Aug 2011 03:50:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=dOnmtK1vZFSsCLzPCBPf2P7YP8AmKF6CScfHDF2VHro=; b=imXmzn4tXs9B1Hz5fth0qff5zPWAL/2E4zmU4FWZ+pQMiovgs0k1g6eMoCutVNip6k bjw5pfRwY5pM5dnSoo6cd48DvF04koCApblYPgqXMXMiKPMSB6xNL79//+OHvA5NaMq8 XD6y7yADAAP5HhI6E9viMf2G81XhSumb1sBLM=
Received: by 10.90.23.34 with SMTP id 34mr6222495agw.90.1314269417409; Thu, 25 Aug 2011 03:50:17 -0700 (PDT)
Received: from [10.255.132.23] ([192.100.123.77]) by mx.google.com with ESMTPS id f4sm683009yhn.41.2011.08.25.03.50.15 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 25 Aug 2011 03:50:16 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: jouni korhonen <jouni.nospam@gmail.com>
In-Reply-To: <CA7AE8B2.C2F68%mundy@sparta.com>
Date: Thu, 25 Aug 2011 13:50:09 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <6425C318-F3AB-4321-A238-2828F43580E0@gmail.com>
References: <CA7AE8B2.C2F68%mundy@sparta.com>
To: Russ Mundy <mundy@sparta.com>
X-Mailer: Apple Mail (2.1084)
Cc: draft-ietf-v6ops-3gpp-eps.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] secdir Review of draft-ietf-v6ops-3gpp-eps
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: Thu, 25 Aug 2011 10:49:05 -0000

Russ,

Thanks for the review. You are echoing the same thing as the most in IESG. I crafted a bit of text that could be put into the security considerations section. I don't know if this would be enough.

- JOuni

----


   In 3GPP access the UE and the network always perform a mutual
   authentication during the network attachment [TS.33102][TS.33401].
   Furthermore, each time a PDP Context/PDN Connection gets created,
   a new connection, a modification of an existing connection and
   an assignment of an IPv6 prefix or an IP address can be authorized
   against the PCC infrastructure [TS.23203] and/or PDN's AAA server.

   The wireless part of the 3GPP link between the UE and the (e)NodeB
   as well as the signaling messages between the UE and the MME/SGSN
   can be protected depending on the regional regulation an operator
   deployment policy. User plane traffic can be confidentially
   protected. The control plane is always at least integrity and 
   replay protected, and may also be confidentially protected. The
   protection within the transmission part of the network depends
   on the operator deployment policy.

   Due the nature of 3GPP point-to-point link model, the UE and the
   first hop router (PGW/GGSN or SGW) are the only nodes on the link,
   which mitigates most of the known on-link attacks. For off-link IPv6
   attacks the 3GPP EPS is as vulnerable as any IPv6 system. There has
   also been concerns that UE IP stack might use permanent subscriber
   identities, such as IMSI and MSISDN, as the source for IPv6 address
   Interface Identifier. This would be a privacy threat and allow
   tracking of subscribers, and therefore use of IMSI and MSISDN as the
   Interface Identifier is prohibited. However, there is no standardized
   method to block such misbehaving UEs.




   [TS.33102]
              3GPP, "3G Security;  Security architecture",
              3GPP TS 33.102 10.0.0, December 2010.


   [TS.33401]
              3GPP, "3GPP System Architecture Evolution (SAE); 
              Security architecture", 3GPP TS 33.401 10.1.1,
              June 2011.

On Aug 25, 2011, at 12:43 AM, Russ Mundy wrote:

> 
> 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.
> 
> While I do agree with the factual correctness of the Security Considerations
> section (the document does not _introduce_ any security related concerns),
> the support for IPv6 in 3GPP networks described in document certainly does
> have a number of security concerns.  Some obvious examples, use of DHCP
> based address management and access control/authorization of the PDN
> Connection (shown in Figure 8).  Although these and other security issues
> are likely addressed in various other documents, it would be useful to make
> a definitive statement to that effect in the Security Considerations
> section.  It would be even more useful if some more specific references were
> to be included in parts of the document that clearly deal with security
> issues such as address management and access control and authorization.
> 
> 
>        Russ Mundy
> 
> 
> 
> 
> 
>