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

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18

INTERNET DRAFT                                             Pat R. Calhoun
Category: Standards Track                           Sun Laboratories, Inc.
Title: draft-calhoun-diameter-07.txt                      Allan C. Rubens
Date: November 1998                                 Ascend Communications



                         DIAMETER Base Protocol



Status of this Memo

   Comments should be submitted to the diameter@ipass.com mailing list.

   Distribution of this memo is unlimited.

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

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

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


Abstract

   The DIAMETER base protocol is intended to provide a framework for any
   services which require AAA/Policy support. The protocol is intended
   to be flexible enough to allow services to add building blocks (or
   extensions) to DIAMETER in order to meet their requirements.

   This draft specifies the message format and transport to be used by
   all DIAMETER extensions and MUST be supported by all DIAMETER
   implementations, regardless of the specific underlying service.







Calhoun, Rubens            expires April 1999                   [Page 1]


INTERNET DRAFT                                             November 1998


Table of Contents

      1.0  Introduction
      1.1  Definitions
      1.2  Terminology
      2.0  Protocol Overview
            2.1  Header Format
            2.2  AVP Format
            2.3  Error Reporting
      3.0  DIAMETER AVPs
            3.1  DIAMETER-Command AVP
                  3.1.1  Message-Reject-Ind
                  3.1.2  Device-Reboot-Ind
                  3.1.3  Device-Watchdog-Ind
            3.2  Host-IP-Address
            3.3  Host-Name
            3.4  State
            3.5  Class
            3.6  Session-Timeout
            3.7  Extension-Id
            3.8  Integrity-Check-Vector
            3.9  Initialization-Vector
            3.10 Timestamp
            3.11 Session-Id
            3.12 Vendor-Name
            3.13 Firmware-Revision
            3.14 Result-Code
            3.15 Error-Code
            3.16 Unrecognized-Command-Code
            3.17 Reboot-Type
            3.18 Reboot-Time
            3.19 Failed-AVP-Code
            3.20 User-Name
      4.0  Protocol Definition
            4.1  DIAMETER Bootstrap Message
            4.2  Keepalive Exchange
            4.3  Unrecognized Command Support
            4.4  The art of AVP Tagging
            4.5  Using the Integrity-Check-Vector
            4.6  AVP Encryption with Shared Secrets
      5.0  References
      6.0  Acknowledgements
      7.0  Author's Address








Calhoun, Rubens            expires April 1999                   [Page 2]


INTERNET DRAFT                                             November 1998


1.0  Introduction

   Since the RADIUS protocol is being used today for much more than
   simple authentication and accounting of dial-up users (i.e.
   authentication of WWW clients, etc), a more extensible protocol was
   necessary which could support new services being deployed in the
   internet and corporate networks.

   RADIUS in itself is not an extensible protocol largely due to its
   very limited command and attribute address space. In addition, the
   RADIUS protocol assumes that there cannot be any unsolicited messages
   from a server to a client. In order to support new services it is
   imperative that a server be able to send unsolicited messages to
   clients on a network, and this is a requirement for any DIAMETER
   implementation.

   This document describes the base DIAMETER protocol, which is used as
   the transport for all DIAMETER extensions. This document in itself is
   not complete and MUST be used with an accompanying applicability
   extension document.

   An example of such a document would be [7] that defines extensions to
   the base protocol to support user authentication and [XXX] which
   defines extensions to support accounting.


1.1  Definitions

   In this document, several words are used to signify the requirements
   of the specification.  These words are often capitalized.

   MUST      This word, or the adjective "required", means that the
             definition is an absolute requirement of the
             specification.

   MUST NOT  This phrase means that the definition is an absolute
             prohibition of the specification.

   SHOULD    This word, or the adjective "recommended", means that
             there may exist valid reasons in particular circumstances
             to ignore this item, but the full implications must be
             understood and carefully weighed before choosing a
             different course.

   MAY       This word, or the adjective "optional", means that this
             item is one of an allowed set of alternatives.  An
             implementation which does not include this option MUST
             be prepared to interoperate with another implementation



Calhoun, Rubens            expires April 1999                   [Page 3]


INTERNET DRAFT                                             November 1998


             which does include the option.


1.2  Terminology

   AVP

      The DIAMETER protocol consists of a header followed by objects.
      Each object is encapsulated in a header known as an Attribute-
      Value-Pair (AVP).

   DIAMETER Device

      A Diameter device is a client or server system that supports the
      Diameter Base protocol and 0 or more extensions.

   ICV

      An Integrity Check Vector (ICV) is a hash of the packet with a
      shared secret.


2.0  Protocol Overview


2.1  Header Format

   The base DIAMETER protocol MAY be transmitted over TCP. The document
   [11] defines the extensions required to transmit DIAMETER over UDP.
   The destination port field for DIAMETER is 1812.

   Each DIAMETER Service Extension (i.e. Mobile IP, ROAMOPS, etc) MUST
   define the transport layer required.

   For UDP, when a reply is generated the source and destination ports
   are reversed.

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












Calhoun, Rubens            expires April 1999                   [Page 4]


INTERNET DRAFT                                             November 1998


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  RADIUS PCC   | Flags |W| Ver |         Packet Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Identifier                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Next Send (Ns)        |       Next Received (Nr)      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  AVPs ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-

   RADIUS PCC (Packet Compatibility Code)

      The RADIUS PCC  field is a one octet field which is used for
      backward compatibility with RADIUS. In order to easily distinguish
      DIAMETER packets from RADIUS a special value has been reserved and
      allows an implementation to support both protocols concurrently
      using the first octet in the header. The RADIUS PCC field MUST be
      set as follows:

          254       DIAMETER packet

   PKT Flags

      The Packet Flags field is five bits, and is used in order to
      identify any options. This field MUST be initialized to zero. The
      following flag may be set:

         The 'W' bit is set when the Next Send (Ns) and Next Received
         (Nr) fields are present in the header. This SHOULD be set
         unless the underlying layer provides reliability (i.e. TCP).

   Version

      The Version field is three bits, and indicates the version number
      which is associated with the packet received. This field MUST be
      set to 1 to indicate DIAMETER Version 1.

   Packet Length

      The Packet Length field is two octets.  It indicates the length of
      the packet including the header fields. For messages received via
      UDP, octets outside the range of the Length field should be
      treated as padding and should be ignored upon receipt.

   Identifier




Calhoun, Rubens            expires April 1999                   [Page 5]


