GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3580

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
 is transferred between Access Points, accounting packets MAY be sent
 without a corresponding authentication and authorization exchange,

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

 provided that Association has occurred.  However, in such a situation
 it is assumed that the Acct-Multi-Session-Id is transferred between
 the Access Points as part of the Inter-Access Point Protocol (IAPP).
 If the Acct-Multi-Session-Id were not unique between Access Points,
 then it is possible that the chosen Acct-Multi-Session-Id will
 overlap with an existing value allocated on that Access Point, and
 the Accounting Server would therefore be unable to distinguish a
 roaming session from a multi-link session.
 As a result, the Acct-Multi-Session-Id attribute is unique among all
 the bridges or Access Points, Supplicants and sessions.  In order to
 provide this uniqueness, it is suggested that the Acct-Multi-
 Session-Id be of the form:
 Original AP MAC Address | Supplicant MAC Address | NTP Timestamp
 Here "|" represents concatenation, the original AP MAC Address is the
 MAC address of the bridge or Access Point at which the session
 started, and the 64-bit NTP timestamp indicates the beginning of the
 original session.  In order to provide for consistency of the Acct-
 Multi-Session-Id between roaming sessions, the Acct-Multi-Session-Id
 may be moved between Access Points as part of IAPP or another handoff
 scheme.
 The use of an Acct-Multi-Session-Id of this form guarantees
 uniqueness among all Access Points, Supplicants and sessions.  Since
 the NTP timestamp does not wrap on reboot, there is no possibility
 that a rebooted Access Point could choose an Acct-Multi-Session-Id
 that could be confused with that of a previous session.
 Since the Acct-Multi-Session-Id is of type String as defined in
 [RFC2866], for use with IEEE 802.1X, it is encoded as an ASCII string
 of Hex digits.  Example:  "00-10-A4-23-19-C0-00-12-B2-
 14-23-DE-AF-23-83-C0-76-B8-44-E8"

2.3. Acct-Link-Count

 The Acct-Link-Count attribute may be used to account for the number
 of ports that have been aggregated.

3. RADIUS Authentication

 This section describes how attributes defined in [RFC2865],
 [RFC2867], [RFC2868], [RFC2869], [RFC3162] and [RFC3579] are used in
 IEEE 802.1X authentication.

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

3.1. User-Name

 In IEEE 802.1X, the Supplicant typically provides its identity via an
 EAP-Response/Identity message.  Where available, the Supplicant
 identity is included in the User-Name attribute, and included in the
 RADIUS Access-Request and Access-Reply messages as specified in
 [RFC2865] and [RFC3579].
 Alternatively, as discussed in [RFC3579] Section 2.1., the User-Name
 attribute may contain the Calling-Station-ID value, which is set to
 the Supplicant MAC address.

3.2. User-Password, CHAP-Password, CHAP-Challenge

 Since IEEE 802.1X does not support PAP or CHAP authentication, the
 User-Password, CHAP-Password or CHAP-Challenge attributes are not
 used by IEEE 802.1X Authenticators acting as RADIUS clients.

3.3. NAS-IP-Address, NAS-IPv6-Address

 For use with IEEE 802.1X, the NAS-IP-Address contains the IPv4
 address of the bridge or Access Point acting as an Authenticator, and
 the NAS-IPv6-Address contains the IPv6 address.  If the IEEE 802.1X
 Authenticator has more than one interface, it may be desirable to use
 a loopback address for this purpose so that the Authenticator will
 still be reachable even if one of the interfaces were to fail.

3.4. NAS-Port

 For use with IEEE 802.1X the NAS-Port will contain the port number of
 the bridge, if this is available.  While an Access Point does not
 have physical ports, a unique "association ID" is assigned to every
 mobile Station upon a successful association exchange.  As a result,
 for an Access Point, if the association exchange has been completed
 prior to authentication, the NAS-Port attribute will contain the
 association ID, which is a 16-bit unsigned integer.  Where IEEE
 802.1X authentication occurs prior to association, a unique NAS-Port
 value may not be available.

3.5. Service-Type

 For use with IEEE 802.1X, the Framed (2), Authenticate Only (8), and
 Call Check (10) values are most commonly used.
 A Service-Type of Framed indicates that appropriate 802 framing
 should be used for the connection.  A Service-Type of Authenticate
 Only (8) indicates that no authorization information needs to be
 returned in the Access-Accept.  As described in [RFC2865], a

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

 Service-Type of Call Check is included in an Access-Request packet to
 request that the RADIUS server accept or reject the connection
 attempt, typically based on the Called-Station-ID (set to the bridge
 or Access Point MAC address) or Calling-Station-ID attributes (set to
 the Supplicant MAC address).  As noted in [RFC2865], it is
 recommended that in this case, the User-Name attribute be given the
 value of Calling-Station-Id.

3.6. Framed-Protocol

 Since there is no value for IEEE 802 media, the Framed-Protocol
 attribute is not used by IEEE 802.1X Authenticators.

3.7. Framed-IP-Address, Framed-IP-Netmask

 IEEE 802.1X does not provide a mechanism for IP address assignment.
 Therefore the Framed-IP-Address and Framed-IP-Netmask attributes can
 only be used by IEEE 802.1X Authenticators that support IP address
 assignment mechanisms.  Typically this capability is supported by
 layer 3 devices.

3.8. Framed-Routing

 The Framed-Routing attribute indicates the routing method for the
 Supplicant.  It is therefore only relevant for IEEE 802.1X
 Authenticators that act as layer 3 devices, and cannot be used by a
 bridge or Access Point.

