7 Network Working Group P. Congdon
8 Request for Comments: 3580 Hewlett Packard Company
9 Category: Informational B. Aboba
20 IEEE 802.1X Remote Authentication Dial In User Service (RADIUS)
25 This memo provides information for the Internet community. It does
26 not specify an Internet standard of any kind. Distribution of this
31 Copyright (C) The Internet Society (2003). All Rights Reserved.
35 This document provides suggestions on Remote Authentication Dial In
36 User Service (RADIUS) usage by IEEE 802.1X Authenticators. The
37 material in this document is also included within a non-normative
38 Appendix within the IEEE 802.1X specification, and is being presented
39 as an IETF RFC for informational purposes.
58 Congdon, et al. Informational [Page 1]
60 RFC 3580 IEEE 802.1X RADIUS September 2003
65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
66 1.1. Terminology. . . . . . . . . . . . . . . . . . . . . . . 3
67 1.2. Requirements Language. . . . . . . . . . . . . . . . . . 4
68 2. RADIUS Accounting Attributes . . . . . . . . . . . . . . . . . 5
69 2.1. Acct-Terminate-Cause . . . . . . . . . . . . . . . . . . 5
70 2.2. Acct-Multi-Session-Id. . . . . . . . . . . . . . . . . . 6
71 2.3. Acct-Link-Count. . . . . . . . . . . . . . . . . . . . . 7
72 3. RADIUS Authentication. . . . . . . . . . . . . . . . . . . . . 7
73 3.1. User-Name. . . . . . . . . . . . . . . . . . . . . . . . 8
74 3.2. User-Password, CHAP-Password, CHAP-Challenge . . . . . . 8
75 3.3. NAS-IP-Address, NAS-IPv6-Address . . . . . . . . . . . . 8
76 3.4. NAS-Port . . . . . . . . . . . . . . . . . . . . . . . . 8
77 3.5. Service-Type . . . . . . . . . . . . . . . . . . . . . . 8
78 3.6. Framed-Protocol. . . . . . . . . . . . . . . . . . . . . 9
79 3.7. Framed-IP-Address, Framed-IP-Netmask . . . . . . . . . . 9
80 3.8. Framed-Routing . . . . . . . . . . . . . . . . . . . . . 9
81 3.9. Filter-ID. . . . . . . . . . . . . . . . . . . . . . . . 9
82 3.10. Framed-MTU . . . . . . . . . . . . . . . . . . . . . . . 9
83 3.11. Framed-Compression . . . . . . . . . . . . . . . . . . . 10
84 3.12. Displayable Messages . . . . . . . . . . . . . . . . . . 10
85 3.13. Callback-Number, Callback-ID . . . . . . . . . . . . . . 10
86 3.14. Framed-Route, Framed-IPv6-Route. . . . . . . . . . . . . 11
87 3.15. State, Class, Proxy-State. . . . . . . . . . . . . . . . 11
88 3.16. Vendor-Specific. . . . . . . . . . . . . . . . . . . . . 11
89 3.17. Session-Timeout. . . . . . . . . . . . . . . . . . . . . 11
90 3.18. Idle-Timeout . . . . . . . . . . . . . . . . . . . . . . 12
91 3.19. Termination-Action . . . . . . . . . . . . . . . . . . . 12
92 3.20. Called-Station-Id. . . . . . . . . . . . . . . . . . . . 12
93 3.21. Calling-Station-Id . . . . . . . . . . . . . . . . . . . 12
94 3.22. NAS-Identifier . . . . . . . . . . . . . . . . . . . . . 12
95 3.23. NAS-Port-Type. . . . . . . . . . . . . . . . . . . . . . 12
96 3.24. Port-Limit . . . . . . . . . . . . . . . . . . . . . . . 13
97 3.25. Password-Retry . . . . . . . . . . . . . . . . . . . . . 13
98 3.26. Connect-Info . . . . . . . . . . . . . . . . . . . . . . 13
99 3.27. EAP-Message. . . . . . . . . . . . . . . . . . . . . . . 13
100 3.28. Message-Authenticator. . . . . . . . . . . . . . . . . . 13
101 3.29. NAS-Port-Id. . . . . . . . . . . . . . . . . . . . . . . 13
102 3.30. Framed-Pool, Framed-IPv6-Pool. . . . . . . . . . . . . . 14
103 3.31. Tunnel Attributes. . . . . . . . . . . . . . . . . . . . 14
104 4. RC4 EAPOL-Key Descriptor . . . . . . . . . . . . . . . . . . . 15
105 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 18
106 5.1. Packet Modification or Forgery . . . . . . . . . . . . . 18
107 5.2. Dictionary Attacks . . . . . . . . . . . . . . . . . . . 19
108 5.3. Known Plaintext Attacks. . . . . . . . . . . . . . . . . 19
109 5.4. Replay . . . . . . . . . . . . . . . . . . . . . . . . . 20
110 5.5. Outcome Mismatches . . . . . . . . . . . . . . . . . . . 20
114 Congdon, et al. Informational [Page 2]
116 RFC 3580 IEEE 802.1X RADIUS September 2003
119 5.6. 802.11 Integration . . . . . . . . . . . . . . . . . . . 20
120 5.7. Key Management Issues. . . . . . . . . . . . . . . . . . 21
121 6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 22
122 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
123 7.1. Normative References . . . . . . . . . . . . . . . . . . 22
124 7.2. Informative References . . . . . . . . . . . . . . . . . 23
125 8. Table of Attributes. . . . . . . . . . . . . . . . . . . . . . 25
126 9. Intellectual Property Statement . . . . . . . . . . . . . . . 28
127 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
128 11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29
129 12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 30
133 IEEE 802.1X enables authenticated access to IEEE 802 media, including
134 Ethernet, Token Ring, and 802.11 wireless LANs. Although Remote
135 Authentication Dial In User Service (RADIUS) support is optional
136 within IEEE 802.1X, it is expected that many IEEE 802.1X
137 Authenticators will function as RADIUS clients.
139 IEEE 802.1X [IEEE8021X] provides "network port authentication" for
140 IEEE 802 [IEEE802] media, including Ethernet [IEEE8023], Token Ring
141 and 802.11 [IEEE80211] wireless LANS.
143 IEEE 802.1X does not require use of a backend Authentication Server,
144 and thus can be deployed with stand-alone bridges or Access Points,
145 as well as in centrally managed scenarios.
147 In situations where it is desirable to centrally manage
148 authentication, authorization and accounting (AAA) for IEEE 802
149 networks, deployment of a backend authentication and accounting
150 server is desirable. In such situations, it is expected that IEEE
151 802.1X Authenticators will function as AAA clients.
153 This document provides suggestions on RADIUS usage by IEEE 802.1X
154 Authenticators. Support for any AAA protocol is optional for IEEE
155 802.1X Authenticators, and therefore this specification has been
156 incorporated into a non-normative Appendix within the IEEE 802.1X
161 This document uses the following terms:
164 A Station that provides access to the distribution services via
165 the wireless medium for associated Stations.
170 Congdon, et al. Informational [Page 3]
172 RFC 3580 IEEE 802.1X RADIUS September 2003
176 The service used to establish Access Point/Station mapping and
177 enable Station invocation of the distribution system services.
180 An Authenticator is an entity that requires authentication from
181 the Supplicant. The Authenticator may be connected to the
182 Supplicant at the other end of a point-to-point LAN segment or
183 802.11 wireless link.
185 Authentication Server
186 An Authentication Server is an entity that provides an
187 Authentication Service to an Authenticator. This service
188 verifies, from the credentials provided by the Supplicant, the
189 claim of identity made by the Supplicant.
191 Port Access Entity (PAE)
192 The protocol entity associated with a physical or virtual
193 (802.11) Port. A given PAE may support the protocol
194 functionality associated with the Authenticator, Supplicant or
198 Any device that contains an IEEE 802.11 conformant medium
199 access control (MAC) and physical layer (PHY) interface to the
200 wireless medium (WM).
203 A Supplicant is an entity that is being authenticated by an
204 Authenticator. The Supplicant may be connected to the
205 Authenticator at one end of a point-to-point LAN segment or
206 802.11 wireless link.
208 1.2. Requirements Language
210 In this document, several words are used to signify the requirements
211 of the specification. These words are often capitalized. The key
212 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
213 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
214 are to be interpreted as described in [RFC2119].
226 Congdon, et al. Informational [Page 4]
228 RFC 3580 IEEE 802.1X RADIUS September 2003
231 2. RADIUS Accounting Attributes
233 With a few exceptions, the RADIUS accounting attributes defined in
234 [RFC2866], [RFC2867], and [RFC2869] have the same meaning within IEEE
235 802.1X sessions as they do in dialup sessions and therefore no
236 additional commentary is needed.
238 Attributes requiring more discussion include:
241 Acct-Multi-Session-Id
244 2.1. Acct-Terminate-Cause
246 This attribute indicates how the session was terminated, as described
247 in [RFC2866]. [IEEE8021X] defines the following termination cause
248 values, which are shown with their RADIUS equivalents in the table on
252 dot1xAuthSessionTerminateCause Acct-Terminate-Cause
254 ------------- --------------------
255 SupplicantLogoff(1) User Request (1)
256 portFailure(2) Lost Carrier (2)
257 SupplicantRestart(3) Supplicant Restart (19)
258 reauthFailed(4) Reauthentication Failure (20)
259 authControlForceUnauth(5) Admin Reset (6)
260 portReInit(6) Port Reinitialized (21)
261 portAdminDisabled(7) Port Administratively Disabled (22)
262 notTerminatedYet(999) N/A
264 When using this attribute, the User Request (1) termination cause
265 corresponds to the situation in which the session terminated due to
266 an EAPOL-Logoff received from the Supplicant. When a session is
267 moved due to roaming, the EAPOL state machines will treat this as a
270 A Lost Carrier (2) termination cause indicates session termination
271 due to loss of physical connectivity for reasons other than roaming
272 between Access Points. For example, if the Supplicant disconnects a
273 point-to-point LAN connection, or moves out of range of an Access
274 Point, this termination cause is used. Lost Carrier (2) therefore
275 equates to a Port Disabled condition in the EAPOL state machines.
277 A Supplicant Restart (19) termination cause indicates
278 re-initialization of the Supplicant state machines.
282 Congdon, et al. Informational [Page 5]
284 RFC 3580 IEEE 802.1X RADIUS September 2003
287 A Reauthentication Failure (20) termination cause indicates that a
288 previously authenticated Supplicant has failed to re-authenticate
289 successfully following expiry of the re-authentication timer or
290 explicit re-authentication request by management action.
292 Within [IEEE80211], periodic re-authentication may be useful in
293 preventing reuse of an initialization vector with a given key. Since
294 successful re-authentication does not result in termination of the
295 session, accounting packets are not sent as a result of
296 re-authentication unless the status of the session changes. For
299 a. The session is terminated due to re-authentication failure. In
300 this case the Reauthentication Failure (20) termination cause is
303 b. The authorizations are changed as a result of a successful
304 re-authentication. In this case, the Service Unavailable (15)
305 termination cause is used. For accounting purposes, the portion
306 of the session after the authorization change is treated as a
309 Where IEEE 802.1X authentication occurs prior to association,
310 accounting packets are not sent until an association occurs.
312 An Admin Reset (6) termination cause indicates that the Port has been
313 administratively forced into the unauthorized state.
315 A Port Reinitialized (21) termination cause indicates that the Port's
316 MAC has been reinitialized.
318 A Port Administratively Disabled (22) termination cause indicates
319 that the Port has been administratively disabled.
321 2.2. Acct-Multi-Session-Id
323 The purpose of this attribute is to make it possible to link together
324 multiple related sessions. While [IEEE8021X] does not act on
325 aggregated ports, it is possible for a Supplicant roaming between
326 Access Points to cause multiple RADIUS accounting packets to be sent
327 by different Access Points.
329 Where supported by the Access Points, the Acct-Multi-Session-Id
330 attribute can be used to link together the multiple related sessions
331 of a roaming Supplicant. In such a situation, if the session context
332 is transferred between Access Points, accounting packets MAY be sent
333 without a corresponding authentication and authorization exchange,
338 Congdon, et al. Informational [Page 6]
340 RFC 3580 IEEE 802.1X RADIUS September 2003
343 provided that Association has occurred. However, in such a situation
344 it is assumed that the Acct-Multi-Session-Id is transferred between
345 the Access Points as part of the Inter-Access Point Protocol (IAPP).
347 If the Acct-Multi-Session-Id were not unique between Access Points,
348 then it is possible that the chosen Acct-Multi-Session-Id will
349 overlap with an existing value allocated on that Access Point, and
350 the Accounting Server would therefore be unable to distinguish a
351 roaming session from a multi-link session.
353 As a result, the Acct-Multi-Session-Id attribute is unique among all
354 the bridges or Access Points, Supplicants and sessions. In order to
355 provide this uniqueness, it is suggested that the Acct-Multi-
356 Session-Id be of the form:
358 Original AP MAC Address | Supplicant MAC Address | NTP Timestamp
360 Here "|" represents concatenation, the original AP MAC Address is the
361 MAC address of the bridge or Access Point at which the session
362 started, and the 64-bit NTP timestamp indicates the beginning of the
363 original session. In order to provide for consistency of the Acct-
364 Multi-Session-Id between roaming sessions, the Acct-Multi-Session-Id
365 may be moved between Access Points as part of IAPP or another handoff
368 The use of an Acct-Multi-Session-Id of this form guarantees
369 uniqueness among all Access Points, Supplicants and sessions. Since
370 the NTP timestamp does not wrap on reboot, there is no possibility
371 that a rebooted Access Point could choose an Acct-Multi-Session-Id
372 that could be confused with that of a previous session.
374 Since the Acct-Multi-Session-Id is of type String as defined in
375 [RFC2866], for use with IEEE 802.1X, it is encoded as an ASCII string
376 of Hex digits. Example: "00-10-A4-23-19-C0-00-12-B2-
377 14-23-DE-AF-23-83-C0-76-B8-44-E8"
381 The Acct-Link-Count attribute may be used to account for the number
382 of ports that have been aggregated.
384 3. RADIUS Authentication
386 This section describes how attributes defined in [RFC2865],
387 [RFC2867], [RFC2868], [RFC2869], [RFC3162] and [RFC3579] are used in
388 IEEE 802.1X authentication.
394 Congdon, et al. Informational [Page 7]
396 RFC 3580 IEEE 802.1X RADIUS September 2003
401 In IEEE 802.1X, the Supplicant typically provides its identity via an
402 EAP-Response/Identity message. Where available, the Supplicant
403 identity is included in the User-Name attribute, and included in the
404 RADIUS Access-Request and Access-Reply messages as specified in
405 [RFC2865] and [RFC3579].
407 Alternatively, as discussed in [RFC3579] Section 2.1., the User-Name
408 attribute may contain the Calling-Station-ID value, which is set to
409 the Supplicant MAC address.
411 3.2. User-Password, CHAP-Password, CHAP-Challenge
413 Since IEEE 802.1X does not support PAP or CHAP authentication, the
414 User-Password, CHAP-Password or CHAP-Challenge attributes are not
415 used by IEEE 802.1X Authenticators acting as RADIUS clients.
417 3.3. NAS-IP-Address, NAS-IPv6-Address
419 For use with IEEE 802.1X, the NAS-IP-Address contains the IPv4
420 address of the bridge or Access Point acting as an Authenticator, and
421 the NAS-IPv6-Address contains the IPv6 address. If the IEEE 802.1X
422 Authenticator has more than one interface, it may be desirable to use
423 a loopback address for this purpose so that the Authenticator will
424 still be reachable even if one of the interfaces were to fail.
428 For use with IEEE 802.1X the NAS-Port will contain the port number of
429 the bridge, if this is available. While an Access Point does not
430 have physical ports, a unique "association ID" is assigned to every
431 mobile Station upon a successful association exchange. As a result,
432 for an Access Point, if the association exchange has been completed
433 prior to authentication, the NAS-Port attribute will contain the
434 association ID, which is a 16-bit unsigned integer. Where IEEE
435 802.1X authentication occurs prior to association, a unique NAS-Port
436 value may not be available.
440 For use with IEEE 802.1X, the Framed (2), Authenticate Only (8), and
441 Call Check (10) values are most commonly used.
443 A Service-Type of Framed indicates that appropriate 802 framing
444 should be used for the connection. A Service-Type of Authenticate
445 Only (8) indicates that no authorization information needs to be
446 returned in the Access-Accept. As described in [RFC2865], a
450 Congdon, et al. Informational [Page 8]
452 RFC 3580 IEEE 802.1X RADIUS September 2003
455 Service-Type of Call Check is included in an Access-Request packet to
456 request that the RADIUS server accept or reject the connection
457 attempt, typically based on the Called-Station-ID (set to the bridge
458 or Access Point MAC address) or Calling-Station-ID attributes (set to
459 the Supplicant MAC address). As noted in [RFC2865], it is
460 recommended that in this case, the User-Name attribute be given the
461 value of Calling-Station-Id.
465 Since there is no value for IEEE 802 media, the Framed-Protocol
466 attribute is not used by IEEE 802.1X Authenticators.
468 3.7. Framed-IP-Address, Framed-IP-Netmask
470 IEEE 802.1X does not provide a mechanism for IP address assignment.
471 Therefore the Framed-IP-Address and Framed-IP-Netmask attributes can
472 only be used by IEEE 802.1X Authenticators that support IP address
473 assignment mechanisms. Typically this capability is supported by
478 The Framed-Routing attribute indicates the routing method for the
479 Supplicant. It is therefore only relevant for IEEE 802.1X
480 Authenticators that act as layer 3 devices, and cannot be used by a
481 bridge or Access Point.
485 This attribute indicates the name of the filter list to be applied to
486 the Supplicant's session. For use with an IEEE 802.1X Authenticator,
487 it may be used to indicate either layer 2 or layer 3 filters. Layer
488 3 filters are typically only supported on IEEE 802.1X Authenticators
489 that act as layer 3 devices.
493 This attribute indicates the maximum size of an IP packet that may be
494 transmitted over the wire between the Supplicant and the
495 Authenticator. IEEE 802.1X Authenticators set this to the value
496 corresponding to the relevant 802 medium, and include it in the
497 RADIUS Access-Request. The RADIUS server may send an EAP packet as
498 large as Framed-MTU minus four (4) octets, taking into account the
499 additional overhead for the IEEE 802.1X Version (1), Type (1) and
500 Body Length (2) fields. For EAP over IEEE 802 media, the Framed-MTU
501 values (which do not include LLC/SNAP overhead) and maximum frame
502 length values (not including the preamble) are as follows:
506 Congdon, et al. Informational [Page 9]
508 RFC 3580 IEEE 802.1X RADIUS September 2003
512 Media Framed-MTU Length
513 ========= =============== ==============
517 802.5 (4 Mbps) 4528 4550
518 802.5 (16 Mbps) 18173 18200
519 802.5 (100 Mb/s) 18173 18200
523 802.12 (Ethernet) 1500 1518
524 802.12 (Token Ring) 4502 4528
527 NOTE - the Framed-MTU size for IEEE 802.11 media may change as a
528 result of ongoing work being undertaken in the IEEE 802.11 Working
529 Group. Since some 802.11 stations cannot handle an MTU larger than
530 1500 octets, it is recommended that RADIUS servers encountering a
531 NAS-Port-Type value of 802.11 send EAP packets no larger than 1496
534 3.11. Framed-Compression
536 [IEEE8021X] does not include compression support. Therefore this
537 attribute is not understood by [IEEE8021X] Authenticators.
539 3.12. Displayable Messages
541 The Reply-Message attribute, defined in section 5.18 of [RFC2865],
542 indicates text which may be displayed to the user. This is similar
543 in concept to the EAP Notification Type, defined in [RFC2284]. As
544 noted in [RFC3579], Section 2.6.5, when sending a displayable message
545 to an [IEEE8021X] Authenticator, displayable messages are best sent
546 within EAP-Message/EAP-Request/Notification attribute(s), and not
547 within Reply-Message attribute(s).
549 3.13. Callback-Number, Callback-ID
551 These attributes are not understood by IEEE 802.1X Authenticators.
562 Congdon, et al. Informational [Page 10]
564 RFC 3580 IEEE 802.1X RADIUS September 2003
567 3.14. Framed-Route, Framed-IPv6-Route
569 The Framed-Route and Framed-IPv6-Route attributes provide routes that
570 are to be configured for the Supplicant. These attributes are
571 therefore only relevant for IEEE 802.1X Authenticators that act as
572 layer 3 devices, and cannot be understood by a bridge or Access
575 3.15. State, Class, Proxy-State
577 These attributes are used for the same purposes as described in
580 3.16. Vendor-Specific
582 Vendor-specific attributes are used for the same purposes as
583 described in [RFC2865]. The MS-MPPE-Send-Key and MS-MPPE-Recv-Key
584 attributes, described in section 2.4 of [RFC2548], MAY be used to
585 encrypt and authenticate the RC4 EAPOL-Key descriptor [IEEE8021X,
586 Section 7.6]. Examples of the derivation of the MS-MPPE-Send-Key and
587 MS-MPPE-Recv-Key attributes from the master key negotiated by an EAP
588 method are given in [RFC2716]. Details of the EAPOL-Key descriptor
589 are provided in Section 4.
591 3.17. Session-Timeout
593 When sent along in an Access-Accept without a Termination-Action
594 attribute or with a Termination-Action attribute set to Default, the
595 Session-Timeout attribute specifies the maximum number of seconds of
596 service provided prior to session termination.
598 When sent in an Access-Accept along with a Termination-Action value
599 of RADIUS-Request, the Session-Timeout attribute specifies the
600 maximum number of seconds of service provided prior to re-
601 authentication. In this case, the Session-Timeout attribute is used
602 to load the reAuthPeriod constant within the Reauthentication Timer
603 state machine of 802.1X. When sent with a Termination-Action value
604 of RADIUS-Request, a Session-Timeout value of zero indicates the
605 desire to perform another authentication (possibly of a different
606 type) immediately after the first authentication has successfully
609 When sent in an Access-Challenge, this attribute represents the
610 maximum number of seconds that an IEEE 802.1X Authenticator should
611 wait for an EAP-Response before retransmitting. In this case, the
612 Session-Timeout attribute is used to load the suppTimeout constant
613 within the backend state machine of IEEE 802.1X.
618 Congdon, et al. Informational [Page 11]
620 RFC 3580 IEEE 802.1X RADIUS September 2003
625 The Idle-Timeout attribute is described in [RFC2865]. For IEEE 802
626 media other than 802.11 the media are always on. As a result the
627 Idle-Timeout attribute is typically only used with wireless media
628 such as IEEE 802.11. It is possible for a wireless device to wander
629 out of range of all Access Points. In this case, the Idle-Timeout
630 attribute indicates the maximum time that a wireless device may
633 3.19. Termination-Action
635 This attribute indicates what action should be taken when the service
636 is completed. The value RADIUS-Request (1) indicates that re-
637 authentication should occur on expiration of the Session-Time. The
638 value Default (0) indicates that the session should terminate.
640 3.20. Called-Station-Id
642 For IEEE 802.1X Authenticators, this attribute is used to store the
643 bridge or Access Point MAC address in ASCII format (upper case only),
644 with octet values separated by a "-". Example: "00-10-A4-23-19-C0".
645 In IEEE 802.11, where the SSID is known, it SHOULD be appended to the
646 Access Point MAC address, separated from the MAC address with a ":".
647 Example "00-10-A4-23-19-C0:AP1".
649 3.21. Calling-Station-Id
651 For IEEE 802.1X Authenticators, this attribute is used to store the
652 Supplicant MAC address in ASCII format (upper case only), with octet
653 values separated by a "-". Example: "00-10-A4-23-19-C0".
657 This attribute contains a string identifying the IEEE 802.1X
658 Authenticator originating the Access-Request.
662 For use with IEEE 802.1X, NAS-Port-Type values of Ethernet (15)
663 Wireless - IEEE 802.11 (19), Token Ring (20) and FDDI (21) may be
674 Congdon, et al. Informational [Page 12]
676 RFC 3580 IEEE 802.1X RADIUS September 2003
681 This attribute has no meaning when sent to an [IEEE8021X]
686 In IEEE 802.1X, the Authenticator always transitions to the HELD
687 state after an authentication failure. Thus this attribute does not
688 make sense for IEEE 802.1X.
692 This attribute is sent by a bridge or Access Point to indicate the
693 nature of the Supplicant's connection. When sent in the Access-
694 Request it is recommended that this attribute contain information on
695 the speed of the Supplicant's connection. For 802.11, the following
696 format is recommended: "CONNECT 11Mbps 802.11b". If sent in the
697 Accounting STOP, this attribute may be used to summarize statistics
698 relating to session quality. For example, in IEEE 802.11, the
699 Connect-Info attribute may contain information on the number of link
700 layer retransmissions. The exact format of this attribute is
701 implementation specific.
705 Since IEEE 802.1X provides for encapsulation of EAP as described in
706 [RFC2284] and [IEEE8021X], the EAP-Message attribute defined in
707 [RFC3579] is used to encapsulate EAP packets for transmission from
708 the IEEE 802.1X Authenticator to the Authentication Server. [RFC3579]
709 Section 2.2. describes how the Authentication Server handles invalid
710 EAP packets passed to it by the Authenticator.
712 3.28. Message-Authenticator
714 As noted in [RFC3579] Section 3.1., the Message-Authenticator
715 attribute MUST be used to protect packets within a RADIUS/EAP
720 This attribute is used to identify the IEEE 802.1X Authenticator port
721 which authenticates the Supplicant. The NAS-Port-Id differs from the
722 NAS-Port in that it is a string of variable length whereas the NAS-
723 Port is a 4 octet value.
730 Congdon, et al. Informational [Page 13]
732 RFC 3580 IEEE 802.1X RADIUS September 2003
735 3.30. Framed-Pool, Framed-IPv6-Pool
737 IEEE 802.1X does not provide a mechanism for IP address assignment.
738 Therefore the Framed-Pool and Framed-IPv6-Pool attributes can only be
739 used by IEEE 802.1X Authenticators that support IP address assignment
740 mechanisms. Typically this capability is supported by layer 3
743 3.31. Tunnel Attributes
745 Reference [RFC2868] defines RADIUS tunnel attributes used for
746 authentication and authorization, and [RFC2867] defines tunnel
747 attributes used for accounting. Where the IEEE 802.1X Authenticator
748 supports tunneling, a compulsory tunnel may be set up for the
749 Supplicant as a result of the authentication.
751 In particular, it may be desirable to allow a port to be placed into
752 a particular Virtual LAN (VLAN), defined in [IEEE8021Q], based on the
753 result of the authentication. This can be used, for example, to
754 allow a wireless host to remain on the same VLAN as it moves within a
757 The RADIUS server typically indicates the desired VLAN by including
758 tunnel attributes within the Access-Accept. However, the IEEE 802.1X
759 Authenticator may also provide a hint as to the VLAN to be assigned
760 to the Supplicant by including Tunnel attributes within the Access-
763 For use in VLAN assignment, the following tunnel attributes are used:
765 Tunnel-Type=VLAN (13)
766 Tunnel-Medium-Type=802
767 Tunnel-Private-Group-ID=VLANID
769 Note that the VLANID is 12-bits, taking a value between 1 and 4094,
770 inclusive. Since the Tunnel-Private-Group-ID is of type String as
771 defined in [RFC2868], for use with IEEE 802.1X, the VLANID integer
772 value is encoded as a string.
774 When Tunnel attributes are sent, it is necessary to fill in the Tag
775 field. As noted in [RFC2868], section 3.1:
777 The Tag field is one octet in length and is intended to provide a
778 means of grouping attributes in the same packet which refer to the
779 same tunnel. Valid values for this field are 0x01 through 0x1F,
780 inclusive. If the Tag field is unused, it MUST be zero (0x00).
786 Congdon, et al. Informational [Page 14]
788 RFC 3580 IEEE 802.1X RADIUS September 2003
791 For use with Tunnel-Client-Endpoint, Tunnel-Server-Endpoint, Tunnel-
792 Private-Group-ID, Tunnel-Assignment-ID, Tunnel-Client-Auth-ID or
793 Tunnel-Server-Auth-ID attributes (but not Tunnel-Type, Tunnel-
794 Medium-Type, Tunnel-Password, or Tunnel-Preference), a tag field of
795 greater than 0x1F is interpreted as the first octet of the following
798 Unless alternative tunnel types are provided, (e.g. for IEEE 802.1X
799 Authenticators that may support tunneling but not VLANs), it is only
800 necessary for tunnel attributes to specify a single tunnel. As a
801 result, where it is only desired to specify the VLANID, the tag field
802 SHOULD be set to zero (0x00) in all tunnel attributes. Where
803 alternative tunnel types are to be provided, tag values between 0x01
804 and 0x1F SHOULD be chosen.
806 4. RC4 EAPOL-Key Frame
808 The RC4 EAPOL-Key frame is created and transmitted by the
809 Authenticator in order to provide media specific key information.
810 For example, within 802.11 the RC4 EAPOL-Key frame can be used to
811 distribute multicast/broadcast ("default") keys, or unicast ("key
812 mapping") keys. The "default" key is the same for all Stations
813 within a broadcast domain.
815 The RC4 EAPOL-Key frame is not acknowledged and therefore the
816 Authenticator does not know whether the Supplicant has received it.
817 If it is lost, then the Supplicant and Authenticator will not have
818 the same keying material, and communication will fail. If this
819 occurs, the problem is typically addressed by re-running the
822 The RC4 EAPOL-Key frame is sent from the Authenticator to the
823 Supplicant in order to provision the "default" key, and subsequently
824 in order to refresh the "default" key. It may also be used to
825 refresh the key-mapping key. Rekey is typically only required with
826 weak ciphersuites such as WEP, defined in [IEEE80211].
828 Where keys are required, an EAP method that derives keys is typically
829 selected. Therefore the initial "key mapping" keys can be derived
830 from EAP keying material, without requiring the Authenticator to send
831 an RC4 EAPOL-Key frame to the Supplicant. An example of how EAP
832 keying material can be derived and used is presented in [RFC2716].
842 Congdon, et al. Informational [Page 15]
844 RFC 3580 IEEE 802.1X RADIUS September 2003
847 While the RC4 EAPOL-Key frame is defined in [IEEE8021X], a more
848 complete description is provided on the next page.
851 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
852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
853 | Version | Packet Type | Packet Body Length |
854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
855 | Type | Key Length |Replay Counter...
856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
859 | Replay Counter | Key IV...
860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
867 | Key IV... |F| Key Index |
868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
881 The Version field is one octet. For IEEE 802.1X, it contains the
885 The Packet Type field is one octet, and determines the type of
886 packet being transmitted. For an EAPOL-Key Descriptor, the Packet
887 Type field contains 0x03.
890 The Packet Body Length is two octets, and contains the length of
891 the EAPOL-Key descriptor in octets, not including the Version,
892 Packet Type and Packet Body Length fields.
898 Congdon, et al. Informational [Page 16]
900 RFC 3580 IEEE 802.1X RADIUS September 2003
904 The Type field is a single octet. The Key descriptor is defined
905 differently for each Type; this specification documents only the
906 RC4 Key Descriptor (Type = 0x01).
909 The Key Length field is two octets. If Packet Body Length = 44 +
910 Key Length, then the Key Field contains the key in encrypted form,
911 of length Key Length. This is 5 octets (40 bits) for WEP, and 13
912 octets (104 bits) for WEP-128. If Packet Body Length = 44, then
913 the Key field is absent, and Key Length represents the number of
914 least significant octets from the MS-MPPE-Send-Key attribute
915 [RFC2548] to be used as the keying material. Note that the MS-
916 MPPE-Send-Key and MS-MPPE-Recv-Key attributes are defined from the
917 point of view of the Authenticator. From the Supplicant point of
918 reference, the terms are reversed. Thus the MS-MPPE-Recv-Key on
919 the Supplicant corresponds to the MS-MPPE-Send-Key on the
920 Authenticator, and the MS-MPPE-Send-Key on the Supplicant
921 corresponds to the MS-MPPE-Recv-Key on the Authenticator.
924 The Replay Counter field is 8 octets. It does not repeat within
925 the life of the keying material used to encrypt the Key field and
926 compute the Key Signature field. A 64-bit NTP timestamp MAY be
927 used as the Replay Counter.
930 The Key IV field is 16 octets and includes a 128-bit
931 cryptographically random number.
934 The Key flag (F) is a single bit, describing the type of key that
935 is included in the Key field. Values are:
937 0 = for broadcast (default key)
938 1 = for unicast (key mapping key)
941 The Key Index is 7 bits.
944 The Key Signature field is 16 octets. It contains an HMAC-MD5
945 message integrity check computed over the EAPOL-Key descriptor,
946 starting from the Version field, with the Key field filled in if
947 present, but with the Key Signature field set to zero. For the
948 computation, the 32 octet (256 bit) MS-MPPE-Send-Key [RFC2548] is
949 used as the HMAC-MD5 key.
954 Congdon, et al. Informational [Page 17]
956 RFC 3580 IEEE 802.1X RADIUS September 2003
960 If Packet Body Length = 44 + Key Length, then the Key Field
961 contains the key in encrypted form, of length Key Length. If
962 Packet Body Length = 44, then the Key field is absent, and the
963 least significant Key Length octets from the MS-MPPE-Send-Key
964 attribute is used as the keying material. Where the Key field is
965 encrypted using RC4, the RC4 encryption key used to encrypt this
966 field is formed by concatenating the 16 octet (128 bit) Key-IV
967 field with the 32 octet MS-MPPE-Recv-Key attribute. This yields a
968 48 octet RC4 key (384 bits).
970 5. Security Considerations
972 Since this document describes the use of RADIUS for purposes of
973 authentication, authorization, and accounting in IEEE 802.1X-enabled
974 networks, it is vulnerable to all of the threats that are present in
975 other RADIUS applications. For a discussion of these threats, see
976 [RFC2607], [RFC2865], [RFC3162], [RFC3579], and [RFC3576].
978 Vulnerabilities include:
980 Packet modification or forgery
982 Known plaintext attacks
986 Key management issues
988 5.1. Packet Modification or Forgery
990 RADIUS, defined in [RFC2865], does not require all Access-Requests to
991 be authenticated or integrity protected. However, IEEE 802.1X is
992 based on EAP. As described in [3579], Section 3.1.:
994 The Message-Authenticator attribute MUST be used to protect all
995 Access-Request, Access-Challenge, Access-Accept, and Access-Reject
996 packets containing an EAP-Message attribute.
998 As a result, when used with IEEE 802.1X, all RADIUS packets MUST be
999 authenticated and integrity protected. In addition, as described in
1000 [3579], Section 4.2.:
1002 To address the security vulnerabilities of RADIUS/EAP,
1003 implementations of this specification SHOULD support IPsec
1004 [RFC2401] along with IKE [RFC2409] for key management. IPsec ESP
1005 [RFC2406] with non-null transform SHOULD be supported, and IPsec
1006 ESP with a non-null encryption transform and authentication
1010 Congdon, et al. Informational [Page 18]
1012 RFC 3580 IEEE 802.1X RADIUS September 2003
1015 support SHOULD be used to provide per-packet confidentiality,
1016 authentication, integrity and replay protection. IKE SHOULD be
1017 used for key management.
1019 5.2. Dictionary Attacks
1021 As discussed in [RFC3579] Section 4.3.3., the RADIUS shared secret is
1022 vulnerable to offline dictionary attack, based on capture of the
1023 Response Authenticator or Message-Authenticator attribute. In order
1024 to decrease the level of vulnerability, [RFC2865], Section 3
1027 The secret (password shared between the client and the RADIUS
1028 server) SHOULD be at least as large and unguessable as a well-
1029 chosen password. It is preferred that the secret be at least 16
1032 In addition, the risk of an offline dictionary attack can be further
1033 mitigated by employing IPsec ESP with a non-null transform in order
1034 to encrypt the RADIUS conversation, as described in [RFC3579],
1037 5.3. Known Plaintext Attacks
1039 Since IEEE 802.1X is based on EAP, which does not support PAP, the
1040 RADIUS User-Password attribute is not used to carry hidden user
1041 passwords. The hiding mechanism utilizes MD5, defined in [RFC1321],
1042 in order to generate a key stream based on the RADIUS shared secret
1043 and the Request Authenticator. Where PAP is in use, it is possible
1044 to collect key streams corresponding to a given Request Authenticator
1045 value, by capturing RADIUS conversations corresponding to a PAP
1046 authentication attempt using a known password. Since the User-
1047 Password is known, the key stream corresponding to a given Request
1048 Authenticator can be determined and stored.
1050 The vulnerability is described in detail in [RFC3579], Section 4.3.4.
1051 Even though IEEE 802.1X Authenticators do not support PAP
1052 authentication, a security vulnerability can still exist where the
1053 same RADIUS shared secret is used for hiding User-Password as well as
1054 other attributes. This can occur, for example, if the same RADIUS
1055 proxy handles authentication requests for both IEEE 802.1X (which may
1056 hide the Tunnel-Password, MS-MPPE-Send-Key and MS-MPPE-Recv-Key
1057 attributes) and GPRS (which may hide the User-Password attribute).
1059 The threat can be mitigated by protecting RADIUS with IPsec ESP with
1060 a non-null transform, as described in [RFC3579], Section 4.2. In
1061 addition, the same RADIUS shared secret MUST NOT be used for both
1062 IEEE 802.1X authentication and PAP authentication.
1066 Congdon, et al. Informational [Page 19]
1068 RFC 3580 IEEE 802.1X RADIUS September 2003
1073 As noted in [RFC3579] Section 4.3.5., the RADIUS protocol provides
1074 only limited support for replay protection. Replay protection for
1075 RADIUS authentication and accounting can be provided by enabling
1076 IPsec replay protection with RADIUS, as described in [RFC3579],
1079 As with the Request Authenticator, for use with IEEE 802.1X
1080 Authenticators, the Acct-Session-Id SHOULD be globally and temporally
1083 5.5. Outcome Mismatches
1085 [RFC3579] Section 2.6.3. discusses the issues that arise when the EAP
1086 packet encapsulated in an EAP-Message attribute does not agree with
1087 the RADIUS Packet Type. For example, an EAP Success packet might be
1088 encapsulated within an Access-Reject; an EAP Failure might be sent
1089 within an Access-Accept; or an EAP Success or Failure might be sent
1090 within an Access-Challenge.
1092 As described in [RFC3579] Section 2.6.3., these conflicting messages
1093 are likely to cause confusion. To ensure that access decisions made
1094 by IEEE 802.1X Authenticators conform to the wishes of the RADIUS
1095 server, it is necessary for the Authenticator to make the decision
1096 solely based on the authentication result (Access-Accept/Reject) and
1097 not based on the contents of EAP-Message attributes, if present.
1099 5.6. 802.11 Integration
1101 [IEEE8021X] was developed for use on wired IEEE 802 networks such as
1102 Ethernet, and therefore does not describe how to securely adapt IEEE
1103 802.1X for use with 802.11. This is left to an enhanced security
1104 specification under development within IEEE 802.11.
1106 For example, [IEEE8021X] does not specify whether authentication
1107 occurs prior to, or after association, nor how the derived keys are
1108 used within various ciphersuites. It also does not specify
1109 ciphersuites addressing the vulnerabilities discovered in WEP,
1110 described in [Berkeley], [Arbaugh], [Fluhrer], and [Stubbl].
1111 [IEEE8021X] only defines an authentication framework, leaving the
1112 definition of the authentication methods to other documents, such as
1115 Since [IEEE8021X] does not address 802.11 integration issues,
1116 implementors are strongly advised to consult additional IEEE 802.11
1117 security specifications for guidance on how to adapt IEEE 802.1X for
1118 use with 802.11. For example, it is likely that the IEEE 802.11
1122 Congdon, et al. Informational [Page 20]
1124 RFC 3580 IEEE 802.1X RADIUS September 2003
1127 enhanced security specification will define its own IEEE 802.11 key
1128 hierarchy as well as new EAPOL-Key descriptors.
1130 5.7. Key Management Issues
1132 The EAPOL-Key descriptor described in Section 4. is likely to be
1133 deprecated in the future, when the IEEE 802.11 enhanced security
1134 group completes its work. Known security issues include:
1136 [1] Default key-only support. IEEE 802.1X enables the derivation of
1137 per-Station unicast keys, known in [IEEE80211] as "key mapping
1138 keys." Keys used to encrypt multicast/broadcast traffic are
1139 known as "default keys". However, in some 802.11
1140 implementations, the unicast keys, derived as part of the EAP
1141 authentication process, are used solely in order to encrypt,
1142 authenticate and integrity protect the EAPOL-Key descriptor, as
1143 described in Section 4. These implementations only support use
1144 of default keys (ordinarily only used with multicast/broadcast
1145 traffic) to secure all traffic, unicast or multicast/broadcast,
1146 resulting in inherent security weaknesses.
1148 Where per-Station key-mapping keys (e.g. unicast keys) are
1149 unsupported, any Station possessing the default key can decrypt
1150 traffic from other Stations or impersonate them. When used
1151 along with a weak cipher (e.g. WEP), implementations supporting
1152 only default keys provide more material for attacks such as
1153 those described in [Fluhrer] and [Stubbl]. If in addition, the
1154 default key is not refreshed periodically, IEEE 802.1X dynamic
1155 key derivation provides little or no security benefit. For an
1156 understanding of the issues with WEP, see [Berkeley], [Arbaugh],
1157 [Fluhrer], and [Stubbl].
1159 [2] Reuse of keying material. The EAPOL-Key descriptor specified in
1160 section 4 uses the same keying material (MS-MPPE-Recv-Key) both
1161 to encrypt the Key field within the EAPOL-Key descriptor, and to
1162 encrypt data passed between the Station and Access Point.
1163 Multi-purpose keying material is frowned upon, since multiple
1164 uses can leak information helpful to an attacker.
1166 [3] Weak algorithms. The algorithm used to encrypt the Key field
1167 within the EAPOL-Key descriptor is similar to the algorithm used
1168 in WEP, and as a result, shares some of the same weaknesses. As
1169 with WEP, the RC4 stream cipher is used to encrypt the key. As
1170 input to the RC4 engine, the IV and key are concatenated rather
1171 than being combined within a mixing function. As with WEP, the
1172 IV is not a counter, and therefore there is little protection
1178 Congdon, et al. Informational [Page 21]
1180 RFC 3580 IEEE 802.1X RADIUS September 2003
1183 As a result of these vulnerabilities, implementors intending to use
1184 the EAPOL-Key descriptor described in this document are urged to
1185 consult the 802.11 enhanced security specification for a more secure
1186 alternative. It is also advisable to consult the evolving literature
1187 on WEP vulnerabilities, in order to better understand the risks, as
1188 well as to obtain guidance on setting an appropriate re-keying
1191 6. IANA Considerations
1193 This specification does not create any RADIUS attributes nor any new
1194 number spaces for IANA administration. However, it does require
1195 assignment of new values to existing RADIUS attributes. These
1198 Attribute Values Required
1199 ========= ===============
1200 NAS-Port-Type Token-Ring (20), FDDI (21)
1201 Tunnel-Type VLAN (13)
1202 Acct-Terminate-Cause Supplicant Restart (19)
1203 Reauthentication Failure (20)
1204 Port Reinitialized (21)
1205 Port Administratively Disabled (22)
1209 7.1. Normative References
1211 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC
1214 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1215 Requirement Levels", BCP 14, RFC 2119, March 1997.
1217 [RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible
1218 Authentication Protocol (EAP)", RFC 2284, March 1998.
1220 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson,
1221 "Remote Authentication Dial In User Service (RADIUS)",
1222 RFC 2865, June 2000.
1224 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
1226 [RFC2867] Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting
1227 Modifications for Tunnel Protocol Support", RFC 2867,
1234 Congdon, et al. Informational [Page 22]
1236 RFC 3580 IEEE 802.1X RADIUS September 2003
1239 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J.,
1240 Holdrege, M. and I. Goyret, "RADIUS Attributes for
1241 Tunnel Protocol Support", RFC 2868, June 2000.
1243 [RFC2869] Rigney, C., Willats, W. and P. Calhoun, "RADIUS
1244 Extensions", RFC 2869, June 2000.
1246 [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6",
1247 RFC 3162, August 2001.
1249 [RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
1250 X.509 Public Key Infrastructure Certificate and
1251 Certificate Revocation List (CRL) Profile", RFC 3280,
1254 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B.
1255 Aboba, "Dynamic Authorization Extensions to Remote
1256 Authentication Dial In User Service (RADIUS)", RFC
1259 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote
1260 Authentication Dial In User Service) Support For
1261 Extensible Authentication Protocol (EAP)", RFC 3579,
1264 [IEEE8021X] IEEE Standards for Local and Metropolitan Area
1265 Networks: Port based Network Access Control, IEEE Std
1266 802.1X-2001, June 2001.
1268 7.2. Informative References
1270 [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:
1271 Keyed-Hashing for Message Authentication", RFC 2104,
1274 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
1275 an IANA Considerations Section in RFCs", BCP 26, RFC
1278 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS
1279 Attributes", RFC 2548, March 1999.
1281 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and
1282 Policy Implementation in Roaming", RFC 2607, June
1285 [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication
1286 Protocol", RFC 2716, October 1999.
1290 Congdon, et al. Informational [Page 23]
1292 RFC 3580 IEEE 802.1X RADIUS September 2003
1295 [MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent
1296 Attack." CryptoBytes Vol.2 No.2, Summer 1996.
1298 [IEEE802] IEEE Standards for Local and Metropolitan Area
1299 Networks: Overview and Architecture, ANSI/IEEE Std
1302 [IEEE8021Q] IEEE Standards for Local and Metropolitan Area
1303 Networks: Draft Standard for Virtual Bridged Local
1304 Area Networks, P802.1Q, January 1998.
1306 [IEEE8023] ISO/IEC 8802-3 Information technology -
1307 Telecommunications and information exchange between
1308 systems - Local and metropolitan area networks -
1309 Common specifications - Part 3: Carrier Sense
1310 Multiple Access with Collision Detection (CSMA/CD)
1311 Access Method and Physical Layer Specifications, (also
1312 ANSI/IEEE Std 802.3- 1996), 1996.
1314 [IEEE80211] Information technology - Telecommunications and
1315 information exchange between systems - Local and
1316 metropolitan area networks - Specific Requirements
1317 Part 11: Wireless LAN Medium Access Control (MAC) and
1318 Physical Layer (PHY) Specifications, IEEE Std.
1321 [Berkeley] Borisov, N., Goldberg, I. and D. Wagner, "Intercepting
1322 Mobile Communications: The Insecurity of 802.11", ACM
1323 SIGMOBILE, Seventh Annual International Conference on
1324 Mobile Computing and Networking, July 2001, Rome,
1327 [Arbaugh] Arbaugh, W., Shankar, N. and J.Y.C. Wan, "Your 802.11
1328 Wireless Network has No Clothes", Department of
1329 Computer Science, University of Maryland, College
1332 [Fluhrer] Fluhrer, S., Mantin, I. and A. Shamir, "Weaknesses in
1333 the Key Scheduling Algorithm of RC4", Eighth Annual
1334 Workshop on Selected Areas in Cryptography, Toronto,
1335 Canada, August 2001.
1337 [Stubbl] Stubblefield, A., Ioannidis, J. and A. Rubin, "Using
1338 the Fluhrer, Mantin and Shamir Attack to Break WEP",
1339 2002 NDSS Conference.
1346 Congdon, et al. Informational [Page 24]
1348 RFC 3580 IEEE 802.1X RADIUS September 2003
1351 8. Table of Attributes
1353 The following table provides a guide to which attributes MAY be sent
1354 and received as part of IEEE 802.1X authentication. L3 denotes
1355 attributes that require layer 3 capabilities, and thus may not be
1356 supported by all Authenticators. For each attribute, the reference
1357 provides the definitive information on usage.
1360 X 1 User-Name [RFC2865]
1361 2 User-Password [RFC2865]
1362 3 CHAP-Password [RFC2865]
1363 X 4 NAS-IP-Address [RFC2865]
1364 X 5 NAS-Port [RFC2865]
1365 X 6 Service-Type [RFC2865]
1366 7 Framed-Protocol [RFC2865]
1367 L3 8 Framed-IP-Address [RFC2865]
1368 L3 9 Framed-IP-Netmask [RFC2865]
1369 L3 10 Framed-Routing [RFC2865]
1370 X 11 Filter-Id [RFC2865]
1371 X 12 Framed-MTU [RFC2865]
1372 13 Framed-Compression [RFC2865]
1373 L3 14 Login-IP-Host [RFC2865]
1374 L3 15 Login-Service [RFC2865]
1375 L3 16 Login-TCP-Port [RFC2865]
1376 18 Reply-Message [RFC2865]
1377 19 Callback-Number [RFC2865]
1378 20 Callback-Id [RFC2865]
1379 L3 22 Framed-Route [RFC2865]
1380 L3 23 Framed-IPX-Network [RFC2865]
1381 X 24 State [RFC2865]
1382 X 25 Class [RFC2865]
1383 X 26 Vendor-Specific [RFC2865]
1384 X 27 Session-Timeout [RFC2865]
1385 X 28 Idle-Timeout [RFC2865]
1386 X 29 Termination-Action [RFC2865]
1387 X 30 Called-Station-Id [RFC2865]
1388 X 31 Calling-Station-Id [RFC2865]
1389 X 32 NAS-Identifier [RFC2865]
1390 X 33 Proxy-State [RFC2865]
1391 34 Login-LAT-Service [RFC2865]
1392 35 Login-LAT-Node [RFC2865]
1393 36 Login-LAT-Group [RFC2865]
1402 Congdon, et al. Informational [Page 25]
1404 RFC 3580 IEEE 802.1X RADIUS September 2003
1408 L3 37 Framed-AppleTalk-Link [RFC2865]
1409 L3 38 Framed-AppleTalk-Network [RFC2865]
1410 L3 39 Framed-AppleTalk-Zone [RFC2865]
1411 X 40 Acct-Status-Type [RFC2866]
1412 X 41 Acct-Delay-Time [RFC2866]
1413 X 42 Acct-Input-Octets [RFC2866]
1414 X 43 Acct-Output-Octets [RFC2866]
1415 X 44 Acct-Session-Id [RFC2866]
1416 X 45 Acct-Authentic [RFC2866]
1417 X 46 Acct-Session-Time [RFC2866]
1418 X 47 Acct-Input-Packets [RFC2866]
1419 X 48 Acct-Output-Packets [RFC2866]
1420 X 49 Acct-Terminate-Cause [RFC2866]
1421 X 50 Acct-Multi-Session-Id [RFC2866]
1422 X 51 Acct-Link-Count [RFC2866]
1423 X 52 Acct-Input-Gigawords [RFC2869]
1424 X 53 Acct-Output-Gigawords [RFC2869]
1425 X 55 Event-Timestamp [RFC2869]
1426 60 CHAP-Challenge [RFC2865]
1427 X 61 NAS-Port-Type [RFC2865]
1428 62 Port-Limit [RFC2865]
1429 63 Login-LAT-Port [RFC2865]
1430 X 64 Tunnel-Type [RFC2868]
1431 X 65 Tunnel-Medium-Type [RFC2868]
1432 L3 66 Tunnel-Client-Endpoint [RFC2868]
1433 L3 67 Tunnel-Server-Endpoint [RFC2868]
1434 L3 68 Acct-Tunnel-Connection [RFC2867]
1435 L3 69 Tunnel-Password [RFC2868]
1436 70 ARAP-Password [RFC2869]
1437 71 ARAP-Features [RFC2869]
1438 72 ARAP-Zone-Access [RFC2869]
1439 73 ARAP-Security [RFC2869]
1440 74 ARAP-Security-Data [RFC2869]
1441 75 Password-Retry [RFC2869]
1443 X 77 Connect-Info [RFC2869]
1444 X 78 Configuration-Token [RFC2869]
1445 X 79 EAP-Message [RFC3579]
1446 X 80 Message-Authenticator [RFC3579]
1447 X 81 Tunnel-Private-Group-ID [RFC2868]
1448 L3 82 Tunnel-Assignment-ID [RFC2868]
1449 X 83 Tunnel-Preference [RFC2868]
1450 84 ARAP-Challenge-Response [RFC2869]
1458 Congdon, et al. Informational [Page 26]
1460 RFC 3580 IEEE 802.1X RADIUS September 2003
1464 X 85 Acct-Interim-Interval [RFC2869]
1465 X 86 Acct-Tunnel-Packets-Lost [RFC2867]
1466 X 87 NAS-Port-Id [RFC2869]
1467 L3 88 Framed-Pool [RFC2869]
1468 L3 90 Tunnel-Client-Auth-ID [RFC2868]
1469 L3 91 Tunnel-Server-Auth-ID [RFC2868]
1470 X 95 NAS-IPv6-Address [RFC3162]
1471 96 Framed-Interface-Id [RFC3162]
1472 L3 97 Framed-IPv6-Prefix [RFC3162]
1473 L3 98 Login-IPv6-Host [RFC3162]
1474 L3 99 Framed-IPv6-Route [RFC3162]
1475 L3 100 Framed-IPv6-Pool [RFC3162]
1476 X 101 Error-Cause [RFC3576]
1481 X = May be used with IEEE 802.1X authentication
1482 L3 = Implemented only by Authenticators with Layer 3
1514 Congdon, et al. Informational [Page 27]
1516 RFC 3580 IEEE 802.1X RADIUS September 2003
1519 9. Intellectual Property Statement
1521 The IETF takes no position regarding the validity or scope of any
1522 intellectual property or other rights that might be claimed to
1523 pertain to the implementation or use of the technology described in
1524 this document or the extent to which any license under such rights
1525 might or might not be available; neither does it represent that it
1526 has made any effort to identify any such rights. Information on the
1527 IETF's procedures with respect to rights in standards-track and
1528 standards- related documentation can be found in BCP-11. Copies of
1529 claims of rights made available for publication and any assurances of
1530 licenses to be made available, or the result of an attempt made to
1531 obtain a general license or permission for the use of such
1532 proprietary rights by implementors or users of this specification can
1533 be obtained from the IETF Secretariat.
1535 The IETF invites any interested party to bring to its attention any
1536 copyrights, patents or patent applications, or other proprietary
1537 rights which may cover technology that may be required to practice
1538 this standard. Please address the information to the IETF Executive
1543 The authors would like to acknowledge Bob O'Hara of Airespace, David
1544 Halasz of Cisco, Tim Moore, Sachin Seth and Ashwin Palekar of
1545 Microsoft, Andrea Li, Albert Young and Dave Bagby of 3Com for
1546 contributions to this document.
1570 Congdon, et al. Informational [Page 28]
1572 RFC 3580 IEEE 802.1X RADIUS September 2003
1575 11. Authors' Addresses
1578 Hewlett Packard Company
1579 HP ProCurve Networking
1580 8000 Foothills Blvd, M/S 5662
1583 Phone: +1 916 785 5753
1584 Fax: +1 916 785 8478
1585 EMail: paul_congdon@hp.com
1588 Microsoft Corporation
1592 Phone: +1 425 706 6605
1593 Fax: +1 425 936 7329
1594 EMail: bernarda@microsoft.com
1598 5753 W. Las Positas Blvd.
1599 Pleasanton, CA 94588-4084
1601 Fax: +1 415 345 1827
1602 EMail: ah_smith@acm.org
1607 Phone: +1 603 337 1506
1608 EMail: jjr@enterasys.com
1612 500 108th Avenue N.E., Suite 500
1615 Phone: +1 425 438 8218
1616 Fax: +1 425 438 1848
1617 EMail: gwz@cisco.com
1626 Congdon, et al. Informational [Page 29]
1628 RFC 3580 IEEE 802.1X RADIUS September 2003
1631 12. Full Copyright Statement
1633 Copyright (C) The Internet Society (2003). All Rights Reserved.
1635 This document and translations of it may be copied and furnished to
1636 others, and derivative works that comment on or otherwise explain it
1637 or assist in its implementation may be prepared, copied, published
1638 and distributed, in whole or in part, without restriction of any
1639 kind, provided that the above copyright notice and this paragraph are
1640 included on all such copies and derivative works. However, this
1641 document itself may not be modified in any way, such as by removing
1642 the copyright notice or references to the Internet Society or other
1643 Internet organizations, except as needed for the purpose of
1644 developing Internet standards in which case the procedures for
1645 copyrights defined in the Internet Standards process must be
1646 followed, or as required to translate it into languages other than
1649 The limited permissions granted above are perpetual and will not be
1650 revoked by the Internet Society or its successors or assignees.
1652 This document and the information contained herein is provided on an
1653 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1654 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1655 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1656 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1657 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1661 Funding for the RFC Editor function is currently provided by the
1682 Congdon, et al. Informational [Page 30]