rfc3576.txt

radius协议的经典实现

   messages, the protocol exchanges described in this document are
   susceptible to the same vulnerabilities as RADIUS [RFC2865].  It is
   RECOMMENDED that IPsec be employed to afford better security.






Chiba, et al.                Informational                     [Page 22]

RFC 3576       Dynamic Authorization Extensions to RADIUS      July 2003


   Implementations of this specification SHOULD support IPsec [RFC2401]
   along with IKE [RFC2409] for key management.  IPsec ESP [RFC2406]
   with a non-null transform SHOULD be supported, and IPsec ESP with a
   non-null encryption transform and authentication support SHOULD be
   used to provide per-packet confidentiality, authentication, integrity
   and replay protection.  IKE SHOULD be used for key management.

   Within RADIUS [RFC2865], a shared secret is used for hiding
   Attributes such as User-Password, as well as used in computation of
   the Response Authenticator.  In RADIUS accounting [RFC2866], the
   shared secret is used in computation of both the Request
   Authenticator and the Response Authenticator.

   Since in RADIUS a shared secret is used to provide confidentiality as
   well as integrity protection and authentication, only use of IPsec
   ESP with a non-null transform can provide security services
   sufficient to substitute for RADIUS application-layer security.
   Therefore, where IPsec AH or ESP null is used, it will typically
   still be necessary to configure a RADIUS shared secret.

   Where RADIUS is run over IPsec ESP with a non-null transform, the
   secret shared between the NAS and the RADIUS server MAY NOT be
   configured.  In this case, a shared secret of zero length MUST be
   assumed.  However, a RADIUS server that cannot know whether incoming
   traffic is IPsec-protected MUST be configured with a non-null RADIUS
   shared secret.

   When IPsec ESP is used with RADIUS, per-packet authentication,
   integrity and replay protection MUST be used.  3DES-CBC MUST be
   supported as an encryption transform and AES-CBC SHOULD be supported.
   AES-CBC SHOULD be offered as a preferred encryption transform if
   supported.  HMAC-SHA1-96 MUST be supported as an authentication
   transform.  DES-CBC SHOULD NOT be used as the encryption transform.

   A typical IPsec policy for an IPsec-capable RADIUS client is
   "Initiate IPsec, from me to any destination port UDP 1812".  This
   IPsec policy causes an IPsec SA to be set up by the RADIUS client
   prior to sending RADIUS traffic.  If some RADIUS servers contacted by
   the client do not support IPsec, then a more granular policy will be
   required: "Initiate IPsec, from me to IPsec-Capable-RADIUS-Server,
   destination port UDP 1812."

   For a client implementing this specification, the policy would be
   "Accept IPsec, from any to me, destination port UDP 3799".  This
   causes the RADIUS client to accept (but not require) use of IPsec.
   It may not be appropriate to require IPsec for all RADIUS servers
   connecting to an IPsec-enabled RADIUS client, since some RADIUS
   servers may not support IPsec.



Chiba, et al.                Informational                     [Page 23]

RFC 3576       Dynamic Authorization Extensions to RADIUS      July 2003


   For an IPsec-capable RADIUS server, a typical IPsec policy is "Accept
   IPsec, from any to me, destination port 1812".  This causes the
   RADIUS server to accept (but not require) use of IPsec.  It may not
   be appropriate to require IPsec for all RADIUS clients connecting to
   an IPsec-enabled RADIUS server, since some RADIUS clients may not
   support IPsec.

   For servers implementing this specification, the policy would be
   "Initiate IPsec, from me to any, destination port UDP 3799".  This
   causes the RADIUS server to initiate IPsec when sending RADIUS
   extension traffic to any RADIUS client.  If some RADIUS clients
   contacted by the server do not support IPsec, then a more granular
   policy will be required, such as "Initiate IPsec, from me to IPsec-
   capable-RADIUS-client, destination port UDP 3799".

   Where IPsec is used for security, and no RADIUS shared secret is
   configured, it is important that the RADIUS client and server perform
   an authorization check.  Before enabling a host to act as a RADIUS
   client, the RADIUS server SHOULD check whether the host is authorized
   to provide network access.  Similarly, before enabling a host to act
   as a RADIUS server, the RADIUS client SHOULD check whether the host
   is authorized for that role.

   RADIUS servers can be configured with the IP addresses (for IKE
   Aggressive Mode with pre-shared keys) or FQDNs (for certificate
   authentication) of RADIUS clients.  Alternatively, if a separate
   Certification Authority (CA) exists for RADIUS clients, then the
   RADIUS server can configure this CA as a trust anchor [RFC3280] for
   use with IPsec.

   Similarly, RADIUS clients can be configured with the IP addresses
   (for IKE Aggressive Mode with pre-shared keys) or FQDNs (for
   certificate authentication) of RADIUS servers.  Alternatively, if a
   separate CA exists for RADIUS servers, then the RADIUS client can
   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 deployment
   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), Main Mode with pre-shared keys
   [RFC2409] SHOULD NOT be used, since this requires use of a group



