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

From: Leif Johansson <[email-masked]>
Date: Mon, 07 Jul 2014 10:18:43 +0200

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.

The drafts define a set of EAP attributes for signalling wifi handover
from 3gpp devices. In general the draft is well written.

I believe the draft is more or less ready. I have two comments, one of
which is stylistic and the other may be just me misunderstanding the
EAP-AKA handshake...

1. In a few places the draft sais that the defined attributes SHOULD be
used. I would qualify this to say that "mobile nodes implementing the
spec SHOULD" since EAP is used in a lot of situations where 3gpp _could_
be used but isn't.

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.

	Cheers Leif

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Mon, 7 Jul 2014 22:51:21 +0000

Hi Leif,

Thanks for the review.

Please see inline:

>spec SHOULD" since EAP is used in a lot of situations where 3gpp _could_

You mean the ³SHOULD² should be made specific to 3GPP? If so, we can
clarify at the beginning itself.

>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.

Thanks.

-Rajeev

---

From: Leif Johansson <[email-masked]>
Date: Tue, 08 Jul 2014 15:31:17 +0200

> clarify at the beginning itself.

Thx

> 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...

	Cheers Leif

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Tue, 8 Jul 2014 16:17:50 +0000

>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

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 8 Jul 2014 17:15:21 +0000

>   a legitimate EAP server and proceeds to send the EAP-Response/

[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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

---

From: Leif Johansson <[email-masked]>
Date: Tue, 08 Jul 2014 19:16:41 +0200

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

yeah what Joe said

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Tue, 8 Jul 2014 22:20:03 +0000

RFC 4187:

"8.2 Protocol Extensibility

   EAP-AKA can be extended by specifying new attribute types.  If
   skippable attributes are used, it is possible to extend the protocol
   without breaking old implementations.  As specified in Section 10.13,
   if new attributes are specified for EAP-Request/AKA-Identity or
   EAP-Response/AKA-Identity, then the AT_CHECKCODE MUST be used to
   integrity protect the new attributes.²

So, this applies for the attribute in question.

-Rajeev

On 7/8/14, 10:16 AM, "Leif Johansson" <[email-masked]> wrote:

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

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 9 Jul 2014 04:48:19 +0000

>   integrity protect the new attributes.²

[Joe]  Makes sense.  Although it is redundant with RFC4187, It might be worth mentioning in the security considerations section that AT_CHECKCODE protects the attributes in the EAP/AKA-Identity messages once it has be verified by a valid AT_MAC.   This would help clarify that the attributes are protected and at what point they are authenticated.  It might also help remind implementers that they need to implement AT_CHECKCODE.

---

From: "Leif Johansson" <[email-masked]>
Date: Wed, 9 Jul 2014 07:32:39 +0200

> 9 jul 2014 kl. 06:48 skrev "Joseph Salowey (jsalowey)" <[email-masked]>:
> 
> 

agree!

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Wed, 9 Jul 2014 16:16:51 +0000

Fine with me.

Thanks.

-Rajeev

On 7/8/14, 10:32 PM, "Leif Johansson" <[email-masked]> wrote:

>> [Joe]  Makes sense.  Although it is redundant with RFC4187, It might be
>>worth mentioning in the security considerations section that
>>AT_CHECKCODE protects the attributes in the EAP/AKA-Identity messages
>>once it has be verified by a valid AT_MAC.   This would help clarify
>>that the attributes are protected and at what point they are
>>authenticated.  It might also help remind implementers that they need to
>>implement AT_CHECKCODE.
>
>agree!
>
>> 
>>>