3.9. Filter-ID

 This attribute indicates the name of the filter list to be applied to
 the Supplicant's session.  For use with an IEEE 802.1X Authenticator,
 it may be used to indicate either layer 2 or layer 3 filters.  Layer
 3 filters are typically only supported on IEEE 802.1X Authenticators
 that act as layer 3 devices.

3.10. Framed-MTU

 This attribute indicates the maximum size of an IP packet that may be
 transmitted over the wire between the Supplicant and the
 Authenticator.  IEEE 802.1X Authenticators set this to the value
 corresponding to the relevant 802 medium, and include it in the
 RADIUS Access-Request.  The RADIUS server may send an EAP packet as
 large as Framed-MTU minus four (4) octets, taking into account the
 additional overhead for the IEEE 802.1X Version (1), Type (1) and
 Body Length (2) fields.  For EAP over IEEE 802 media, the Framed-MTU
 values (which do not include LLC/SNAP overhead) and maximum frame
 length values (not including the preamble) are as follows:

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

                                      Maximum Frame
 Media             Framed-MTU            Length
 =========        ===============     ==============
 Ethernet              1500              1522
 802.3                 1500              1522
 802.4                 8174              8193
 802.5 (4 Mbps)        4528              4550
 802.5 (16 Mbps)      18173             18200
 802.5 (100 Mb/s)     18173             18200
 802.6                 9191              9240
 802.9a                1500              1518
 802.11                2304              2346
 802.12 (Ethernet)     1500              1518
 802.12 (Token Ring)   4502              4528
 FDDI                  4479              4500
 NOTE - the Framed-MTU size for IEEE 802.11 media may change as a
 result of ongoing work being undertaken in the IEEE 802.11 Working
 Group.  Since some 802.11 stations cannot handle an MTU larger than
 1500 octets, it is recommended that RADIUS servers encountering a
 NAS-Port-Type value of 802.11 send EAP packets no larger than 1496
 octets.

3.11. Framed-Compression

 [IEEE8021X] does not include compression support.  Therefore this
 attribute is not understood by [IEEE8021X] Authenticators.

3.12. Displayable Messages

 The Reply-Message attribute, defined in section 5.18 of [RFC2865],
 indicates text which may be displayed to the user.  This is similar
 in concept to the EAP Notification Type, defined in [RFC2284].  As
 noted in [RFC3579], Section 2.6.5, when sending a displayable message
 to an [IEEE8021X] Authenticator, displayable messages are best sent
 within EAP-Message/EAP-Request/Notification attribute(s), and not
 within Reply-Message attribute(s).

3.13. Callback-Number, Callback-ID

 These attributes are not understood by IEEE 802.1X Authenticators.

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

3.14. Framed-Route, Framed-IPv6-Route

 The Framed-Route and Framed-IPv6-Route attributes provide routes that
 are to be configured for the Supplicant.  These attributes are
 therefore only relevant for IEEE 802.1X Authenticators that act as
 layer 3 devices, and cannot be understood by a bridge or Access
 Point.

3.15. State, Class, Proxy-State

 These attributes are used for the same purposes as described in
 [RFC2865].

3.16. Vendor-Specific

 Vendor-specific attributes are used for the same purposes as
 described in [RFC2865].  The MS-MPPE-Send-Key and MS-MPPE-Recv-Key
 attributes, described in section 2.4 of [RFC2548], MAY be used to
 encrypt and authenticate the RC4 EAPOL-Key descriptor [IEEE8021X,
 Section 7.6].  Examples of the derivation of the MS-MPPE-Send-Key and
 MS-MPPE-Recv-Key attributes from the master key negotiated by an EAP
 method are given in [RFC2716].  Details of the EAPOL-Key descriptor
 are provided in Section 4.

3.17. Session-Timeout

 When sent along in an Access-Accept without a Termination-Action
 attribute or with a Termination-Action attribute set to Default, the
 Session-Timeout attribute specifies the maximum number of seconds of
 service provided prior to session termination.
 When sent in an Access-Accept along with a Termination-Action value
 of RADIUS-Request, the Session-Timeout attribute specifies the
 maximum number of seconds of service provided prior to re-
 authentication.  In this case, the Session-Timeout attribute is used
 to load the reAuthPeriod constant within the Reauthentication Timer
 state machine of 802.1X.  When sent with a Termination-Action value
 of RADIUS-Request, a Session-Timeout value of zero indicates the
 desire to perform another authentication (possibly of a different
 type) immediately after the first authentication has successfully
 completed.
 When sent in an Access-Challenge, this attribute represents the
 maximum number of seconds that an IEEE 802.1X Authenticator should
 wait for an EAP-Response before retransmitting.  In this case, the
 Session-Timeout attribute is used to load the suppTimeout constant
 within the backend state machine of IEEE 802.1X.

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

3.18. Idle-Timeout

 The Idle-Timeout attribute is described in [RFC2865].  For IEEE 802
 media other than 802.11 the media are always on.  As a result the
 Idle-Timeout attribute is typically only used with wireless media
 such as IEEE 802.11.  It is possible for a wireless device to wander
 out of range of all Access Points.  In this case, the Idle-Timeout
 attribute indicates the maximum time that a wireless device may
 remain idle.

3.19. Termination-Action

 This attribute indicates what action should be taken when the service
 is completed.  The value RADIUS-Request (1) indicates that re-
 authentication should occur on expiration of the Session-Time.  The
 value Default (0) indicates that the session should terminate.

