Internet DRAFT - draft-hardaker-snmp-session-sm

draft-hardaker-snmp-session-sm





Network Working Group                                        W. Hardaker
Internet-Draft                                                    Sparta
Expires: April 16, 2005                                       D. Perkins
                                                                SNMPInfo
                                                        October 16, 2004



   A Session-Based Security Model (SBSM) for version 3 of the Simple
                  Network Management Protocol (SNMPv3)
                 draft-hardaker-snmp-session-sm-03.txt


Status of this Memo


   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.


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


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


   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.


   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


   This Internet-Draft will expire on April 16, 2005.


Copyright Notice


   Copyright (C) The Internet Society (2004).  All Rights Reserved.


Abstract


   This document describes a Session Based Security Model (SBSM) for use
   within version 3 of the Simple Network Management Protocol (SNMPv3).
   The security model is designed to establish a "session" between two
   interacting SNMPv3 entities, over which SNMP operations can be sent
   securely.  It provides a number of security properties not previously
   available in defined SNMPv3 security models, such as public key based
   identity authentication, limited life-time keying, and the ability to




Hardaker & Perkins       Expires April 16, 2005                 [Page 1]
Internet-Draft    A Session-based security model for SNMP   October 2004



   make use of previously implemented and deployed security
   infrastructures for purposes of identification and authentication.


Table of Contents


   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1   SNMPv3 background information  . . . . . . . . . . . . . .  4
     1.2   Status of this document  . . . . . . . . . . . . . . . . .  4
   2.  Document conventions . . . . . . . . . . . . . . . . . . . . .  4
     2.1   SBSM Definitions and Terminology . . . . . . . . . . . . .  4
     2.2   Protocol documentation conventions . . . . . . . . . . . .  5
   3.  Goals and Objectives . . . . . . . . . . . . . . . . . . . . .  6
   4.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . .  7
   5.  Protocol Definitions . . . . . . . . . . . . . . . . . . . . .  9
   6.  Elements of Procedure  . . . . . . . . . . . . . . . . . . . . 13
     6.1   Session State Information  . . . . . . . . . . . . . . . . 13
       6.1.1   Closing sessions . . . . . . . . . . . . . . . . . . . 14
     6.2   The msgSecurityModel field in the msgGlobalData  . . . . . 15
     6.3   Diffie-Helman exchange and key derivation  . . . . . . . . 15
       6.3.1   Generating Keying Material . . . . . . . . . . . . . . 16
       6.3.2   Generating the session keys  . . . . . . . . . . . . . 16
     6.4   Authenticaton and Encryption Algorithms  . . . . . . . . . 17
       6.4.1   Differences from USM encryption algorithm
               implementations  . . . . . . . . . . . . . . . . . . . 17
     6.5   Creating new sessions  . . . . . . . . . . . . . . . . . . 19
       6.5.1   Session initialization and generation of SBSMInit1 . . 19
       6.5.2   Reception of SBSMInit1 and generation of SBSMInit2 . . 21
       6.5.3   Reception of SBSMInit2 and generation of SBSMInit3 . . 26
       6.5.4   Reception of the SBSMInit3 message and generation
               of the SBSMRunning REPORT  . . . . . . . . . . . . . . 30
     6.6   Processing messages in an active session.  . . . . . . . . 33
       6.6.1   Outgoing Messages on an open session.  . . . . . . . . 33
       6.6.2   Incoming Messages on an open session.  . . . . . . . . 35
     6.7   Processing SBSMError messages. . . . . . . . . . . . . . . 38
       6.7.1   Processing outgoing SBSMError messages.  . . . . . . . 38
       6.7.2   Processing incoming SBSMError messages.  . . . . . . . 38
     6.8   Closing an active session from either side . . . . . . . . 40
     6.9   Processing the SBSM messages for anti-replay support.  . . 40
       6.9.1   Processing outgoing messages . . . . . . . . . . . . . 41
       6.9.2   Processing Incoming Messages . . . . . . . . . . . . . 42
   7.  MIB Definitions  . . . . . . . . . . . . . . . . . . . . . . . 44
   8.  Identification Mechanisms  . . . . . . . . . . . . . . . . . . 47
     8.1   Public Key Based Identities  . . . . . . . . . . . . . . . 48
       8.1.1   Security Model assignment  . . . . . . . . . . . . . . 48
       8.1.2   Format of the identity field . . . . . . . . . . . . . 48
       8.1.3   Signatures . . . . . . . . . . . . . . . . . . . . . . 49
       8.1.4   Security Name Mapping  . . . . . . . . . . . . . . . . 49
     8.2   Local Accounts . . . . . . . . . . . . . . . . . . . . . . 49




Hardaker & Perkins       Expires April 16, 2005                 [Page 2]
Internet-Draft    A Session-based security model for SNMP   October 2004



       8.2.1   Security Model assignment  . . . . . . . . . . . . . . 50
       8.2.2   Format of the identity field . . . . . . . . . . . . . 50
       8.2.3   Signatures . . . . . . . . . . . . . . . . . . . . . . 50
       8.2.4   Security Name Mapping  . . . . . . . . . . . . . . . . 50
     8.3   EAP Authentication and Identification  . . . . . . . . . . 51
     8.4   SSH Authentication and Identification  . . . . . . . . . . 51
   9.  Compression Algorithms . . . . . . . . . . . . . . . . . . . . 51
     9.1   sbsmNullCompressionAlgorithm . . . . . . . . . . . . . . . 51
     9.2   sbsmGZipCompressionAlgorithm . . . . . . . . . . . . . . . 51
     9.3   sbsmBZip2CompressionAlgorithm  . . . . . . . . . . . . . . 51
   10.   Security Considerations  . . . . . . . . . . . . . . . . . . 52
   11.   TODO list  . . . . . . . . . . . . . . . . . . . . . . . . . 52
   12.   History and Acknowledgments  . . . . . . . . . . . . . . . . 52
   13.   References . . . . . . . . . . . . . . . . . . . . . . . . . 54
   13.1  Normative References . . . . . . . . . . . . . . . . . . . . 54
   13.2  Informative References . . . . . . . . . . . . . . . . . . . 55
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 55
   A.  Diffie-Helman Group information  . . . . . . . . . . . . . . . 55
     A.1   Diffie-Helman Group IKEv2-N5 . . . . . . . . . . . . . . . 55
       Intellectual Property and Copyright Statements . . . . . . . . 56
































Hardaker & Perkins       Expires April 16, 2005                 [Page 3]
Internet-Draft    A Session-based security model for SNMP   October 2004



1.  Introduction


   This document describes a Session Based Security Model (SBSM) for use
   within version 3 of the Simple Network Management Protocol (SNMPv3).
   The security model is designed to establish a "session" between two
   interacting SNMPv3 entities, over which SNMP operations can be sent
   securely.  It provides a number of security properties not previously
   available in defined SNMPv3 security models, such as public key based
   identity authentication, limited life-time keying, and the ability to
   make use of previously implemented and deployed security
   infrastructures for purposes of identification and authentication.
   It also supports creation of a authenticated and possibly encrypted
   session when the identity of the initiator of the session is
   anonymous or unknown.  These properties and the other goals of the
   (SBSM) are documented in Section Section 3.


   The details of the technology and concepts on which the SBSM is built
   comes from previously described and operationally proven works, such
   as the SIGMA security protocol, and the IKEv2 key exchange
   specification.  Although it is not required that the reader
   understands the concepts in these other documents, it certainly
   wouldn't hurt.  And to ease the review of this document, note that no
   new cryptographic algorithms or security protocols are defined in
   this document beyond those defined in previous or other SNMPv3
   standards documents.


1.1  SNMPv3 background information


   Although all of the SNMPv3 protocol specifications are described in
   RFCs 3410-3415 those who are new to SNMPv3 may find it useful to read
   a companion document instead, which is a concise and easy to
   understand summary of the SNMPv3 protocol specifications
   [refs.v3overview].  It is designed to be especially helpful for
   people which wish to read this document but are not well versed in
   how the security aspects of the SNMPv3 protocol specification are
   designed.


1.2  Status of this document


   This document is a work in progress.


2.  Document conventions


2.1  SBSM Definitions and Terminology


   The following terms are used through this document:






Hardaker & Perkins       Expires April 16, 2005                 [Page 4]
Internet-Draft    A Session-based security model for SNMP   October 2004



   session: A potentially long lived interaction between two SNMPv3
      entities.


   initiator: The SNMPv3 entity that starts a session by sending the
      first SBSM initiation message.  An initiator can be either a
      manager and/or a managed device and once the session is
      established all types of transactions may flow through it
      regardless of origin (that is, the responder can be a manager or
      managed device).  For example, if a manager becomes an initiator
      and opens a session, it can send SNMP GET operations through it
      and the managed device can send SNMP INFORM operations back
      through the same session.


   responder: The SNMPv3 entity that listens for connections and
      responds to initiation requests from the initiator.


   identity authentication: Verifying that the SNMPv3 entity is who it
      claims to be.  This can be a process running on a computer system,
      or a network operator acting through an application.


   message authentication: Verifying that a SNMPv3 message has not been
      modified, reordered, or replayed and that it belongs to the
      sessions under which it was received.


   message encryption: Protecting portions of a message from disclosure
      during transmission through the use of cryptographic algorithms.


      The | operator used in multiple equations in this document refers
      to the string concatenation operator, *not* the xor operator.  In
      the ASN.1 and MIB portions of this document, it refers to options.



2.2  Protocol documentation conventions


   Portions of this document contain simple assignment operations in
   order to simplify understanding of what happens at particular points
   during processing of the protocol operations.  They are expressed in
   a pseudo-code style text block, such as:


        outgoingMessage.init-identifier = store.local-identifier


    In the simplest and most common case, this is simply a copy
   operation which dictates what should be copied and to where it should
   be copied (in this case the local-identifies stored in the "store" is
   copied to the init-identifier field of the outgoingMessage
   construct).  Generally the usage of these code blocks should be
   simple to understand and shorter than what a text sentence could
   quickly convey.




Hardaker & Perkins       Expires April 16, 2005                 [Page 5]
Internet-Draft    A Session-based security model for SNMP   October 2004



   One particular information source which might take a bit more
   explanation: "generated", EG:


        outgoingMessage.init-DH-value = generated.diffie-helman-half


    In this case, the value to be stored in the outgoingMessage is
   generated from a diffie-helman calculation, which is frequently
   described elsewhere in text.


   Finally, it should be important to note that both these equations and
   the surrounding text must be read and understood in order to get the
   protocol correct.  IE, a successful implementation must take
   everything into account: both the text wording and the equations.
   Order of execution of both the text and equations are critical for
   preserving some of the security properties of the SBSM protocol.


3.  Goals and Objectives


   The brief list of goals and objectives met by this protocol include:


   o  Security transactions that make use of previously deployed and
      widely used mechanisms for establishing identity authentication.
      This includes public/private key technologies (including PKI
      infrastructures), and other common and currently deployed
      authenticating mechanisms such as Radius and TACACS+.


   o  Session-based keying properties such as dynamically created keys,
      limited lifetime keys, separate negotiated keys for message
      authentication and message encryption, and perfect forward secrecy
      (PFS) support of those keys.


   o  Retransmissions and replays of SNMP protocol operations do NOT
      result in reprocessing of the message within the protocol.  EG, a
      managed device which receives and processes a SET request will not
      reprocess that same SET request in the future, even if a manager
      retransmits its original request due to packets being dropped
      within the network.  This is done to nullify the damage possible
      via retransmitted SNMP messages which would have previously been
      reprocessed within the security time window of other protocols,
      such as the USM.


   o  SBSM sessions will work over any lower layer transports, which
      include both UDP and TCP, for example.  As well, the session
      parameters are not bound to the lower layer transport.


   o  SNMP message exchange that is authenticated and even private when
      the session initiator or responder is anonymous.





Hardaker & Perkins       Expires April 16, 2005                 [Page 6]
Internet-Draft    A Session-based security model for SNMP   October 2004



   o  Negotiated compression to reduce the overhead of BER encoding
      rules before encryption is processed.



