rfc5080.txt

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

   RADIUS server should not send a VSA encoding a filter without
   knowledge that the RADIUS client supports the VSA.






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


2.6.  Interpretation of Access-Reject

2.6.1.  Improper Use of Access-Reject

   The intent of an Access-Reject is to deny access to the requested
   service.  [RFC2865] Section 2 states:

      If any condition is not met, the RADIUS server sends an "Access-
      Reject" response indicating that this user request is invalid.  If
      desired, the server MAY include a text message in the Access-
      Reject which MAY be displayed by the client to the user.  No other
      Attributes (except Proxy-State) are permitted in an Access-Reject.

   This text makes it clear that RADIUS does not allow the provisioning
   of services within an Access-Reject.  If the desire is to allow
   limited access, then an Access-Accept can be sent with attributes
   provisioning limited access.  Attributes within an Access-Reject are
   restricted to those necessary to route the message (e.g., Proxy-
   State), attributes providing the user with an indication that access
   has been denied (e.g., an EAP-Message attribute containing an EAP-
   Failure), or attributes conveying an error message (e.g., a Reply-
   Message or Error-Cause attribute).

   Unfortunately, there are examples where this requirement has been
   misunderstood.  [RFC2869] Section 2.2 states:

      If that authentication fails, the RADIUS server should return an
      Access-Reject packet to the NAS, with optional Password-Retry and
      Reply-Messages attributes.  The presence of Password-Retry
      indicates the ARAP NAS MAY choose to initiate another challenge-
      response cycle...

   This paragraph is problematic from two perspectives.  Firstly, a
   Password-Retry attribute is being returned in an Access-Reject; this
   attribute does not fit into the categories established in [RFC2865].
   Secondly, an Access-Reject packet is being sent in the context of a
   continuing authentication conversation; [RFC2865] requires use of an
   Access-Challenge for this.  [RFC2869] uses the phrase "challenge-
   response" to describe this use of Access-Reject, indicating that the
   semantics of Access-Challenge are being used.

   [RFC2865] Section 4.4 addresses the semantics of Access-Challenge
   being equivalent to Access-Reject in some cases:

      If the NAS does not support challenge/response, it MUST treat an
      Access-Challenge as though it had received an Access-Reject
      instead.




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


   While it is difficult to correct existing deployments of [RFC2869],
   we make the following recommendations:

      [1]   New RADIUS specifications and implementations MUST NOT use
            Access-Reject where the semantics of Access-Challenge are
            intended.

      [2]   Access-Reject MUST mean denial of access to the requested
            service.  In response to an Access-Reject, the NAS MUST NOT
            send any additional Access-Request packets for that user
            session.

      [3]   New deployments of ARAP [RFC2869] SHOULD use Access-
            Challenge instead of Access-Reject packets in the
            conversations described in [RFC2869] Section 2.2.

   We also note that the table of attributes in [RFC2869] Section 5.19
   has an error for the Password-Retry attribute.  It says:

   Request  Accept  Reject  Challenge   #    Attribute
   0        0       0-1     0           75   Password-Retry

   However, the text in [RFC2869], Section 2.3.2 says that Password-
   Retry can be included within an Access-Challenge packet for EAP
   authentication sessions.  We recommend a correction to the table that
   removes the "0-1" from the Reject column, and moves it to the
   Challenge column.  We also add a "Note 2" to follow the existing
   "Note 1" in the document to clarify the use of this attribute.

   Request  Accept  Reject  Challenge   #    Attribute
   0        0       0       0-1         75   Password-Retry [Note 2]

   [Note 2] As per RFC 3579, the use of the Password-Retry in EAP
   authentications is deprecated.  The Password-Retry attribute can be
   used only for ARAP authentication.

2.6.2.  Service Request Denial

   RADIUS has been deployed for purposes outside network access
   authentication, authorization, and accounting.  For example, RADIUS
   has been deployed as a "back-end" for authenticating Voice Over IP
   (VOIP) connections, Hypertext Transfer Protocol (HTTP) sessions
   (e.g., Apache), File Transfer Protocol (FTP) sessions (e.g.,
   proftpd), and machine logins for multiple operating systems (e.g.,
   bsdi, pam, and gina).  In those contexts, an Access-Reject sent to
   the RADIUS client MUST be interpreted as a rejection of the request
   for service, and the RADIUS client MUST NOT offer that service to the
   user.



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


   For example, when an authentication failure occurs in the context of
   an FTP session, the normal semantics for rejecting FTP services
   apply.  The rejection does not necessarily cause the FTP server to
   terminate the underlying TCP connection, but the FTP server MUST NOT
   offer any services protected by user authentication.

   Users may request multiple services from the NAS.  Where those
   services are independent, the deployment MUST treat the RADIUS
   sessions as being independent.

   For example, a NAS may offer multi-link services where a user may
   have multiple simultaneous network connections.  In that case, an
   Access-Reject for a later multi-link connection request does not
   necessarily mean that earlier multi-link connections are torn down.
   Similarly, if a NAS offers both dialup and VOIP services, the
   rejection of a VOIP attempt does not mean that the dialup session is
   torn down.

2.7.  Addressing

