Subject: Re: [eap] Re: [802.1] Re: 802.1X interface variable

From: John Vollbrecht <[email-masked]>
Date: Wed, 07 Jan 2004 16:01:09 -0500

I have some question about the cases.  See below -

--On Friday, January 2, 2004 2:44 PM -0800 Yoshihiro Ohba 
<[email-masked]> wrote:

> I agree with Bernard.  Please see my further comments in line.
>
> On Fri, Jan 02, 2004 at 10:50:01AM -0800, Bernard Aboba wrote:
> >
> > > I agree that overloading the AAA delivery to indicate satisfaction of
> > > both authenticator and peer policies should work in most cases, but
> > > there are two (2) cases/issues that concern me:
> >
> > > 1. This presumes the EAP method being utilized can produce a key. Does
> > > 2284bis now require only EAP methods that produce keys? Is EAP-MD5
> > > deprecated?
> >
> > > 2. The definition of 'policy' may go beyond the current EAP method.
> >
> > I think point #1 is related to the difference between protected result
> > indications and mutual authentication/key derivation.  It has been
> > claimed that running a mutually authenticating method that derives keys
> > does not provide protected result indications, but I believe that in
> > practice this is a distinction without a difference for a properly
> > designed method.
>
> I agree.
>
> In my analysis, there there are logically four cases:
>
> (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?

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

> Case C) would allow a rogue NAS between the peer and the real NAS to
> redirect traffic to the attacker's network immediately after
> successful mutual authentication and the peer will not notice the
> attack because there is no security association between the peer and
> real NAS.  This makes me think that defining a new AAA attribute does
> not provide useful information.
>
I think this is correct, except if there is an authorization the other 
direction it might provide a key.  Is there a man in the middle attack if 
there are two authorizations, one of which provides a key and the other 
does not?
> So, I think a properly designed method should always belong to case
> D).
>
does this mean an Authenticator should only call a properly designed method 
for what it does?  i.e. it should call MD5 if that is ok and TLS if that is 
required?  Presumably a return of key and success would not be enough 
unless it came from a "well designed" method.

> >
> > In order to clarify this point (which was raised in EAP Issue 207), the
> > proposed resolution was to add the following text to Section 4.2:
> >
> > "If a mutually authenticating method supports error messages,
> > then the peer and server SHOULD use them to provide
> > protected result indications. This ensures that the peer
> > and server are aware of each other's final access decision,
> > and prevents lengthy timeouts.
> >
> > For example, within EAP-TLS [RFC2716], the peer
> > always authenticates the server, and sends a TLS alert message
> > in the event of an authentication or authorization failure.
> > If the server does not receive a TLS alert message from the
> > peer and the peer continues the conversation
> > to completion (e.g. sends a FINISHED message),
> > then the server can assume that the peer
> > will accept access if granted it by the server.
> >
> > Similarly, the peer can assume that the server will grant
> > access if it does not receive a TLS alert message from the
> > server, and the server carries the conversation to completion
> > (e.g. sends a FINISHED message).
> >
> > A server may use the "access denied" TLS alert
> > after successfully authenticating the peer to indicate that a
> > valid certificate was received from the peer, but when access
> > control was applied, the server decided not to proceed."
> >
> > The implication here is that methods that provide mutual
> > authentication and key derivation as well as error messages also provide
> > protected result indications.  The absence of an error message,
> > taken in concert with successful key derivation and mutual
> > authentication, should be taken as an implication that both sides are
> > satisfied.
>
> >
> > As long as the key is only transported along with the Access-Accept
> > (never an Access-Reject), for such a method, there is no need for an
> > additional AAA variable; the presence of the key attribute provides the
> > same information.
> >
I guess an accept and a key would indicate that the remote Authorization 
Server was happy with the result - but not necessarily that the 
Authorization Server had authenticated the peer?

> > Should we require that all methods providing key derivation also
> > provide mutual authentication and error messages?  If we do this, then
> > all methods providing key derivation will automatically provide
> > protected result indications, and we can dispense with the additional
> > AAA attribute.
> >
> > There may be scenarios in which a key is derived, but there is no mutual
> > authentication (e.g. GUEST scenarios using TLS with server auth only).
> > In such situations it would be dangerous for the authenticator to
> > conclude that the peer is satisfied because a key attribute was sent;
> > it may not be.
> >
true.   the peer may now know the authenticator, but the peer may want the 
authenticator to know the peer as well.  This seems possible in net to net 
connections where a rule for both sides is that each knows the other.