4.  Protocol Overview


   The SBSM protocol is designed to meet the goals and objectives listed
   in Section Section 3.  The SBSM session gets established through some
   initial hand-shake transactions.  These transactions exist entirely
   within the security parameter field of the SNMPv3 message and the
   application is not involved.  Generally an application sending
   something through a SBSM security model will trigger the creation of
   a session within the initiator, and the responder will trigger
   session creation when it receives the first message from a
   hand-shake.


   Establishing a SBSM security session between an initiator and a
   responder takes some negotiation between the two pairs.  The
   complexity of this exchange has been kept to a bare minimum wherever
   possible.  It would be easy to conclude that more parameters should
   be included since they would be convenient (such as timeout values,
   session length values, etc) but they offer little benefit for their
   increased complexity and thus have been left out.


   The initial exchange for creating a session looks roughly like the
   following series of security-parameter exchanges, assuming no errors
   occur during the establishment:


          Initiator                          Responder
          -----------                        -----------
          SBSMInit1           -->
                              <--            SBSMInit2


          SBSMInit3           -->
                              <--            SBSMRunning


            ... session started ...




   Note: The above flow diagram is the most simple case.  When
   challenge-response identification protocols, such as EAP, are used to
   authenticate identities, then more messages need to be sent than
   those above.  E.G., an SBSMError message may be used by the
   identification protocol to trigger the need for additional SBSMInit3
   messages to be sent before the Responder is satisfied with the
   initiators credentials.





Hardaker & Perkins       Expires April 16, 2005                 [Page 7]
Internet-Draft    A Session-based security model for SNMP   October 2004



   Note that the initiation of a session can occur at either end of the
   protocol.  E.G., a management station can establish a session with a
   device through which it can send management operations (E.G.  for
   sending GETs, SETs, ...) and a managed device can also establish a
   session with a management station (E.G.  for sending TRAPs, INFORMs,
   ...).  Additionally, a peer MUST expect management operations of any
   type to be sent through a given session.  EG, just because a managed
   device opens a session to send a notification, it must be able to
   accept management operations of other types (GETs, etc) to be sent
   from the management station to the device under the same session.


   The details of how the session establishment exchange works is
   described in Section Section 6.5.


   Once a session has been established, the security parameters switch
   to using the running form:


          Initiator                          Responder
          -----------                        -----------
          SBSMRunning       <-->             SBSMRunning


   The security model sent within the SNMPv3 message is always the
   security model number assigned to the SBSM security model.  Within
   the application, however, the security model assigned to the identity
   type is typically used which will differ from the security model
   number assigned to the SBSM security model.  The use of these
   sub-security models is further discussed in the elements of procedure
   below (Section Section 6.


   There are several differences from the way the previous User Based
   Security model (USM) [refs.RFC3414] worked that are important to
   understand.  Most importantly, the User Based Security model was
   based on shared secrets and thus was a symmetric protocol.  This is
   starkly different from the way the SBSM protocol works, which is
   asymmetric in nature.  For example, two identities exist (the
   initiator and responder) within the SBSM session and both sides of
   the transaction MUST check the identity of the other side for proper
   authentication and authorization.


   Since identity types within the security model can differ on each
   side (EG, one side may have an identity associated with a public key
   certificate and the other side may have an identity associated with a
   user name and password pair), there can be two sub-security models in
   use within a session, one for each direction.  This may seem odd to
   those previously familiar with the USM, but will not affect usage of
   the SNMP protocol's applications.


   The details of how the session operates once it has been established




Hardaker & Perkins       Expires April 16, 2005                 [Page 8]
Internet-Draft    A Session-based security model for SNMP   October 2004



   is described in Section Section 6.6.


5.  Protocol Definitions


   Here are the ASN.1 definitions that describe how the
   msgSecurityParameters field within the msgGlobalData [RFC3412] should
   be encoded.  Note that the msgSecurityParameters field is an OCTET
   STRING, and the SBSMSecurityParameters CHOICE, defined below, would
   be encoded as a normal BER-encoded CHOICE/SEQUENCE and then wrapped
   inside the OCTET STRING when encoded into the msgSecurityParameters
   field of the msgGlobalData.


   Many readers less familiar with ASN.1 may choose to skip to Section
   where the elements of procedure are defined in English text. (Section
   6)


   SBSMSecurityParametersSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN


       -- Needed data types copied from RFC3416:


       Unsigned32 ::= [APPLICATION 2] IMPLICIT INTEGER (0..4294967295)


       --
       -- TODO:
       --  1) State-keeping DoS protection for the Responder
       --  5) too-large packet sizing -- works now, document though
       --  7) handle multiple responses to requests properly.  (don't
       --     assume first message is correct unless authenticated)
       --     (Some places are documented now, need to check all spots)
       --     (mostly done.  need to double check everywhere though)
       --  8) encrypt errors when possible, use NULL when not.


       SBSMSecurityParameters ::=
           CHOICE {
               sbsm-establishment1[0]        SBSMInit1,        -- 0xA0
               sbsm-establishment2[1]        SBSMInit2,        -- 0xA1
               sbsm-establishment3[2]        SBSMInit3,        -- 0xA2
               sbsm-running[3]               SBSMRunning,      -- 0xA3
               sbsm-error[4]                 SBSMError         -- 0xA4
           }


       SBSMInit1 ::=
           SEQUENCE {
               init-identifier               Unsigned32,
               dhgroup-list                  NegotiationList,
               init-DH-value                 NegotiationOctetList,
               init-nonce                    OCTET STRING,
               authentication-list           NegotiationList,




Hardaker & Perkins       Expires April 16, 2005                 [Page 9]
Internet-Draft    A Session-based security model for SNMP   October 2004



               encryption-list               NegotiationList,
               compression-list              NegotiationList,
               init-encryption-parameters    OCTET STRING,
               init-accepted-identity-types  IdentityTypeList



           }


       SBSMInit2 ::=
           SEQUENCE {
               init-identifier               Unsigned32,
               resp-identifier               Unsigned32,
               sequence-number               Unsigned32
               dhgroup                       OBJECT IDENTIFIER,
               resp-DH-value                 OCTET STRING,
               resp-nonce                    OCTET STRING
               authentication-algorithm      OBJECT IDENTIFIER,
               resp-encryption-parameters    OCTET STRING,
               encryption-algorithm          OBJECT IDENTIFIER,
               encryption-parameters         OCTET STRING,
               compression-algorithm         OBJECT IDENTIFIER,
               compression-parameters        OCTET STRING,



               -- Encrypted SBSMInit2Encr:
               resp-information              OCTET STRING,
           }


       SBSMInit2Encr ::=
           SEQUENCE {
               max-window-size               INTEGER (0..255),
               resp-engineID                 OCTET STRING (0|5..32),
               resp-accepted-identity-types  IdentityTypeList,



               resp-identity-type            Unsigned32,
               resp-identity                 OCTET STRING,
               resp-proof1                   OCTET STRING,
               resp-proof2                   OCTET STRING,
           }


       SBSMInit3 ::=
           SEQUENCE {
               to-identifier                 Unsigned32,
               sequence-number               Unsigned32
               encryption-parameters         OCTET STRING,
               compression-parameters        OCTET STRING,
               -- Encrypted SBSMInit3Encr:




Hardaker & Perkins       Expires April 16, 2005                [Page 10]
Internet-Draft    A Session-based security model for SNMP   October 2004



               init-information              OCTET STRING,
           }


       SBSMInit3Encr ::=
           SEQUENCE {
               window-size                   INTEGER (0..255),
               init-engineID                 OCTET STRING (0|5..32)



               init-identity-type            Unsigned32,
               init-identity                 OCTET STRING,
               init-proof1                   OCTET STRING,
               init-proof2                   OCTET STRING,
           }


       SBSMRunning ::=
           SEQUENCE {
               to-identifier                 Unsigned32,
               sequence-number               Unsigned32
               authentication-parameters     OCTET STRING,
               encryption-parameters         OCTET STRING
               compression-parameters        OCTET STRING,
           }


       --
       -- Error structures
       --


       SBSMError ::=
           SEQUENCE {
               to-identifier                 Unsigned32,
               error-code                    SBSMErrorCode
               error-description             OCTET STRING,
               sequence-number               Unsigned32
               authentication-parameters     OCTET STRING,
           }


       -- numbers are synched with SNMPv2 PDU error codes just for ease
       -- of #defines and enum lists.
       SBSMErrorCode ::=
           INTEGER {
               noError(0),   -- never used
               genErr(5),
               resourceUnavailable(13),


               noSupportedAuthAlgorthim(100),
               noSupportedPrivAlgorthim(101),
               noSupportedDHGroup(102),




Hardaker & Perkins       Expires April 16, 2005                [Page 11]
Internet-Draft    A Session-based security model for SNMP   October 2004



               insufficientNonce(103),
               insufficientEncryptionParameters(104),
               insufficientCompressionParameters(105),
               noSupportedIdentityType(106),


               incorrectIdentityType(107),
               identificationError(108),
               identityAuthenticationError(109),
               unacceptableIdentity(110),
               identityContinuationNeeded(111)
               messageAuthenticationError(112),
               messageEncryptionError(113),
               messageCompressionerror(114),


               sessionClosing(150)
               sessionClosed(151)
           }


       --
       -- Support structures
       --


       NegotiationList ::=
            SEQUENCE (SIZE (0..32)) OF OBJECT IDENTIFIER


       NegotiationOctetList ::=
            SEQUENCE (SIZE (0..32)) OF OCTET STRING


       -- This is a list of supported SNMP security models which are
       -- valid for use within a SBSM session.
       IdentityTypeList ::=
            SEQUENCE (SIZE (0..255)) OF Unsigned32


       --
       -- Security sequences for signing
       --
       -- the contents of these two sequences MUST NOT be transmitted in
       -- this form (the values are transmitted in other sequences).
       -- They exist purely for BER encoding before being signed by
       -- an identity.


       SBSMResponderProofInfo ::=
           SEQUENCE {
               init-nonce                    OCTET STRING,
               resp-messages                 SEQUENCE (SIZE (0..255))
                                                 OF OCTET STRING






Hardaker & Perkins       Expires April 16, 2005                [Page 12]
Internet-Draft    A Session-based security model for SNMP   October 2004



           }


       SBSMInitiatorProofInfo ::=
           SEQUENCE {
               resp-nonce                    OCTET STRING,
               init-messages                 SEQUENCE (SIZE (0..255))
                                                 OF OCTET STRING



           }
   END



6.  Elements of Procedure


6.1  Session State Information


   When a session exists within a SNMP engine, a certain amount of state
   must be kept and associated with it.  This amounts to the following
   collection of information.  The data is listed as normal SNMP SMIv2
   data types, but can be stored in any fashion as long as the bits on
   the wire end up being encoded properly as the elements of procedures
   require.  In particular, the startTime value would be more
   efficiently implemented if stored as a local clock value format (like
   an integer value as returned by the common time() function).



   SBSMSessionStoreDefs DEFINITIONS IMPLICIT TAGS ::= BEGIN


      Unsigned32 ::= [APPLICATION 2] IMPLICIT INTEGER (0..4294967295)


      SBSMSessionStore ::=
         SEQUENCE {
             local-identifier                 Unsigned32,
             remote-identifier                Unsigned32,
             session-status                   INTEGER { init1(1),
                                                        init2(2),
                                                        up(3),
                                                        closed(4) }
             security-model                   Unsigned32,
             diffieHelmanExponent             NegotiationOctetList,
             remote-nonce                     OCTET STRING,
             outgoingSequenceNumber           Unsigned32,
             incomingMinSequenceNumber        Unsigned32,
             window-size                      INTEGER (1..255),
             securityName                     OCTET STRING,
             authenticationType               OBJECT IDENTIFER,
             encryptionType                   OBJECT IDENTIFER,




Hardaker & Perkins       Expires April 16, 2005                [Page 13]
Internet-Draft    A Session-based security model for SNMP   October 2004



             incomingEncryptionParameters     OCTET STRING,
             outgoingEncryptionParameters     OCTET STRING,
             incomingAuthenticationKey        OBJECT STRING,
             outgoingAuthenticationKey        OBJECT STRING,
             incomingEncryptionKey            OBJECT STRING,
             outgoingEncryptionKey            OBJECT STRING,
             startTime                        Unsigned32,
             legalSessionLength               Unsigned32,  -- seconds
             remoteEngineID                   OCTET STRING (0|5..32)
             -- data store array for replaying responses
             lastIncomingInit                 OCTET STRING,
             messageStoreList                 SEQUENCE (SIZE(0..255))
                                                 OF SBSMMessageStore


             -- Other session information may be useful to keep in the
             -- session store, such as the remote destination
             -- transport address, etc.
         }


     SBSMMessageStore ::=
         SEQUENCE {
             sequence-number                  Unsigned32,
             timestamp                        Unsigned32,
             message                          OCTET STRING
         }
   END


   The descriptions of how the value for each field is obtained is
   outlined in section Section 6.5.


   SNMP Engines MUST occasionally review their open session list and
   close any sessions where the current time minus the startTime is
   greater the number of seconds indicated by the legalSessionLength
   field (see section Section 6.1.1).


   The legalSessionLength field MAY be implemented as a global system
   policy.  IE, it is not required that each session's length be
   individually configurable and a global system policy may be used
   instead.


