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

[jouni korhonen <[e-mail]>]

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


On Aug 30, 2011, at 2:52 PM, Stephen Farrell wrote:

> 
> 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.
> 
> On 08/25/2011 11:50 AM, jouni korhonen wrote:
>> 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
> 
> 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.
> 
>>    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
> 
> s/has/have/
> 
>>    also been concerns that UE IP stack might use permanent subscriber
> 
> s/UE IP stack/the UE IP stack/
> 
>>    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.
> 
> Prohibited by whom? Maybe add a reference?
> 
>> 
>> 
>> 
>> 
>>    [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
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>>