rfc3579.txt

radius服务器

   configure this CA as a trust anchor for use with IPsec.

   Since unlike SSL/TLS, IKE does not permit certificate policies to be
   set on a per-port basis, certificate policies need to apply to all
   uses of IPsec on RADIUS clients and servers.  In IPsec deployments
   supporting only certificate authentication, a management station
   initiating an IPsec-protected telnet session to the RADIUS server
   would need to obtain a certificate chaining to the RADIUS client CA.
   Issuing such a certificate might not be appropriate if the management
   station was not authorized as a RADIUS client.

   Where RADIUS clients may obtain their IP address dynamically (such as
   an Access Point supporting DHCP), IKE Main Mode with pre-shared keys
   [RFC2409] SHOULD NOT be used, since this requires use of a group



Aboba & Calhoun              Informational                     [Page 21]

RFC 3579                      RADIUS & EAP                September 2003


   pre-shared key; instead, Aggressive Mode SHOULD be used.  IKEv2, a
   work in progress, may address this issue in the future.  Where RADIUS
   client addresses are statically assigned, either Aggressive Mode or
   Main Mode MAY be used.  With certificate authentication, Main Mode
   SHOULD be used.

   Care needs to be taken with IKE Phase 1 Identity Payload selection in
   order to enable mapping of identities to pre-shared keys even with
   Aggressive Mode.  Where the ID_IPV4_ADDR or ID_IPV6_ADDR Identity
   Payloads are used and addresses are dynamically assigned, mapping of
   identities to keys is not possible, so that group pre-shared keys are
   still a practical necessity.  As a result, the ID_FQDN identity
   payload SHOULD be employed in situations where Aggressive mode is
   utilized along with pre-shared keys and IP addresses are dynamically
   assigned.  This approach also has other advantages, since it allows
   the RADIUS server and client to configure themselves based on the
   fully qualified domain name of their peers.

   Note that with IPsec, security services are negotiated at the
   granularity of an IPsec SA, so that RADIUS exchanges requiring a set
   of security services different from those negotiated with existing
   IPsec SAs will need to negotiate a new IPsec SA.  Separate IPsec SAs
   are also advisable where quality of service considerations dictate
   different handling RADIUS conversations.  Attempting to apply
   different quality of service to connections handled by the same IPsec
   SA can result in reordering, and falling outside the replay window.
   For a discussion of the issues, see [RFC2983].

4.3.  Security Issues

   This section provides more detail on the vulnerabilities identified
   in Section 4.1., and how they may be mitigated.  Vulnerabilities
   include:

   Privacy issues
   Spoofing and hijacking
   Dictionary attacks
   Known plaintext attacks
   Replay attacks
   Negotiation attacks
   Impersonation
   Man in the middle attacks
   Separation of authenticator and authentication server
   Multiple databases







Aboba & Calhoun              Informational                     [Page 22]

RFC 3579                      RADIUS & EAP                September 2003


4.3.1.  Privacy Issues

   Since RADIUS messages may contain the User-Name attribute as well as
   NAS-IP-Address or NAS-Identifier attributes, an attacker snooping on
   RADIUS traffic may be able to determine the geographic location of
   peers in real time.  In wireless networks, it is often assumed that
   RADIUS traffic is physically secure, since it typically travels over
   the wired network and that this limits the release of location
   information.

   However, it is possible for an authenticated attacker to spoof ARP
   packets [RFC826] so as to cause diversion of RADIUS traffic onto the
   wireless network.  In this way an attacker may obtain RADIUS packets
   from which it can glean peer location information, or which it can
   subject to a known plaintext or offline dictionary attack.  To
   address these vulnerabilities, implementations of this specification
   SHOULD use IPsec ESP with non-null transform and per-packet
   encryption, authentication, integrity and replay protection to
   protect both RADIUS authentication [RFC2865] and accounting [RFC2866]
   traffic, as described in Section 4.2.

4.3.2.  Spoofing and Hijacking

   Access-Request packets with a User-Password attribute establish the
   identity of both the user and the NAS sending the Access-Request,
   because of the way the shared secret between the NAS and RADIUS
   server is used.  Access-Request packets with CHAP-Password or
   EAP-Message attributes do not have a User-Password attribute.  As a
   result, the Message-Authenticator attribute SHOULD be used in
   Access-Request packets that do not have a User-Password attribute, in
   order to establish the identity of the NAS sending the request.

   An attacker may attempt to inject packets into the conversation
   between the NAS and the RADIUS server, or between the RADIUS server
   and the security server.  RADIUS [RFC2865] does not support
   encryption other than attribute hiding.  As described in [RFC2865],
   only Access-Reply and Access-Challenge packets are integrity
   protected.  Moreover, the per-packet authentication and integrity
   protection mechanism described in [RFC2865] has known weaknesses
   [MD5Attack], making it a tempting target for attackers looking to
   subvert RADIUS/EAP.

   To provide stronger security, the Message-Authenticator attribute
   MUST be used in all RADIUS packets containing an EAP-Message
   attribute.  Implementations of this specification SHOULD use IPsec
   ESP with non-null transform and per-packet encryption,
   authentication, integrity and replay protection, as described in
   Section 4.2.



Aboba & Calhoun              Informational                     [Page 23]

RFC 3579                      RADIUS & EAP                September 2003


4.3.3.  Dictionary Attacks

   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] 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.

   The risk of an offline dictionary attack can be further reduced by
   employing IPsec ESP with non-null transform in order to encrypt the
   RADIUS conversation, as described in Section 4.2.