INTERNET DRAFT                                             November 1998


      The Identifier field is four octets, and aids in matching requests
      and replies. The sender MUST ensure that the identifier in a
      message is locally unique (to the sender) at any given time, and
      MAY attempt to ensure that the number is unique across reboots.
      The identifier is normally a monotonically increasing number, but
      using a random value is also permitted. Given the size of the
      Identifier field it is unlikely that 2^32 requests could be
      outstanding at any given time.

   Next Send

      This field is defined in [11].

   Next Received

      This field is defined in [11].

   AVPs

      AVPs is a method of encapsulating information relevant to the
      DIAMETER message. See section 2.2 for more information on AVPs.


2.2  AVP Format

   DIAMETER Attributes carry specific authentication, accounting and
   authorization information as well as configuration details for the
   request and reply.

   Some Attributes MAY be listed more than once. The effect of this is
   Attribute specific, and is specified in each case by the attribute
   description.

   Each AVP MUST be padded to align on a 32 bit boundary. Although this
   is not problematic for most attribute types, it does require that AVP
   of string and data type be padded with zeroes accordingly. The
   Padding size can be calculated using the following formula:

      if( Length mod 4 != 0 )
          padding_size = 4 - ( Length mod 0 )
      else
          padding_size = 0

   The end of the list of attributes is defined by the length of the
   DIAMETER packet minus the length of the header.

   The attribute format is shown below and MUST be sent in network byte
   order.



Calhoun, Rubens            expires April 1999                   [Page 6]


INTERNET DRAFT                                             November 1998


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |     Reserved      |P|T|V|E|H|M|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Vendor ID (opt)                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Tag (opt)                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Data ...
      +-+-+-+-+-+-+-+-+

   AVP Code

      The AVP Code field is four octets. The first 256 AVP numbers are
      reserved for backward RADIUS compatibility. Up-to-date values of
      the RADIUS Type field are specified in the most recent "Assigned
      Numbers" RFC [2].

      AVP numbers 256 and above are used for DIAMETER. Each service MUST
      allocate AVP numbers through the IANA.

      If the Vendor-Specific-AVP flag is set, the AVP Code is allocated
      from the vendor's private address space.

   AVP Length

      The AVP Length field is two octets, and indicates the length of
      this Attribute including the AVP Code, AVP Length, AVP Flags,
      Reserved, the Tag and Vendor ID fields if present and the AVP
      data. If a packet is received with an Invalid attribute length,
      the packet SHOULD be rejected.

   Reserved

      The Reserved field MUST be set to zero (0).

   AVP Flags

      The AVP Flags field informs the DIAMETER host how each attribute
      must be handled.

      The 'M' Bit, known as the Mandatory bit, indicates whether support
      of the AVP is required. If an AVP is received with the 'M' bit
      enabled and the receiver does not support the AVP, the request
      MUST be rejected.



Calhoun, Rubens            expires April 1999                   [Page 7]


INTERNET DRAFT                                             November 1998


      AVPs without the 'M' bit enabled are informational only and a
      receiver that receives a message with such an AVP that is not
      supported MAY simply ignore the AVP.

      When the 'H' bit is enabled it indicates that the AVP data is
      encrypted using hop-by-hop encryption. See section 4.5 for more
      information.

      When the 'E' bit is enabled it indicates that the AVP data is
      encrypted using end-to-end encryption. See [12] for more
      information.

      The 'V' bit, known as the Vendor-Specific bit, indicates whether
      the optional Vendor ID field is present in the AVP header. When
      set the AVP Code belongs to the specific vendor code address
      space.

      The 'T' bit, known as the Tag bit, is used to group sets of AVPs
      together. Grouping of AVPs is necessary when more than one AVP is
      needed to express a condition.

      The 'P' bit, known as the protected AVP bit, is used to indicate
      whether the AVP is protected by a Digital Signature AVP. When set,
      the AVP is protected and the contents cannot be changed by a
      DIAMETER proxy server. See [12] for more information.


   Vendor ID

      The optional four octet Vendor ID field contains the IANA assigned
      "SMI Network Management Private Enterprise Codes" value, encoded
      in network byte order. Any vendor wishing to implement DIAMETER
      extensions can use their own Vendor ID along with private
      Attribute values, guaranteeing that they will not collide with any
      other vendor's extensions, nor with future IETF extensions.

      The value zero, reserved in this protocol, corresponds to IETF
      adopted Attribute values, defined within this document; zero MUST
      NOT be used in an AVP.

   Tag

      The Tag field is four octet in length and is intended to provide a
      means of grouping attributes in the same packet which refer to the
      same tunnel. If the Tag field is unused, the 'T' bit MUST NOT be
      set..

   Data



Calhoun, Rubens            expires April 1999                   [Page 8]


INTERNET DRAFT                                             November 1998


      The Data field is zero or more octets and contains information
      specific to the Attribute. The format and length of the Data field
      is determined by the AVP Code and AVP Length fields.

      The format of the value field MAY be one of six data types. It is
      possible for an attribute to have a structure and this MUST be
      defined along with the attribute.

      Data

         0-65400 octets of arbitrary data.

      String

         0-65400 octets of string data using the UTF-8 character set.

      Address

         32 bit or 128 bit value, most significant octet first. The
         length of the attribute is determined by the length.

      Integer32

         32 bit value, most significant octet first.

      Integer64

         64 bit value, most significant octet first.

      Time

         32 bit value, most significant octet first -- seconds since
         00:00:00 GMT, January 1, 1970.


2.3  Error Reporting

   There are five different types of errors within DIAMETER. The first
   being where a DIAMETER message is poorly formatted and
   unrecognizable, indicated below by "Bad Packet".

   The second case involves receiving a DIAMETER-Command-AVP that is not
   supported, which is shown below by "Unknown Command". The third case
   is where an AVP is received, marked mandatory and is unknown by the
   receiver, which is labeled below as "Unknown AVP".

   This fourth case involves receiving a message with a known AVP, yet
   the value is either unknown or illegal, which is shown below as "Bad



Calhoun, Rubens            expires April 1999                   [Page 9]


INTERNET DRAFT                                             November 1998


   Value".  The last case occurs when an error occurs while processing a
   specific extension command, which is not related to the packet format
   and is labeled "Extension Error" below.

   Error Type           Ignore Message          Send         Extension
                                         Message-Reject-Ind  Response /w
                                                             Result-Code
   Bad Packet                 X
   Unknown Command                               X
   Unknown AVP                                   X
   Bad Value                                     X
   Extension Error                                               X

   "Ignore Message" indicates that the message is simply dropped. The
   "Message-Reject-Ind" indicates that a Message-Reject-Ind message MUST
   be sent to the peer as described in the appropriate section. The
   "Extension Error w/ Result-Code" indicates that the appropriate
   Response to the message MUST be sent with the Result-Code or Error-
   Code AVP set to a value that enables the peer to understand the
   nature of the problem.