> > On point #2, while RFC 2284bis only permits a single EAP authentication
> > method in one direction, it does allow another EAP authentication to be
> > run in the other direction.  As discussed in Section 2.4, there may be
> > a number of reasons why an authentication may need to be run in the
> > other direction, even though a method providing protected result
> > indications has already been run in the other direction.
> >
in
> > has already been run.
> >
> > Section 2.4 describes 3 additional factors: support for bi-directional
> > session key derivation in the lower layer, support for tie-breaking and
> > peer policy satisfaction.
> >
> > None of these factors are taken into account either by proposed AAA
> > attribute (which really only provides the authenticator with the
> > information provided in the peer's protected result indication).
>
I may be wrong, but I think the attribute is meant to provide information 
to 802.1X that it will use to implement policy.

> I agree.  It seems that point #2 is purely an issue of IEEE 802.1X,
> and there might be no need to change RFC2284bis, EAP state machine and
> AAA protocols.
>
I also think point 2 is an 802.1X issue having to do with 802.1X connection 
rules.  The proposal seems to impley that 802.1X ports may require certain 
authentication/ authorization rules to be satisfied.  It may run 
authorizations in one or both directions to try to get the rules satisfied.

-- John

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 09 Jan 2004 13:32:58 -0800

> authentication occurred?  Or can I only make a decision about whether I 

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

> seems useful to me.  
> Am I missing something here?  Certainly I can provide 

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

---

From: John Vollbrecht <[email-masked]>
Date: Sat, 10 Jan 2004 13:40:21 -0500

I try to clarify the question below --

> where there is mutual authentication but there is no key (derivation),
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?

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 11 Jan 2004 22:04:43 -0800

> walled garden environment.  Am I wrong?

That case is another form of Case C).  I think host only
authentication is as vulnerable to rogue NAS attack as server only
authentication.  How the host can know whether it is connected to the
walled garden instead of the attacker's network without authenticating
the server? 

Yoshihiro Ohba

---

From: John Vollbrecht <[email-masked]>
Date: Mon, 12 Jan 2004 20:40:37 -0500

--On Sunday, January 11, 2004 10:04 PM -0800 Yoshihiro Ohba 
<[email-masked]> wrote:

>> >>> (A) One-way authentication without key derivation (e.g.,
>> >>> MD5-Challenge) (B) One-way authentication with key derivation
>> >> authentication occurred?  Or can I only make a decision about whether
>> >> I have a key?
>> >
>> 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?
>>
>

I think a stardard case would be to have the user authenticate the server 
using TLS, then authenticate some other way over the protected connection 
into the walled garden.   For example one might setup a VPN from the client 
to an edge device leaving the walled garden. In this case I don't think it 
is necessary to do  mutual authentication initially.

John

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 12 Jan 2004 18:24:48 -0800

On Mon, Jan 12, 2004 at 08:40:37PM -0500, John Vollbrecht wrote:
> into the walled garden.   For example one might setup a VPN from the 
> client to an edge device leaving the walled garden. In this case I don't 
> think it is necessary to do  mutual authentication initially.

As long as two one-way authentications in different directions are
cryptographically bound, it is ok.  But it actually forms a mutual
authentication if we view the combined authentications as a unified
mechanism (e.g., the EAP usage in IKEv2).

Yoshihiro Ohba

---

From: John Vollbrecht <[email-masked]>
Date: Tue, 13 Jan 2004 11:31:36 -0500

--On Monday, January 12, 2004 6:24 PM -0800 Yoshihiro Ohba 
<[email-masked]> wrote:

>> >> The question is that suppose one uses TLS host only authentication
>> >> (not mutual).  Is it possible for (master) keys to be derived at
>> I think a stardard case would be to have the user authenticate the
>> server  using TLS, then authenticate some other way over the protected
>> connection  into the walled garden.   For example one might setup a VPN
>> from the  client to an edge device leaving the walled garden. In this
>> case I don't  think it is necessary to do  mutual authentication
>> initially.
>
I am not sure of your meaning.   Are you agreeing that the EAP 
authentication does not have to be mutual?  Or are you thinking the second 
authentication would be in the same method?  My thinking is that if the 
second authentication is done after the first has allowed attaching to the 
network at the walled garden, then (in this example) the first (EAP) method 
is not mutual.

In fact, if the user does not want to leave the walled garden, then the 
second authentication may never be done.  The walled garden provider does 
not care who the user is, and the user knows who the walled garden is.

I think this is ok - do you agree?

-- John

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 13 Jan 2004 09:28:22 -0800

> not care who the user is, and the user knows who the walled garden is.

I would agree that the EAP authentication does not have to be mutual
in the considered case if the following conditions are met:

o The key that is established as a result of the first (EAP) method
(which is server-only, one-way authentication) should be used ONLY for
protecting the (optional) second authentication signaling traffic, and
NOT for protecting data traffic.  (As I mentioned already, giving a
key to an anonymous user for protecting data traffic can be dangerous
for authenticated users in the same network and not much useful.)

AND

o When the second authentication (which is host-only, one-way
authentication) is performed, the first and second authentications are
cryptographically bound in order to prevent the known
man-in-the-middle attack against compound authentication methods.

> I think this is ok - do you agree?

I conditionally agree, as described above.

Yoshihiro Ohba

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 13 Jan 2004 14:47:48 -0800 (PST)

IEEE 802.1X-REV met today, and my understanding is that the resolution of
the issue was that the changes required to resolve this issue would be
made solely within the EAP State Machine document.  Since no new EAP-SM
document was available incorporating the changes, no reference was
inserted in IEEE 802.1X-REV.

As a result, this Issue exists only within the EAP WG, and there is no
need to cc: IEEE 802.1 on this issue discussion any more.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap