doc/rfc/rfc3580.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                         P. Congdon
   8 Request for Comments: 3580                       Hewlett Packard Company
   9 Category: Informational                                         B. Aboba
  10                                                                Microsoft
  11                                                                 A. Smith
  12                                                         Trapeze Networks
  13                                                                  G. Zorn
  14                                                            Cisco Systems
  15                                                                 J. Roese
  16                                                                Enterasys
  17                                                           September 2003
  18
  19
  20     IEEE 802.1X Remote Authentication Dial In User Service (RADIUS)
  21                             Usage Guidelines
  22
  23 Status of this Memo
  24
  25    This memo provides information for the Internet community.  It does
  26    not specify an Internet standard of any kind.  Distribution of this
  27    memo is unlimited.
  28
  29 Copyright Notice
  30
  31    Copyright (C) The Internet Society (2003).  All Rights Reserved.
  32
  33 Abstract
  34
  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.
  40
  41
  42
  43
  44
  45
  46
  47
  48
  49
  50
  51
  52
  53
  54
  55
  56
  57
  58 Congdon, et al.              Informational                      [Page 1]
  59 \f
  60 RFC 3580                   IEEE 802.1X RADIUS             September 2003
  61
  62
  63 Table of Contents
  64
  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
 111
 112
 113
 114 Congdon, et al.              Informational                      [Page 2]
 115 \f
 116 RFC 3580                   IEEE 802.1X RADIUS             September 2003
 117
 118
 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
 130
 131 1.  Introduction
 132
 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.
 138
 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.
 142
 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.
 146
 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.
 152
 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
 157    specification.
 158
 159 1.1.  Terminology
 160
 161    This document uses the following terms:
 162
 163    Access Point (AP)
 164          A Station that provides access to the distribution services via
 165          the wireless medium for associated Stations.
 166
 167
 168
 169
 170 Congdon, et al.              Informational                      [Page 3]
 171 \f
 172 RFC 3580                   IEEE 802.1X RADIUS             September 2003
 173
 174
 175    Association
 176          The service used to establish Access Point/Station mapping and
 177          enable Station invocation of the distribution system services.
 178
 179    Authenticator
 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.
 184
 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.
 190
 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
 195          both.
 196
 197    Station (STA)
 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).
 201
 202    Supplicant
 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.
 207
 208 1.2.  Requirements Language
 209
 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].
 215
 216
 217
 218
 219
 220
 221
 222
 223
 224
 225
 226 Congdon, et al.              Informational                      [Page 4]
 227 \f
 228 RFC 3580                   IEEE 802.1X RADIUS             September 2003
 229
 230
 231 2.  RADIUS Accounting Attributes
 232
 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.
 237
 238    Attributes requiring more discussion include:
 239
 240       Acct-Terminate-Cause
 241       Acct-Multi-Session-Id
 242       Acct-Link-Count
 243
 244 2.1.  Acct-Terminate-Cause
 245
 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
 249    the next page.
 250
 251    IEEE 802.1X                       RADIUS
 252    dot1xAuthSessionTerminateCause    Acct-Terminate-Cause
 253    Value                             Value
 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
 263
 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
 268    Supplicant Logoff.
 269
 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.
 276
 277    A Supplicant Restart (19) termination cause indicates
 278    re-initialization of the Supplicant state machines.
 279
 280
 281
 282 Congdon, et al.              Informational                      [Page 5]
 283 \f
 284 RFC 3580                   IEEE 802.1X RADIUS             September 2003
 285
 286
 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.
 291
 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
 297    example:
 298
 299    a. The session is terminated due to re-authentication failure.  In
 300       this case the Reauthentication Failure (20) termination cause is
 301       used.
 302
 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
 307       separate session.
 308
 309    Where IEEE 802.1X authentication occurs prior to association,
 310    accounting packets are not sent until an association occurs.
 311
 312    An Admin Reset (6) termination cause indicates that the Port has been
 313    administratively forced into the unauthorized state.
 314
 315    A Port Reinitialized (21) termination cause indicates that the Port's
 316    MAC has been reinitialized.
 317
 318    A Port Administratively Disabled (22) termination cause indicates
 319    that the Port has been administratively disabled.
 320
 321 2.2.  Acct-Multi-Session-Id
 322
 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.
 328
 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,
 334
 335
 336
 337
 338 Congdon, et al.              Informational                      [Page 6]
 339 \f
 340 RFC 3580                   IEEE 802.1X RADIUS             September 2003
 341
 342
 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).
 346
 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.
 352
 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:
 357
 358    Original AP MAC Address | Supplicant MAC Address | NTP Timestamp
 359
 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
 366    scheme.
 367
 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.
 373
 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"
 378
 379 2.3.  Acct-Link-Count
 380
 381    The Acct-Link-Count attribute may be used to account for the number
 382    of ports that have been aggregated.
 383
 384 3.  RADIUS Authentication
 385
 386    This section describes how attributes defined in [RFC2865],
 387    [RFC2867], [RFC2868], [RFC2869], [RFC3162] and [RFC3579] are used in
 388    IEEE 802.1X authentication.
 389
 390
 391
 392
 393
 394 Congdon, et al.              Informational                      [Page 7]
 395 \f
 396 RFC 3580                   IEEE 802.1X RADIUS             September 2003
 397
 398
 399 3.1.  User-Name
 400
 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].
 406
 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.
 410
 411 3.2.  User-Password, CHAP-Password, CHAP-Challenge
 412
 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.
 416
 417 3.3.  NAS-IP-Address, NAS-IPv6-Address
 418
 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.
 425
 426 3.4.  NAS-Port
 427
 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.
 437
 438 3.5.  Service-Type
 439
 440    For use with IEEE 802.1X, the Framed (2), Authenticate Only (8), and
 441    Call Check (10) values are most commonly used.
 442
 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
 447
 448
 449
 450 Congdon, et al.              Informational                      [Page 8]
 451 \f
 452 RFC 3580                   IEEE 802.1X RADIUS             September 2003
 453
 454
 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.
 462
 463 3.6.  Framed-Protocol
 464
 465    Since there is no value for IEEE 802 media, the Framed-Protocol
 466    attribute is not used by IEEE 802.1X Authenticators.
 467
 468 3.7.  Framed-IP-Address, Framed-IP-Netmask
 469
 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
 474    layer 3 devices.
 475
 476 3.8.  Framed-Routing
 477
 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.
 482
 483 3.9.  Filter-ID
 484
 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.
 490
 491 3.10.  Framed-MTU
 492
 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:
 503
 504
 505
 506 Congdon, et al.              Informational                      [Page 9]
 507 \f
 508 RFC 3580                   IEEE 802.1X RADIUS             September 2003
 509
 510
 511                                         Maximum Frame
 512    Media             Framed-MTU            Length
 513    =========        ===============     ==============
 514    Ethernet              1500              1522
 515    802.3                 1500              1522
 516    802.4                 8174              8193
 517    802.5 (4 Mbps)        4528              4550
 518    802.5 (16 Mbps)      18173             18200
 519    802.5 (100 Mb/s)     18173             18200
 520    802.6                 9191              9240
 521    802.9a                1500              1518
 522    802.11                2304              2346
 523    802.12 (Ethernet)     1500              1518
 524    802.12 (Token Ring)   4502              4528
 525    FDDI                  4479              4500
 526
 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
 532    octets.
 533
 534 3.11.  Framed-Compression
 535
 536    [IEEE8021X] does not include compression support.  Therefore this
 537    attribute is not understood by [IEEE8021X] Authenticators.
 538
 539 3.12.  Displayable Messages
 540
 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).
 548
 549 3.13.  Callback-Number, Callback-ID
 550
 551    These attributes are not understood by IEEE 802.1X Authenticators.
 552
 553
 554
 555
 556
 557
 558
 559
 560
 561
 562 Congdon, et al.              Informational                     [Page 10]
 563 \f
 564 RFC 3580                   IEEE 802.1X RADIUS             September 2003
 565
 566
 567 3.14.  Framed-Route, Framed-IPv6-Route
 568
 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
 573    Point.
 574
 575 3.15.  State, Class, Proxy-State
 576
 577    These attributes are used for the same purposes as described in
 578    [RFC2865].
 579
 580 3.16.  Vendor-Specific
 581
 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.
 590
 591 3.17.  Session-Timeout
 592
 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.
 597
 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
 607    completed.
 608
 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.
 614
 615
 616
 617
 618 Congdon, et al.              Informational                     [Page 11]
 619 \f
 620 RFC 3580                   IEEE 802.1X RADIUS             September 2003
 621
 622
 623 3.18.  Idle-Timeout
 624
 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
 631    remain idle.
 632
 633 3.19.  Termination-Action
 634
 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.
 639
 640 3.20.  Called-Station-Id
 641
 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".
 648
 649 3.21.  Calling-Station-Id
 650
 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".
 654
 655 3.22.  NAS-Identifier
 656
 657    This attribute contains a string identifying the IEEE 802.1X
 658    Authenticator originating the Access-Request.
 659
 660 3.23.  NAS-Port-Type
 661
 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
 664    used.
 665
 666
 667
 668
 669
 670
 671
 672
 673
 674 Congdon, et al.              Informational                     [Page 12]
 675 \f
 676 RFC 3580                   IEEE 802.1X RADIUS             September 2003
 677
 678
 679 3.24.  Port-Limit
 680
 681    This attribute has no meaning when sent to an [IEEE8021X]
 682    Authenticator.
 683
 684 3.25.  Password-Retry
 685
 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.
 689
 690 3.26.  Connect-Info
 691
 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.
 702
 703 3.27.  EAP-Message
 704
 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.
 711
 712 3.28.  Message-Authenticator
 713
 714    As noted in [RFC3579] Section 3.1., the Message-Authenticator
 715    attribute MUST be used to protect packets within a RADIUS/EAP
 716    conversation.
 717
 718 3.29.  NAS-Port-Id
 719
 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.
 724
 725
 726
 727
 728
 729
 730 Congdon, et al.              Informational                     [Page 13]
 731 \f
 732 RFC 3580                   IEEE 802.1X RADIUS             September 2003
 733
 734
 735 3.30.  Framed-Pool, Framed-IPv6-Pool
 736
 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
 741    devices.
 742
 743 3.31.  Tunnel Attributes
 744
 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.
 750
 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
 755    campus network.
 756
 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-
 761    Request.
 762
 763    For use in VLAN assignment, the following tunnel attributes are used:
 764
 765    Tunnel-Type=VLAN (13)
 766    Tunnel-Medium-Type=802
 767    Tunnel-Private-Group-ID=VLANID
 768
 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.
 773
 774    When Tunnel attributes are sent, it is necessary to fill in the Tag
 775    field.  As noted in [RFC2868], section 3.1:
 776
 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).
 781
 782
 783
 784
 785
 786 Congdon, et al.              Informational                     [Page 14]
 787 \f
 788 RFC 3580                   IEEE 802.1X RADIUS             September 2003
 789
 790
 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
 796    field.
 797
 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.
 805
 806 4.  RC4 EAPOL-Key Frame
 807
 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.
 814
 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
 820    authentication.
 821
 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].
 827
 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].
 833
 834
 835
 836
 837
 838
 839
 840
 841
 842 Congdon, et al.              Informational                     [Page 15]
 843 \f
 844 RFC 3580                   IEEE 802.1X RADIUS             September 2003
 845
 846
 847    While the RC4 EAPOL-Key frame is defined in [IEEE8021X], a more
 848    complete description is provided on the next page.
 849
 850     0                   1                   2                   3
 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    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 857    |                             Replay Counter...
 858    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 859    |                             Replay Counter    |   Key IV...
 860    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 861    |                             Key IV...
 862    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 863    |                             Key IV...
 864    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 865    |                             Key IV...
 866    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 867    |                             Key IV...         |F| Key Index   |
 868    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 869    |                             Key Signature...
 870    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 871    |                             Key Signature...
 872    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 873    |                             Key Signature...
 874    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 875    |                             Key Signature...
 876    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 877    |                             Key...
 878    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 879
 880    Version
 881       The Version field is one octet.  For IEEE 802.1X, it contains the
 882       value 0x01.
 883
 884    Packet Type
 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.
 888
 889    Packet Body Length
 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.
 893
 894
 895
 896
 897
 898 Congdon, et al.              Informational                     [Page 16]
 899 \f
 900 RFC 3580                   IEEE 802.1X RADIUS             September 2003
 901
 902
 903    Type
 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).
 907
 908    Key Length
 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.
 922
 923    Replay Counter
 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.
 928
 929    Key IV
 930       The Key IV field is 16 octets and includes a 128-bit
 931       cryptographically random number.
 932
 933    F
 934       The Key flag (F) is a single bit, describing the type of key that
 935       is included in the Key field.  Values are:
 936
 937       0 = for broadcast (default key)
 938       1 = for unicast (key mapping key)
 939
 940    Key Index
 941       The Key Index is 7 bits.
 942
 943    Key Signature
 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.
 950
 951
 952
 953
 954 Congdon, et al.              Informational                     [Page 17]
 955 \f
 956 RFC 3580                   IEEE 802.1X RADIUS             September 2003
 957
 958
 959    Key
 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).
 969
 970 5.  Security Considerations
 971
 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].
 977
 978    Vulnerabilities include:
 979
 980       Packet modification or forgery
 981       Dictionary attacks
 982       Known plaintext attacks
 983       Replay
 984       Outcome mismatches
 985       802.11 integration
 986       Key management issues
 987
 988 5.1.  Packet Modification or Forgery
 989
 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.:
 993
 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.
 997
 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.:
