[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-01.txt                         Allan Rubens
Date: March 1998                                      Merit Networks Inc.



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

   This original document was named Enhanced RADIUS and  was  changed  at
   the  request  of  the  WG  since  this  protocol is different from the
   former.

   This document describes a management  protocol  used  between  Network
   Access Servers and DIAMETER Servers for authentication, authorization,
   and accounting of dial-up users. A considerable amount of  effort  was
   put  into the design of this protocol to ensure that an implementation
   could support both DIAMETER and RADIUS at the same time.


Table of Contents

      1.0    Introduction
      1.1    Definitions
      2.0    Packet Format
      3.0    DIAMETER Attributes Format
      4.0    Command Meanings


Calhoun, Rubens              expires September 1998              [Page 1]


INTERNET DRAFT                                                 March 1998


      4.1    Command AVP
      4.1.1  Command Name and Command Code
      4.1.2  Command-Unrecognized
      4.1.3  Device-Reboot-Indication
      4.1.4  Device-Reboot-Ack
      4.1.5  Device-Feature-Request
      4.1.6  Device-Feature-Response
      4.2    DIAMETER AVPs
      4.2.1  Version-Number
      4.2.2  Supported-Extension
      4.2.3  Signature
      4.2.4  Digital-Signature
      4.2.5  Initialization-Vector
      4.2.6  Timestamp
      4.2.7  Session-Id
      5.0    Protocol Definition
      5.1    DIAMETER Proxy
      5.2    Digital Signatures
      6.0    References
      7.0    Contacts


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.

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








Calhoun, Rubens              expires September 1998              [Page 2]


INTERNET DRAFT                                                 March 1998


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.

   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.

    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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Code      |  Flags  | Ver |            Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          Identifier                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Attributes ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-


    Code

      The Code field is a one octet field which is  used  in  the  RADIUS


Calhoun, Rubens              expires September 1998              [Page 3]


INTERNET DRAFT                                                 March 1998


      protocol  to  identify  the  command  type.  In  order  to   easily
      distinguish  DIAMETER  packets from RADIUS a special value has been
      reserved.

      This field allows an implementation to support both RADIUS as  well
      as  DIAMETER  simply  by identifying the first octet in the header.
      The Code field MUST be set as follows:

          254       DIAMETER packet


    Flags

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


    Length

      The Length field is two octets.  It indicates  the  length  of  the
      packet including the header fields. 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.

    Attributes

      See section 6 for more information of attribute formats.


3.0 DIAMETER Attributes Format

    DIAMETER   Attributes   carry   the   specific   authentication   and
    authorization  information  as  well as configuration details for the


Calhoun, Rubens              expires September 1998              [Page 4]


INTERNET DRAFT                                                 March 1998


    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.

    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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       Attribute Type          |           Length              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Flags     |         Vendor ID (opt)       |    Value...   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Attribute Type

      The Type field is  two  octets.  RADIUS  reserves  the  lowest  256
      attribute  numbers.  Up-to-date values of the RADIUS Type field are
      specified in the most recent "Assigned Numbers" RFC [2].

      DIAMETER will use attribute numbers 257 and above. Vendor  Specific
      attributes reside within this space when the Vendor Specific bit is
      set (see flags).  This  will  allow  up  to  65535  vendor-specific
      attributes (per vendor ID).


    Length

      The Length field is two octets, and indicates the  length  of  this
      Attribute  including  the  Type, Length, Flag, Vendor ID is present
      and Value fields. If a packet is received with an Invalid attribute
      length, the packet SHOULD be rejected.


    Flags

      The Flags field indicates how DIAMETER devices MUST  react  to  the
      attribute received. The following values are currently supported:

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


Calhoun, Rubens              expires September 1998              [Page 5]


INTERNET DRAFT                                                 March 1998


        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 3 for more information.

            NOTE That this bit MUST NOT be turned on  if  the  encryption
            bit  is  set  in  the  DIAMETER  header  which means that all
            attributes are encrypted.

      128 - If this bit is set, the optional Vendor ID field will be
            present. When set, the attribute is a vendor specific
            attribute


    Vendor ID

      Vendor ID is the IANA  assigned  "SMI  Network  Management  Private
      Enterprise  Codes" value, encoded in network byte order.  The value
      0, reserved in this table, corresponds to  IETF  adopted  Attribute
      values,  defined  within  this  document.   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.


    Value

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

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

      string    0-65526 octets.

      address   32 bit value, most significant octet first.


      extended
      address   Address Length is determined from the Length field, most
                significant octet first. This is required in order to
                support protocols which require an address length greater
                than 32 bits (i.e. IPNG).  Note that this type is
                differentiated from the previous type by the value of
                length.

      integer   32 bit value, most significant octet first.



Calhoun, Rubens              expires September 1998              [Page 6]


INTERNET DRAFT                                                 March 1998


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


4.0 Command Meanings

4.1 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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Attribute Type         |            Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Flags     |         Vendor ID (opt)       |     Value     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Value     |
       +-+-+-+-+-+-+-+-+


    Attribute Type

      256     DIAMETER Command


    Length

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


    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
      be set if the command is vendor-specific.


    Value

      The value field is set to the actual Command (defined later).  Note
      that each extensions draft MAY define a new set of Commands.



Calhoun, Rubens              expires September 1998              [Page 7]


INTERNET DRAFT                                                 March 1998


4.1.1 Command Name and Command Code

    The following  Command  types  MUST  be  supported  by  all  DIAMETER
    implementations   in   order   to   conform   to  the  base  protocol
    specification.

       Command Name: Command-Unrecognized
       Command Code: 1

       Command Name: Device-Reboot-Indication
       Command Code: 2

       Command Name: Device-Reboot-Ack
       Command Code: 3

       Command Name: Device-Feature-Request
       Command Code: 4

       Command Name: Device-Feature-Response
       Command Code: 5


4.1.2 Command-Unrecognized

    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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Attribute Type         |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Flags     |         Command Type          |     Value     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Value     |
     +-+-+-+-+-+-+-+-+

    Attribute Type

      256     DIAMETER Command


Calhoun, Rubens              expires September 1998              [Page 8]


INTERNET DRAFT                                                 March 1998


    Length

      The length of this attribute MUST be 9.


    Flags

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


    Command Type

      The Command Type field MUST be set to 1 (Command-Unrecognized).


4.1.3 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
      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 and Vendor-Name AVPs.


Calhoun, Rubens              expires September 1998              [Page 9]


INTERNET DRAFT                                                 March 1998


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


    Attribute Type

      256     DIAMETER Command


    Length

      The length of this attribute MUST be 7.


    Flags

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


    Command Type

      The Command Type field MUST be set to 2 (Device-Reboot-Indication).


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

      This message MAY contain the Version-Number and Vendor-Name 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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Attribute Type         |            Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Calhoun, Rubens             expires September 1998              [Page 10]


INTERNET DRAFT                                                 March 1998


       |     Flags     |         Command Type          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


    Attribute Type

      256     DIAMETER Command


    Length

      The length of this attribute MUST be 7.


    Flags

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


    Command Type

      The Command Type field MUST be set to 3 (Device-Reboot-Ack).


4.1.5 Device-Feature-Request

    Description

      The Device-Feature-Request message is used in order  to  request  a
      peer  about it's supported extensions. This message MAY contain the
      Version-Number and Vendor-Name 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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Attribute Type         |            Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Flags     |         Command Type          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


    Attribute Type

      256     DIAMETER Command


    Length

      The length of this attribute MUST be 7.



Calhoun, Rubens             expires September 1998              [Page 11]


INTERNET DRAFT                                                 March 1998


    Flags

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


    Command Type

      The Command Type field MUST be set to 4 (Device-Feature-Request).


4.1.6 Device-Feature-Response

    Description

      The Device-Feature-Response message is  sent  in  response  to  the
      Device-Feature-Request message. This message includes all supported
      extensions by the responder and MAY contain the Version-Number  and
      Vendor-Name 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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Attribute Type         |            Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Flags     |         Command Type          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


    Attribute Type

      256     DIAMETER Command


    Length

      The length of this attribute MUST be 7.


    Flags

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


    Command Type

      The Command Type field MUST be set to 5 (Device-Feature-Response).


4.2 DIAMETER AVPs



Calhoun, Rubens             expires September 1998              [Page 12]


INTERNET DRAFT                                                 March 1998


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

       Attribute Name: Version-Number
       Attribute Code: 257

       Attribute Name: Supported-Extension
       Attribute Code: 258

       Attribute Name: Signature
       Attribute Code: 259

       Attribute Name: Digital-Signature
       Attribute Code: 260

       Attribute Name: Initialization-Vector
       Attribute Code: 261

       Attribute Name: Timestamp
       Attribute Code: 262

       Attribute Name: Session-Id
       Attribute Code: 263

       Attribute Name: X509-Certificate
       Attribute Code: 264

       Attribute Name: X509-Certificate-URL
       Attribute Code: 265

       Attribute Name: Vendor-Name
       Attribute Code: 266


4.2.1 Version-Number

    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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Attribute Type         |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Flags     |             Value             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


    Attribute Type


Calhoun, Rubens             expires September 1998              [Page 13]


INTERNET DRAFT                                                 March 1998


      257     Version-Number


    Length

      The length of this attribute MUST be 7.


    Flags

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


    Value

      The value field contains the system version number.


4.2.2 Supported-Extension

    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.

     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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Attribute Type         |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Flags     |             Value             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


    Attribute Type

      258     Supported-Extension


    Length

      The length of this attribute MUST be 7.


    Flags

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


    Value


Calhoun, Rubens             expires September 1998              [Page 14]


INTERNET DRAFT                                                 March 1998


      The value field contains the extension number.


4.2.3 Signature

    The Signature AVP is  used  for  authentication  and  integrity.  The
    DIAMETER header as well as all AVPs prior to this AVP is protected by
    the Signature.


     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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Attribute Type         |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Flags     |           Value...            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


    Attribute Type

      259     Signature


    Length

      The length of this attribute MUST be at least 7.


    Flags

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


    Value

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


4.2.4 Digital-Signature

    The Digital-Signature AVP is used for  authentication,  integrity  as
    well  as  non-repudiation.  The  DIAMETER  header as well as all AVPs
    prior to 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 through proxy


Calhoun, Rubens             expires September 1998              [Page 15]


INTERNET DRAFT                                                 March 1998


    arrangements.

     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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Attribute Type         |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Flags     |           Value...            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


    Attribute Type

      260     Digital-Signature


    Length

      The length of this attribute MUST be 7.


    Flags

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


    Value

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


4.2.5 Initialization-Vector

    The Initialization-Vector AVP MUST be present prior to  the  Digital-
    Signature  AVP  within  a  message  and  is used to ensure randomness
    within a message. The content of this AVP MUST be a  random  128  bit
    value.


     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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Attribute Type         |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Flags     |           Value...            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


    Attribute Type


Calhoun, Rubens             expires September 1998              [Page 16]


INTERNET DRAFT                                                 March 1998


      261     Initialization-Vector


    Length

      The length of this attribute MUST be 21.


    Flags

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


    Value

      The value field contains a random 128 bit value.


4.2.6 Timestamp

    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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Attribute Type         |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Flags     |                    Value                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Value     |
     +-+-+-+-+-+-+-+-+


    Attribute Type

      262     Timestamp


    Length

      The length of this attribute MUST be 9.


Calhoun, Rubens             expires September 1998              [Page 17]


INTERNET DRAFT                                                 March 1998


    Flags

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


    Value

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


4.2.7 Session-Id

    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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Attribute Type         |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Flags     |                    Value                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Value     |
     +-+-+-+-+-+-+-+-+


    Attribute Type

      263     Session-Id


    Length

      The length of this attribute MUST be 9.


    Flags

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


    Value



Calhoun, Rubens             expires September 1998              [Page 18]


INTERNET DRAFT                                                 March 1998


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


4.2.8 X509-Certificate

    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.


     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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Attribute Type         |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Flags     |    Value...   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


    Attribute Type

      264     X509-Certificate


    Length

      The length of this attribute MUST be greater than 7.


    Flags

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


    Value

      The value field contains the X.509 Certificate Chain.


4.2.9 X509-Certificate-URL

    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.


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


INTERNET DRAFT                                                 March 1998


     |        Attribute Type         |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Flags     |    Value...   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


    Attribute Type

      265     X509-Certificate-URL


    Length

      The length of this attribute MUST be greater than 7.


    Flags

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


    Value

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


4.2.10 Vendor-Name

    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.


     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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Attribute Type         |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Flags     |    Value...   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


    Attribute Type

      266     Vendor-Name


    Length



Calhoun, Rubens             expires September 1998              [Page 20]


INTERNET DRAFT                                                 March 1998


      The length of this attribute MUST be greater than 7.


    Flags

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


    Value

      The value field contains the vendor name.


5.0 Protocol Definition

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

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

    In these cases the Digital Signature AVP may be used.

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

    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.


5.2 Signatures

    The use of the Signature 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


Calhoun, Rubens             expires September 1998              [Page 21]


INTERNET DRAFT                                                 March 1998


    where asymetric technology is not required.

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

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


6.0 References

    [1] Rigney, et alia, "RADIUS", RFC-2058, Livingston, January 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.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
      Merit Network, Inc.
      4251 Plymouth Rd.
      Ann Arbor, MI 48105-2785



Calhoun, Rubens             expires September 1998              [Page 22]


INTERNET DRAFT                                                 March 1998


       Phone: 1-734-647-0417
      E-Mail: acr@merit.edu


















































Calhoun, Rubens             expires September 1998              [Page 23]


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