[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 Microsystems, Inc.
Title: draft-calhoun-diameter-02.txt                      Allan C. Rubens
Date: March 1998                                    Ascend Communications



                                       DIAMETER
                                    Base Protocol
                           <draft-calhoun-diameter-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

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

   This  draft  MUST  be  supported  by  all  DIAMETER   implementations,
   regardless of the specific underlying service.













Calhoun, Rubens              expires September 1998              [Page 1]


INTERNET DRAFT                                                 March 1998


Table of Contents

      1.0    Introduction
      1.1    Definitions
      2.0    Packet Format
      3.0    DIAMETER AVP Format
      4.0    DIAMETER AVPs
      4.1    DIAMETER-Command AVP
      4.1.1  Command-Unrecognized
      4.1.2  Device-Reboot-Indication
      4.1.3  Device-Reboot-Ack
      4.1.4  Device-Feature-Request
      4.1.5  Device-Feature-Response
      4.2    Host-IP-Address
      4.3    Host-Name
      4.4    Version-Number
      4.5    Supported-Extension
      4.6    Integrity-Check-Vector
      4.7    Digital-Signature
      4.8    Initialization-Vector
      4.9    Timestamp
      4.10   Session-Id
      4.11   X509-Certificate
      4.12   X509-Certificate-URL
      4.13   Vendor-Name
      4.14   Firmware-Revision
      5.0    Protocol Definition
      5.1    Data Integrity
      5.1.1  Using Integrity-Check-Vector
      5.1.2  Using Digital Signatures
      5.1.3  Using Mixed Data Integrity AVPs
      5.2    AVP Data Encryption
      5.2.1  AVP Encryption with Shared Secrets
      5.2.2  AVP Encryption with Public Keys
      5.3    Public Key Cryptography Support
      5.3.1  X509-Certificate
      5.3.2  X509-Certificate-URL
      5.3.3  Static Public Key Configuration
      6.0    References
      7.0    Acknowledgements
      8.0    Author's Address


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 WEB clients, etc), a more  extensible  protocol  was
   necessary  which  could  support  new  services  being deployed in the
   internet and corporate networks.


Calhoun, Rubens              expires September 1998              [Page 2]


INTERNET DRAFT                                                 March 1998


   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. 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 [8] which defines extensions to
   the base protocol to support user authentication and [x] 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
             which does include the option.


2.0 DIAMETER Header Format

   DIAMETER packets MAY be transmitted over  UDP  or  TCP.  Each  Service
   Extensions  draft  SHOULD specify the transport layer. The destination
   port field for DIAMETER is 1645.

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



Calhoun, Rubens              expires September 1998              [Page 3]


INTERNET DRAFT                                                 March 1998


   A summary of the DIAMETER data 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  RADIUS PCC   |PKT Flags| Ver |         Packet Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Identifier                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Attributes ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-

   RADIUS PCC (Packet Compatibility Code)

      The RADIUS PCC  field is a one octet field which is used for RADIUS
      backward  compatibility.  In  order  to easily distinguish DIAMETER
      packets from RADIUS a special value has been reserved and allows an
      implementation  to  support  both  protocols  concurently 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 set initialized to zero.
      No flags are defined at this time.

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

   Identifier

      The Identifier field is four octets, and aids in matching  requests
      and  replies.  The  identifier MUST be unique at any given time and
      one mechanism to ensure this is to use a  monotonically  increasing
      number.  Given the size of the Identifier field it is unlikely that
      2^32 requests could be outstanding at any given time.


Calhoun, Rubens              expires September 1998              [Page 4]


INTERNET DRAFT                                                 March 1998


   Attributes

      See section 3.0 for more information of attribute formats.


