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

[Brian Haberman <[e-mail]>]

Hi Rajeev,
    The changes look reasonable.  I will start IETF Last Call shortly.

Regards,
Brian


On 6/10/14 12:19 PM, Rajeev Koodli wrote:
> Hi Brian,
> 
> we have submitted a new version reflecting the comments/conversation.
> 
> http://www.ietf.org/internet-drafts/draft-ietf-netext-wifi-epc-eap-attributes-08.txt
> 
> I have revised the draft based on what we agreed on.
> 
> - introduced a new registry for various sub-types
> - expanded security considerations
> - clarified multiple issues
> - fixed ID nits
> 
> I have left the AT_HANDOVER_SESSION_ID as is, since combining it with
> HANDOVER_INDICATION introduces clumsy header logic.
> 
> Please have a look.
> 
> Thanks.
> 
> -Rajeev
> 
> 
> 
> On Thu, May 8, 2014 at 9:32 AM, Brian Haberman <[e-mail]>
> wrote:
> 
>> 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
>>
>>
>>
>