3.20. Called-Station-Id

 For IEEE 802.1X Authenticators, this attribute is used to store the
 bridge or Access Point MAC address in ASCII format (upper case only),
 with octet values separated by a "-".  Example: "00-10-A4-23-19-C0".
 In IEEE 802.11, where the SSID is known, it SHOULD be appended to the
 Access Point MAC address, separated from the MAC address with a ":".
 Example "00-10-A4-23-19-C0:AP1".

3.21. Calling-Station-Id

 For IEEE 802.1X Authenticators, this attribute is used to store the
 Supplicant MAC address in ASCII format (upper case only), with octet
 values separated by a "-".  Example: "00-10-A4-23-19-C0".

3.22. NAS-Identifier

 This attribute contains a string identifying the IEEE 802.1X
 Authenticator originating the Access-Request.

3.23. NAS-Port-Type

 For use with IEEE 802.1X, NAS-Port-Type values of Ethernet (15)
 Wireless - IEEE 802.11 (19), Token Ring (20) and FDDI (21) may be
 used.

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

3.24. Port-Limit

 This attribute has no meaning when sent to an [IEEE8021X]
 Authenticator.

3.25. Password-Retry

 In IEEE 802.1X, the Authenticator always transitions to the HELD
 state after an authentication failure.  Thus this attribute does not
 make sense for IEEE 802.1X.

3.26. Connect-Info

 This attribute is sent by a bridge or Access Point to indicate the
 nature of the Supplicant's connection.  When sent in the Access-
 Request it is recommended that this attribute contain information on
 the speed of the Supplicant's connection.  For 802.11, the following
 format is recommended: "CONNECT 11Mbps 802.11b".  If sent in the
 Accounting STOP, this attribute may be used to summarize statistics
 relating to session quality.  For example, in IEEE 802.11, the
 Connect-Info attribute may contain information on the number of link
 layer retransmissions.  The exact format of this attribute is
 implementation specific.

3.27. EAP-Message

 Since IEEE 802.1X provides for encapsulation of EAP as described in
 [RFC2284] and [IEEE8021X], the EAP-Message attribute defined in
 [RFC3579] is used to encapsulate EAP packets for transmission from
 the IEEE 802.1X Authenticator to the Authentication Server. [RFC3579]
 Section 2.2. describes how the Authentication Server handles invalid
 EAP packets passed to it by the Authenticator.

3.28. Message-Authenticator

 As noted in [RFC3579] Section 3.1., the Message-Authenticator
 attribute MUST be used to protect packets within a RADIUS/EAP
 conversation.

3.29. NAS-Port-Id

 This attribute is used to identify the IEEE 802.1X Authenticator port
 which authenticates the Supplicant.  The NAS-Port-Id differs from the
 NAS-Port in that it is a string of variable length whereas the NAS-
 Port is a 4 octet value.

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

3.30. Framed-Pool, Framed-IPv6-Pool

 IEEE 802.1X does not provide a mechanism for IP address assignment.
 Therefore the Framed-Pool and Framed-IPv6-Pool attributes can only be
 used by IEEE 802.1X Authenticators that support IP address assignment
 mechanisms.  Typically this capability is supported by layer 3
 devices.

3.31. Tunnel Attributes

 Reference [RFC2868] defines RADIUS tunnel attributes used for
 authentication and authorization, and [RFC2867] defines tunnel
 attributes used for accounting.  Where the IEEE 802.1X Authenticator
 supports tunneling, a compulsory tunnel may be set up for the
 Supplicant as a result of the authentication.
 In particular, it may be desirable to allow a port to be placed into
 a particular Virtual LAN (VLAN), defined in [IEEE8021Q], based on the
 result of the authentication.  This can be used, for example, to
 allow a wireless host to remain on the same VLAN as it moves within a
 campus network.
 The RADIUS server typically indicates the desired VLAN by including
 tunnel attributes within the Access-Accept.  However, the IEEE 802.1X
 Authenticator may also provide a hint as to the VLAN to be assigned
 to the Supplicant by including Tunnel attributes within the Access-
 Request.
 For use in VLAN assignment, the following tunnel attributes are used:
 Tunnel-Type=VLAN (13)
 Tunnel-Medium-Type=802
 Tunnel-Private-Group-ID=VLANID
 Note that the VLANID is 12-bits, taking a value between 1 and 4094,
 inclusive.  Since the Tunnel-Private-Group-ID is of type String as
 defined in [RFC2868], for use with IEEE 802.1X, the VLANID integer
 value is encoded as a string.
 When Tunnel attributes are sent, it is necessary to fill in the Tag
 field.  As noted in [RFC2868], section 3.1:
    The Tag field is one octet in length and is intended to provide a
    means of grouping attributes in the same packet which refer to the
    same tunnel.  Valid values for this field are 0x01 through 0x1F,
    inclusive.  If the Tag field is unused, it MUST be zero (0x00).

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

 For use with Tunnel-Client-Endpoint, Tunnel-Server-Endpoint, Tunnel-
 Private-Group-ID, Tunnel-Assignment-ID, Tunnel-Client-Auth-ID or
 Tunnel-Server-Auth-ID attributes (but not Tunnel-Type, Tunnel-
 Medium-Type, Tunnel-Password, or Tunnel-Preference), a tag field of
 greater than 0x1F is interpreted as the first octet of the following
 field.
 Unless alternative tunnel types are provided, (e.g. for IEEE 802.1X
 Authenticators that may support tunneling but not VLANs), it is only
 necessary for tunnel attributes to specify a single tunnel.  As a
 result, where it is only desired to specify the VLANID, the tag field
 SHOULD be set to zero (0x00) in all tunnel attributes.  Where
 alternative tunnel types are to be provided, tag values between 0x01
 and 0x1F SHOULD be chosen.

4. RC4 EAPOL-Key Frame

 The RC4 EAPOL-Key frame is created and transmitted by the
 Authenticator in order to provide media specific key information.
 For example, within 802.11 the RC4 EAPOL-Key frame can be used to
 distribute multicast/broadcast ("default") keys, or unicast ("key
 mapping") keys.  The "default" key is the same for all Stations
 within a broadcast domain.
 The RC4 EAPOL-Key frame is not acknowledged and therefore the
 Authenticator does not know whether the Supplicant has received it.
 If it is lost, then the Supplicant and Authenticator will not have
 the same keying material, and communication will fail.  If this
 occurs, the problem is typically addressed by re-running the
 authentication.
 The RC4 EAPOL-Key frame is sent from the Authenticator to the
 Supplicant in order to provision the "default" key, and subsequently
 in order to refresh the "default" key.  It may also be used to
 refresh the key-mapping key.  Rekey is typically only required with
 weak ciphersuites such as WEP, defined in [IEEE80211].
 Where keys are required, an EAP method that derives keys is typically
 selected.  Therefore the initial "key mapping" keys can be derived
 from EAP keying material, without requiring the Authenticator to send
 an RC4 EAPOL-Key frame to the Supplicant.  An example of how EAP
 keying material can be derived and used is presented in [RFC2716].

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

 While the RC4 EAPOL-Key frame is defined in [IEEE8021X], a more
 complete description is provided on the next page.
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    Version    |  Packet Type  |  Packet Body Length           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Type      |          Key  Length          |Replay Counter...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                             Replay Counter...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                             Replay Counter    |   Key IV...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                             Key IV...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                             Key IV...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                             Key IV...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                             Key IV...         |F| Key Index   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                             Key Signature...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                             Key Signature...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                             Key Signature...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                             Key Signature...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                             Key...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Version
    The Version field is one octet.  For IEEE 802.1X, it contains the
    value 0x01.
 Packet Type
    The Packet Type field is one octet, and determines the type of
    packet being transmitted.  For an EAPOL-Key Descriptor, the Packet
    Type field contains 0x03.
 Packet Body Length
    The Packet Body Length is two octets, and contains the length of
    the EAPOL-Key descriptor in octets, not including the Version,
    Packet Type and Packet Body Length fields.

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

 Type
    The Type field is a single octet.  The Key descriptor is defined
    differently for each Type; this specification documents only the
    RC4 Key Descriptor (Type = 0x01).
 Key Length
    The Key Length field is two octets.  If Packet Body Length = 44 +
    Key Length, then the Key Field contains the key in encrypted form,
    of length Key Length.  This is 5 octets (40 bits) for WEP, and 13
    octets (104 bits) for WEP-128.  If Packet Body Length = 44, then
    the Key field is absent, and Key Length represents the number of
    least significant octets from the MS-MPPE-Send-Key attribute
    [RFC2548] to be used as the keying material.  Note that the MS-
    MPPE-Send-Key and MS-MPPE-Recv-Key attributes are defined from the
    point of view of the Authenticator.  From the Supplicant point of
    reference, the terms are reversed.  Thus the MS-MPPE-Recv-Key on
    the Supplicant corresponds to the MS-MPPE-Send-Key on the
    Authenticator, and the MS-MPPE-Send-Key on the Supplicant
    corresponds to the MS-MPPE-Recv-Key on the Authenticator.
 Replay Counter
    The Replay Counter field is 8 octets.  It does not repeat within
    the life of the keying material used to encrypt the Key field and
    compute the Key Signature field.  A 64-bit NTP timestamp MAY be
    used as the Replay Counter.
 Key IV
    The Key IV field is 16 octets and includes a 128-bit
    cryptographically random number.
 F
    The Key flag (F) is a single bit, describing the type of key that
    is included in the Key field.  Values are:
    0 = for broadcast (default key)
    1 = for unicast (key mapping key)
 Key Index
    The Key Index is 7 bits.
 Key Signature
    The Key Signature field is 16 octets.  It contains an HMAC-MD5
    message integrity check computed over the EAPOL-Key descriptor,
    starting from the Version field, with the Key field filled in if
    present, but with the Key Signature field set to zero.  For the
    computation, the 32 octet (256 bit) MS-MPPE-Send-Key [RFC2548] is
    used as the HMAC-MD5 key.

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

 Key
    If Packet Body Length = 44 + Key Length, then the Key Field
    contains the key in encrypted form, of length Key Length.  If
    Packet Body Length = 44, then the Key field is absent, and the
    least significant Key Length octets from the MS-MPPE-Send-Key
    attribute is used as the keying material.  Where the Key field is
    encrypted using RC4, the RC4 encryption key used to encrypt this
    field is formed by concatenating the 16 octet (128 bit) Key-IV
    field with the 32 octet MS-MPPE-Recv-Key attribute.  This yields a
    48 octet RC4 key (384 bits).

5. Security Considerations

 Since this document describes the use of RADIUS for purposes of
 authentication, authorization, and accounting in IEEE 802.1X-enabled
 networks, it is vulnerable to all of the threats that are present in
 other RADIUS applications.  For a discussion of these threats, see
 [RFC2607], [RFC2865], [RFC3162], [RFC3579], and [RFC3576].
 Vulnerabilities include:
    Packet modification or forgery
    Dictionary attacks
    Known plaintext attacks
    Replay
    Outcome mismatches
    802.11 integration
    Key management issues

5.1. Packet Modification or Forgery

 RADIUS, defined in [RFC2865], does not require all Access-Requests to
 be authenticated or integrity protected.  However, IEEE 802.1X is
 based on EAP.  As described in [3579], Section 3.1.:
    The Message-Authenticator attribute MUST be used to protect all
    Access-Request, Access-Challenge, Access-Accept, and Access-Reject
    packets containing an EAP-Message attribute.
 As a result, when used with IEEE 802.1X, all RADIUS packets MUST be
 authenticated and integrity protected.  In addition, as described in
 [3579], Section 4.2.:
    To address the security vulnerabilities of RADIUS/EAP,
    implementations of this specification SHOULD support IPsec
    [RFC2401] along with IKE [RFC2409] for key management.  IPsec ESP
    [RFC2406] with non-null transform SHOULD be supported, and IPsec
    ESP with a non-null encryption transform and authentication

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

    support SHOULD be used to provide per-packet confidentiality,
    authentication, integrity and replay protection.  IKE SHOULD be
    used for key management.

5.2. Dictionary Attacks

 As discussed in [RFC3579] Section 4.3.3., the RADIUS shared secret is
 vulnerable to offline dictionary attack, based on capture of the
 Response Authenticator or Message-Authenticator attribute.  In order
 to decrease the level of vulnerability, [RFC2865], Section 3
 recommends:
    The secret (password shared between the client and the RADIUS
    server) SHOULD be at least as large and unguessable as a well-
    chosen password.  It is preferred that the secret be at least 16
    octets.
 In addition, the risk of an offline dictionary attack can be further
 mitigated by employing IPsec ESP with a non-null transform in order
 to encrypt the RADIUS conversation, as described in [RFC3579],
 Section 4.2.

5.3. Known Plaintext Attacks

 Since IEEE 802.1X is based on EAP, which does not support PAP, the
 RADIUS User-Password attribute is not used to carry hidden user
 passwords.  The hiding mechanism utilizes MD5, defined in [RFC1321],
 in order to generate a key stream based on the RADIUS shared secret
 and the Request Authenticator.  Where PAP is in use, it is possible
 to collect key streams corresponding to a given Request Authenticator
 value, by capturing RADIUS conversations corresponding to a PAP
 authentication attempt using a known password.  Since the User-
 Password is known, the key stream corresponding to a given Request
 Authenticator can be determined and stored.
 The vulnerability is described in detail in [RFC3579], Section 4.3.4.
 Even though IEEE 802.1X Authenticators do not support PAP
 authentication, a security vulnerability can still exist where the
 same RADIUS shared secret is used for hiding User-Password as well as
 other attributes.  This can occur, for example, if the same RADIUS
 proxy handles authentication requests for both IEEE 802.1X (which may
 hide the Tunnel-Password, MS-MPPE-Send-Key and MS-MPPE-Recv-Key
 attributes) and GPRS (which may hide the User-Password attribute).
 The threat can be mitigated by protecting RADIUS with IPsec ESP with
 a non-null transform, as described in [RFC3579], Section 4.2.  In
 addition, the same RADIUS shared secret MUST NOT be used for both
 IEEE 802.1X authentication and PAP authentication.

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

5.4. Replay

 As noted in [RFC3579] Section 4.3.5., the RADIUS protocol provides
 only limited support for replay protection.  Replay protection for
 RADIUS authentication and accounting can be provided by enabling
 IPsec replay protection with RADIUS, as described in [RFC3579],
 Section 4.2.
 As with the Request Authenticator, for use with IEEE 802.1X
 Authenticators, the Acct-Session-Id SHOULD be globally and temporally
 unique.

5.5. Outcome Mismatches

 [RFC3579] Section 2.6.3. discusses the issues that arise when the EAP
 packet encapsulated in an EAP-Message attribute does not agree with
 the RADIUS Packet Type.  For example, an EAP Success packet might be
 encapsulated within an Access-Reject; an EAP Failure might be sent
 within an Access-Accept; or an EAP Success or Failure might be sent
 within an Access-Challenge.
 As described in [RFC3579] Section 2.6.3., these conflicting messages
 are likely to cause confusion.  To ensure that access decisions made
 by IEEE 802.1X Authenticators conform to the wishes of the RADIUS
 server, it is necessary for the Authenticator to make the decision
 solely based on the authentication result (Access-Accept/Reject) and
 not based on the contents of EAP-Message attributes, if present.

5.6. 802.11 Integration

 [IEEE8021X] was developed for use on wired IEEE 802 networks such as
 Ethernet, and therefore does not describe how to securely adapt IEEE
 802.1X for use with 802.11.  This is left to an enhanced security
 specification under development within IEEE 802.11.
 For example, [IEEE8021X] does not specify whether authentication
 occurs prior to, or after association, nor how the derived keys are
 used within various ciphersuites.  It also does not specify
 ciphersuites addressing the vulnerabilities discovered in WEP,
 described in [Berkeley], [Arbaugh], [Fluhrer], and [Stubbl].
 [IEEE8021X] only defines an authentication framework, leaving the
 definition of the authentication methods to other documents, such as
 [RFC2716].
 Since [IEEE8021X] does not address 802.11 integration issues,
 implementors are strongly advised to consult additional IEEE 802.11
 security specifications for guidance on how to adapt IEEE 802.1X for
 use with 802.11.  For example, it is likely that the IEEE 802.11

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

 enhanced security specification will define its own IEEE 802.11 key
 hierarchy as well as new EAPOL-Key descriptors.

5.7. Key Management Issues

 The EAPOL-Key descriptor described in Section 4. is likely to be
 deprecated in the future, when the IEEE 802.11 enhanced security
 group completes its work.  Known security issues include:
 [1]  Default key-only support.  IEEE 802.1X enables the derivation of
      per-Station unicast keys, known in [IEEE80211] as "key mapping
      keys."  Keys used to encrypt multicast/broadcast traffic are
      known as "default keys".  However, in some 802.11
      implementations, the unicast keys, derived as part of the EAP
      authentication process, are used solely in order to encrypt,
      authenticate and integrity protect the EAPOL-Key descriptor, as
      described in Section 4.  These implementations only support use
      of default keys (ordinarily only used with multicast/broadcast
      traffic) to secure all traffic, unicast or multicast/broadcast,
      resulting in inherent security weaknesses.
      Where per-Station key-mapping keys (e.g. unicast keys) are
      unsupported, any Station possessing the default key can decrypt
      traffic from other Stations or impersonate them.  When used
      along with a weak cipher (e.g. WEP), implementations supporting
      only default keys provide more material for attacks such as
      those described in [Fluhrer] and [Stubbl].  If in addition, the
      default key is not refreshed periodically, IEEE 802.1X dynamic
      key derivation provides little or no security benefit.  For an
      understanding of the issues with WEP, see [Berkeley], [Arbaugh],
      [Fluhrer], and [Stubbl].
 [2]  Reuse of keying material.  The EAPOL-Key descriptor specified in
      section 4 uses the same keying material (MS-MPPE-Recv-Key) both
      to encrypt the Key field within the EAPOL-Key descriptor, and to
      encrypt data passed between the Station and Access Point.
      Multi-purpose keying material is frowned upon, since multiple
      uses can leak information helpful to an attacker.
 [3]  Weak algorithms.  The algorithm used to encrypt the Key field
      within the EAPOL-Key descriptor is similar to the algorithm used
      in WEP, and as a result, shares some of the same weaknesses.  As
      with WEP, the RC4 stream cipher is used to encrypt the key.  As
      input to the RC4 engine, the IV and key are concatenated rather
      than being combined within a mixing function.  As with WEP, the
      IV is not a counter, and therefore there is little protection
      against reuse.

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

 As a result of these vulnerabilities, implementors intending to use
 the EAPOL-Key descriptor described in this document are urged to
 consult the 802.11 enhanced security specification for a more secure
 alternative.  It is also advisable to consult the evolving literature
 on WEP vulnerabilities, in order to better understand the risks, as
 well as to obtain guidance on setting an appropriate re-keying
 interval.

6. IANA Considerations

 This specification does not create any RADIUS attributes nor any new
 number spaces for IANA administration.  However, it does require
 assignment of new values to existing RADIUS attributes.  These
 include:
 Attribute              Values Required
 =========              ===============
 NAS-Port-Type          Token-Ring (20), FDDI (21)
 Tunnel-Type            VLAN (13)
 Acct-Terminate-Cause   Supplicant Restart (19)
                        Reauthentication Failure (20)
                        Port Reinitialized (21)
                        Port Administratively Disabled (22)

7. References

7.1. Normative References

 [RFC1321]      Rivest, R., "The MD5 Message-Digest Algorithm", RFC
                1321, April 1992.
 [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC2284]      Blunk, L. and J. Vollbrecht, "PPP Extensible
                Authentication Protocol (EAP)", RFC 2284, March 1998.
 [RFC2865]      Rigney, C., Willens, S., Rubens, A. and W. Simpson,
                "Remote Authentication Dial In User Service (RADIUS)",
                RFC 2865, June 2000.
 [RFC2866]      Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
 [RFC2867]      Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting
                Modifications for Tunnel Protocol Support", RFC 2867,
                June 2000.

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

 [RFC2868]      Zorn, G., Leifer, D., Rubens, A., Shriver, J.,
                Holdrege, M. and I. Goyret, "RADIUS Attributes for
                Tunnel Protocol Support", RFC 2868, June 2000.
 [RFC2869]      Rigney, C., Willats, W. and P. Calhoun, "RADIUS
                Extensions", RFC 2869, June 2000.
 [RFC3162]      Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6",
                RFC 3162, August 2001.
 [RFC3280]      Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
                X.509 Public Key Infrastructure Certificate and
                Certificate Revocation List (CRL) Profile", RFC 3280,
                April 2002.
 [RFC3576]      Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B.
                Aboba, "Dynamic Authorization Extensions to Remote
                Authentication Dial In User Service (RADIUS)", RFC
                3576, July 2003.
 [RFC3579]      Aboba, B. and P. Calhoun, "RADIUS (Remote
                Authentication Dial In User Service) Support For
                Extensible Authentication Protocol (EAP)", RFC 3579,
                September 2003.
 [IEEE8021X]    IEEE Standards for Local and Metropolitan Area
                Networks:  Port based Network Access Control, IEEE Std
                802.1X-2001, June 2001.