3.0 DIAMETER AVP Format

   DIAMETER   Attributes   carry   the   specific   authentication    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  by  each  such  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 accordingly. The Padding size can be
   deduced using the following formula:

      padding_size = Length % 4

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

   A summary of the 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     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Vendor ID (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 257 and above are used for DIAMETER. Each service  MUST
      allocate AVP numbers through the IANA.



Calhoun, Rubens              expires September 1998              [Page 5]


INTERNET DRAFT                                                 March 1998


      If the Vendor ID bit 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 Address Type, AVP Length, AVP Flags,
      Reserved, Vendor ID if present and the AVP data.  If  a  packet  is
      received  with  an  Invalid  attribute length, the packet SHOULD be
      rejected.

   AVP Flags

      The AVP Flags field informs the DIAMETER host  how  each  attribute
      must be handled. The following values are currently defined:

         Mandatory-Support   1
            The receiver MUST support this attribute. If the attribute is
            NOT  supported,  the  device MUST reject the Command. If this
            flag is not set, then the receiver  MAY  accept  the  command
            regardless  of  whether  or  not  the particular attribute is
            recognized.

         SS-Encrypted-Data   2
            If this bit is  set,  the  contents  of  the  attributes  are
            encrypted. Note that the attribute header is NOT encrypted in
            this case. See section 5.2 for more information.

         PK-Encrypted-Data   4
            If this bit is  set,  the  contents  of  the  attributes  are
            encrypted. Note that the attribute header is NOT encrypted in
            this case. See section 5.2 for more information.

         Vendor-Specific-AVP 8
            If this bit is set, the optional  Vendor  ID  field  will  be
            present  in  the  AVP header and the AVP Code MUST be treated
            accordingly.

   Reserved

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

   Vendor ID

      The optional four octet Vendor  ID  field  contains  the  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.


Calhoun, Rubens              expires September 1998              [Page 6]


INTERNET DRAFT                                                 March 1998


      The value 0, reserved in this protocol, corresponds to IETF adopted
      Attribute values, defined within this document and MUST NOT be used
      in an AVP since it is implied  with  the  absence  of  the  Vendor-
      Specific-AVP bit.

   Data

      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-65526 octets of arbitrary data.

      String

         0-65526 octets of string data in some agreed upon char set.

      Address

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

      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.


4.0 DIAMETER AVPs

   This section will define the mandatory AVPs which 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:



Calhoun, Rubens              expires September 1998              [Page 7]


INTERNET DRAFT                                                 March 1998


      Attribute Name       Attribute Code
      -----------------------------------
      DIAMETER-Command          256
      Host-IP-Address             4
      Host-Name                  32
      Supported-Extension       258
      Integrity-Check-Vector    259
      Digital-Signature         260
      Initialization-Vector     261
      Timestamp                 262
      Session-Id                263
      X509-Certificate          264
      X509-Certificate-URL      265
      Vendor-Name               266
      Firmware-Revision         267


4.1 DIAMETER-Command AVP

   Description

      The 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. There MUST only be  a  single  Command
      AVP within a given message. 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           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Command Code          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code

      256     DIAMETER-Command

   AVP Length

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

   AVP Flags

      The flag field MUST have bit  1  (Mandatory  Support)  set.  Bit  2
      (Encrypted  AVP)  SHOULD NOT be set. The optional Vendor ID bit MAY


Calhoun, Rubens              expires September 1998              [Page 8]


INTERNET DRAFT                                                 March 1998


      be set if the command is vendor-specific.

   Reserved

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

   Command Code

      The Command Code field contains the command number.  The  following
      commands are defined in this document:

      The  following  commands  MUST  be  supported   by   all   DIAMETER
      implementations   in   order   to  conform  to  the  base  protocol
      specification:

         Command Name          Command Code
         -----------------------------------
         Command-Unrecognized      256
         Device-Reboot-Indication  257
         Device-Reboot-Ack         258
         Device-Feature-Query      259
         Device-Feature-Response   260


4.1.1 Command-Unrecognized

   Description

      Messages with the  Command-Unrecognized  AVP  MUST  be  sent  by  a
      DIAMETER device to inform its peer that a message was received with
      an unsupported Command AVP value.

      Since there certainly will exist a case where  an  existing  device
      does not support a new extension to the DIAMETER protocol, a device
      which receives a packet with  an  unrecognized  Command  code  MUST
      return a Command-Unrecognized packet.

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

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Command Code          |   Unrecognized Command  Code  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Calhoun, Rubens              expires September 1998              [Page 9]


INTERNET DRAFT                                                 March 1998


   AVP Code

      256     DIAMETER Command

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flags

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

   Command Code

      The Command Code field MUST be set to 256 (Command-Unrecognized).

   Unrecognized Command Code

      The Unrecognized Command Code field MUST contain the  Command  Code
      that resulted in this message.


4.1.2 Device-Reboot-Indication

   Description

      The Device-Reboot-Indication message is sent by a  DIAMETER  device
      to  inform  all  of  its  peers that it has rebooted. The peer MUST
      respond to the message with a successful acknowledgement. Note that
      a  device  MUST  only send this message once it is ready to receive
      packets.

      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


Calhoun, Rubens             expires September 1998              [Page 10]


INTERNET DRAFT                                                 March 1998


      described above) in the response to the initiator.

      It is desireable 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  MAY  contain  the  Version-Number,  Vendor-Name  and
      Supported-Extension AVPs.

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

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Command Code          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code

      256     DIAMETER Command

   AVP Length

      The length of this attribute MUST be 10.

   AVP Flags

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

   Command Code

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


4.1.3 Device-Reboot-Ack

   Description

      The Device-Reboot-Ack message is  sent  by  a  DIAMETER  device  to
      acknowledge  the  receipt  of the Device-Reboot-Indication message.
      The originator of this message MUST  include  the  highest  support
      version  number  (up  to and including the value in the request) in
      the DIAMETER header as well as all supported extensions (as long as
      they were present in the requesting message).


Calhoun, Rubens             expires September 1998              [Page 11]


INTERNET DRAFT                                                 March 1998


      This  message  MAY  contain  the  Version-Number,  Vendor-Name  and
      Supported-Extension AVPs.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Command Code          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code

      256     DIAMETER Command

   AVP Length

      The length of this attribute MUST be 10.

   AVP Flags

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

   Command Code

      The Command Code field MUST be set to 258 (Device-Reboot-Ack).


4.1.4 Device-Feature-Query

   Description

      The Device-Feature-Query message is used in order to query  a  peer
      about  it's  supported  extensions.  This  message  MAY contain the
      Version-Number, Vendor-Name and Supported-Extension AVPs.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Command Code          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code



Calhoun, Rubens             expires September 1998              [Page 12]


INTERNET DRAFT                                                 March 1998


      256     DIAMETER Command

   AVP Length

      The length of this attribute MUST be 10.

   AVP Flags

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

   Command Code

      The Command Code field MUST be set to 259 (Device-Feature-Request).


4.1.5 Device-Feature-Response

   Description

      The Device-Feature-Response message is  sent  in  response  to  the
      Device-Feature-Query  message.  This message includes all supported
      extensions by the responder and  MAY  contain  the  Version-Number,
      Vendor-Name and Supported-Extension AVPs.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Command Code          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AVP Code

      256     DIAMETER Command

   AVP Length

      The length of this attribute MUST be 10.

   AVP Flags

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

   Command Code

      The  Command  Code  field  MUST  be  set  to  260  (Device-Feature-
      Response).


Calhoun, Rubens             expires September 1998              [Page 13]


INTERNET DRAFT                                                 March 1998


4.2 Host-IP-Address

   Description

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

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

   AVP Code

      4     Host-IP-Address

   AVP Length

      The length of this attribute MUST be at least 12.

   AVP Flags

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

   Address

      The Address field contains the sender's IP address.


4.3 Host-Name

   Description

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

      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, Rubens             expires September 1998              [Page 14]


INTERNET DRAFT                                                 March 1998


   AVP Code

      32     Host-Name

   AVP Length

      The length of this attribute MUST be at least 9.

   AVP Flags

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

   String

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


4.4 Version-Number

   Description

      The Version-Number AVP is used in order  to  indicate  the  current
      DIAMETER system version number to a peer.

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

   AVP Code

      257     Version-Number

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flags

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

   Integer32



Calhoun, Rubens             expires September 1998              [Page 15]


INTERNET DRAFT                                                 March 1998


      The Integer32 field contains the system version number.


4.5 Supported-Extension

   Description

      The Supported-Extension AVP  is  used  to  inform  a  peer  of  the
      supported  extensions.  Note  that  each supported extensions draft
      MUST  have  an  identifier  assigned.  The  base  protocol  is  not
      considered an extension since its support is mandatory.

      Each DIAMETER Extension draft will be assigned an extension  number
      by  the  IANA. The value of the extension number is passed along in
      this AVP. There MAY be more than one Supported-Extension AVP within
      a DIAMETER message.

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

   AVP Code

      258     Supported-Extension

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flags

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

   Integer32

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


4.6 Integrity-Check-Vector

   Description

      The   Integrity-Check-Vector   AVP   is   used    for    hop-by-hop


Calhoun, Rubens             expires September 1998              [Page 16]


INTERNET DRAFT                                                 March 1998


      authentication and integrity, and is not recommended for  use  with
      untrusted proxy servers.

      The DIAMETER header as well as all AVPs up to and including the AVP
      Code field of this AVP is protected by the ICV.

      The ICV is generated in the method described in section 5.1.1.

      All DIAMETER implementations MUST support this AVP.

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

   AVP Code

      259     Integrity-Check-Vector

   AVP Length

      The length of this attribute MUST be at least 9.

   AVP Flags

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

   Data

      The Data field contains an HMAC-MD5-96[6] of the message up to  and
      including the attribute type field of this AVP.

4.7 Digital-Signature

   Description

      The Digital-Signature AVP is used for authentication, integrity  as
      well as non-repudiation. The DIAMETER header as well as all AVPs up
      to and including the AVP Code field of this AVP is protected by the
      Digital-Signature.

      Note that for services which use the  concept  of  a  proxy  server
      which  forwards  the request to a next hop server, the proxy server
      MUST NOT modify any attributes found prior to the Digital-Signature
      AVP.  This  ensures  that  end-to-end  security  is maintained even


Calhoun, Rubens             expires September 1998              [Page 17]


INTERNET DRAFT                                                 March 1998


      through proxy arrangements.

      The Digital-Signature is  generated  in  the  method  described  in
      section 5.1.2.

      All DIAMETER implementations SHOULD support this AVP.

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

   AVP Code

      260     Digital-Signature

   AVP Length

      The length of this attribute MUST be at least 9.

   AVP Flags

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

   Address

      The Address field contains the address of the DIAMETER  host  which
      generated the Digital-Signature.

   Data

      The Data field contains the digital signature of the packet  up  to
      and including the attribute type field within this AVP.


4.8 Initialization-Vector

   Description

      The Initialization-Vector AVP MUST be present prior to the Digital-
      Signature  and  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 128 bit value.


Calhoun, Rubens             expires September 1998              [Page 18]


INTERNET DRAFT                                                 March 1998


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |  AVP Flags  |    Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Data ...
      +-+-+-+-+-+-+-+-+

   AVP Code

      261     Initialization-Vector

   AVP Length

      The length of this attribute MUST be 24.

   AVP Flags

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

   Data

      The Data field contains a random 128 bit value.


4.9 Timestamp

   Description

      The Timestamp field is used in order to enable replay protection of
      previous  messages.  The value of time is the most significant four
      octets returned from an NTP server which indicates  the  number  of
      seconds expired since Jan. 1, 1970.

      This document does not specify the window which  an  implementation
      will accept packets, however it is strongly encouraged to make this
      value user configurable with a reasonable  default  value  (i.e.  4
      seconds).

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


Calhoun, Rubens             expires September 1998              [Page 19]


INTERNET DRAFT                                                 March 1998


   AVP Code

      262     Timestamp

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flags

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

   Time

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


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

      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
      other than a session.

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

   AVP Code

      263     Session-Id

   AVP Length

      The length of this attribute MUST be 12.

   AVP Flags


Calhoun, Rubens             expires September 1998              [Page 20]


INTERNET DRAFT                                                 March 1998


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

   Integer32

      The Integer32 field contains the session identifier assigned to the
      session.


4.11 X509-Certificate

   Description

      The X509-Certificate is used in order to send a DIAMETER  peer  the
      local  system's  X.509 certificate chain, which is used in order to
      validate the Digital-Signature attribute.

      Section  5.3  contains  more   information   about   the   use   of
      certificates.

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

   AVP Code

      264     X509-Certificate

   AVP Length

      The length of this attribute MUST be at least 9.

   AVP Flags

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

   Data

      The Data field contains the X.509 Certificate Chain.


4.12 X509-Certificate-URL

   Description



Calhoun, Rubens             expires September 1998              [Page 21]


INTERNET DRAFT                                                 March 1998


      The X509-Certificate-URL is used in order to send a DIAMETER peer a
      URL to the local system's X.509 certificate chain, which is used in
      order to validate the Digital-Signature attribute.

      Section  5.3  contains  more   information   about   the   use   of
      certificates.

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

   AVP Code

      265     X509-Certificate-URL

   AVP Length

      The length of this attribute MUST be at least 9.

   AVP Flags

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

   String

      The String field contains the X.509 Certificate Chain URL.


4.13 Vendor-Name

   Description

      The Vendor-Name attribute is used in order  to  inform  a  DIAMETER
      peer of the Vendor of the DIAMETER protocol stack. 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.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Calhoun, Rubens             expires September 1998              [Page 22]


INTERNET DRAFT                                                 March 1998


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

   AVP Code

      266     Vendor-Name

   AVP Length

      The length of this attribute MUST be at least 9.

   AVP Flags

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

   String

      The String field contains the vendor name.


4.14 Firmware-Revision

   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.

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

   AVP Code

      267     Firmware-Revision

   AVP Length


Calhoun, Rubens             expires September 1998              [Page 23]


INTERNET DRAFT                                                 March 1998


      The length of this attribute MUST be at least 12.

   AVP Flags

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

   Integer32

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


5.0 Protocol Definition

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


5.1 Data Integrity

   This section will describe how data integrity is  achieved  using  the
   Data Integrity AVPs.

   Note that the Timestamp and Initialization-Vector AVPs MUST be present
   in  the  message  PRIOR to any of the Data Integrity AVPs discussed in
   this section.


5.1.1 Using Integrity Check Vector

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

   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  and  including  the  attribute  type  field  of the AVP. Using the
   example code provided in [6], the following  call  would  be  used  to
   generate the ICV:

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

   The Timestamp attribute provides replay protection and this  AVP  MUST
   be  present  prior  to the Integrity-Check-Vector AVP. In addition the


Calhoun, Rubens             expires September 1998              [Page 24]


INTERNET DRAFT                                                 March 1998


   Initialization Vector AVP MUST also be present prior to the Integrity-
   Check-Vector AVP in order to provide some randomness.


5.1.2 Using Digital Signatures

   In the case of a simple peer to peer relationship the use of IPSEC  is
   sufficient  for  data integrity and non-repudiation. However there are
   instances where a peer must communicate with another peer through  the
   use  of  a proxy server. IPSEC does not provide a mechanism to protect
   traffic when two peers must use an intermediary node to communicate at
   the  application  layer  therefore  the  Digital-Signature AVP MUST be
   used.

   The following diagram shows  an  example  of  a  router  initiating  a
   DIAMETER  message  to  DIA1.  Once  DIA1  has  finished processing the
   message it adds its signature and forwards the  message  to  the  non-
   trusted DIA2 proxy server. If DIA2 needs to add or change any muteable
   AVPs it SHOULD add its digital signature before forwarding the message
   to DIA3.

      +------+  ----->  +------+  ----->  +------+  ----->  +------+
      |      |          |      |          | non- |          |      |
      |router+----------+ DIA1 +----------+trustd+----------+ DIA3 +
      |      |          |      |          | DIA2 |          |      |
      +------+  <-----  +------+  <-----  +------+  <-----  +------+

   Since some fields within the DIAMETER header will  change  "en  route"
   towards  the  final  DIAMETER  destination, it is necessary to set the
   mutable fields to zero (0) prior to calculating the signature. The two
   mutable fields are the identifier and the length.

   The Timestamp attribute provides replay protection and this  AVP  MUST
   be  present  prior  to  the  Digital  Signature  AVP.  In addition the
   Initialization Vector AVP MUST also be present prior  to  the  Digital
   Signature AVP in order to provide some randomness.

   Note that Digital Signatures only protect the DIAMETER header as  well
   as  all  AVPs  found  prior  to the digital signature. It is therefore
   possible to have AVPs following the digital signature  and  these  are
   considered unprotected.

   The Data field of  the  Digital-Signature  AVP  contains  the  RSA/MD5
   signature algorithm as defined in [9].


