Diameter Extensible Authentication Protocol (EAP) Application
RFC 4072

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    aaa mailing list <aaa-wg@merit.edu>, 
    aaa chair <aaa-chairs@tools.ietf.org>
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:

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
   contains the value ((Vendor-Id * 232) + Vendor-Type).
   contains the value ((Vendor-Id * 2^32) + Vendor-Type).