7.2. Informative References

 [RFC2104]      Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:
                Keyed-Hashing for Message Authentication", RFC 2104,
                February 1997.
 [RFC2434]      Narten, T. and H. Alvestrand, "Guidelines for Writing
                an IANA Considerations Section in RFCs", BCP 26, RFC
                2434, October 1998.
 [RFC2548]      Zorn, G., "Microsoft Vendor-specific RADIUS
                Attributes", RFC 2548, March 1999.
 [RFC2607]      Aboba, B. and J. Vollbrecht, "Proxy Chaining and
                Policy Implementation in Roaming", RFC 2607, June
                1999.
 [RFC2716]      Aboba, B. and D. Simon, "PPP EAP TLS Authentication
                Protocol", RFC 2716, October 1999.

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

 [MD5Attack]    Dobbertin, H., "The Status of MD5 After a Recent
                Attack."  CryptoBytes Vol.2 No.2, Summer 1996.
 [IEEE802]      IEEE Standards for Local and Metropolitan Area
                Networks:  Overview and Architecture, ANSI/IEEE Std
                802, 1990.
 [IEEE8021Q]    IEEE Standards for Local and Metropolitan Area
                Networks:  Draft Standard for Virtual Bridged Local
                Area Networks, P802.1Q, January 1998.
 [IEEE8023]     ISO/IEC 8802-3 Information technology -
                Telecommunications and information exchange between
                systems - Local and metropolitan area networks -
                Common specifications - Part 3:  Carrier Sense
                Multiple Access with Collision Detection (CSMA/CD)
                Access Method and Physical Layer Specifications, (also
                ANSI/IEEE Std 802.3- 1996), 1996.
 [IEEE80211]    Information technology - Telecommunications and
                information exchange between systems - Local and
                metropolitan area networks - Specific Requirements
                Part 11:  Wireless LAN Medium Access Control (MAC) and
                Physical Layer (PHY) Specifications, IEEE Std.
                802.11-1999, 1999.
 [Berkeley]     Borisov, N., Goldberg, I. and D. Wagner, "Intercepting
                Mobile Communications: The Insecurity of 802.11", ACM
                SIGMOBILE, Seventh Annual International Conference on
                Mobile Computing and Networking, July 2001, Rome,
                Italy.
 [Arbaugh]      Arbaugh, W., Shankar, N. and J.Y.C. Wan, "Your 802.11
                Wireless Network has No Clothes", Department of
                Computer Science, University of Maryland, College
                Park, March 2001.
 [Fluhrer]      Fluhrer, S., Mantin, I. and A. Shamir, "Weaknesses in
                the Key Scheduling Algorithm of RC4", Eighth Annual
                Workshop on Selected Areas in Cryptography, Toronto,
                Canada, August 2001.
 [Stubbl]       Stubblefield, A., Ioannidis, J. and A. Rubin, "Using
                the Fluhrer, Mantin and Shamir Attack to Break WEP",
                2002 NDSS Conference.

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