5.1.3 Using Mixed Data Integrity AVPs

   Both previous sections describe the differences between the Integrity-
   Check-Vector  and  the Digital-Signature AVP. Note that it is valid to


Calhoun, Rubens             expires September 1998              [Page 25]


INTERNET DRAFT                                                 March 1998


   use both within a single DIAMETER message.

   In the case where an intermediate DIAMETER server is used to reach the
   end  DIAMETER  Server, the Integrity-Check-Vector AVP provides hop-by-
   hop integrity and requires that each set of  DIAMETER  peers  share  a
   secret.

   The Digital-Signature AVP provides end-to-end integrity  and  requires
   knowledge of all parties public keys.

   If both  AVPs  co-exist  within  a  single  DIAMETER  message,  it  is
   necessary  to  ensure  that the Digital-Signature appears prior to the
   Integrity-Check-Vector since the ICV will be removed by the next hop.

            <Shared-Secret>    <Public-Key>
      +------+  ----->  +------+  ----->  +------+
      |      |          |      |          |      |
      |router+----------+ DIA1 +----------+ DIA2 +
      |      |          |      |          |      |
      +------+  <-----  +------+  <-----  +------+

   There are cases, such as in remote access, where the device initiating
   the  DIAMETER  request  does not have the processing power to generate
   Digital-Signatures  as  required  by  the   protocol.   In   such   an
   arrangement,  there normally exists a first hop DIAMETER Server (DIA1)
   which acts as a proxy to relay the request to the final authenticating
   DIAMETER server (DIA2). It is valid for the first hop server to remove
   the Integrity-Check-Vector AVP inserted by the router and  replace  it
   with a Digital-Signature AVP.


5.2 AVP Data Encryption

   DIAMETER supports two methods of encrypting AVP data. One is  using  a
   shared secret and the other is used with private keys.

   This feature can be used to encrypt sensitive data such as  user  ID's
   and passwords. The Encryption bits MUST NOT be set in the Command Type
   or Initialization-Vector AVPs.


5.2.1 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 SS-Encrypted-Data bit MUST only be set if a shared  secret  exists
   between  both  DIAMETER  peers. If the SS-Encrypted-Data bit is set in
   any DIAMETER AVP, the Initialization-Vector AVP MUST be present  prior


Calhoun, Rubens             expires September 1998              [Page 26]


INTERNET DRAFT                                                 March 1998


   to the first encrypted AVP.

   The length of the AVP value to be encrypted is first  encoded  in  the
   following Subformat:

       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
   octects  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 2 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 be placed in the message by the sender before  any  hidden  AVPs.
   The  same  IV  may  be  used  for more than one hidden AVP in the same
   message.  If a different IV 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


Calhoun, Rubens             expires September 1998              [Page 27]


INTERNET DRAFT                                                 March 1998


   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.

   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 IV 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.2.2 AVP Encryption with Public Keys

   AVP encryption using  public  keys  is  much  more  complex  than  the
   previously  decribed  method,  yet  it is desirable to use it in cases
   where  the  DIAMETER  message  will  be  processed  by  an   untrusted
   intermediate node (proxy).

   Public Key encryption SHOULD be supported, however it  is  permissible
   for a low powered device initiating the DIAMETER message to use shared
   secret encryption with the first hop (proxy)  DIAMETER  server,  which
   would decrypt and encrypt using the Public Key method.