6.1.1  Closing sessions


   When a session is closed either due to a normal operation, or due to
   an error condition which mandates that the session be closed, the
   store.session-status field should be set to closed(4) and all future
   traffic to such a session MUST trigger a unknownSBSMSession error
   condition message (described below).  After a period of time defined
   by local policy (a suggested default is 300 seconds) or after a




Hardaker & Perkins       Expires April 16, 2005                [Page 14]
Internet-Draft    A Session-based security model for SNMP   October 2004



   maximum number of allowed closed connections is hit (a suggested
   default is 30), then the session should be deleted from the session
   store.


   When a session is first set to closed, an implementation MUST zeroize
   the following fields:


   diffieHelmanExponent
   incomingEncryptionParameters
   outgoingEncryptionParameters
   incomingAuthenticationKey
   outgoingAuthenticationKey
   incomingEncryptionKey
   outgoingEncryptionKey


   Implementations SHOULD zeroize the entire memory contents for the
   session state just before the session is actually deleted from the
   store.


6.2  The msgSecurityModel field in the msgGlobalData


   [refs.RFC3412] documents the msgGlobalData field which is used to
   indicate the security model is use.  In the following elements of
   procedure, the value XXX:IANA ASSIGNMENT MUST be used.  However, the
   VACM processing [refs.RFC3415] documents processing of authorization
   of incoming requests.  For use within authorization processing within
   the VACM or any other security models, the value passed to the
   isAccessAllowed directive MUST be the security-model value from the
   current session store.  IE, each identification algorithm is always
   transmitted across the wire using the XXX:IANA ASSIGMENT but for
   authorization purposes the individual identity type's specified value
   must be used instead.


6.3  Diffie-Helman exchange and key derivation


   [this section needs a lot more work, but the basic concepts are
   there.  A very large portion of this text was stolen from the current
   IKEv2 internet-draft.]


   The output of a diffie-helman exchange produces a negotiated
   symmetric secret key known only to the two sides of the negotiation.
   The keying material needed for both the authentication and encryption
   algorithms to be used are derived from this initial negotiated key
   using the following procedure.  In the following text, prf indicates
   a pseudo-random function.  This function, for purposes of this
   security model, is the HMAC algorithm combined with the negotiated
   authentication algorithm.





Hardaker & Perkins       Expires April 16, 2005                [Page 15]
Internet-Draft    A Session-based security model for SNMP   October 2004



6.3.1  Generating Keying Material


   Keying material will always be derived as the output of the
   negotiated message authentication algorithm (HMAC).  Since the amount
   of keying material needed may be greater than the size of the output
   of the prf algorithm, we will use the prf iteratively.  We will use
   the terminology prf+ to describe the function that outputs a
   pseudo-random stream based on the inputs to a prf as follows: (where
   | indicates concatenation)


      prf+ (K,S) = T1 | T2 | T3 | T4 | ...


      where:
      T1 = prf (K, S | 0x01)
      T2 = prf (K, T1 | S | 0x02)
      T3 = prf (K, T2 | S | 0x03)
      T4 = prf (K, T3 | S | 0x04)


   continuing as needed to compute all required keys.  The keys are
   taken from the output string without regard to boundaries (e.g.  if
   the required keys are a 256 bit AES key and a 160 bit HMAC key, and
   the prf function generates 160 bits, the AES key will come from T1
   and the beginning of T2, while the HMAC key will come from the rest
   of T2 and the beginning of T3).


   The constant concatenated to the end of each string feeding the prf
   is a single octet.  prf+ in this document is not defined beyond 255
   times the size of the prf output.


6.3.2  Generating the session keys


          SKEYSEED = prf(init-nonce | resp-nonce, g^ir)


          {K-ai, K-ar, K-ei, K-er}
                    = prf+ (SKEYSEED, g^ir | init-nonce | resp-nonce |
                            init-identifier | resp-identifier )


   Note: the init-identifier and resp-identifier MUST be 4 bytes and
   stored in network byte order.


   The 4 derived session keys are used for the following purposes:


      K-ai: Authentication of messages from the initiator.


      K-ar: Authentication of messages from the responder.







Hardaker & Perkins       Expires April 16, 2005                [Page 16]
Internet-Draft    A Session-based security model for SNMP   October 2004



      K-ei: Encryption of messages from the initiator.


      K-er: Encryption of messages from the responder.


   The proper use of these keys will be further discussed in the
   following sections.


6.4  Authenticaton and Encryption Algorithms


   The negotiated authentication and encryption algorithms used by the
   SBSM security model duplicate those defined for the User Based
   Security model (USM) [refs.RFC3414].  The mechanisms for calling
   their ASI primitives are the same, although some minor implementation
   details are slightly different for use within SBSM.  Future
   equivalent or better authentication and encryption algorithms defined
   in future documents for use within the SBSM framework and those
   documents MUST specify if there are any changes for use within the
   SBSM protocol.  At the time of this writing, the current list of
   acceptable authentication and encryption algorithms include:


   Authentication:


      *  SNMP-USER-BASED-SM-MIB::usmHMACMD5AuthProtocol


      *  SNMP-USER-BASED-SM-MIB::usmHMACSHAAuthProtocol


   Encryption:


      *  SNMP-USER-BASED-SM-MIB:usmDESPrivProtocol


      *  SNMP-USM-AES-MIB::usmAesCfb128Protocol


   NULL-equivalent authentication algorithms (IE,
   SNMP-USER-BASED-SM-MIB::usmNoAuthProtocol) MUST NOT be used within
   the SBSM framework, as both authentication and encryption algorithms
   will be needed to securely finish the establishment of a session.


   At a minimum, the usmHMACSHAAuthProtocol protocol MUST be supported
   and the usmAesCfb128Protocol SHOULD be supported.  Implementations
   MAY choose to implement the usmHMACMD5AuthProtocol and
   usmDESPrivProtocol values as well.


6.4.1  Differences from USM encryption algorithm implementations


   One difference exists between how encryption algorithms are used
   within the USM and how they are used within the SBSM.  Within the
   USM, the initialization vectors (IVs) passed to the encryption
   algorithms are created using the engineBoots and engineTime values,




Hardaker & Perkins       Expires April 16, 2005                [Page 17]
Internet-Draft    A Session-based security model for SNMP   October 2004



   which are not required for implementation of the SBSM protocol.


   To alleviate this, when the encryption algorithms are used within the
   SBSM their IVs are created as follows.  First a vector of the
   appropriate length (L) for the encryption algorithm (for DES this
   would be 64 bits, and for AES this would be 128 bits) is filled by
   concatenating first the 32 bit sequence-number encoded in network
   byte order (see the rest of this section for the details on
   calculating this value) along with a random value calculated at
   session initialization time for each side.  The random value should
   be of sufficient length to fill the vector for the encryption
   algorthim being used.  IE, if L is the required IV length in bits for
   an algorthim, then the vector is generated using:


      vector = sequence-number | random(L - 32)


   For usmDESPrivProtocol, the vector is then used as the "salt"
   according to section 8.1.1.1 of [refs.RFC3414].


   For usmAesCfb128Protocol, the vector is then used as the IV for the
   protocol.


   The init-encryption-parameters field of the SBSMInit1 message MUST be
   filled with a sufficient length vector suitable for use by any of the
   encryption algorithms offered in the encryption-list field.


   For the algorithms mentioned in this document, the
   init-encryption-parameters field of the SBSMInit1 and
   resp-encryption-parameters field of the SBSMInit2 MUST be filled in
   using the random portion of the vector.  For the algorithms mentioned
   in this document, the encryption-parameters field of the SBSMINIT3
   and SBSMRunning messages MUST be left as a zero length octet string.
   This requires that each side retain the random portion of the vector
   values for the incoming and outgoing directions in the session state
   store in the OutgoingEncryptionParameters and
   IncomingEncryptionParameters fields so that the calculation of the
   correct IV can take place during both encryption and decryption.


   These procedures are required MUST be followed for the encryption
   algorithms listed in this document, and MAY be used by future
   algorithms defined in future documents.


   These procedures are designed to ensure that a given vector is never
   reused for a given encryption key and that the vectors are only
   transmitted once to reduce packet sizes for running sessions.







Hardaker & Perkins       Expires April 16, 2005                [Page 18]
Internet-Draft    A Session-based security model for SNMP   October 2004



6.5  Creating new sessions


   This section describes the process by which new sessions are created
   on both sides of the protocol.  This is done using a handshake
   process that will eventually result in the creation of a valid
   session, or unrecoverable errors in extreme cases.  Once a session is
   established, the procedures in Section Section 6.6 should be followed
   to make use of the live session.


   All SBSMInit1 and SBSMInit3 messages MUST be sent with a contained
   PDU payload of an empty GET payload.  All SBSMInit2 messages MUST be
   sent containing a PDU payload of an empty REPORT PDU.  All SBSMInit1,
   SBSMInit2, SBSMInit3 and SBSMRunning messages MUST be sent with a
   securityModel value for the assigned SBSM security model value (see
   Section Section 6.2)


   It should be noted that within the Session Initialization phase
   *only* the fields within the msgSecurityParameters field can be
   trusted.  Modification on the wire of any of the rest of the
   parameters in a normal SNMPv3 message will not be detected by the
   security model as a session is getting set up.  However, this is of
   no consequence since all of the values will be safely ignored or will
   generate errors at a higher layer (E.G., within the message
   processor) that will cause the packet to be dropped before it gets to
   the security model.  No real SNMP transmitted packet is ever acted
   upon during session initialization, and thus only the session
   parameters need to be protected against modification and/or
   disclosure (and they are as appropriate).


6.5.1  Session initialization and generation of SBSMInit1


   The sequence values of the first message should be filled in as
   follows:


   1.  The store.local-identifier field is filled in using a unique
        value which has not been assigned to any other session within
        the session store storage.  An entry in the session store is
        created for this store.local-identifier index value.


   2.  The SBSMInit1.init-DH-value value is the initiator's half of the
        Diffie-Helman transaction.  One value should be generated for
        every dhgroup being offered in the dhgroup-lis field using the
        Diffie-Helman group information defined in Appendix Appendix A
        or other appropriate standards documents.


   3.  XXX The SBSMInit1.init-nonce value MUST be composed of randomly
        chosen octets and of size equal to half of the sum of the
        maximum key length of all the authentication algorithms




