rfc3748.txt

使用最广泛的radius的linux的源码

Network Working Group                                           B. Aboba
Request for Comments: 3748                                     Microsoft
Obsoletes: 2284                                                 L. Blunk
Category: Standards Track                             Merit Network, Inc
                                                           J. Vollbrecht
                                               Vollbrecht Consulting LLC
                                                              J. Carlson
                                                                     Sun
                                                       H. Levkowetz, Ed.
                                                             ipUnplugged
                                                               June 2004


                Extensible Authentication Protocol (EAP)

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract

   This document defines the Extensible Authentication Protocol (EAP),
   an authentication framework which supports multiple authentication
   methods.  EAP typically runs directly over data link layers such as
   Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP.  EAP
   provides its own support for duplicate elimination and
   retransmission, but is reliant on lower layer ordering guarantees.
   Fragmentation is not supported within EAP itself; however, individual
   EAP methods may support this.

   This document obsoletes RFC 2284.  A summary of the changes between
   this document and RFC 2284 is available in Appendix A.











Aboba, et al.               Standards Track                     [Page 1]

RFC 3748                          EAP                          June 2004


Table of Contents

   1.   Introduction. . . . . . . . . . . . . . . . . . . . . . . . .  3
        1.1.  Specification of Requirements . . . . . . . . . . . . .  4
        1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . .  4
        1.3.  Applicability . . . . . . . . . . . . . . . . . . . . .  6
   2.   Extensible Authentication Protocol (EAP). . . . . . . . . . .  7
        2.1.  Support for Sequences . . . . . . . . . . . . . . . . .  9
        2.2.  EAP Multiplexing Model. . . . . . . . . . . . . . . . . 10
        2.3.  Pass-Through Behavior . . . . . . . . . . . . . . . . . 12
        2.4.  Peer-to-Peer Operation. . . . . . . . . . . . . . . . . 14
   3.   Lower Layer Behavior. . . . . . . . . . . . . . . . . . . . . 15
        3.1.  Lower Layer Requirements. . . . . . . . . . . . . . . . 15
        3.2.  EAP Usage Within PPP. . . . . . . . . . . . . . . . . . 18
              3.2.1. PPP Configuration Option Format. . . . . . . . . 18
        3.3.  EAP Usage Within IEEE 802 . . . . . . . . . . . . . . . 19
        3.4.  Lower Layer Indications . . . . . . . . . . . . . . . . 19
   4.   EAP Packet Format . . . . . . . . . . . . . . . . . . . . . . 20
        4.1.  Request and Response. . . . . . . . . . . . . . . . . . 21
        4.2.  Success and Failure . . . . . . . . . . . . . . . . . . 23
        4.3.  Retransmission Behavior . . . . . . . . . . . . . . . . 26
   5.   Initial EAP Request/Response Types. . . . . . . . . . . . . . 27
        5.1.  Identity. . . . . . . . . . . . . . . . . . . . . . . . 28
        5.2.  Notification. . . . . . . . . . . . . . . . . . . . . . 29
        5.3.  Nak . . . . . . . . . . . . . . . . . . . . . . . . . . 31
              5.3.1. Legacy Nak . . . . . . . . . . . . . . . . . . . 31
              5.3.2. Expanded Nak . . . . . . . . . . . . . . . . . . 32
        5.4.  MD5-Challenge . . . . . . . . . . . . . . . . . . . . . 35
        5.5.  One-Time Password (OTP) . . . . . . . . . . . . . . . . 36
        5.6.  Generic Token Card (GTC). . . . . . . . . . . . . . . . 37
        5.7.  Expanded Types. . . . . . . . . . . . . . . . . . . . . 38
        5.8.  Experimental. . . . . . . . . . . . . . . . . . . . . . 40
   6.   IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
        6.1.  Packet Codes. . . . . . . . . . . . . . . . . . . . . . 41
        6.2.  Method Types. . . . . . . . . . . . . . . . . . . . . . 41
   7.   Security Considerations . . . . . . . . . . . . . . . . . . . 42
        7.1.  Threat Model. . . . . . . . . . . . . . . . . . . . . . 42
        7.2.  Security Claims . . . . . . . . . . . . . . . . . . . . 43
              7.2.1. Security Claims Terminology for EAP Methods. . . 44
        7.3.  Identity Protection . . . . . . . . . . . . . . . . . . 46
        7.4.  Man-in-the-Middle Attacks . . . . . . . . . . . . . . . 47
        7.5.  Packet Modification Attacks . . . . . . . . . . . . . . 48
        7.6.  Dictionary Attacks. . . . . . . . . . . . . . . . . . . 49
        7.7.  Connection to an Untrusted Network. . . . . . . . . . . 49
        7.8.  Negotiation Attacks . . . . . . . . . . . . . . . . . . 50
        7.9.  Implementation Idiosyncrasies . . . . . . . . . . . . . 50
        7.10. Key Derivation. . . . . . . . . . . . . . . . . . . . . 51
        7.11. Weak Ciphersuites . . . . . . . . . . . . . . . . . . . 53



Aboba, et al.               Standards Track                     [Page 2]

RFC 3748                          EAP                          June 2004


        7.12. Link Layer. . . . . . . . . . . . . . . . . . . . . . . 53
        7.13. Separation of Authenticator and Backend Authentication
              Server. . . . . . . . . . . . . . . . . . . . . . . . . 54
        7.14. Cleartext Passwords . . . . . . . . . . . . . . . . . . 55
        7.15. Channel Binding . . . . . . . . . . . . . . . . . . . . 55
        7.16. Protected Result Indications. . . . . . . . . . . . . . 56
   8.   Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 58
   9.   References. . . . . . . . . . . . . . . . . . . . . . . . . . 59
        9.1.  Normative References. . . . . . . . . . . . . . . . . . 59
        9.2.  Informative References. . . . . . . . . . . . . . . . . 60
   Appendix A. Changes from RFC 2284. . . . . . . . . . . . . . . . . 64
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 66
   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 67

