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

[Brian Haberman <[e-mail]>]

Hi Rajeev,

On 5/8/14 12:28 PM, Rajeev Koodli wrote:
> Hi Brian,
> 
> 
> On Thu, May 8, 2014 at 7:17 AM, Brian Haberman <[e-mail]>wrote:
> 
>>> 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?
>>
>>
> Rajeev> Yes, and I would refer to 3GPP TS 23.003 (as 4187 does).
> 
> 

That works.


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

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

Regards,
Brian