rfc3580.txt

radius服务器

Network Working Group                                         P. Congdon
Request for Comments: 3580                       Hewlett Packard Company
Category: Informational                                         B. Aboba
                                                               Microsoft
                                                                A. Smith
                                                        Trapeze Networks
                                                                 G. Zorn
                                                           Cisco Systems
                                                                J. Roese
                                                               Enterasys
                                                          September 2003


    IEEE 802.1X Remote Authentication Dial In User Service (RADIUS)
                            Usage Guidelines

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

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

Abstract

   This document provides suggestions on Remote Authentication Dial In
   User Service (RADIUS) usage by IEEE 802.1X Authenticators.  The
   material in this document is also included within a non-normative
   Appendix within the IEEE 802.1X specification, and is being presented
   as an IETF RFC for informational purposes.


















Congdon, et al.              Informational                      [Page 1]

RFC 3580                   IEEE 802.1X RADIUS             September 2003


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
       1.1.  Terminology. . . . . . . . . . . . . . . . . . . . . . .  3
       1.2.  Requirements Language. . . . . . . . . . . . . . . . . .  4
   2.  RADIUS Accounting Attributes . . . . . . . . . . . . . . . . .  5
       2.1.  Acct-Terminate-Cause . . . . . . . . . . . . . . . . . .  5
       2.2.  Acct-Multi-Session-Id. . . . . . . . . . . . . . . . . .  6
       2.3.  Acct-Link-Count. . . . . . . . . . . . . . . . . . . . .  7
   3.  RADIUS Authentication. . . . . . . . . . . . . . . . . . . . .  7
       3.1.  User-Name. . . . . . . . . . . . . . . . . . . . . . . .  8
       3.2.  User-Password, CHAP-Password, CHAP-Challenge . . . . . .  8
       3.3.  NAS-IP-Address, NAS-IPv6-Address . . . . . . . . . . . .  8
       3.4.  NAS-Port . . . . . . . . . . . . . . . . . . . . . . . .  8
       3.5.  Service-Type . . . . . . . . . . . . . . . . . . . . . .  8
       3.6.  Framed-Protocol. . . . . . . . . . . . . . . . . . . . .  9
       3.7.  Framed-IP-Address, Framed-IP-Netmask . . . . . . . . . .  9
       3.8.  Framed-Routing . . . . . . . . . . . . . . . . . . . . .  9
       3.9.  Filter-ID. . . . . . . . . . . . . . . . . . . . . . . .  9
       3.10. Framed-MTU . . . . . . . . . . . . . . . . . . . . . . .  9
       3.11. Framed-Compression . . . . . . . . . . . . . . . . . . . 10
       3.12. Displayable Messages . . . . . . . . . . . . . . . . . . 10
       3.13. Callback-Number, Callback-ID . . . . . . . . . . . . . . 10
       3.14. Framed-Route, Framed-IPv6-Route. . . . . . . . . . . . . 11
       3.15. State, Class, Proxy-State. . . . . . . . . . . . . . . . 11
       3.16. Vendor-Specific. . . . . . . . . . . . . . . . . . . . . 11
       3.17. Session-Timeout. . . . . . . . . . . . . . . . . . . . . 11
       3.18. Idle-Timeout . . . . . . . . . . . . . . . . . . . . . . 12
       3.19. Termination-Action . . . . . . . . . . . . . . . . . . . 12
       3.20. Called-Station-Id. . . . . . . . . . . . . . . . . . . . 12
       3.21. Calling-Station-Id . . . . . . . . . . . . . . . . . . . 12
       3.22. NAS-Identifier . . . . . . . . . . . . . . . . . . . . . 12
       3.23. NAS-Port-Type. . . . . . . . . . . . . . . . . . . . . . 12
       3.24. Port-Limit . . . . . . . . . . . . . . . . . . . . . . . 13
       3.25. Password-Retry . . . . . . . . . . . . . . . . . . . . . 13
       3.26. Connect-Info . . . . . . . . . . . . . . . . . . . . . . 13
       3.27. EAP-Message. . . . . . . . . . . . . . . . . . . . . . . 13
       3.28. Message-Authenticator. . . . . . . . . . . . . . . . . . 13
       3.29. NAS-Port-Id. . . . . . . . . . . . . . . . . . . . . . . 13
       3.30. Framed-Pool, Framed-IPv6-Pool. . . . . . . . . . . . . . 14
       3.31. Tunnel Attributes. . . . . . . . . . . . . . . . . . . . 14
   4.  RC4 EAPOL-Key Descriptor . . . . . . . . . . . . . . . . . . . 15
   5.  Security Considerations. . . . . . . . . . . . . . . . . . . . 18
       5.1.  Packet Modification or Forgery . . . . . . . . . . . . . 18
       5.2.  Dictionary Attacks . . . . . . . . . . . . . . . . . . . 19
       5.3.  Known Plaintext Attacks. . . . . . . . . . . . . . . . . 19
       5.4.  Replay . . . . . . . . . . . . . . . . . . . . . . . . . 20
       5.5.  Outcome Mismatches . . . . . . . . . . . . . . . . . . . 20



