eap Mailing List: Re: Re: [802.1] Re: 802.1X interface variable

[Yoshihiro Ohba (yohba]

On Wed, Jan 07, 2004 at 04:01:09PM -0500, John Vollbrecht wrote:
> 
> I have some question about the cases.  See below -
> 
> --On Friday, January 2, 2004 2:44 PM -0800 Yoshihiro Ohba 
> <yohba [at] tari.toshiba.com> wrote:
> 
> >(A) One-way authentication without key derivation (e.g., MD5-Challenge)
> >(B) One-way authentication with key derivation
> >(C) Mutual authentication without key derivation
> >(D) Mutual authentication with key derivation
> >
> >Case A) does not provide protected method indication and thus the
> >authentication server cannot securely know whether the peer is
> >satisfied.  So, defining a new AAA attribute does not provide useful
> >information to the pass-through authenticator.
> 
> is the assumption then that if there is no key that there is no mutual 
> authentication?  Does this overload the key to mean that mutual 
> authentication occurred?  Or can I only make a decision about whether I 
> have a key?

I am not sure I understand the question, but there is certainly a case
where there is mutual authentication but there is no key (derivation),
which is Case C).

> 
> >
> >With regard to Case B), the GUEST scenario using TLS with server auth
> >only as mentioned by Bernard is an example of this case, and I agree
> >with Bernard saying that this would be dangerous.  I even think that
> >giving keys to unauthenticated peers is almost equivalent to providing
> >unauthenticated access without any per-packet protection, and the key
> >derivation does not seem to be a useful feature in Case B).
> >
> I thought that the key would allow secure connection over the air.  This 
> seems useful to me.  
> Am I missing something here?  Certainly I can provide 
> access to a walled garden and then require authentication to get out.

If both unauthenticated and authenticated clients can equally obtain a
key and establish secure connection to the NAS with using the key, it
will be a threat for authenticated clients.  An attacker can spoof an
authenitcated client's MAC address and perform IEEE 802.11
Disassociation (which is unprotected) on the spoofed MAC address,
obtain a key as a guest, and finally hijack the authenticated client's
traffic by also spoofing the victim's IP address.  Unless
Disassociation is protected, or protected disconnect procedure is
provided at a higher layer, or different access networks are used for
unauthenticated and authenticated clients, giving a key to guest seems
to be dangerous.

Yoshihiro Ohba