[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08                                    
INTERNET DRAFT                                            Pat R. Calhoun
Category: Standards Track                          Sun Microsystems, Inc.
Title: draft-calhoun-diameter-authent-03.txt              William Bulley
Date: May 1998                                        Merit Network, Inc.



                                DIAMETER
                     User Authentication Extensions
                <draft-calhoun-diameter-authent-03.txt>



Status of this Memo

   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.  Internet-Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet-
   Drafts as reference material or to cite them other than as a
   ``working draft'' or ``work in progress.''

   To view the entire list of current Internet-Drafts, please check
   the "1id-abstracts.txt" listing contained in the Internet-Drafts
   Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
   (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
   (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
   (US West Coast).

Abstract

   DIAMETER is a Policy and AAA protocol which can be used for a variety
   of services. This document defines DIAMETER messages that are used
   for the authentication, authorization and accounting of users.

   A considerable amount of effort was put into the design of this
   protocol to ensure that an implementation could support both DIAMETER
   and RADIUS concurrently.











Calhoun                  expires November 1998                  [Page 1]


INTERNET DRAFT                                                  May 1998


Table of Contents

      1.0  Introduction
      1.1  Specification of Requirements
      2.0  Command Codes
      2.1  Domain-Discovery-Request
      2.2  Domain-Discovery-Response
      2.3  Access-Request
      2.4  Access-Response
      2.5  Access-Challenge
      3.0  DIAMETER AVPs
      3.1  User-Name
      3.2  User-Password
      3.3  CHAP-Password
      3.4  NAS-Port
      3.5  Service-Type
      3.6  Framed-Protocol
      3.7  Framed-IP-Address
      3.8  Framed-IP-Netmask
      3.9  Framed-Routing
      3.10 Filter-Id
      3.11 Framed-MTU
      3.12 Framed-Compression
      3.13 Login-IP-Host
      3.14 Login-Service
      3.15 Login-TCP-Port
      3.16 Reply-Message
      3.17 Callback-Number
      3.18 Callback-Id
      3.19 Framed-Route
      3.20 Framed-IPX-Network
      3.21 State
      3.22 Class
      3.23 Vendor-Specific
      3.24 Session-Timeout
      3.25 Idle-Timeout
      3.26 Termination-Action
      3.27 Called-Station-Id
      3.28 Calling-Station-Id
      3.29 Proxy-State
      3.30 Login-LAT-Service
      3.31 Login-LAT-Node
      3.32 Login-LAT-Group
      3.33 Framed-AppleTalk-Link
      3.34 Framed-AppleTalk-Network
      3.35 Framed-AppleTalk-Zone
      3.36 CHAP-Challenge
      3.37 NAS-Port-Type



Calhoun                  expires November 1998                  [Page 2]


INTERNET DRAFT                                                  May 1998


      3.38 Port-Limit
      3.39 Login-LAT-Port
      3.40 Filter-Rule
      3.41 Framed-Password-Policy
      3.42 Table of Attributes
      4.0  Protocol Definition
      4.1  Authorization Procedure
      4.2  Integration with Resource-Management
      4.3  RADIUS Proxies
      4.4  DIAMETER Proxies
      4.5  Domain Discovery
      5.0  References
      6.0  Acknowledgements
      7.0  Authors' Addresses


1.0  Introduction

   This document describes the DIAMETER User Authentication Extensions
   that can be used for a variety of services including Dial-up users
   via NAS, WWW User Authentication, Firewall User Authentication[5][6].

   This document describes Authentication/Authorization messages as well
   as a set of messages which allow DIAMETER hosts to bypass proxies.

   Since Most of the AVPs found in this document was copied from the
   RADIUS protocol[1], it is possible to have both RADIUS and DIAMETER
   servers read the same dictionary and users files. The backward
   compatibility that DIAMETER offers is intended to facilitate
   deployment.

   The Extension number for this draft is one. This value is used in the
   Service-Id AVP as defined in [2].


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



Calhoun                  expires November 1998                  [Page 3]


INTERNET DRAFT                                                  May 1998


              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.


2.0  Command Codes

   This document defines the following DIAMETER Commands. All DIAMETER
   implementations supporting this extension MUST support all of the
   following commands:

      Command Name          Command Code
      -----------------------------------
      Domain-Discovery-Request  261
      Domain-Discovery-Response 262
      Access-Request            263
      Access-Response           264
      Access-Challenge          265


2.1  Domain-Discovery-Request

   Description

      The Domain-Discovery-Request message is used by a DIAMETER device
      wishing to get contact information about a domain's home
      authentication server as well as to receive password policy
      information. This message MUST contain the User-Name attribute in
      order to pass along the user's domain information.

      The X509-Certificate or the X509-Certificate-URL [2] MUST be
      present in this message in order to inform the home authentication
      server of the issuing host's certificate.

      A summary of the Domain-Discovery-Request packet 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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           AVP Code                            |



Calhoun                  expires November 1998                  [Page 4]


INTERNET DRAFT                                                  May 1998


       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          AVP Length           |  AVP Flags  |    Reserved     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Command Code                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Code

      256     DIAMETER Command

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flags

      The AVP Flags field MUST have bit one (Mandatory Support) set.

   Command Type

      The Command Type field MUST be set to 261 (Domain-Discovery-
      Request).


2.2  Domain-Discovery-Response

   Description

      The Domain-Discovery-Response message is sent in response to the
      Domain-Discovery-Request message by the domain's Home
      authentication server. The message MUST contain either the Host-
      Name or Host-IP-Address and either the X509-Certificate or the
      X509-Certificate-URL attribute and SHOULD contain at least one
      Framed-Password-Policy AVP.

      The absence of any Framed-Password-Policy AVPs means that the
      issuer will only accept CHAP and PAP.

      The Domain-Discovery-Response message MUST include the Result-Code
      AVP to indicate whether the request was successful or not. The
      following Error Codes are defined for this command:

         DIAMETER_ERROR_UNKNOWN_DOMAIN       1
            This error code is used to indicate to the initiator of the
            request that the requested domain is unknown and cannot be
            resolved.

         DIAMETER_ERROR_BAD_CERT             2



Calhoun                  expires November 1998                  [Page 5]


INTERNET DRAFT                                                  May 1998


            This error code is used to indicate that the X509-
            Certificate or the X509-Certificate-URL in the Domain-
            Discovery-Request was invalid.

         DIAMETER_ERROR_CANNOT_REPLY         3
            This error code is returned when either an intermediate
            DIAMETER node or the home authentication server cannot reply
            to DIAMETER messages directly.  This could be that the
            policy of an intermediate DIAMETER server does not permit
            direct contact and therefore requires proxying. It could
            also signify that the home authentication server does not
            have public key support.

      A summary of the Domain-Discovery-Response packet 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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           AVP Code                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          AVP Length           |  AVP Flags  |    Reserved     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Command Code                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Code

      256     DIAMETER Command

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flags

      The AVP Flags field MUST have bit one (Mandatory Support) set.

   Command Type

      The Command Type field MUST be set to 262 (Domain-Discovery-
      Response).


2.3  Access-Request

   Description




Calhoun                  expires November 1998                  [Page 6]


INTERNET DRAFT                                                  May 1998


      The Access-Request message is used in order to request
      authentication and authorization for a given user.

      If Authentication is requested the User-Name attribute MUST be
      present. If only Authorization is required it is possible to
      authorize based on DNIS and ANI instead. However, it is not
      possible to authenticate using a User-Name AVP and later
      requesting authorization based on DNIS using the same Session-Id
      (although the inverse is legal).

      Note that the flag field MAY be used in this command in order to
      indicate that either Authentication-Only or Authorization-Only is
      required for the request. If the Authentication-Only bit is set
      the response MUST NOT include any authorization information. Both
      the Authenticate and Authorize bits MUST NOT be set at the same
      time. To ensure that a user is both authenticated and authorized,
      neither flag is set.

      The Access-Request message MUST include a unique Session-Id AVP.
      If The Access-Request is a result of a successful Access-Challenge
      the Session-Id MUST be identical to the one provided in the
      initial Access-Request.

      A summary of the Access-Request packet 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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           AVP Code                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          AVP Length           |  AVP Flags  |    Reserved     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Command Code                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Code

      256     DIAMETER Command

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flags

      The AVP Flags field MUST have bit one (Mandatory Support) set. In
      addition, the following bits may be used (note these bits are



Calhoun                  expires November 1998                  [Page 7]


INTERNET DRAFT                                                  May 1998


      mutually exclusive):

         Authenticate-Only       32
            The Authentication-Only bit is set to indicate that only
            authentication of the user is requested and that no
            authorization information should be returned in the
            response.

         Authorize-Only          64
            The Authorization-Only bit is set to indicate that only
            authorization of the user is requested and that no
            authentication is required.

   Command Type

      The Command Type field MUST be set to 263 (Access-Request).


2.4  Access-Response

   Description

      The Access-Response message is used in order to indicate that
      Authentication and/or authorization was successful. If
      authorization was requested a list of AVPs with the authorization
      information MUST be attached to the message (see section 3.41).

      The Access-Response message MUST include the Session-Id AVP that
      was present in the Access-Request. The Access-Response MUST also
      include the Host-Name AVP and the Result-Code AVP to indicate the
      status of the session. The following error codes are defined for
      this message:

         DIAMETER_ERROR_UNKNOWN_DOMAIN       1
            This error code is used to indicate to the initiator of the
            request that the requested domain is unknown and cannot be
            resolved.

         DIAMETER_ERROR_USER_UNKNOWN         2
            This error code is used to indicate to the initiator that
            the username request is not valid.

         DIAMETER_ERROR_BAD_PASSWORD         3
            This error code indicates that the password provided is
            invalid.

         DIAMETER_ERROR_CANNOT_AUTHORIZE     4
            This error code is used to indicate that the user cannot be



Calhoun                  expires November 1998                  [Page 8]


INTERNET DRAFT                                                  May 1998


            authorized due to the fact that the user has expended the
            servers local resources.  This could be a result that the
            server believes that the user already has an active session,
            or that the user has already spent the number of credits in
            his/her account, etc.

      Note that the flag field MUST be set to the same value that was
      found in the Access-Request message.

      A summary of the Access-Response packet 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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           AVP Code                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          AVP Length           |  AVP Flags  |    Reserved     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Command Code                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Code

      256     DIAMETER Command

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flags

      The AVP Flags field MUST have bit one (Mandatory Support) set. In
      addition, the following bits may be used (note these bits are
      mutually exclusive):

         Authenticate-Only       32
            The Authentication-Only bit is set to indicate that only
            authentication of the user is requested and that no
            authorization information should be returned in the
            response.

         Authorize-Only          64
            The Authorization-Only bit is set to indicate that only
            authorization of the user is requested and that no
            authentication is required.

   Command Type



Calhoun                  expires November 1998                  [Page 9]


INTERNET DRAFT                                                  May 1998


      The Command Type field MUST be set to 264 (Access-Response).


2.5  Access-Challenge

   Description

      If the DIAMETER server desires to send the user a challenge
      requiring a response, then the DIAMETER server MUST respond to the
      Access-Request by transmitting a packet with the Code field set to
      265 (Access-Challenge).

      The message MAY have one or more Reply-Message AVP, and MAY have a
      single State AVP, or none.  No other AVPs are permitted in an
      Access-Challenge other than the Integrity-Check-Vector or
      Digital-Signature AVP as defined in [2].

      On receipt of an Access-Challenge, the Identifier field is matched
      with a pending Access-Request. Invalid packets are silently
      discarded.

      The receipt of a valid Access-Challenge indicates that a new
      Access-Request SHOULD be sent. The NAS MAY display the text
      message, if any, to the user, and then prompt the user for a
      response.  It then sends its original Acess-Request with a new
      request ID, with the User-Password AVP replaced by the user's
      response (encrypted), and including the State AVP from the
      Access-Challenge, if any.  Only zero or one instances of the State
      Attribute can be present in an Access-Request.

      A NAS which supports PAP MAY forward the Reply-Message to the
      dialin client and accept a PAP response which it can use as though
      the user had entered the response.  If the NAS cannot do so, it
      should treat the Access-Challenge as though it had received an
      Access-Response with a Result-Code AVP set to a value other than
      DIAMETER_SUCCESS instead.

      It is preferable to use EAP [5] instead of the Access-Challenge,
      yet it has been maintained for backward compatibility.

      The Access-Response message MUST include the Session-Id AVP that
      was present in the Access-Request and MUST include the same flag
      value that was found in the Access-Request.

      A summary of the Access-Challenge packet format is shown below.
      The fields are transmitted from left to right.

       0                   1                   2                   3



Calhoun                  expires November 1998                 [Page 10]


INTERNET DRAFT                                                  May 1998


       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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           AVP Code                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          AVP Length           |  AVP Flags  |    Reserved     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Command Code                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Code

      256     DIAMETER Command

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flags

      The AVP Flags field MUST have bit one (Mandatory Support) set. In
      addition, following bits may be used (note these bits are mutually
      exclusive):

         Authenticate-Only       32
            The Authentication-Only bit is set to indicate that only
            authentication of the user is requested and that no
            authorization information should be returned in the
            response.

         Authorize-Only          64
            The Authorization-Only bit is set to indicate that only
            authorization of the user is requested and that no
            authentication is required.

   Command Type

      The Command Type field MUST be set to 265 (Access-Challenge).


3.0  DIAMETER AVPs

   This section will define the mandatory AVPs which MUST be supported
   by all DIAMETER implementations supporting this extension. The
   following AVPs are defined in this document:

      Attribute Name       Attribute Code
      -----------------------------------
      User-Name                   1



Calhoun                  expires November 1998                 [Page 11]


INTERNET DRAFT                                                  May 1998


      User-Password               2
      CHAP-Password               3
      NAS-IP-Address              4
      NAS-Port                    5
      Service-Type                6
      Framed-Protocol             7
      Framed-IP-Address           8
      Framed-IP-Netmask           9
      Framed-Routing             10
      Filter-Id                  11
      Framed-MTU                 12
      Framed-Compression         13
      Login-IP-Host              14
      Login-Service              15
      Login-TCP-Port             16
      Reply-Message              18
      Callback-Number            19
      Callback-Id                20
      Framed-Route               22
      Framed-IPX-Network         23
      State                      24
      Class                      25
      Vendor-Specific            26
      Session-Timeout            27
      Idle-Timeout               28
      Termination-Action         29
      Called-Station-Id          30
      Calling-Station-Id         31
      NAS-Identifier             32
      Proxy-State                33
      Login-LAT-Service          34
      Login-LAT-Node             35
      Login-LAT-Group            36
      Framed-AppleTalk-Link      37
      Framed-AppleTalk-Network   38
      Framed-AppleTalk-Zone      39
      CHAP-Challenge             60
      NAS-Port-Type              61
      Port-Limit                 62
      Login-LAT-Port             63
      Filter-Rule               280
      Framed-Password-Policy    281


3.1  User-Name

   Description




Calhoun                  expires November 1998                 [Page 12]


INTERNET DRAFT                                                  May 1998


      This Attribute indicates the name of the user to be authenticated.
      It is normally used in Access-Request packets, but MAY be present
      in the Access-Response message.

      A summary of the User-Name 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   String ...
      +-+-+-+-+-+-+-+-+

   Type

      1 for User-Name.

   AVP Length

      The length of this attribute MUST be at least 9.

   AVP Flags

      The AVP Flags field MUST have bit one (Mandatory Support) set. The
      SS-Encrypted-Data bit SHOULD be set if a shared secret exists.
      The PK-Encrypted-data bit SHOULD NOT be set since intermediate
      DIAMETER servers will require this information in order to
      determine the home DIAMETER server.

   String

      The String field is one or more octets. All DIAMETER systems
      SHOULD support User-Name lengths of at least 63 octets. The format
      of the User-Name SHOULD follow the format defined in [3].


3.2  User-Password

   Description

      This Attribute indicates the password of the user to be
      authenticated, or the user's input following an Access-Challenge.
      It is only used in Access-Request packets.




Calhoun                  expires November 1998                 [Page 13]


INTERNET DRAFT                                                  May 1998


      This AVP MUST be encrypted using one of the methods described in
      [2]. The use of this AVP with shared secret encryption is strongly
      discouraged by the author due to the security implications in a
      proxy environment, yet the support of this attribute has been
      retained for RADIUS backward compability.

      A summary of the User-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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Data ...
      +-+-+-+-+-+-+-+-+

   Type

      2 for User-Password.

   AVP Length

      The length of this attribute MUST be at least 24 and MUST be no
      larger than 136.

   AVP Flags

      The AVP Flags field MUST have bit one (Mandatory Support) set. One
      of the AVP Encryption bits MUST be set.

   Data

      The Data field is between 16 and 128 octets long, inclusive.


3.3  CHAP-Password

   Description

      This Attribute indicates the response value provided by a PPP
      Challenge-Handshake Authentication Protocol (CHAP) user in
      response to the challenge. It is only used in Access-Request
      packets.

      If the CHAP-Password Attribute is found in a message, the CHAP-



Calhoun                  expires November 1998                 [Page 14]


INTERNET DRAFT                                                  May 1998


      Challenge Attribute (60) MUST be present as well.

      A summary of the CHAP-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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  CHAP Ident   |    Data ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      3 for CHAP-Password.

   AVP Length

      The length of this attribute MUST be 25.

   AVP Flags

      The AVP Flags field MUST have bit one (Mandatory Support) set.

   CHAP Ident

      This field is one octet, and contains the CHAP Identifier from the
      user's CHAP Response.

   Data

      The Data field is 16 octets, and contains the CHAP Response from
      the user.


3.4  NAS-Port

   Description

      This Attribute indicates the physical port number of the NAS which
      is authenticating the user. It is normally only used in Access-
      Request messages (see section x for more info). Note that this is
      using "port" in its sense of a physical connection on the NAS, not
      in the sense of a TCP or UDP port number. Either NAS-Port or NAS-
      Port-Type (61) or both SHOULD be present in an Access-Request



Calhoun                  expires November 1998                 [Page 15]


INTERNET DRAFT                                                  May 1998


      packet, if the NAS differentiates among its ports.

      A summary of the NAS-Port 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Integer32                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      5 for NAS-Port.

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flags

      The AVP Flags field MUST have bit one (Mandatory Support) set.

   Integer32

      The Integer32 field is four octets.


3.5  Service-Type

   Description

      This Attribute indicates the type of service the user has
      requested, or the type of service to be provided. It MAY be used
      in both Access-Request and Access-Response messages. A NAS is not
      required to implement all of these service types, and MUST treat
      unknown or unsupported Service-Types as though an Access-Response
      with a Result-Code other than DIAMETER-SUCCESS had been received
      instead.

      A summary of the Service-Type Attribute format is shown below. The
      fields are transmitted from left to right.

      0                   1                   2                   3



Calhoun                  expires November 1998                 [Page 16]


INTERNET DRAFT                                                  May 1998


      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Integer32                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      6 for Service-Type.

   AVP Flags

      The AVP Flags field MUST have bit one (Mandatory Support) set.

   AVP Length

      The length of this attribute MUST be 12.

   Integer32

      The Integer32 field is four octets.

          1      Login
          2      Framed
          3      Callback Login
          4      Callback Framed
          5      Outbound
          6      Administrative
          7      NAS Prompt
          8      Authenticate Only
          9      Callback NAS Prompt

   The service types are defined as follows when used in an Access-
   Response. When used in an Access-Request, they should be considered
   to be a hint to the DIAMETER server that the NAS has reason to
   believe the user would prefer the kind of service indicated, but the
   server is not required to honor the hint.

   Login               The user should be connected to a host.

   Framed              A Framed Protocol should be started for the
                       User, such as PPP or SLIP.

   Callback Login      The user should be disconnected and called
                       back, then connected to a host.



Calhoun                  expires November 1998                 [Page 17]


INTERNET DRAFT                                                  May 1998


   Callback Framed     The user should be disconnected and called
                       back, then a Framed Protocol should be started
                       for the User, such as PPP or SLIP.

   Outbound            The user should be granted access to outgoing
                       devices.

   Administrative      The user should be granted access to the
                       administrative interface to the NAS from which
                       privileged commands can be executed.

   NAS Prompt          The user should be provided a command prompt
                       on the NAS from which non-privileged commands
                       can be executed.

   Authenticate Only   Only Authentication is requested, and no
                       authorization information needs to be returned
                       in the Access-Response (typically used by
                       proxy servers rather than the NAS itself). This
                       SHOULD NOT be used in DIAMETER, yet it is
                       maintained for backward compatibility.

   Callback NAS Prompt The user should be disconnected and called
                       back, then provided a command prompt on the
                       NAS from which non-privileged commands can be
                       executed.


3.6  Framed-Protocol

   Description

      This Attribute indicates the framing to be used for framed access.
      It MAY be used in both Access-Request and Access-Response
      messages.

      A summary of the Framed-Protocol 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Integer32                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Calhoun                  expires November 1998                 [Page 18]


INTERNET DRAFT                                                  May 1998


   Type

      7 for Framed-Protocol.

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flags

      The AVP Flags field MUST have bit one (Mandatory Support) set.

   Integer32

      The Integer32 field is four octets.

          1      PPP
          2      SLIP
          3      AppleTalk Remote Access Protocol (ARAP)
          4      Gandalf proprietary SingleLink/MultiLink protocol
          5      Xylogics proprietary IPX/SLIP


3.7  Framed-IP-Address

   Description

      This Attribute indicates the address to be configured for the
      user. It MAY be used in Access-Request messages as a hint by the
      NAS to the server that it would prefer that address, but the
      server is not required to honor the hint.

      A summary of the Framed-IP-Address 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Address                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      8 for Framed-IP-Address.



Calhoun                  expires November 1998                 [Page 19]


INTERNET DRAFT                                                  May 1998


   AVP Length

      The length of this attribute MUST be 12.

   AVP Flags

      The AVP Flags field MUST have bit one (Mandatory Support) set.

   Address

      The Address field is four octets. The value 0xFFFFFFFF indicates
      that the NAS should allow the user to select an address (e.g.
      Negotiated). The value 0xFFFFFFFE indicates that the NAS should
      select an address for the user (e.g. Assigned from a pool of
      addresses kept by the NAS). Other valid values indicate that the
      NAS should use that value as the user's IP address.


3.8  Framed-IP-Netmask

   Description

      This Attribute indicates the IP netmask to be configured for the
      user when the user is a router to a network. It MUST be used in
      Access-Response messages if the Framed-IP-Address AVP was returned
      with a value other than 0xFFFFFFFF. It MAY be used in an Access-
      Request message as a hint by the NAS to the server that it would
      prefer that netmask, but the server is not required to honor the
      hint.

      A summary of the Framed-IP-Netmask 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Address                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      9 for Framed-IP-Netmask.

   AVP Length



Calhoun                  expires November 1998                 [Page 20]


INTERNET DRAFT                                                  May 1998


      The length of this attribute MUST be 12.

   AVP Flags

      The AVP Flags field MUST have bit one (Mandatory Support) set.

   Address

      The Address field is four octets specifying the IP netmask of the
      user.


3.9  Framed-Routing

   Description

      This Attribute indicates the routing method for the user, when the
      user is a router to a network. It is only used in Access-Response
      messages.

      A summary of the Framed-Routing 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Integer32                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      10 for Framed-Routing.

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flags

      The AVP Flags field MUST have bit one (Mandatory Support) set.

   Integer32

   The Integer32 field is four octets.



Calhoun                  expires November 1998                 [Page 21]


INTERNET DRAFT                                                  May 1998


          0      None
          1      Send routing packets
          2      Listen for routing packets
          3      Send and Listen


3.10  Filter-Id

   Description

      This Attribute indicates the name of the filter list for this
      user. Zero or more Filter-Id attributes MAY be sent in an Access-
      Response message.

      Identifying a filter list by name allows the filter to be used on
      different NASes without regard to filter-list implementation
      details. However, this AVP is not roaming friendly since filter
      naming differs from one service provider to another.

      It is strongly encouraged to support the Filter-Rule AVP instead.

      A summary of the Filter-Id 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   String ...
      +-+-+-+-+-+-+-+-+

   Type

      11 for Filter-Id.

   AVP Length

      The length of this attribute MUST be at least 9.

   AVP Flags

      The AVP Flags field MUST have bit one (Mandatory Support) set.

   String




Calhoun                  expires November 1998                 [Page 22]


INTERNET DRAFT                                                  May 1998


      The String field is one or more octets, and its contents are
      implementation dependent. It is intended to be human readable and
      MUST NOT affect operation of the protocol. It is recommended that
      the message contain displayable ASCII characters from the range 32
      through 126 decimal.


3.11  Framed-MTU

   Description

      This Attribute indicates the Maximum Transmission Unit to be
      configured for the user, when it is not negotiated by some other
      means (such as PPP). It is only used in Access-Response messages.

      A summary of the Framed-MTU 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Integer32                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      12 for Framed-MTU.

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flags

      The AVP Flags field MUST have bit one (Mandatory Support) set.

   Integer32

      The Integer32 field is four octets. Despite the size of the field,
      values range from 64 to 65535.


3.12  Framed-Compression




Calhoun                  expires November 1998                 [Page 23]


INTERNET DRAFT                                                  May 1998


   Description

      This Attribute indicates a compression protocol to be used for the
      link. It MAY be used in Access-Response packets. It MAY be used in
      an Access-Request packet as a hint to the server that the NAS
      would prefer to use that compression, but the server is not
      required to honor the hint.

      More than one compression protocol Attribute MAY be sent. It is
      the responsibility of the NAS to apply the proper compression
      protocol to appropriate link traffic.

      A summary of the Framed-Compression 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Integer32                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      13 for Framed-Compression.

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flags

      The AVP Flags field MUST have bit one (Mandatory Support) set.

   Integer32

      The Integer32 field is four octets.

          0      None
          1      VJ TCP/IP header compression [7]
          2      IPX header compression


3.13  Login-IP-Host




Calhoun                  expires November 1998                 [Page 24]


INTERNET DRAFT                                                  May 1998


   Description

      This Attribute indicates the system with which to connect the
      user, when the Login-Service Attribute is included. It MAY be used
      in Access-Response messages. It MAY be used in an Access-Request
      message as a hint to the server that the NAS would prefer to use
      that host, but the server is not required to honor the hint.

      A summary of the Login-IP-Host 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Address                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      14 for Login-IP-Host.

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flags

      The AVP Flags field MUST have bit one (Mandatory Support) set.

   Address

      The Address field is four octets. The value 0xFFFFFFFF indicates
      that the NAS SHOULD allow the user to select an address. The value
      zero indicates that the NAS SHOULD select a host to connect the
      user to. Other values indicate the address the NAS SHOULD connect
      the user to.


3.14  Login-Service

   Description

      This Attribute indicates the service which should be used to
      connect the user to the login host. It is only used in Access-



Calhoun                  expires November 1998                 [Page 25]


INTERNET DRAFT                                                  May 1998


      Response messages.

      A summary of the Login-Service 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Integer32                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      15 for Login-Service.

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flags

      The AVP Flags field MUST have bit one (Mandatory Support) set.

   Integer32

      The Integer32 field is four octets.

          0      Telnet
          1      Rlogin
          2      TCP Clear
          3      PortMaster (proprietary)
          4      LAT


3.15  Login-TCP-Port

   Description

      This Attribute indicates the TCP port with which the user is to be
      connected, when the Login-Service Attribute is also present. It is
      only used in Access-Response packets.

      A summary of the Login-TCP-Port Attribute format is shown below.
      The fields are transmitted from left to right.



Calhoun                  expires November 1998                 [Page 26]


INTERNET DRAFT                                                  May 1998


      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Integer32                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      16 for Login-TCP-Port.

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flags

      The AVP Flags field MUST have bit one (Mandatory Support) set.

   Integer32

      The Integer32 field is four octets. Despite the size of the field,
      values range from zero to 65535.


3.16  Reply-Message

   Description

      This Attribute indicates text which MAY be displayed to the user.

      When used in an Access-Response message with a successful Result-
      Code AVP it indicates the success message. When found in the same
      message with a Result-Code other than DIAMETER-SUCCESS it contains
      the failure message.

      It MAY indicate a dialog message to prompt the user before another
      Access-Request attempt.

      When used in an Access-Challenge, it MAY indicate a dialog message
      to prompt the user for a response.

      Multiple Reply-Message's MAY be included and if any are displayed,
      they MUST be displayed in the same order as they appear in the
      packet.



Calhoun                  expires November 1998                 [Page 27]


INTERNET DRAFT                                                  May 1998


      A summary of the Reply-Message 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   String ...
      +-+-+-+-+-+-+-+-+

   Type

      18 for Reply-Message.

   AVP Length

      The length of this attribute MUST be at least 9.

   AVP Flags

      The AVP Flags field MUST have bit one (Mandatory Support) set.

   String

      The String field is one or more octets, and its contents are
      implementation dependent. It is intended to be human readable, and
      MUST NOT affect operation of the protocol. It is recommended that
      the message contain displayable ASCII characters from the range
      10, 13, and 32 through 126 decimal. Mechanisms for extension to
      other character sets are beyond the scope of this specification.


3.17  Callback-Number

   Description

      This Attribute indicates a dialing string to be used for callback.
      It MAY be used in Access-Response packets. It MAY be used in an
      Access-Request packet as a hint to the server that a Callback
      service is desired, but the server is not required to honor the
      hint.

      A summary of the Callback-Number Attribute format is shown below.
      The fields are transmitted from left to right.




Calhoun                  expires November 1998                 [Page 28]


INTERNET DRAFT                                                  May 1998


      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   String ...
      +-+-+-+-+-+-+-+-+

   Type

      19 for Callback-Number.

   AVP Length

      The length of this attribute MUST be at least 9.

   AVP Flags

      The AVP Flags field MUST have bit one (Mandatory Support) set.

   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.


3.18  Callback-Id

   Description

      This Attribute indicates the name of a place to be called, to be
      interpreted by the NAS. It MAY be used in Access-Response
      messages.

      This AVP is not roaming friendly since it assumes that the
      Callback-Id is configured on the NAS. It is therefore preferable
      to use the Callback-Number AVP instead.

      A summary of the Callback-Id Attribute format is shown below. The
      fields are transmitted from left to right.

      0                   1                   2                   3



Calhoun                  expires November 1998                 [Page 29]


INTERNET DRAFT                                                  May 1998


      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   String ...
      +-+-+-+-+-+-+-+-+

   Type

      20 for Callback-Id.

   AVP Length

      The length of this attribute MUST be at least 9.

   AVP Flags

      The AVP Flags field MUST have bit one (Mandatory Support) set.

   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.


3.19  Framed-IP-Route

   Description

      This Attribute provides routing information to be configured for
      the user on the NAS. It is used in the Access-Response message and
      can appear multiple times.

      A summary of the Framed-Route 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Calhoun                  expires November 1998                 [Page 30]


INTERNET DRAFT                                                  May 1998


      |   String ...
      +-+-+-+-+-+-+-+-+

   Type

      22 for Framed-IP-Route.

   AVP Length

      The length of this attribute MUST be at least 9.

   AVP Flags

      The AVP Flags field MUST have bit one (Mandatory Support) set.

   String

      It MUST contain a destination prefix in dotted quad form
      optionally followed by a slash and a decimal length specifier
      stating how many high order bits of the prefix should be used.
      That is followed by a space, a gateway address in dotted quad
      form, a space, and one or more metrics separated by spaces. For
      example, "192.168.1.0/24 192.168.1.1 1".

      The length specifier may be omitted in which case it should
      default to 8 bits for class A prefixes, 16 bits for class B
      prefixes, and 24 bits for class C prefixes. For example,
      "192.168.1.0 192.168.1.1 1".

      Whenever the gateway address is specified as "0.0.0.0" the IP
      address of the user SHOULD be used as the gateway address.


3.20  Framed-IPX-Network

   Description

      This Attribute indicates the IPX Network number to be configured
      for the user. It is used in Access-Response messages.

      A summary of the Framed-IPX-Network 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |



Calhoun                  expires November 1998                 [Page 31]


INTERNET DRAFT                                                  May 1998


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Integer32                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      23 for Framed-IPX-Network.

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flags

      The AVP Flags field MUST have bit one (Mandatory Support) set.

   Integer32

      The Integer32 field is four octets. The value 0xFFFFFFFF indicates
      that the NAS should allow the user to select an address (e.g.
      Negotiated). The value 0xFFFFFFFE indicates that the NAS should
      select an address for the user (e.g. assigned from a pool of one
      or more IPX networks kept by the NAS). Other values should be used
      as the IPX network for the link to the user.

3.21  State

   Description

      This Attribute is available to be sent by the server to the client
      in an Access-Challenge and MUST be sent unmodified from the client
      to the server in the new Access-Request reply to that challenge,
      if any.

      In either usage, no interpretation by the client should be made.
      A packet may have only one State Attribute. Usage of the State
      Attribute is implementation dependent.

      A summary of the State 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Calhoun                  expires November 1998                 [Page 32]


INTERNET DRAFT                                                  May 1998


      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Data ...
      +-+-+-+-+-+-+-+-+

   Type

      24 for State.

   AVP Length

      The length of this attribute MUST be at least 9.

   AVP Flags

      The AVP Flags field MUST have bit one (Mandatory Support) set.

   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.


3.22  Class

   Description

      This Attribute is available to be sent by the server to the client
      in an Access-Response and should be sent unmodified by the client
      to the accounting server as part of the Accounting-Request message
      if accounting is supported. No interpretation by the client should
      be made.

      A summary of the Class 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Data ...



Calhoun                  expires November 1998                 [Page 33]


INTERNET DRAFT                                                  May 1998


      +-+-+-+-+-+-+-+-+

   Type

      25 for Class.

   AVP Length

      The length of this attribute MUST be at least 9.

   AVP Flags

      The AVP Flags field MUST have bit one (Mandatory Support) set.

   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.


3.23  Vendor-Specific

   Description

      This AVP is not supported in DIAMETER. Vendor Specific Attributes
      are used by enabling the Vendor-Specific bit in the AVP header.


3.24  Session-Timeout

   Description

      This Attribute sets the maximum number of seconds of service to be
      provided to the user before termination of the session or prompt.
      This Attribute is available to be sent by the server to the client
      in an Access-Response or Access-Challenge.

      A summary of the Session-Timeout 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |



Calhoun                  expires November 1998                 [Page 34]


INTERNET DRAFT                                                  May 1998


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Integer32                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      27 for Session-Timeout.

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flags

      The AVP Flags field MUST have bit one (Mandatory Support) set.

   Integer32

      The Integer32 field is 4 octets, containing a 32-bit unsigned
      integer with the maximum number of seconds this user should be
      allowed to remain connected by the NAS.

      A value of zero means that this session has an unlimited number of
      seconds before termination or prompt.

3.25  Idle-Timeout

   Description

      This Attribute sets the maximum number of consecutive seconds of
      idle connection allowed to the user before termination of the
      session or prompt. This Attribute is available to be sent by the
      server to the client in an Access-Response or Access-Challenge.

      A summary of the Idle-Timeout 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Integer32                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Calhoun                  expires November 1998                 [Page 35]


INTERNET DRAFT                                                  May 1998


   Type

      28 for Idle-Timeout.

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flags

      The AVP Flags field MUST have bit one (Mandatory Support) set.

   Integer32

      The Integer32 field is 4 octets, containing a 32-bit unsigned
      integer with the maximum number of consecutive seconds of idle
      time this user should be permitted before being disconnected by
      the NAS.


3.26. Termination-Action

   Description

      This Attribute is not supported in DIAMETER.


3.27  Called-Station-Id

   Description

      This Attribute allows the NAS to send in the Access-Request
      message the phone number that the user called, using Dialed Number
      Identification (DNIS) or similar technology. Note that this may be
      different from the phone number the call comes in on. It is only
      used in Access-Request packets.

      If the Authorization-Only flag is set in the message and the
      User-Name AVP is absent, the DIAMETER Server MUST perform
      authorization based on this field. This can be used by a NAS to
      request whether a call should be answered based on the DNIS.

      A summary of the Called-Station-Id 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Calhoun                  expires November 1998                 [Page 36]


INTERNET DRAFT                                                  May 1998


      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   String ...
      +-+-+-+-+-+-+-+-+

   Type

      30 for Called-Station-Id.

   AVP Length

      The length of this attribute MUST be at least 9.

   AVP Flags

      The AVP Flags field MUST have bit one (Mandatory Support) set.

   String

      The String field is one or more octets, containing the phone
      number that the user's call came in on.

      The actual format of the information is site or application
      specific. Printable ASCII is recommended, but 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.


3.28  Calling-Station-Id

   Description

      This Attribute allows the NAS to send in the Access-Request packet
      the phone number that the call came from, using Automatic Number
      Identification (ANI) or similar technology. It is only used in
      Access-Request packets.

      If the Authorization-Only flag is set in the message and the
      User-Name AVP is absent, the DIAMETER Server must perform
      authorization based on this field. This can be used by a NAS to
      request whether a call should be answered based on the ANI.

      A summary of the Calling-Station-Id Attribute format is shown
      below.  The fields are transmitted from left to right.



Calhoun                  expires November 1998                 [Page 37]


INTERNET DRAFT                                                  May 1998


      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   String ...
      +-+-+-+-+-+-+-+-+

   Type

      31 for Calling-Station-Id.

   AVP Length

      The length of this attribute MUST be at least 9.

   AVP Flags

      The AVP Flags field MUST have bit one (Mandatory Support) set.

   String

      The String field is one or more octets, containing the phone
      number that the user placed the call from.

      The actual format of the information is site or application
      specific. Printable ASCII is recommended, but 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.


3.29  Proxy-State

   Description

      This Attribute is available to be sent by a proxy server to
      another server when forwarding an Access-Request and MUST be
      returned unmodified in the Access-Response, or Access-Challenge.

      This attribute should be removed by the proxy server before the
      response is forwarded to the NAS, and SHOULD therefore not be
      protected by the Integrity-Check-Vector or the Digital-Signature.

      A summary of the Proxy-State Attribute format is shown below. The



Calhoun                  expires November 1998                 [Page 38]


INTERNET DRAFT                                                  May 1998


      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Data ...
      +-+-+-+-+-+-+-+-+

   Type

      33 for Proxy-State.

   AVP Length

      The length of this attribute MUST be at least 9.

   AVP Flags

      The AVP Flags field MUST have bit one (Mandatory Support) set.

   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.


3.30  Login-LAT-Service

   Description

      This Attribute indicates the system with which the user is to be
      connected by LAT. It MAY be used in Access-Response packets, but
      only when LAT is specified as the Login-Service. It MAY be used in
      an Access-Request packet as a hint to the server, but the server
      is not required to honor the hint.

      Administrators use the service attribute when dealing with
      clustered systems, such as a VAX or Alpha cluster. In such an
      environment several different time sharing hosts share the same
      resources (disks, printers, etc.), and administrators often



Calhoun                  expires November 1998                 [Page 39]


INTERNET DRAFT                                                  May 1998


      configure each to offer access (service) to each of the shared
      resources. In this case, each host in the cluster advertises its
      services through LAT broadcasts.

      Sophisticated users often know which service providers (machines)
      are faster and tend to use a node name when initiating a LAT
      connection. Alternately, some administrators want particular users
      to use certain machines as a primitive form of load balancing
      (although LAT knows how to do load balancing itself).

      A summary of the Login-LAT-Service 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   String ...
      +-+-+-+-+-+-+-+-+

   Type

      34 for Login-LAT-Service.

   AVP Length

      The length of this attribute MUST be at least 9.

   AVP Flags

      The AVP Flags field MUST have bit one (Mandatory Support) set.

   String

      The String field is one or more octets, and contains the identity
      of the LAT service to use. The LAT Architecture allows this string
      to contain $ (dollar), - (hyphen), . (period), _ (underscore),
      numerics, upper and lower case alphabetics, and the ISO Latin-1
      character set extension [8]. All LAT string comparisons are case
      insensitive.


3.31  Login-LAT-Node

   Description



Calhoun                  expires November 1998                 [Page 40]


INTERNET DRAFT                                                  May 1998


      This Attribute indicates the Node with which the user is to be
      automatically connected by LAT. It MAY be used in Access-Response
      packets, but only when LAT is specified as the Login-Service. It
      MAY be used in an Access-Request packet as a hint to the server,
      but the server is not required to honor the hint.

      A summary of the Login-LAT-Node 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   String ...
      +-+-+-+-+-+-+-+-+

   Type

      35 for Login-LAT-Node.

   AVP Length

      The length of this attribute MUST be at least 9.

   AVP Flags

      The AVP Flags field MUST have bit one (Mandatory Support) set.

   String

      The String field is one or more octets, and contains the identity
      of the LAT Node to connect the user to. The LAT Architecture
      allows this string to contain $ (dollar), - (hyphen), . (period),
      _ (underscore), numerics, upper and lower case alphabetics, and
      the ISO Latin-1 character set extension. All LAT string
      comparisons are case insensitive.


3.32  Login-LAT-Group

   Description

      This Attribute contains a string identifying the LAT group codes
      which this user is authorized to use. It MAY be used in Access-
      Response packets, but only when LAT is specified as the Login-



Calhoun                  expires November 1998                 [Page 41]


INTERNET DRAFT                                                  May 1998


      Service. It MAY be used in an Access-Request packet as a hint to
      the server, but the server is not required to honor the hint.

      LAT supports 256 different group codes, which LAT uses as a form
      of access rights. LAT encodes the group codes as a 256 bit bitmap.

      Administrators can assign one or more of the group code bits at
      the LAT service provider; it will only accept LAT connections that
      have these group codes set in the bit map. The administrators
      assign a bitmap of authorized group codes to each user; LAT gets
      these from the operating system, and uses these in its requests to
      the service providers.

      A summary of the Login-LAT-Group 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Data ...
      +-+-+-+-+-+-+-+-+

   Type

      36 for Login-LAT-Group.

   AVP Length

      The length of this attribute MUST be 40.

   AVP Flags

      The AVP Flags field MUST have bit one (Mandatory Support) set.

   Data

      The Data field is a 32 octet bit map, most significant octet
      first. 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.





Calhoun                  expires November 1998                 [Page 42]


INTERNET DRAFT                                                  May 1998


3.33  Framed-AppleTalk-Link

   Description

      This Attribute indicates the AppleTalk network number which should
      be used for the serial link to the user, which is another
      AppleTalk router. It is only used in Access-Response packets. It
      is never used when the user is not another router.

      A summary of the Framed-AppleTalk-Link 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Integer32                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      37 for Framed-AppleTalk-Link.

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flags

      The AVP Flags field MUST have bit one (Mandatory Support) set.

   Integer32

      The Integer32 field is four octets. Despite the size of the field,
      values range from zero to 65535. The special value of zero
      indicates that this is an unnumbered serial link. A value of one
      to 65535 means that the serial line between the NAS and the user
      should be assigned that value as an AppleTalk network number.


3.34  Framed-AppleTalk-Network

   Description

      This Attribute indicates the AppleTalk Network number which the



Calhoun                  expires November 1998                 [Page 43]


INTERNET DRAFT                                                  May 1998


      NAS should probe to allocate an AppleTalk node for the user. It is
      only used in Access-Response packets. It is never used when the
      user is another router. Multiple instances of this Attribute
      indicate that the NAS may probe using any of the network numbers
      specified.

      A summary of the Framed-AppleTalk-Network 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Integer32                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      38 for Framed-AppleTalk-Network.

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flags

      The AVP Flags field MUST have bit one (Mandatory Support) set.

   Integer32

      The Integer32 field is four octets. Despite the size of the field,
      values range from zero to 65535. The special value zero indicates
      that the NAS should assign a network for the user, using its
      default cable range. A value between one and 65535 (inclusive)
      indicates the AppleTalk Network the NAS should probe to find an
      address for the user.


3.35  Framed-AppleTalk-Zone

   Description

      This Attribute indicates the AppleTalk Default Zone to be used for
      this user. It is only used in Access-Response packets. Multiple
      instances of this attribute in the same packet are not allowed.



Calhoun                  expires November 1998                 [Page 44]


INTERNET DRAFT                                                  May 1998


      A summary of the Framed-AppleTalk-Zone 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Data ...
      +-+-+-+-+-+-+-+-+

   Type

      39 for Framed-AppleTalk-Zone.

   AVP Length

      The length of this attribute MUST be at least 9.

   AVP Flags

      The AVP Flags field MUST have bit one (Mandatory Support) set.

   String

      The name of the Default AppleTalk Zone to be used for this user.
      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.


3.36  CHAP-Challenge

   Description

      This Attribute contains the CHAP Challenge sent by the NAS to a
      PPP Challenge-Handshake Authentication Protocol (CHAP) user. It is
      only used in Access-Request packets.

      A summary of the CHAP-Challenge 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



Calhoun                  expires November 1998                 [Page 45]


INTERNET DRAFT                                                  May 1998


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Data ...
      +-+-+-+-+-+-+-+-+

   Type

      60 for CHAP-Challenge.

   AVP Length

      The length of this attribute MUST be at least 24.

   AVP Flags

      The AVP Flags field MUST have bit one (Mandatory Support) set.

   Data

      The Data field contains the CHAP Challenge.


3.37  NAS-Port-Type

   Description

      This Attribute indicates the type of the physical port of the NAS
      which is authenticating the user. It can be used instead of or in
      addition to the NAS-Port (5) attribute. It is only used in
      Access-Request packets. Either NAS-Port (5) or NAS-Port-Type or
      both SHOULD be present in an Access-Request packet, if the NAS
      differentiates among its ports.

      A summary of the NAS-Port-Type 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Integer32                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Calhoun                  expires November 1998                 [Page 46]


INTERNET DRAFT                                                  May 1998


   Type

      61 for NAS-Port-Type.

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flags

      The AVP Flags field MUST have bit one (Mandatory Support) set.

   Integer32

      The Integer32 field is four octets. "Virtual" refers to a
      connection to the NAS via some transport protocol, instead of
      through a physical port. For example, if a user telnetted into a
      NAS to authenticate himself as an Outbound-User, the Access-
      Request might include NAS-Port-Type = Virtual as a hint to the
      RADIUS server that the user was not on a physical port.

          0       Async
          1       Sync
          2       ISDN Sync
          3       ISDN Async V.120
          4       ISDN Async V.110
          5       Virtual


3.38  Port-Limit

   Description

      This Attribute sets the maximum number of ports to be provided to
      the user by the NAS. This Attribute MAY be sent by the server to
      the client in an Access-Response packet. It is intended for use in
      conjunction with Multilink PPP [9] or similar uses. It MAY also be
      sent by the NAS to the server as a hint that that many ports are
      desired for use, but the server is not required to honor the hint.

      A summary of the Port-Limit 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Calhoun                  expires November 1998                 [Page 47]


INTERNET DRAFT                                                  May 1998


      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Integer32                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      62 for Port-Limit.

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flags

      The AVP Flags field MUST have bit one (Mandatory Support) set.

   Integer32

      The Integer32 field is four octets, containing a 32-bit unsigned
      integer with the maximum number of ports this user should be
      allowed to connect to on the NAS.


3.39  Login-LAT-Port

   Description

      This Attribute indicates the Port with which the user is to be
      connected by LAT. It MAY be used in Access-Response packets, but
      only when LAT is specified as the Login-Service. It MAY be used in
      an Access-Request packet as a hint to the server, but the server
      is not required to honor the hint.

      A summary of the Login-LAT-Port 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   String ...
      +-+-+-+-+-+-+-+-+

   Type



Calhoun                  expires November 1998                 [Page 48]


INTERNET DRAFT                                                  May 1998


      63 for Login-LAT-Port.

   AVP Length

      The length of this attribute MUST be at least 9.

   AVP Flags

      The AVP Flags field MUST have bit one (Mandatory Support) set.

   String

      The String field is one or more octets, and contains the identity
      of the LAT port to use. The LAT Architecture allows this string to
      contain $ (dollar), - (hyphen), . (period), _ (underscore),
      numerics, upper and lower case alphabetics, and the ISO Latin-1
      character set extension. All LAT string comparisons are case
      insensitive.


3.40  Filter-Rule

   Description

      This Attribute provides filter rules that need to be configured on
      the NAS for the user. It is used in the Access-Response message
      and can appear multiple times.

      A summary of the Filter-Rule 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   String ...
      +-+-+-+-+-+-+-+-+

   Type

      280 for Filter-Rule.

   AVP Length

      The length of this attribute MUST be at least 9.



Calhoun                  expires November 1998                 [Page 49]


INTERNET DRAFT                                                  May 1998


   AVP Flags

      The AVP Flags field MUST have bit one (Mandatory Support) set.

   String

      The String field MUST contain a filter rule in the following
      format:  "permit (offset=value AND offset=value) OR offset=value"
      or "deny (offset=value AND offset=value) OR offset=value".


3.41  Framed-Password-Policy

   Description

      This Attribute is used to indicate to a peer what types of
      authentication are supported by the issuing DIAMETER peer. More
      than one Framed-Password-Policy AVP MAY be present in the Domain-
      Discovery-Response message.

      A summary of the User-Name 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Integer32                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      281 for Framed-Password-Policy.

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flags

      The AVP Flags field MUST have bit one (Mandatory Support) set.

   Integer32

      The Integer32 field contains the supported authentication schemes



Calhoun                  expires November 1998                 [Page 50]


INTERNET DRAFT                                                  May 1998


      supported. The following values are supported:

         PAP         1
         CHAP        2
         MS-CHAP     3
         EAP         4
         SPAP        5


3.42  Table of Attributes

   The following table provides a guide to which attributes may be found
   in which kinds of packets, and in what quantity.

      Req  Succ  Fail  Chal  Disc-Req Disc-Rsp #    Attribute
      0-1  0-1   0     0     1        0-1       1   User-Name
      0-1  0     0     0     0        0         2   User-Password [*1]
      0-1  0     0     0     0        0         3   CHAP-Password [*1]
      0-1  0     0     0     0        0         4   NAS-IP-Address
      0-1  0     0     0     0        0         5   NAS-Port
      0-1  0-1   0     0     0        0         6   Service-Type
      0-1  0-1   0     0     0        0         7   Framed-Protocol
      0-1  0-1   0     0     0        0         8   Framed-IP-Address
      0-1  0-1   0     0     0        0         9   Framed-IP-Netmask
      0    0-1   0     0     0        0        10   Framed-Routing
      0    0+    0     0     0        0        11   Filter-Id
      0    0-1   0     0     0        0        12   Framed-MTU
      0+   0+    0     0     0        0        13   Framed-Compression
      0+   0+    0     0     0        0        14   Login-IP-Host
      0    0-1   0     0     0        0        15   Login-Service
      0    0-1   0     0     0        0        16   Login-TCP-Port
      0    0+    0+    0+    0        0        18   Reply-Message
      0-1  0-1   0     0     0        0        19   Callback-Number
      0    0-1   0     0     0        0        20   Callback-Id
      0    0+    0     0     0        0        22   Framed-Route
      0    0-1   0     0     0        0        23   Framed-IPX-Network
      0-1  0-1   0     0-1   0        0        24   State
      0    0+    0     0     0        0        25   Class
      0    0-1   0     0-1   0-1      0-1      27   Session-Timeout
      0    0-1   0     0-1   0-1      0-1      28   Idle-Timeout
      0    0-1   0     0     0        0        29   Termination-Action
      0-1  0     0     0     0        0        30   Called-Station-Id
      0-1  0     0     0     0        0        31   Calling-Station-Id
      0-1  0     0     0     0        0        32   NAS-Identifier
      0+   0+    0+    0+    0+       0+       33   Proxy-State
      0-1  0-1   0     0     0        0        34   Login-LAT-Service
      0-1  0-1   0     0     0        0        35   Login-LAT-Node
      0-1  0-1   0     0     0        0        36   Login-LAT-Group



Calhoun                  expires November 1998                 [Page 51]


INTERNET DRAFT                                                  May 1998


      0    0-1   0     0     0        0        37   Framed-AppleTalk-Link
      0    0+    0     0     0        0        38   Framed-AppleTalk-Net.
      0    0-1   0     0     0        0        39   Framed-AppleTalk-Zone
      0-1  0     0     0     0        0        60   CHAP-Challenge
      0-1  0     0     0     0        0        61   NAS-Port-Type
      0-1  0-1   0     0     0        0        62   Port-Limit
      0-1  0-1   0     0     0        0        63   Login-LAT-Port
      0    0+    0     0     0        0        280  Filter-Rule
      0    0     0     0     0+       0+       281  Framed-Password-Pol.
      Req  Succ  Fail  Chal  Disc-Req Disc-Rsp #    Attribute

      [*1] An Access-Request MUST NOT contain both a User-Password and a
      CHAP-Password AVP.

      The following table defines the meaning of the above table
      entries.

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


4.0  Protocol Definition

   This section will outline how the DIAMETER Authentication Extension
   can be used.

4.1  Authorization Procedure

   This specification allows two different types of Authorization
   procedures.  The first method is identical to the way RADIUS works
   today and requires the Access-Request to contain the UserName as well
   as either the Password or the CHAP-Password AVPs.

   The second method is used by NASes that send Access-Request whenever
   they receive an incoming call and want to get authorization from the
   DIAMETER Server to answer the call. In this case the Access-Request
   contains the NAS-IP-Address, the Calling-Station-Id and the Called-
   Station-Id AVPs.

   In this case the DIAMETER Server can lookup the combination of the
   Calling-Station-Id and the Called-Station-Id in order to ensure that
   the pair are authorized as per the local policy.



Calhoun                  expires November 1998                 [Page 52]


INTERNET DRAFT                                                  May 1998


4.2  Integration with Resource-Management

   Document [10] specifies the Resource-Token AVP that is used to carry
   information required for a DIAMETER server to rebuild its state
   information in the event of a crash or some other event that would
   cause the server to loose its state information.

   When creating the Resource-Token AVP, the following AVPs MUST be
   present, in addition to the AVPs listed in [10]; the UserName AVP,
   the NAS-IP- Address, the NAS-Port. Any additional AVP MAY be included
   if the AVP is a resource that is being managed (i.e. Framed-IP-
   Address in the case where the DIAMETER Server is allocating IP
   Addresses out of a centrally managed address pool).


4.3  RADIUS Proxies

   In today's dial up networks the RADIUS protocol is used to
   authentication, authorize and perform accounting for dial-up users.
   However, it has become common practice to make use of RADIUS Servers
   known as proxies.

   The use of proxies has become widespread especially with the
   popularity of Internet Roaming[4]. In this example a user has a
   single user account with a local service provider. When this user
   roams outside of the ISP's service area, it is possible for the user
   to connect to another service provider (see [4] for more detail).

   In this scenario, the new service provider (ISPB) provides internet
   access for the user through a NAS (NASB). ISPB owns an authentication
   server (RADB), which proxies the authentication request to the user's
   original provider's authentication server (RADA).

                (Access-Request)           (Access-Request)
      +------+       ----->       +------+      ------>       +------+
      |      |                    |      |                    |      |
      | NASB +--------------------+ RADB +--------------------+ RADA |
      |      |                    |      |                    |      |
      +------+       <-----       +------+      <------       +------+
                 (Access-Accept)            (Access-Accept)

   The example shown above NASB generates an authentication request on
   behalf of the dial-in user to the RADB Authentication server. In this
   case, the user's identity would include a domain identifier [3] that
   would enable RADB to identify the authentication server (i.e.
   user@ISPA.com).

   The RADB server then forwards the request to RADA which authenticates



Calhoun                  expires November 1998                 [Page 53]


INTERNET DRAFT                                                  May 1998


   the user based on information found within the request. If
   successfully authenticated the RADA server returns a successful
   response along with authorization information. If the user
   authentication fails RADA replies with a failed response.

   In the past this model has caused much concern over it's security
   implication.  The model is much worse in the when there exists an
   intermediate provider between ISPB and ISPA (say ISPC). The following
   diagram depicts such an example where RADB must forward any requests
   for RADA through RADC.

              (Accounting-Request)        (Accounting-Request)
      +------+       ----->       +------+      ------>       +------+
      |      |                    |      |                    |      |
      | RADB +--------------------+ RADC +--------------------+ RADA |
      |      |                    |      |                    |      |
      +------+       <-----       +------+      <------       +------+
              (Accounting-Response)       (Accounting-Response)

   The problem with the above scenario is that complete trust is placed
   in RADC (and hence ISPC) since it is very simple to modify any
   attributes found within the request or the response. The example
   shows an accounting request sent from RADB to RADA through RADC. The
   following is a list of a few attacks which can be generated by a
   malicious proxy:

      - Generating Accounting Records by replaying old
      authentication/accounting records. In this example it is very
      simple for RADC to simple retain old packets and replay then at a
      later date. This will cause RADA to "pay" for services which were
      never rendered.

      - Modify Attributes within the request or response. In this case
      RADC can modify attributes, such as the length of the call, that
      would fool RADA into believing the call was longer than in
      reality.

      - Stealing PAP Passwords is another problem with today's proxies.
      In the current model PAP passwords are encrypted using a shared
      secret which is shared between each hop in the proxy chain. In
      this case each hop has the opportunity to decrypt, and possibly
      save for future use, the user's password.

   Given the problems identified above with the current proxy model it
   is necessary to create a mechanism which allows for non-repudiation,
   end-to-end data integrity as well as end-to-end encryption. Given the
   current encryption technology this can only be achieved with the use
   of asymetric encryption and digital signatures.



Calhoun                  expires November 1998                 [Page 54]


INTERNET DRAFT                                                  May 1998


4.4  DIAMETER Proxies

   The DIAMETER protocol also makes use of proxies in order to keep the
   existing arrangements while migrating from RADIUS to DIAMETER.
   However since DIAMETER makes use of asymetric encryption and digital
   signatures it solves many of the problems shown above.

                (Access-Request)           (Access-Request)
      +------+       ----->       +------+      ------>       +------+
      |      |                    |      |                    |      |
      | NASB +--------------------+ DIA2 +--------------------+ DIA1 |
      |      |                    |      |                    |      |
      +------+       <-----       +------+      <------       +------+
               (Access-Response)           (Access-Response)

   In this example NASB generates an Access-Request that is forwarded to
   DIA2. The Access-Request contains a digital signature AVP which
   "protects" all mandatory (or non-editable) AVPs within the request.
   All AVPs which may be modified, or removed appear after the digital
   signature AVP. Once DIA2 receives the request, it MAY authenticate
   the request to ensure that it was originated by NASB (verifying the
   signature is not necessary if the link between NASB and DIA2 is
   secured using IPSEC).

   The DIA2 Server may then add new attributes to the request. All
   mandatory AVPs MUST be present prior to the non mandatory AVPs and
   MUST be preceeded by a Digital Signature AVP (using DIA2's private
   key). Note that all non-mandatory AVPs added to the packet by NASB
   must appear after DIA2's digital signature AVP. The message is then
   forwarded towards the DIA1 server.

   Since all packets between NASB and DIA1 must flow through DIA2, it is
   not possible to use IPSEC between both hosts. Therefore DIA1 MUST
   validate NASB's digital signature AVP. However it is not necessary to
   validate DIA2's digital signature if the link between DIA2 and DIA1
   is secured using IPSEC.

   This mechanism now provides a method for DIA1 to prove that NASB was
   the initiator of the request (note that DIAMETER also includes a
   timestap to prevent replay attacks). It also provides a method of
   ensuring that DIA2 cannot modify any "non-editable" attributes (such
   as length of call, etc).

   In addition, this same mechanism can be used for end-to-end
   encryption of AVPs. In the case where NASB needs to encrypt an AVP it
   is done using asymetric encryption using DIA1's public key. This
   ensures that only DIA1 can decrypt the AVP.




Calhoun                  expires November 1998                 [Page 55]


INTERNET DRAFT                                                  May 1998


   An attack has been identified in this proposal which allows a
   malicous man in the middle attack as shown in the following diagram.

           (Access-Request)  (Access-Request)  (Access-Request)
      +------+  ----->  +------+  ----->  +------+  ----->  +------+
      |      |          |      |          |      |          |      |
      | NASB +----------+ DIA2 +----------+ DIA3 +----------+ DIA1 |
      |      |          |      |          |      |          |      |
      +------+  <-----  +------+  <-----  +------+  <-----  +------+
           (Access-Response) (Access-Response) (Access-Response)

   In this example, DIA3 traps packets generated from DIA2 towards DIA1,
   removes the AVPs added by DIA2 and inserts its own AVPs (posibly by
   trying to convince DIA1 to pay DIA3 for the services). This attack
   can be prevented by supporting a new Next-Hop AVP. In this case when
   NASB prepares a request it inserts a non-editable Next-Hop AVP which
   contains DIA2's identitity. DIA2 also adds a Next-Hop AVP with DIA1
   as the next hop.

   This mechanism ensures that a man in the middle cannot alter the
   packet by overriding the previous hop's additions and signature. DIA1
   could easily validate the packet's path with the use of the Next-Hop
   AVPs.


4.5  Domain Discovery

   The Domain Discovery message set is very useful in determining the
   Home authentication server, the password policies for the domain, as
   a mechanism to retrieve a certificate (or a pointer to a
   certificate).

   The following example shows a case where DIA1 needs to communicate
   with DIA3. In this example it is necessary to use DIA2 as a proxy in
   order for both ISPs to communicate. Although this MAY be desireable
   in some business models, there are cases where it is beneficial to
   remove the proxy altogether and allow both DIA3 and DIA1 to
   communicate in a secure fashion.

                  (DD-Request)               (DD-Request)
      +------+       ----->       +------+      ------>       +------+
      |      |                    |      |                    |      |
      | DIA1 +--------------------+ DIA2 +--------------------+ DIA3 |
      |      |                    |      |                    |      |
      +------+       <-----       +------+      <------       +------+
                  (DD-Response)              (DD-Response)

   The way the Domain Discovery works is that prior to sending out an



Calhoun                  expires November 1998                 [Page 56]


INTERNET DRAFT                                                  May 1998


   authentication request DIA1 would issue a Domain Discovery message
   towards DIA2. This message is protected with the digital signature as
   well as the Next-Hop AVP. DIA2 would then forward the request to DIA3
   including the Next-Hop and the digital signature AVP.

   When DIA3 receives the request, it MUST save the certificate (or the
   pointer to the certificate) and respond back including the local
   password policy, DIA3's certificate, it's contact information (i.e.
   IP address) and protect the response with the digital signature.

   Note that in all cases the TimeStamp AVP is also present to ensure no
   reply packets are accepted.

   When DIA2 receives the packet, it must add the Next-Hop AVP as well
   as the digital signature AVP. When DIA1 receives the packet it then
   knows a direct route to communicate with DIA3 since the contact
   information is present in the response. The fact that both DIA1 and
   DIA3 can now communicate directly allows both peers to use IPSEC to
   protect the message exchange (note that it MAY be desirable to also
   use the digital signature in order to keep the information in the
   DIAMETER logs).

                                    (Access-Request)
                     +------+       ----->       +------+
                     |      |                    |      |
                     | DIA1 +--------------------+ DIA3 |
                     |      |                    |      |
                     +------+       <-----       +------+
                                   (Access-Response)

     In addition, the password policy is also present which can indicate
     whether DIA3 is willing to accept CHAP, PAP or EAP authentication.

     Note that the Domain-Request/Response MAY include the Supported-
     Extension AVPs [2].


5.0  References

    [1] Rigney, et alia, "RADIUS", RFC-2138, Livingston, April 1997

    [2] Calhoun, Rubens, "DIAMETER Base Protocol", Internet-Draft,
        draft-calhoun-diameter-03.txt, May 1998.

    [3] Aboba, Beadles, "Network Address Identifier", Internet-
        Draft, draft-ietf-roamops-nai-10.txt, February 1998.

    [4] Aboba, Zorn, "Dialup Roaming Requirements", Internet-Draft,



Calhoun                  expires November 1998                 [Page 57]


INTERNET DRAFT                                                  May 1998


        July 1997.

    [5] Calhoun, Rubens, Aboba, "DIAMETER Extensible Authentication
        Protocol Extensions", Internet-Draft, draft-calhoun-
        diameter-eap-01.txt, March 1998.

    [6] Calhoun, Haag, Zorn, "EAP Authentication for SOCKS
        Version 5", draft-ietf-aft-socks-eap-00.txt, March 1998.

    [7] Jacobson, "Compressing TCP/IP headers for low-speed serial
        links", RFC 1144, February 1990.

    [8] ISO 8859. International Standard -- Information Processing --
        8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin
        Alphabet No. 1, ISO 8859-1:1987.
        <URL:http://www.iso.ch/cate/d16338.html>

    [9] Sklower, Lloyd, McGregor, Carr, "The PPP Multilink Protocol
        (MP)", RFC 1717, November 1994.

    [10] Calhoun, Greene, "DIAMETER Resource Management Extension",
         Internet-Draft, draft-calhoun-diameter-res-mgmt-01.txt,
         May 1998.

    [11] Calhoun, Zorn, Pan, "DIAMETER Framework", Internet-
         Draft, draft-calhoun-diameter-framework-00.txt, May 1998


6.0  Acknowledgements

   The Author wishes to thank Carl Rigney since much of the text in the
   document was shamefully copied from [1] as well as the following
   people for their help in the development of this protocol:

   Nancy Greene, Ryan Moats


7.0  Authors' Addresses

   Questions about this memo can be directed to:

      Pat R. Calhoun
      Technology Development
      Sun Microsystems, Inc.
      15 Network Circle
      Menlo Park, California, 94025
      USA




Calhoun                  expires November 1998                 [Page 58]


INTERNET DRAFT                                                  May 1998


       Phone:  1-650-786-7733
         Fax:  1-650-786-6445
      E-mail:  pcalhoun@eng.sun.com

      William Bulley
      Merit Network, Inc.
      4251 Plymouth Road, Suite C
      Ann Arbor, Michigan, 48105-2785
      USA

       Phone:  1-734-764-9993
         Fax:  1-734-647-3185
      E-mail:  web@merit.edu






































Calhoun                  expires November 1998                 [Page 59]