rfc2865.txt

gnu 的radius服务器很好用的

   User-Password Attribute replaced by the response (encrypted), and
   including the State Attribute from the Access-Challenge, if any.
   Only 0 or 1 instances of the State Attribute SHOULD be





Rigney, et al.              Standards Track                     [Page 6]

RFC 2865                         RADIUS                        June 2000


   present in a request.  The server can respond to this new Access-
   Request with either an Access-Accept, an Access-Reject, or another
   Access-Challenge.

   If all conditions are met, the list of configuration values for the
   user are placed into an "Access-Accept" response.  These values
   include the type of service (for example: SLIP, PPP, Login User) and
   all necessary values to deliver the desired service.  For SLIP and
   PPP, this may include values such as IP address, subnet mask, MTU,
   desired compression, and desired packet filter identifiers.  For
   character mode users, this may include values such as desired
   protocol and host.

2.1.  Challenge/Response

   In challenge/response authentication, the user is given an
   unpredictable number and challenged to encrypt it and give back the
   result. Authorized users are equipped with special devices such as
   smart cards or software that facilitate calculation of the correct
   response with ease. Unauthorized users, lacking the appropriate
   device or software and lacking knowledge of the secret key necessary
   to emulate such a device or software, can only guess at the response.

   The Access-Challenge packet typically contains a Reply-Message
   including a challenge to be displayed to the user, such as a numeric
   value unlikely ever to be repeated. Typically this is obtained from
   an external server that knows what type of authenticator is in the
   possession of the authorized user and can therefore choose a random
   or non-repeating pseudorandom number of an appropriate radix and
   length.

   The user then enters the challenge into his device (or software) and
   it calculates a response, which the user enters into the client which
   forwards it to the RADIUS server via a second Access-Request.  If the
   response matches the expected response the RADIUS server replies with
   an Access-Accept, otherwise an Access-Reject.

   Example: The NAS sends an Access-Request packet to the RADIUS Server
   with NAS-Identifier, NAS-Port, User-Name, User-Password (which may
   just be a fixed string like "challenge" or ignored).  The server
   sends back an Access-Challenge packet with State and a Reply-Message
   along the lines of "Challenge 12345678, enter your response at the
   prompt" which the NAS displays.  The NAS prompts for the response and
   sends a NEW Access-Request to the server (with a new ID) with NAS-
   Identifier, NAS-Port, User-Name, User-Password (the response just
   entered by the user, encrypted), and the same State Attribute that





Rigney, et al.              Standards Track                     [Page 7]

RFC 2865                         RADIUS                        June 2000


   came with the Access-Challenge.  The server then sends back either an
   Access-Accept or Access-Reject based on whether the response matches
   the required value, or it can even send another Access-Challenge.

2.2.  Interoperation with PAP and CHAP

   For PAP, the NAS takes the PAP ID and password and sends them in an
   Access-Request packet as the User-Name and User-Password. The NAS MAY
   include the Attributes Service-Type = Framed-User and Framed-Protocol
   = PPP as a hint to the RADIUS server that PPP service is expected.

   For CHAP, the NAS generates a random challenge (preferably 16 octets)
   and sends it to the user, who returns a CHAP response along with a
   CHAP ID and CHAP username.  The NAS then sends an Access-Request
   packet to the RADIUS server with the CHAP username as the User-Name
   and with the CHAP ID and CHAP response as the CHAP-Password
   (Attribute 3).  The random challenge can either be included in the
   CHAP-Challenge attribute or, if it is 16 octets long, it can be
   placed in the Request Authenticator field of the Access-Request
   packet.  The NAS MAY include the Attributes Service-Type = Framed-
   User and Framed-Protocol = PPP as a hint to the RADIUS server that
   PPP service is expected.

   The RADIUS server looks up a password based on the User-Name,
   encrypts the challenge using MD5 on the CHAP ID octet, that password,
   and the CHAP challenge (from the CHAP-Challenge attribute if present,
   otherwise from the Request Authenticator), and compares that result
   to the CHAP-Password.  If they match, the server sends back an
   Access-Accept, otherwise it sends back an Access-Reject.

   If the RADIUS server is unable to perform the requested
   authentication it MUST return an Access-Reject.  For example, CHAP
   requires that the user's password be available in cleartext to the
   server so that it can encrypt the CHAP challenge and compare that to
   the CHAP response.  If the password is not available in cleartext to
   the RADIUS server then the server MUST send an Access-Reject to the
   client.

