Subject: [AAA-WG]: Fwd: I-D ACTION:draft-ietf-aaa-eap-06.txt

From: <[email-masked]>
Date: Thu, 3 Jun 2004 09:09:24 +0300

I believe this version handles all currently open issues,
and if the chairs agree, I'd suggest proceeding to IESG 
review and IETF last call.

Best regards,
Pasi

---------------------------------------
From: [email-masked]
Subject: I-D ACTION:draft-ietf-aaa-eap-06.txt
Date: Wed, 02 Jun 2004 09:50:36 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Authentication, Authorization and Accounting Working Group of the IETF.

	Title		: Diameter Extensible Authentication Protocol (EAP) 
			  Application
	Author(s)	: P. Eronen, et al.
	Filename	: draft-ietf-aaa-eap-06.txt
	Pages		: 37
	Date		: 2004-6-1
	
The Extensible Authentication Protocol (EAP) provides a standard
mechanism for support of various authentication methods.  This
document defines the Command-Codes and AVPs necessary to carry EAP
packets between a Network Access Server (NAS) and a back-end
authentication server

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-aaa-eap-06.txt

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 2 Jun 2004 23:57:47 -0700 (PDT)

Some comments:

"A Diameter client MUST NOT send a Diameter-EAP-Request encapsulating an
EAP Request packet, and a Diameter server receiving such packet MUST
respond with a failure Result-Code.."

Two periods at the end of the sentence.

This document does not define the ABNF for use with the ASR, ASA, RAR,
RAA, STR, or STA commands.  This is probably very similar to the ABNFs
used with NASREQ, in which case a reference to [NASREQ] may suffice.

I believe that this application shares many of the same RADIUS/Diameter
translation considerations as NASREQ Section 9.  It should probably
explicitly state this, particularly as regards the RADIUS
Dynamic Authorization considerations described in Sections 9.1.1 and
9.2.1 of NASREQ.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 03 Jun 2004 10:35:40 +0300

> used with NASREQ, in which case a reference to [NASREQ] may suffice.

Yes. The document does not even mention these commands
currently. Perhaps a new subsection somewhere under
current Section 3. Also, accounting request ABNF needs
to be defined, and it has one difference to the NASREQ
ABNF, the Accounting-EAP-Auth-Method AVP.

