rfc2869.txt

gnu 的radius服务器很好用的

   like, all existing security modules use simple challenge and response
   cycles, with perhaps some overall control information.  This document
   assumes all existing security modules can be supported with one or
   more challenge/response cycles.

   To complicate RADIUS and ARAP integration, ARAP sends down some
   profile information after the DES Phase and before the Security
   Module phase.  This means that besides the responses to challenges,
   this profile information must also be present, at somewhat unusual
   times.  Fortunately the information is only a few  pieces of numeric
   data related to passwords, which this document packs into a single
   new attribute.

   Presenting an Access-Request to RADIUS on behalf of an ARAP
   connection is straightforward. The ARAP NAS generates the random
   number challenge, and then receives the dial-in client's response,
   the dial-in client's challenge, and the user's name. Assuming the
   user is not a guest, the following information is forwarded in an
   Access-Request packet:  User-Name (up to 31 characters long),
   Framed-Protocol (set to 3, ARAP), ARAP-Password, and any additional
   attributes desired, such as Service-Type, NAS-IP-Address, NAS-Id,
   NAS-Port-Type, NAS-Port, NAS-Port-Id, Connect-Info, etc.

   The Request Authenticator is a NAS-generated 16 octet random number.
   The low-order 8 octets of this number are sent to the dial-in user as
   the two 4 octet random numbers required in the ARAP
   msg_auth_challenge packet. Octets 0-3 are the first random number and
   Octets 4-7 are the second random number.

   The ARAP-Password in the Access-Request contains a 16 octet random
   number field, and is used to carry the dial-in user's response to the
   NAS challenge and the client's own challenge to the NAS.  The high-
   order octets contain the dial-in user's challenge to the NAS (2 32-
   bit numbers, 8 octets) and the low-order octets contain the dial-in
   user's response to the NAS challenge (2 32-bit numbers, 8 octets).

   Only one of User-Password, CHAP-Password, or ARAP-Password needs to
   be present in an Access-Request, or one or more EAP-Messages.

   If the RADIUS server does not support ARAP it SHOULD return an
   Access-Reject to the NAS.




Rigney, et al.               Informational                      [Page 7]

RFC 2869                   RADIUS Extensions                   June 2000


   If the RADIUS server does support ARAP, it should verify the user's
   response using the Challenge (from the lower order 8 octets of the
   Request Authenticator) and the user's response (from the low order 8
   octets of the ARAP-Password).

   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,
   up to a total number of times equal to the integer value of the
   Password-Retry attribute.

   If the user is authenticated, the RADIUS server should return an
   Access-Accept packet (Code 2) to the NAS, with ID and Response
   Authenticator as usual, and attributes as follows:

      Service-Type of Framed-Protocol.

      Framed-Protocol of ARAP (3).

      Session-Timeout with the maximum connect time for the user in
      seconds.  If the user is to be given unlimited time,
      Session-Timeout should not be included in the Access-Accept
      packet, and ARAP will treat that as an unlimited timeout (-1).

      ARAP-Challenge-Response, containing 8 octets with the response to
      the dial-in client's challenge. The RADIUS server calculates this
      value by taking the dial-in client's challenge from the high order
      8 octets of the ARAP-Password attribute and  performing DES
      encryption on this value with the authenticating user's password
      as the key. If the user's password is less than 8 octets in
      length, the password is padded at the end with NULL octets to a
      length of 8 before using it as a key. If the user's password is
      greater than 8 octets in length, an Access-Reject MUST be sent
      instead.

      ARAP-Features, containing information that the NAS should send to
      the user in an ARAP "feature flags" packet.

         Octet 0: If zero, user cannot change their password. If non-
         zero user can.  (RADIUS does not handle the password changing,
         just the attribute which indicates whether ARAP indicates they
         can.)

         Octet 1: Minimum acceptable password length (0-8).






Rigney, et al.               Informational                      [Page 8]

