rfc3579.txt

radius服务器

   a 'lock step' protocol, so that other than the initial Request, a new
   Request cannot be sent prior to receiving a valid Response.

   The conversation continues until either a RADIUS Access-Reject or
   Access-Accept packet is received from the RADIUS server.  Reception
   of a RADIUS Access-Reject packet MUST result in the NAS denying
   access to the authenticating peer.  A RADIUS Access-Accept packet
   successfully ends the authentication phase.  The NAS MUST NOT
   "manufacture" a Success or Failure packet as the result of a timeout.
   After a suitable number of timeouts have elapsed, the NAS SHOULD
   instead end the EAP conversation.

   Using RADIUS, the NAS can act as a pass-through for an EAP
   conversation between the peer and authentication server, without
   needing to implement the EAP method used between them.  Where the NAS
   initiates the conversation by sending an EAP-Request for an
   authentication method, it may not be required that the NAS fully
   implement the EAP method reflected in the initial EAP-Request.
   Depending on the initial method, it may be sufficient for the NAS to
   be configured with the initial packet to be sent to the peer, and for
   the NAS to act as a pass-through for subsequent messages.  Note that
   since the NAS only encapsulates the EAP-Response in its initial
   Access-Request, the initial EAP-Request within the authentication
   method is not available to the RADIUS server.  For the RADIUS server
   to be able to continue the conversation, either the initial
   EAP-Request is vestigial, so that the RADIUS server need not be aware
   of it, or the relevant information from the initial EAP-Request (such
   as a nonce) is reflected in the initial EAP-Response, so that the
   RADIUS server can obtain it without having received the initial
   EAP-Request.

   Where the initial EAP-Request sent by the NAS is for an
   authentication Type (4 or greater), the peer MAY respond with a Nak
   indicating that it would prefer another authentication method that is
   not implemented locally.  In this case, the NAS SHOULD send
   Access-Request encapsulating the received EAP-Response/Nak.  This
   provides the RADIUS server with a hint about the authentication
   method(s) preferred by the peer, although it does not provide
   information on the Type of the original Request.  It also provides
   the server with the Identifier used in the initial EAP-Request, so
   that Identifier conflicts can be avoided.






Aboba & Calhoun              Informational                      [Page 6]

RFC 3579                      RADIUS & EAP                September 2003


   In order to evaluate whether the alternatives preferred by the
   authenticating peer are allowed, the RADIUS server will typically
   respond with an Access-Challenge containing EAP-Message attribute(s)
   encapsulating an EAP-Request/Identity (Type 1).  This allows the
   RADIUS server to determine the peer identity, so as to be able to
   retrieve the associated authentication policy.  Alternatively, an
   EAP-Request for an authentication method (Type 4 or greater) could be
   sent.  Since the RADIUS server may not be aware of the Type of the
   initial EAP-Request, it is possible for the RADIUS server to choose
   an unacceptable method, and for the peer to respond with another Nak.

   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.  Since RADIUS proxies
   are assumed to act as a pass-through, they cannot be expected to
   parse an EAP-Response/Identity encapsulated within EAP-Message
   attribute(s).  If the NAS initially sends an EAP-Request for an
   authentication method, and the peer identity cannot be determined
   from the EAP-Response, then the User-Name attribute SHOULD be
   determined by another means.  As noted in [RFC2865] Section 5.6, it
   is recommended that Access-Requests use the value of the
   Calling-Station-Id as the value of the User-Name attribute.

   Having the NAS send the initial EAP-Request packet has a number of
   advantages:

   [1]  It saves a round trip between the NAS and RADIUS server.

   [2]  An Access-Request is only sent to the RADIUS server if the
        authenticating peer sends an EAP-Response, confirming that it
        supports EAP.  In situations where peers may be EAP unaware,
        initiating a RADIUS Access-Request on a "carrier sense" or
        "media up" indication may result in many authentication
        exchanges that cannot complete successfully.  For example, on
        wired networks [IEEE8021X] Supplicants typically do not initiate
        the 802.1X conversation with an EAPOL-Start.  Therefore an IEEE
        802.1X-enabled bridge may not be able to determine whether the
        peer supports EAP until it receives a Response to the initial
        EAP-Request.

   [3]  It allows some peers to be authenticated locally.