4.3.4.  Known Plaintext Attacks

   Since EAP [RFC2284] does not support PAP, the RADIUS User-Password
   attribute is not used to carry hidden user passwords within
   RADIUS/EAP conversations.  The User-Password hiding mechanism,
   defined in [RFC2865] 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.

   Since the key stream may have been determined previously from a known
   plaintext attack, if the Request Authenticator repeats, attributes
   encrypted using the RADIUS attribute hiding mechanism should be
   considered compromised.  In addition to the User-Password attribute,
   which is not used with EAP, this includes attributes such as
   Tunnel-Password [RFC2868, section 3.5] and MS-MPPE-Send-Key and
   MS-MPPE-Recv-Key attributes [RFC2548, section 2.4], which include a
   Salt field as part of the hiding algorithm.

   To avoid this, [RFC2865], Section 3 advises:

      Since it is expected that the same secret MAY be used to
      authenticate with servers in disparate geographic regions, the
      Request Authenticator field SHOULD exhibit global and temporal
      uniqueness.






Aboba & Calhoun              Informational                     [Page 24]

RFC 3579                      RADIUS & EAP                September 2003


   Where the Request Authenticator repeats, the Salt field defined in
   [RFC2548], Section 2.4 does not provide protection against
   compromise.  This is because MD5 [RFC1321], rather than HMAC-MD5
   [RFC2104], is used to generate the key stream, which is calculated
   from the 128-bit RADIUS shared secret (S), the  128-bit Request
   Authenticator (R), and the Salt field (A), using the formula b(1) =
   MD5(S + R + A).  Since the Salt field is placed at the end, if the
   Request Authenticator were to repeat on a network where PAP is in
   use, then the salted keystream could be calculated from the
   User-Password keystream by continuing the MD5 calculation based on
   the Salt field (A), which is sent in the clear.

   Even though EAP does 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 EAP and PAP.

   The threat can be mitigated by protecting RADIUS with IPsec ESP with
   non-null transform, as described in Section 4.2.  Where RADIUS shared
   secrets are configured, the RADIUS shared secret used by a NAS
   supporting EAP MUST NOT be reused by a NAS utilizing the
   User-Password attribute, since improper shared secret hygiene could
   lead to compromise of hidden attributes.

4.3.5.  Replay Attacks

   The RADIUS protocol provides only limited support for replay
   protection.  RADIUS Access-Requests include liveness via the 128-bit
   Request Authenticator.  However, the Request Authenticator is not a
   replay counter.  Since RADIUS servers may not maintain a cache of
   previous Request Authenticators, the Request Authenticator does not
   provide replay protection.

   RADIUS accounting [RFC2866] does not support replay protection at the
   protocol level.  Due to the need to support failover between RADIUS
   accounting servers, protocol-based replay protection is not
   sufficient to prevent duplicate accounting records.  However, once
   accepted by the accounting server, duplicate accounting records can
   be detected by use of the the Acct-Session-Id [RFC2866, section 5.5]
   and Event-Timestamp [RFC2869, section 5.3] attributes.

   Unlike RADIUS authentication, RADIUS accounting does not use the
   Request Authenticator as a nonce.  Instead, the Request Authenticator
   contains an MD5 hash calculated over the Code, Identifier, Length,
   and request attributes of the Accounting Request packet, plus the
   shared secret.  The Response Authenticator also contains an MD5 hash
   calculated over the Code, Identifier and Length, the Request



Aboba & Calhoun              Informational                     [Page 25]

RFC 3579                      RADIUS & EAP                September 2003


   Authenticator field from the Accounting-Request packet being replied
   to, the response attributes and the shared secret.

   Since the Accounting Response Authenticator depends in part on the
   Accounting Request Authenticator, it is not possible to replay an
   Accounting-Response unless the Request Authenticator repeats.  While
   it is possible to utilize EAP methods such as EAP TLS [RFC2716] which
   include liveness checks on both sides, not all EAP messages will
   include liveness so that this provides incomplete protection.

   Strong replay protection for RADIUS authentication and accounting can
   be provided by enabling IPsec replay protection with RADIUS, as
   described in Section 4.2.

4.3.6.  Negotiation Attacks

   In a negotiation attack a rogue NAS, tunnel server, RADIUS proxy or
   RADIUS server attempts to cause the authenticating peer to choose a
   less secure authentication method.  For example, a session that would
   normally be authenticated with EAP would instead be authenticated via
   CHAP or PAP; alternatively, a connection that would normally be
   authenticated via a more secure EAP method such as EAP-TLS [RFC2716]
   might be made to occur via a less secure EAP method, such as
   MD5-Challenge.  The threat posed by rogue devices, once thought to be
   remote, has gained currency given compromises of telephone company
   switching systems, such as those described in [Masters].

   Protection against negotiation attacks requires the elimination of
   downward negotiations.  The RADIUS exchange may be further protected
   by use of IPsec, as described in Section 4.2.  Alternatively, where
   IPsec is not used, the vulnerability can be mitigated via
   implementation of per-connection policy on the part of the
   authenticating peer, and per-peer policy on the part of the RADIUS
   server.  For the authenticating peer, authentication policy should be
   set on a per-connection basis.  Per-connection policy allows an
   authenticating peer to negotiate a strong EAP method when connecting
   to one service, while negotiating a weaker EAP method for another
   service.

   With per-connection policy, an authenticating peer will only attempt
   to negotiate EAP for a session in which EAP support is expected.  As
   a result, there is a presumption that an authenticating peer
   selecting EAP requires t