rfc1022.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 671 行 · 第 1/2 页

Network Working Group                                      C. Partridge
Request For Comment: 1022                                      BBN/NNSC
                                                             G. Trewitt
                                                               Stanford
                                                           October 1987

          THE HIGH-LEVEL ENTITY MANAGEMENT PROTOCOL (HEMP)

STATUS OF THIS MEMO

   An application protocol for managing network entities such as hosts,
   gateways and front-end machines, is presented.  This protocol is a
   component of the High-Level Entity Management System (HEMS) described
   in RFC-1021.  Readers may want to consult RFC-1021 when reading this
   memo.  This memo also assumes a knowledge of the ISO data encoding
   standard, ASN.1.  Distribution of this memo is unlimited.

PROTOCOL OVERVIEW

   The High-Level Entity Management Protocol (HEMP) provides an
   encapsulation system and set of services for communications between
   applications and managed entities.  HEMP is an application protocol
   which relies on existing transport protocols to deliver HEMP messages
   to their destination(s).

   The protocol is targeted for management interactions between
   applications and entities.  The protocol is believed to be suitable
   for both monitoring and control interactions.

   HEMP provides what the authors believe are the three essential
   features of a management protocol:  (1) a standard encapsulation
   scheme for all interactions, (2) an authentication facility which can
   be used both to verify messages and limit access to managed systems,
   and (3) the ability to encrypt messages to protect sensitive
   information.  These features are discussed in detail in the following
   sections.

PROTOCOL OPERATION

   HEMP is designed to support messages; where a message is an
   arbitrarily long sequence of octets.

   Five types of messages are currently defined: request, event, reply,
   and protocol error, and application error messages.  Reply, protocol
   error and application error messages are only sent in reaction to a
   request message, and are referred to collectively as responses.





Partridge & Trewitt                                             [Page 1]

RFC 1022                     HEMS Protocol                  October 1987


   Two types of interaction are envisioned: a message exchange between
   an application and an entity managed by the application, and
   unsolicited messages from an entity to the management centers
   responsible for managing it.

   When an application wants to retrieve information from an entity or
   gives instructions to an entity, it sends a request message to the
   entity.  The entity replies with a response, either a reply message
   if the request was valid, or an error message if the request was
   invalid (e.g., failed authentication).  It is expected that there
   will only be one response to a request message, although the protocol
   does not preclude multiple responses to a single request.

   Protocol error messages are generated if errors are found when
   processing the HEMP encapsulation of the message.  The possible
   protocol error messages are described later in this document.  Non-
   HEMP errors (e.g., errors that occur during the processing of the
   contents of the message) are application errors.  The existence of
   application error messages does not preclude the possibility that a
   reply will have an error message in it.  It is expected that the
   processing agent on the entity may have already started sending a
   reply message before an error in a request message is discovered.  As
   a result, application errors found during processing may show up in
   the reply message instead of a separate application error message.

   Note that in certain situations, such as on secure networks,
   returning error messages may be considered undesirable.  As a result,
   entities are not required to send error messages, although on
   "friendly" networks the use of error messages is encouraged.

   Event messages are unsolicited notices sent by an entity to an
   address, which is expected to correspond to one or more management
   centers.  (Note that a single address may correspond to a multicast
   address, and thus reach multiple hosts.)  Event messages are
   typically used to allow entities to alert management centers of
   important changes in their state (for example, when an interface goes
   down or the entity runs out of network buffers).














Partridge & Trewitt                                             [Page 2]

RFC 1022                     HEMS Protocol                  October 1987


STANDARD MESSAGE FORMAT

   Every HEMP message is put in the general form shown in Figure 1.

                     +-------------------------------+
                     :           leader              :
                     +-------------------------------+
                     :       encryption section      :
                     +-------------------------------+
                     :    reply encryption section   :
                     +-------------------------------+
                     :     authentication section    :
                     +-------------------------------+
                     :          common header        :
                     +-------------------------------+
                     :              data             :
                     +-------------------------------+

                  Figure 1: General Form of HEMP Messages

   Each message has five components: (1) the leader, which is simply the
   ASN.1 tag and message length; (2) the encryption section, which
   provides whatever information the receiver may require to decrypt the
   message; (3) the reply encryption section, in which the requesting
   application may specify the type of encryption to use in the reply;
   (4) the authentication section, which allows the receiver to
   authenticate the message; (5) the common header, which identifies the
   message type, the HEMP version, and the message id; and (6) the data
   section.  All four sections following the leader are also ASN.1
   encoded.  The ASN.1 format of the message is shown in Figure 2.

          HempMessage ::= [0] IMPLICIT SEQUENCE {
              [0] IMPLICIT EncryptSection OPTIONAL,
              [1] IMPLICIT ReplyEncryptSection OPTIONAL,
              [2] IMPLICIT AuthenticateSection OPTIONAL,
              [3] IMPLICIT CommonHeader,
              [4] IMPLICIT Data }

                  Figure 2: ASN.1 Format of HEMP Messages

   The ordering of the sections is significant.  The encryption section
   comes first so that all succeeding sections (which may contain
   sensitive information) may be encrypted.  The authentication section
   precedes the header so that messages which fail authentication can be
   discarded without header processing.