3.0  DIAMETER AVPs

   This section will define the mandatory AVPs that MUST be supported by
   all DIAMETER implementations. Note the first 256 AVP numbers are
   reserved for RADIUS compatibility.

   The following AVPs are defined in this document:

      Attribute Name       Attribute Code
      -----------------------------------
      DIAMETER-Command          256
      Host-IP-Address             4
      Host-Name                  32
      State                      24
      Class                      25
      Session-Timeout            27
      Extension-Id              258
      Integrity-Check-Vector    259
      Initialization-Vector     261
      Timestamp                 262
      Session-Id                263
      Vendor-Name               266
      Firmware-Revision         267
      Result-Code               268
      Error-Code                269
      Unrecognized-Command-Code 270



Calhoun, Rubens            expires April 1999                  [Page 10]


INTERNET DRAFT                                             November 1998


      Reboot-Type               271
      Reboot-Time               272
      Failed-AVP-Code           279


3.1  DIAMETER-Command AVP

   Description

      The DIAMETER-Command AVP MUST be the first AVP following the
      DIAMETER header. This AVP is used in order to communicate the
      command associated with the message. A DIAMETER message can have
      at most one DIAMETER-Command AVP. The format of the AVP is as
      follows:

      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           |     Reserved      |P|T|V|E|H|M|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Command Code                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      AVP Code

         256     DIAMETER-Command

      AVP Length

         The length of this attribute MUST be at least 12. The exact
         length of the AVP is determined by the actual Command and is
         defined with each command.

      AVP Flags

         The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
         upon the security model used. The 'V' MAY be set if the Command
         Code is vendor specific. The 'T' and the 'P' bits MUST NOT be
         set.

      Command Code

         The Command Code field contains the command number. The
         following commands are defined and MUST be supported by all
         DIAMETER implementations in order to conform to the base
         protocol specification:



Calhoun, Rubens            expires April 1999                  [Page 11]


INTERNET DRAFT                                             November 1998


            Command Name          Command Code
            -----------------------------------
            Message-Reject-Ind        256
            Device-Reboot-Ind         257
            Device-Watchdog-Ind       258


3.1.1  Message-Reject-Ind (MRI)

   Description

      The Message-Reject-Ind command provides a generic means of
      completing transactions by indicating errors in the messages which
      initiated them. The Message-Reject-Ind command is a possible
      response to any DIAMETER command, but some DIAMETER commands MAY
      expect more specialized error messages, depending on the error
      type.

      The Message-Reject-Ind message MUST contain the same
      identification in the header and include the Session-Id if it was
      present in the original message that it is responding to, even if
      the identification is erroneous. The receiver of a Message-
      Reject-Ind SHOULD examine the Result-Code AVP provided before
      processing the identification, in order to handle the letter
      appropriately.

   Message Format

      The structure of the Message-Reject message is defined as follows:

      <Message-Reject-Ind message> ::= <DIAMETER Header>
                                       <Message-Reject-Ind Command AVP>
                                       <Host-IP-Address AVP>
                                       [<Host-Name AVP>]
                                       [<Session-Id AVP>]
                                       <Result-Code AVP>
                                       [<Error-Code AVP> ]
                                       {<Failed-AVP-Code AVP> ||
                                        <Unrecognized-Command-Code AVP>}
                                       <Timestamp AVP>
                                       <Initialization-Vector AVP>
                                       {<Integrity-Check-Vector AVP> ||
                                        <Digital-Signature AVP }

      where the Identifier value in the message header and optionally
      the Session-Id AVP are copied from the message being rejected and
      the DIAMETER-Command AVP has the format described below. The
      Result-Code and conditionally-present Error-Code AVPs indicate the



Calhoun, Rubens            expires April 1999                  [Page 12]


INTERNET DRAFT                                             November 1998


      nature of the error causing rejection, and the conditionally-
      present Failed-AVP-Code AVP provides some minimal debugging data
      by indicating a specific AVP type which caused the problem. See
      the description of the Result-Code AVP for indication of when the
      Error-Code and/or Failed-AVP-Code AVPs will be present in the
      message. The Unrecognized-Command-Code AVP is present only when
      the reason for message rejection is an unrecognized or unsupported
      command code.

   AVP Format

      The format of the DIAMETER-Command AVP for Message-Reject-Ind is
      as follows:

       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           |     Reserved      |P|T|V|E|H|M|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Command Code                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      AVP Code

         256     DIAMETER-Command

      AVP Length

         The length of this attribute MUST be at exactly 12.

      AVP Flags

         The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
         upon the security model used. The 'V', 'T' and the 'P' bits
         MUST NOT be set.

      Command Code

         The Command Code field MUST be set to 256 (Message-Reject-Ind)


3.1.2  Device-Reboot-Ind (DRI)

   Description

      A DIAMETER device sends the Device-Reboot-Ind message to inform



Calhoun, Rubens            expires April 1999                  [Page 13]


INTERNET DRAFT                                             November 1998


      all of its peers either of an upcoming reboot or that it has just
      rebooted.

      The Reboot-Type AVP MUST be present and indicates the type of
      reboot associated with this command. Note that a DIAMETER device
      should only send this message once it is able to receive network
      traffic.

      This message is also used by a DIAMETER device in order to
      exchange the supported protocol version number as well as all
      supported extensions. The originator of this message MUST insert
      it's highest supported version number within the DIAMETER header.
      The response message MUST include the highest supported version up
      to and including the version number within the request.

      Similarly the originator of this message MUST include all
      supported extensions within the message. The responder MUST
      include all supported extensions as long as they were present
      within the request message.

      In the case where the receiver of this message is a proxy device,
      it is responsible for inserting the highest version number which
      it supports in the version field before sending the proxy request
      to the remote DIAMETER peer. The proxy device may then retain the
      version number of the remote peers as received in the message, and
      must insert its highest version number (with the limitations
      described above) in the response to the initiator.

      It is desirable for a DIAMETER device to retain the supported
      extensions as well as the version number in order to ensure that
      any requests issued to a peer will be processed.

      This message MUST contain the Vendor-Name and Extension-Id AVPs.

      In the case where a DIAMETER device is configured to communicate
      with many peers, this message MUST be issued to each peer.

      No explicit DIAMETER message is necessary to acknowledge this
      message since it is handled by DIAMETER's reliable transport.

   Message Format










Calhoun, Rubens            expires April 1999                  [Page 14]