2.3.  Proxy

   With proxy RADIUS, one RADIUS server receives an authentication (or
   accounting) request from a RADIUS client (such as a NAS), forwards
   the request to a remote RADIUS server, receives the reply from the
   remote server, and sends that reply to the client, possibly with
   changes to reflect local administrative policy.  A common use for
   proxy RADIUS is roaming.  Roaming permits two or more administrative
   entities to allow each other's users to dial in to either entity's
   network for service.



Rigney, et al.              Standards Track                     [Page 8]

RFC 2865                         RADIUS                        June 2000


   The NAS sends its RADIUS access-request to the "forwarding server"
   which forwards it to the "remote server".  The remote server sends a
   response (Access-Accept, Access-Reject, or Access-Challenge) back to
   the forwarding server, which sends it back to the NAS.  The User-Name
   attribute MAY contain a Network Access Identifier [8] for RADIUS
   Proxy operations.  The choice of which server receives the forwarded
   request SHOULD be based on the authentication "realm". The
   authentication realm MAY be the realm part of a Network Access
   Identifier (a "named realm").  Alternatively, the choice of which
   server receives the forwarded request MAY be based on whatever other
   criteria the forwarding server is configured to use, such as Called-
   Station-Id (a "numbered realm").

   A RADIUS server can function as both a forwarding server and a remote
   server, serving as a forwarding server for some realms and a remote
   server for other realms.  One forwarding server can act as a
   forwarder for any number of remote servers.  A remote server can have
   any number of servers forwarding to it and can provide authentication
   for any number of realms.  One forwarding server can forward to
   another forwarding server to create a chain of proxies, although care
   must be taken to avoid introducing loops.

   The following scenario illustrates a proxy RADIUS communication
   between a NAS and the forwarding and remote RADIUS servers:

   1. A NAS sends its access-request to the forwarding server.

   2. The forwarding server forwards the access-request to the remote
      server.

   3. The remote server sends an access-accept, access-reject or
      access-challenge back to the forwarding server.  For this example,
      an access-accept is sent.

   4. The forwarding server sends the access-accept to the NAS.

   The forwarding server MUST treat any Proxy-State attributes already
   in the packet as opaque data.  Its operation MUST NOT depend on the
   content of Proxy-State attributes added by previous servers.

   If there are any Proxy-State attributes in the request received from
   the client, the forwarding server MUST include those Proxy-State
   attributes in its reply to the client.  The forwarding server MAY
   include the Proxy-State attributes in the access-request when it
   forwards the request, or MAY omit them in the forwarded request.  If
   the forwarding server omits the Proxy-State attributes in the
   forwarded access-request, it MUST attach them to the response before
   sending it to the client.



Rigney, et al.              Standards Track                     [Page 9]

RFC 2865                         RADIUS                        June 2000


   We now examine each step in more detail.

   1. A NAS sends its access-request to the forwarding server.  The
      forwarding server decrypts the User-Password, if present, using
      the shared secret it knows for the NAS.  If a CHAP-Password
      attribute is present in the packet and no CHAP-Challenge attribute
      is present, the forwarding server MUST leave the Request-
      Authenticator untouched or copy it to a CHAP-Challenge attribute.

   '' The forwarding server MAY add one Proxy-State attribute to the
      packet.  (It MUST NOT add more than one.)  If it adds a Proxy-
      State, the Proxy-State MUST appear after any other Proxy-States in
      the packet.  The forwarding server MUST NOT modify any other
      Proxy-States that were in the packet (it may choose not to forward
      them, but it MUST NOT change their contents).  The forwarding
      server MUST NOT change the order of any attributes of the same
      type, including Proxy-State.

   2. The forwarding server encrypts the User-Password, if present,
      using the secret it shares with the remote server, sets the
      Identifier as needed, and forwards the access-request to the
      remote server.

   3. The remote server (if the final destination) verifies the user
      using User-Password, CHAP-Password, or such method as future
      extensions may dictate, and returns an access-accept, access-
      reject or access-challenge back to the forwarding server.  For
      this example, an access-accept is sent.  The remote server MUST
      copy all Proxy-State attributes (and only the Proxy-State
      attributes) in order from the access-request to the response
      packet, without modifying them.

   4. The forwarding server verifies the Response Authenticator using
      the secret it shares with the remote server, and silently discards
      the packet if it fails verification.  If the packet passes
      verification, the forwarding server removes the last Proxy-State
      (if it attached one), signs the Response Authenticator using the
      secret it shares with the NAS, restores the Identifier to match
      the one in the original request by the NAS, and sends the access-
      accept to the NAS.

   A forwarding server MAY need to modify attributes to enforce local
   policy.  Such policy is outside the scope of this document, with the
   following restrictions.  A forwarding server MUST not modify existing
   Proxy-State, State, or Class attributes present in the packet.






Rigney, et al.              Standards Track                    [Page 10]

RFC 2865                         RADIUS                        June 2000


   Implementers of forwarding servers should consider carefully which
   values it is willing to accept for Service-Type.  Careful
   consideration must be given to the effects of passing along Service-
   Types of NAS-Prompt or Administrative in a proxied Access-Accept, and
   implementers may wish to provide mechanisms to block those or other
   service types, or other attributes.  Such mechanisms are outside the
   scope of this document.

2.4.  Why UDP?

   A frequently asked question is why RADIUS uses UDP instead of TCP as
   a transport protocol.  UDP was chosen for strictly technical reasons.

   There are a number of issues which must be understood.  RADIUS is a
   transaction based protocol which has several interesting
   characteristics:

   1. If the request to a primary Authentication server fails, a
      secondary server must be queried.

      To meet this requirement, a copy of the request must be kept above
      the transport layer to allow for alternate transmission.  This
      means that retransmission timers are still required.

   2. The timing requirements of this particular protocol are
      significantly different than TCP provides.

      At one extreme, RADIUS does not require a "responsive" detection
      of lost data.  The user is willing to wait several seconds for the
      authentication to complete.  The generally aggressive TCP
      retransmission (based on average round trip time) is not required,
      nor is the acknowledgement overhead of TCP.

      At the other extreme, the user is not willing to wait several
      minutes for authentication.  Therefore the reliable delivery of
      TCP data two minutes later is not useful.  The faster use of an
      alternate server allows the user to gain access before giving up.

   3. The stateless nature of this protocol simplifies the use of UDP.

      Clients and servers come and go.  Systems are rebooted, or are
      power cycled independently.  Generally this does not cause a
      problem and with creative timeouts and detection of lost TCP
      connections, code can be written to handle anomalous events.  UDP
      however completely eliminates any of this special handling.  Each
      client and server can open their UDP transport just once and leave
      it open through all types of failure events on the network.




Rigney, et al.              Standards Track                    [Page 11]

RFC 2865                         RADIUS                        June 2000


   4. UDP simplifies the server implementation.

      In the earliest implementations of RADIUS, the server was single
      threaded.  This means that a single request was received,
      processed, and returned.  This was found to be unmanageable in
      environments where the back-end security mechanism took real time
      (1 or more seconds).  The server request queue would fill and in
      environments where hundreds of people were being authenticated
      every minute, the request turn-around time increased to longer
      than users were willing to wait (this was especially severe when a
      specific lookup in a database or over DNS took 30 or more
      seconds).  The obvious solution was to make the server multi-
      threaded.  Achieving this was simple with UDP.  Separate processes
      were spawned to serve each request and these processes could
      respond directly to the client NAS with a simple UDP packet to the
      original transport of the client.

   It's not all a panacea.  As noted, using UDP requires one thing which
   is built into TCP: with UDP we must artificially manage
   retransmission timers to the same server, although they don't require
   the same attention to timing provided by TCP.  This one penalty is a
   small price to pay for the advantages of UDP in this protocol.

   Without TCP we would still probably be using tin cans connected by
   string.  But for this particular protocol, UDP is a better choice.

2.5.  Retransmission Hints

   If the RADIUS server and alternate RADIUS server share the same
   shared secret, it is OK to retransmit the packet to the alternate
   RADIUS server with the same ID and Request Authenticator, because the
   content of the attributes haven't changed.  If you want to use a new
   Request Authenticator when sending to the alternate server, you may.

   If you change the contents of the User-Password attribute (or any
   other attribute), you need a new Request Authenticator and therefore