rfc3580.txt

radius服务器

      The Message-Authenticator attribute MUST be used to protect all
      Access-Request, Access-Challenge, Access-Accept, and Access-Reject
      packets containing an EAP-Message attribute.

   As a result, when used with IEEE 802.1X, all RADIUS packets MUST be
   authenticated and integrity protected.  In addition, as described in
   [3579], Section 4.2.:

      To address the security vulnerabilities of RADIUS/EAP,
      implementations of this specification SHOULD support IPsec
      [RFC2401] along with IKE [RFC2409] for key management.  IPsec ESP
      [RFC2406] with non-null transform SHOULD be supported, and IPsec
      ESP with a non-null encryption transform and authentication



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


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

5.2.  Dictionary Attacks

   As discussed in [RFC3579] Section 4.3.3., the RADIUS shared secret is
   vulnerable to offline dictionary attack, based on capture of the
   Response Authenticator or Message-Authenticator attribute.  In order
   to decrease the level of vulnerability, [RFC2865], Section 3
   recommends:

      The secret (password shared between the client and the RADIUS
      server) SHOULD be at least as large and unguessable as a well-
      chosen password.  It is preferred that the secret be at least 16
      octets.

   In addition, the risk of an offline dictionary attack can be further
   mitigated by employing IPsec ESP with a non-null transform in order
   to encrypt the RADIUS conversation, as described in [RFC3579],
   Section 4.2.

5.3.  Known Plaintext Attacks

   Since IEEE 802.1X is based on EAP, which does not support PAP, the
   RADIUS User-Password attribute is not used to carry hidden user
   passwords.  The hiding mechanism utilizes MD5, defined in [RFC1321],
   in order to generate a key stream based on the RADIUS shared secret
   and the Request Authenticator.  Where PAP is in use, it is possible
   to collect key streams corresponding to a given Request Authenticator
   value, by capturing RADIUS conversations corresponding to a PAP
   authentication attempt using a known password.  Since the User-
   Password is known, the key stream corresponding to a given Request
   Authenticator can be determined and stored.

   The vulnerability is described in detail in [RFC3579], Section 4.3.4.
   Even though IEEE 802.1X Authenticators do not support PAP
   authentication, a security vulnerability can still exist where the
   same RADIUS shared secret is used for hiding User-Password as well as
   other attributes.  This can occur, for example, if the same RADIUS
   proxy handles authentication requests for both IEEE 802.1X (which may
   hide the Tunnel-Password, MS-MPPE-Send-Key and MS-MPPE-Recv-Key
   attributes) and GPRS (which may hide the User-Password attribute).

   The threat can be mitigated by protecting RADIUS with IPsec ESP with
   a non-null transform, as described in [RFC3579], Section 4.2.  In
   addition, the same RADIUS shared secret MUST NOT be used for both
   IEEE 802.1X authentication and PAP authentication.



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


5.4.  Replay

   As noted in [RFC3579] Section 4.3.5., the RADIUS protocol provides
   only limited support for replay protection.  Replay protection for
   RADIUS authentication and accounting can be provided by enabling
   IPsec replay protection with RADIUS, as described in [RFC3579],
   Section 4.2.

   As with the Request Authenticator, for use with IEEE 802.1X
   Authenticators, the Acct-Session-Id SHOULD be globally and temporally
   unique.

5.5.  Outcome Mismatches

   [RFC3579] Section 2.6.3. discusses the issues that arise when the EAP
   packet encapsulated in an EAP-Message attribute does not agree with
   the RADIUS Packet Type.  For example, an EAP Success packet might be
   encapsulated within an Access-Reject; an EAP Failure might be sent
   within an Access-Accept; or an EAP Success or Failure might be sent
   within an Access-Challenge.

   As described in [RFC3579] Section 2.6.3., these conflicting messages
   are likely to cause confusion.  To ensure that access decisions made
   by IEEE 802.1X Authenticators conform to the wishes of the RADIUS
   server, it is necessary for the Authenticator to make the decision
   solely based on the authentication result (Access-Accept/Reject) and
   not based on the contents of EAP-Message attributes, if present.