Hardaker & Perkins       Expires April 16, 2005                [Page 19]
Internet-Draft    A Session-based security model for SNMP   October 2004



        potentially in use and the maximum key length of all the
        encryption algorithms potentially in use.  IE, length = (Ka +
        Ke)/2.


   4.  The SBSMInit1.dhgroup-list should be filled in using values
        supported by the local system that were desired to be used by
        the calling system.


   5.  The SBSMInit1.authentication-list and SBSMInit1.encryption-list
        fields are filled in using desired algorithms to be used by the
        session for message authentication checking and encryption
        (respectively).  The valid values for these fields are dictated
        by the list of authentication and encryption protocols supported
        by the implementation (see Section Section 6.4 for details).


        At least one authentication and encryption algorithm MUST be
        specified and the list MUST NOT include any NULL-equivalent
        algorithms.


   6.  The following assignments are made relative to the recently
        created store and the SBSMInit1 message (some of these have
        already been discussed above, but are repeated here for
        completeness:


   7.  The SBSMInit1.init-encryption-parameters value MUST be randomly
        chosen of size equal to the maximum size value needed by any of
        the values in SBSMInit1.encryption-list as dictated by the
        selected encryption algorithm (see Section Section 6.4.1).  The
        value is then stored in the store.outgoingEncryptionParameters
        field of the session store.


   8.  The SBSMInit1.init-accepted-identity-types field should be filled
        in with acceptable identity types, in order of preference, for
        the responder to use when returning an identity, such as those
        specified in Section Section 8 for a list of identity types.


   9.  The SBSMInit1.compression-parameters field should be filled in
        according to the initialization needs of the compression
        algorithms being proposed.













Hardaker & Perkins       Expires April 16, 2005                [Page 20]
Internet-Draft    A Session-based security model for SNMP   October 2004



        store.session-status = init1(1)


        SBSMInit1.init-identifier = store.local-identifier
        SBSMInit1.init-DH-value = generated.list.diffie-helman-half
        store.diffieHelmanExponent = generated.list.diffie-helman-half
        SBSMInit1.init-nonce = generated.init-nonce
        SBSMInit1.dhgroup-list = policy.dhgroup-list
        SBSMInit1.authentication-list = policy.authentication-list
        SBSMInit1.encryption-list = policy.encryption-list
        store.outgoingEncryptionParameters =
            generated.encryption-parameters
        SBSMInit1.init-accepted-identity-types =
            policy.accepted-identity-types


   10.  Timers should be used to determine if a packet was lost and to
        retransmit the exact same copy of the SBSMInit1 message after a
        suitable period of time.  A new SNMPv3 message MAY be created,
        but a new SBSMInit1 message SHOULD NOT be created and the
        previous exact copy should be sent instead.  After a
        implementation dependent number of retries, the session SHOULD
        be deleted and an error reported to the application.



6.5.2  Reception of SBSMInit1 and generation of SBSMInit2


   When a SNMPv3Message is received containing a SBSMInit1 message
   encoded into the securityParameters field, it MUST follow the
   following elements of procedure below to establish it's side of the
   SBSM session.


   Note: If at any time during processing of the SBSMInit1 message an
   error occurs which prevents further processing of the message (such
   as insufficient resources, etc), then a SBSMError message may be
   returned containing a error-code of genErr or resourceUnavailable and
   processing should stop and the active session store deleted (if it
   exists yet).


   1.  If an existing session exists within the session store with the
        session-status of init1(1) and a lastIncomingInit value equal to
        the SBSMInit1 incoming message, the SBSMInit2 message contained
        in the messageStore[0].message session state MUST be resent.
        Processing then MUST be stopped and the packet dropped.  This
        processing serves to respond to retransmitted packets from the
        other side, but prevents recalculation on the responder's side.
        If no such matching session exists, it is deemed to be a new
        request (IE, not a retransmission of a previously sent SBSMInit1
        message) and processing continues.





Hardaker & Perkins       Expires April 16, 2005                [Page 21]
Internet-Draft    A Session-based security model for SNMP   October 2004



   2.  If an existing session exists within the session store with the
        session-status of init2(1) and a lastIncomingInit value equal to
        the SBSMInit1 incoming message, the SBSMInit1 message must be
        dropped.


   3.  The lists of offered message authentication and encryption
        algorithms (authentication-list, encryption-list) are examined
        for support and accepted values.  One of each type MUST be
        selected and the first in each list that is acceptable SHOULD be
        the one selected.  The resulting selected algorithms are later
        referred to as authAlgorthim and encrAlgorthim.


   4.  If a message authentication algorithm, encryption algorithm or
        diffie-helman group can't be picked (E.G., they are unsupported
        or administratively prohibited), then: A SBSMError message
        should be returned to the sender with a error-code of either
        unsupportedAuthAlgorthim, unsupportedPrivAlgorthim or
        unsupportedDHGroup.  The message is dropped and further
        processing is stopped.


   5.  If the init-nonce value is not of sufficient length to support
        the selected authentication and encryption algorithm (See
        section Section 6.5.1 for length requirement details), then: A
        SBSMError message should be returned to the sender with a
        error-code of insufficientNonce.  The message is dropped and
        further processing is stopped.


   6.  The list of offered identity types, found in the
        init-accepted-identity-types field, is examined.  If multiple
        acceptable identities are listed, then the first acceptable
        value in the list SHOULD be selected although responder
        implementations MAY choose to select a different one based on
        local policy.  We will refer to this selection later as
        policy.selectedOutgoingIdentityType.  If no acceptable identity
        type is found within the list then an SBSMError message should
        be returned with a error-code of noSupportedIdentityType


   7.  If the encryption algorithm chosen requires the use of the
        init-encryption-parameters field and it is not of sufficient
        length, then: A SBSMError message should be returned to the
        sender with a error-code of insufficientEncryptionParameters.
        The message is dropped and further processing is stopped.


   8.  If the compression algorithm chosen requires the use of the
        init-compression-parameters field and it is not of sufficient
        length, then: A SBSMError message should be returned to the
        sender with a error-code of insufficientCompressionParameters.
        The message is dropped and further processing is stopped.




Hardaker & Perkins       Expires April 16, 2005                [Page 22]
Internet-Draft    A Session-based security model for SNMP   October 2004



   9.  A unique local-identifier is generated and a new session store is
        created to store session parameters.  A SBSMInit2 response
        message (including the SBSMInit2Encr SEQUENCE) is also created.
        The two structures are filled in using the following guidelines:


        SBSMInit2.init-identifier = SBSMInit1.init-identifier
        SBSMInit2.resp-identifier = store.local-identifier
        SBSMInit2.dhgroup = policy.dhgroup
        SBSMInit2.authentication-algorithm = policy.authAlgorthim
        SBSMInit2.encryption-algorithm = policy.encrAlgorthim
        SBSMInit2.sequence-number = 0


        store.session-status = init1(1)
        store.local-identifier = generated.identifier
        store.remote-identifier = message.init-identifier
        store.authenticationType = policy.authAlgorthim
        store.encryptionType = policy.encrAlgorthim
        store.init-encryption-parameters =
            SBSMInit1.init-encryption-parameters
        store.outgoingSequenceNumber = 0
        store.incomingSequenceNumber = 0
        store.startTime = generated.now
        store.legalSessionLength = policy.session-length
        store.lastIncomingInit = message


        // Other values may be needed or desired by implementations.


   10.  The store's resp-DH-value value is the responder's half of the
        Diffie-Helman transaction using the Diffie-Helman group defined
        by the accepted SBSMInit2.dhgroup field and the related values
        found in Appendix Appendix A or other appropriate standards
        documents.  It's value is stored in the resp-DH-value field of
        the SBSMInit2 message.


   11.  The resp-nonce value MUST be randomly chosen and of size equal
        to half of the sum of the maximum key length of all the
        authentication algorithms potentially in use and the maximum key
        length of all the encryption algorithms potentially in use.  IE,
        length = (Ka + Ke)/2.


        SBSMInit2.resp-nonce = generated.resp-nonce


   12.  A suitable value for the SBSMInit2.resp-encryption-parameters
        field MUST be randomly chosen of size equal to the needed as
        dictated by the selected encryption algorithm (see Section
        Section 6.4.1).  The value is then stored in both the store and
        the SBSMInit2 message:





Hardaker & Perkins       Expires April 16, 2005                [Page 23]
Internet-Draft    A Session-based security model for SNMP   October 2004



        store.outgoingCompressionParameters =
             generated.encr-parameters


   13.  A suitable value for the SBSMInit2.resp-compression-parameters
        field MUST be chosen according to the compression algorithm in
        use (see Section Section 9).


        store.outgoingCompressionParameters =
             generated.compression-parameters


   14.  The session keys (K-ai, K-ar, K-ei, and K-er) are derived from
        the Diffie-Helman derived secret key (g^ir) and the init-nonce
        and resp-nonce values according to the procedures in Section
        Section 6.3.


   15.  These keys are stored in the session store according to the
        following mapping:


        store.incomingAuthenticationKey = generated.K-ai
        store.outgoingAuthenticationKey = generated.K-ar
        store.incomingEncryptionKey = generated.K-ei
        store.outgoingEncryptionKey = generated.K-er


   16.  The max-window-size field of the SBSMInit2Encr sequence are
        filled in according to local policy.


        SBSMInit2Encr.max-window-size = policy.selected-window-value


   17.  The resp-engineID field is filled in with a suitable default
        engineID which can be used in the engineID field of a ScopedPDU
        for transmissions requiring them from the remote side, or a zero
        length string if no value is suitable.


        SBSMInit2Encr.resp-engineID = policy.local-engineID


   18.  The resp-accepted-identity-types field should be filled in with
        acceptable identity types, in order of preference, for the
        initiator to use when returning an identity.  For a list of
        identity types specified by this document, see Section Section 8
        for a list of identity types.


        SBSMInit2Encr.resp-accepted-identity-types =
            policy.accepted-identity-types


   19.  The resp-identity-type and resp-identity fields are filled in
        using the policy.selectedOutgoingIdentityType value selected
        above and the identity value for that type to be transmitted to
        the initiator.  The proper format for this field is dictated by




Hardaker & Perkins       Expires April 16, 2005                [Page 24]
Internet-Draft    A Session-based security model for SNMP   October 2004



        the resp-identity-type value being used and its associated
        implementation details in Section Section 8.


        SBSMInit2Encr.resp-identity-type =
            policy.selectedOutgoingIdentityType
        SBSMInit2Encr.resp-identity = policy.identity


   20.  The securityName field of the session store is derived from the
        same policy.selectedOutgoingIdentityType security model's
        identity mapping transform, also described in Section Section 8.
        XXX: should be bi-directional sec names


   21.  The resp-proof2 field is filled in using the results of a
        message authentication signature created using the algorithm
        indicated by the store.authenticationType value and the
        store.outgoingAuthenticationKey key to sign the contents of the
        resp-identity field.


   22.  The resp-proof1 field is filled in using an identity
        authentication signature created using the key and signing
        algorithm associated with resp-identity (see Section Section 8)
        to sign an encoded SBSMResponderProofInfo SEQUENCE.  This
        sequence includes the nonce value sent by the initiator as well
        as all of the messages sent by the responder to the initiator up
        till and including this message being sent.  To include this
        message, it must be first encoded in its entirety except for the
        resp-proof1 field, which should be left as a proper length field
        containing as many 0x00 value octets as is needed to fill the
        field.  Once the signature has been created, the field should be
        filled in with the newly generated value.


        Note: The init-nonce field within the SBSMResponderProofInfo
        sequence operation MUST include the BER tag and length fields
        from the on-the-wire packet format.


        To fill in the resp-information field during this identity
        authentication step, use the plain-text version of the
        SBSMInit2Encr sequence wrapped in an OCTET STRING and placed
        into the resp-information field.


   23.  The entire SBSMInit2Encr SEQUENCE is encoded according to BER
        encoding rules and the resulting byte sequence is then encrypted
        using the store.encryptionType algorithm and the
        store.outgoingEncryptionKey key.  The resulting cyphertext bytes
        are then stored, after being wrapped in an OCTET STING, in the
        resp-information field within the SBSMInit2 SEQUENCE.


   24.  The entire SBSMInit2 message, once constructed, is returned to




Hardaker & Perkins       Expires April 16, 2005                [Page 25]
Internet-Draft    A Session-based security model for SNMP   October 2004



        the sender of the initial SBSMInit1 message as a REPORT message.


   25.  The messageStore[0].message value is set to the entire encoded
        SBSMInit2 SEQUENCE.  The session store is stored for later
        retrieval.


        store.messageStore[0] = SBSMInit2


   26.  Success is returned to the calling module, along with the
        contents of the SBSMInit1 packet to be sent.  Note that the
        packet returned MUST NOT be processed by an application.



6.5.3  Reception of SBSMInit2 and generation of SBSMInit3


   When a SNMPv2Message is received containing a SBSMInit2 message
   encoded into the securityParameters field, it MUST follow the
   elements of procedure below to finish establishing it's side of the
   SBSM session:


   1.  The local session store is examined to determine if a session
        exists where the store.local-identifier field matches the
        SBSMInit2.init-identifier field.  If not, the message is dropped
        and processing is ceased.  If one is found but the
        store.session-status field is set to up(2), the message is also
        dropped and processing is ceased.  XXX: the only legal value
        should be init1


   2.  The anti-replay processing discussed in Section Section 6.9.2 is
        performed.  This should only happen when a responder needed to
        retransmit an SBSMInit2 message that was deemed to be lost.
        After the SBSMInit3 message is retransmitted, further processing
        of the incoming SBSMInit2 message is stopped.


   3.  The diffie-helman exchange is completed using the appropriate
        store.diffieHelmanExponent value and the SBSMInit2.resp-DH-value
        value.  This should produce a g^ir value.


   4.  The session keys (K-ai, K-ar, K-ei, and K-er) are derived from
        the Diffie-Helman derived secret key (g^ir) and the init-nonce
        and resp-nonce values according to the procedures in Section
        Section 6.3.


   5.  The SBSMInit2.resp-information field is decrypted using the
        encryption type specified by the SBSMInit2.encryption-algorithm
        field, the SBSMInit2.encryption-parameters field and the
        generated.K-er key to produce a decrypted but possibly still
        compressed SBSMInit2Encr SEQUENCE.  The results are then




