Diameter Extensible Authentication Protocol (EAP) Application
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: IETF-Announce <email@example.com> Cc: Internet Architecture Board <firstname.lastname@example.org>, RFC Editor <email@example.com>, aaa mailing list <firstname.lastname@example.org>, aaa chair <email@example.com> Subject: Protocol Action: 'Diameter Extensible Authentication Protocol (EAP) Application' to Proposed Standard The IESG has approved the following document: - 'Diameter Extensible Authentication Protocol (EAP) Application ' <draft-ietf-aaa-eap-11.txt> as a Proposed Standard This document is the product of the Authentication, Authorization and Accounting Working Group. The IESG contact persons are Bert Wijnen and Dan Romascanu. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-aaa-eap-11.txt
Technical Summary: 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. It therefore provides the same function for Diameter as RFC 3579 does for RADIUS. Working Group Summary The document being advanced represents the culmination of a long effort to standardize support for EAP within Diameter, including key transport. One of the major obstacles that was overcome was the development of a mechanism (using Diameter Redirect) to transport keys without access by intermediaries. There is strong working group consensus relating to this document. The document has been reviewed by participants in both AAA WG and EAP WG, as well as by participants within IEEE 802, 3GPP, and 3GPP2. Protocol Quality: This protocol document was originally part of the Diameter NASREQ specification, but was split off into a separate specification in order to improve clarity and allow EAP-specific security issues to be addressed. Since the split, the clarity of the protocol as well as the level of analysis in the security considerations section has been greatly improved. Bert Wijnen has reviewed this document for the IESG. RFC-Editor note: In sect 4.1.5 fix incorrect notation on 3rd line OLD: contains the value ((Vendor-Id * 232) + Vendor-Type). NEW: contains the value ((Vendor-Id * 2^32) + Vendor-Type).