How about this:

   3.3 Base and NASREQ Commands

   Where the NASREQ AA-Request (AAR) or AA-Answer (AAA)
   commands are used for authorization in conjunction with
   EAP (see Section 2.3.3), the Auth-Application-Id AVP
   MUST be set to 1 (NASREQ), and the rules and command
   ABNF defined in [Diameter NASREQ] MUST be followed.

   Where the Re-Auth-Request (RAR), Re-Auth-Answer (RAA),
   Session-Termination-Request (STR), Session-Termination-Answer (STA),
   Abort-Session-Request (ASR) and Abort-Session-Answer (ASA)
   are used in conjunction with EAP, the Auth-Application-Id
   AVP MUST be set to <To Be Allocated By IANA> (EAP). Nevertheless,
   the same rules and command ABNF defined in [Diameter NASREQ]
   MUST be followed even in this case.

   3.4. Accounting Commands

   The Accounting-Request (ACR) message [Base], is sent by the NAS, to
   report it's session information to a target server downstream.

   One of Acct-Application-Id and Vendor-Specific-Application-Id AVPs
   MUST be present.  If the Vendor-Specific-Application-Id grouped AVP
   is present, it must have an Acct-Application-Id inside.
   [NOTE: This text is copied from NASREQ. But I don't understand
   how the NASREQ or EAP application can have a VSAID.]

   The AVPs listed in the Base MUST be assumed to be present as
   approriate.  NASREQ and EAP specific accounting AVPs, SHOULD be present
   as described in [Diameter NASREQ] and the rest of this specification.

    Message Format

       <AC-Request> ::= < Diameter Header: 271, REQ, PXY >
                       < Session-Id >
                       { Origin-Host }
                       { Origin-Realm }
                       { Destination-Realm }
                       { Accounting-Record-Type }
                       { Accounting-Record-Number }
                       [ Acct-Application-Id ]
                       [ Vendor-Specific-Application-Id ]
                       [ User-Name ]
                       [ Accounting-Sub-Session-Id ]
                       [ Accounting-Session-Id ]
                       [ Acct-Multi-Session-Id ]
                       [ Origin-State-Id ]
                       [ Destination-Host ]
                       [ Event-Timestamp ]
                       [ Acct-Delay-Time ]
                       [ NAS-Identifier ]
                       [ NAS-IP-Address ]
                       [ NAS-IPv6-Address ]
                       [ NAS-Port ]
                       [ NAS-Port-Id ]
                       [ NAS-Port-Type ]
                     * [ Class ]
                       [ Service-Type ]
                       [ Termination-Cause ]
                       [ Accounting-Input-Octets ]
                       [ Accounting-Input-Packets ]
                       [ Accounting-Output-Octets ]
                       [ Accounting-Output-Packets ]
                       [ Acct-Authentic ]
                       [ Accounting-Auth-Method ]
                       [ Acct-Link-Count ]
                       [ Acct-Session-Time ]
                       [ Acct-Tunnel-Connection ]
                       [ Acct-Tunnel-Packets-Lost ]
                       [ Callback-Id ]
                       [ Callback-Number ]
                       [ Called-Station-Id ]
                       [ Calling-Station-Id ]
                     * [ Connection-Info ]
                       [ Originating-Line-Info ]
                       [ Authorization-Lifetime ]
                       [ Session-Timeout ]
                       [ Idle-Timeout ]
                       [ Port-Limit ]
                       [ Accounting-Realtime-Required ]
                       [ Acct-Interim-Interval ]
                     * [ Filter-Id ]
                     * [ NAS-Filter-Rule ]
                       [ Framed-AppleTalk-Link ]
                       [ Framed-AppleTalk-Network ]
                       [ Framed-AppleTalk-Zone ]
                       [ Framed-Compression ]
                       [ Framed-Interface-Id ]
                       [ Framed-IP-Address ]
                       [ Framed-IP-Netmask ]
                     * [ Framed-IPv6-Prefix ]
                       [ Framed-IPv6-Pool ]
                     * [ Framed-IPv6-Route ]
                       [ Framed-IPX-Network ]
                       [ Framed-MTU ]
                       [ Framed-Pool ]
                       [ Framed-Protocol ]
                     * [ Framed-Route ]
                       [ Framed-Routing ]
                     * [ Login-IP-Host ]
                     * [ Login-IPv6-Host ]
                       [ Login-LAT-Group ]
                       [ Login-LAT-Node ]
                       [ Login-LAT-Port ]
                       [ Login-LAT-Service ]
                       [ Login-Service ]
                       [ Login-TCP-Port ]
                     * [ Accounting-EAP-Auth-Method ]
                     * [ Tunneling ]
                     * [ Proxy-Info ]
                     * [ Route-Record ]
                     * [ AVP ]

    The Accounting-Answer (ACA) message [Base], is used to acknowledge an
    Accounting-Request command.  The Accounting-Answer command contains
    the same Session-Id as the Request.  If the Accounting- Request was
    protected by end-to-end security, then the corresponding ACA message
    MUST be protected by end-to-end security.

    Only the target Diameter Server, or home Diameter Server, SHOULD
    respond with the Accounting-Answer command.

    One of Acct-Application-Id and Vendor-Specific-Application-Id AVPs
    MUST be present, as was in the request.

    The AVPs listed in the Base MUST be assumed to be present as
    approriate.  NASREQ and EAP specific accounting AVPs, SHOULD be present
    as described in [Diameter NASREQ] and the rest of this specification.

    Message Format

       <AC-Answer> ::= < Diameter Header: 271, PXY >
                       < Session-Id >
                       { Result-Code }
                       { Origin-Host }
                       { Origin-Realm }
                       { Accounting-Record-Type }
                       { Accounting-Record-Number }
                       [ Acct-Application-Id ]
                       [ Vendor-Specific-Application-Id ]
                       [ User-Name ]
                       [ Accounting-Sub-Session-Id ]
                       [ Accounting-Session-Id ]
                       [ Acct-Multi-Session-Id ]
                       [ Event-Timestamp ]
                       [ Error-Reporting-Host ]
                       [ Origin-State-Id ]
                       [ NAS-Identifier ]
                       [ NAS-IP-Address ]
                       [ NAS-IPv6-Address ]
                       [ NAS-Port ]
                       [ NAS-Port-Id ]
                       [ NAS-Port-Type ]
                       [ Service-Type ]
                       [ Termination-Cause ]
                       [ Accounting-Realtime-Required ]
                       [ Acct-Interim-Interval ]
                     * [ Class ]
                     * [ Proxy-Info ]
                     * [ Route-Record ]
                     * [ AVP ]

> Dynamic Authorization considerations described in Sections 9.1.1 and

Perhaps this is sufficient:

    Section 9 of [NASREQ] describes basic guidelines that translation
    agents may follow when translating between RADIUS and Diameter
    protocols. This section gives additional guidelines for the Diameter
    EAP application.

=>

    Section 9 of [NASREQ] describes basic guidelines for translation
    agents that translate between RADIUS and Diameter protocols.
    These guidelines SHOULD be followed for EAP application as well,
    with some additional guidelines given in this section.

--Jari

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 3 Jun 2004 07:47:34 -0700 (PDT)

>    MUST be followed even in this case.

Presumably the EAP application will add a mandatory EAP payload AVP to the
ABNF, no?

>    3.4. Accounting Commands

This looks ok.

> Additional guidelines for use of EAP.

I think this is sufficient.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 03 Jun 2004 17:56:06 +0300

> Presumably the EAP application will add a mandatory EAP payload AVP to the

I don't know, but lets see:

- STR, STA: I think we just kill the session,
   and no EAP needs to be run. Hence no EAP-Payload AVP either.

- ASR, ASA: As above.

- RAR, RAA: This is trickier. The purpose of the
   reauthentication may be re-authentication. If so,
   in theory we could carry an EAP Identity Request
   (or some other first server generated message) in
   the RAR, and its response in the RAA. But I think
   Diameter base intended the actual auth/authz process
   to start in the subsequent application specific
   command. In the case of EAP, this would be DER/DEA.

--Jari

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 3 Jun 2004 08:12:00 -0700 (PDT)

>    command. In the case of EAP, this would be DER/DEA.

Yes, that's what we decided.  So I guess that the RAR/RAA won't contain
any EAP AVPs and a reference to NASREQ will suffice.  Thanks.