Re: [secdir] secdir review odraft-ietf-netext-wifi-epc-eap-attributes

On Jul 8, 2014, at 9:17 AM, Koodli, Rajeev <rajeev.koodli@intel.com> wrote:

> 
> 
> On 7/8/14, 6:31 AM, "Leif Johansson" <leifj@sunet.se> wrote:
> 
>> On 2014-07-08 00:51, Koodli, Rajeev wrote:
>>> 
>>>> 
>>>> 2. It seems like AT_CONNECTIVITY_TYPE is signalled before the EAP
>>>> challenge is completed. Unless I misunderstood something I think this
>>>> warrants a discussion in the Security Considerations section. Currently
>>>> the text in that section only talks about when attributes are to be
>>>> processed but there is no discussion of possible threats based on when
>>>> attributes are transmitted.
>>> 
>>> We can clarify this.
>>> 
>>> The AT_CONNECTIVITY_TYPE attribute indicates what connectivity type MN
>>> wants to use. The Network (³3GPP AAA Server²) communicates with the
>>> subscriber database ("3GPP HSS") to retrieve MN credentials, but this is
>>> outside the scope of this ID and is specific to 3GPP. Regardless, the
>>> Network provides back to the MN what is supported (based on the
>>> credentials obtained from the subscriber database). So, the MN signaling
>>> the attribute does not create new threats.
>>> 
>> 
>> Yeah I understand how the attribute works. What I don't understand is
>> how the MN knows it gets the AT_CONNECTIVITY_TYPE from the right source
>> since this handshake happens before the EAP authentication has finished.
>> 
>> Again - I may just be confused about EAP...
> 
> 
> The MN verifies the AUTN (AKA parameter) sent in EAP-Request/AKA-Challenge
> to conclude the legitimacy of the source. At this point, EAP-AKA has not
> completed yet. If AUTN verification is successful, the MN responds back
> with EAP-Respone/AKA-Challenge. See RFC 4187, Section 3:
> 
> "The peer runs the AKA algorithm (typically using an identity module)
>   and verifies the AUTN.  If this is successful, the peer is talking to
>   a legitimate EAP server and proceeds to send the EAP-Response/
>   AKA-Challenge…”
> 

[Joe] Is the attribute in question protected by AT_MAC?  If not, its possible that it could be modified in transit.  

> -Rajeev
> 
> 
> 
>> 
>> 	Cheers Leif
>> 
> 
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview