[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-calhoun-radius-ext) 00 02 03 04 05 06 RFC 2869

RADIUS Working Group                                            C Rigney
INTERNET-DRAFT                                                Livingston
                                                               W Willats
                                                       Cyno Technologies
expires in six months                                       January 1997


                           RADIUS Extensions
                      draft-ietf-radius-ext-00.txt



Status of this Memo

   This document is a submission to the RADIUS Working Group of the
   Internet Engineering Task Force (IETF).  Comments should be submitted
   to the ietf-radius@livingston.com mailing list.

   Distribution of this memo is unlimited.

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).


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 2058 and RFC 2059.







Rigney, et al.           expires in six months                  [Page i]


DRAFT                      RADIUS Extensions                January 1997


                           Table of Contents


     1.     Introduction ..........................................    1
        1.1       Specification of Requirements ...................    1
        1.2       Terminology .....................................    1

     2.     Operation .............................................    2
        2.1       RADIUS support for Apple Remote Access ..........    2

     3.     Packet Format .........................................    8

     4.     Packet Types ..........................................    8

     5.     Attributes ............................................    8
        5.1       Prompt ..........................................   10
        5.2       Connect-Info ....................................   10
        5.3       Signature .......................................   11
        5.4       EAP-Message .....................................   12
        5.5       Configuration-Token .............................   13
        5.6       Password-Retry ..................................   14
        5.7       ARAP-Password ...................................   15
        5.8       ARAP-Features ...................................   16
        5.9       ARAP-Zone-Access ................................   17
        5.10      ARAP-Security ...................................   18
        5.11      ARAP-Security-Data ..............................   18
        5.12      Table of Attributes .............................   19

     Security Considerations ......................................   20

     References ...................................................   20

     Acknowledgements .............................................   20

     Chair's Address ..............................................   21

     Author's Addresses ...........................................   21














Rigney, et al.           expires in six months                  [Page ii]


DRAFT                      RADIUS Extensions                January 1997


1.  Introduction

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

   This Internet-Draft 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.

   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

   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.


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



Rigney, et al.           expires in six months                  [Page 1]


DRAFT                      RADIUS Extensions                January 1997


             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, 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 2058 and 2059.

2.1.  RADIUS support for Apple Remote Access

   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:




Rigney, et al.           expires in six months                  [Page 2]


DRAFT                      RADIUS Extensions                January 1997


      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 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) [4] 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



Rigney, et al.           expires in six months                  [Page 3]


DRAFT                      RADIUS Extensions                January 1997


   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 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
   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.  [Probably needs to make
   ordering clearer.]

   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



Rigney, et al.           expires in six months                  [Page 4]


DRAFT                      RADIUS Extensions                January 1997


   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.

   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 high-order 8 octets of the
      ARAP-Password).

      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).

         Octet 2-5: Password creation date in Macintosh format, defined



Rigney, et al.           expires in six months                  [Page 5]


DRAFT                      RADIUS Extensions                January 1997


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

   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



Rigney, et al.           expires in six months                  [Page 6]


DRAFT                      RADIUS Extensions                January 1997


   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 on
      the 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:

   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



Rigney, et al.           expires in six months                  [Page 7]


DRAFT                      RADIUS Extensions                January 1997


   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.

3.  Packet Format

   Packet Format is identical to that defined in RFC 2058 and 2059.

4.  Packet Types

   Packet types are identical to those defined in RFC 2058 and 2059.

   See "Table of Attributes" below to determine which types of packets
   can contain which attributes defined here.

5.  Attributes

   RADIUS Attributes carry the specific authentication, authorization
   and accounting details for the request and response.

   Some attributes MAY be included more than once.  The effect of this
   is attribute specific, and is specified in each attribute
   description.  The order of attributes of the same type SHOULD be
   preserved.  The order of attributes of different types is not
   required to be preserved.

   The end of the list of attributes is indicated by the Length of the
   RADIUS packet.

   A summary of the attribute format is the same as in RFC 2058 but is
   included here for ease of reference.  The fields are transmitted from
   left to right.

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |  Value ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type

      The Type field is one octet.  Up-to-date values of the RADIUS Type
      field are specified in the most recent "Assigned Numbers" RFC [2].
      Values 192-223 are reserved for experimental use, values 224-240
      are reserved for implementation-specific use, and values 241-255
      are reserved and should not be used.  This specification concerns



Rigney, et al.           expires in six months                  [Page 8]


DRAFT                      RADIUS Extensions                January 1997


      the following values:

           1-39   (refer to RFC 2058, "RADIUS")
          40-51   (refer to RFC 2059, "RADIUS Accounting")
          52-59   Unused
          60-63   (refer to RFC 2058, "RADIUS")
          64      Prompt
          65      Connect-Info
          66      Signature
          67      EAP-Message
          68      Configuration-Token
          69      Password-Retry
          70      ARAP-Password
          71      ARAP-Features
          72      ARAP-Zone-Access
          73      ARAP-Security
          74      ARAP-Security-Data
          75-191  Unused

   Length

      The Length field is one octet, and indicates the length of this
      attribute including the Type, Length and Value fields.  If an
      attribute is received in a packet with an invalid Length, the
      entire request should be silently discarded.

   Value

      The Value field is zero or more octets and contains information
      specific to the attribute.  The format and length of the Value
      field is determined by the Type and Length fields.

      The format of the value field is one of four data types.

      string    0-253 octets

      address   32 bit value, most significant octet first.

      integer   32 bit value, most significant octet first.

      time      32 bit value, most significant octet first -- seconds
                since 00:00:00 GMT, January 1, 1970.  The standard
                Attributes do not use this data type.








Rigney, et al.           expires in six months                  [Page 9]


DRAFT                      RADIUS Extensions                January 1997


5.1.  Prompt

   Description

      This attribute is used only in Access-Challenge packets, and
      indicates to the NAS whether it should echo the user's response as
      it is entered, or not echo it.


   A summary of the Prompt attribute format is shown below.  The fields
   are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |             Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Value (cont)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type

      64 for Prompt.

   Length

      6

   Value

      The Value field is four octets.

       0      No Echo
       1      Echo




5.2.  Connect-Info

   Description

      This attribute is sent from the NAS to indicate the nature of the
      user's connection.

      The NAS MAY send this attribute in an Access-Request or
      Accounting-Request to indicate the nature of the user's



Rigney, et al.           expires in six months                 [Page 10]


DRAFT                      RADIUS Extensions                January 1997


      connection.

   A summary of the Connect-Info attribute format is shown below.  The
   fields are transmitted from left to right.

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |     String...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type

      65 for Connect-Info.

   Length

      >= 3

   String

      The String field is encoded as a ASCII characters with the
      connection speed at the beginning of the string.

      For example, "28800 V42BIS/LAPM"



5.3.  Signature

   Description

      This attribute MAY be used to sign Access-Requests to prevent
      dictionary attacks on CHAP, ARAP or EAP authentication methods.
      It MAY be used in any Access-Request.

      A RADIUS Server receiving an Access-Request with a Signature
      Attribute present SHOULD calculate the correct value of the
      Signature and silently discard the packet if it does not match the
      value sent.

   A summary of the Signature attribute format is shown below.  The
   fields are transmitted from left to right.







Rigney, et al.           expires in six months                 [Page 11]


DRAFT                      RADIUS Extensions                January 1997



    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |     String...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type

      66 for Signature.

   Length

      18

   String

      Signature is an MD-5 [3] checksum of the shared secret followed by
      the entire Access-Request packet, including Type, ID, Length and
      authenticator.  When the checksum is calculated the signature
      string should be considered to be sixteen octets of zero.

      This attribute is not needed if the User-Password attribute is
      present, but is useful for preventing dictionary attacks on other
      types of authentication.  IP Security will eventually make this
      attribute unnecessary, so it should be considered an interim
      measure.



5.4.  EAP-Message

   Description

      This attribute opaquely encodes Extended Access Protocol [4]
      information to allow dial-in users to use EAP to authenticate
      without having to implement EAP on the NAS.

      The NAS places any EAP messages received from the user into one or
      more EAP attributes and forwards them to the RADIUS Server as part
      of the Access-Request, which can return EAP messages in Access-
      Challenge, Access-Accept and Access-Reject packets.

      A RADIUS Server receiving EAP messages that it does not understand
      SHOULD return an Access-Reject.

   A summary of the EAP-Message attribute format is shown below.  The



Rigney, et al.           expires in six months                 [Page 12]


DRAFT                      RADIUS Extensions                January 1997


   fields are transmitted from left to right.

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |     String...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type

      67 for EAP-Message.

   Length

      >= 3.

   String

      The String field contains undifferentiated octets.  If multiple
      EAP-Message attributes are present in a packet their values should
      be concatenated; this allows EAP packets longer than 253 octets to
      be passed by RADIUS.



5.5.  Configuration-Token

   Description

      This attribute is for use in large distributed authentication
      networks based on proxy.  It is sent from a RADIUS Proxy Server to
      a RADIUS Proxy Client in an Access-Request to indicate a type of
      user profile to be used.  It should not be sent to a NAS.

   A summary of the Configuration-Token attribute format is shown below.
   The fields are transmitted from left to right.

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |  String ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type

      68 for Configuration-Token.



Rigney, et al.           expires in six months                 [Page 13]


DRAFT                      RADIUS Extensions                January 1997


   Length

      >= 3

   String

      The String field is one or more octets.  The actual format of the
      information is site or application specific, and a robust
      implementation SHOULD support the field as undistinguished octets.

      The codification of the range of allowed usage of this field is
      outside the scope of this specification.



5.6.  Password-Retry

   Description

      This attribute MAY be included in an Access-Reject to indicate how
      many authentication attempts a user may be allowed to attempt
      before being disconnected.

      It is primarily intended for use with ARAP authentication.

   A summary of the Password-Retry attribute format is shown below.  The
   fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |             Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Value (cont)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type

      69 for Password-Retry.

   Length

      6

   Value

      The Value field is four octets, containing an integer specifying



Rigney, et al.           expires in six months                 [Page 14]


DRAFT                      RADIUS Extensions                January 1997


      the number of password retry attempts to permit the user.



5.7.  ARAP-Password

   Description

      This attribute is only present in an Access-Request packet
      containing a Framed-Protocol of ARAP.

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

   A summary of the ARAP-Password attribute format is shown below.  The
   fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |             Value1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |             Value2
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |             Value3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |             Value4
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type

      70 for ARAP-Password.

   Length

      18

   Value

      This attribute contains a 16 octet string, 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 (Value1 and Value2)
      contain the dial-in user's challenge to the NAS (2 32-bit numbers,
      8 octets) and the low-order octets (Value3 and Value4) contain the
      dial-in user's response to the NAS challenge (2 32-bit numbers, 8
      octets).


Rigney, et al.           expires in six months                 [Page 15]


DRAFT                      RADIUS Extensions                January 1997


5.8.  ARAP-Features

   Description

      This attribute is sent in an Access-Accept packet with Framed-
      Protocol of ARAP, and includes password information that the NAS
      should sent to the user in an ARAP "feature flags" packet.

   A summary of the ARAP-Features attribute format is shown below.  The
   fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |     Value1    |    Value2     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Value3                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Value4                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Value5                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type

      71 for ARAP-Features.

   Length

      16

   Value

      The Value field is a compound string containing information the
      NAS should send to the user in the ARAP "feature flags" packet.

         Value1: 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.)

         Value2: Minimum acceptable password length, from 0 to 8.

         Value3: Password creation date in Macintosh format, defined as







Rigney, et al.           expires in six months                 [Page 16]


DRAFT                      RADIUS Extensions                January 1997


         32 unsigned bits representing seconds since Midnight GMT
         January 1, 1904.

         Value4: Password Expiration Delta from create date in seconds.

         Value5: Current RADIUS time in Macintosh format.



5.9.  ARAP-Zone-Access

   Description

      This attribute is included in an Access-Accept packet with
      Framed-Protocol of ARAP to indicate how the ARAP zone list for the
      user should be used.

   A summary of the ARAP-Zone-Access attribute format is shown below.
   The fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |             Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Value (cont)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type

      72 for ARAP-Zone-Access.

   Length

      6

   Value

      The Value field is four octets encoding an integer with one of the
      following values:

      1      Only allow access to default zone
      2      Use zone filter inclusively
      4      Use zone filter exclusively


      The value 3 is skipped, not because these are bit flags, but



Rigney, et al.           expires in six months                 [Page 17]


DRAFT                      RADIUS Extensions                January 1997


      because 3 in some ARAP implementations means "all zones" which is
      the same as not specifying a list at all under RADIUS.

      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.



