rfc2138.txt

gnu 的radius服务器很好用的

Network Working Group                                          C. Rigney
Request for Comments: 2138                                    Livingston
Obsoletes: 2058                                                A. Rubens
Category: Standards Track                                          Merit
                                                              W. Simpson
                                                              Daydreamer
                                                              S. Willens
                                                              Livingston
                                                              April 1997


          Remote Authentication Dial In User Service (RADIUS)

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 a protocol for carrying authentication,
   authorization, and configuration information between a Network Access
   Server which desires to authenticate its links and a shared
   Authentication Server.

Implementation Note

   This memo documents the RADIUS protocol.  There has been some
   confusion in the assignment of port numbers for this protocol.  The
   early deployment of RADIUS was done using the erroneously chosen port
   number 1645, which conflicts with the "datametrics" service.  The
   officially assigned port number for RADIUS is 1812.

Table of Contents

   1.     Introduction ..........................................    3
      1.1       Specification of Requirements ...................    4
      1.2       Terminology .....................................    5
   2.     Operation .............................................    5
      2.1       Challenge/Response ..............................    7
      2.2       Interoperation with PAP and CHAP ................    7
      2.3       Why UDP? ........................................    8
   3.     Packet Format .........................................   10
   4.     Packet Types ..........................................   13
      4.1       Access-Request ..................................   13



Rigney, et. al.             Standards Track                     [Page 1]

RFC 2138                         RADIUS                       April 1997


      4.2       Access-Accept ...................................   14
      4.3       Access-Reject ...................................   15
      4.4       Access-Challenge ................................   17
   5.     Attributes ............................................   18
      5.1       User-Name .......................................   21
      5.2       User-Password ...................................   22
      5.3       CHAP-Password ...................................   23
      5.4       NAS-IP-Address ..................................   24
      5.5       NAS-Port ........................................   25
      5.6       Service-Type ....................................   26
      5.7       Framed-Protocol .................................   28
      5.8       Framed-IP-Address ...............................   29
      5.9       Framed-IP-Netmask ...............................   29
      5.10      Framed-Routing ..................................   30
      5.11      Filter-Id .......................................   31
      5.12      Framed-MTU ......................................   32
      5.13      Framed-Compression ..............................   33
      5.14      Login-IP-Host ...................................   33
      5.15      Login-Service ...................................   34
      5.16      Login-TCP-Port ..................................   35
      5.17      (unassigned) ....................................   36
      5.18      Reply-Message ...................................   36
      5.19      Callback-Number .................................   37
      5.20      Callback-Id .....................................   38
      5.21      (unassigned) ....................................   38
      5.22      Framed-Route ....................................   39
      5.23      Framed-IPX-Network ..............................   40
      5.24      State ...........................................   40
      5.25      Class ...........................................   41
      5.26      Vendor-Specific .................................   42
      5.27      Session-Timeout .................................   44
      5.28      Idle-Timeout ....................................   44
      5.29      Termination-Action ..............................   45
      5.30      Called-Station-Id ...............................   46
      5.31      Calling-Station-Id ..............................   47
      5.32      NAS-Identifier ..................................   48
      5.33      Proxy-State .....................................   48
      5.34      Login-LAT-Service ...............................   49
      5.35      Login-LAT-Node ..................................   50
      5.36      Login-LAT-Group .................................   51
      5.37      Framed-AppleTalk-Link ...........................   52
      5.38      Framed-AppleTalk-Network ........................   53
      5.39      Framed-AppleTalk-Zone ...........................   54
      5.40      CHAP-Challenge ..................................   55
      5.41      NAS-Port-Type ...................................   55
      5.42      Port-Limit ......................................   56
      5.43      Login-LAT-Port ..................................   57
      5.44      Table of Attributes .............................   58



Rigney, et. al.             Standards Track                     [Page 2]

RFC 2138                         RADIUS                       April 1997


   6.     Examples ..............................................   59
      6.1       User Telnet to Specified Host ...................   60
      6.2       Framed User Authenticating with CHAP ............   60
      6.3       User with Challenge-Response card ...............   61
   Security Considerations ......................................   63
   References ...................................................   64
   Acknowledgements .............................................   64
   Chair's Address ..............................................   65
   Author's Addresses ...........................................   65

1.  Introduction

   Managing dispersed serial line and modem pools for large numbers of
   users can create the need for significant administrative support.
   Since modem pools are by definition a link to the outside world, they
   require careful attention to security, authorization and accounting.
   This can be best achieved by managing a single "database" of users,
   which allows for authentication (verifying user name and password) as
   well as configuration information detailing the type of service to
   deliver to the user (for example, SLIP, PPP, telnet, rlogin).

   Key features of RADIUS are:

   Client/Server Model

      A Network Access Server (NAS) operates as a client of RADIUS.  The
      client is responsible for passing user information to designated
      RADIUS servers, and then acting on the response which is returned.

      RADIUS servers are responsible for receiving user connection
      requests, authenticating the user, and then returning all
      configuration information necessary for the client to deliver
      service to the user.

      A RADIUS server can act as a proxy client to other RADIUS servers
      or other kinds of authentication servers.

   Network Security

      Transactions between the client and RADIUS server are
      authenticated through the use of a shared secret, which is never
      sent over the network.  In addition, any user passwords are sent
      encrypted between the client and RADIUS server, to eliminate the
      possibility that someone snooping on an unsecure network could
      determine a user's password.






Rigney, et. al.             Standards Track                     [Page 3]

RFC 2138                         RADIUS                       April 1997


   Flexible Authentication Mechanisms

      The RADIUS server can support a variety of methods to authenticate
      a user.  When it is provided with the user name and original
      password given by the user, it can support PPP PAP or CHAP, UNIX
      login, and other authentication mechanisms.

   Extensible Protocol

      All transactions are comprised of variable length Attribute-
      Length-Value 3-tuples.  New attribute values can be added without
      disturbing existing implementations of the protocol.

1.1.  Specification of Requirements

   In this document, several words are used to signify the requirements
   of the specification.  These words are often capitalized.

   MUST      This word, or the adjective "required", means that the
             definition is an absolute requirement of the specification.

   MUST NOT  This phrase means that the definition is an absolute
             prohibition of the specification.

   SHOULD    This word, or the adjective "recommended", means that there
             may exist valid reasons in particular circumstances to
             ignore this item, but the full implications must be
             understood and carefully weighed before choosing a
             different course.

   MAY       This word, or the adjective "optional", means that this
             item is one of an allowed set of alternatives.  An
             implementation which does not include this option MUST be
             prepared to interoperate with another implementation which
             does include the option.
















Rigney, et. al.             Standards Track                     [Page 4]

RFC 2138                         RADIUS                       April 1997


1.2.  Terminology

   This document frequently uses the following terms:

   service   The NAS provides a service to the dial-in user, such as PPP
             or Telnet.

   session   Each service provided by the NAS to a dial-in user
             constitutes a session, with the beginning of the session
             defined as the point where service is first provided and
             the end of the session defined as the point where service
             is ended.  A user may have multiple sessions in parallel or
             series if the NAS supports that.

   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.

2.  Operation

   When a client is configured to use RADIUS, any user of the client
   presents authentication information to the client.  This might be
   with a customizable login prompt, where the user is expected to enter
   their username and password.  Alternatively, the user might use a
   link framing protocol such as the Point-to-Point Protocol (PPP),
   which has authentication packets which carry this information.

   Once the client has obtained such information, it may choose to
   authenticate using RADIUS.  To do so, the client creates an "Access-
   Request" containing such Attributes as the user's name, the user's
   password, the ID of the client and the Port ID which the user is
   accessing.  When a password is present, it is hidden using a method
   based on the RSA Message Digest Algorithm MD5 [1].

   The Access-Request is submitted to the RADIUS server via the network.
   If no response is returned within a length of time, the request is
   re-sent a number of times.  The client can also forward requests to
   an alternate server or servers in the event that the primary server
   is down or unreachable.  An alternate server can be used either after
   a number of tries to the primary server fail, or in a round-robin
   fashion.  Retry and fallback algorithms are the topic of current
   research and are not specified in detail in this document.






Rigney, et. al.             Standards Track                     [Page 5]

RFC 2138                         RADIUS                       April 1997


   Once the RADIUS server receives the request, it validates the sending
   client.  A request from a client for which the RADIUS server does not
   have a shared secret should be silently discarded.  If the client is
   valid, the RADIUS server consults a database of users to find the
   user whose name matches the request.  The user entry in the database
   contains a list of requirements which must be met to allow access for
   the user.  This always includes verification of the password, but can
   also specify the client(s) or port(s) to which the user is allowed
   access.

   The RADIUS server MAY make requests of other servers in order to
   satisfy the request, in which case it acts as a client.

   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 are permitted in an Access-Reject.

   If all conditions are met and the RADIUS server wishes to issue a
   challenge to which the user must respond, the RADIUS server sends an
   "Access-Challenge" response.  It MAY include a text message to be
   displayed by the client to the user prompting for a response to the
   challenge, and MAY include a State attribute.  If the client receives
   an Access-Challenge and supports challenge/response it MAY display
   the text message, if any, to the user, and then prompt the user for a
   response.  The client then re-submits its original Access-Request
   with a new request ID, with the 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
   Attributes should be 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.









Rigney, et. al.             Standards Track                     [Page 6]

RFC 2138                         RADIUS                       April 1997


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 should be 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.