INTERNET DRAFT                                             November 1998


      <Device-Reboot-Ind> ::= <DIAMETER Header>
                              <Device-Reboot-Ind Command AVP>
                              <Reboot-Type AVP>
                              [<Reboot-Time AVP>]
                              <Host-IP-Address AVP>
                              [<Host-Name AVP>]
                              <Vendor-Name AVP>
                              <Extension-Id AVPs>
                              <Firmware-Revision AVP>
                              [<X509-Certificate AVP>]
                              [<X509-Certificate-URL AVP>]
                              <Timestamp AVP>
                              <Initialization-Vector AVP>
                              {<Integrity-Check-Vector AVP> ||
                               <Digital-Signature AVP }

   AVP Format

      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           |     Reserved      |P|T|V|E|H|M|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Command Code                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      AVP Code

         256     DIAMETER-Command

      AVP Length

         The length of this attribute MUST be 12.

      AVP Flags

         The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
         upon the security model used. The 'V', 'T' and the 'P' bits
         MUST NOT be set.

      Command Code

         The Command Code field MUST be set to 257 (Device-Reboot-
         Indication).





Calhoun, Rubens            expires April 1999                  [Page 15]


INTERNET DRAFT                                             November 1998


3.1.3  Device-Watchdog-Ind (WDI)

   Description

      The Device-Watchdog-Ind is used as a keepalive mechanism between
      two DIAMETER peers. This message MUST contain the Host-IP-Address
      or Host-Name AVP as well as any security related AVPs.

      No explicit DIAMETER message is necessary to acknowledge this
      message since it is handled by DIAMETER's reliable transport.

   Message Format

      <Device-Watchdog-Ind> ::= <DIAMETER Header>
                                <Device-Watchdog-Ind Command AVP>
                                <Host-IP-Address AVP>
                                [<Host-Name AVP>]
                                <Timestamp AVP>
                                <Initialization-Vector AVP>
                                {<Integrity-Check-Vector AVP> ||
                                 <Digital-Signature AVP }

   AVP Format

      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           |     Reserved      |P|T|V|E|H|M|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Command Code                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      AVP Code

         256     DIAMETER-Command

      AVP Length

         The length of this attribute MUST be 12.

      AVP Flags

         The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
         upon the security model used. The 'V', 'T' and the 'P' bits
         MUST NOT be set.




Calhoun, Rubens            expires April 1999                  [Page 16]


INTERNET DRAFT                                             November 1998


      Command Code

         The Command Code field MUST be set to 258 (Device-Watchdog-
         Ind).


3.2  Host-IP-Address

   Description

      The Host-IP-Address attribute is used to inform a DIAMETER peer of
      the sender's identity.

   AVP Format

      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           |     Reserved      |P|T|V|E|H|M|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Address                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      AVP Code

         4     Host-IP-Address

      AVP Length

         The length of this attribute MUST be at least 12.

      AVP Flags

         The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
         upon the security model used. The 'V', 'T' and the 'P' bits
         MUST NOT be set.

      Address

         The Address field contains the sender's IP address.


3.3  Host-Name

   Description




Calhoun, Rubens            expires April 1999                  [Page 17]


INTERNET DRAFT                                             November 1998


      The Host-Name attribute is used to inform a DIAMETER peer of the
      sender's identity.

   AVP Format

      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           |     Reserved      |P|T|V|E|H|M|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   String ...
      +-+-+-+-+-+-+-+-+

      AVP Code

         32     Host-Name

      AVP Length

         The length of this attribute MUST be at least 9.

      AVP Flags

         The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
         upon the security model used. The 'V', 'T' and the 'P' bits
         MUST NOT be set.

      String

         The String field is one or more octets, and should be unique to
         the DIAMETER host. The Host Name MUST follow the NAI [8] naming
         conventions.


3.4  State

   Description

      This AVP is available to be sent by the server to the client when
      the DIAMETER exchange can span multiple round-trip messages and is
      used to maintain server state information. The opaque data MUST be
      sent unmodified by the client to the server in subsequent messages
      for the same Session-Id.

      Usage of the State AVP is implementation dependent.




Calhoun, Rubens            expires April 1999                  [Page 18]


INTERNET DRAFT                                             November 1998


   AVP Format

      A summary of the State AVP 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           |     Reserved      |P|T|V|E|H|M|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Data ...
      +-+-+-+-+-+-+-+-+

      Type

         24 for State.

      AVP Length

         The length of this attribute MUST be at least 9.

      AVP Flags

         The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
         upon the security model used. The 'V', 'T' and the 'P' bits
         MUST NOT be set.

      Data

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


3.5  Class

   Description

      The server sends this AVP to the client during authentication or
      authorization and MUST be sent unmodified by the client to the
      accounting server as part of the accounting message if accounting
      is supported. No interpretation of the opaque data should be made
      by the client.

      A summary of the Class AVP format is shown below. The fields are



Calhoun, Rubens            expires April 1999                  [Page 19]


INTERNET DRAFT                                             November 1998


      transmitted from left to right.

   AVP Format

      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           |     Reserved      |P|T|V|E|H|M|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Data ...
      +-+-+-+-+-+-+-+-+

      Type

         25 for Class.

      AVP Length

         The length of this attribute MUST be at least 9.

      AVP Flags

         The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
         upon the security model used. The 'V', 'T' and the 'P' bits
         MUST NOT be set.

      Data

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


3.6  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 AA-Answer or AA-Challenge.

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




Calhoun, Rubens            expires April 1999                  [Page 20]


INTERNET DRAFT                                             November 1998


   AVP Format

      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           |     Reserved      |P|T|V|E|H|M|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Integer32                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type

         27 for Session-Timeout.

      AVP Length

         The length of this attribute MUST be 12.

      AVP Flags

         The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
         upon the security model used. The 'V', 'T' and the 'P' bits
         MUST NOT be set.

      Integer32

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

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


3.7  Extension-Id

   Description

      The Extension-Id AVP is used in order to identify a specific
      DIAMETER extension. This AVP MAY be used in the Device-Reboot-Ind
      and the Device-Feature-Reply command in order to inform the peer
      what extensions are locally supported.

      Each DIAMETER extension draft MUST have an Extension-Id assigned
      to it by the IANA. The base protocol does not require a
      Extension-Id since its support is mandatory.



Calhoun, Rubens            expires April 1999                  [Page 21]


INTERNET DRAFT                                             November 1998


      There MAY be more than one Extension-Id AVP within a DIAMETER
      message.

   AVP Format

      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           |     Reserved      |P|T|V|E|H|M|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Integer32                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      AVP Code

         258     Extension-Id

      AVP Length

         The length of this attribute MUST be 12.

      AVP Flags

         The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
         upon the security model used. The 'V', 'T' and the 'P' bits
         MUST NOT be set.

      Integer32

         The Integer32 field contains the extension identifier as
         defined in the extension's document.


3.8  Integrity-Check-Vector

   Description

      The Integrity-Check-Vector AVP is used for hop-by-hop
      authentication and integrity, and is not recommended for use with
      untrusted proxy servers.

      The DIAMETER header as well as all AVPs (including padding) up to
      this AVP is protected by the Integrity-Check-Vector. The Timestamp
      AVP MUST be present to provide replay protection and the
      Initialization-Vector AVP must be present to add randomness to the
      packet.



