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

[Rajeev Koodli <[e-mail]>]

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



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


> >
> >>
> >> 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.
>
>
Yes, I understand.



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

Regards,

-Rajeev




> Regards,
> Brian
>
>
>