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

From: Russ Mundy <[email-masked]>
Date: Wed, 24 Aug 2011 17:43:14 -0400

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

---

From: jouni korhonen <[email-masked]>
Date: Thu, 25 Aug 2011 13:50:09 +0300

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.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 30 Aug 2011 12:52:21 +0100

Hi Jouni,

Just checking - do you intend to push out a new version with this
included before the telechat next week?

A few nits below as well.

Ta,
Stephen.

>     deployment policy. User plane traffic can be confidentially

s/confidentially/confidentiality/ would be better.

If you can add references as to how that can be achieved that
would also be good.

The same points apply for the control plane I guess.

>     attacks the 3GPP EPS is as vulnerable as any IPv6 system. There has

s/has/have/

>     also been concerns that UE IP stack might use permanent subscriber

s/UE IP stack/the UE IP stack/

>     method to block such misbehaving UEs.

Prohibited by whom? Maybe add a reference?

---

From: jouni korhonen <[email-masked]>
Date: Tue, 30 Aug 2011 16:07:49 +0300

Stephen,

Thanks for picking up the nits. And yes, I would push out a new version with the additional security consideration text below, *if* folks think it is worth having it there.

And for prohibiting the use of IMSI/MSISDN (or any "3GPP identity") as the IID, the reference would be Section 5.3.1.2.2 of [TS.23401].

- Jouni

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 30 Aug 2011 14:22:25 +0100

I think its worth including. Why don't you talk to Ron and
see if he'd prefer you to push out a version now or not and
we can go from there.

Cheers,
S.

---

From: jouni korhonen <[email-masked]>
Date: Wed, 31 Aug 2011 10:40:11 +0300

I have just uploaded -05 with updated security considerations section.

- Jouni

On Aug 30, 2011, at 4:43 PM, Ronald Bonica wrote:

> I think that it would be a good idea to spin a new version before the call next week.
> 
>                                            Ron
> 
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>> Stephen Farrell
>> Sent: Tuesday, August 30, 2011 9:22 AM
>> To: jouni korhonen
>> Cc: Russ Mundy; [email-masked];
>> [email-masked]; [email-masked]
>> Subject: Re: secdir Review of draft-ietf-v6ops-3gpp-eps
>> 
>> 
>>> Thanks for picking up the nits. And yes, I would push out a new
>> version with the additional security consideration text below, *if*
>> folks think it is worth having it there.
>>> 
>>> And for prohibiting the use of IMSI/MSISDN (or any "3GPP identity")
>> as the IID, the reference would be Section 5.3.1.2.2 of [TS.23401].
>>> 
>>> - Jouni
>>> 
>>> 
>>>>> 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
>>>>> 
>>>>> ----
>>>>> 
>>>>>