rfc4372.txt

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


RFC 4372                Chargeable User Identity            January 2006


   re-authentication, the CUI attribute will include a previously
   received CUI value (referred to as a non-nul CUI value) in the
   Access-Accept.

   Upon receiving a non-nul CUI value in an Access-Request, the home
   RADIUS server MAY verify that the value of CUI matches the CUI from
   the previous Access-Accept.  If the verification fails, then the
   RADIUS server SHOULD respond with an Access-Reject message.

   If a home RADIUS server that supports the CUI attribute receives an
   Access-Request packet containing a CUI (set to nul or otherwise), it
   MUST include the CUI attribute in the Access-Accept packet.
   Otherwise, if the Access-Request packet does not contain a CUI, the
   home RADIUS server SHOULD NOT include the CUI attribute in the
   Access-Accept packet.  The Access-Request may be sent either in the
   initial authentication or during re-authentication.

   A NAS that requested the CUI during re-authentication by including
   the CUI in the Access-Request will receive the CUI in the
   Access-Accept.  The NAS MUST include the value of that CUI in all
   Accounting Messages.

2.2.  CUI Attribute

   A summary of the RADIUS CUI attribute is given below.


      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     | String...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type: 89 for Chargeable-User-Identity.

   Length: >= 3

   String:

      The string identifies the CUI of the end-user.  This string value
      is a reference to a particular user.  The format and content of
      the string value are determined by the Home RADIUS server.  The
      binding lifetime of the reference to the user is determined based
      on business agreements.  For example, the lifetime can be set to
      one billing period.  RADIUS entities other than the Home RADIUS
      server MUST treat the CUI content as an opaque token, and SHOULD
      NOT perform operations on its content other than a binary equality
      comparison test, between two instances of CUI.  In cases where the




Adrangi, et al.             Standards Track                     [Page 6]

RFC 4372                Chargeable User Identity            January 2006


      attribute is used to indicate the NAS support for the CUI, the
      string value contains a nul character.

3.  Attribute Table

   The following table provides a guide to which attribute(s) may be
   found in which kinds of packets, and in what quantity.

   Request Accept Reject Challenge Accounting #     Attribute
                                    Request
     0-1    0-1     0        0        0-1    89 Chargeable-User-Identity

   Note: If the Access-Accept packet contains CUI, then the NAS MUST
   include the CUI in Accounting Requests (Start, Interim, and Stop)
   packets.

4.  Diameter Consideration

   Diameter needs to define an identical attribute with the same Type
   value.  The CUI should be available as part of the NASREQ application
   [RFC4005].

5.  IANA Considerations

   This document uses the RADIUS [RFC2865] namespace; see
   http://www.iana.org/assignments/radius-types.  The IANA has assigned
   a new RADIUS attribute number for the CUI attribute.

   CUI 89

6.  Security Considerations

   It is strongly recommended that the CUI format used is such that the
   real user identity is not revealed.  Furthermore, where a reference
   is used to a real user identity, it is recommended that the binding
   lifetime of that reference to the real user be kept as short as
   possible.

   The RADIUS entities (RADIUS proxies and clients) outside the home
   network MUST NOT modify the CUI or insert a CUI in an Access-Accept.
   However, there is no way to detect or prevent this.

   Attempting theft of service, a man-in-the-middle may try to insert,
   modify, or remove the CUI in the Access-Accept packets and Accounting
   packets.  However, RADIUS Access-Accept and Accounting packets
   already provide integrity protection.





Adrangi, et al.             Standards Track                     [Page 7]

RFC 4372                Chargeable User Identity            January 2006


   If the NAS includes CUI in an Access-Request packet, a
   man-in-the-middle may remove it.  This will cause the Access-Accept
   packet to not include a CUI attribute, which may cause the NAS to
   reject the session.  To prevent such a denial of service (DoS)
   attack, the NAS SHOULD include a Message-Authenticator(80) attribute
   within Access-Request packets containing a CUI attribute.

7.  Acknowledgements

   The authors would like to thank Jari Arkko, Bernard Aboba, David
   Nelson, Barney Wolff, Blair Bullock, Sami Ala-Luukko, Lothar Reith,
   David Mariblanca, Eugene Chang, Greg Weber, and Mark Grayson for
   their feedback and guidance.

8.  References

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

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

   [RFC4005]  Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
              "Diameter Network Access Server Application", RFC 4005,
              August 2005.

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

8.2.  Informative References

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

   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.








Adrangi, et al.             Standards Track                     [Page 8]

RFC 4372                Chargeable User Identity            January 2006


Authors' Addresses

   Farid Adrangi
   Intel Corporation
   2111 N.E. 25th Avenue
   Hillsboro, OR  97124
   USA

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


   Avi Lior
   Bridgewater Systems Corporation
   303 Terry Fox Drive
   Ottawa, Ontario  K2K 3J1
   Canada

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


   Jouni Korhonen
   Teliasonera Corporation
   P.O.Box 970
   FIN-00051,   Sonera
   Finland

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


   John Loughney
   Nokia
   Itamerenkatu 11-13
   FIN-00180,   Helsinki
   Finland

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











Adrangi, et al.             Standards Track                     [Page 9]

RFC 4372                Chargeable User Identity            January 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

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

Acknowledgement

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).







Adrangi, et al.             Standards Track                    [Page 10]