Hardaker & Perkins       Expires April 16, 2005                [Page 26]
Internet-Draft    A Session-based security model for SNMP   October 2004



        decompressed using the compression algorithm defined and the
        SBSMInit2.compression-parameters field.  The values of the
        SBSMInit2Encr field are then parsed.  If the values can not be
        parsed, then the snmpInASNParseErrs counter [RFC3418] is
        incremented, and an error indication (parseError) is returned to
        the calling module.


   6.  The list of offered identity types, found in the
        SBSMInit2Encr.resp-accepted-identity-types field, are examined.
        If no acceptable identity type is found within the list then an
        authenticated and encrypted SBSMError message should be returned
        to the responder with an error-code of noSupportedIdentityType.
        If multiple acceptable identities are listed, then the first
        acceptable value in the list SHOULD be selected although
        responder implementations MAY choose to select a different one
        based on local policy.  We will refer to this selection later as
        policy.selectedOutgoingIdentityType.


   7.  The SBSMInit2Encr.resp-identity-type field is examined and
        checked to see if the identity type matches one of the types
        sent in the initial SBSMInit1 message and that it matches
        locally acceptable identity types.  If not, then an
        authenticated and encrypted SBSMError message should be returned
        to the responder with an error-code of incorrectIdentityType.


   8.  The SBSMInit2Encr.resp-identity field is examined, according to
        the security model and associated parameters (see Section
        Section 8) and if it does not match the expected identity for
        the other side of the session, processing is stopped and an
        authenticated and encrypted SBSMError message should be returned
        to the responder with an error-code of identificationError.


   9.  The SBSMInit2Encr.resp-proof1 field value is checked to ensure it
        matches the expected signature as described in Section Section
        6.5.2 using the signing mode described by the security model in
        Section Section 8.  If the signature in the
        SBSMInit2Encr.resp-proof1 field does not match the output of the
        signature alogrithm, then processing is stopped and an
        authenticated and encrypted SBSMError message should be returned
        to the responder with an error-code of
        identityAuthenticationError.  Note that the session MUST NOT be
        dropped due to this error since a packet may arrive from the
        real identity with proper credentials.


   10.  the SBSMInit2Encr.resp-proof2 field value is checked to ensure
        it matches the expected message authentication signature as
        described in Section Section 6.5.2 using the authentication mode
        described by the store.authentication-algorithm field along with




Hardaker & Perkins       Expires April 16, 2005                [Page 27]
Internet-Draft    A Session-based security model for SNMP   October 2004



        the store.incomingAuthenticationKey key.  If the signature in
        the SBSMInit2Encr.resp-proof2 field does not match the output of
        the authentication alogrithm, then an authenticated and
        encrypted SBSMError message should be returned to the responder
        with an error-code of messageAuthenticationError.


   11.  Now that the SBSMInit2 message has been deemed authentic, the
        initiator can fully establish its side of the session
        parameters:


        store.session-status = init2(2)
        store.outgoingAuthenticationKey = generated.K-ai
        store.incomingAuthenticationKey = generated.K-ar
        store.outgoingEncryptionKey = generated.K-ei
        store.incomingEncryptionKey = generated.K-er
        store.authenticationType = SBSMInit2.authentication-algorithm
        store.encryptionType = SBSMInit2.encryption-algorithm
        store.remoteEngineID = SBSMInit2.resp-engineID
        store.incomingSequenceNumber = SBSMInit2.sequence-number
        store.window-size =
            min(policy.window-size, SBSMInit2Encr.max-window-size)
        store.startTime = generated.now
        store.legalSessionLength = policy.session-length


        A.  The store.diffieHelmanExponent memory contents is erased/
            zeroed.


        B.  The store.securityName field is filled in using the mapping
            described by the security model to extract it from the
            SBSMInit2.resp-identity field.


   12.  The SBSMInit3 SEQUENCE is created, as is a SBSMInit3Encr
        SEQUENCE, and its values are filled in as follows:


        store.outgoingSequenceNumber = store.outgoingSequenceNumber + 1


        XXX: local-identifier not needed in init3?
        SBSMInit3.to-identifier = store.remote-identifier
        SBSMInit3Encr.window-size = store.window-size
        SBSMInit3.sequence-number = store.outgoingSequenceNumber


        A.  The init-engineID field is filled in with a suitable default
            engineID which can be used in the engineID field of a
            ScopedPDU for transmissions requiring them from the remote
            side, or a zero length string if no value is suitable:


        SBSMInit3Encr.init-engineID = policy.local-engineID





Hardaker & Perkins       Expires April 16, 2005                [Page 28]
Internet-Draft    A Session-based security model for SNMP   October 2004



        B.  The init-identity-type and init-identity fields are filled
            in using the identity-type value selected above and the
            identity value for that type to be transmitted to the
            initiator.  The proper format for this field is dictated by
            the init-identity-type value being used and its associated
            implementation details in Section Section 8.


        SBSMInit3Encr.init-identity-type =
            policy.selectedOutgoingIdentityType
        SBSMInit3Encr.init-identity = policy.identity


        C.  The SBSMInit3Encr.init-proof1 field is filled in using a
            authentication signature created using the key associated
            with SBSMInit3Encr.init-identity (see Section Section 8) to
            sign an encoded SBSMInitiatorProofInfo SEQUENCE, which
            includes the necessary fields from the SBSMInit1, SBSMInit2
            and SBSMInit3 messages to ensure proper authentication can
            be determined by the responder.


            The SBSMResponderProofInfo SEQUENCE is encoded using the
            actual BER encoded values taken from the on-the-wire
            messages.  They MUST be identical copies of the transmitted
            values using the exact same encoding as was transmitted on
            the wire.  Care must be taken that the values transmitted by
            the other side are used exactly how they were sent.


            Note: Identity authentication schemes which require multiple
            negotiation might specify that the init-proof1 field is to
            be left blank and implementations supporting negotiating
            identity authentication mechanisms should except this.


        D.  The SBSMInit3Encr.init-proof2 field is filled in using a
            HMAC authentication signature created using the
            store.outgoingAuthenticationKey to sign the contents of the
            SBSMInit3Encr.init-identity field using the
            store.authenticationType algorithm.


            Note: The resp-identity field value within the HMAC
            operation includes the BER tag and length fields from the
            on-the-wire packet format.


            Note: Identity authentication schemes which require multiple
            negotiation might specify that the init-proof2 field is to
            be left blank and implementations supporting negotiating
            identity authentication mechanisms should except this.


        E.  The SBSMInit3Encr SEQUENCE is encrypted using the
            store.encryptionType encryption algorithm and




Hardaker & Perkins       Expires April 16, 2005                [Page 29]
Internet-Draft    A Session-based security model for SNMP   October 2004



            store.outgoingEncryptionKey and then wrapped in an OCTET
            STRING and placed into the SBSMInit3.resp-information field.
            For the vector generation, described in Section Section
            6.4.1, a sequence-number of SBSMInit3.sequence-number MUST
            be used.


   13.  The initiator of the session MAY begin transmitting messages
        under protection of the newly created session at this point,
        assuming the identity authentication for the initiator is
        complete.  However, it should be noted that the SBSMInit3
        message may not have been received by the responder and thus
        retransmissions may be necessary at a future time.  Thus, the
        initiator SHOULD wait for the reception of a proper SBSMRunning
        acknowledgment message first.


   14.  Timers should be used to determine if the SBSMInit3 message was
        lost (IE, no SBSMRunning acknowledgment message was received)
        and to retransmit the exact same copy of the SBSMInit3 message
        after a suitable period of time (as dictated by local policy).
        A new SNMPv3 message MAY be created, but a new SBSMInit3 message
        MUST NOT be created and the previous exact same bitwise copy
        MUST be sent.  Once the local session status has been set to
        up(3) by related processing from Section Section 6.6.2 then
        retransmissions of SBSMInit3 MUST stop.  After an implementation
        dependent number of retries, the session SHOULD be deleted and a
        failure should be returned to the application which requested
        session creation.


   15.  Success is returned to the calling module, along with the
        contents of the packet to be sent.  Note that the packet
        returned MUST NOT be processed by an application and is only
        intended for use by the SNMP engine.



6.5.4  Reception of the SBSMInit3 message and generation of the
      SBSMRunning REPORT


   When a SNMPv3Message is received containing a SBSMInit3 message
   encoded into the securityParameters field, it MUST follow the
   elements of procedure below to finish establishing it's side of the
   SBSM session:


   1.  The local session store is examined to determine if a session
        exists where the store.local-identifier field matches the
        SBSMInit3.to-identifier field.  If not, the message is dropped
        and processing is ceased.


   2.  If the store.session-status field is already set to up(2) then




Hardaker & Perkins       Expires April 16, 2005                [Page 30]
Internet-Draft    A Session-based security model for SNMP   October 2004



        processing continues as in Section Section 6.6.2, as the
        store.messageStore must contain an already generated answer for
        the SBSMInit3 message.  XXX move to an independent section.  XXX
        state should only be one state (init1?)


   3.  The SBSMInit3.init-information field is decrypted using the
        store.encryptionType and store.incomingEncryptionKey fields from
        the session store to produce a decrypted SBSMInit3Encr SEQUENCE.
        The values of the SBSMInit3Encr field are then parsed.  If the
        values can not be parsed, then the snmpInASNParseErrs counter
        [RFC3418] is incremented, and an error indication (parseError)
        is returned to the calling module.


   4.  The SBSMInit3Encr.init-identity field is examined, according to
        the security model and associated parameters (see section
        Section 8) and if it does not match an acceptable identity for
        the other side of the session then: an authenticated SBSMError
        message should be returned to the responder with an error-code
        of unacceptableIdentity, processing is stopped and an error
        indication (authenticationFailed?) is returned.  The store can
        be freed and the session establishment dropped.


   5.  The SBSMInit3Encr.init-proof1 field value is checked to ensure it
        matches the expected signature as described in Section Section
        6.5.3 using the signing mode described by the security model in
        section Section 8.


        If the identity authentication mechanism specifies that further
        processing is needed, a SBSMError message should be returned to
        the responder with an error-code of identityContinuationNeeded
        and a error-description field specificly encoded according to
        the needs of identity authentication mechanism.  Processing of
        the incoming message should be stopped, although the session
        should be left in its current state.


        If the signature in the SBSMInit3Encr.init-proof1 field does not
        match the output of the signature alogrithm, then: an
        authenticated SBSMError message should be returned to the
        responder with an error-code of identityAuthenticationError,
        processing is stopped and an error indication
        (authenticationFailed?) is returned.  The store can be freed and
        the session establishment dropped.


   6.  The SBSMInit3Encr.init-proof2 field value is checked to ensure it
        matches the expected message authentication signature as
        described in Section Section 6.5.3 using the authentication mode
        described by the store.authenticationType field along with the
        store.incomingAuthenticationKey.




Hardaker & Perkins       Expires April 16, 2005                [Page 31]


        If the identity authentication mechanism specifies that further
        processing is needed, a SBSMError message should be returned to
        the responder with an error-code of identityContinuationNeeded
        and a error-description field specificly encoded according to
        the needs of identity authentication mechanism.  Processing of
        the incoming message should be stopped, although the session
        should be left in its current state.


        If the signature in the SBSMInit3Encr.init-proof1 field does not
        match the output of the message authentication alogrithm, then:
        an authenticated SBSMError message should be returned to the
        responder with an error-code of messageAuthenticationError,
        processing is stopped and an error indication
        (authenticationFailed?) is returned.  The store can be freed and
        the session establishment dropped.


   7.  Now that the SBSMInit3 message has been deemed authentic and the
        remote identity has been verified, the responder can fully
        establish the remaining portions of its side of the session
        parameters:


        store.session-status = up(2)
        store.window-size =
            min(policy.maximum-window-size, SBSMInit3Encr.window-size)
        store.startTime = generated.now
        store.legalSessionLength = policy.session-length
        store.remoteEngineID = SBSMInit3.init-engineID



        A.  The store.securityName field is filled in using the mapping
            described by the security model to extract it from the
            init-identity field.


   8.  A REPORT message is generated with a PDU containing the
        sbsmSessionsEstablished counter after it has been incremented.
        The REPORT is sent using the newly created session with a
        security level of authPriv and the mechanisms described in
        Section Section 6.6.1 using a SBSMRunning message.  This message
        will be the first message sent over the live session, from the
        viewpoint of the responder and serves as an acknowledgment to
        the initiator that the SBSMInit3 message was received.


   9.  The responder of the session may begin transmitting messages
        under protection of the newly created session at this point.


   10.  XXX: store processing








Hardaker & Perkins       Expires April 16, 2005                [Page 32]
Internet-Draft    A Session-based security model for SNMP   October 2004



6.6  Processing messages in an active session.


   Once a session has been established, messages may be then sent and
   received through it using the procedures defined in this section.