5.6.  802.11 Integration

   [IEEE8021X] was developed for use on wired IEEE 802 networks such as
   Ethernet, and therefore does not describe how to securely adapt IEEE
   802.1X for use with 802.11.  This is left to an enhanced security
   specification under development within IEEE 802.11.

   For example, [IEEE8021X] does not specify whether authentication
   occurs prior to, or after association, nor how the derived keys are
   used within various ciphersuites.  It also does not specify
   ciphersuites addressing the vulnerabilities discovered in WEP,
   described in [Berkeley], [Arbaugh], [Fluhrer], and [Stubbl].
   [IEEE8021X] only defines an authentication framework, leaving the
   definition of the authentication methods to other documents, such as
   [RFC2716].

   Since [IEEE8021X] does not address 802.11 integration issues,
   implementors are strongly advised to consult additional IEEE 802.11
   security specifications for guidance on how to adapt IEEE 802.1X for
   use with 802.11.  For example, it is likely that the IEEE 802.11



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


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

5.7.  Key Management Issues

   The EAPOL-Key descriptor described in Section 4. is likely to be
   deprecated in the future, when the IEEE 802.11 enhanced security
   group completes its work.  Known security issues include:

   [1]  Default key-only support.  IEEE 802.1X enables the derivation of
        per-Station unicast keys, known in [IEEE80211] as "key mapping
        keys."  Keys used to encrypt multicast/broadcast traffic are
        known as "default keys".  However, in some 802.11
        implementations, the unicast keys, derived as part of the EAP
        authentication process, are used solely in order to encrypt,
        authenticate and integrity protect the EAPOL-Key descriptor, as
        described in Section 4.  These implementations only support use
        of default keys (ordinarily only used with multicast/broadcast
        traffic) to secure all traffic, unicast or multicast/broadcast,
        resulting in inherent security weaknesses.

        Where per-Station key-mapping keys (e.g. unicast keys) are
        unsupported, any Station possessing the default key can decrypt
        traffic from other Stations or impersonate them.  When used
        along with a weak cipher (e.g. WEP), implementations supporting
        only default keys provide more material for attacks such as
        those described in [Fluhrer] and [Stubbl].  If in addition, the
        default key is not refreshed periodically, IEEE 802.1X dynamic
        key derivation provides little or no security benefit.  For an
        understanding of the issues with WEP, see [Berkeley], [Arbaugh],
        [Fluhrer], and [Stubbl].

   [2]  Reuse of keying material.  The EAPOL-Key descriptor specified in
        section 4 uses the same keying material (MS-MPPE-Recv-Key) both
        to encrypt the Key field within the EAPOL-Key descriptor, and to
        encrypt data passed between the Station and Access Point.
        Multi-purpose keying material is frowned upon, since multiple
        uses can leak information helpful to an attacker.

   [3]  Weak algorithms.  The algorithm used to encrypt the Key field
        within the EAPOL-Key descriptor is similar to the algorithm used
        in WEP, and as a result, shares some of the same weaknesses.  As
        with WEP, the RC4 stream cipher is used to encrypt the key.  As
        input to the RC4 engine, the IV and key are concatenated rather
        than being combined within a mixing function.  As with WEP, the
        IV is not a counter, and therefore there is little protection
        against reuse.




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


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

6.  IANA Considerations

   This specification does not create any RADIUS attributes nor any new
   number spaces for IANA administration.  However, it does require
   assignment of new values to existing RADIUS attributes.  These
   include:

   Attribute              Values Required
   =========              ===============
   NAS-Port-Type          Token-Ring (20), FDDI (21)
   Tunnel-Type            VLAN (13)
   Acct-Terminate-Cause   Supplicant Restart (19)
                          Reauthentication Failure (20)
                          Port Reinitialized (21)
                          Port Administratively Disabled (22)

7.  References