Partridge & Trewitt                                             [Page 3]

RFC 1022                     HEMS Protocol                  October 1987


THE ENCRYPTION SECTION

Need For Encryption

   Encryption must be supported in any management scheme.  In
   particular, a certain amount of monitoring information is potentially
   sensitive.  For example, imagine that an entity maintains a traffic
   matrix, which shows the number of packets it sent to other entities.
   Such a traffic matrix can reveal communications patterns in an
   organization (e.g., a corporation or a government agency).
   Organizations concerned with privacy may wish to employ encryption to
   protect such information.  Access control ensures that only people
   entitled to request the data are able to retrieve it, but does not
   protect from eavesdroppers reading the messages.  Encryption protects
   against eavesdropping.

   Note that encryption in HEMP does not protect against traffic
   analysis.  It is expected that HEMP interactions will have distinct
   signatures such that a party which can observe traffic patterns may
   guess at the sort of interactions being performed, even if the data
   being sent is encrypted.  Organizations concerned with security at
   this level should additionally consider link-level encryption.

Format of the Encryption Section

   The encryption section contains any data required to decrypt the
   message.  The ASN.1 format of this section is shown in Figure 3.

          EncryptSection :: = IMPLICIT SEQUENCE {
                encryptType INTEGER,
                encryptData ANY
          }

                Figure 3: ASN.1 Format of Encryption Section

   If the section is omitted, then no decryption is required.  If the
   section is present, then the encryptType field contains a number
   defining the encryption method in use and encryptData contains
   whatever data, for example a key, which the receiver must have to
   decrypt the remainder of the message using the type of encryption
   specified.

   Currently no encryption types are assigned.

   If the message has been encrypted, data is encrypted starting with
   the first octet after the encryption section.





Partridge & Trewitt                                             [Page 4]

RFC 1022                     HEMS Protocol                  October 1987


THE REPLY ENCRYPTION SECTION

Need for Reply Encryption

   The reasons for encrypting messages have already been discussed.

   The reply encryption section provides the ability for management
   agents to request that responses be encrypted even though the
   requests are not encrypted, or that responses be encrypted using a
   different key or even a different scheme from that used to encrypt
   the request.  A good example is a public key encryption system, where
   the requesting application needs to pass its public key to the
   processing agent.

Format of the Reply Encryption Section

   The reply encryption section contains any data required to encrypt
   the reply message.  The ASN.1 format of this section is shown in
   Figure 4.

          ReplyEncryptSection :: = IMPLICIT SEQUENCE {
                replyEncryptType INTEGER,
                replyEncryptData ANY
          }

          Figure 4: ASN.1 Format of Reply Encryption Section

   If the section is omitted, then the reply should be encrypted in the
   manner specified by the encryption section.  If the section is
   present, then the replyEncryptType field contains a number defining
   the encryption method to use and replyEncryptData contains whatever
   data, for example a key, which the receiver must have to encrypt the
   reply message.

   If the reply encryption section is present, then the reply message
   must contain an appropriate encryption section, which indicates the
   encryption method requested in the reply encryption section is in
   use.  The reply message should be encrypted starting with the first
   octet after the encryption section.

   If the reply encryption method requested is not supported by the
   entity, the entity may not send a reply.  It may, at the discretion
   of the implementor, send a protocol error message.  (See below for
   descriptions of protocol error messages.)

   Currently no encryption types are assigned.





Partridge & Trewitt                                             [Page 5]

RFC 1022                     HEMS Protocol                  October 1987


THE AUTHENTICATION SECTION

Need for Authentication

   It is often useful for an application to be able to confirm either
   that a message is indeed from the entity it claims to have originated
   at, or that the sender of the message is accredited to make a
   monitoring request, or both.  An example may be useful here.
   Consider the situation in which an entity sends a event message to a
   monitoring center which indicates that a trunk link is unstable.
   Before the monitoring center personnel take actions to re-route
   traffic around the bad link (or makes a service call to get the link
   fixed), it would be nice to confirm that the event was indeed sent by
   the entity, and not by a prankster.  Authentication provides this
   facility by allowing entities to authenticate their event messages.

   Another use of the authentication section is to provide access
   control.  Requests demand processing time from the entity.  In cases
   where the entity is a critical node, such as a gateway, we would like
   to be able to limit requests to authorized applications.  We can use
   the authentication section to provide access control, by only
   allowing specially authenticated applications to request processing
   time.

   It should also be noted that, in certain cases, the encryption method
   may also implicitly authenticate a message.  In such situations, the
   authentication section should still be present, but uses a type code
   which indicates that authentication was provided by the encryption
   method.

Format of the Authentication Section

   The authentication section contains any data required to allow the
   receiver to authenticate the message.  The ASN.1 format of this
   section is shown in Figure 5.

         AuthenticateSection :: = IMPLICIT SEQUENCE {
                authenticateType INTEGER,
                authenticateData ANY
               }


             Figure 5: ASN.1 Format of Authentication Section

   If the section is omitted, then the message is not authenticated.  If
   the section is present, then the authenticateType defines the type of
   authentication used and the authenticateData contains the
   authenticating data.



Partridge & Trewitt                                             [Page 6]

RFC 1022                     HEMS Protocol                  October 1987