6.6.1  Outgoing Messages on an open session.


   This section describes the procedure followed by an SNMP engine
   whenever it generates a message containing a management operation
   (like a request, a response, a notification, or a report) through an
   open SBSM session.  The elements of procedure below define how to
   fill in the values within the sbsm-running element which is then
   encoded by wrapping it as an OCTET STRING and placing it in the
   SNMPv3Message's msgSecurityParameters field.


   1.  If any securityStateReference is passed (EG, for a Response or
        Report message), then information concerning the session is
        extracted from the storedSecurityData.  The storedSecurityData
        can now be discarded after its two values, the local-identifier
        and the from-sequence-number fields, are extracted from the
        securityStateReference.


   2.  If a securityStateReference is not passed, then a
        local-identifier must have been passed.  If not, then a error
        indication (unknownSBSMSession) is returned to the calling
        module.


   3.  The security session state is looked up based on the value of the
        local-identifier parameter, and if not found then an error
        indication (unknownSBSMSession) is returned to the calling
        module.


   4.  If the current time minus the store.startTime is greater than the
        number of seconds from the store.legalSessionLength field (or
        any other value from a policy that restricts session time
        lengths), then the session MUST be immediately closed (see
        Section Section 6.1.1 for information on closing a session) and
        a unknownSBSMSession error returned to the calling module.


        Applications MAY choose to initiate another session under which
        the new message will be sent if the message type is not in
        reponse to another message (E.G., a Response-PDU or a Report-PDU
        and thus no storedSecurityData was passed in and thus no
        from-sequence-number value is available).  If it is a
        reponse-class message then no new session is open and processing
        of the PDU MUST be dropped after the unknownSBSMSession error is
        returned.





Hardaker & Perkins       Expires April 16, 2005                [Page 33]
Internet-Draft    A Session-based security model for SNMP   October 2004



   5.  If the passed securityLevel specifies that the message is to be
        protected from disclosure, but the session does not support both
        an authentication and a encryption protocol then the message
        cannot be sent.  An error indication (unsupportedSecurityLevel)
        is returned to the calling module.


   6.  If the securityLevel specifies that the message is not to be
        authenticated, then the message cannot be sent.  An error
        indication (unsupportedSecurityLevel) is returned to the calling
        module.


        SBSMRunning.to-identifier = store.remote-identifier


   7.  The procedures for anti-replay protection described in Section
        Section 6.9.1 MUST be followed at this point.


   8.  If the session is making use of a compression algorithm, then the
        ScopedPDU is compressed according to the
        store.compression-algorithm and any compression-parameters
        required by the algorithm are stored in the
        SBSMRunning.compression-parameters field.


   9.  Possibly encrypt the ScopedPDU


        A.  If the securityLevel specifies that the message is not to be
            protected from disclosure, then a zero-length OCTET STRING
            is encoded into the SBSMRunning.encryption-parameters field
            and the plaintext scopedPDU serves as the payload of the
            message being prepared.


        B.  If the securityLevel specifies that the message is to be
            protected from disclosure, then the octet sequence
            representing the serialized scopedPDU is encrypted according
            to the store.encryptionType encryption protocol (see Section
            Section 6.4 for more details) .  To do so a call is made to
            the encryption module that implements the
            store.encryptionType encryption algorithm using the
            store.outgoingEncryptionKey as the encryption key.


            If the encryption module returns failure, then the message
            cannot be sent and an error indication (encryptionError) is
            returned to the calling module.


            If the encryption module returns success, then the returned
            privParameters (if any, see Section Section 6.4.1) are put
            into the SBSMRunning.encryption-parameters field and the
            encryptedPDU serves as the payload of the message being
            prepared.




Hardaker & Perkins       Expires April 16, 2005                [Page 34]
Internet-Draft    A Session-based security model for SNMP   October 2004



   10.  The message is authenticated according to the session's
        authentication protocol (see Section Section 6.4).  To do so a
        call is made to the authentication module that implements the
        store.authenticationType algorithm using the
        store.outgoingAuthenticationKey as the authentication key.


        If the authentication module returns failure, then the message
        cannot be sent and an error indication (authenticationFailure)
        is returned to the calling module.


        If the authentication module returns success, then the
        authentication-parameters field is put into the sbsm-running and
        the authenticatedWholeMsg represents the serialization of the
        authenticated message being prepared.


   11.  The completed message with its length is returned to the calling
        module with the statusInformation set to success.



6.6.2  Incoming Messages on an open session.


   This section describes the procedure followed by an SNMP engine
   whenever it receives a message sent through an active SBSM session
   with a particular securityLevel.


   XXX: delete? To simplify the elements of procedure, the release of
   state information is not always explicitly specified.  As a general
   rule, if state information is available when a message gets
   discarded, the state information should also be released.  Also, an
   error indication can return an OID and value for an incremented
   counter and optionally a value for securityLevel, and values for
   engineID or contextID (from ScopedPDU) for the counter.  In addition,
   the securityStateReference data is returned if any such information
   is available at the point where the error is detected.


   1.  If the received securityParameters is not the serialization
        (according to the conventions of [RFC3417]) of an OCTET STRING
        formatted according to the SBSMSecurityParameters defined in
        section 2.4, then the snmpInASNParseErrs counter [RFC3418] is
        incremented, and an error indication (parseError) is returned to
        the calling module.  Note that we return without the OID and
        value of the incremented counter, because in this case there is
        not enough information to generate a Report PDU.


   2.  The values of the SBSMRunning fields are extracted and the value
        of the SBSMRunning.to-identifier is used to look up a session
        store with a store.local-identifier equal to the
        SBSMRunning.to-identifier.  If no such session store is found,




Hardaker & Perkins       Expires April 16, 2005                [Page 35]
Internet-Draft    A Session-based security model for SNMP   October 2004



        processing is stopped and a unknownSBSMSession is returned to
        the calling module.


   3.  If the current session is considered closed, then an
        unknownSBSMSession error returned to the calling module.


   4.  check against valid session states...  must be up or just have
        sent init3 right?


   5.  If the current time minus the store.startTime is greater than the
        number of seconds from the store.legalSessionLength field (or
        any other value from a policy that restricts session time
        lengths), then the session MUST be immediately closed (see
        Section Section 6.1.1 for information on closing a session) and
        an unknownSBSMSession error returned to the calling module.


   6.  If the SNMPv3 message's securityLevel specifies that the message
        was not authenticated, then processing is stopped, the
        sbsmStatsUnsupportedSecLevels counter is incremented and an
        error indication (unsupportedSecurityLevel) together with the
        OID and value of the incremented counter is returned to the
        calling module.  IE, message authentication is a requirement of
        the SBSM security model.


   7.  The anti-replay processing described in Section Section 6.9.2
        MUST be followed at this point.


   8.  The store.session-status field is set to up(3) if it is not set
        to up(3) yet (IE, it might be set to init2(2) if no response had
        been received from the SBSMInit3 message yet).


   9.  If the SNMPv3 message's securityLevel indicates that the message
        was not protected from disclosure, then the scopedPDU is assumed
        to be in plain text format.


   10.  If the securityLevel indicates that the message was protected
        from disclosure, then the OCTET STRING representing the
        encryptedPDU is decrypted according to the store.encryptionType
        encryption protocol, the message.encryption-parameters field and
        the store.incomingEncryptionKey to obtain an unencrypted
        serialized scopedPDU value.  To do so a call is made to the
        encryption module that implements the store.encryptionType
        encryption protocol using the store.incomingEncryptionKey as the
        encryption secret key.


        If the encryption module returns failure, then the message can
        not be processed, so the sbsmStatsDecryptionErrors counter is
        incremented and an error indication (messageEncryptionError)




Hardaker & Perkins       Expires April 16, 2005                [Page 36]
Internet-Draft    A Session-based security model for SNMP   October 2004



        together with the OID and value of the incremented counter is
        returned to the calling module.


        If the encryption module returns success, then the decrypted
        scopedPDU is used as the message payload to be later returned to
        the calling module.


   11.  If the session.compression-algorithm field indicates the packet
        should be compressed, then the compression algorithm is passed
        the scopedPDU field and the message.compression-parameters field
        and the results are used as the new scopedPDU.  If the
        compression algorithm fails, then the sbsmStatsCompressionErrors
        counter is incremented and an error condition
        (messageCompressionError) is returned to the calling module and
        processing is stopped.


   12.  If the PDU contained within the scopedPDU is a REPORT message of
        type sbsmSessionEstablished, then the message is dropped and
        processing is stopped.  Success is returned to the calling
        module.


   13.  The maxSizeResponseScopedPDU is calculated.  This is the maximum
        size allowed for a scopedPDU for a possible Response message.
        Provision is made for a message header that allows the same
        securityLevel as the received Request.


   14.  The securityName to be used when processing this message is
        retrieved from store.securityName.


   15.  The security data is stored as storedSecurityData, so that a
        possible response to this message can and will use the same
        authentication and encryption parameters.  Information to be
        saved/stored is as follows:


           local-identifier


           sequence-number


   16.  The store.messageStoreList[sequence-number mod
        window-size].sequence-number field from the session store is set
        to the SBSMRunning.sequence-number of the incoming message.


   17.  The statusInformation is set to success and a return is made to
        the calling module passing back the OUT parameters as specified
        in the processIncomingMsg primitive.  Note that the application,
        especially for purposes of access control determination, should
        process the message as if it came through a security module
        equivalent to the security-model from the session store.  IE, a




Hardaker & Perkins       Expires April 16, 2005                [Page 37]
Internet-Draft    A Session-based security model for SNMP   October 2004



        application should not need be aware of SBSM processing but
        should only be aware of the identity mechanism used instead,
        which maps to a real SNMP security model number.



6.7  Processing SBSMError messages.


6.7.1  Processing outgoing SBSMError messages.


   Outgoing error codes are generated using a SBSMError message, used
   only when indicated by the elements of procedure in either Section
   Section 6.5 or Section Section 6.6, are combined with a REPORT PDU
   containing a varbind with an incremented sbsmProtocolError counter
   contained within it and sent in response to the previous message that
   triggered an error.  The procedure for generating the values of the
   SBSMError message are as follows.  These procedures assume that a
   session store has already been found to process the error in.


   1.  A SBSMError sequence is created and the SBSMError.error-code and
       SBSMError.error-description fields are filled according to the
       passed values.


   2.  The procedures set forth in Section Section 6.6.1 should
       generally be followed, although XXX



6.7.2  Processing incoming SBSMError messages.


   When SBSMError mesasges are received either during session creation
   or during a running session, they should be processed according to
   the following procedures, depending on the value of the contained
   error-code.  If no store.local-identifier matches the
   SBSMError.to-identifier, then the message is to be dropped and
   processing of the error message is ceased.


   1.  When the SBSMError.to-identifier matches a store.local-identifier
       and the store.session-status is equal to anything other than
       up(3), then the following error codes are all processed in the
       same manner:


       *  genErr(5)


       *  resourceUnavailable


       *  noSupportedAuthAlgorthim


       *  noSupportedPrivAlgorthim





Hardaker & Perkins       Expires April 16, 2005                [Page 38]
Internet-Draft    A Session-based security model for SNMP   October 2004



       *  insufficientNonce


       *  insufficientEncryptionParameters


       *  noSupportedIdentityType


       *  incorrectIdentityType


       *  identificationError


       *  identityAuthenticationError


       *  unacceptableIdentity


       *  messageAuthenticationError


       Specifically, all these errors indicate that the remote and gin
       was unable to process a SBSMInit1 message properly due to an
       unsupported value.


       Most importantly, an implementation MUST NOT accept one of these
       error messages as authoritative.  They have not been
       cryptographically signed and are thus untrustworthy.  Even if
       they have been properly signed by the negotiated diffie-helman
       key, the identity of the remote side has yet to be proven and
       thus the packet may be the work of an imposter (a
       man-in-the-middle).  They are, however, useful for informational
       purposes.  Upon reception of one of these messages, an action
       SHOULD NOT be taken until a suitable time out has passed, and no
       other corresponding error message or SBSM message was received.


       Reception of one of these messages can be dealt with and one of
       two ways, after the suitable timeout period has passed:


       M.  Cease attempting the establishment of a session, delete the
           local corresponding session store, and log an error.  The
           SBSMError.error-description field might contain a message
           intended for human consumption and implications.


       N.  Attempt to renegotiate the establishment of a session after
           fixing the parameters associated with the error code in
           question.  After new parameters have been generated, the SBSM
           message may be sent again containing the new parameters,
           assuming the session is in a suitable state to do so (E.G.,
           it is known that the other side of the connection hasn't
           closed their side of the negotiation).






Hardaker & Perkins       Expires April 16, 2005                [Page 39]
Internet-Draft    A Session-based security model for SNMP   October 2004



   2.  When the SBSMError.to-identifier matches a store.local-identifier
       and the store.session-status is equal to anything other than
       up(3) and the error-code is set to identityContinuationNeeded and
       the message is properly protected, then the error-description
       field should be passed to the identity authentication module as
       part of a continuing series of identification messages.  The
       identity authentication module should then indicate what should
       happen next: either another SBSMInit3 message should be sent to
       the responder, or the session should be closed as an
       unrecoverable failure was hit (see Section Section 6.1.1 for
       information on closing a session).  When further SBSMInit3 fields
       are sent, it is likely that new init-proof1 and a new init-proof2
       field should be encoded into the new SBSMInit3 message.  Other
       than that, the other fields can be calculated according to the
       procedures outlined in Section Section 6.5.3.


   XXX: sequence-number and caching check


