rfc5080.txt

使用最广泛的radius的linux的源码

   response, even if as noted above, it disagrees with earlier
   responses.

   This problem can be made worse by implementations that use a fixed
   retransmission timeout (30 seconds is common).  We reiterate the
   suggestions in Section 2.1 about using congestive backoff.  In that
   case, responses to earlier transmissions MAY be used as data points
   for congestive backoff, even if their contents are discarded.

2.11.  Framed-IPv6-Prefix

   [RFC3162] Section 2.3 says:

      This Attribute indicates an IPv6 prefix (and corresponding route)
      to be configured for the user.  It MAY be used in Access-Accept
      packets, and can appear multiple times.  It MAY be used in an
      Access-Request packet as a hint by the NAS to the server that it
      would prefer these prefix(es), but the server is not required to
      honor the hint.  Since it is assumed that the NAS will plumb a
      route corresponding to the prefix, it is not necessary for the
      server to also send a Framed-IPv6-Route attribute for the same
      prefix.

   An Internet Service Provider (ISP) may desire to support Prefix
   Delegation [RFC4818] at the same time that it would like to assign a
   prefix for the link between the NAS and the user.  The intent of the



Nelson & DeKok              Standards Track                    [Page 23]

RFC 5080                 RADIUS Issues & Fixes             December 2007


   paragraph was to enable the NAS to advertise the prefix (such as via
   a Router Advertisement).  If the Framed-Routing attribute is used, it
   is also possible that the prefix would be advertised in a routing
   protocol such as Routing Information Protocol Next Generation
   (RIPNG).  RFC 2865 Section 5.10 describes the purpose of Framed-
   Routing:

      This Attribute indicates the routing method for the user, when the
      user is a router to a network.  It is only used in Access-Accept
      packets.

   The description of the Prefix-Length field in RFC 3162 indicates
   excessively wide latitude:

      The length of the prefix, in bits.  At least 0 and no larger than
      128.

   This length appears too broad, because it is not clear what a NAS
   should do with a prefix of greater granularity than /64.  For
   example, the Framed-IPv6-Prefix may contain a /128.  This does not
   imply that the NAS should assign an IPv6 address to the end user,
   because RFC 3162 already defines a Framed-IPv6-Identifier attribute
   to handle the Identifier portion.

   It appears that the Framed-IPv6-Prefix is used for the link between
   the NAS and Customer Premises Equipment (CPE) only if a /64 prefix is
   assigned.  When a /64 or larger prefix is sent, the intent is for the
   NAS to send a routing advertisement containing the information
   present in the Framed-IPv6-Prefix attribute.

   The CPE may also require a delegated prefix for its own use, if it is
   decrementing the Hop Limit field of IP headers.  In that case, it
   should be delegated a prefix by the NAS via the Delegated-IPv6-Prefix
   attribute [RFC4818].  If the CPE is not decrementing Hop Limit, it
   does not require a delegated prefix.

3.  Security Considerations

   The contents of the State attribute are available to both the RADIUS
   client and observers of the RADIUS protocol.  RADIUS server
   implementations should ensure that the State attribute does not
   disclose sensitive information to a RADIUS client or third parties
   observing the RADIUS protocol.

   The cache mechanism described in Section 2.2.2 is vulnerable to
   attacks when Access-Request packets do not contain a Message-
   Authenticator attribute.  If the server accepts requests without a
   Message-Authenticator, then RADIUS packets can be trivially forged by



Nelson & DeKok              Standards Track                    [Page 24]

RFC 5080                 RADIUS Issues & Fixes             December 2007


   an attacker.  Cache entries can then be forcibly expired, negating
   the utility of the cache.  This attack can be mitigated by following
   the suggestions in [RFC3579] Section 4, or by requiring the presence
   of Message-Authenticator, as described in Sections 2.1.1 and 2.2.2.

   Since this document describes the use of RADIUS for purposes of
   authentication, authorization, and accounting in a wide variety of
   networks, applications using these specifications are vulnerable to
   all of the threats that are present in other RADIUS applications.
   For a discussion of these threats, see [RFC2865], [RFC2607],
   [RFC3162], [RFC3579], and [RFC3580].

4.  References

4.1.  Normative References

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

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

   [RFC4818]   Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix
               Attribute", RFC 4818, April 2007.

4.2.  Informative References

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

   [RFC2618]   Aboba, B. and G. Zorn, "RADIUS Authentication Client
               MIB", RFC 2618, June 1999.

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

   [RFC3315]   Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
               C., and M. Carney, "Dynamic Host Configuration Protocol
               for IPv6 (DHCPv6)", RFC 3315, July 2003.






Nelson & DeKok              Standards Track                    [Page 25]

RFC 5080                 RADIUS Issues & Fixes             December 2007


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

   [RFC3580]   Congdon, P., Aboba, B., Smith, A., Zorn, G., and J.
               Roese, "IEEE 802.1X Remote Authentication Dial In User
               Service (RADIUS) Usage Guidelines", RFC 3580, September
               2003.

   [RFC3748]   Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
               Levkowetz, Ed., "Extensible Authentication Protocol
               (EAP)", RFC 3748, June 2004.

   [RFC3927]   Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
               Configuration of IPv4 Link-Local Addresses", RFC 3927,
               May 2005.

   [RFC4282]   Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
               Network Access Identifier", RFC 4282, December 2005.

   [RFC4668]   Nelson, D., "RADIUS Authentication Client MIB for IPv6",
               RFC 4668, August 2006.

   [RFC4669]   Nelson, D., "RADIUS Authentication Server MIB for IPv6",
               RFC 4669, August 2006.

   [RFC4862]   Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
               Address Autoconfiguration", RFC 4862, September 2007.

   [PANA]      Forsberg, D., Ohba, Y.,Ed., Patil, B., Tschofenig, H.,
               and A. Yegin, "Protocol for Carrying Authentication for
               Network Access (PANA)", Work in Progress.














Nelson & DeKok              Standards Track                    [Page 26]

RFC 5080                 RADIUS Issues & Fixes             December 2007


Acknowledgments

   The authors would like to acknowledge Glen Zorn and Bernard Aboba for
   contributions to this document.

   The alternate algorithm to [RFC3579] Section 2.6.1 that is described
   in Section 2.1.2 of this document was designed by Raghu Dendukuri.

   The text discussing retransmissions in Section 2.2.1 is taken with
   minor edits from Section 9 of" Protocol for Carrying Authentication
   for Network Access (PANA)" [PANA].

   Alan DeKok wishes to acknowledge the support of Quiconnect Inc.,
   where he was employed during much of the work on this document.

   David Nelson wishes to acknowledge the support of Enterasys Networks,
   where he was employed during much of the work on this document.

Authors' Addresses

   David B. Nelson
   Elbrys Networks, Inc.
   75 Rochester Ave., Unit 3
   Portsmouth, N.H. 03801 USA

   Phone: [phone]
   EMail: [e-mail]


   Alan DeKok
   The FreeRADIUS Server Project
   http://freeradius.org/

   EMail: [e-mail]

















Nelson & DeKok              Standards Track                    [Page 27]

RFC 5080                 RADIUS Issues & Fixes             December 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [e-mail].












Nelson & DeKok              Standards Track                    [Page 28]