Congdon, et al.              Informational                      [Page 2]

RFC 3580                   IEEE 802.1X RADIUS             September 2003


       5.6.  802.11 Integration . . . . . . . . . . . . . . . . . . . 20
       5.7.  Key Management Issues. . . . . . . . . . . . . . . . . . 21
   6.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 22
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
       7.1.  Normative References . . . . . . . . . . . . . . . . . . 22
       7.2.  Informative References . . . . . . . . . . . . . . . . . 23
   8.  Table of Attributes. . . . . . . . . . . . . . . . . . . . . . 25
   9.  Intellectual Property Statement  . . . . . . . . . . . . . . . 28
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
   11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29
   12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 30

1.  Introduction

   IEEE 802.1X enables authenticated access to IEEE 802 media, including
   Ethernet, Token Ring, and 802.11 wireless LANs.  Although Remote
   Authentication Dial In User Service (RADIUS) support is optional
   within IEEE 802.1X, it is expected that many IEEE 802.1X
   Authenticators will function as RADIUS clients.

   IEEE 802.1X [IEEE8021X] provides "network port authentication" for
   IEEE 802 [IEEE802] media, including Ethernet [IEEE8023], Token Ring
   and 802.11 [IEEE80211] wireless LANS.

   IEEE 802.1X does not require use of a backend Authentication Server,
   and thus can be deployed with stand-alone bridges or Access Points,
   as well as in centrally managed scenarios.

   In situations where it is desirable to centrally manage
   authentication, authorization and accounting (AAA) for IEEE 802
   networks, deployment of a backend authentication and accounting
   server is desirable.  In such situations, it is expected that IEEE
   802.1X Authenticators will function as AAA clients.

   This document provides suggestions on RADIUS usage by IEEE 802.1X
   Authenticators.  Support for any AAA protocol is optional for IEEE
   802.1X Authenticators, and therefore this specification has been
   incorporated into a non-normative Appendix within the IEEE 802.1X
   specification.

1.1.  Terminology

   This document uses the following terms:

   Access Point (AP)
         A Station that provides access to the distribution services via
         the wireless medium for associated Stations.




Congdon, et al.              Informational                      [Page 3]

RFC 3580                   IEEE 802.1X RADIUS             September 2003


   Association
         The service used to establish Access Point/Station mapping and
         enable Station invocation of the distribution system services.

   Authenticator
         An Authenticator is an entity that requires authentication from
         the Supplicant.  The Authenticator may be connected to the
         Supplicant at the other end of a point-to-point LAN segment or
         802.11 wireless link.

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

   Port Access Entity (PAE)
         The protocol entity associated with a physical or virtual
         (802.11) Port.  A given PAE may support the protocol
         functionality associated with the Authenticator, Supplicant or
         both.

   Station (STA)
         Any device that contains an IEEE 802.11 conformant medium
         access control (MAC) and physical layer (PHY) interface to the
         wireless medium (WM).

   Supplicant
         A Supplicant is an entity that is being authenticated by an
         Authenticator.  The Supplicant may be connected to the
         Authenticator at one end of a point-to-point LAN segment or
         802.11 wireless link.