6.8  Closing an active session from either side


   Although implementations must expect the case where the other side of
   a session may have lost its session information, when possible
   closing messages should be sent in order to assist in
   resource-freeing and other cleanup tasks.


   To send a closing-session message, an empty GET PDU is constructed
   and sent to the opposite side with a SBSMError message where the
   error-code value is set to sessionClosing.  This is responded to from
   the other side with a sessionClosed SBSMError message sent coupled
   with a REPORT PDU.  If a REPORT message is not received by the side
   initiating the session closing, it SHOULD resend the close request
   (retrying with a suitable number of close attempts over a suitable
   period of time).  Note that if the remote side has already closed its
   session, it will send a unknownSBSMSession SBSMError REPORT although
   it will be unable to properly authenticate it.


   When closing a session, the session cache must be cleaned according
   to the description in Section Section 6.1.1.


6.9  Processing the SBSM messages for anti-replay support.


   there are multiple points within the SBSM protocol where messages may
   be resent or retransmitted either intentionally by one side of the
   session or maliciously by an attacker.  For these cases, the SBSM
   protocol is designed to officially take care of such messages.  This
   section describes the processing required to support this for both
   incoming and outgoing messages of all types.





Hardaker & Perkins       Expires April 16, 2005                [Page 40]
Internet-Draft    A Session-based security model for SNMP   October 2004



   The most fundamental concept to understand is that once a response to
   an incoming message it is stored by the security model so that the
   application and SNMP engine does not have to regenerate the response
   at a future time.  Each SBSM message contains a sequence-number
   field, which is monotonically increasing in nature, deficit this
   sequence number that helps provide this replay protection.  The size
   of this outgoing cash is dependent on a number of factors: the local
   implementation supported maximum, the locally defined policy, and the
   negotiated window-size parameter.


   Another important point is that the real transmission of previous
   requests do not result in an application reprocessing the request.
   Only the security model and the SNMP engine needs to be aware of the
   reach transmission, which should save computational cycles and used
   to lead to denial of service attacks.  It should be noted that
   message indication and encryption services are still exercised again,
   but this competition should be lower than what would be needed to
   completely recompute a new response.  It is recommended that engines
   which currently deal with retransmissions of lost requests now do so
   using these services when possible.


6.9.1  Processing outgoing messages


   Anytime a new outgoing message is being sent which is a direct
   response to an incoming message, it is stored as follows:



        /* update the caching information for the current message */
        store.outgoingSequenceNumber = store.outgoingSequenceNumber + 1
        outgoingMessage.sequence-number = store.outgoingSequenceNumber



   If the outgoing message is in response to an incoming message, then
   the sequence-number field must be available and the following
   processing is performed:


        /* put the outgoing message in the store in the right place */
        tempvar.N =
           incomingMessage.sequence-number mod store.window-size


        store.messageStore[tempvar.N].sequence-number =
             incomingMessage.sequence-number
        store.messageStore[tempvar.N].message =
             outgoingMessageData                      /* see below */
        store.messageStore[tempvar.N].timestamp = generated.now()


   If the value of the store.outgoingSequenceNumber wraps in the above
   process, the session MUST be immediately closed (see Section Section




Hardaker & Perkins       Expires April 16, 2005                [Page 41]
Internet-Draft    A Session-based security model for SNMP   October 2004



   6.1.1 for information on closing a session)and unknownSBSMSession
   error returned to the calling module.


   For the outgoingMessageData, whatever data is needed to reconstruct
   the response properly should be stored here.  For messages which are
   specific to the negotiation portion of the SBSM protocol, this would
   generally be the protocol fields as well as the possibly-mostly-blank
   ScopedPDU.  In general, sensed this specification can not mandate
   that the other side of the session use an identical SNMPv3 message,
   it must be possible to receive a new SNMPv3 message from the other
   side which contains a new msgID field and still be able to
   reauthenticate the message without regenerating any of the other SBSM
   fields or the enclosed ScopedPDU.  For outgoing messages on a running
   session, the only outgoingMessageData that is to be saved should be
   the unencrypted ScopedPDU.  Note that the unencrypted version must be
   saved since the retransmission of the SNMPv3 message may have dropped
   the encryption flag.


6.9.2  Processing Incoming Messages


   When an incoming message is received, it should be subject to the
   following processing procedures for all message types except
   SBSMInit1 messages:


   1.  If the incomingMessage.sequence-number is less than the
       store.incomingMinSequenceNumber, then an error indication
       (authenticationFailure) is returned to the calling module and
       processing is stopped.


   2.  If the message is an SBSMInit2 or SBSMInit3 message or is a
       SBSMRunning message but is not a response class message, and the
       second three of both these statements are both true:


        tempvar.N =
           incomingMessage.sequence-number mod store.window-size


        incomingMessage.sequence-number <
               store.incomingMinSequenceNumber + store.window-size


        incomingMessage.sequence-number ==
               store.messageStoreList[tempvar.N].sequence-number


        store.messageStoreList[tempvar.N].timestamp >=
               generated.now() + 300 seconds




       Then: the message stored in the




Hardaker & Perkins       Expires April 16, 2005                [Page 42]
Internet-Draft    A Session-based security model for SNMP   October 2004



       store.messageStoreList[tempvar.N].message field is returned as
       the answer to the incoming request and is returned to the calling
       module.  An application MUST NOT process this request and the
       resulting response message contained within the store message
       MUST be used to generate a duplicate response.  Processing should
       then continue through the outgoing processing steps for the given
       outgoing message type, but using the
       store.messageStoreList[tempvar.N].message value as the returned
       message.


   3.  If the message is a response class message, and if both of the
       following two statements are true:


        incomingMessage.sequence-number <
                 store.incomingMinSequenceNumber + store.window-size


           store.messageStoreList[tempvar.N].sequence-number ==
                 incomingMessage.sequence-number field


        Then the message is dropped as it has already been previously
       received.


   4.  The message's authentication is checked according to the
       store.authenticationType authentication protocol and
       store.incomingAuthenticationKey.  To do so a call is made to the
       authentication module that implements the
       store.authenticationType authentication protocol using the
       store.incomingAuthenticationKey as the authentication secret key.


       If the authentication module returns failure, then the message
       cannot be trusted, so the sbsmStatsWrongDigests counter is
       incremented and an error indication (sbsmIntegrityFailure)
       together with the OID and value of the incremented counter is
       returned to the calling module.


       If the authentication module returns success, then the message is
       authentic and can be trusted so processing continues.


   5.  The store.incomingMinSequenceNumber is then updated: to be the
       maximum of:


        store.incomingMinSequenceNumber =
             min(store.incomingMinSequenceNumber,
                 incomingMessage.sequence-number - store.window-size)


        If the new incomingMinSequenceNumber number wraps or is set to
       2^32-1-store.window-size, then the session MUST be closed after
       this message is processed (see Section Section 6.1.1 for




Hardaker & Perkins       Expires April 16, 2005                [Page 43]
Internet-Draft    A Session-based security model for SNMP   October 2004



       information on closing a session).



7.  MIB Definitions


   The MIB included below is only minimal in nature (obviously) but it
   is a start.  Feedback on useful objects to be placed into this MIB
   would be highly appreciated.


   SBSM-MIB DEFINITIONS ::= BEGIN


   IMPORTS
       MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Integer32,
       Unsigned32, Counter32               FROM SNMPv2-SMI


       TEXTUAL-CONVENTION
                                           FROM SNMPv2-TC


       MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
                                           FROM SNMPv2-CONF


       InetAddressType, InetAddress, InetPortNumber
                                           FROM INET-ADDRESS-MIB
   ;


   --
   -- module identity
   --


   sbsmMIB MODULE-IDENTITY
       LAST-UPDATED "200402150000Z"
       ORGANIZATION "IETF non-existent SBSM Working Group"
       CONTACT-INFO "Wes Hardaker
                     Sparta, Inc.
                     P.O. Box 382
                     Davis, CA  95617
                     Phone: +1 530 792 1913
                     Email: hardaker@tislabs.com"
       DESCRIPTION
        "This MIB module defines objects for managing the SNMPv3 SBSM
        security module.


         Copyright (C) The Internet Society (2004). This version of
         this MIB module is part of RFC XXXX, see the RFC itself for
         full legal notices."


   -- Revision History





Hardaker & Perkins       Expires April 16, 2005                [Page 44]
Internet-Draft    A Session-based security model for SNMP   October 2004



       REVISION     "200402150000Z"
       DESCRIPTION  "Initial version, published as RFC xxxx."
       -- RFC-editor assigns xxxx


   -- XXX: To be assigned by IANA
       ::= { XXX }


   --
   -- groups of related objects
   --


   sbsmObjects         OBJECT IDENTIFIER
        ::= { sbsmMIB 1 }
   sbsmNotificationObjects   OBJECT IDENTIFIER
        ::= { sbsmMIB 2 }
   sbsmConformanceObjects    OBJECT IDENTIFIER
        ::= { sbsmMIB 3 }


   --
   -- Textual Conventions
   --


   sbsmCounterObjects OBJECT IDENTIFIER ::= { sbsmObjects 1 }
   sbsmSessionObjects OBJECT IDENTIFIER ::= { sbsmObjects 2 }
   sbsmCompressionDefinitions
      OBJECT IDENTIFIER ::= { sbsmObjects 3 }


   --
   -- Counter objects
   --
   sbsmSessionsEstablished OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           ""
       ::= { sbsmCounterObjects 1}


   sbsmStatsUnsupportedSecLevels OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           ""
       ::= { sbsmCounterObjects 2}


   sbsmStatsDecryptionErrors OBJECT-TYPE
       SYNTAX      Counter32




Hardaker & Perkins       Expires April 16, 2005                [Page 45]
Internet-Draft    A Session-based security model for SNMP   October 2004



       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           ""
       ::= { sbsmCounterObjects 3}


   sbsmStatsCompressionErrors OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           ""
       ::= { sbsmCounterObjects 4}


   sbsmProtocolError OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           ""
       ::= { sbsmCounterObjects 5}


   sbsmStatsWrongDigests OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           ""
       ::= { sbsmCounterObjects 6}


   --
   -- Established sessions
   --


   sbsmSessionTable OBJECT-TYPE
       SYNTAX      SEQUENCE OF SbsmSessionEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "A table describing currenly open, currently being established
           or recently closed SBSM sessions."
       ::= { sbsmSessionObjects 1 }


   sbsmSessionEntry OBJECT-TYPE
       SYNTAX      SbsmSessionEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION




Hardaker & Perkins       Expires April 16, 2005                [Page 46]
Internet-Draft    A Session-based security model for SNMP   October 2004



           ""
       INDEX   { sbsmId }
       ::= { sbsmSessionTable 1 }


   SbsmSessionEntry ::= SEQUENCE {
       sbsmId            Unsigned32
   }


   sbsmId OBJECT-TYPE
       SYNTAX      Unsigned32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           ""
       ::= { sbsmSessionEntry 1 }



   -- remote ID, state, alg types in use, started when, misc counters, ...
   -- (suggestions welcome)


   --
   -- Compression algorithms
   --
   sbsmNullCompressionAlgorithm
       OBJECT IDENTIFIER ::= { sbsmCompressionDefinitions 1 }


   sbsmGZipCompressionAlgorithm
       OBJECT IDENTIFIER ::= { sbsmCompressionDefinitions 1 }


   sbsmBZip2CompressionAlgorithm
       OBJECT IDENTIFIER ::= { sbsmCompressionDefinitions 1 }


   --
   -- other MIB items to do:
   --
   -- o notifications
   -- o configuration of policy.  eg: user A using algorthim B/C
   --   is different than user X using Y/Z.




   END




8.  Identification Mechanisms


   overall picture: TBD




Hardaker & Perkins       Expires April 16, 2005                [Page 47]
Internet-Draft    A Session-based security model for SNMP   October 2004



8.1  Public Key Based Identities


8.1.1  Security Model assignment


   This mechanism defines multiple identity types, all of which are
   based on public-key mechanisms for authentication.  The SNMP security
   model numbers will be assigned by (IANA).  These models include:


   o  BER encoded signature-based X.509 certificate.


   o  PGP certificate.


   o  ssh public key.


   o  PKIX certificate


   o  XXX