Calhoun, Rubens            expires April 1999                  [Page 22]


INTERNET DRAFT                                             November 1998


      The Integrity-Check-Vector is generated in the method described in
      section 4.5.1.

      All DIAMETER implementations MUST support this AVP.

   AVP Format

      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           |     Reserved      |P|T|V|E|H|M|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Transform ID                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Data ...
      +-+-+-+-+-+-+-+-+

      AVP Code

         259     Integrity-Check-Vector

      AVP Length

         The length of this attribute MUST be at least 13.

      AVP Flags

         The 'M' bit MUST be set. The 'E', 'H', 'V', 'T' and the 'P'
         bits MUST NOT be set.

      Transform ID

         The Transform ID field contains a value that identifies the
         transform that was used to compute the ICV. The following
         values are defined in this document:

         HMAC-MD5-96[6]          1

      Data

         The Data field contains an ICV of the message up to this AVP.


3.9  Initialization-Vector

   Description



Calhoun, Rubens            expires April 1999                  [Page 23]


INTERNET DRAFT                                             November 1998


      The Initialization-Vector AVP MUST be present prior to the
      Integrity-Check-Vector AVPs within a message and is used to ensure
      randomness within a message. The content of this AVP MUST be a
      random value of at least 128 bits.

   AVP Format

      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           |     Reserved      |P|T|V|E|H|M|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Data ...
      +-+-+-+-+-+-+-+-+

      AVP Code

         261     Initialization-Vector

      AVP Length

         The length of this attribute MUST be at least 24.

      AVP Flags

         The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
         upon the security model used. The 'V', 'T' and the 'P' bits
         MUST NOT be set.

      Data

         The Data field contains a random value of at least 128 bits.


3.10  Timestamp

   Description

      The Timestamp AVP is used to add replay protection to the DIAMETER
      protocol. This AVP MUST appear prior to the Integrity-Check-Vector
      AVP or any other Integrity AVP defined in separate extensions. The
      value of time is the most significant four octets returned from an
      NTP server that indicates the number of seconds expired since Jan.
      1, 1970.

      This document does not specify the window which an implementation



Calhoun, Rubens            expires April 1999                  [Page 24]


INTERNET DRAFT                                             November 1998


      will accept packets, however it is strongly encouraged to make
      this value user configurable with a reasonable default value (i.e.
      4 seconds).

   AVP Format

      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           |     Reserved      |P|T|V|E|H|M|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              Time                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      AVP Code

         262     Timestamp

      AVP Length

         The length of this attribute MUST be 12.

      AVP Flags

         The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
         upon the security model used. The 'V', 'T' and the 'P' bits
         MUST NOT be set.

      Time

         The Time field contains the number of seconds since Jan. 1,
         1970 when the message was created.


3.11  Session-Id

   Description

      The Session-Id field is used in order to identify a specific
      session.  All messages pertaining to a specific session MUST
      include this AVP and the same value MUST be used throughout the
      life of a session. When present, the Session-Id SHOULD appear
      immediately following the DIAMETER-Command AVP.

      Note that in some applications there is no concept of a session
      (i.e.  data flow) and this field MAY be used to identify objects



Calhoun, Rubens            expires April 1999                  [Page 25]


INTERNET DRAFT                                             November 1998


      other than a session.

      The Session-Id MUST be globally unique at any given time since it
      is used by the server to identify the session (or flow). It is
      recommended that the format of the AVP be as follow:

      <Sender's IP Address><monotonically increasing 32 bit
      value><optional value>

      It is suggested that the monotonically increasing 32 bit value NOT
      start at zero upon reboot, but rather start at a random value.
      This will minimize the possibility of overlapping Session-Ids
      after a reboot. The optional value is implementation specific but
      may include a modem's device Id, a random value, etc.

      The session Id is created by the DIAMETER device initiating the
      session, which in most cases is done by the client. Note that a
      Session-Id can be used by more than one extension.

   AVP Format

      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           |     Reserved      |P|T|V|E|H|M|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Data ...
      +-+-+-+-+-+-+-+-+

      AVP Code

         263     Session-Id

      AVP Length

         The length of this attribute MUST be at least 9.

      AVP Flags

         The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
         upon the security model used. The 'V', 'T' and the 'P' bits
         MUST NOT be set.

      Data

         The Data field contains the session identifier assigned to the



Calhoun, Rubens            expires April 1999                  [Page 26]


INTERNET DRAFT                                             November 1998


         session.


3.12  Vendor-Name

   Description

      The Vendor-Name attribute is used in order to inform a DIAMETER
      peer of the Vendor Name of the DIAMETER device. This MAY be used
      in order to know which vendor specific attributes may be sent to
      the peer.

      It is also envisioned that the combination of the Vendor-Name and
      the Firmware-Revision AVPs can provide very useful debugging
      information.

   AVP Format

      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           |     Reserved      |P|T|V|E|H|M|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   String ...
      +-+-+-+-+-+-+-+-+

      AVP Code

         266     Vendor-Name

      AVP Length

         The length of this attribute MUST be at least 9.

      AVP Flags

         The 'H' and 'E' MAY be set depending upon the security model
         used. The 'M', 'V', 'T' and the 'P' bits MUST NOT be set.

      String

         The String field contains the vendor name.


3.13  Firmware-Revision




Calhoun, Rubens            expires April 1999                  [Page 27]


INTERNET DRAFT                                             November 1998


   Description

      The Firmware-Revision AVP is used to inform a DIAMETER peer of the
      firmware revision of the issuing device.

      For devices which do not have a firmware revision (general purpose
      computers running DIAMETER software modules, for instance), the
      revision of the DIAMETER software module may be reported instead.

   AVP Format

      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           |     Reserved      |P|T|V|E|H|M|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Integer32                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      AVP Code

         267     Firmware-Revision

      AVP Length

         The length of this attribute MUST be at least 12.

      AVP Flags

         The 'H' and 'E' MAY be set depending upon the security model
         used. The 'M', 'V', 'T' and the 'P' bits MUST NOT be set.

      Integer32

         The Integer32 field contains the firmware revision number of
         the issuing device.


3.14  Result-Code

   Description

      The Result-Code AVP is used in order to indicate whether a
      particular command was completed successfully or whether an error
      occurred. The Result-Code AVP MUST be present in all DIAMETER
      messages of type -Request or -Answer.



Calhoun, Rubens            expires April 1999                  [Page 28]