8. Table of Attributes

 The following table provides a guide to which attributes MAY be sent
 and received as part of IEEE 802.1X authentication.  L3 denotes
 attributes that require layer 3 capabilities, and thus may not be
 supported by all Authenticators.  For each attribute, the reference
 provides the definitive information on usage.
 802.1X        #   Attribute
   X           1   User-Name [RFC2865]
               2   User-Password [RFC2865]
               3   CHAP-Password [RFC2865]
   X           4   NAS-IP-Address [RFC2865]
   X           5   NAS-Port [RFC2865]
   X           6   Service-Type [RFC2865]
               7   Framed-Protocol [RFC2865]
   L3          8   Framed-IP-Address [RFC2865]
   L3          9   Framed-IP-Netmask [RFC2865]
   L3         10   Framed-Routing [RFC2865]
   X          11   Filter-Id [RFC2865]
   X          12   Framed-MTU [RFC2865]
              13   Framed-Compression [RFC2865]
   L3         14   Login-IP-Host [RFC2865]
   L3         15   Login-Service [RFC2865]
   L3         16   Login-TCP-Port [RFC2865]
              18   Reply-Message [RFC2865]
              19   Callback-Number [RFC2865]
              20   Callback-Id [RFC2865]
   L3         22   Framed-Route [RFC2865]
   L3         23   Framed-IPX-Network [RFC2865]
   X          24   State [RFC2865]
   X          25   Class [RFC2865]
   X          26   Vendor-Specific [RFC2865]
   X          27   Session-Timeout [RFC2865]
   X          28   Idle-Timeout [RFC2865]
   X          29   Termination-Action [RFC2865]
   X          30   Called-Station-Id [RFC2865]
   X          31   Calling-Station-Id [RFC2865]
   X          32   NAS-Identifier [RFC2865]
   X          33   Proxy-State [RFC2865]
              34   Login-LAT-Service [RFC2865]
              35   Login-LAT-Node [RFC2865]
              36   Login-LAT-Group [RFC2865]
 802.1X        #   Attribute

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

 802.1X        #   Attribute
   L3         37   Framed-AppleTalk-Link [RFC2865]
   L3         38   Framed-AppleTalk-Network [RFC2865]
   L3         39   Framed-AppleTalk-Zone [RFC2865]
   X          40   Acct-Status-Type [RFC2866]
   X          41   Acct-Delay-Time [RFC2866]
   X          42   Acct-Input-Octets [RFC2866]
   X          43   Acct-Output-Octets [RFC2866]
   X          44   Acct-Session-Id [RFC2866]
   X          45   Acct-Authentic [RFC2866]
   X          46   Acct-Session-Time [RFC2866]
   X          47   Acct-Input-Packets [RFC2866]
   X          48   Acct-Output-Packets [RFC2866]
   X          49   Acct-Terminate-Cause [RFC2866]
   X          50   Acct-Multi-Session-Id [RFC2866]
   X          51   Acct-Link-Count [RFC2866]
   X          52   Acct-Input-Gigawords [RFC2869]
   X          53   Acct-Output-Gigawords [RFC2869]
   X          55   Event-Timestamp [RFC2869]
              60   CHAP-Challenge [RFC2865]
   X          61   NAS-Port-Type [RFC2865]
              62   Port-Limit [RFC2865]
              63   Login-LAT-Port [RFC2865]
   X          64   Tunnel-Type [RFC2868]
   X          65   Tunnel-Medium-Type [RFC2868]
   L3         66   Tunnel-Client-Endpoint [RFC2868]
   L3         67   Tunnel-Server-Endpoint [RFC2868]
   L3         68   Acct-Tunnel-Connection [RFC2867]
   L3         69   Tunnel-Password [RFC2868]
              70   ARAP-Password [RFC2869]
              71   ARAP-Features [RFC2869]
              72   ARAP-Zone-Access [RFC2869]
              73   ARAP-Security [RFC2869]
              74   ARAP-Security-Data [RFC2869]
              75   Password-Retry [RFC2869]
              76   Prompt [RFC2869]
   X          77   Connect-Info [RFC2869]
   X          78   Configuration-Token [RFC2869]
   X          79   EAP-Message [RFC3579]
   X          80   Message-Authenticator [RFC3579]
   X          81   Tunnel-Private-Group-ID [RFC2868]
   L3         82   Tunnel-Assignment-ID [RFC2868]
   X          83   Tunnel-Preference [RFC2868]
              84   ARAP-Challenge-Response [RFC2869]
 802.1X        #   Attribute

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

 802.1X        #   Attribute
   X          85   Acct-Interim-Interval [RFC2869]
   X          86   Acct-Tunnel-Packets-Lost [RFC2867]
   X          87   NAS-Port-Id [RFC2869]
   L3         88   Framed-Pool [RFC2869]
   L3         90   Tunnel-Client-Auth-ID [RFC2868]
   L3         91   Tunnel-Server-Auth-ID [RFC2868]
   X          95   NAS-IPv6-Address [RFC3162]
              96   Framed-Interface-Id [RFC3162]
   L3         97   Framed-IPv6-Prefix [RFC3162]
   L3         98   Login-IPv6-Host [RFC3162]
   L3         99   Framed-IPv6-Route [RFC3162]
   L3        100   Framed-IPv6-Pool [RFC3162]
   X         101   Error-Cause [RFC3576]
 802.1X        #   Attribute
 Key
 ===
 X         = May be used with IEEE 802.1X authentication
 L3        = Implemented only by Authenticators with Layer 3
             capabilities

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