5.10.  ARAP-Security

   Description

      This attribute identifies the ARAP Security Module to be used in
      an Access-Challenge packet.

   A summary of the ARAP-Security attribute format is shown below.  The
   fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |             Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Value (cont)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type

      73 for ARAP-Security.

   Length

      6

   Value

      The Value field is four octets, containing an integer specifying
      the security module signature, which is a Macintosh OSType.
      (Macintosh OSTypes are 4 ascii characters cast as a 32-bit
      integer)



5.11.  ARAP-Security-Data

   Description



Rigney, et al.           expires in six months                 [Page 18]


DRAFT                      RADIUS Extensions                January 1997


      This attribute contains the actual security module challenge or
      response, and can be found in Access-Challenge and Access-Request
      packets.

   A summary of the ARAP-Security-Data attribute format is shown below.
   The fields are transmitted from left to right.

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |     String...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type

      74 for ARAP-Security-Data.

   Length

      >=3

   String

      The String field contains the security module challenge or
      response associated with the ARAP Security Module specified in
      ARAP-Security.



5.12.  Table of Attributes

   The following table provides a guide to which attributes may be found
   in which kind of packets.  Connect-Info may have 0-1 instances in an
   Accounting-Request packet, the other attributes added in this
   document must not be present in an Accounting-Request.


   Request   Accept   Reject   Challenge   #    Attribute
   0         0        0        0-1         64   Prompt
   0-1       0        0        0           65   Connect-Info
   0-1       0        0        0           66   Signature
   0+        0+       0+       0+          67   EAP-Message [Note 1]
   0         0+       0        0           68   Configuration-Token
   0         0        0-1      0           69   Password-Retry
   0-1       0        0        0           70   ARAP-Password [Note 1]
   0         0-1      0        0-1         71   ARAP-Features
   0         0-1      0        0           72   ARAP-Zone-Access



Rigney, et al.           expires in six months                 [Page 19]


DRAFT                      RADIUS Extensions                January 1997


   0-1       0        0        0-1         73   ARAP-Security
   0+        0        0        0+          73   ARAP-Security-Data
   Request   Accept   Reject   Challenge   #    Attribute


   [Note 1] An Access-Request MUST contain either a User-Password or
   CHAP-Password or ARAP-Password or one or more EAP-Messages, and MUST
   NOT contain more than one type of those four attributes.

   The following table defines the above table entries.

      0     This attribute MUST NOT be present
      0+    Zero or more instances of this attribute MAY be present.
      0-1   Zero or one instance of this attribute MAY be present.
      1     Exactly one instance of this attribute MUST be present.


Security Considerations

   Security issues are the primary topic of this document.



References

   [1]   Rigney, C., Rubens, A., Simpson, W., and S. Willens, "Remote
         Authentication Dial In User Service (RADIUS)", RFC 2058,
         January 1997.

   [2]   Rigney, C., "RADIUS Accounting", RFC 2059, January 1997.

   [3]   Rivest, R., and Dusse, S., "The MD5 Message-Digest Algorithm",
         RFC 1321, MIT Laboratory for Computer Science, RSA Data
         Security Inc., April 1992.

   [4]   Blunk, L., and Vollbrecht, J., "PPP Extensible Authentication
         Protocol (EAP)", draft-ietf-pppext-eap-auth-02.txt, June 1996.



Acknowledgments

   RADIUS and RADIUS Accounting were originally developed by Livingston
   Enterprises for their PortMaster series of Network Access Servers.

   The section on ARAP is adopted with permission from "Using RADIUS to
   Authenticate Apple Remote Access Connections" by Ward Willats of Cyno
   Technologies (ward@cyno.com).



Rigney, et al.           expires in six months                 [Page 20]


DRAFT                      RADIUS Extensions                January 1997



Chair's Address

   The RADIUS working group can be contacted via the current chair:

      Carl Rigney
      Livingston Enterprises
      4464 Willow Road
      Pleasanton, California  94588

      Phone: +1 510 426 0770
      E-Mail: cdr@livingston.com


Author's Addresses

   Questions about this memo can also be directed to:

      Carl Rigney
      Livingston Enterprises
      4464 Willow Road
      Pleasanton, California  94566

      E-Mail: cdr@livingston.com

   Questions on ARAP and RADIUS may be directed to:

      Ward Willats
      Cyno Technologies
      1082 Glen Echo Ave
      San Jose, CA 95125

      Phone: +1 408 297 7766
      Email: ward@cyno.com

















Rigney, et al.           expires in six months                 [Page 21]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/