RFC 2869                   RADIUS Extensions                   June 2000


         Octet 2-5: Password creation date in Macintosh format, defined
         as 32 bits unsigned representing seconds since Midnight GMT
         January 1, 1904.

         Octet 6-9 Password Expiration Delta from create date in
         seconds.

         Octet 10-13: Current RADIUS time in Macintosh format

      Optionally, a single Reply-Message with a text string up to 253
      characters long which MAY be sent down to the user to be displayed
      in a sign-on/message of the day dialog.

      Framed-AppleTalk-Network may be included.

      Framed-AppleTalk-Zone, up to 32 characters in length, may be
      included.

      ARAP defines the notion of a list of zones for a user.  Along with
      a list of zone names, a Zone Access Flag is defined (and used by
      the NAS) which says how to use the list of zone names. That is,
      the dial-in user may only be allowed to see the Default Zone, or
      only the zones in the zone list (inclusive) or any zone except
      those in the zone list (exclusive).

      The ARAP NAS handles this by having a named filter which contains
      (at least) zone names.  This solves the problem where a single
      RADIUS server is managing disparate NAS clients who may not be
      able to "see" all of the zone names in a user zone list.  Zone
      names only have meaning "at the NAS." The disadvantage of this
      approach is that zone filters must be set up on the NAS somehow,
      then referenced by the RADIUS Filter-Id.

      ARAP-Zone-Access contains an integer which specifies how the "zone
      list" for this user should be used.  If this attribute is present
      and the value is 2 or 4 then a Filter-Id must also be present to
      name a zone list filter to apply the access flag to.

      The inclusion of a Callback-Number or Callback-Id attribute in the
      Access-Accept MAY cause the ARAP NAS to disconnect after sending
      the Feature Flags to begin callback processing in an ARAP specific
      way.









Rigney, et al.               Informational                      [Page 9]

RFC 2869                   RADIUS Extensions                   June 2000


   Other attributes may be present in the Access-Accept packet as well.

   An ARAP NAS will need other information to finish bringing up the
   connection to the dial in client, but this information can be
   provided by the ARAP NAS without any help from RADIUS, either through
   configuration by SNMP, a NAS administration program, or deduced by
   the AppleTalk stack in the NAS. Specifically:

      1. AppearAsNet and AppearAsNode values, sent to the client to tell
         it what network and node numbers it should use in its datagram
         packets.  AppearAsNet can be taken from the Framed-AppleTalk-
         Network attribute or from the configuration or AppleTalk stack
         onthe NAS.

      2. The "default" zone - that is the name of the AppleTalk zone in
         which the dial-in client will appear.  (Or can be specified
         with the Framed-AppleTalk-Zone attribute.)

      3. Other very NAS specific stuff such as the name of the NAS, and
         smartbuffering information.  (Smartbuffering is an ARAP
         mechanism for replacing common AppleTalk datagrams with small
         tokens, to improve slow link performance in a few common
         traffic situations.)

      4. "Zone List" information for this user.  The ARAP specification
         defines a "zone count" field which is actually unused.

   RADIUS supports ARAP Security Modules in the following manner.

   After DES authentication has been completed, the RADIUS server may
   instruct the ARAP NAS to run one or more security modules for the
   dial-in user. Although the underlying protocol supports executing
   multiple security modules in series, in practice all current
   implementations only allow executing one.  Through the use of
   multiple Access-Challenge requests, multiple modules can be
   supported, but this facility will probably never be used.

   We also assume that, even though ARAP allows a free-form dialog
   between security modules on each end of the point-to-point link, in
   actual practice all security modules can be reduced to a simple
   challenge/response cycle.

   If the RADIUS server wishes to instruct the ARAP NAS to run a
   security module, it should send an Access-Challenge packet to the NAS
   with (optionally) the State attribute, plus the ARAP-Challenge-
   Response, ARAP-Features, and two more attributes:





Rigney, et al.               Informational                     [Page 10]

RFC 2869                   RADIUS Extensions                   June 2000


   ARAP-Security: a four octet security module signature, containing a
   Macintosh OSType.

   ARAP-Security-Data, a string to carry the actual security module
   challenge and response.

   When the security module finishes executing, the security module
   response is passed  in an ARAP-Security-Data attribute from the NAS
   to the RADIUS server in a second Access-Request, also including the
   State from the Access-Challenge.  The authenticator field contains no
   special information in this case, and this can be discerned by the
   presence of the State attribute.

2.3.  RADIUS Support for Extensible Authentication Protocol (EAP)

   The Extensible Authentication Protocol (EAP), described in [3],
   provides a standard mechanism for support of additional
   authentication methods within PPP.  Through the use of EAP, support
   for a number of authentication schemes may be added, including smart
   cards, Kerberos, Public Key, One Time Passwords, and others.  In
   order to provide for support of EAP within RADIUS, two new
   attributes, EAP-Message and Message-Authenticator, are introduced in
   this document. This section describes how these new attributes may be
   used for providing EAP support within RADIUS.

   In the proposed scheme, the RADIUS server is used to shuttle RADIUS-
   encapsulated EAP Packets between the NAS and a backend security
   server. While the conversation between the RADIUS server and the
   backend security server will typically occur using a proprietary
   protocol developed by the backend security server vendor, it is also
   possible to use RADIUS-encapsulated EAP via the EAP-Message
   attribute.  This has the advantage of allowing the RADIUS server to
   support EAP without the need for authentication-specific code, which
   can instead reside on the backend security server.