Chiba, et al.                Informational                     [Page 24]

RFC 3576       Dynamic Authorization Extensions to RADIUS      July 2003


   pre-shared key; instead, Aggressive Mode SHOULD be used.  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].

5.4.  Replay Protection

   Where IPsec replay protection is not used, the Event-Timestamp (55)
   Attribute [RFC2869] SHOULD be included within all messages.  When
   this attribute is present, both the NAS and the RADIUS server MUST
   check that the Event-Timestamp Attribute is current within an
   acceptable time window.  If the Event-Timestamp Attribute is not
   current, then the message MUST be silently discarded.  This implies
   the need for time synchronization within the network, which can be
   achieved by a variety of means, including secure NTP, as described in
   [NTPAUTH].

   Both the NAS and the RADIUS server SHOULD be configurable to silently
   discard messages lacking an Event-Timestamp Attribute.  A default
   time window of 300 seconds is recommended.









Chiba, et al.                Informational                     [Page 25]

RFC 3576       Dynamic Authorization Extensions to RADIUS      July 2003


6.  Example Traces

   Disconnect Request with User-Name:

    0: xxxx xxxx xxxx xxxx xxxx 2801 001c 1b23    .B.....$.-(....#
   16: 624c 3543 ceba 55f1 be55 a714 ca5e 0108    bL5C..U..U...^..
   32: 6d63 6869 6261

   Disconnect Request with Acct-Session-ID:

    0: xxxx xxxx xxxx xxxx xxxx 2801 001e ad0d    .B..... ~.(.....
   16: 8e53 55b6 bd02 a0cb ace6 4e38 77bd 2c0a    .SU.......N8w.,.
   32: 3930 3233 3435 3637                        90234567

   Disconnect Request with Framed-IP-Address:

    0: xxxx xxxx xxxx xxxx xxxx 2801 001a 0bda    .B....."2.(.....
   16: 33fe 765b 05f0 fd9c c32a 2f6b 5182 0806    3.v[.....*/kQ...
   32: 0a00 0203

7.  References

7.1.  Normative References

   [RFC1305]      Mills, D., "Network Time Protocol (version 3)
                  Specification, Implementation and Analysis", RFC 1305,
                  March 1992.

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

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

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

   [RFC2401]      Kent, S. and R. Atkinson, "Security Architecture for
                  the Internet Protocol", RFC 2401, November 1998.

   [RFC2406]      Kent, S. and R. Atkinson, "IP Encapsulating Security
                  Payload (ESP)", RFC 2406, November 1998.

   [RFC2409]      Harkins, D. and D. Carrel, "The Internet Key Exchange
                  (IKE)", RFC 2409, November 1998.





Chiba, et al.                Informational                     [Page 26]

RFC 3576       Dynamic Authorization Extensions to RADIUS      July 2003


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

   [RFC2486]      Aboba, B. and M. Beadles, "The Network Access
                  Identifier", RFC 2486, January 1999.

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

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

   [RADIANA]      Aboba, B., "IANA Considerations for RADIUS (Remote
                  Authentication Dial In User Service)", RFC 3575, July
                  2003.

7.2.  Informative References

   [RFC2882]      Mitton, D., "Network Access Server Requirements:
                  Extended RADIUS Practices", RFC 2882, July 2000.

   [RFC2983]      Black, D. "Differentiated Services and Tunnels", RFC
                  2983, October 2000.

   [AAATransport] Aboba,  B. and J. Wood, "Authentication, Authorization
                  and Accounting (AAA) Transport Profile", RFC 3539,
                  June 2003.

   [Diameter]     Calhoun, P., et al., "Diameter Base Protocol", Work in
                  Progress.

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

   [NASREQ]       Calhoun, P., et al., "Diameter Network Access Server
                  Application", Work in Progress.



Chiba, et al.                Informational                     [Page 27]

RFC 3576       Dynamic Authorization Extensions to RADIUS      July 2003


   [NTPAUTH]      Mills, D., "Public Key Cryptography for the Network
                  Time Protocol", Work in Progress.

8.  Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the imple