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

[John Vollbrecht (jrv]

I try to clarify the question below --

--On Friday, January 9, 2004 1:32 PM -0800 Yoshihiro Ohba 
<yohba [at] tari.toshiba.com> wrote:

> 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).
The question is that suppose one uses TLS host only authentication (not 
mutual).  Is it possible for (master) keys to be derived at authenticator 
and peer?  I think this is possible and desirable for allowing access to a 
walled garden environment.  Am I wrong?

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