INTERNET DRAFT                                             November 1998


   AVP Format

      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           |     Reserved      |P|T|V|E|H|M|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Integer32                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      AVP Code

         268     Result-Code

      AVP Length

         The length of this attribute MUST be 12.

      AVP Flags

         The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
         upon the security model used. The 'V', 'T' and the 'P' bits
         MUST NOT be set.

      Integer32

         The Integer32 field contains the result code associated with
         the DIAMETER command. The following codes have been defined:

            DIAMETER_SUCCESS                0
               The Request was successfully completed.

            DIAMETER_FAILURE                1
               The Request was not successfully completed for an
               unspecified reason.  A DIAMETER Message-Reject message
               returning this result SHOULD whenever possible also
               contain one or more Failed-AVP-Code AVPs indicating the
               attributes which caused the failure.

            DIAMETER_POOR_REQUEST           2
               The Request was poorly constructed.  A DIAMETER Message-
               Reject message returning this result SHOULD whenever
               possible also contain one or more Failed-AVP-Code AVPs
               indicating the attributes which caused the failure.

            DIAMETER_INVALID_MAC            3



Calhoun, Rubens            expires April 1999                  [Page 29]


INTERNET DRAFT                                             November 1998


               The Request did not contain a valid Integrity-Check-
               Vector or Digital-Signature [12].

            DIAMETER_UNKNOWN_SESSION_ID     4
               The Request contained an unknown Session-Id.

            DIAMETER_SEE_ERROR_CODE         5
               The Request failed. The message MUST also contain an
               Error-Code AVP which provides command-specific
               information on the failure.  A DIAMETER Message-Reject-
               Ind message returning this result SHOULD whenever
               possible also contain one or more Failed-AVP-Code AVPs
               indicating the attributes which caused the failure.

            DIAMETER_COMMAND_UNSUPPORTED    6

               The  Request contained a command code which the DIAMETER
               implementation does not recognize or does not support.
               The Message-Reject-Ind message MUST also contain an
               Unrecognized-Command-Code AVP which contains the Command
               Code value which was rejected.

            DIAMETER_ATTRIBUTE_UNSUPPORTED  8

               The Request contained an AVP with an AVP Code which the
               DIAMETER implementation does not recognize or does not
               support. An DIAMETER Message-Reject-Ind message returning
               this result MUST also contain one or more Failed-AVP-Code
               AVPs indicating the AVP Codes which caused the failure.


3.15  Error-Code

   Description

      The Error-Code AVP contains the message specific error code, if
      any.  This AVP only needs to be present if the Result-Code AVP is
      present with the DIAMETER_SEE_ERROR_CODE.

      Error-Code values and corresponding semantics are specific to the
      command to which the Error-Code is a response, and MUST therefore
      be documented as part of the description of that command.

   AVP Format







Calhoun, Rubens            expires April 1999                  [Page 30]


INTERNET DRAFT                                             November 1998


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |     Reserved      |P|T|V|E|H|M|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Integer32                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      AVP Code

         269     Error-Code

      AVP Length

         The length of this attribute MUST be 12.

      AVP Flags

         The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
         upon the security model used. The 'V', 'T' and the 'P' bits
         MUST NOT be set.

      Integer32

         The Integer32 field contains the error code.


3.16  Unrecognized-Command-Code

   Description

      The Unrecognized-Command-Code AVP contains the offending Command
      Code that resulted in sending the Message-Reject-Ind message.

   AVP Format

      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           |     Reserved      |P|T|V|E|H|M|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Integer32                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Calhoun, Rubens            expires April 1999                  [Page 31]


INTERNET DRAFT                                             November 1998


      AVP Code

         270     Unrecognized-Command-Code

      AVP Length

         The length of this attribute MUST be 12.

      AVP Flags

         The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
         upon the security model used. The 'V', 'T' and the 'P' bits
         MUST NOT be set.

      Integer32

         The Integer32 field contains the unrecognized command code that
         resulted in sending an Message-Reject-Ind message.


3.17  Reboot-Type

   Description

      The Reboot-Type AVP MUST be present in the Device-Reboot-
      Indication message and contains an indication of the type of
      reboot.

   AVP Format

      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           |     Reserved      |P|T|V|E|H|M|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Integer32                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      AVP Code

         271     Reboot-Type

      AVP Length

         The length of this attribute MUST be 12.




Calhoun, Rubens            expires April 1999                  [Page 32]


INTERNET DRAFT                                             November 1998


      AVP Flags

         The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
         upon the security model used. The 'V', 'T' and the 'P' bits
         MUST NOT be set.

      Integer32

         The Integer32 field contains the reboot type associated with
         the DRI command. The following value are currently defined:

            REBOOT_IMMINENT                 1
               When the Reboot-Type AVP is set to this value it is an
               indication that the DIAMETER peer is about to reboot and
               should not be sent any additional DIAMETER messages
               besides the acknowledgement.

            REBOOTED                        2
               When the Reboot-Type AVP is set to this value it is an
               indication that the DIAMETER peer has recently rebooted
               and is ready to accept new DIAMETER messages.

            CLEAN_REBOOT                    3
               When the Reboot-Type AVP is set to this value the server
               is in the process of shutting down and MAY be available
               at some time in the future.


3.18  Reboot-Time

   Description

      The Reboot-Time AVP MAY be present in the DRI and indicates the
      number of seconds before the issuer expects to be ready to receive
      new DIAMETER messages. This AVP MUST only be present when the
      Reboot-Type AVP is set to REBOOT_IMMINENT. The value indicated by
      this AVP should be used as an estimate and is not a hard rule.

   AVP Format












Calhoun, Rubens            expires April 1999                  [Page 33]


INTERNET DRAFT                                             November 1998


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |     Reserved      |P|T|V|E|H|M|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Integer32                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      AVP Code

         272     Reboot-Time

      AVP Length

         The length of this attribute MUST be 12.

      AVP Flags

         The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
         upon the security model used. The 'V', 'T' and the 'P' bits
         MUST NOT be set.

      Integer32

         The Integer32 field contains the expected amount of seconds
         before the issuer of the DRI expects to be receive to receive
         new DIAMETER messages.


3.19  Failed-AVP-Code

   Description

      The Failed-AVP-Code AVP provides debugging information in cases
      where a request is rejected or not fully processed due to
      erroneous information in a specific AVP. The documentation of the
      Result-Code AVP and of the Message-Reject-Ind command provide
      information on the use of the Failed-AVP-Code AVP. This AVP has
      the following format:

   AVP Format








Calhoun, Rubens            expires April 1999                  [Page 34]


INTERNET DRAFT                                             November 1998


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |     Reserved      |P|T|V|E|H|M|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Data...
      +-+-+-+-+-+-+-+-+

      AVP Code

         279      Failed-AVP-Code

      AVP Length

         The length of this attribute MUST be 12.

      AVP Flags

         The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
         upon the security model used. The 'V', 'T' and the 'P' bits
         MUST NOT be set.

      Data

         The Data field contains the complete AVP that could not be
         processed successfully.Possible reasons for this are an
         improperly-constructed AVP, an unsupported or unrecognized AVP
         Code, or an invalid value.


