rfc5080.txt

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

Network Working Group                                          D. Nelson
Request for Comments: 5080                          Elbrys Networks, Inc
Updates: 2865, 2866, 2869, 3579                                 A. DeKok
Category: Standards Track                                     FreeRADIUS
                                                           December 2007


       Common Remote Authentication Dial In User Service (RADIUS)
               Implementation Issues and Suggested Fixes

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   This document describes common issues seen in Remote Authentication
   Dial In User Service (RADIUS) implementations and suggests some
   fixes.  Where applicable, ambiguities and errors in previous RADIUS
   specifications are clarified.



























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


Table of Contents

   1. Introduction ....................................................2
      1.1. Terminology ................................................3
      1.2. Requirements Language ......................................3
   2. Issues ..........................................................3
      2.1. Session Definition .........................................3
           2.1.1. State Attribute .....................................3
           2.1.2. Request-ID Supplementation ..........................6
      2.2. Overload Conditions ........................................7
           2.2.1. Retransmission Behavior .............................7
           2.2.2. Duplicate Detection and Orderly Delivery ...........10
           2.2.3. Server Response to Overload ........................11
      2.3. Accounting Issues .........................................12
           2.3.1. Attributes Allowed in an Interim Update ............12
           2.3.2. Acct-Session-Id and Acct-Multi-Session-Id ..........12
           2.3.3. Request Authenticator ..............................13
           2.3.4. Interim-Accounting-Interval ........................13
           2.3.5. Counter Values in the RADIUS Management
                  Information Base (MIB) .............................14
      2.4. Multiple Filter-ID Attributes .............................15
      2.5. Mandatory and Optional Attributes .........................16
      2.6. Interpretation of Access-Reject ...........................18
           2.6.1. Improper Use of Access-Reject ......................18
           2.6.2. Service Request Denial .............................19
      2.7. Addressing ................................................20
           2.7.1. Link-Local Addresses ...............................20
           2.7.2. Multiple Addresses .................................20
      2.8. Idle-Timeout ..............................................21
      2.9. Unknown Identity ..........................................21
      2.10. Responses After Retransmissions ..........................22
      2.11. Framed-IPv6-Prefix .......................................23
   3. Security Considerations ........................................24
   4. References .....................................................25
      4.1. Normative References ......................................25
      4.2. Informative References ....................................25

1.  Introduction

   The last few years have seen an increase in the deployment of RADIUS
   clients and servers.  This document describes common issues seen in
   RADIUS implementations and suggests some fixes.  Where applicable,
   ambiguities and errors in previous RADIUS specifications are
   clarified.







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


1.1.  Terminology

   This document uses the following terms:

   Network Access Server (NAS)
      The device providing access to the network.  Also known as the
      Authenticator in IEEE 802.1X or Extensible Authentication Protocol
      (EAP) terminology, or RADIUS client.

   service
      The NAS provides a service to the user, such as network access via
      802.11 or Point to Point Protocol (PPP).

   session
      Each service provided by the NAS to a peer constitutes a session,
      with the beginning of the session defined as the point where
      service is first provided, and the end of the session is defined
      as the point where service is ended.  A peer may have multiple
      sessions in parallel or series if the NAS supports that, with each
      session generating a separate start and stop accounting record.

   silently discard
      This means the implementation discards the packet without further
      processing.  The implementation SHOULD provide the capability of
      logging the error, including the contents of the silently
      discarded packet, and SHOULD record the event in a statistics
      counter.

1.2.  Requirements Language

   In this document, several words are used to signify the requirements
   of the specification.  The key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY",
   and "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119].

2.  Issues

2.1.  Session Definition

