rfc2869.txt

gnu 的radius服务器很好用的

Network Working Group                                           C. Rigney
Request for Comments: 2869                                     Livingston
Category: Informational                                        W. Willats
                                                        Cyno Technologies
                                                               P. Calhoun
                                                         Sun Microsystems
                                                                June 2000


                           RADIUS Extensions

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   This document describes additional attributes for carrying
   authentication, authorization and accounting information between a
   Network Access Server (NAS) and a shared Accounting Server using the
   Remote Authentication Dial In User Service (RADIUS) protocol
   described in RFC 2865 [1] and RFC 2866 [2].

Table of Contents

   1.     Introduction ..........................................    2
      1.1       Specification of Requirements ...................    3
      1.2       Terminology .....................................    3
   2.     Operation .............................................    4
      2.1       RADIUS support for Interim Accounting Updates....    4
      2.2       RADIUS support for Apple Remote Access
                Protocol ........................................    5
      2.3       RADIUS Support for Extensible Authentication
                Protocol (EAP) ..................................   11
         2.3.1  Protocol Overview ...............................   11
         2.3.2  Retransmission ..................................   13
         2.3.3  Fragmentation ...................................   14
         2.3.4  Examples ........................................   14
         2.3.5  Alternative uses ................................   19
   3.     Packet Format .........................................   19
   4.     Packet Types ..........................................   19
   5.     Attributes ............................................   20



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


      5.1       Acct-Input-Gigawords ............................   22
      5.2       Acct-Output-Gigawords ...........................   23
      5.3       Event-Timestamp .................................   23
      5.4       ARAP-Password ...................................   24
      5.5       ARAP-Features ...................................   25
      5.6       ARAP-Zone-Access ................................   26
      5.7       ARAP-Security ...................................   27
      5.8       ARAP-Security-Data ..............................   28
      5.9       Password-Retry ..................................   28
      5.10      Prompt ..........................................   29
      5.11      Connect-Info ....................................   30
      5.12      Configuration-Token .............................   31
      5.13      EAP-Message .....................................   32
      5.14      Message-Authenticator ...........................   33
      5.15      ARAP-Challenge-Response .........................   35
      5.16      Acct-Interim-Interval ...........................   36
      5.17      NAS-Port-Id .....................................   37
      5.18      Framed-Pool .....................................   37
      5.19      Table of Attributes .............................   38
   6.     IANA Considerations ...................................   39
   7.     Security Considerations ...............................   39
      7.1       Message-Authenticator Security ..................   39
      7.2       EAP Security ....................................   39
         7.2.1  Separation of EAP server and PPP authenticator ..   40
         7.2.2  Connection hijacking ............................   41
         7.2.3  Man in the middle attacks .......................   41
         7.2.4  Multiple databases ..............................   41
         7.2.5  Negotiation attacks .............................   42
   8.     References ............................................   43
   9.     Acknowledgements ......................................   44
   10.    Chair's Address .......................................   44
   11.    Authors' Addresses ....................................   45
   12.    Full Copyright Statement ..............................   47

1.  Introduction

   RFC 2865 [1] describes the RADIUS Protocol as it is implemented and
   deployed today, and RFC 2866 [2] describes how Accounting can be
   performed with RADIUS.












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


   This memo suggests several additional Attributes that can be added to
   RADIUS to perform various useful functions.  These Attributes do not
   have extensive field experience yet and should therefore be
   considered experimental.

   The Extensible Authentication Protocol (EAP) [3] is a PPP extension
   that provides support for additional authentication methods within
   PPP.  This memo describes how the EAP-Message and Message-
   Authenticator attributes may be used for providing EAP support within
   RADIUS.

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

1.1.  Specification of Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [4].

   An implementation is not compliant if it fails to satisfy one or more
   of the must or must not requirements for the protocols it implements.
   An implementation that satisfies all the must, must not, should and
   should not requirements for its protocols is said to be
   "unconditionally compliant"; one that satisfies all the must and must
   not requirements but not all the should or should not requirements
   for its protocols is said to be "conditionally compliant."

   A NAS that does not implement a given service MUST NOT implement the
   RADIUS attributes for that service.  For example, a NAS that is
   unable to offer ARAP service MUST NOT implement the RADIUS attributes
   for ARAP.  A NAS MUST treat a RADIUS access-request requesting an
   unavailable service as an access-reject instead.

1.2.  Terminology

   This document 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





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


             is ended.  A user may have multiple sessions in parallel or
             series if the NAS supports that, with each session
             generating a separate start and stop accounting record.

   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

   Operation is identical to that defined in RFC 2865 [1] and RFC 2866
   [2].

