Subject: [AAA-WG]: RE: Proposed resolution of EAP issue 461: Alternate Uses and Conflicting AVPs

From: <[email-masked]>
Date: Tue, 30 Mar 2004 13:58:28 +0300

> > I think the "MUST NOT modify EAP messages" part is more
> > important; that's essentially attempting a man-in-the-middle
> > attack against the protocol, and many EAP methods have e.g.
> > method-specific result indications that prevent this
> > from even working.
> 
> [Joe] It sounds like you are arguing for not allowing an
> intermediary to change and authorization decision. The basic
> problem is that an EAP authentication decision in not
> necessarily an authorization decision.  By enforcing no
> conflicts and no modifications we make successful
> authentication equivalent to successful authorization.  
> I do not think this is so good.
>
> Perhaps authenticate and authorize functionality should only
> be used in cases where the authentication decision is
> equivalent to authorization.  In other cases two separate
> authentication followed by authorization messages should be
> used.

I agree, EAP success/failure and Diameter success/failure
Result-Code are two separate things. I'm proposing that
we enforce the "no modifications to EAP messages" part, 
but allow conflicting messages with a note explaining
why they may cause problems (this is what RFC3579 also does).

A separate Diameter AUTHORIZE_ONLY exchange doesn't really
help here, because the NAS does not have any conflicts about
what to do (it's not supposed to look inside the EAP packet).
What is really missing is a secure way to notify the client 
that "EAP went OK, but I decided anyway not to give you access".
For instance, the 802.11i four-way handshake could have had some
field denoting "authorization failed" (which would be protected
with keys derived from PMK).

> > Other than that, it's IMHO enough to say that "there are
> > circumstances where conflicting messages can't be avoided,
> > but you should be aware that it causes some problems".
> > I don't think we have to solve these problem in this document;
> > neither does RFC3579... 
> 
> [Joe] Maybe, but how does this work in 802.1x case if AAA 
> rejects, but EAP indicates success?  If we don't solve it 
> here then where do we solve it?

Since we don't have a protected "authorization failure" exchange
between the client and NAS, we seem to be stuck with either
attempting MitM attack against EAP, or sending conflicting
messages. Both usually lead to the same situation: a timeout
before the client discovers that it didn't actually get access.

In 802.11i, it seems the timeout for conflicting messages isn't
necessarily that long.  The client is expecting the first
message of four-way handshake; the default retransmission
timeout is 100 ms, and the default number of retransmissions 
is 3. Therefore, if the client doesn't receive something in, say, 
one second after EAP Success, it could deduce that something went
wrong...

(If the NAS or proxy changes the EAP Success to Failure, and 
the client ignores the Failure message because it had contradicting
method-specific indication, it seems the timeout would have
to be much longer than this.)

In plain 802.1X for e.g. wired Ethernet switch ports the timeout
could be longer, sure (no response to any ARP or DHCP
messages). But IMHO this is not something that absolutely 
needs to be solved... (and the successor of 802.1X/11i looks 
like a more logical place to solve this than Diameter EAP spec).

Best regards,
Pasi

---

From: "Joseph Salowey" <[email-masked]>
Date: Wed, 31 Mar 2004 17:53:20 -0800

[email-masked] wrote:
>>> I think the "MUST NOT modify EAP messages" part is more important;
>>> that's essentially attempting a man-in-the-middle attack against the
>>> protocol, and many EAP methods have e.g. method-specific result
>>> indications that prevent this from even working.
>> 
>> [Joe] It sounds like you are arguing for not allowing an intermediary
>> to change and authorization decision. The basic problem is that an
>> EAP authentication decision in not necessarily an authorization
>> decision. By enforcing no conflicts and no modifications we make
>> successful authentication equivalent to successful authorization.
>> Perhaps authenticate and authorize functionality should only be used
>> in cases where the authentication decision is equivalent to
>> authorization.  In other cases two separate authentication followed
>> by authorization messages should be used.
> 
> Result-Code are two separate things. I'm proposing that we
> enforce the "no modifications to EAP messages" part,
> that "EAP went OK, but I decided anyway not to give you
> access". For instance, the 802.11i four-way handshake could
> have had some field denoting "authorization failed" (which
> would be protected with keys derived from PMK).
> 

[Joe] yes, I agree I agree about the authorize only.  I'm not as strict on
modifications to EAP-Success and EAP-Failures.

>>> circumstances where conflicting messages can't be avoided, but you
>>> should be aware that it causes some problems". I don't think we have
>>> to solve these problem in this document; neither does RFC3579...
>> 
> Since we don't have a protected "authorization failure"
> exchange between the client and NAS, we seem to be stuck with
> either attempting MitM attack against EAP, or sending
> conflicting messages. Both usually lead to the same
> situation: a timeout before the client discovers that it
> didn't actually get access.
> 
> In 802.11i, it seems the timeout for conflicting messages
> isn't necessarily that long.  The client is expecting the
> first message of four-way handshake; the default
> retransmission timeout is 100 ms, and the default number of
> retransmissions is 3. Therefore, if the client doesn't receive
> something in, say, one second after EAP Success, it could deduce that
> something went wrong... 
> 
> the client ignores the Failure message because it had
> contradicting method-specific indication, it seems the
> timeout would have to be much longer than this.)
> 
> In plain 802.1X for e.g. wired Ethernet switch ports the
> timeout could be longer, sure (no response to any ARP or DHCP

[Joe] Not all lower layers behave consistently.  Perhaps we need to better
describe the potential problems with how the lower layers behave and make
recommendation upon that.  I included a modification to text below also
including EAP message modification text that aligns more closely with 3579.

"A Diameter-EAP-Answer message containing an EAP-Payload of
   type EAP-Success or EAP-Failure MUST NOT have the Result-Code
   AVP set to DIAMETER_MULTI_ROUND_AUTH.  

   When used with lower layers that treat authentication as sufficient 
   for authorization the Result-Code should match the contained EAP
   packet: a successful Result-Code
   for EAP-Success, and a failure Result-Code for EAP-Failure. In this case 
   when the encapsulated EAP packet does not match the result
   implied by the Result-Code AVP, the combination is likely to
   cause confusion, because the NAS and peer will arrive at
   different conclusions as to the outcome of the
   authentication. For example, if the NAS receives a failure
   Result-Code with an encapsulated EAP Success, it will not
   grant access to the peer.  However, on receiving the EAP
   Success, the peer will be lead to believe that it
   authenticated successfully.

   This situation can be difficult to avoid when Diameter proxy
   agents make authorization decisions (that is, proxies can
   change the Result-Code AVP sent by the home server), or when
   Diameter is used for communicating with a backend
   authentication server (see Section 2.8.5).  Since the responsibility for
   avoiding conflicts lies with the Diameter
   server, the NAS MUST NOT "manufacture" EAP result packets in order to
   correct contradictory messages that it receives.  This behavior,
   originally mandated within [IEEE8021X], will be deprecated in the
   future.
"