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

["Koodli, Rajeev" <[e-mail]>]

On 7/8/14, 6:31 AM, "Leif Johansson" <[e-mail]> 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…”

-Rajeev



>
>	Cheers Leif
>