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

From: <[email-masked]>
Date: Thu, 25 Mar 2004 16:10:19 +0200

Hi!

I think the key name part of this issue is already 
covered by issue #460. Would this change be ok?

Change Section 2.8.2 from

   "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 (successful Result-Code
   if EAP-Success, and a failure Result-Code for EAP-Failure).
   TO BE WRITTEN: clarify this."

To

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

Best regards,
Pasi

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> ext Joseph Salowey
> Sent: Thursday, March 04, 2004 3:52 AM
> To: [email-masked]
> Subject: [AAA-WG]: Issue eap: Alternate uses and conflicting AVPs
> 
> 
> 
> Submitter name: Joe Salowey 
> Submitter email address: [email-masked] 
> Date first submitted: 3/3/2004 
> Reference: 
> Document: eap 
> Comment type: E
> Priority: '1' Should fix 
> Section: 2.8.2 and 2.8.5
> Rationale/Explanation of issue: 
> 
> Since EAP keying has the concept of the key name this should 
> probably be
> returned along with the Master Key. 
> 
> It might be goos to provide some motivation behind the 2.8.2
> recommendation. I think the basic reason is that often lower layer
> protocols do not distingush between authentication and authorization.
> In these protocols the EAP-Success translates to a granting of access.
> If one were dealing with lower layer protocols that handled this
> differently then perhaps the having conflicting AVPs in some 
> cases might
> not be so bad. 
> 
> The alternate use of using Diameter to interface to an EAP
> authentication server from an authorization server introduces some
> interesting behavior.  It could be possible that the authentication
> succeeds and the authorization fails.  In this case it would seem that
> the authorization server should turn the EAP-Payload to an EAP-Failure
> to be in line with 2.8.2.  It might also be noted that this behavior
> when used with certain EAP methods may cause a EAP timeout in lower
> layers that expect the authorization decision to match the EAP
> Authentication decision.
> 
>

---

From: "Joseph Salowey" <[email-masked]>
Date: Thu, 25 Mar 2004 09:47:06 -0800

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

>> probably be returned along with the Master Key.
>> 
>> In these protocols the EAP-Success translates to a granting of
>> access. If one were dealing with lower layer protocols that handled
>> this differently then perhaps the having conflicting AVPs in some
>> cases might not be so bad. 
>> 
>> succeeds and the authorization fails.  In this case it would seem
>> that the authorization server should turn the EAP-Payload to an
>> EAP-Failure to be in line with 2.8.2.  It might also be noted that
>> this behavior when used with certain EAP methods may cause a EAP
>> timeout in lower layers that expect the authorization decision to
>> match the EAP Authentication decision.