Subject: [netext] AD Evaluation: draft-ietf-netext-wifi-epc-eap-attributes

From: Brian Haberman <[email-masked]>
Date: Wed, 07 May 2014 11:54:09 -0400

All,
     I have performed my review of
draft-ietf-netext-wifi-epc-eap-attributes as a part of the IETF
publication process.  These comments will need to be addressed prior to
IETF Last Call.

1. The draft has several nits that need to be fixed.  Please run id-nits
and resolve the warnings generated.

2. The document states that these new EAP attributes can be used in WiFi
networks.  Later, it talks about networks that employ 802.1X.  Please be
more specific as to what is covered under the generic WiFi in the
context of this specification.

3. Please change all occurrences of EUTRAN to E-UTRAN (per RFC 6459).

4. Given the use of PMIP as an example, please include an informative
reference to the relevant PMIP RFC(s).

5. There is no expansion/definition of P-TMSI or M-TMSI in the draft.
Those terms do not appear in RFC 6459.  Please clarify these acronyms on
first use.

6. The document notionally mentions 3GPP and references GPRS.  Are those
the target 3G/4G networks?  Is this applicable to LTE or other
technologies? More clarity here would be useful.

7. In section 4, it would be beneficial to include forward references to
the actual option specification sections for the AT_* attributes.

8. Several of the attributes include strings in the data.  What is the
encoding for these strings?

9. The attributes all contain Length fields with no description of what
fields are included in the length.

10. Are the sub-types and types in 5.2, 5.3, 5.5, & 5.6 set in stone?
Could new ones be defined in the future?  If so, you will want to
consider if they should be IANA registries.  Otherwise, future RFCs will
need to update this spec to extend the type/sub-type values supported.

11. I am confused by the relationship between the attributes defined in
sections 5.4 and 5.5.  Would the AT_HANDOVER_SESSION_ID attribute ever
be used without the AT_HANDOVER_INDICATION?  If not, why have the
session id in a separate attribute?  It seems straightforward to include
the session id info in the AT_HANDOVER_INDICATION attribute if Type=1.
Am I missing something?

12. The formatting of figure 7 is messed up.

13. I see that there are no normative references.  At a minimum, it
seems like the EAP specs should be normative.

14. The Security Considerations section tells me nothing.  Are there new
threats with these new pieces of information flowing across the network?
 What are the privacy implications of these messages?  Can any of the
possible threat vectors be minimized?

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Thu, 08 May 2014 10:17:22 -0400

Hi Rajeev,
     Snipping down to just the open questions/issues...

On 5/7/14 7:53 PM, Koodli, Rajeev wrote:
> 
> On 5/7/14, 8:54 AM, "Brian Haberman" <[email-masked]> wrote:
> 

> Reference to 802.1X is illustrative as in WiFi networks. The new EAP
> attributes are applicable for trusted non-3GPP networks in general, but to
> WiFi in particular.
> 

I think that it would be good to clarify that in the Introduction.

> The encoding would follow 3GPP TS 23.003 as do the attributes in RFC 4187.
> Will mention this.
> 

I see a single reference to ASCII encoding for the username string in
4187.  Is ASCII encoding assumed here as well?

> This is a good point. AFAIK, there is no existing registry for these kinds
> of sub-types and types.
> Wondering pros and cons of creating a new registry..Thoughts?
> 

It depends on how much the authors/WG think this spec will be extended.
 If you don't envision much change to these (sub-)types, the registry
isn't useful.  If there is potential to see new values (e.g., new
connectivity types for AT_CONNECTIVITY_TYPE), a registry minimizes the
need to have future RFCs update this one.  I would suggest an analysis
of potential new (sub-)type values coming along in the future.

> AT_HANDOVER_SESSION_ID also includes the Access Technology in addition to
> the Session Id.
> 
> 
> We can do this by embedding Access Technology into the existing Pad field
> for Type = 1. 
> (So, Pad if Type = 0, Access Technology if Type = 1). If this seems okay,
> I don¹t mind combining the two.
> 

Combining them makes sense if AT_HANDOVER_SESSION_ID is never sent
without the corresponding AT_HANDOVER_INDICATION.

> We are basically following RFC 4187 here. The relevant part is 12.7 which
> refers to new attribute types:
> 
> 
> "As described in Section 8, EAP-AKA allows the protocol to be extended
>    by defining new attribute types.  When defining such attributes, it
>    should be noted that any extra attributes included in
>    EAP-Request/AKA-Identity or EAP-Response/AKA-Identity packets are not
> included in the MACs later on, and thus some other precautions must
>    be taken to avoid modifications to them.²
> 
> 
> We do not have attributes that fit this requirement ( I¹ll double check
> again).
> In any case, we can refer to this text.

The security considerations in 4187 are quite detailed in some
instances.  I think it would be good to document any potential
security/privacy issues that could arise if these new attributes are
abused in some way.

Regards,
Brian

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 8 May 2014 09:28:49 -0700

Hi Brian,

> 4187.  Is ASCII encoding assumed here as well?
Rajeev> Yes, and I would refer to 3GPP TS 23.003 (as 4187 does).

> of potential new (sub-)type values coming along in the future.
ok.

> without the corresponding AT_HANDOVER_INDICATION.
Yes, I understand.

> security/privacy issues that could arise if these new attributes are
4187 is extensive because the attributes there have to do with the EAP-AKA
mechanism itself.

The attributes here are not related to the EAP-AKA itself, but extensions
carried along with the EAP-AKA messages.

Let me think about this further.

Regards,

-Rajeev

---

From: Brian Haberman <[email-masked]>
Date: Thu, 08 May 2014 12:32:39 -0400

Hi Rajeev,

> Rajeev> Yes, and I would refer to 3GPP TS 23.003 (as 4187 does).

That works.

> Let me think about this further.

Sure.  I want to make sure we head off any late issues when the Sec-Dir
review occurs.

Regards,
Brian