2.1.  RADIUS support for Interim Accounting Updates

   When a user is authenticated, a RADIUS server issues an Access-Accept
   in response to a successful Access-Request. If the server wishes to
   receive interim accounting messages for the given user it must
   include the Acct-Interim-Interval RADIUS attribute in the message,
   which indicates the interval in seconds between interim messages.

   It is also possible to statically configure an interim value on the
   NAS itself. Note that a locally configured value on the NAS MUST
   override the value found in an Access-Accept.

   This scheme does not break backward interoperability since a RADIUS
   server not supporting this extension will simply not add the new
   Attribute. NASes not supporting this extension will ignore the
   Attribute.

   Note that all information in an interim message is cumulative (i.e.
   number of packets sent is the total since the beginning of the
   session, not since the last interim message).

   It is envisioned that an Interim Accounting record (with Acct-
   Status-Type = Interim-Update (3)) would contain all of the attributes
   normally found in an Accounting Stop message with the exception of
   the Acct-Term-Cause attribute.

   Since all the information is cumulative, a NAS MUST ensure that only
   a single generation of an interim Accounting message for a given
   session is present in the retransmission queue at any given time.






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


   A NAS MAY use a fudge factor to add a random delay between Interim
   Accounting messages for separate sessions. This will ensure that a
   cycle where all messages are sent at once is prevented, such as might
   otherwise occur if a primary link was recently restored and many
   dial-up users were directed to the same NAS at once.

   The Network and NAS CPU load of using Interim Updates should be
   carefully considered, and appropriate values of Acct-Interim-Interval
   chosen.

2.2.  RADIUS support for Apple Remote Access Protocol

   The RADIUS (Remote Authentication Dial-In User Service) protocol
   provides a method that allows multiple dial-in Network Access Server
   (NAS) devices to share a common authentication database.

   The Apple Remote Access Protocol (ARAP) provides a method for sending
   AppleTalk network traffic over point-to-point links, typically, but
   not exclusively, asynchronous and ISDN switched-circuit connections.
   Though Apple is moving toward ATCP on PPP for future remote access
   services, ARAP is still a common way for the installed base of
   Macintosh users to make remote network connections, and is likely to
   remain so for some time.

   ARAP is supported by several NAS vendors who also support PPP, IPX
   and other protocols in the same NAS. ARAP connections in these
   multi-protocol devices are often not authenticated with RADIUS, or if
   they are, each vendor creates an individual solution to the problem.

   This section describes the use of additional RADIUS attributes to
   support ARAP. RADIUS client and server implementations that implement
   this specification should be able to authenticate ARAP connections in
   an interoperable manner.

   This section assumes prior knowledge of RADIUS, and will go into some
   detail on the operation of ARAP before entering a detailed discussion
   of the proposed ARAP RADIUS attributes.

   There are two features of ARAP this document does not address:

      1. User initiated password changing. This is not part of RADIUS,
         but can be implemented through a software process other than
         RADIUS.

      2. Out-of-Band messages. At any time, the NAS can send messages to
         an ARA client which appear in a dialog box on the dial-in
         user's screen.  These are not part of authentication and do not
         belong here. However, we note that a Reply-Message attribute in



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


         an Access-Accept may be sent down to the user as a sign-on
         message of the day string using the out-of-band channel.

   We have tried to respect the spirit of the existing RADIUS protocol
   as much as possible, making design decisions compatible with prior
   art.  Further, we have tried to strike a balance between flooding the
   RADIUS world with new attributes, and hiding all of ARAP operation
   within a single multiplexed ARAP attribute string or within Extended
   Authentication Protocol (EAP) [3] machinery.

   However, we feel ARAP is enough of a departure from PPP to warrant a
   small set of similarly named attributes of its own.

   We have assumed that an ARAP-aware RADIUS server will be able to do
   DES encryption and generate security module challenges.  This is in
   keeping with the general RADIUS goal of smart server / simple NAS.

   ARAP authenticates a connection in two phases. The first is a "Two-
   Way DES" random number exchange, using the user's password as a key.
   We say "Two-Way" because the ARAP NAS challenges the dial-in client
   to authenticate itself, and the dial-in client challenges the ARAP
   NAS to authenticate itself.

   Specifically, ARAP does the following:

      1. The NAS sends two 32-bit random numbers to the dial-in client
         in an ARAP msg_auth_challenge packet.

      2. The dial-in client uses the user's password to DES encrypt the
         two random numbers sent to it by the NAS. The dial-in client
         then sends this result, the user's name and two 32-bit random
         numbers of its own back to the NAS in an ARAP msg_auth_request
         packet.

      3. The NAS verifies the encrypted random numbers sent by the
         dial-in client are what it expected. If so, it encrypts the
         dial-in client's challenge using the password and sends it back
         to the dial-in client in an ARAP msg_auth_response packet.

   Note that if the dial-in client's response was wrong,  meaning the
   user has the wrong password, the server can initiate a retry sequence
   up to the maximum amount of retries allowed by the NAS. In this case,
   when the dial-in client receives the ARAP msg_auth_response packet it
   will acknowledge it with an ARAP msg_auth_again packet.

   After this first "DES Phase" the ARAP NAS MAY initiate a secondary
   authentication phase using what Apple calls "Add-In Security
   Modules."  Security Modules are small pieces of code which run on



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


   both the client and server and are allowed to read and write
   arbitrary data across the communications link to perform additional
   authentication functions.  Various security token vendors use this
   mechanism to authenticate ARA callers.

   Although ARAP allows security modules to read and write anything they