|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
##
##
##
##
##
##
##
## EMUwg
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
Last Update: May 10, 2008
-- Color Legend: RFC Editor Queue
/ Processed by IESG
/ ID Exists
/ Recently Expired
-- Each I-D name is a link to an I-D description, which points to a text version, a two-page and fit-in-window PDF version, as well as the IETF Tools' HTML version.
|
|
|
|
|
|
|
|
|
##
##
##
##
##
##
##
## EMUwg
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
|
|
##
##
##
##
##
##
##
## EMUwg
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
| The charter of the EMU working group
is reported below.
|
|
|
|
The Extensible Authentication Protocol (EAP)
[RFC 3748] is a network
access authentication framework used in the PPP, 802.11, 802.16, VPN,
PANA, and in some functions in 3G networks. EAP itself is a simple
protocol and actual authentication happens in EAP methods.
Over 40 different EAP methods exist. Most of this methods are
proprietary methods and only a few methods are documented in RFCs. The
lack of documented, open specifications is a deployment and
interoperability problem. In addition, none of the EAP methods in the
standards track implement features such as key derivation that are
required for many modern applications. This poses a problem for, among
other things, the selection of a mandatory to implement EAP method in
new network access technologies. For example, no standards track
methods meet new requirements such as those posed in
RFC 4017, which
documents IEEE 802.11 requirements for EAP methods.
This group is chartered to work on the following types of mechanisms to
meet RFC 3748 and RFC 4017 requirements:
|
|
| - |
An update to RFC 2716 to bring EAP-TLS into standards track, clarify
specification, interoperability, and implementation issues gathered
over the years, and update the document to meet the requirements of
RFC 3748, RFC 4017, and EAP keying framework documents. Backwards
compatibility with RFC 2716 is a requirement.
|
| - |
Enhanced functionality to enable a TLS-based EAP method to support
authentication methods beyond certificates, channel bindings and other
optional functions required in RFC 4017. So as to enable RFC 2716bis
to focus solely on clarifications to the existing protocol, this effort
will be handled in a separate document. Depending on an analysis of the
behavior of existing implementations, it is possible that this effort
may be able to use the existing EAP-TLS type code, or it may need to be
handled via assignment of a new EAP Type Code.
|
| - |
A mechanism based on strong shared secrets that meets RFC 3748 and
RFC 4017 requirements. This mechanism should strive to be simple and
compact for implementation in resource constrained environments.
|
| - |
A mechanism meeting RFC 3748 and RFC 4017 requirements that makes use
of existing password databases such as AAA databases. The
implementation should strive to be usable in resource constrained
environments.
|
|
|
n order to facilitate the development of the shared secret and
password based methods design teams will be formed. The design teams
should take into consideration existing methods including mechanisms
based on EAP-TLS such as TLS-PSK.
|
|
|
|
|
|
|
|
##
##
##
##
##
##
##
## EMUwg
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
| | |
RFC5216
03/2008
(34 p.)
[html]
[pdf(2)] |
D. Simon
B. Aboba
R. Hurst |
|
The EAP-TLS Authentication Protocol |
The Extensible Authentication Protocol (EAP), defined in
RFC 3748,
provides support for multiple authentication methods. Transport
Layer Security (TLS) provides for mutual authentication, integrity-
protected ciphersuite negotiation, and key exchange between two
endpoints. This document defines EAP-TLS, which includes support for
certificate-based mutual authentication and key derivation.
This document obsoletes RFC 2716. A summary of the changes between
this document and RFC 2716 is available in Appendix A.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
##
##
##
##
##
##
##
## EMUwg
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
| -
|
|
|
|
|
|
|
|
|
##
##
##
##
##
##
##
## EMUwg
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
|
|
|
|
##
##
##
##
##
##
##
## EMUwg
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
| -
|
|
|
|
|
|
|
|
|
##
##
##
##
##
##
##
## EMUwg
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
