[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-02.txt
Date: March 1998



                                       DIAMETER
                            User Authentication Extensions
                       <draft-calhoun-diameter-authent-02.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 learn the current status of any Internet-Draft,  please  check  the
   1id-abstracts.txt  listing  contained  in  the  Internet-Drafts Shadow
   Directories on ds.internic.net,  nic.nordu.net,  ftp.nisc.sri.com,  or
   munnari.oz.au.

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 September 1998                  [Page 1]


INTERNET DRAFT                                                 March 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  Authentication-Request
      2.4  Authentication-Success
      2.5  Authentication-Failure
      2.6  Authentication-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
      3.38  Port-Limit


Calhoun                  expires September 1998                  [Page 2]


INTERNET DRAFT                                                 March 1998


      3.39  Login-LAT-Port
      3.40  Framed-Password-Policy
      3.41. Table of Attributes
      5.0  Protocol Definition
      5.1  RADIUS Proxies
      5.2  DIAMETER Proxies
      5.2  Domain Discovery
      6.0  Acknowledgements
      7.0  References
      8.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', Web 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 1. This value is  used  in  the
   Supported-Extension 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
              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


Calhoun                  expires September 1998                  [Page 3]


INTERNET DRAFT                                                 March 1998


              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
      Authentication-Request    263
      Authentication-Success    264
      Authentication-Failure    265
      Authentication-Challenge  266


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

   Code


Calhoun                  expires September 1998                  [Page 4]


INTERNET DRAFT                                                 March 1998


      256     DIAMETER Command

   AVP Length

      The length of this attribute MUST be 10.

   AVP Flagss

      The AVP Flags field MUST have bit 1 (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.

      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 Type          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Code

      256     DIAMETER Command

   AVP Length

      The length of this attribute MUST be 10.


Calhoun                  expires September 1998                  [Page 5]


INTERNET DRAFT                                                 March 1998


   AVP Flagss

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

   Command Type

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


2.3  Authentication-Request

   Description

      The Authentication-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  command  is both authenticated and authorized,
      neither flag is set.

      A summary of the  Authentication-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 Type          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Code

      256     DIAMETER Command

   AVP Length


Calhoun                  expires September 1998                  [Page 6]


INTERNET DRAFT                                                 March 1998


      The length of this attribute MUST be 7.

   AVP Flagss

      The AVP Flags field MUST have bit 1  (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

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


2.4  Authentication-Success

   Description

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

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

      A summary of the  Authentication-Success  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 Type          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Code



Calhoun                  expires September 1998                  [Page 7]


INTERNET DRAFT                                                 March 1998


      256     DIAMETER Command

   AVP Length

      The length of this attribute MUST be 10.

   AVP Flagss

      The AVP Flags field MUST have bit 1  (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

      The Command Type field MUST be set to 264 (Authentication-Success).


2.5  Authentication-Failure

   Description

      The Authentication-Failure message is used  in  order  to  indicate
      that  Authentication  (or authorization) was unsuccessful. The list
      of AVPs that may be attached  to  this  message  can  be  found  in
      section 4.40.

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

      A summary of the  Authentication-Failure  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 Type          |


Calhoun                  expires September 1998                  [Page 8]


INTERNET DRAFT                                                 March 1998


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

   Code

      256     DIAMETER Command

   AVP Length

      The length of this attribute MUST be 10.

   AVP Flagss

      The AVP Flags field MUST have bit 1  (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

      The Command Type field MUST be set to 265 (Authentication-Failure).


2.6  Authentication-Challenge

   Description

      If the DIAMETER  server  desires  to  send  the  user  a  challenge
      requiring  a response, then the DIAMETER server MUST respond to the
      Authentication-Request by transmitting a packet with the Code field
      set to 266 (Authentication-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
      Authentication-Challenge other than the  Integrity-Check-Vector  or
      Digital-Signature AVP as defined in [2].

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

      The receipt of a valid Authentication-Challenge  indicates  that  a


Calhoun                  expires September 1998                  [Page 9]


INTERNET DRAFT                                                 March 1998


      new Authentication-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 Authentication-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
      Authentication-Challenge,  if  any.   Only  0 or 1 instances of the
      State Attribute can be present in an Authentication-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 Authentication-Challenge as though it had received
      an Authentication-Failure instead.

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

      The Authentication-Failure message is used  in  order  to  indicate
      that  Authentication  (or authorization) was unsuccessful. The list
      of AVPs that may be attached  to  this  message  can  be  found  in
      section 4.40.

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

      A summary of the  Authentication-Failure  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 Type          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Code

      256     DIAMETER Command

   AVP Length

      The length of this attribute MUST be 10.

   AVP Flagss

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


Calhoun                 expires September 1998                  [Page 10]


INTERNET DRAFT                                                 March 1998


      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 266 (Authentication-Failure).


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


Calhoun                 expires September 1998                  [Page 11]


INTERNET DRAFT                                                 March 1998


      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
      Framed-Password-Policy    268


3.1. User-Name

   Description

      This Attribute indicates the name of the user to be  authenticated.
      It  is  normally used in Authentication-Request packets, but MAY be
      present in the Authentication-Success 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 Flagss



Calhoun                 expires September 1998                  [Page 12]


INTERNET DRAFT                                                 March 1998


      The AVP Flags field MUST have bit 1 (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 [7].


3.2. User-Password

   Description

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

      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 no larger than
      136.

   AVP Flagss


Calhoun                 expires September 1998                  [Page 13]


INTERNET DRAFT                                                 March 1998


      The AVP Flags field MUST have bit 1 (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 Authenticate-Request packets.

      If the CHAP-Password Attribute is found in  a  message,  the  CHAP-
      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 Flagss

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

   CHAP Ident

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

   Data


Calhoun                 expires September 1998                  [Page 14]


INTERNET DRAFT                                                 March 1998


      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  only used in Authetication-
      Request messages. 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  Authentication-Request  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 Flagss

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

   Integer32

      The Integer32 field is four octets.


3.5. Service-Type

   Description



Calhoun                 expires September 1998                  [Page 15]


INTERNET DRAFT                                                 March 1998


      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 Authentication-Request and Authentication-Success messages.  A
      NAS  is  not  required to implement all of these service types, and
      MUST treat  unknown  or  unsupported  Service-Types  as  though  an
      Authentication-Failure 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
      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 Flagss

      The AVP Flags field MUST have bit 1 (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
   Authetication-Success.  When  used  in an Authentication-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


Calhoun                 expires September 1998                  [Page 16]


INTERNET DRAFT                                                 March 1998


   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.

   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 Authentication-Success (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 Authentication-Request and Authentication-
      Success messages.

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

      0                   1                   2                   3


Calhoun                 expires September 1998                  [Page 17]


INTERNET DRAFT                                                 March 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

      7 for Framed-Protocol.

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flagss

      The AVP Flags field MUST have bit 1 (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 Authentication-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     |


Calhoun                 expires September 1998                  [Page 18]


INTERNET DRAFT                                                 March 1998


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Address                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      8 for Framed-IP-Address.

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flagss

      The AVP Flags field MUST have bit 1 (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
      Authentication-Success messages if the  Framed-IP-Address  AVP  was
      returned  with  a value other than 0xFFFFFFFF. It MAY be used in an
      Authentication-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                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Calhoun                 expires September 1998                  [Page 19]


INTERNET DRAFT                                                 March 1998


   Type

      9 for Framed-IP-Netmask.

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flagss

      The AVP Flags field MUST have bit 1 (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 Authentication-
      Success 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 Flagss

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


Calhoun                 expires September 1998                  [Page 20]


INTERNET DRAFT                                                 March 1998


   Integer32

   The Integer32 field is four octets.

          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 Authentication-
      Success 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 differ 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 Flagss

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



Calhoun                 expires September 1998                  [Page 21]


INTERNET DRAFT                                                 March 1998


   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 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  Authentication-Success
      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 Flagss

      The AVP Flags field MUST have bit 1 (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 September 1998                  [Page 22]


INTERNET DRAFT                                                 March 1998


   Description

      This Attribute indicates a compression protocol to be used for  the
      link.  It  MAY be used in Authentication-Success packets. It MAY be
      used in an Authentication-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 Flagss

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

   Integer32

      The Integer32 field is four octets.

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


3.13. Login-IP-Host

   Description



Calhoun                 expires September 1998                  [Page 23]


INTERNET DRAFT                                                 March 1998


      This Attribute indicates the system with which to connect the user,
      when  the  Login-Service  Attribute  is included. It MAY be used in
      Authentication-Success   messages.   It   MAY   be   used   in   an
      Authentication-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 Flagss

      The AVP Flags field MUST have bit 1 (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
      0 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
      Authentication-Success messages.

      A summary of the Login-Service Attribute format is shown below. The


Calhoun                 expires September 1998                  [Page 24]


INTERNET DRAFT                                                 March 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     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Integer32                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      15 for Login-Service.

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flagss

      The AVP Flags field MUST have bit 1 (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 Authentication-Success packets.

      A summary of the Login-TCP-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                            |


Calhoun                 expires September 1998                  [Page 25]


INTERNET DRAFT                                                 March 1998


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

   Type

      16 for Login-TCP-Port.

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flagss

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

   Integer32

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


3.16. Reply-Message

   Description

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

      When used in an Authentication-Success, it is the success message.

      When used in an Authentication-Failure, it is the failure  message.
      It  MAY indicate a dialog message to prompt the user before another
      Authentication-Request attempt.

      When used in an Authentication-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.

      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                            |


Calhoun                 expires September 1998                  [Page 26]


INTERNET DRAFT                                                 March 1998


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

   Type

      18 for Reply-Message.

   AVP Length

      The length of this attribute MUST be at least 9.

   AVP Flagss

      The AVP Flags field MUST have bit 1 (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 Authentication-Success packets. It MAY be used in
      an Authentication-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.

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


Calhoun                 expires September 1998                  [Page 27]


INTERNET DRAFT                                                 March 1998


   Type

      19 for Callback-Number.

   AVP Length

      The length of this attribute MUST be at least 9.

   AVP Flagss

      The AVP Flags field MUST have bit 1 (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 Authentication-Success
      messages.

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

      20 for Callback-Id.

   AVP Length

      The length of this attribute MUST be at least 9.


Calhoun                 expires September 1998                  [Page 28]


INTERNET DRAFT                                                 March 1998


   AVP Flagss

      The AVP Flags field MUST have bit 1 (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-Route


   Description

      This Attribute provides routing information to  be  configured  for
      the  user  on  the  NAS.  It  is used in the Authentication-Success
      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     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   String ...
      +-+-+-+-+-+-+-+-+

   Type

      22 for Framed-Route.

   AVP Length

      The length of this attribute MUST be at least 9.

   AVP Flagss

      The AVP Flags field MUST have bit 1 (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


Calhoun                 expires September 1998                  [Page 29]


INTERNET DRAFT                                                 March 1998


      MUST NOT affect operation of the protocol. It is  recommended  that
      the  message contain displayable ASCII characters from the range 32
      through 126 decimal.

      For IP routes, it SHOULD 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  2  -1 3 400". 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 Authentication-Success 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                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Integer32                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      23 for Framed-IPX-Network.

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flagss

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


Calhoun                 expires September 1998                  [Page 30]


INTERNET DRAFT                                                 March 1998


   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 Authentication-Challenge and MUST be sent unmodified from the
      client to the server in the  new  Authentication-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                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Data ...
      +-+-+-+-+-+-+-+-+

   Type

      24 for State.

   AVP Length

      The length of this attribute MUST be at least 9.

   AVP Flagss

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

   String

      The String field is one or more octets. The actual  format  of  the


Calhoun                 expires September 1998                  [Page 31]


INTERNET DRAFT                                                 March 1998


      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  Authentication-Success 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 ...
      +-+-+-+-+-+-+-+-+

   Type

      25 for Class.

   AVP Length

      The length of this attribute MUST be at least 9.

   AVP Flagss

      The AVP Flags field MUST have bit 1 (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.


Calhoun                 expires September 1998                  [Page 32]


INTERNET DRAFT                                                 March 1998


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 Authentication-Success or Authentication-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                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Integer32                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      27 for Session-Timeout.

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flagss

      The AVP Flags field MUST have bit 1 (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.


3.25. Idle-Timeout


Calhoun                 expires September 1998                  [Page 33]


INTERNET DRAFT                                                 March 1998


   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   Authentication-Success   or
      Authentication-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                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      28 for Idle-Timeout.

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flagss

      The AVP Flags field MUST have bit 1 (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


Calhoun                 expires September 1998                  [Page 34]


INTERNET DRAFT                                                 March 1998


      This Attribute allows the NAS to send in the Authentication-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 Authentication-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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           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 Flagss

      The AVP Flags field MUST have bit 1 (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


Calhoun                 expires September 1998                  [Page 35]


INTERNET DRAFT                                                 March 1998


   Description

      This Attribute allows the NAS to send in the Authentication-Request
      packet  the  phone  number that the call came from, using Automatic
      Number Identification (ANI) or similar technology. It is only  used
      in Authentication-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.

      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 Flagss

      The AVP Flags field MUST have bit 1 (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.




Calhoun                 expires September 1998                  [Page 36]


INTERNET DRAFT                                                 March 1998


3.29. Proxy-State

   Description

      This Attribute is available to be sent by a proxy server to another
      server  when  forwarding  an  Authentication-Request  and  MUST  be
      returned unmodified in the Authentication-Success,  Authentication-
      Failure  or  Authentication-Challenge.  This  attribute  should  be
      removed by the proxy server before the response is forwarded to the
      NAS.

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

   Type

      33 for Proxy-State.

   AVP Length

      The length of this attribute MUST be at least 9.

   AVP Flagss

      The AVP Flags field MUST have bit 1 (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



Calhoun                 expires September 1998                  [Page 37]


INTERNET DRAFT                                                 March 1998


      This Attribute indicates the system with which the user  is  to  be
      connected by LAT. It MAY be used in Authentication-Success packets,
      but only when LAT is specified as the Login-Service. It MAY be used
      in  an  Authentication-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
      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 Flagss

      The AVP Flags field MUST have bit 1 (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),


Calhoun                 expires September 1998                  [Page 38]


INTERNET DRAFT                                                 March 1998


      numerics, upper and lower case alphabetics,  and  the  ISO  Latin-1
      character  set  extension  [6]. All LAT string comparisons are case
      insensitive.


3.31. Login-LAT-Node

   Description

      This Attribute indicates the Node with which  the  user  is  to  be
      automatically  connected  by LAT. It MAY be used in Authentication-
      Success packets, but only when  LAT  is  specified  as  the  Login-
      Service.  It  MAY  be used in an Authentication-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 Flagss

      The AVP Flags field MUST have bit 1 (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.



Calhoun                 expires September 1998                  [Page 39]


INTERNET DRAFT                                                 March 1998


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
      Authentication-Success packets, but only when LAT is  specified  as
      the  Login-Service.  It  MAY  be  used in an Authentication-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 Flagss

      The AVP Flags field MUST have bit 1 (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


Calhoun                 expires September 1998                  [Page 40]


INTERNET DRAFT                                                 March 1998


      octets.

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


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 Authentication-Success  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 Flagss

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

   Integer32

      The Integer32 field is four octets. Despite the size of the  field,
      values range from 0 to 65535. The special value of 0 indicates that
      this is an unnumbered serial link. A value of  1-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


Calhoun                 expires September 1998                  [Page 41]


INTERNET DRAFT                                                 March 1998


   Description

      This Attribute indicates the AppleTalk Network number which the NAS
      should probe to allocate an AppleTalk node for the user. It is only
      used in Authentication-Success 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 Flagss

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

   Integer32

      The Integer32 field is four octets. Despite the size of the  field,
      values  range  from  0 to 65535. The special value 0 indicates that
      the NAS should assign a network for the  user,  using  its  default
      cable  range. A value between 1 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 Authentication-Success packets.


Calhoun                 expires September 1998                  [Page 42]


INTERNET DRAFT                                                 March 1998


      Multiple instances of this attribute in the  same  packet  are  not
      allowed.

      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 Flagss

      The AVP Flags field MUST have bit 1 (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 Authentication-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


Calhoun                 expires September 1998                  [Page 43]


INTERNET DRAFT                                                 March 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     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Data ...
      +-+-+-+-+-+-+-+-+

   Type

      60 for CHAP-Challenge.

   AVP Length

      The length of this attribute MUST be at least 24.

   AVP Flagss

      The AVP Flags field MUST have bit 1 (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
      Authentication-Request  packets.  Either  NAS-Port (5) or NAS-Port-
      Type or both SHOULD be present in an Authentication-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 September 1998                  [Page 44]


INTERNET DRAFT                                                 March 1998


   Type

      61 for NAS-Port-Type.

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flagss

      The AVP Flags field MUST have bit 1 (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
      Authentication-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 Authentication-Success packet. It is intended  for
      use  in  conjunction with Multilink PPP [7] 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                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |


Calhoun                 expires September 1998                  [Page 45]


INTERNET DRAFT                                                 March 1998


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Integer32                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      62 for Port-Limit.

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flagss

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

   Integer32

      The Integer32 field is  4  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 Authentication-Success packets,
      but only when LAT is specified as the Login-Service. It MAY be used
      in  an  Authentication-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

      63 for Login-LAT-Port.



Calhoun                 expires September 1998                  [Page 46]


INTERNET DRAFT                                                 March 1998


   AVP Length

      The length of this attribute MUST be at least 9.

   AVP Flagss

      The AVP Flags field MUST have bit 1 (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. 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

      268 for Framed-Password-Policy.

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flagss



Calhoun                 expires September 1998                  [Page 47]


INTERNET DRAFT                                                 March 1998


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

   Integer32

      The Integer32 field contains the supported  authentication  schemes
      supported. The following values are supported:

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


3.41. 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+    0     0+    0+       0+       26   Vendor-Specific
      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


Calhoun                 expires September 1998                  [Page 48]


INTERNET DRAFT                                                 March 1998


      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
      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-1  0-1   0     0     0        0+       268  Framed-Password-Pol.
      Req  Succ  Fail  Chal  Disc-Req Disc-Rsp #    Attribute

      [*1] An  Authentication-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  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  his  ISPs  service  area,  it is possible for the user to
   connect to another service provider (see [4] for more details).

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


Calhoun                 expires September 1998                  [Page 49]


INTERNET DRAFT                                                 March 1998


                (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
   the   user   based   on  information  found  within  the  request.  If
   successfully authentication  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 model where 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.


Calhoun                 expires September 1998                  [Page 50]


INTERNET DRAFT                                                 March 1998


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


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

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

   In this example  NASB  generates  an  Authentication-Request  that  is
   forwarded  to  DIA2.  The  Authentication-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.



Calhoun                 expires September 1998                  [Page 51]


INTERNET DRAFT                                                 March 1998


   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.

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

            (Auth-Request)    (Auth-Request)    (Auth-Request)
      +------+  ----->  +------+  ----->  +------+  ----->  +------+
      |      |          |      |          |      |          |      |
      | NASB +----------+ DIA2 +----------+ DIA3 +----------+ DIA1 +
      |      |          |      |          |      |          |      |
      +------+  <-----  +------+  <-----  +------+  <-----  +------+
           (Auth-Response)   (Auth-Response)    (Auth-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.3  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)


Calhoun                 expires September 1998                  [Page 52]


INTERNET DRAFT                                                 March 1998


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

   The way the Domain Discovery works is that prior  to  sending  out  an
   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).

                                 (Authentication-Request)
                        +------+       ----->       +------+
                        |      |                    |      |
                        | DIA1 +--------------------+ DIA3 +
                        |      |                    |      |
                        +------+       <-----       +------+
                                (Authentication-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 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:


Calhoun                 expires September 1998                  [Page 53]


INTERNET DRAFT                                                 March 1998


   Nancy Greene, Ryan Moats

6.0  References

    [1] Rigney, et alia, "RADIUS", RFC-2138, Livingston, April 1997
    [2] P. R. Calhoun, A. Rubens, "DIAMETER Base Protocol",
        draft-calhoun-diameter-00.txt, February 1998.
    [3] B. Aboba. "The Network Access Identifier." Internet-Draft,
        August 1997.
    [4] Aboba, Zorn, "Dialup Roaming Requirements", Internet-Draft,
        July 1997.
    [5] P. Calhoun, A. Rubens, B. Aboba, "DIAMETER Extensible
        Authentication Protocol Extensions",
        draft-calhoun-diameter-eap-01.txt, March 1998.
    [6] P. Calhoun, J. Haag, G. Zorn, "EAP Authentication for SOCKS
        Version 5", draft-ietf-aft-socks-eap-00.txt, March 1998.
    [7] B. Aboba, M. Beadles, "Network Address Identifier",
        draft-ietf-roamops-nai-10.txt, February 1998.


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

       Phone:  1-847-548-9587
         Fax:  1-650-786-6445
      E-mail:  pcalhoun@toast.net


















Calhoun                 expires September 1998                  [Page 54]