2.7.1.  Link-Local Addresses

   Since Link-Local addresses are unique only on the local link, if the
   NAS and RADIUS server are not on the same link, then an IPv6 Link-
   Local address [RFC4862] or an IPv4 Link-Local Address [RFC3927]
   cannot be used to uniquely identify the NAS.  A NAS SHOULD NOT
   utilize a link-scope address within a NAS-IPv6-Address or NAS-IP-
   Address attribute.  A RADIUS server receiving a NAS-IPv6-Address or
   NAS-IP-Address attribute containing a Link-Local address SHOULD NOT
   count such an attribute toward satisfying the requirements of
   [RFC3162] Section 2.1:

      NAS-IPv6-Address and/or NAS-IP-Address MAY be present in an
      Access-Request packet; however, if neither attribute is present
      then NAS-Identifier MUST be present.

2.7.2.  Multiple Addresses

   There are situations in which a RADIUS client or server may have
   multiple addresses.  For example, a dual stack host can have both
   IPv4 and IPv6 addresses; a host that is a member of multiple VLANs
   could have IPv4 and/or IPv6 addresses on each VLAN; a host can have
   multiple IPv4 or IPv6 addresses on a single interface.  However,
   [RFC2865] Section 5.44 only permits zero or one NAS-IP-Address
   attributes within an Access-Request, and [RFC3162] Section 3 only
   permits zero or one NAS-IPv6-Address attributes within an Access-
   Request.  When a NAS has more than one global address and no ability
   to determine which is used for identification in a particular



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


   request, it is RECOMMENDED that the NAS include the NAS-Identifier
   attribute in an Access-Request in order to identify itself to the
   RADIUS server.

   [RFC2865] Section 3 states:

      A RADIUS server MUST use the source IP address of the RADIUS UDP
      packet to decide which shared secret to use, so that RADIUS
      requests can be proxied.

   Therefore, if a RADIUS client sends packets from more than one source
   address, a shared secret will need to be configured on both the
   client and server for each source address.

2.8.  Idle-Timeout

   With respect to the Idle-Timeout attribute, [RFC2865] Section 5.28
   states:

      This Attribute sets the maximum number of consecutive seconds of
      idle connection allowed to the user before termination of the
      session or prompt.  This Attribute is available to be sent by the
      server to the client in an Access-Accept or Access-Challenge.

   [RFC3580] Section 3.12 states:

      The Idle-Timeout attribute is described in [RFC2865].  For IEEE
      802 media other than 802.11 the media are always on.  As a result
      the Idle-Timeout attribute is typically only used with wireless
      media such as IEEE 802.11.  It is possible for a wireless device
      to wander out of range of all Access Points.  In this case, the
      Idle-Timeout attribute indicates the maximum time that a wireless
      device may remain idle.

   In the above paragraphs "idle" may not necessarily mean "no traffic";
   the NAS may support filters defining what traffic is included in the
   idle time determination.  As a result, an "idle connection" is
   defined by local policy in the absence of other attributes.

2.9.  Unknown Identity

   [RFC3748] Section 5.1 states:

      If the Identity is unknown, the Identity Response field should be
      zero bytes in length.






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


   However, [RFC2865] Section 5.1 describes the User-Name attribute as
   follows:

      The String field is one or more octets.

   How should the RADIUS client behave if it receives an EAP-
   Response/Identity that is zero octets in length?

   [RFC2865] Section 5.1 states:

      This Attribute indicates the name of the user to be authenticated.
      It MUST be sent in Access-Request packets if available.

   This suggests that the User-Name attribute may be omitted if it is
   unavailable.

   However, [RFC3579] Section 2.1 states:

      In order to permit non-EAP aware RADIUS proxies to forward the
      Access-Request packet, if the NAS initially sends an EAP-
      Request/Identity message to the peer, the NAS MUST copy the
      contents of the Type-Data field of the EAP-Response/Identity
      received from the peer into the User-Name attribute and MUST
      include the Type-Data field of the EAP-Response/Identity in the
      User-Name attribute in every subsequent Access-Request.

   This suggests that the User-Name attribute should contain the
   contents of the Type-Data field of the EAP-Response/Identity, even if
   it is zero octets in length.

   Note that [RFC4282] does not permit a Network Access Identifier (NAI)
   of zero octets, so that an EAP-Response/Identity with a Type-Data
   field of zero octets MUST NOT be construed as a request for privacy
   (e.g., anonymous NAI).

   When a NAS receives an EAP-Response/Identity with a Type-Data field
   that is zero octets in length, it is RECOMMENDED that it either omit
   the User-Name attribute in the Access-Request or include the
   Calling-Station-Id in the User-Name attribute, along with a Calling-
   Station-Id attribute.

2.10.  Responses After Retransmissions

   Some implementations do not correctly handle the receipt of RADIUS
   responses after retransmissions. [RFC2865] Section 2.5 states:






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


      If the NAS is retransmitting a RADIUS request to the same server
      as before, and the attributes haven't changed, you MUST use the
      same Request Authenticator, ID, and source port.  If any
      attributes have changed, you MUST use a new Request Authenticator
      and ID.

   Note that changing the Request ID for a retransmission may have
   undesirable side effects.  Since RADIUS does not have a clear
   definition of a "session", it is perfectly valid for a RADIUS server
   to treat a retransmission as a new session request, and to reject it
   due to, for example, the enforcement of restrictions on multiple
   simultaneous logins.

   In that situation, the NAS may receive a belated Access-Accept for
   the first request, and an Access-Reject for the retransmitted
   request, both of which apply to the same "session".

   We suggest that the contents of Access-Request packets SHOULD NOT be
   changed during retransmissions.  If they must be changed due to the
   inclusion of an Event-Timestamp attribute, for example, then
   responses to earlier transmissions MUST be silently discarded.  Any
   response to the current request MUST be treated as the definitive