2.3.1.  Protocol Overview

   The EAP conversation between the authenticating peer (dial-in user)
   and the NAS begins with the negotiation of EAP within LCP.  Once EAP
   has been negotiated, the NAS MUST send an EAP-Request/Identity
   message to the authenticating peer, unless identity is determined via
   some other means such as Called-Station-Id or Calling-Station-Id.
   The peer will then respond with an EAP-Response/Identity which the
   the NAS will then forward to the RADIUS server in the EAP-Message
   attribute of a RADIUS Access-Request packet. The RADIUS Server will
   typically use the EAP-Response/Identity to determine which EAP type
   is to be applied to the user.




Rigney, et al.               Informational                     [Page 11]

RFC 2869                   RADIUS Extensions                   June 2000


   In order to permit non-EAP aware RADIUS proxies to forward the
   Access-Request packet, if the NAS sends the EAP-Request/Identity, the
   NAS MUST copy the contents of the EAP-Response/Identity into the
   User-Name attribute and MUST include the EAP-Response/Identity in the
   User-Name attribute in every subsequent Access-Request. NAS-Port or
   NAS-Port-Id SHOULD be included in the attributes issued by the NAS in
   the Access-Request packet, and either NAS-Identifier or NAS-IP-
   Address MUST be included.  In order to permit forwarding of the
   Access-Reply by EAP-unaware proxies, if a User-Name attribute was
   included in an Access-Request, the RADIUS Server MUST include the
   User-Name attribute in subsequent Access-Accept packets. Without the
   User-Name attribute, accounting and billing becomes very difficult to
   manage.

   If identity is determined via another means such as Called-Station-Id
   or Calling-Station-Id, the NAS MUST include these identifying
   attributes in every Access-Request.

   While this approach will save a round-trip, it cannot be universally
   employed.  There are circumstances in which the user's identity may
   not be needed (such as when authentication and accounting is handled
   based on Called-Station-Id or Calling-Station-Id), and therefore an
   EAP-Request/Identity packet may not necessarily be issued by the NAS
   to the authenticating peer. In cases where an EAP-Request/Identity
   packet will not be sent, the NAS will send to the RADIUS server a
   RADIUS Access-Request packet containing an EAP-Message attribute
   signifying EAP-Start. EAP-Start is indicated by sending an EAP-
   Message attribute with a length of 2 (no data). However, it should be
   noted that since no User-Name attribute is included in the Access-
   Request, this approach is not compatible with RADIUS as specified in
   [1], nor can it easily be applied in situations where proxies are
   deployed, such as roaming or shared use networks.

   If the RADIUS server supports EAP, it MUST respond with an Access-
   Challenge packet containing an EAP-Message attribute. If the RADIUS
   server does not support EAP, it MUST respond with an Access-Reject.
   The EAP-Message attribute includes an encapsulated EAP packet which
   is then passed on to the authenticating peer.  In the case where the
   NAS does not initially send an EAP-Request/Identity message to the
   peer, the Access-Challenge typically will contain an EAP-Message
   attribute encapsulating an EAP-Request/Identity message, requesting
   the dial-in user to identify themself. The NAS will then respond with
   a RADIUS Access-Request packet containing an EAP-Message attribute
   encapsulating an EAP-Response.  The conversation continues until
   either a RADIUS Access-Reject or Access-Accept packet is received.






Rigney, et al.               Informational                     [Page 12]

RFC 2869                   RADIUS Extensions                   June 2000


   Reception of a RADIUS Access-Reject packet, with or without an EAP-
   Message attribute encapsulating EAP-Failure, MUST result in the NAS
   issuing an LCP Terminate Request to the authenticating peer.  A
   RADIUS Access-Accept packet with an EAP-Message attribute
   encapsulating EAP-Success successfully ends the authentication phase.
   The RADIUS Access-Accept/EAP-Message/EAP-Success packet MUST contain
   all of the expected attributes which are currently returned in an
   Access-Accept packet.

   The above scenario creates a situation in which the NAS never needs
   to manipulate an EAP packet.  An alternative may be used in
   situations where an EAP-Request/Identity message will always be sent
   by the NAS to the authenticating peer.

   For proxied RADIUS requests there are two methods of processing.  If
   the domain is determined based on the Called-Station-Id, the RADIUS
   Server may proxy the initial RADIUS Access-Request/EAP-Start. If the
   domain is determined based on the user's identity, the local RADIUS