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

[Brian Haberman <[e-mail]>]

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" <[e-mail]> wrote:
> 

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

>>
>> 8. Several of the attributes include strings in the data.  What is the
>> encoding for these strings?
> 
> 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?

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

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

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