draft-josefsson-pppext-eap-tls-eap-05.txt

Linux上的802.1x 的supplicant的实现。很多supplicant程序都是基于它开发的

PPPEXT Working Group                                        H. Andersson
INTERNET-DRAFT                                              S. Josefsson
Category: Standards Track                                   RSA Security
<draft-josefsson-pppext-eap-tls-eap-05.txt>                    Glen Zorn
September 2002                                                     Cisco
                                                               Dan Simon
                                                          Ashwin Palekar
                                                               Microsoft


                     Protected EAP Protocol (PEAP)

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that other groups
may also distribute working documents as Internet- Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Copyright Notice

Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

The Extensible Authentication Protocol (EAP), defined in RFC 2284,
provides for support of multiple authentication methods. While EAP was
originally created for use with PPP, it has since been adopted for use
with IEEE 802.1X "Network Port Authentication".

Since its deployment, a number of weaknesses in EAP have become
apparent. These include lack of protection of the user identity or the
EAP negotiation; no standardized mechanism for key exchange; no built-in
support for fragmentation and reassembly; and lack of support for fast
reconnect.





Andersson et al.             Standards Track                    [Page 1]





INTERNET-DRAFT                    PEAP                    September 2002


By wrapping the EAP protocol within TLS, Protected EAP (PEAP) addresses
these deficiencies. Any EAP method running within PEAP is provided with
built-in support for key exchange, session resumption and fragmentation
and reassembly.

Table of Contents

1.     Introduction ..........................................    3
   1.1       EAP Issues ......................................    3
   1.2       Requirements language ...........................    5
   1.3       Terminology .....................................    5
2.     Protocol overview .....................................    6
   2.1        PEAP Part 1 ....................................    6
   2.2        PEAP Part 2 ....................................   10
   2.3        Version negotiation ............................   11
   2.4        Error handling .................................   12
   2.5        Retry behavior .................................   12
   2.6        Session resumption .............................   12
   2.7        Fragmentation ..................................   13
   2.8        Key derivation .................................   14
   2.9        Ciphersuite negotiation ........................   16
3.      Detailed description of the PEAP protocol ............   18
   3.1        PEAP Packet Format .............................   18
   3.2        PEAP Request Packet ............................   20
   3.3        PEAP Response Packet ...........................   22
4.      Security considerations ..............................   23
   4.1        Method negotiation .............................   23
   4.2        TLS session cache handling .....................   24
   4.3        Certificate revocation .........................   24
   4.4        Separation of EAP server and PPP authenticator..   25
   4.5        Separation of PEAP Part 1 and Part 2 Servers ...   26
   4.6        Identity verification ..........................   27
5.       Normative references ................................   28
6.       Informative references ..............................   29
Appendix A - Examples ........................................   31
Acknowledgments ..............................................   40
Author's Addresses ...........................................   40
Intellectual Property Statement ..............................   41
Full Copyright Statement .....................................   41












Andersson et al.             Standards Track                    [Page 2]





INTERNET-DRAFT                    PEAP                    September 2002


1.  Introduction

The Extensible Authentication Protocol (EAP), described in [RFC2284],
provides a standard mechanism for support of multiple authentication
methods.  Through the use of EAP, support for a number of authentication
schemes may be added, including smart cards, Kerberos, Public Key, One
Time Passwords, and others.

One of the goals of EAP is to enable development of new authentication
methods without requiring deployment of new code on the Network Access
Server (NAS). As a result, the NAS acts as a "passthrough", and need not
understand specific EAP methods.

Figure 1 describes the relationship between the EAP peer, NAS and
backend authentication server.  As described in the figure, the EAP
conversation "passes through" the NAS on its way between the client and
the backend authentication server.  While the authentication
conversation is between the EAP peer and backend authentication server,
the NAS and backend authentication server need to have established trust
for the conversation to proceed.

In PEAP, the conversation between the EAP peer and the backend server is
encrypted and integrity protected within a TLS channel, and mutual
authentication is required between the EAP peer and the backend server.

As a result, the NAS does not have knowledge of the TLS master secret
derived between the EAP Peer and the backend authentication server, and
cannot decrypt the PEAP conversation. In order to providing keying
material for link-layer ciphersuites however, the NAS does obtain the
master session keys, which are derived from the TLS master secret via a
one-way function.

1.1.  EAP Issues

With the increasing adoption of EAP, a number of deficiencies have
become apparent. Since the EAP method negotiation is unprotected, where
an attacker can easily access the medium (such as on a wireless network
or where EAP is run over IP), it is possible for an attacker to inject
packets in order to cause the negotiation of a method with lesser
security. Denial of service attacks are also possible. By protecting the
EAP negotiation within a TLS channel, PEAP addresses this issue.

