eap Mailing List: Re: EAP Keying Framework - section 1.4.1

[Jari Arkko (jari.arkko]

Right. Also, many protocols, including EAP, are vulnerable
to denial-of-service where mitms forge some of the fields
in the initial packets. The end result is that you don't get
access. Unfortunately, there is usually little we can do about
that. Well, the protocol could have been designed better
to have more resistance against these types of attacks, but
there'd still be other attacks with the same end-result.

--jari

Bernard Aboba wrote:

> The Authenticator can make the decision based on the 
> EAP-Response/Identity.  If the asserted identity corresponds to one 
> for which the Authenticator has local credentials, it can respond by 
> proposing one of the locally implemented EAP methods.  If the EAP peer 
> NAKs the proposal and suggests a method that is not implemented on the 
> Authenticator, then the Authenticator can forward the 
> EAP-Response/Identity to the backend authentication server.
>
> There is some discussion of this in RFC 3748, Section 2.3:
>
>   Unless the authenticator implements one or more authentication
>   methods locally which support the authenticator role, the EAP method
>   layer header fields (Type, Type-Data) are not examined as part of the
>   forwarding decision.  Where the authenticator supports local
>   authentication methods, it MAY examine the Type field to determine
>   whether to act on the packet itself or forward it.  Compliant pass-
>   through authenticator implementations MUST by default forward EAP
>   packets of any Type.
>
>
>
> > From: Thomas Otto <t.otto [at] sharevolution.de>
> > To: eap [at] frascone.com
> > Subject: [eap] EAP Keying Framework - section 1.4.1
> > Date: Tue, 22 Nov 2005 13:54:54 +0100
> >
> > In section 1.4.1, Mode independence, the draft says:
> >
> >    While the authenticator may implement some EAP methods locally and
> >    use those methods to authenticate local users, it may at the same
> >    time act as a pass-through for other users and methods, forwarding
> >    EAP packets back and forth between the backend authentication server
> >    and the peer.
> >
> > How can the authenticator (in context of 802.11: the access point) then
> > decide which authentication it should do self and which 
> > authentication to
> > relay to the backend authentication server?
> >
> > Both MAC address of the peer and identity, delivered in EAP-Response/
> > Identity(id) are no good choice, because they can easily be forged.
> >
> > Thomas
> > _________________________________________________________________
> > To unsubscribe or modify your subscription options, please visit:
> > http://lists.frascone.com/mailman/options/eap/bernard_aboba%40hotmail.com 
>
>
>
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/options/eap/jari.arkko%40piuha.net