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

[John Vollbrecht (jrv]

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:

> 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