1.2.  Requirements Language

   In this document, several words are used to signify the requirements
   of the specification.  These words are often capitalized.  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].











Congdon, et al.              Informational                      [Page 4]

RFC 3580                   IEEE 802.1X RADIUS             September 2003


2.  RADIUS Accounting Attributes

   With a few exceptions, the RADIUS accounting attributes defined in
   [RFC2866], [RFC2867], and [RFC2869] have the same meaning within IEEE
   802.1X sessions as they do in dialup sessions and therefore no
   additional commentary is needed.

   Attributes requiring more discussion include:

      Acct-Terminate-Cause
      Acct-Multi-Session-Id
      Acct-Link-Count

2.1.  Acct-Terminate-Cause

   This attribute indicates how the session was terminated, as described
   in [RFC2866].  [IEEE8021X] defines the following termination cause
   values, which are shown with their RADIUS equivalents in the table on
   the next page.

   IEEE 802.1X                       RADIUS
   dot1xAuthSessionTerminateCause    Acct-Terminate-Cause
   Value                             Value
   -------------                     --------------------
   SupplicantLogoff(1)               User Request (1)
   portFailure(2)                    Lost Carrier (2)
   SupplicantRestart(3)              Supplicant Restart (19)
   reauthFailed(4)                   Reauthentication Failure (20)
   authControlForceUnauth(5)         Admin Reset (6)
   portReInit(6)                     Port Reinitialized (21)
   portAdminDisabled(7)              Port Administratively Disabled (22)
   notTerminatedYet(999)             N/A

   When using this attribute, the User Request (1) termination cause
   corresponds to the situation in which the session terminated due to
   an EAPOL-Logoff received from the Supplicant.  When a session is
   moved due to roaming, the EAPOL state machines will treat this as a
   Supplicant Logoff.

   A Lost Carrier (2) termination cause indicates session termination
   due to loss of physical connectivity for reasons other than roaming
   between Access Points.  For example, if the Supplicant disconnects a
   point-to-point LAN connection, or moves out of range of an Access
   Point, this termination cause is used.  Lost Carrier (2) therefore
   equates to a Port Disabled condition in the EAPOL state machines.

   A Supplicant Restart (19) termination cause indicates
   re-initialization of the Supplicant state machines.



Congdon, et al.              Informational                      [Page 5]

RFC 3580                   IEEE 802.1X RADIUS             September 2003


   A Reauthentication Failure (20) termination cause indicates that a
   previously authenticated Supplicant has failed to re-authenticate
   successfully following expiry of the re-authentication timer or
   explicit re-authentication request by management action.

   Within [IEEE80211], periodic re-authentication may be useful in
   preventing reuse of an initialization vector with a given key.  Since
   successful re-authentication does not result in termination of the
   session, accounting packets are not sent as a result of
   re-authentication unless the status of the session changes.  For
   example:

   a. The session is terminated due to re-authentication failure.  In
      this case the Reauthentication Failure (20) termination cause is
      used.

   b. The authorizations are changed as a result of a successful
      re-authentication.  In this case, the Service Unavailable (15)
      termination cause is used.  For accounting purposes, the portion
      of the session after the authorization change is treated as a
      separate session.

   Where IEEE 802.1X authentication occurs prior to association,
   accounting packets are not sent until an association occurs.

   An Admin Reset (6) termination cause indicates that the Port has been
   administratively forced into the unauthorized state.

   A Port Reinitialized (21) termination cause indicates that the Port's
   MAC has been reinitialized.

   A Port Administratively Disabled (22) termination cause indicates
   that the Port has been administratively disabled.

2.2.  Acct-Multi-Session-Id

   The purpose of this attribute is to make it possible to link together
   multiple related sessions.  While [IEEE8021X] does not act on
   aggregated ports, it is possible for a Supplicant roaming between
   Access Points to cause multiple RADIUS accounting packets to be sent
   by different Access Points.

   Where supported by the Access Points, the Acct-Multi-Session-Id
   attribute can be used to link together the multiple related sessions
   of a roaming Supplicant.  In such a situation, if the session context