Subject: [AAA-WG]: RE: Diameter Proposed Changes

From: [email-masked]
Date: Fri, 25 May 2001 18:45:48 +0300

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

Pat,

I apologize for my ignorance. Here are my issues re-formatted:

=========================================================================

Subject: [issue] EAP Roundtrips

Submitter name: Henry Haverinen
Submitter email address: [email-masked]
Date first submitted: 2001-05-25
Reference: http://www.merit.edu/mail.archives/aaa-wg/msg00974.html
Document: <NASREQ>
Comment type: T
Priority: 2
Section: 4.0, 4.2.1, 4.2.2
Rationale/Explanation of issue:

This issue is an optimization. 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.

Requested change:

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.

====================================================================

Subject: [issue] Multi-roundtrip Mobile IP authentication

Submitter name: Henry Haverinen
Submitter email address: [email-masked]
Date first submitted: 2001-05-25
Reference: http://www.merit.edu/mail.archives/aaa-wg/msg00972.html
Document: <MobileIP> 
Comment type: T
Priority: 1
Section: 2.2
Rationale/Explanation of issue:

Some authentication mechanisms may take more than one 
roundtrip to authenticate and authorize the user. An example
of such a mechanism is draft-haverinen-mobileip-gsmsim-02.txt,
but there may be others.
This is not supported in the current Diameter Mobile IP draft.

Requested change:

These mechanisms can easily be supported in the Diameter Mobile IP
draft if an unsuccessful AMA message can be used to convey authentication 
data to the MN in a key distribution extension. So please
include the following text in Section 2.2:

   An unsuccessful AMA message MAY include mobile node registration 
   key AVPs (Section 7.1) such as the MIP-MN-to-FA-Key AVP and 
   the MIP-MN-to-HA-Key AVP. If such an AVP is present in the AMA message, 
   then the foreign agent MUST include the corresponding Mobile IP key 
   distribution extension in the Registration Reply it sends to 
   the mobile node. This is to support multi-roundtrip authentication
   mechanisms.

In addition, please include MIP-MN-to-FA-Key AVP in the 
AA-Mobile-Node-Answer message format definition.

====================================================================

Subject: [issue] What if the AAAL cannot reach the HA?

Submitter name: Henry Haverinen
Submitter email address: [email-masked]
Date first submitted: 2001-05-25
Reference: http://www.merit.edu/mail.archives/aaa-wg/msg00972.html
Document: <MobileIP>
Comment type: T
Priority: 1
Section: 2.2
Rationale/Explanation of issue:

The AAAL may not be able to reach the home agent the mobile 
node is using even if it was able to reach the AAAH. This may occur 
for example if the home agent was allocated from a previously visited 
network, or if the mobile node is authenticated and authorized using
a local gateway to a back end AAA server (see draft-haverinen-
mobileip-gsmsim-02.txt for an example). In these cases, the foreign 
agent needs to forward the Registration Request to the home agent 
itself.

Requested change:

Section 2.2 currently says: "A successful AMA message MUST include 
the MIP-Home-Agent-Address, MIP-Home-Mobile-Node-Address AVP and 
MIP-Reg-Reply AVPs." Please remove the MIP-Reg-Reply AVP from the list.
In addition, please include the following text in Section 2.2:

   The AAAL may not always be able to reach the home agent even if was able
   to authenticate and authorize the mobile node. Therefore, if a successful

   AMA message does not include the MIP-Reg-Reply AVP, then then the foreign

   agent MUST relay the Registration Request in question to the home agent 
   itself. An AMA message can only be successful and not include
   the MIP-Reg-Reply AVP if the Registration Request includes a Home Agent
   address and a Mobile-Home Authentication Extension. As required in
   [MIPv4 base document], the foreign agent must remove any Extensions 
   following the Mobile-Home Authentication Extension before relaying
   the Request to the home agent.

====================================================================

---

From: Patrice Calhoun <[email-masked]>
Date: Fri, 25 May 2001 09:06:14 -0700 (PDT)

> I apologize for my ignorance. Here are my issues re-formatted:

The issues web page has been updated to include the issues you have submitted.

Thanks for your cooperation,

PatC

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 27 May 2001 11:28:58 -0700 (PDT)

I think we are actually getting into some murky areas of RFC 2869 here,
and the solution is *not* to specify behavior for Diameter alone, but to
figure out what should happen and issue an RFC 2869bis, then have Diameter
inherit the correct behavior. 

1. If a AAA server an Accept message with an EAP-Message inside not
corresponding to a Failure or Success, this implies that the user is to be
let on. For PPP, RFC 2284 indicates that the peer is to be able to discern
Failure or Success by alternate methods (seeing NCP packets as an
indication of Success, receipt of an LCP-Terminate as an alternate
indication of Failure). For 802.1X, these alternate mechanisms are not
available so that a manufactured EAP-Success or EAP-Failure packet is sent
instead. Note that this implies that the last encapsulated packet will
actually not be sent to the peer. So in general, it seems to me that
AAA servers terminating a AAA exchange this way will not be obtaining a
guaranteed result. 

2. Sending an EAP-Response after an EAP-Sucess message is illegal under
RFC 2284, since Success messages are not ACK'd. This is what leads to the
need for "alternate" indication methods in RFC 2284, and the issues
described in #1. 

3. EAP authentication does *not* terminate on receipt of an
encapsulated EAP-Success/Failure message from the AAA server, but rather
on receipt of an Accept/Reject indication. So if an EAP-Success/Failiure 
message is encapsulated in a Challenge rather than an Accept/Reject
message, then authentication could continue, enabling more than one EAP
method to be used for a given session. However, it is not clear to
me how the two auth methods would be bridged within AAA, since there is no
EAP-Response to be sent back to the AAA server as described above. The
situation would be different if the other side initiated the second EAP
conversation, since then the packet sent after an EAP-Success would be an
EAP-Request.