Subject: [AAA-WG]: Another proposed change to Diameter NASREQ (EAP roundtrips)

From: [email-masked]
Date: Fri, 25 May 2001 17:19:36 +0300

Hi all,

In some EAP types, the last EAP-Response from the authenticating
peer to the Diameter server is just an aknowledgement that doesn't contain
any actual data. In these cases, one NAS-AAA-NAS roundtrip can be 
saved if the AAA server is able to indicate successful authentication
in the Diameter command that contains the last EAP-Request.

So I'd like to propose the following changes in the 
Diameter NASREQ draft:

Section 4.0 on page 20 reads:
   If the Result-Code AVP indicates success,
   the EAP-Payload AVP MUST encapsulate an EAP-Success [25] payload, 
   and the NAS SHOULD successfully terminate the PPP authentication 
   phase.

Please replace that with: 
   If the Result-Code AVP indicates success, the EAP-Payload AVP MUST 
   encapsulate an EAP-Success or an EAP-Request [25] payload, and the 
   NAS SHOULD successfully terminate the PPP authentication phase. 
   Even if the payload encapsulates an EAP-Request, the authentication
   has been successful. In these cases, the NAS successfully terminates
   the PPP authentication phase by first sending the encapsulated
EAP-Request
   to the authenticating peer. Then on receipt of the corresponding
EAP-Response, 
   the NAS SHOULD send an EAP-Success to the authenticating peer.
   The NAS MUST NOT send the last EAP-Response to the Diameter server 
   but it MUST discard the EAP-Response.

Please add a new item in the list of Section  4.2.1:

   5) A Diameter-EAP-Answer containing an EAP-Request encapsulated
      within an EAP-Payload and a Result-Code indicating success.

Please include EAP-Request in the explanations of the first paragraph 
of Section 4.2.2. Like this:

   The Diameter-EAP-Answer (DEA) message, indicated by the Command-Code
   field set to 268 and the 'A' bit set in the message flags field, is
   sent by the Diameter server to the client to indicate either a
   successful or failed authentication. The Diameter-EAP-Answer message
   SHOULD include an EAP payload of type EAP-Success, EAP-Request or 
   EAP-Failure encapsulated within an EAP-Payload AVP. The Result-Code AVP 
   MUST indicate a failure if the EAP-Failure payload is present, while the
   AVP MUST indicate success if the EAP-Success or the EAP-Request payload 
   is present.

---

From: Patrice Calhoun <[email-masked]>
Date: Fri, 25 May 2001 08:07:39 -0700 (PDT)

May I kindly request that all proposed changes include an issue request, as we
have been doing to track all issues.

Furthermore, I would like to remind everyone that we agreed at the Minn IETF
that we wouldn't accept new features. Please keep this in mind when requesting
new features, and provide the necessary justification for all new issues.

Thanks,

PatC

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 25 May 2001 09:09:15 -0700 (PDT)

RFC 2284  indicates that EAP Success and EAP Failure message are
unacknolwedged. Therefore there is no way for an EAP Response to be sent
after that. 

Also note that RFC 2869 does *not* require that any EAP message be
included in an Accept or Reject, or that the EAP Success or Failure
indication be consistent with the Accept or Reject indication. This seems
weird at first, but then you realize that often the EAP entity and AAA
server are different pieces of code, and may take actions for different
reasons. For example, the authentication may be ok, but policies are
violated so that a Reject is sent. Or the authentication failed, but
access is being authorized based on called or calling station id instead,
so an Accept is sent. 

My answer to the situations where an EAP message isn't present, or
disagrees with the Accept or Reject is for the NAS to *manufacture* an
EAP-Success or Failure message rather than passing through what is in the
encapsulated EAP message. That way the peer always gets a consistent view
of the state of the conversation.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 25 May 2001 09:16:38 -0700 (PDT)

> new features, and provide the necessary justification for all new issues.
Actually, we agreed at IETF 50, not to accept *major* new functionality to
the protocol. We can still accept changes at this point, but they need
to make technical sense and be necessary. If there is WG consensus on both
these points, then we will make the change.