2.1.1.  State Attribute

   Regarding the State attribute, [RFC2865] Section 5.24 states:

      This Attribute is available to be sent by the server to the client
      in an Access-Challenge and MUST be sent unmodified from the client
      to the server in the new Access-Request reply to that challenge,
      if any.



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


      This Attribute is available to be sent by the server to the client
      in an Access-Accept that also includes a Termination-Action
      Attribute with the value of RADIUS-Request.  If the NAS performs
      the Termination-Action by sending a new Access-Request upon
      termination of the current session, it MUST include the State
      attribute unchanged in that Access-Request.

   Some RADIUS client implementations do not properly use the State
   attribute in order to distinguish a restarted EAP authentication
   process from the continuation of an ongoing process (by the same user
   on the same NAS and port).  Where an EAP-Message attribute is
   included in an Access-Challenge or Access-Accept attribute, RADIUS
   servers SHOULD also include a State attribute.  See Section 2.1.2 on
   Request ID supplementation for additional benefits to using the State
   attribute in this fashion.

   As defined in [RFC2865] Table 5.44, Access-Request packets may
   contain a State attribute.  The table does not qualify this
   statement, while the text in Section 5.24 (quoted above) adds other
   requirements not specified in that table.

   We extend the requirements of [RFC2865] to say that Access-Requests
   that are part of an ongoing Access-Request / Access-Challenge
   authentication process SHOULD contain a State attribute.  It is the
   responsibility of the server, to send a State attribute in an
   Access-Challenge packet, if that server needs a State attribute in a
   subsequent Access-Request to tie multiple Access-Requests together
   into one authentication session.  As defined in [RFC2865] Section
   5.24, the State MUST be sent unmodified from the client to the server
   in the new Access-Request reply to that challenge, if any.

   While most server implementations require the presence of a State
   attribute in an Access-Challenge packet, some challenge-response
   systems can distinguish the initial request from the response to the
   challenge without using a State attribute to track an authentication
   session.  The Access-Challenge and subsequent Access-Request packets
   for those systems do not need to contain a State attribute.

   Other authentication mechanisms need to tie a sequence of Access-
   Request / Access-Challenge packets together into one ongoing
   authentication session.  Servers implementing those authentication
   mechanisms SHOULD include a State attribute in Access-Challenge
   packets.

   In general, if the authentication process involves one or more
   Access-Request / Access-Challenge sequences, the State attribute
   SHOULD be sent by the server in the Access-Challenge packets.  Using
   the State attribute to create a multi-packet session is the simplest



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


   method available in RADIUS today.  While other methods of creating
   multi-packet sessions are possible (e.g., [RFC3579] Section 2.6.1),
   those methods are NOT RECOMMENDED.

   The only permissible values for a State attribute are values provided
   in an Access-Accept, Access-Challenge, CoA-Request or Disconnect-
   Request packet.  A RADIUS client MUST use only those values for the
   State attribute that it has previously received from a server.  An
   Access-Request sent as a result of a new or restarted authentication
   run MUST NOT include the State attribute, even if a State attribute
   has previously been received in an Access-Challenge for the same user
   and port.

   Access-Request packets that contain a Service-Type attribute with the
   value Authorize Only (17) MUST contain a State attribute.  Access-
   Request packets that contain a Service-Type attribute with value Call
   Check (10) SHOULD NOT contain a State attribute.  Any other Access-
   Request packet that performs authorization checks MUST contain a
   State attribute.  This last requirement often means that an Access-
   Accept needs to contain a State attribute, which can then be used in
   a later Access-Request that performs authorization checks.

   The standard use case for Call Check is pre-screening authentication
   based solely on the end-point identifier information, such as phone
   number or Media Access Control (MAC) address in Calling-Station-ID
   and optionally Called-Station-ID.  In this use case, the NAS has no
   way to obtain a State attribute suitable for inclusion in an Access-
   Request.  Other, non-standard, uses of Call Check may require or
   permit the use of a State attribute, but are beyond the scope of this
   document.

   In an Access-Request with a Service-Type Attribute with value Call
   Check, it is NOT RECOMMENDED for the User-Name and User-Password
   attributes to contain the same values (e.g., a MAC address).
   Implementing MAC address checking without using a Service-Type of
   Call Check is NOT RECOMMENDED.  This practice gives an attacker both
   the clear-text and cipher-text of the User-Password field, which
   permits many attacks on the security of the RADIUS protocol.  For
   example, if the Request Authenticator does not satisfy the [RFC2865]
   requirements on global and temporal uniqueness, the practice
   described above may lead to the compromise of the User-Password
   attribute in other Access-Requests for unrelated users.  Access to
   the cipher-text enables offline dictionary attacks, potentially
   exposing the shared secret and compromising the entire RADIUS
   protocol.






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


   Any Access-Request packet that performs authorization checks,
   including Call Check, SHOULD contain a Message-Authenticator
   attribute.  Any response to an Access-Request performing an
   authorization check MUST NOT contain confidential information about
   any user (such as Tunnel-Password), unless that Access-Request
   contains a State attribute.  The use of State here permits the
   authorization check to be tied to an earlier user authentication.  In
   that case, the server MAY respond to the NAS with confidential
   information about that user.  The server MUST NOT respond to that
   authorization check with confidential information about any other
   user.

   For an Access-Request packet performing an authorization check that
   does not contain a State attribute, the server MUST respond with an
   Access-Reject.

2.1.2.  Request-ID Supplementation

   [RFC3579] Section 2.6.1 states:

      In EAP, each session has its own unique Identifier space.  RADIUS
      server implementations MUST be able to distinguish between EAP
      packets with the same Identifier existing within distinct
      sessions, originating on the same NAS.  For this purpose, sessions
      can be distinguished based on NAS and session identification
      attributes.  NAS identification attributes include NAS-Identifier,
      NAS-IPv6-Address and NAS-IPv4-Address.  Session identification
      attributes include User-Name, NAS-Port, NAS-Port-Type, NAS-Port-
      Id, Called-Station-Id, Calling-Station-Id and Originating-Line-