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

From: <[email-masked]>
Date: Fri, 26 Mar 2004 10:10:13 +0200

Joseph Salowey wrote:

> >    "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.  Also, the Result-Code
> >    SHOULD match the contained EAP packet: a successful Result-Code
> >    for EAP-Success, and a failure Result-Code for EAP-Failure.
> > 
> >    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). The responsibility
> >    for avoiding conflicts lies with the EAP server. The NAS or
> >    proxy agents MUST NOT "manufacture" or modify EAP packets in
> >    order to correct contradictory messages they receive."
> 
> [Joe] I don't think this works.  Contradictory messages SHOULD NOT
> be allowed, but EAP-Messages MUST NOT be modified. This 
> basically says that an intermediate proxy SHOULD NOT fail 
> authorization, is this what we want to say? It seems that either 
> you should allow EAP-Success to be turned into EAP-Failure 
> (not the other way around) or disallow proxies.  

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.  

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

Best regards,
Pasi

---

From: "Joseph Salowey" <[email-masked]>
Date: Mon, 29 Mar 2004 12:36:46 -0800

[email-masked] wrote:
>> [Joe] I don't think this works.  Contradictory messages SHOULD NOT be
>> allowed, but EAP-Messages MUST NOT be modified. This basically says
>> that an intermediate proxy SHOULD NOT fail authorization, is this
>> what we want to say? It seems that either you should allow
>> EAP-Success to be turned into EAP-Failure (not the other way around)
>> or disallow proxies.
> 

[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 don't think we have to solve these problem in this document;

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