1001
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
1007
1008
1009
1010 Congdon, et al.              Informational                     [Page 18]
1011 \f
1012 RFC 3580                   IEEE 802.1X RADIUS             September 2003
1013
1014
1015       support SHOULD be used to provide per-packet confidentiality,
1016       authentication, integrity and replay protection.  IKE SHOULD be
1017       used for key management.
1018
1019 5.2.  Dictionary Attacks
1020
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
1025    recommends:
1026
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
1030       octets.
1031
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],
1035    Section 4.2.
1036
1037 5.3.  Known Plaintext Attacks
1038
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.
1049
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).
1058
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.
1063
1064
1065
1066 Congdon, et al.              Informational                     [Page 19]
1067 \f
1068 RFC 3580                   IEEE 802.1X RADIUS             September 2003
1069
1070
1071 5.4.  Replay
1072
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],
1077    Section 4.2.
1078
1079    As with the Request Authenticator, for use with IEEE 802.1X
1080    Authenticators, the Acct-Session-Id SHOULD be globally and temporally
1081    unique.
1082
1083 5.5.  Outcome Mismatches
1084
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.
1091
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.
1098
1099 5.6.  802.11 Integration
1100
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.
1105
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
1113    [RFC2716].
1114
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
1119
1120
1121
1122 Congdon, et al.              Informational                     [Page 20]
1123 \f
1124 RFC 3580                   IEEE 802.1X RADIUS             September 2003
1125
1126
1127    enhanced security specification will define its own IEEE 802.11 key
1128    hierarchy as well as new EAPOL-Key descriptors.
1129
1130 5.7.  Key Management Issues
1131
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:
1135
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.
1147
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].
1158
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.
1165
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
1173         against reuse.
1174
1175
1176
1177
1178 Congdon, et al.              Informational                     [Page 21]
1179 \f
1180 RFC 3580                   IEEE 802.1X RADIUS             September 2003
1181
1182
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
1189    interval.
1190
1191 6.  IANA Considerations
1192
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
1196    include:
1197
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)
1206
1207 7.  References
1208
1209 7.1.  Normative References
1210
1211    [RFC1321]      Rivest, R., "The MD5 Message-Digest Algorithm", RFC
1212                   1321, April 1992.
1213
1214    [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
1215                   Requirement Levels", BCP 14, RFC 2119, March 1997.
1216
1217    [RFC2284]      Blunk, L. and J. Vollbrecht, "PPP Extensible
1218                   Authentication Protocol (EAP)", RFC 2284, March 1998.
1219
1220    [RFC2865]      Rigney, C., Willens, S., Rubens, A. and W. Simpson,
1221                   "Remote Authentication Dial In User Service (RADIUS)",
1222                   RFC 2865, June 2000.
1223
1224    [RFC2866]      Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
1225
1226    [RFC2867]      Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting
1227                   Modifications for Tunnel Protocol Support", RFC 2867,
1228                   June 2000.
1229
1230
1231
1232
1233
1234 Congdon, et al.              Informational                     [Page 22]
1235 \f
1236 RFC 3580                   IEEE 802.1X RADIUS             September 2003
1237
1238
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.
1242
1243    [RFC2869]      Rigney, C., Willats, W. and P. Calhoun, "RADIUS
1244                   Extensions", RFC 2869, June 2000.
1245
1246    [RFC3162]      Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6",
1247                   RFC 3162, August 2001.
1248
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,
1252                   April 2002.
1253
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
1257                   3576, July 2003.
1258
1259    [RFC3579]      Aboba, B. and P. Calhoun, "RADIUS (Remote
1260                   Authentication Dial In User Service) Support For
1261                   Extensible Authentication Protocol (EAP)", RFC 3579,
1262                   September 2003.
1263
1264    [IEEE8021X]    IEEE Standards for Local and Metropolitan Area
1265                   Networks:  Port based Network Access Control, IEEE Std
1266                   802.1X-2001, June 2001.
1267
1268 7.2.  Informative References
1269
1270    [RFC2104]      Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:
1271                   Keyed-Hashing for Message Authentication", RFC 2104,
1272                   February 1997.
1273
1274    [RFC2434]      Narten, T. and H. Alvestrand, "Guidelines for Writing
1275                   an IANA Considerations Section in RFCs", BCP 26, RFC
1276                   2434, October 1998.
1277
1278    [RFC2548]      Zorn, G., "Microsoft Vendor-specific RADIUS
1279                   Attributes", RFC 2548, March 1999.
1280
1281    [RFC2607]      Aboba, B. and J. Vollbrecht, "Proxy Chaining and
1282                   Policy Implementation in Roaming", RFC 2607, June
1283                   1999.
1284
1285    [RFC2716]      Aboba, B. and D. Simon, "PPP EAP TLS Authentication
1286                   Protocol", RFC 2716, October 1999.
1287
1288
1289
1290 Congdon, et al.              Informational                     [Page 23]
1291 \f
1292 RFC 3580                   IEEE 802.1X RADIUS             September 2003
1293
1294
1295    [MD5Attack]    Dobbertin, H., "The Status of MD5 After a Recent
1296                   Attack."  CryptoBytes Vol.2 No.2, Summer 1996.
1297
1298    [IEEE802]      IEEE Standards for Local and Metropolitan Area
1299                   Networks:  Overview and Architecture, ANSI/IEEE Std
1300                   802, 1990.
1301
1302    [IEEE8021Q]    IEEE Standards for Local and Metropolitan Area
1303                   Networks:  Draft Standard for Virtual Bridged Local
1304                   Area Networks, P802.1Q, January 1998.
1305
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.
1313
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.
1319                   802.11-1999, 1999.
1320
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,
1325                   Italy.
1326
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
1330                   Park, March 2001.
1331
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.
1336
1337    [Stubbl]       Stubblefield, A., Ioannidis, J. and A. Rubin, "Using
1338                   the Fluhrer, Mantin and Shamir Attack to Break WEP",
1339                   2002 NDSS Conference.
1340
1341
1342
1343
1344
1345
1346 Congdon, et al.              Informational                     [Page 24]
1347 \f
1348 RFC 3580                   IEEE 802.1X RADIUS             September 2003
1349
1350
1351 8.  Table of Attributes
1352
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.
1358
1359    802.1X        #   Attribute
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]
1394    802.1X        #   Attribute
1395
1396
1397
1398
1399
1400
1401
1402 Congdon, et al.              Informational                     [Page 25]
1403 \f
1404 RFC 3580                   IEEE 802.1X RADIUS             September 2003
1405
1406
1407    802.1X        #   Attribute
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]
1442                 76   Prompt [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]
1451    802.1X        #   Attribute
1452
1453
1454
1455
1456
1457
1458 Congdon, et al.              Informational                     [Page 26]
1459 \f
1460 RFC 3580                   IEEE 802.1X RADIUS             September 2003
1461
1462
1463    802.1X        #   Attribute
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]
1477    802.1X        #   Attribute
1478
1479    Key
1480    ===
1481    X         = May be used with IEEE 802.1X authentication
1482    L3        = Implemented only by Authenticators with Layer 3
1483                capabilities
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514 Congdon, et al.              Informational                     [Page 27]
1515 \f
1516 RFC 3580                   IEEE 802.1X RADIUS             September 2003
1517
1518
1519 9.  Intellectual Property Statement
1520
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.
1534
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
1539    Director.
1540
1541 10.  Acknowledgments
1542
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.
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570 Congdon, et al.              Informational                     [Page 28]
1571 \f
1572 RFC 3580                   IEEE 802.1X RADIUS             September 2003
1573
1574
1575 11.  Authors' Addresses
1576
1577    Paul Congdon
1578    Hewlett Packard Company
1579    HP ProCurve Networking
1580    8000 Foothills Blvd, M/S 5662
1581    Roseville, CA  95747
1582
1583    Phone: +1 916 785 5753
1584    Fax:   +1 916 785 8478
1585    EMail: paul_congdon@hp.com
1586
1587    Bernard Aboba
1588    Microsoft Corporation
1589    One Microsoft Way
1590    Redmond, WA 98052
1591
1592    Phone: +1 425 706 6605
1593    Fax:   +1 425 936 7329
1594    EMail: bernarda@microsoft.com
1595
1596    Andrew Smith
1597    Trapeze Networks
1598    5753 W. Las Positas Blvd.
1599    Pleasanton, CA 94588-4084
1600
1601    Fax: +1 415 345 1827
1602    EMail: ah_smith@acm.org
1603
1604    John Roese
1605    Enterasys
1606
1607    Phone: +1 603 337 1506
1608    EMail: jjr@enterasys.com
1609
1610    Glen Zorn
1611    Cisco Systems, Inc.
1612    500 108th Avenue N.E., Suite 500
1613    Bellevue, WA 98004
1614
1615    Phone: +1 425 438 8218
1616    Fax:   +1 425 438 1848
1617    EMail: gwz@cisco.com
1618
1619
1620
1621
1622
1623
1624
1625
1626 Congdon, et al.              Informational                     [Page 29]
1627 \f
1628 RFC 3580                   IEEE 802.1X RADIUS             September 2003
1629
1630
1631 12.  Full Copyright Statement
1632
1633    Copyright (C) The Internet Society (2003).  All Rights Reserved.
1634
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
1647    English.
1648
1649    The limited permissions granted above are perpetual and will not be
1650    revoked by the Internet Society or its successors or assignees.
1651
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.
1658
1659 Acknowledgement
1660
1661    Funding for the RFC Editor function is currently provided by the
1662    Internet Society.
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682 Congdon, et al.              Informational                     [Page 30]
1683 \f