rfc1022.txt

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

   This memo defines two types of authentication, a password scheme and
   authentication by encryption method.  For the password scheme, the
   AuthenticateSection has the form shown in Figure 6.

         AuthenticateSection :: = IMPLICIT SEQUENCE {
                authenticateType INTEGER { password(1) },
                authenticateData OCTETSTRING
          }

          Figure 6: ASN.1 Format of Password Authentication Section

   The authenticateType is 1, and the password is an octet string of any
   length.  The system is used to validate requests to an entity.  Upon
   receiving a request, an entity checks the password against an entity
   specific password which has been assigned to the entity.  If the
   passwords match, the request is accepted for processing.  The scheme
   is a slightly more powerful password scheme than that currently used
   for monitoring on the Internet.

   For authentication by encryption, the AuthenticateSection has the
   format shown in Figure 7.

         AuthenticateSection :: = IMPLICIT SEQUENCE {
                authenticateType INTEGER { encryption(2) },
                authenticateData NULL
          }

          Figure 7: ASN.1 Format of Encryption Authentication Section

   This section simply indicates that authentication was implicit in the
   encryption method.  Recipients of such messages should confirm that
   the encryption method does indeed provide authentication.

   No other authentication types are currently defined.

   If a message fails authentication, it should be discarded.  If the
   type of authentication used on the message is unknown or the section
   is omitted, the message may be discarded or processed at the
   discretion of the implementation.  It is recommended that requests
   with unknown authentication types be logged as potential intrusions,
   but not processed.

THE COMMON HEADER

   The common header contains generic information about the message such
   as the protocol version number and the type of request.  The ASN.1
   format of the common header is shown in Figure 8.




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


           CommonHeader ::= IMPLICIT SEQUENCE {
               link IMPLICIT INTEGER,
               messageType IMPLICIT INTEGER,
               messageId IMPLICIT INTEGER,
               resourceId ANY
           }


                  Figure 8: ASN.1 Format of Common Header

   The link indicates which version of HEMS is in use.

   The messageType is a value indicating whether the message is a
   request (0), reply (1), event (2), protocol error (3) or application
   error (4) message.

   The messageId is a unique bit identifier, which is set in the request
   message, and echoed in the response.  It allows applications to match
   responses to their corresponding request.  Applications should choose
   messageIds such that a substantial period of time elapses before a
   messageId is re-used by a particular application (even across machine
   crashes).

   Event messages also use the messageId field to indicate the number of
   the current event message.  By comparing messageId fields from events
   lost, event values may be detected.  The event messageId should be
   reset to 0 on every reboot, and by convention, the event message with
   messageId of 0 should always be a "reboot" event.  (Facilities should
   be provided in the event message definition to allow entities which
   are capable of storing messageIds across reboots to send the highest
   messageId reached before the reboot.)

   The resourceId is defined for ISO compatibility and corresponds to
   the resource ID used by the Common Management Information Protocol to
   identify the relevant ISO resource.

DATA SECTION

   The data section contains the message specific data.  The format of
   the data section is shown in Figure 9.

                   Data ::= ANY

                  Figure 9: ASN.1 Format of Data Section

   The contents of the data section is application specific and, with
   the exception of protocol error messages, is outside the scope of
   this memo.



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


TRANSPORT PROTOCOL

   There has been considerable debate about the proper transport
   protocol to use under HEMP.  Part of the problem is that HEMP is
   being used for two different types of interactions:  request-response
   exchanges and event messages.  Request-response interactions may
   involve arbitrary amounts of data being sent in both directions, and
   is believed to require a reliable transport mechanism.  Event
   messages are typically small and need not be reliably delivered.

   Public opinion seems to lean towards running HEMP over a transaction
   protocol (see RFC-955 for a general discussion).  Unfortunately, the
   community is still experimenting with transaction protocols, and many
   groups would like to be able to implement HEMP now.  Accordingly,
   this memo defines two transport protocols for use with HEMP.

   Groups interested in using an implementation of HEMP and the HEMS in
   the near future should use a combination of the Transmission Control
   Protocol (TCP) and the User Datagram Protocol (UDP) under HEMP.  TCP
   should be used for all request-response interactions and UDP should
   be used to send event messages.  Using UDP to support the request-
   response interactions is strongly discouraged.

   More forward looking groups are encouraged to implement HEMP over a
   transaction protocol, in particular, experiments are planned with the
   Versatile Message Transaction Protocol (VMTP).

PROTOCOL ERROR MESSAGES

   Protocol error messages are so closely tied to the definition of HEMP
   that it made sense to define the contents of the data section for
   protocol error messages in this memo, even though the data section is
   generally considered application specific.

   The data section of all protocol error messages has the same format,
   which is shown in Figure 10.  This format has been chosen to agree
   with the error message format and ASN.1 type used for language
   processing errors in RFC-1024, and the error codes have been chosen
   such that they do not overlap.

           ProtocolError ::= [APPLICATION 0] implicit sequence {
               protoErrorCode INTEGER,
               protoErrorOffset INTEGER,
               protoErrorDescribed IA5String,
           }

            Figure 10: Data Section For Protocol Error Messages




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


   The protoErrorCode is a number which specifies the particular type of
   error encountered.  The defined codes are:

           0 - reserved <not used>

           1 - ASN.1 format error.  Some error has been encountered
           in parsing the message.  Examples of such an error are an
           unknown type or a violation of the ASN.1 syntax.

           2 - Wrong HEMP version number.  The version number in
           the common header is invalid.  Note that this may
           be an indication of possible network intrusion and
           should be logged at sites concerned with security.

           3 - Authentication error.  Authentication has failed.
           This error code is defined for completeness, but
           implementations are *strongly* discouraged from using
           it.  Returning authentication failure information may
           aid intruders in cracking the authentication system.
           It is recommended taht authentication errors be logged
           as possible security problems.

           4 - ReplyEncryption type not supported.  The entity
           does not support the encryption method requested in the
           ReplyEncryption section.

           5 - Decryption failed.  The entity could not decrypt the
           encrypted message.  Note that this means that the
           entity could not read the CommonHeader to find the
           messageId for the reply.  In this case, the messageId
           field should be set to 0.

           6 - Application Failed.  Some application failure made it
           impossible to process the message.

   The protoErrorOffset is the number of the octet in which the error
   was discovered.  The first octet in the message is octet number 0.

   The protoErrorDescribed field is a string which describes the
   particular error.  This description is expected to give a more
   detailed description of the particular error encountered.

APPENDIX OF TYPES

   This section lists all ASN.1 types defined in this document.






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


   HEMP Types

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

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

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


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


       CommonHeader ::= IMPLICIT SEQUENCE {
           link IMPLICIT INTEGER,
           messageType IMPLICIT INTEGER {
               request(0), reply(1), event(2),
               protocol error (3), application error(4)
           }
           messageId IMPLICIT INTEGER,
           resourceId ANY
       }

       Data ::= ANY

Protocol Error Types

       ProtocolError ::= [APPLICATION 0] implicit sequence {
           protoErrorCode INTEGER,
           protoErrorOffset INTEGER,
           protoErrorDescribed OCTETSTRING
       }






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


REFERENCES

   ISO Standard ASN.1 (Abstract Syntax Notation 1).  It comes in two
   parts:
      International Standard 8824 -- Specification (meaning, notation)
      International Standard 8825 -- Encoding Rules (representation)

   The current VMTP specification is available from David Cheriton of
   Stanford University.










































Partridge & Trewitt                                            [Page 12]