9. Intellectual Property Statement

 The IETF takes no position regarding the validity or scope of any
 intellectual property or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; neither does it represent that it
 has made any effort to identify any such rights.  Information on the
 IETF's procedures with respect to rights in standards-track and
 standards- related documentation can be found in BCP-11.  Copies of
 claims of rights made available for publication and any assurances of
 licenses to be made available, or the result of an attempt made to
 obtain a general license or permission for the use of such
 proprietary rights by implementors or users of this specification can
 be obtained from the IETF Secretariat.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights which may cover technology that may be required to practice
 this standard.  Please address the information to the IETF Executive
 Director.

10. Acknowledgments

 The authors would like to acknowledge Bob O'Hara of Airespace, David
 Halasz of Cisco, Tim Moore, Sachin Seth and Ashwin Palekar of
 Microsoft, Andrea Li, Albert Young and Dave Bagby of 3Com for
 contributions to this document.

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

11. Authors' Addresses

 Paul Congdon
 Hewlett Packard Company
 HP ProCurve Networking
 8000 Foothills Blvd, M/S 5662
 Roseville, CA  95747
 Phone: +1 916 785 5753
 Fax:   +1 916 785 8478
 EMail: paul_congdon@hp.com
 Bernard Aboba
 Microsoft Corporation
 One Microsoft Way
 Redmond, WA 98052
 Phone: +1 425 706 6605
 Fax:   +1 425 936 7329
 EMail: bernarda@microsoft.com
 Andrew Smith
 Trapeze Networks
 5753 W. Las Positas Blvd.
 Pleasanton, CA 94588-4084
 Fax: +1 415 345 1827
 EMail: ah_smith@acm.org
 John Roese
 Enterasys
 Phone: +1 603 337 1506
 EMail: jjr@enterasys.com
 Glen Zorn
 Cisco Systems, Inc.
 500 108th Avenue N.E., Suite 500
 Bellevue, WA 98004
 Phone: +1 425 438 8218
 Fax:   +1 425 438 1848
 EMail: gwz@cisco.com

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

12. Full Copyright Statement

 Copyright (C) The Internet Society (2003).  All Rights Reserved.
 This document and translations of it may be copied and furnished to
 others, and derivative works that comment on or otherwise explain it
 or assist in its implementation may be prepared, copied, published
 and distributed, in whole or in part, without restriction of any
 kind, provided that the above copyright notice and this paragraph are
 included on all such copies and derivative works.  However, this
 document itself may not be modified in any way, such as by removing
 the copyright notice or references to the Internet Society or other
 Internet organizations, except as needed for the purpose of
 developing Internet standards in which case the procedures for
 copyrights defined in the Internet Standards process must be
 followed, or as required to translate it into languages other than
 English.
 The limited permissions granted above are perpetual and will not be
 revoked by the Internet Society or its successors or assignees.
 This document and the information contained herein is provided on an
 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Congdon, et al. Informational [Page 30]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3580.txt · Last modified: 2003/09/02 20:40 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki