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

[Rajeev Koodli <[e-mail]>]

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