7.1.  Normative References

   [RFC1321]      Rivest, R., "The MD5 Message-Digest Algorithm", RFC
                  1321, April 1992.

   [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
                  Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2284]      Blunk, L. and J. Vollbrecht, "PPP Extensible
                  Authentication Protocol (EAP)", RFC 2284, March 1998.

   [RFC2865]      Rigney, C., Willens, S., Rubens, A. and W. Simpson,
                  "Remote Authentication Dial In User Service (RADIUS)",
                  RFC 2865, June 2000.

   [RFC2866]      Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.

   [RFC2867]      Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting
                  Modifications for Tunnel Protocol Support", RFC 2867,
                  June 2000.





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


   [RFC2868]      Zorn, G., Leifer, D., Rubens, A., Shriver, J.,
                  Holdrege, M. and I. Goyret, "RADIUS Attributes for
                  Tunnel Protocol Support", RFC 2868, June 2000.

   [RFC2869]      Rigney, C., Willats, W. and P. Calhoun, "RADIUS
                  Extensions", RFC 2869, June 2000.

   [RFC3162]      Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6",
                  RFC 3162, August 2001.

   [RFC3280]      Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
                  X.509 Public Key Infrastructure Certificate and
                  Certificate Revocation List (CRL) Profile", RFC 3280,
                  April 2002.

   [RFC3576]      Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B.
                  Aboba, "Dynamic Authorization Extensions to Remote
                  Authentication Dial In User Service (RADIUS)", RFC
                  3576, July 2003.

   [RFC3579]      Aboba, B. and P. Calhoun, "RADIUS (Remote
                  Authentication Dial In User Service) Support For
                  Extensible Authentication Protocol (EAP)", RFC 3579,
                  September 2003.

   [IEEE8021X]    IEEE Standards for Local and Metropolitan Area
                  Networks:  Port based Network Access Control, IEEE Std
                  802.1X-2001, June 2001.

7.2.  Informative References

   [RFC2104]      Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:
                  Keyed-Hashing for Message Authentication", RFC 2104,
                  February 1997.

   [RFC2434]      Narten, T. and H. Alvestrand, "Guidelines for Writing
                  an IANA Considerations Section in RFCs", BCP 26, RFC
                  2434, October 1998.

   [RFC2548]      Zorn, G., "Microsoft Vendor-specific RADIUS
                  Attributes", RFC 2548, March 1999.

   [RFC2607]      Aboba, B. and J. Vollbrecht, "Proxy Chaining and
                  Policy Implementation in Roaming", RFC 2607, June
                  1999.

   [RFC2716]      Aboba, B. and D. Simon, "PPP EAP TLS Authentication
                  Protocol", RFC 2716, October 1999.



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


   [MD5Attack]    Dobbertin, H., "The Status of MD5 After a Recent
                  Attack."  CryptoBytes Vol.2 No.2, Summer 1996.

   [IEEE802]      IEEE Standards for Local and Metropolitan Area
                  Networks:  Overview and Architecture, ANSI/IEEE Std
                  802, 1990.

   [IEEE8021Q]    IEEE Standards for Local and Metropolitan Area
                  Networks:  Draft Standard for Virtual Bridged Local
                  Area Networks, P802.1Q, January 1998.

   [IEEE8023]     ISO/IEC 8802-3 Information technology -
                  Telecommunications and information exchange between
                  systems - Local and metropolitan area networks -
                  Common specifications - Part 3:  Carrier Sense
                  Multiple Access with Collision Detection (CSMA/CD)
                  Access Method and Physical Layer Specifications, (also
                  ANSI/IEEE Std 802.3- 1996), 1996.

   [IEEE80211]    Information technology - Telecommunications and
                  information exchange between systems - Local and
                  metropolitan area networks - Specific Requirements
                  Part 11:  Wireless LAN Medium Access Control (MAC) and
                  Physical Layer (PHY) Specifications, IEEE Std.
                  802.11-1999, 1999.

   [Berkeley]     Borisov, N., Goldberg, I. and D. Wagner, "Intercepting
                  Mobile Communications: The Insecurity of 802.11", ACM
                  SIGMOBILE, Seventh Annual International Conference on
                  Mobile Computing and Networking, July 2001, Rome,