1.  Introduction

   This document defines the Extensible Authentication Protocol (EAP),
   an authentication framework which supports multiple authentication
   methods.  EAP typically runs directly over data link layers such as
   Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP.  EAP
   provides its own support for duplicate elimination and
   retransmission, but is reliant on lower layer ordering guarantees.
   Fragmentation is not supported within EAP itself; however, individual
   EAP methods may support this.

   EAP may be used on dedicated links, as well as switched circuits, and
   wired as well as wireless links.  To date, EAP has been implemented
   with hosts and routers that connect via switched circuits or dial-up
   lines using PPP [RFC1661].  It has also been implemented with
   switches and access points using IEEE 802 [IEEE-802].  EAP
   encapsulation on IEEE 802 wired media is described in [IEEE-802.1X],
   and encapsulation on IEEE wireless LANs in [IEEE-802.11i].

   One of the advantages of the EAP architecture is its flexibility.
   EAP is used to select a specific authentication mechanism, typically
   after the authenticator requests more information in order to
   determine the specific authentication method to be used.  Rather than
   requiring the authenticator to be updated to support each new
   authentication method, EAP permits the use of a backend
   authentication server, which may implement some or all authentication
   methods, with the authenticator acting as a pass-through for some or
   all methods and peers.

   Within this document, authenticator requirements apply regardless of
   whether the authenticator is operating as a pass-through or not.
   Where the requirement is meant to apply to either the authenticator
   or backend authentication server, depending on where the EAP
   authentication is terminated, the term "EAP server" will be used.



Aboba, et al.               Standards Track                     [Page 3]

RFC 3748                          EAP                          June 2004


1.1.  Specification of Requirements

   In this document, several words are used to signify the requirements
   of the specification.  The key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119].

1.2.  Terminology

   This document frequently uses the following terms:

   authenticator
      The end of the link initiating EAP authentication.  The term
      authenticator is used in [IEEE-802.1X], and has the same meaning
      in this document.

   peer
      The end of the link that responds to the authenticator.  In
      [IEEE-802.1X], this end is known as the Supplicant.

   Supplicant
      The end of the link that responds to the authenticator in [IEEE-
      802.1X].  In this document, this end of the link is called the
      peer.

   backend authentication server
      A backend authentication server is an entity that provides an
      authentication service to an authenticator.  When used, this
      server typically executes EAP methods for the authenticator.  This
      terminology is also used in [IEEE-802.1X].

   AAA
      Authentication, Authorization, and Accounting.  AAA protocols with
      EAP support include RADIUS [RFC3579] and Diameter [DIAM-EAP].  In
      this document, the terms "AAA server" and "backend authentication
      server" are used interchangeably.

   Displayable Message
      This is interpreted to be a human readable string of characters.
      The message encoding MUST follow the UTF-8 transformation format
      [RFC2279].









Aboba, et al.               Standards Track                     [Page 4]

RFC 3748                          EAP                          June 2004


   EAP server
      The entity that terminates the EAP authentication method with the
      peer.  In the case where no backend authentication server is used,
      the EAP server is part of the authenticator.  In the case where
      the authenticator operates in pass-through mode, the EAP server is
      located on the backend authentication server.

   Silently Discard
      This means the implementation discards the packet without further
      processing.  The implementation SHOULD provide the capability of
      logging the event, including the contents of the silently
      discarded packet, and SHOULD record the event in a statistics
      counter.

   Successful Authentication
      In the context of this document, "successful authentication" is an
      exchange of EAP messages, as a result of which the authenticator
      decides to allow access by the peer, and the peer decides to use
      this access.  The authenticator's decision typically involves both
      authentication and authorization aspects; the peer may
      successfully authenticate to the authenticator, but access may be
      denied by the authenticator due to policy reasons.

   Message Integrity Check (MIC)
      A keyed hash function used for authentication and integrity
      protection of data.  This is usually called a Message
      Authentication Code (MAC), but IEEE 802 specifications (and this
      document) use the acronym MIC to avoid confusion with Medium
      Access Control.

   Cryptographic Separation
      Two keys (x and y) are "cryptographically separate" if an
      adversary that knows all messages exchanged in the protocol cannot
      compute x from y or y from x without "breaking" some cryptographic
      assumption.  In particular, this definition allows that the
      adversary has the knowledge of all nonces sent in cleartext, as
      well as all predictable counter values used in the protocol.
      Breaking a cryptographic assumption would typically require
      inverting a one-way function or predicting the outcome of a
      cryptographic pseudo-random number generator without knowledge of
      the secret state.  In other words, if the keys are
      cryptographically separate, there is no shortcut to compute x from
      y or y from x, but the work an adversary must do to perform this
      computation is equivalent to performing an exhaustive search for
      the secret state value.






Aboba, et al.               Standards Track                     [Page 5]

RFC 3748                          EAP                          June 2004


   Master Session Key (MSK)
      Keying material that is derived between the EAP peer and server
      and exported by the EAP method.  The MSK is at least 64 octets in
      length.  In existing implementations, a AAA server acting as an
      EAP server transports the MSK to the authenticator.

   Extended Master Session Key (EMSK)
      Additional keying material derived between the EAP client and
      server that is exported by the EAP method.  The EMSK is at least