Aboba & Calhoun              Informational                      [Page 7]

RFC 3579                      RADIUS & EAP                September 2003


   Although having the NAS send the initial EAP-Request packet has
   substantial advantages, this technique cannot be universally
   employed.  There are circumstances in which the peer identity is
   already known (such as when authentication and accounting is handled
   based on Called-Station-Id, Calling-Station-Id and/or
   Originating-Line-Info), but where the appropriate EAP method may vary
   based on that identity.

   Rather than sending an initial EAP-Request packet to the
   authenticating peer, on detecting the presence of the peer, the NAS
   MAY send an Access-Request packet to the RADIUS server containing an
   EAP-Message attribute signifying EAP-Start.  The RADIUS server will
   typically respond with an Access-Challenge containing EAP-Message
   attribute(s) encapsulating an EAP-Request/Identity (Type 1).
   However, an EAP-Request for an authentication method (Type 4 or
   greater) can also be sent by the server.

   EAP-Start is indicated by sending an EAP-Message attribute with a
   length of 2 (no data).  The Calling-Station-Id SHOULD be included in
   the User-Name attribute.  This may result in a RADIUS Access-Request
   being sent by the NAS to the RADIUS server without first confirming
   that the peer supports EAP.  Since this technique can result in a
   large number of uncompleted RADIUS conversations, in situations where
   EAP unaware peers are common, or where peer support for EAP cannot be
   determined on initial contact (e.g. [IEEE8021X] Supplicants not
   initiating the conversation with an EAPOL-Start) it SHOULD NOT be
   employed by default.

   For proxied RADIUS requests, there are two methods of processing.  If
   the domain is determined based on the Calling-Station-Id,
   Called-Station-Id and/or Originating-Line-Info, the RADIUS server may
   proxy the initial RADIUS Access-Request/EAP-Start.  If the realm is
   determined based on the peer identity, the local RADIUS server MUST
   respond with a RADIUS Access-Challenge including an EAP-Message
   attribute encapsulating an EAP-Request/Identity packet.  The response
   from the authenticating peer SHOULD be proxied to the final
   authentication server.

   If an Access-Request is sent to a RADIUS server which does not
   support the EAP-Message attribute, then an Access-Reject MUST be sent
   in response.  On receiving an Access-Reject, the NAS MUST deny access
   to the authenticating peer.









Aboba & Calhoun              Informational                      [Page 8]

RFC 3579                      RADIUS & EAP                September 2003


2.2.  Invalid Packets

   While acting as a pass-through, the NAS MUST validate the EAP header
   fields (Code, Identifier, Length) prior to forwarding an EAP packet
   to or from the RADIUS server.  On receiving an EAP packet from the
   peer, the NAS checks the Code (2) and Length fields, and matches the
   Identifier value against the current Identifier, supplied by the
   RADIUS server in the most recently validated EAP-Request.  On
   receiving an EAP packet from the RADIUS server (encapsulated within
   an Access-Challenge), the NAS checks the Code (1) and Length fields,
   then updates the current Identifier value.  Pending EAP Responses
   that do not match the current Identifier value are silently discarded
   by the NAS.

   Since EAP method fields (Type, Type-Data) are typically not validated
   by a NAS operating as a pass-through, despite these checks it is
   possible for a NAS to forward an invalid EAP packet to or from the
   RADIUS server.  A RADIUS server receiving EAP-Message attribute(s) it
   does not understand SHOULD make the determination of whether the
   error is fatal or non-fatal based on the EAP Type.  A RADIUS server
   determining that a fatal error has occurred MUST send an
   Access-Reject containing an EAP-Message attribute encapsulating
   EAP-Failure.

   A RADIUS server determining that a non-fatal error has occurred MAY
   send an Access-Challenge to the NAS including EAP-Message
   attribute(s) as well as an Error-Cause attribute [RFC3576] with value
   202 (decimal), "Invalid EAP Packet (Ignored)".  The Access-Challenge
   SHOULD encapsulate within EAP-Message attribute(s) the most recently
   sent EAP-Request packet (including the same Identifier value).  On
   receiving such an Access-Challenge, a NAS implementing previous
   versions of this specification will decapsulate the EAP-Request and
   send it to the peer, which will retransmit the EAP-Response.

   A NAS compliant with this specification, on receiving an
   Access-Challenge with an Error-Cause attribute of value 202 (decimal)
   SHOULD discard the EAP-Response packet most recently transmitted to
   the RADIUS server and check whether additional EAP-Response packets
   have been received matching the current Identifier value.  If so, a
   new EAP-Response packet, if available, MUST be sent to the RADIUS
   server within an Access-Request, and the EAP-Message attribute(s)
   included within the Access-Challenge are silently discarded.  If no
   EAP-Response packet is available, then the EAP-Request encapsulated
   within the Access-Challenge is sent to the peer, and the
   retransmission timer is reset.






