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

[Stephen Farrell <[e-mail]>]

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.

On 08/30/2011 02:07 PM, jouni korhonen wrote:
>
> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>
>