3.20  User-Name

   Description

      This attribute contains the User-Name in a format consistent with
      the NAI specification [8].

      A summary of the User-Name AVP format is shown below. The fields
      are transmitted from left to right.

   AVP Format

      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, Rubens            expires April 1999                  [Page 35]


INTERNET DRAFT                                             November 1998


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |     Reserved      |P|T|V|E|H|M|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   String ...
      +-+-+-+-+-+-+-+-+

      Type

         1 for User-Name.

      AVP Length

         The length of this AVP MUST be at least 9.

      AVP Flags

         The 'M' bit MUST be set. The 'H' MAY be set, but the 'E' bit
         MUST NOT be set since proxy servers would have no knowledge of
         the user's domain. The 'V', 'T' and the 'P' bits MUST NOT be
         set.

      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
         [8].


4.0  Protocol Definition

   This section will describe how the base protocol works (or is at
   least an attempt to).


4.1  DIAMETER Bootstrap Message

   DIAMETER provides a message that is used to indicate either an
   imminent reboot, or that a reboot has occurred. The DRI message MUST
   be sent to all known DIAMETER peers both previous to a reboot when
   possible as well as following a reboot.

   The Reboot-Type AVP is used to indicate the type of reboot associated
   with the DRI. When set to REBOOT_IMMINENT, all peers should be warned
   that any new DIAMETER requests sent to the issuer will probably not
   be received or processed. If a request MUST be sent it would be
   preferable to issue the request to an alternate peer if available.




Calhoun, Rubens            expires April 1999                  [Page 36]


INTERNET DRAFT                                             November 1998


   The message includes an optional Reboot-Time AVP that specifies an
   estimate of how long before the issuer is available to receive new
   DIAMETER messages.

   Upon reboot, the host MUST issue a DRI message with the Reboot-Type
   AVP set to REBOOTED. This is an indication that new DIAMETER messages
   may be sent to the transmitter of the DRI.

   Note that the Reboot-Time AVP is not required, and when present
   provides an estimate and should not be used as a hard value. In the
   case of a software implementation (server) running on a general
   purpose operating system, the Reboot-Time AVP will probably not be
   present since it is possible that the DIAMETER server has been
   stopped and it is not possible to know how long before (and if) it
   will be restarted.

   Upon receipt of this message the peer's Ss and Sr variables must be
   reset.  It is possible for this message to be received outside the
   window (Ns and Nr set to zero) when it follows a reboot.

   The DIAMETER Reboot-Ind message does not require a reply. The message
   is acknowledged using DIAMETER's reliable transport.


4.2  Keepalive Exchange

   DIAMETER uses the Device-Watchdog-Ind message as a keepalive
   mechanism. DIAMETER entities that need to ensure that connectivity
   with a peer is not lost may use this mechanism.

   A DIAMETER Client can use this mechanism to ensure that failover to
   an alternate server occurs even without any AAA traffic. Redundant
   DIAMETER Servers use this mechanism to identify when the primary
   server is no longer available.

   The DIAMETER Device-Watchdog-Ind message does not require a reply.
   The message is acknowledged using DIAMETER's reliable transport.


4.3  Unrecognized Command Support

   The DIAMETER protocol provides a message that is used to inform a
   peer that a DIAMETER message was received with an unrecognized
   command. The following provides a DIAMETER message that is sent to a
   peer:






Calhoun, Rubens            expires April 1999                  [Page 37]


INTERNET DRAFT                                             November 1998


   <Take-A-Hike-Req> ::= <DIAMETER Header>
                         <Take-A-Hike-Req Command AVP>
                         <Host-IP-Address AVP>
                         [<Host-Name AVP>]
                         <Timestamp AVP>
                         <Initialization-Vector AVP>
                         {<Integrity-Check-Vector AVP> ||
                          <Digital-Signature AVP }

   Upon receipt of the above message, the receiver notices that it does
   not support the command and sends the following message:

   <Message-Reject-Ind> ::= <DIAMETER Header>
                            <Message-Reject-Ind Command AVP>
                            <Unrecognized-Command-Code AVP>
                            <Host-IP-Address AVP>
                            [<Host-Name AVP>]
                            <Timestamp AVP>
                            <Initialization-Vector AVP>
                            {<Integrity-Check-Vector AVP> ||
                             <Digital-Signature AVP }


4.4  The art of AVP Tagging

   The AVP Header provides the 'T' bit that is used for grouping AVPs
   together. Although the base protocol does not define any AVPs that
   need to be grouped, it is envisioned that DIAMETER extensions will
   require tag support.

   In the case where multiple AVPs are needed to indicate a specific
   authorization "rule" tagging is appropriate. Such an example is taken
   from [10] that discusses Tunneling attributes. In this case multiple
   AVPs are required in order to specify tunnel parameter, and more than
   one set of AVPs MAY be present in the message. This is necessary in
   order to support redundant tunnel servers.

   In this case, the AVPs that need to be grouped together would have a
   specific tag value, and each group would use a different tag value.


4.5  Using the Integrity-Check-Vector

   The use of the Integrity-Check-Vector (ICV) AVP requires a pre-
   configured shared secret. Although this mechanism does not scale as
   well as the Digital Signature,  it may be desirable to use this
   mechanism in the case where asymmetric technology is not required or
   available.



Calhoun, Rubens            expires April 1999                  [Page 38]


INTERNET DRAFT                                             November 1998


   Note that in the case where two DIAMETER nodes need to communicate
   through an intermediate node (i.e. Proxy) it does not offer any end-
   to-end data integrity or encryption as each node must re-compute the
   Integrity-Check-Vector AVP.

   The Data field of the AVP contains an HMAC-MD5-96[6] of the message
   up to the ICV AVP. Using the example code provided in [6], the
   following call would be used to generate the Integrity-Check-Vector:

   The Timestamp and Initialization-Vector AVPs MUST be present in the
   message PRIOR to the Integrity-Check-Vector AVP. The Timestamp AVP
   provides replay protection and the Initialization-Vector AVP provides
   randomness.

      hmac_md5(DiameterMessage, MessageLength, Secret, Secretlength,
               Output)

   The following is an example of a message that include hop-by-hop
   security:

   <DIAMETER Message> ::= <DIAMETER Header>
                          <DIAMETER-Command AVP>
                          [<Additional AVPs>]
                          <Timestamp AVP>
                          <Initialization-Vector AVP>
                          <Integrity-Check-Vector AVP>

   Any AVPs in a message that is not succeeded by the Integrity-Check-
   Vector AVP MUST be ignored.