Calhoun, Rubens             expires September 1998              [Page 28]


INTERNET DRAFT                                                 March 1998


   The PK-Encrypted-Data bit MUST only be set if the final DIAMETER  host
   is  aware  of the sender's public key. This information can be relayed
   in three different methods as described in section 5.3.

   The AVP is encrypted in the method described in [9].


5.3 Public Key Cryptography Support

   A DIAMETER peer's public key  is  required  in  order  to  validate  a
   message  which includes the the Digital-Signature AVP. There are three
   possibilities on retrieving public keys:

5.3.1 X509-Certificate

   A message which includes a Digital-Signature  MAY  include  the  X509-
   Certificate AVP. Given the size of a typical certificate, this is very
   wasteful and in most cases DIAMETER peers would cache such information
   in order to minimize per packet processing overhead.

   It is  however  valid  for  a  DIAMETER  host  to  provide  its  X509-
   Certificate  in certain cases, such as when issuing the Device-Reboot-
   Indication. It is envisioned that the peer would  validate  and  cache
   the certificate at that time.


5.3.2 X509-Certificate-URL

   The X509-Certificate-URL is a method for a  DIAMETER  host  sending  a
   message  that  includes  the Digital-Signature to provide a pointer to
   its certificate.

   Upon receiving such a message a DIAMETER host MAY choose  to  retrieve
   the  certificate if it is not locally cached. Of course the process of
   retrieving and validating a certificate is lengthy  and  will  require
   the  initiator  of the message to retransmit the request. However once
   cached the certificate can be used until it expires.


5.3.3 Static Public Key Configuration

   Given that using certificates requires a PKI infrastructure  which  is
   very  costly,  it  is  also possible to use this technology by locally
   configuring DIAMETER peers public keys.

   Note that in a network involving many DIAMETER proxies  this  may  not
   scale well.


6.0 References


Calhoun, Rubens             expires September 1998              [Page 29]


INTERNET DRAFT                                                 March 1998


    [1] Rigney, et alia, "RADIUS", RFC-2138, Livingston, April 1997
    [2] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1700,
        USC/Information Sciences Institute, October 1994.
    [3] Postel, J., "User Datagram Protocol", RFC 768, USC/Information
        Sciences Institute, August 1980.
    [4] Rivest, R., and S. Dusse, "The MD5 Message-Digest Algorithm",
        MIT Laboratory for Computer Science and RSA Data Security,
        Inc., RFC 1321, April 1992.
    [5] Kaufman, C., Perlman, R., and Speciner, M., "Network Security:
        Private Communications in a Public World", Prentice Hall,
        March 1995, ISBN 0-13-061466-1.
    [6] Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed-Hashing
        for Message Authentication", RFC 2104, January 1997.
    [7] P. Calhoun, "DIAMETER User Authentication Extensions",
        draft-calhoun-diameter-authen-01.txt, March 1998.
    [8] B. Aboba, M. Beadles, "Network Address Identifier",
        draft-ietf-roamops-nai-10.txt, February 1998.
    [9] B. Kaliski, "PKCS #1: RSA Encryption Version 1.5",
        draft-hoffman-pkcs-rsa-encrypt-03.txt, October 1997.


7.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,
   Nancy  Greene,  Peter  Heitman,  Ryan  Moats,  Victor  Muslin, Kenneth
   Peirce, Sumit Vakil, John R. Vollbrecht, Jeff Weisberg and Glen Zorn


8.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-847-548-9587
         Fax:  1-650-786-6445
      E-mail:  pcalhoun@toast.net


      Allan C. Rubens
      Ascend Communications
      1678 Broadway


Calhoun, Rubens             expires September 1998              [Page 30]


INTERNET DRAFT                                                 March 1998


      Ann Arbor, MI 48105-1812
      USA

       Phone: 1-734-647-0417
      E-Mail: acr@del.com















































Calhoun, Rubens             expires September 1998              [Page 31]


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