Subject: [eap] RFC 2284bis issues

From: [email-masked] ([email-masked])
Date: Tue, 26 Feb 2002 09:27:33 +0200

Hello Thomas, Dave,

Identity privacy is an important issue especially
on public access networks. However, I don't think
we need to have a general requirement in RFC2284bis.=20
Anonymity support can be built in the EAP type.=20

Many EAP types, such as EAP/SIM, EAP/AKA, EAP/SRP, PEAP and TTLS,=20
already support anonymity. The first three use unlinkable pseudonym=20
identities. PEAP and TTLS protect the user identity with TLS.

Regards,
Henry

> -----Original Message-----
> From: ext Thomas Hardjono [mailto:[email-masked]]
> Sent: 26 February, 2002 01:55
> To: David Halasz; [email-masked]
> Subject: Re: [eap] RFC 2284bis issues
>=20
>=20
>=20
> Dave,
>=20
> There are many levels of anonymity possible.  The easiest way
> would be for a Pre-Paid card type model, where the identity
> is tied to the card.
>=20
> I would put anonymity at a lower priority as it tends to complicate
> the security protocols.
>=20
> thomas
> ------
>=20
>=20
>=20
> At 2/23/2002||03:48 PM, David Halasz wrote:
> >One concern, of EAP and wireless, is anonymity. I don't have=20
> any ideas, of=20
> >how to "hide" the user id, in the identity response. But,=20
> since it gets=20
> >broadcast, in wireless, I have heard concerns.
> >
> >         Dave H.
> >
> >At 10:53 AM 2/20/2002, Bernard Aboba wrote:
> >>Over the last few months, we've collected quite a few issues for
> >>resolution in RFC 2284bis. Here are the list of issues that we have
> >>collected, and how I would propose to resolve them.=20
> Comments welcome.
> >>
> >>1. IANA considerations. RFC 2284 does not include an IANA=20
> considerations
> >>section, and RFC 2284bis needs one. Some thoughts on what=20
> might be in such
> >>a section:
> >>
> >>    a. Reservation of some of the Type space for future=20
> use. Should this be
> >>       a single EAP method (255) or more of the space (e.g.=20
> 127-255)?
> >>
> >>    b. Statement that IANA should not allocate two Type=20
> codes for a single
> >>       EAP method.
> >>
> >>    c. Statement about reclamation of unused Type=20
> allocations. It looks
> >>      like several of the alllocated Type codes have never=20
> been used.
> >>
> >>    d. Allocation of an EAP Type code for "Vendor=20
> Specific". I have in
> >>       mind something like what RADIUS does with attribute=20
> 26. This could
> >>       take the pressure off the Type space.
> >>
> >>    e. Statement on allocation of EAP type codes. Should this be on
> >>       request? By expert review? (e.g. by sending mail to=20
> the WG) By
> >>       designated expert? Assuming that we have a vendor=20
> specific code,
> >>       the criteria might be different, (e.g. a=20
> specification and expert
> >>       review might be required).
> >>
> >>2. State machine issues. There are a lot of these. RFC 2284=20
> has only a
> >>short section describing in general terms what the protocol=20
> does. There
> >>is no detailed section describing the protocol exchange in=20
> more detail,
> >>or a formal state machine. These meaans that in many cases=20
> there is no
> >>clear answer to the question "what do you do if you receive=20
> packet X when
> >>you are in the midst of doing Y?"
> >>
> >>3.  Not allowing data traffic prior to completion of=20
> authentication. RFC
> >>2284 doesn't state specifically that this is required, because it is
> >>required by PPP -- so it probably seemed obvious and not worth
> >>mentioning. But now that EAP can be used over a variety of=20
> media, this
> >>has become a point of confusion.
> >>
> >>Proposed resolution is to indicate that an authentication=20
> conversation, once
> >>initiated, must complete before data traffic can be sent.
> >>
> >>4. EAP Success prior to mutual authentication. RFC 2284 does not
> >>include a state machine, but it seems to imply that the peer should
> >>consider authentication complete on receiving an EAP=20
> Success. Bill Arbaugh
> >>has pointed out that a client requiring mutual=20
> authentication should not
> >>consider itself "on the network" until that mutual authentication is
> >>complete, so this is broken.
> >>
> >>For example, if the peer is authenticating via a method supporting
> >>mutual auth (EAP TLS, EAP SRP, etc.) and an authenticator=20
> sends an EAP
> >>Success in the middle, the recommendation is that the text=20
> of RFC 2284bis
> >>be changed to note that the client SHOULD NOT bring
> >>up the interface and SHOULD disconnect. Comments?
> >>
> >>5. Spoofed EAP Failure. Similarly, RFC 2284 seems to imply=20
> that a peer
> >>always considers themself disconnected when receiving an=20
> EAP Failure,
> >>although it does indicate that "alternative indications of
> >>success/failure" can be considered. What if an attacker=20
> spoofs an EAP
> >>Failure outside of an authentication conversation? What if=20
> other traffic
> >>is being received at the same time, indicating that the=20
> connection is in
> >>fact up? Can the peer ignore the EAP Failure?
> >>
> >>My recommendation is that the text clarify the meaning of=20
> "alternative
> >>indications" with respect to this scenario. I believe that=20
> 802.11 and PPP
> >>both have such alternative indications -- in the case of=20
> PPP, we have LCP
> >>Terminate, in 802.11 we have Disassociate or=20
> Deauthenticate. So typically
> >>the EAP Failure will be followed by an alternative indication,
> >>particularly if it occurs "out of the blue". I think that the EAP
> >>indicator can be ignored (sometimes? all the time?) if it=20
> is at odds with
> >>the alternative indication.
> >>
> >>6. Authentication of the EAP Success. Bill suggests that an=20
> authenticator
> >>be added to the EAP Success message. My inclination is not=20
> to accept this
> >>suggestion since existing proposals (PEAP, TTLS) already support
> >>authentication and encryption of the entire EAP=20
> conversation. Comments?
> >>
> >>
> >>
> >>_______________________________________________
> >>eap mailing list
> >>[email-masked]
> >>http://mail.frascone.com/mailman/listinfo/eap
> >
> >
> >Dave Halasz
> >Cisco Systems, Inc.
> >320 Springside Drive
> >Akron, OH  44333
> >
> >_______________________________________________
> >eap mailing list
> >[email-masked]
> >http://mail.frascone.com/mailman/listinfo/eap
>=20
>=20
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>=20
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
>=20