Since the initial EAP Identity Request/Response exchange is sent in the
clear, an attacker snooping on the conversation can collect user
identities for use in subsequent attacks. By initially negotiating a TLS
channel, PEAP provies support for identity protection.





Andersson et al.             Standards Track                    [Page 3]





INTERNET-DRAFT                    PEAP                    September 2002


+-+-+-+-+-+               +-+-+-+-+-+
|         |               |         |
|         |               |         |
| Cipher- |               | Cipher- |
| Suite   |               | Suite   |
|         |               |         |
+-+-+-+-+-+               +-+-+-+-+-+
    ^                         ^
    |                         |
    |                         |
    |                         |
    V                         V
+-+-+-+-+-+               +-+-+-+-+-+  Trust +-+-+-+-+-+
|         |  EAP          |         |<======>|         |
|         |  Conversation |         |        |         |
|         |<================================>| Backend |
| Client  |  (over PPP,   |   NAS   |        |  Server |
|         |  802.11,etc.) |         |<=======|         |
|         |               |         |  Keys  |         |
|         |               |         |        |         |
+-+-+-+-+-+               +-+-+-+-+-+        +-+-+-+-+-+
    ^                                            ^
    |                                            |
    | EAP API                                    | EAP API
    |                                            |
    V                                            V
+-+-+-+-+-+                                  +-+-+-+-+-+
|         |                                  |         |
|         |                                  |         |
|  EAP    |                                  |  EAP    |
|  Method |                                  |  Method |
|         |                                  |         |
+-+-+-+-+-+                                  +-+-+-+-+-+

Figure 1 - Relationship between EAP client, backend authentication
           server and NAS.















Andersson et al.             Standards Track                    [Page 4]





INTERNET-DRAFT                    PEAP                    September 2002


Since EAP does not include support for fragmentation and reassembly,
individual methods need to include this capability. By including support
for fragmentation and reassembly within PEAP, methods leveraging PEAP do
not need to support this on their own.

Where EAP is used for authentication in wireless networks, the
authentication latency is a concern. As a result, it is valuable to be
able to do a quick re-authentication on roaming between access points.
PEAP supports this capability by leveraging the TLS session resumption
facility, and any EAP method running under PEAP can take advantage of
it.

In order to provide keying material for a wide range of link layer
ciphersuites, EAP methods need to provide a key hierarchy generating
authentication and encryption keys, as well as initialization vectors.
Development of a secure key hierarchy is complex, and not easy to
generalize for all EAP methods.  By relying on the well-reviewed TLS
[RFC2246] key derivation method, PEAP provides the required keying
material for any EAP method running within it. This frees EAP method
developers from taking on the difficult (and error prone) task of
designing a key hierarchy for each method.

1.2.  Requirements language

In this document, the key words "MAY", "MUST,  "MUST  NOT",  "OPTIONAL",
"RECOMMENDED",  "SHOULD",  and  "SHOULD  NOT",  are to be interpreted as
described in [RFC2119].

1.3.  Terminology

This document frequently uses the following terms:

Access Point
     A Network Access Server implementing 802.11.

Authenticator
     The end of the link requiring the authentication.

Authentication Server
          An Authentication Server is an entity that provides an
          Authentication Service to an NAS. This service verifies from
          the credentials provided by the peer, the claim of identity
          made by the peer.

Link layer ciphersuite
          The ciphersuite negotiated for use at the link layer.





Andersson et al.             Standards Track                    [Page 5]





INTERNET-DRAFT                    PEAP                    September 2002


Master key
          The key derived between the EAP client and EAP server during
          the EAP authentication process.

Master session key
          The keys derived from the master key that are subsequently
          used in generation of the transient session keys for
          authentication, encryption, and IV-generation. So that the
          master session keys are usable with any link layer
          ciphersuite, they are longer than is necessary, and are
          truncated to fit.

NAS       Short for "Network Access Server".

Peer      The other end of the point-to-point link (PPP), point-to-point
          LAN segment (IEEE 802.1X) or 802.11 wireless link, which is
          being authenticated by the NAS. In IEEE 802.1X, this end is
          known as the Supplicant.

TLS Ciphersuite
          The ciphersuite negotiated for protection of the PEAP Part 2
          conversation.

Transient session keys
          The transient session keys are derived from the master session
          keys, and are of the appropriate size and type for use with
          the chosen link layer ciphersuite.

2.  Protocol overview

Protected EAP (PEAP) is comprised of a two-part conversation:

[1]  In Part 1, a TLS session is negotiated, with server authenticating
     to the client and optionally the client to the server. The
     negotiated key is then used to encrypt the rest of the
     conversation.

[2]  In Part 2, within the TLS session, a complete EAP conversation is