4.6  AVP Encryption with Shared Secrets

   This method of encrypting AVP data is the simplest to use and MUST be
   supported by all DIAMETER implementations. However, local policy MAY
   determine that the use of this mechanism is not permitted.

   The 'H' bit MUST only be set if a shared secret exists between both
   DIAMETER peers. If the 'H' bit is set in any DIAMETER AVP, the
   Initialization-Vector AVP MUST be present prior to the first
   encrypted AVP.

   The length of the AVP value to be encrypted is first encoded in the
   following Subformat, which is included in the AVP's data field.







Calhoun, Rubens            expires April 1999                  [Page 39]


INTERNET DRAFT                                             November 1998


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Length of ClearText Data    |       ClearText Data ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Padding ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length

      The Length field contains the length of the decrypted data.

   ClearText Data

      Data of AVP that is to be obscured.

   Padding

      Random additional octets used to obscure length of the ClearText
      Data.

   The resulting subformat MAY be padded to a multiple of 16 octets in
   length. For example, if the ClearText Data to be obscured is a string
   containing 6 characters (e.g. password 'foobar'), then 8 + n * 16
   octets of padding would be applied. Padding does NOT alter the value
   placed in the Length of the ClearText Data, only the length of the
   AVP itself.

   Next, An MD5 hash is performed on the concatenation of:

      - the two octet Command Code of the AVP
      - the shared authentication secret
      - an arbitrary length random vector

   The value of the random vector used in this hash is passed in the
   Data field of a Initialization-Vector AVP.  This Initialization-
   Vector AVP must appear in the message before any hidden AVPs. The
   same Initialization-Vector may be used for more than one hidden AVP
   in the same message.  If a different Initialization-Vector is used
   for the hiding of subsequent AVPs then a new Initialization-Vector
   AVP must be placed before the first AVP to which it applies.

   The MD5 hash value is then XORed with the first 16 octet or less
   segment of the AVP Subformat and placed in the Data field of the AVP.
   If the AVP Subformat is less than 16 octets, the Subformat is
   transformed as if the Value field had been padded to 16 octets before
   the XOR, but only the actual octets present in the Subformat are
   modified, and the length of the AVP is not altered.



Calhoun, Rubens            expires April 1999                  [Page 40]


INTERNET DRAFT                                             November 1998


   If the Subformat is longer than 16 octets, a second one-way MD5 hash
   is calculated over a stream of octets consisting of the shared secret
   followed by the result of the first XOR.  That hash is XORed with the
   second 16 octet or less segment of the Subformat and placed in the
   corresponding octets of the Data field of the AVP.

   If necessary, this operation is repeated, with each XOR result being
   used along with the shared secret to generate the next hash to XOR
   the next segment of the value with.  This technique results in the
   content of the AVP being obscured, although the length of the AVP is
   still known.

   On receipt, the Initialization-Vector is taken from the last
   Initialization-Vector AVP encountered in the message prior to the AVP
   to be decrypted. The above process is then reversed to yield the
   original value.  For more details on this hiding method, consult
   RFC2138 [1].

   Please note that in the case where the DIAMETER message needs to be
   processed by an intermediate non-trusted DIAMETER server (also known
   as a proxy server, depicted as DIA2 in the figure below) the AVP
   needs to be decrypted using Shared-Secret-1 and re-encrypted by DIA2
   using Shared-Secret-2.

               (Shared-Secret-1)          (Shared-Secret-2)
      +------+       ----->      +------+      ------>      +------+
      |      |                   |      |                   |      |
      | DIA1 +-------------------+ DIA2 +-------------------+ DIA3 |
      |      |                   |      |                   |      |
      +------+                   +------+                   +------+

   Unfortunately in this case the non-trusted server DIA2 has access to
   sensitive information (such as a password).


5.0  References

    [1] Rigney, et alia, "RADIUS", RFC-2138, April 1997
    [2] Reynolds, Postel, "Assigned Numbers", RFC 1700,
        October 1994.
    [3] Postel, "User Datagram Protocol", RFC 768, August 1980.
    [4] Rivest, Dusse, "The MD5 Message-Digest Algorithm",
        RFC 1321, April 1992.
    [5] Kaufman, Perlman, Speciner, "Network Security: Private
        Communications in a Public World", Prentice Hall,
        March 1995, ISBN 0-13-061466-1.
    [6] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for Message
        Authentication", RFC 2104, January 1997.



Calhoun, Rubens            expires April 1999                  [Page 41]


INTERNET DRAFT                                             November 1998


    [7] Calhoun, Bulley, "DIAMETER User Authentication Extensions",
        draft-calhoun-diameter-authen-04.txt, Work in Progress,
        August 1998.
    [8] Aboba, Beadles, "Network Address Identifier", Internet-Draft,
        draft-ietf-roamops-nai-10.txt, Work in Progress,
        February 1998.
    [9] Calhoun, Zorn, Pan, "DIAMETER Framework",
        draft-calhoun-diameter-framework-01.txt, Work in Progress,
        August 1998
    [10] Zorn, Leifer, Rubens, Shriver, "RADIUS attributes for
         Tunnel Protocol Support",
         draft-ietf-radius-tunnel-auth-05.txt, Work in Progress,
         April 1998.
    [11] Calhoun, Bulley, "DIAMETER Reliable Transport Extension",
         draft-calhoun-diameter-reliable-00.txt,
         Work in Progress,  August 1998.
    [12] Calhoun, Bulley, "DIAMETER Proxy Extension",
         draft-calhoun-diameter-proxy-00.txt, Work in Progress,
         August 1998.


6.0  Acknowledgements

   The Authors would like to acknowledge the following people for their
   contribution in the development of the DIAMETER protocol:

   Bernard Aboba, Jari Arkko, William Bulley, Daniel C. Fox, Lol Grant,
   Ignacio Goyret, Nancy Greene, Erik Guttman, Peter Heitman, Fergal
   Ladley, Ryan Moats, Victor Muslin, Kenneth Peirce, Nenad Trifunovic,
   Sumit Vakil, John R. Vollbrecht, Jeff Weisberg and Glen Zorn


7.0  Author's Address

   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-650-786-7733
         Fax:  1-650-786-6445
      E-mail:  pcalhoun@eng.sun.com





Calhoun, Rubens            expires April 1999                  [Page 42]


INTERNET DRAFT                                             November 1998


      Allan C. Rubens
      Ascend Communications
      1678 Broadway
      Ann Arbor, MI 48105-1812
      USA

       Phone:  1-734-761-6025
      E-Mail:  acr@del.com











































Calhoun, Rubens            expires April 1999                  [Page 43]


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