Aboba & Calhoun              Informational                      [Page 9]

RFC 3579                      RADIUS & EAP                September 2003


   In order to provide protection against Denial of Service (DoS)
   attacks, it is advisable for the NAS to allocate a finite buffer for
   EAP packets received from the peer, and to discard packets according
   to an appropriate policy once that buffer has been exceeded.  Also,
   the RADIUS server is advised to permit only a modest number of
   invalid EAP packets within a single session, prior to terminating the
   session with an Access-Reject.  By default a value of 5 invalid EAP
   packets is recommended.

2.3.  Retransmission

   As noted in [RFC2284], if an EAP packet is lost in transit between
   the authenticating peer and the NAS (or vice versa), the NAS will
   retransmit.

   It may be necessary to adjust retransmission strategies and
   authentication timeouts in certain cases.  For example, when a token
   card is used additional time may be required to allow the user to
   find the card and enter the token.  Since the NAS will typically not
   have knowledge of the required parameters, these need to be provided
   by the RADIUS server.  This can be accomplished by inclusion of
   Session-Timeout attribute within the Access-Challenge packet.

   If Session-Timeout is present in an Access-Challenge packet that also
   contains an EAP-Message, the value of the Session-Timeout is used to
   set the EAP retransmission timer for that EAP Request, and that
   Request alone.  Once the EAP-Request has been sent, the NAS sets the
   retransmission timer, and if it expires without having received an
   EAP-Response corresponding to the Request, then the EAP-Request is
   retransmitted.

2.4.  Fragmentation

   Using the EAP-Message attribute, it is possible for the RADIUS server
   to encapsulate an EAP packet that is larger than the MTU on the link
   between the NAS and the peer.  Since it is not possible for the
   RADIUS server to use MTU discovery to ascertain the link MTU, the
   Framed-MTU attribute may be included in an Access-Request packet
   containing an EAP-Message attribute so as to provide the RADIUS
   server with this information.  A RADIUS server having received a
   Framed-MTU attribute in an Access-Request packet MUST NOT send any
   subsequent packet in this EAP conversation containing EAP-Message
   attributes whose values, when concatenated, exceed the length
   specified by the Framed-MTU value, taking the link type (specified by
   the NAS-Port-Type attribute) into account.  For example, as noted in
   [RFC3580] Section 3.10, for a NAS-Port-Type value of IEEE 802.11, the





Aboba & Calhoun              Informational                     [Page 10]

RFC 3579                      RADIUS & EAP                September 2003


   RADIUS server may send an EAP packet as large as Framed-MTU minus
   four (4) octets, taking into account the additional overhead for the
   IEEE 802.1X Version (1), Type (1) and Body Length (2) fields.

2.5.  Alternative Uses

   Currently the conversation between security servers and the RADIUS
   server is often proprietary because of lack of standardization.  In
   order to increase standardization and provide interoperability
   between RADIUS vendors and  security vendors, it is recommended that
   RADIUS- encapsulated EAP be used for this conversation.

   This has the advantage of allowing the RADIUS server to support EAP
   without the need for authentication-specific code within the RADIUS