8.1.2  Format of the identity field


   Certificate based identities are identities which are represented by
   public key based certificates.  Multiple types of certificates are
   defined below, but not all types of certificates may be supported by
   all implementations.


   The identity, when transmitted, will be formated according to the
   following definition:


   CertificateSecurityIdentity DEFINITIONS IMPLICIT TAGS ::= BEGIN


     CertificateIdentityInformation ::=
        SEQUENCE {
           certificate-user         OCTET STRING,
           certificate-list         CertificateList
        }


     CertificateList ::=
        SEQUENCE (SIZE (0..32)) OF OCTET STRING
   END


   Where:


   certificateUser: The local account the certificate is expected to be
      authorized to grant access for.







Hardaker & Perkins       Expires April 16, 2005                [Page 48]
Internet-Draft    A Session-based security model for SNMP   October 2004



   certificate-list The certificate itself, along with any required
      supporting certificates (E.G.  parent certificates if required),
      all of which are encoded as dictated by the corresponding identity
      type (IE, security model number).



8.1.3  Signatures


   init-proof1 and resp-proof1 are generated by creating a public key
   signing and the resulting signature is used as the value for the
   init-proof1 and resp-proof1 fields.


   Checking the value of the init-proof1 and resp-proof1 fields require
   the following steps:


   1.  If the security model number must be checked and if it is not a
       support typed, then a authentication field error MUST be
       returned.


   2.  The user name mapping must be a legitimate mapping, as explained
       in Section Section 8.1.4 below.


   3.  The value of the signature field should be checked against the
       expected generated value.



8.1.4  Security Name Mapping


   The certificate-user field indicates which securityName the given
   certificate is expected to access.  Legitimate access to this
   securityName via the given certificate MUST be checked for
   authorization for the mapping to take place.  If the provided
   certificate is not allowed to "log into" the given securityName
   account, an authentication error MUST result.


8.2  Local Accounts


   When one side of a session wants to perform a traditional login for
   authentication purposes, this identification mechanism can be used to
   achieve that purpose.  Note that this mechanism is not recommended
   since the user's password is transmitted over the wire, although it
   is encrypted within the session.  It is expected that the mechanism
   will be needed to match current security deployment practices,
   however.  One such example is unix systems which do not have a copy
   of the user's password and must obtain a copy of it to hash and
   ensure that the local password database hash matches the incoming
   password's hash.  A better identification mechanism is specified in
   Section XXX which should be used instead whenever possible.




Hardaker & Perkins       Expires April 16, 2005                [Page 49]
Internet-Draft    A Session-based security model for SNMP   October 2004



   It is critical for security that this mechanism MUST NOT be used to
   authenticate a responder to an initiator.


8.2.1  Security Model assignment


   This mechanism will be assigned the security number XXX (IANA).


8.2.2  Format of the identity field


   The identity, when transmitted, will be formated according to the
   following definition:


   LocalAccountSecurityIdentity DEFINITIONS IMPLICIT TAGS ::= BEGIN


     LocalAccountIdentityInformation ::=
        SEQUENCE {
           userName          OCTET STRING,
           passPhrase        OCTET STRING
        }
   END



8.2.3  Signatures


   Generating init-proof1 requires that a signature be generated to sign
   the protocol values that have been passed over the wire.  To do this,
   the user's passPhrase is converted into a key of an appropriate
   length by using the authentication algorithm, as negotiated via the
   authentication-algorithm field of SBSMInit2, as follows:


     PASSHASH = ALGORITHM_HASH(passPhrase)
     KEY = ALGORITHM_HMAC_HASH(PASSHASH,
                               init-engineID | resp-engineID)


   The KEY is then used to generate a digest using the authentication
   algorithm and protocol indicated by the authentication-algorithm
   value.  It is potentially truncated according to the authentication
   protocol specifications of the authentication-algorithm before being
   inserted into the init-proof1 field of the SBSMInit2Encr portion of
   the message.


     DIGEST = ALGORITHM_HMAC_HASH(KEY, DATA_TO_DIGEST)


   XXX: todo change the engineIDs into proper random nonce data.


8.2.4  Security Name Mapping


   Mapping a local account user name into a securityName for storage in




Hardaker & Perkins       Expires April 16, 2005                [Page 50]
Internet-Draft    A Session-based security model for SNMP   October 2004



   the session store and for use in access control is done using a
   one-to-one mapping.  IE, the userName passed in via the
   IdentityInformation sequence is used directly as the securityName.


8.3  EAP Authentication and Identification


   Although not defined yet, the EAP identification mechanism will
   support a number of important identification concepts missing from
   the previous mechanisms, such as Generic Token Card, One Time
   Password, and two factor authentication support.


   XXX


8.4  SSH Authentication and Identification


   Although not defined yet, the SSH identification mechanism will
   support identifying users and hosts based on the configured ssh keys
   for them.  It will not make use of SSH itself, just the keys to do
   authentication and identification.  Once a SBSM running session has
   been established no use of the SSH identity keys will be needed.  The
   SBSM negotiated algorithms and keys will be used for SBSM/SNMPv3
   running message integrity.


   XXX


9.  Compression Algorithms


9.1  sbsmNullCompressionAlgorithm


   The sbsmNullCompressionAlgorithm algorithm is a NULL compression
   algorithm.  No compression occurs as a result of this algorithm and
   the input and output of the algorithm for both compression and
   decompression are identical.  The compression-parameters field of all
   messages must be set a zero length string.


9.2  sbsmGZipCompressionAlgorithm


   The sbsmGZipCompressionAlgorithm algorithm uses the GZip algorithm to
   compress the SBSM messages.  The compression-parameters field of all
   messages is unneeded and must be set to a zero length string.


9.3  sbsmBZip2CompressionAlgorithm


   The sbsmBZip2CompressionAlgorithm algorithm uses the BZip2 algorithm
   to compress the SBSM messages.  The compression-parameters field of
   all messages is unneeded and must be set to a zero length string.






Hardaker & Perkins       Expires April 16, 2005                [Page 51]
Internet-Draft    A Session-based security model for SNMP   October 2004



10.  Security Considerations


   This document defines a security protocol to be used within the SNMP
   framework for providing authentication, integrity, and encryption of
   SNMP messages.  The elements of procedure defined in this document
   were carefully constructed and must be followed in the proper order
   to ensure the security properties of the SBSM hold true.


   XXX: Write more.


11.  TODO list


   1.  discuss timeout values (don't negotiate, just deny those packets
       in the future?  Doesn't work, necessarily, if managers want to
       know they have an active open session.  But then why not just
       offer a MIB object instead of burdening the security section with
       more fields that won't matter)



12.  History and Acknowledgments


   o  Comments from David:


      Back in 1999 after the updates for SNMPv3 where completed for it
      to be elevated to DRAFT-Standard status, feedback was gathered to
      determine how SNMPv3 was being used in operational networks.  The
      feedback showed that SNMPv3 was not being as widely deployed as
      anticipated.  Only a few vendors were supporting SNMPv3 agents,
      and there was little support in management platforms.  Also, where
      it was supported, it was typically not deployed (turned on).


      This resulted in the start of interactions between the operator
      community and the SNMP community.  Over time, it became clear that
      there was a gap between the needs of the operators and the
      technology defined by the SNMP community.  There were several
      areas where there were gaps.  In the security area, the phrase
      that was heard over and again was that Radius and SSH were used to
      manage user authentication for access to managed devices, and
      SNMPv3/USM created a parallel set of users that had no
      coordination with the existing security infrastructure.


      There were several IETF working groups started to address issues
      unrelated to security, but none were started to address the
      security related issues.  Thus, the investigation into security
      issues was uncordinated by the IETF.  Several individuals attacked
      the security issues.  Ken Hornstein (?sp) looked at creating a
      security model using Kerberos security.  I (and others) looked at
      what it would take to use Radius for user authentication.  After




Hardaker & Perkins       Expires April 16, 2005                [Page 52]
Internet-Draft    A Session-based security model for SNMP   October 2004



      some study, I was convinced that directly using Radius "would not
      work".  This was due to two problems.  The first was that with
      USM, the user identity is carried in each message, and to check
      the user identity with a Radius server would mean that the
      processing of an SNMPv3 message would be delayed until the Radius
      server could authenticate a user's identity.  The added delay,
      recovery from dropped traffic to/from the Radius server, and the
      additional network traffic were judged to be high costs.  The
      second problem was how to support authentication and encryption of
      SNMP messages using Radius technology.  Several approaches were
      considered, but none were determined workable.


      So, if per SNMP operation identity authentication, and then
      message authentication and optionally message encryption are not
      feasible using Radius, how could Radius be used?  It was at that
      point that the idea of creating a session where identity
      authentication was determined, and then creation of session keys
      for message in the session authentication and optional encryption
      was determined.  This fundamentally different approach to
      providing security to SNMPv3 had the promise that many different
      mechanisms could be used to provide identity authentication, and
      negotiated algorithms could be used for message in the session
      authentication and encryption.  Also, I was convinced that
      sessions could be created the ran over UDP, and the overhead of
      the maintained session state was not too costly.


      A sketchy description of this session-based security model was put
      together in June 2001, and shown to a select few during the London
      IETF in July 2001.  The fundamental approach, which is that used
      in this proposal, was contained in that sketchy proposal.  The
      problem was to work through all of the security details.  That is
      when one after another security experts were asked to provide some
      assistance.


      None volunteered until Wes was convinced that there might be merit
      in the approach.  And it took some time before he could start
      focusing on the security details.  This document has only occurred
      due to his dedication to the effort in spite of my delays.


   o  From Wes:


      Much of the work in this document is directly derived from the
      SIGMA protocol [SIGMA].  Specifically, the protocol within this
      document is derived from the SIGMA-I variation of the SIGMA
      protocol.  Some of the design decisions made by the IPsec working
      group surrounding the use of SIGMA in the IKEv2 specification
      [IKEv2] is also reflected here where appropriate (note that IKEv2
      is based on SIGMA-R though).  Finally, some of the text in this




Hardaker & Perkins       Expires April 16, 2005                [Page 53]
Internet-Draft    A Session-based security model for SNMP   October 2004



      document was plagiarized directly from the User Based Security
      module document [RFC3414].


      Discussions Wes has held with the following people over the past
      few years influenced the contents of this document through either
      generation of requirements or design ideas:


         Michael Baer


         Chris Elliot


         Eric Fleishman


         David Harrington


         Ken Hornstein


         Sean O'Keeffe



      David and I have disagreements about where various ideas within
      the draft came from and whether they were derived in parallel or
      not.  He has promised me, though, that I have thought of at least
      one idea in the paper and has thanked me for being an efficient
      pen.



13.  References


13.1  Normative References


   [refs.RFC3412]
              Case, J., "Message Processing and Dispatching for the
              Simple Network Management Protocol (SNMP)", RFC 3412, STD
              62, December 2002.


   [refs.RFC3415]
              Wijen, B., Presuhn, R. and K. McCloghrie, "View-based
              Access Control Model (VACM) for the Simple Network
              Management Protocol (SNMP)", RFC 3415, STD 62, December
              2002.


   [refs.RFC3414]
              Wijen, B. and U. Blumenthal, "User-based Security Model
              (USM) for version 3 of the Simple Network Management
              Protocol (SNMPv3)", RFC 3414, STD 62, December 2002.






Hardaker & Perkins       Expires April 16, 2005                [Page 54]
Internet-Draft    A Session-based security model for SNMP   October 2004



13.2  Informative References


   [refs.v3overview]
              Perkins, D., "An Consolidated Overview of the SNMPv3
              Protocol (Internet-Draft)", February 2004.



Authors' Addresses


   Wes Hardaker
   Sparta
   P.O. Box 382
   Davis  95617
   US


   EMail: hardaker@tislabs.com



   David T. Perkins
   SNMPInfo
   548 Quailbrook Ct
   San Jose  95110
   US


   EMail: dperkins@snmpinfo.com


Appendix A.  Diffie-Helman Group information


A.1  Diffie-Helman Group IKEv2-N5


   This group is represented during negotiations by the OID XXX.


   The Diffie-Helman properties to be used for Diffie-Helman
   calculations using this group is the following.  (Note that this is
   Group 5 from the IKEv2 specification).


   The prime is 2^1536 - 2^1472 - 1 + 2^64 * {[2^1406 pi] + 741804}.
   Its hexadecimal value is


       FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
       8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
       302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
       A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
       49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
       FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
       670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF


   The generator is 2.




Hardaker & Perkins       Expires April 16, 2005                [Page 55]
Internet-Draft    A Session-based security model for SNMP   October 2004



Intellectual Property Statement


   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.


   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.


   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.



Disclaimer of Validity


   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.



Copyright Statement


   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.



Acknowledgment


   Funding for the RFC Editor function is currently provided by the
   Internet Society.





Hardaker & Perkins       Expires April 16, 2005                [Page 56]