Network Working Group W. Hardaker Internet-Draft Sparta Expires: April 2, 2004 October 3, 2003 A Security Based Session Model (SBSM) for the Simple Network Management Protocol (SNMP). draft-hardaker-snmp-session-sm-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 2, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document describes a Session Based Security Model (SBSM) for use within the Simple Network Management Protocol (SNMP). The security model is designed to establish a "session" between two interacting hosts, over which SNMP operations can be sent. It provides a number of security properties not previously available in defined SNMP security models, such as public key based authentication, limited life-time keying, and the ability to make use of previously implemented and deployed security infrastructures for purposes of identification and authentication. Hardaker Expires April 2, 2004 [Page 1] Internet-Draft A Security based session model for SNMP October 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Status of this document . . . . . . . . . . . . . . . . . . 3 2. Definitions and Terminology . . . . . . . . . . . . . . . . 3 3. Goals and Objectives . . . . . . . . . . . . . . . . . . . . 4 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 4 5. Protocol Definitions . . . . . . . . . . . . . . . . . . . . 6 6. Elements of Procedure . . . . . . . . . . . . . . . . . . . 10 6.1 Session State Information . . . . . . . . . . . . . . . . . 10 6.2 The msgSecurityModel field in the msgGlobalData . . . . . . 11 6.3 Diffie-Helman exchange and key derivation . . . . . . . . . 12 6.3.1 Generating Keying Material . . . . . . . . . . . . . . . . . 12 6.3.2 Generating the session keys . . . . . . . . . . . . . . . . 12 6.4 Authenticaton and Encryption Algorithms . . . . . . . . . . 13 6.4.1 Differences from USM encryption algorithm implementations . 14 6.5 Creating new sessions . . . . . . . . . . . . . . . . . . . 15 6.5.1 Session initialization and generation of SBSMInit1 . . . . . 16 6.5.2 Reception of SBSMInit1 and generation of SBSMInit2 . . . . . 17 6.5.3 Reception of SBSMInit2 and generation of SBSMInit3 . . . . . 21 6.5.4 Reception of the SBSMInit3 message . . . . . . . . . . . . . 24 6.6 Processing messages in an active session. . . . . . . . . . 26 6.6.1 Outgoing Messages on an open session. . . . . . . . . . . . 26 6.6.2 Incoming Messages on an open session. . . . . . . . . . . . 29 7. MIB Definitions . . . . . . . . . . . . . . . . . . . . . . 32 8. Identification Mechanisms . . . . . . . . . . . . . . . . . 32 8.1 Public Key Based Identities . . . . . . . . . . . . . . . . 32 8.1.1 Security Model assignment . . . . . . . . . . . . . . . . . 32 8.1.2 Format of the identity field . . . . . . . . . . . . . . . . 33 8.1.3 Signatures . . . . . . . . . . . . . . . . . . . . . . . . . 33 8.1.4 Security Name Mapping . . . . . . . . . . . . . . . . . . . 34 8.2 Local Accounts . . . . . . . . . . . . . . . . . . . . . . . 34 8.2.1 Security Model assignment . . . . . . . . . . . . . . . . . 34 8.2.2 Format of the identity field . . . . . . . . . . . . . . . . 34 8.2.3 Signatures . . . . . . . . . . . . . . . . . . . . . . . . . 35 8.2.4 Security Name Mapping . . . . . . . . . . . . . . . . . . . 35 8.3 EAP Authentication and Identification . . . . . . . . . . . 35 9. Security Considerations . . . . . . . . . . . . . . . . . . 35 10. TODO list . . . . . . . . . . . . . . . . . . . . . . . . . 36 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 36 A. Diffie-Helman Group information . . . . . . . . . . . . . . 36 Normative References . . . . . . . . . . . . . . . . . . . . 37 Author's Address . . . . . . . . . . . . . . . . . . . . . . 37 Intellectual Property and Copyright Statements . . . . . . . 38 Hardaker Expires April 2, 2004 [Page 2] Internet-Draft A Security based session model for SNMP October 2003 1. Introduction This document describes a Session Based Security Model (SBSM) for use within the Simple Network Management Protocol (SNMP). The security model is designed to establish a "session" between two interacting hosts, over which SNMP operations can be sent. It provides a number of security properties not previously available in defined SNMP security models, such as public key based authentication, limited life-time keying, and the ability to make use of previously implemented and deployed security infrastructures for purposes of identification and authentication. These properties and the other goals of the (SBSM) are documented in Section Section 3. Much of this document involves concepts taken from other fields of work, such as from the USM security model, from the SIGMA security protocol, and from 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. 1.1 Status of this document At the time of this writing, the protocol defined within this document is not quite ready for implementation. The specification is about 80% complete, but don't include some important processing features such as error processing, for example. Additionally, there are some known problems that have only been solved on scratch paper sitting on the author's desk. An obvious example is transactions involving packets which are too large (public key certificate transactions involving large hierarchy chains will certainly run into this problem). These problems will be fixed in the next version of this document. The author felt it important to publish this draft as is, however, since the important aspects of the specification are complete and feedback is sought and a number of parties have expressed their interest in reading it as soon as possible. Plus it gives a greater period of time for review before the upcoming IETF meeting. This document is mostly targeting the technical crowd as not much high level documentation has been written to help walk people through the features surrounding the work. This will be remedied in future publications. 2. Definitions and Terminology The following terms are used through this document: Hardaker Expires April 2, 2004 [Page 3] Internet-Draft A Security based session model for SNMP October 2003 initiator: The side of the transaction that starts the session by sending the first SBSM initiation message. An initiator can be both a manager or a managed device and once the session is established all types of transactions may flow through it regardless of origin (IE, the responder can be a manager or managed device). EG, 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 side of the transaction that listens for connections and responds to initiation requests from the initiator. 3. Goals and Objectives The brief list of goals and objectives met by this protocol include (IE, this section is not complete): o Security transactions that make use of previously deployed and widely used mechanisms for establishing authentication. This includes public/private key technologies (including PKI infrastructures), and other common authenticating mechanisms such as Radius servers. o Session-based keying properties such as dynamically created keys and limited lifetime 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. The session parameters are NOT bound to the lower layer transport at well. o ... 4. Protocol Overview The SBSM protocol is designed to meet the goals and objectives listed Hardaker Expires April 2, 2004 [Page 4] Internet-Draft A Security based session model for SNMP October 2003 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 a fair amount of negotiation between the two pairs. The complexity of this exchange has been kept to a bare minimum but still involves a fair number of required parameters to be exchanged. 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 --> ... session started ... [Note XXX: an ack is planned to acknowledge receipt of SBSMInit3, but is not currently defined.] Once a session has been established, the security parameters switch to using the running form of the session security parameters: 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 Hardaker Expires April 2, 2004 [Page 5] Internet-Draft A Security based session model for SNMP October 2003 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. 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 R (eg, ike cookies) -- 5) too-large packet sizing -- 6) negotiation of DH groups -- 7) handle multiple responses to requests properly. (don't -- assume first message is correct unless authenticated) Hardaker Expires April 2, 2004 [Page 6] Internet-Draft A Security based session model for SNMP October 2003 -- -- Flow diagrams: -- -- Establishment: -- I SBSMInit1 -------------> R -- <------------- SBSMInit2 -- SBSMInit3 -------------> -- -- After establishment: -- I <---- SBSMRunning ----> R -- SBSMSecurityParameters ::= CHOICE { sbsm-establishment1[0] SBSMInit1, sbsm-establishment2[1] SBSMInit2, sbsm-establishment3[2] SBSMInit3, -- XXX: An ack is needed for SBSMInit3 sbsm-running[3] SBSMRunning } SBSMInit1 ::= SEQUENCE { init-identifier Unsigned32, init-DH-value OCTET STRING, init-nonce OCTET STRING, authentication-list AlgorithmNegotiationList, encryption-list AlgorithmNegotiationList, init-encryption-parameters OCTET STRING, init-accepted-identity-types IdentityTypeList } SBSMInit2 ::= SEQUENCE { init-identifier Unsigned32, resp-identifier Unsigned32, resp-DH-value OCTET STRING, resp-nonce OCTET STRING authentication-algorithm OBJECT IDENTIFIER, resp-encryption-parameters OCTET STRING, encryption-algorithm OBJECT IDENTIFIER, -- Encrypted SBSMInit2Encr: resp-information OCTET STRING, } Hardaker Expires April 2, 2004 [Page 7] Internet-Draft A Security based session model for SNMP October 2003 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 { init-identifier Unsigned32, resp-identifier Unsigned32, -- Encrypted SBSMInit3Encr: 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 } -- -- Error structures -- SBSMError ::= SEQUENCE { error_code INTEGER (0..255), Hardaker Expires April 2, 2004 [Page 8] Internet-Draft A Security based session model for SNMP October 2003 error_description OCTET STRING, sequence-number Unsigned32 } -- -- Support structures -- -- XXX: 32 ok? Too big (probably)? Too small? AlgorithmNegotiationList ::= SEQUENCE (SIZE (0..32)) OF OBJECT IDENTIFIER -- 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 { resp-identifier Unsigned32, init-nonce OCTET STRING, resp-nonce OCTET STRING resp-DH-value OCTET STRING, max-window-size INTEGER (0..255), resp-engineID OCTET STRING (0|5..32), authentication-algorithm OBJECT IDENTIFIER, encryption-algorithm OBJECT IDENTIFIER, resp-accepted-identity-types IdentityTypeList, } SBSMInitiatorProofInfo ::= SEQUENCE { init-identifier Unsigned32, init-nonce OCTET STRING, resp-nonce OCTET STRING init-DH-value OCTET STRING, authentication-list AlgorithmNegotiationList, encryption-list AlgorithmNegotiationList, Hardaker Expires April 2, 2004 [Page 9] Internet-Draft A Security based session model for SNMP October 2003 init-accepted-identity-types IdentityTypeList, window-size INTEGER (0..255), init-engineID OCTET STRING (0|5..32), } 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). SBSMSessionCacheDefs DEFINITIONS IMPLICIT TAGS ::= BEGIN Unsigned32 ::= [APPLICATION 2] IMPLICIT INTEGER (0..4294967295) SBSMSessionCache ::= SEQUENCE { local-identifier Unsigned32, remote-identifier Unsigned32, session-status INTEGER { init1(1), up(2) } security-model Unsigned32, diffieHelmanExponent OCTET STRING, outgoingSequenceNumber Unsigned32, incomingMinSequenceNumber Unsigned32, window-size INTEGER (1..255), securityName OCTET STRING, authenticationType OBJECT IDENTIFER, encryptionType OBJECT IDENTIFER, incomingEncryptionParameters OCTET STRING, outgoingEncryptionParameters OCTET STRING, incomingAuthenticationKey OBJECT STRING, outgoingAuthenticationKey OBJECT STRING, incomingEncryptionKey OBJECT STRING, Hardaker Expires April 2, 2004 [Page 10] Internet-Draft A Security based session model for SNMP October 2003 outgoingEncryptionKey OBJECT STRING, startTime Unsigned32, legalSessionLength Unsigned32, -- seconds remoteEngineID OCTET STRING (0|5..32) -- data cache array for replaying responses lastIncomingInit OCTET STRING, messageCacheList SEQUENCE (SIZE(0..255)) OF SBSMMessageCache -- Other session information may be useful to keep in the -- session cache, such as the remote destination -- transport address, etc. } SBSMMessageCache ::= SEQUENCE { sequence-number 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. 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.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 cache. 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 Hardaker Expires April 2, 2004 [Page 11] Internet-Draft A Security based session model for SNMP October 2003 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. 6.3.1 Generating Keying Material Keying material will always be derived as the output of the negotiated prf algorithm. 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) Hardaker Expires April 2, 2004 [Page 12] Internet-Draft A Security based session model for SNMP October 2003 {K-ai, K-ar, K-ei, K-er} = prf+ (SKEYSEED, g^ir | init-nonce | resp-nonce | init-identifier | resp-identifier ) The 4 derived session keys are used for the following purposes: K-ai: Authentication of messages from the initiator. K-ai: Authentication of messages from the responder. K-ei: Encryption of messages from the initiator. K-ei: 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 algorithms (IE, SNMP-USER-BASED-SM-MIB::usmNoPrivProtocol and SNMP-USER-BASED-SM-MIB::usmNoAuthProtocol values) 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. Hardaker Expires April 2, 2004 [Page 13] Internet-Draft A Security based session model for SNMP October 2003 At a minimum, the usmHMACSHAAuthProtocol and usmAesCfb128Protocol protocols MUST be supported, and 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, 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 cache in the OutgoingEncryptionParameters and IncomingEncryptionParameters fields so that the calculation of the correct IV can take place during both encryption and decryption. Hardaker Expires April 2, 2004 [Page 14] Internet-Draft A Security based session model for SNMP October 2003 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. 6.5 Creating new sessions There are two view points to creating new sessions: initiating a new session and responding to a request from another entity requesting to create a session. Functionally the entire transaction can be perceived as 3-way handshake negotiation, which is depicted in the following diagram (this assumes no errors are encountered): Initiator Responder ----------- ----------- SBSMInit1 --> <-- SBSMInit2 SBSMInit3 --> ... session started ... 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 each of these values are generated are discussed in the rest of this section. The 3 phases of the hand-shake transaction depicted above are executed using the procedures defined in the following subsections. 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 Hardaker Expires April 2, 2004 [Page 15] Internet-Draft A Security based session model for SNMP October 2003 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 init-identifier field is filled in using a unique value which has not been assigned to any other session within the session cache storage. An entry in the session cache is created for this init-identifier index value and is stored in the local-identifier field of the cache. The session-status field is initialized to init1(1). 2. The init-DH-value value is the initiator's half of the Diffie-Helman transaction using the Diffie-Helman MODP group defined in Appendix Appendix A. It's value must also be copied to the session cache's diffieHelmanExponent field. 3. XXX The init-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. 4. The authentication-list and encryption-list fields are filled in using desired algorithms to be used by the session for authentication/integrity 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 Hardaker Expires April 2, 2004 [Page 16] Internet-Draft A Security based session model for SNMP October 2003 algorithms. 5. The init-encryption-parameters value MUST be randomly chosen of size equal to the maximum size value needed by any of the values in encryption-list as dictated by the selected encryption algorithm (see Section Section 6.4.1). The value is then stored in the outgoingEncryptionParameters field of the session cache. 6. The 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. 7. A SBSM session state should be created which contains the init-identifier stored in the local-identifier field and init-DH-value Diffie-Helman value stored in the diffieHelmanExponent field. 8. 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. 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. 1. If an existing session exists within the session cache with the session-status of init1(1) and a lastIncomingInit value equal to the SBSMInit1 incoming message, the SBSMInit2 message contained in the messageCache[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 SBSMInit1 message) and processing continues. 2. A unique local-identifier is generated and a new session cache is created to store session parameters. A SBSMInit2 response message is also created. The init-identifier field of the response message is filled in using the init-identifier value from the SBSMInit1 message, and the resp-identifier value is Hardaker Expires April 2, 2004 [Page 17] Internet-Draft A Security based session model for SNMP October 2003 filled in using the generated local-identifier value. The generated local-identifier is stored in the local-identifier field of the session cache, and the init-identifier from the SBSMinit1 message is stored in the remote-identifier field. The session cache's session-status field is set to init1(1). 3. The lists of offered 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 supported SHOULD be the one selected. The resulting selected algorithms are stored in the session cache's authenticationType and encryptionType fields. 4. If the init-nonce value is not of sufficient length to support the selected authentication and encryption algorithm, then the session's cache is deleted and processing is stopped. 5. If the encryption algorithm chosen requires the use of the init-encryption-parameters field and it is not of sufficient length, then the session's cache is deleted and processing is stopped. Else, the init-encryption-parameters field is copied to the session cache's incomingEncryptionParameters field 6. The list of offered identity types, found in the init-accepted-identity-types field, are examined. If no acceptable identity type is found within the list then XXX. 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. 7. The resp-DH-value value is the responder's half of the Diffie-Helman transaction using the Diffie-Helman MODP group defined in Appendix Appendix A. It's value is stored in the resp-DH-value field of the SBSMInit2 message. 8. 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. 9. The authentication-algorithm and encryption-algorithm fields are filled in using the values previou sly selected (IE, the authenticationType and encryptionType session cache values). 10. The resp-encryption-parameters value MUST be randomly chosen of size equal to the needed value as dictated by the selected Hardaker Expires April 2, 2004 [Page 18] Internet-Draft A Security based session model for SNMP October 2003 encryption algorithm (see Section Section 6.4.1). The value is then stored in the outgoingEncryptionParameters field of the session cache. 11. 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. These keys are stored in the session cache according to the following mapping: K-ai -> cache.incomingAuthenticationKey K-ar -> cache.outgoingAuthenticationKey K-ei -> cache.incomingEncryptionKey K-er -> cache.outgoingEncryptionKey 12. The max-window-size field of the SBSMInit2Encr sequence is filled in using local policy for the maximum window size supported. 13. The resp-engineID field is filled in with a suitable default engineID which can be used in the contextEngineID field for transmissions requiring them from the remote side, or a zero length string if no value is suitable. 14. 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, such as those specified in Section Section 8 for a list of identity types. 15. The resp-identity-type and resp-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 resp-identity-type value being used and its associated implementation details in Section Section 8. 16. The securityName field of the session cache is derived from the same security model's identity mapping transform, also described in Section Section 8. 17. The resp-proof1 field is filled in using a authentication signature created using the key associated with resp-identity (see Section Section 8) to sign an encoded SBSMResponderProofInfo SEQUENCE, which includes the necessary fields from the SBSMInit1 and SBSMInit2 messages to ensure proper authentication can be determined by the initiator. The SBSMResponderProofInfo SEQUENCE is encoded using the actual Hardaker Expires April 2, 2004 [Page 19] Internet-Draft A Security based session model for SNMP October 2003 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. XXX: does the variable length encoding cause a security problem; can two values be manipulated to return the same bytes in the authentication hash? I think not as long as the BER tags are left in? They definitely shouldn't be left out. 18. The resp-proof2 field is filled in using a HMAC authentication signature created using the outgoingAuthenticationKey key derived from the diffie-helman exchange to sign the contents of the resp-identity field using the algorithm selected previously as the authentication-algorithm. The resp-identity field value within the HMAC operation includes the BER tag and length fields from the on-the-wire packet format. 19. The entire SBSMInit2Encr SEQUENCE according to BER encoding rules and the resulting byte sequence is then encrypted using the algorithm select from the offered set and the outgoingEncryptionKey key derived from the diffie-helman exchange. The resulting cyphertext bytes are then stored, after being wrapped in an OCTET STING, in the resp-information field within the SBSMInit2 SEQUENCE. For the vector generation, described in Section Section 6.4.1, a sequence-number of 0 MUST be used. 20. The startTime of the session cache is set to "now" and the legalSessionLength field is set to a value dictated by local policy. 21. The entire SBSMInit2 message, once constructed, is returned to the sender of the initial SBSMInit1 message as a REPORT message. 22. The session cache's lastIncomingInit field is set to the value of the entire incoming SBSMInit1 SBSM message. The messageCache[0].message value is set to the entire encoded SBSMInit2 SEQUENCE. The session cache is stored for later retrieval. 23. 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. Hardaker Expires April 2, 2004 [Page 20] Internet-Draft A Security based session model for SNMP October 2003 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 cache is examined to determine if a session exists where the local-identifier field matches the init-identifier field of the SBSMInit2 message. If not, the message is dropped and processing is ceased. If one is found, but the session-status field is set to up(2), the message is also dropped and processing is ceased. 2. The diffie-helman exchange is completed using the sent init-DH-value value equal to the diffieHelmanExponent from the session cache and the resp-DH-value value from the SBSMInit2 message. This should produce a g^ir value. 3. 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. 4. The resp-information field is decrypted using the encryption type specified by the encryption-algorithm field and the K-er key to produce a decrypted SBSMInit2Encr SEQUENCE. 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. 5. The list of offered identity types, found in the resp-accepted-identity-types field, are examined. If no acceptable identity type is found within the list then XXX. 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. 6. The 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, XXX. 7. The resp-identity field is examined, according to the security model and associated parameters (see section XXX) and if it does not match the expected identity for the other side of the Hardaker Expires April 2, 2004 [Page 21] Internet-Draft A Security based session model for SNMP October 2003 session, processing is stopped and an error indication (authenticationFailed?) is returned. XXX: inc counter? 8. the 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 resp-proof1 field does not match the output of the signature alogrithm, then processing is stopped and an error indication (authenticationFailed?) is returned. XXX: inc counter? 9. the resp-proof2 field value is checked to ensure it matches the expected HMAC signature as described in Section Section 6.5.2 using the authentication mode described by the authentication-algorithm field along with the incomingAuthenticationKey. If the signature in the resp-proof1 field does not match the output of the authentication alogrithm, then processing is stopped and an error indication (authenticationFailed?) is returned. XXX: inc counter? 10. Now that the SBSMInit2 message has been deemed authentic, the initiator can fully establish its side of the session parameters. A. The keys are stored in the session cache according to the following mapping: K-ai -> cache.outgoingAuthenticationKey K-ar -> cache.incomingAuthenticationKey K-ei -> cache.outgoingEncryptionKey K-er -> cache.incomingEncryptionKey B. the authenticationType and encryptionType fields of the session cache are filled in using the authentication-algorithm and encryption-algorithm fields from the SBSMInit2 SEQUENCE. C. The remoteEngineID cache field is filled in using the value of the resp-engineID field value. D. The diffieHelmanExponent is zeroed. E. The window-size is set to the minimum of: + the desired value passed in, currently stored in the window-size field. + the locally supported maximum Hardaker Expires April 2, 2004 [Page 22] Internet-Draft A Security based session model for SNMP October 2003 + the maxmimumWindow value from the SBSMInit2Encr portion of the incoming message. F. The outgoingSequenceNumber is set to 1, as is the incomingMinSequenceNumber. G. The session-status field of the session cache is set to up(2). H. The securityName field is filled in using the mapping described by the security model to extract it from the resp-identity field. I. The startTime is set to the value indicating the local time. J. The legalSessionLength field is filled in using local policy. 11. The SBSMInit3 SEQUENCE is created, as is a SBSMInit3Encr SEQUENCE, and its values are filled in as follows: A. The init-identifier and resp-identifier fields are filled in using the local-identifier and remote-identifier fields respectively. B. The window-size field is filled in with the same value as was stored in the session cache's window-size field. C. The init-engineID field is filled in with a suitable default engineID which can be used in the contextEngineID field for transmissions requiring them from the remote side, or a zero length string if no value is suitable. D. 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. E. The init-proof1 field is filled in using a authentication signature created using the key associated with 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. Hardaker Expires April 2, 2004 [Page 23] Internet-Draft A Security based session model for SNMP October 2003 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. F. The init-proof2 field is filled in using a HMAC authentication signature created using the outgoingAuthenticationKey to sign the contents of the init-identity field using the algorithmType authentication algorithm. The resp-identity field value within the HMAC operation includes the BER tag and length fields from the on-the-wire packet format. G. The SBSMInit3Encr SEQUENCE is encrypted using the encryptionType encryption algorithm and outgoingEncryptionKey and then wrapped in an OCTET STRING and placed into the SBSMInit3's resp-information field. For the vector generation, described in Section Section 6.4.1, a sequence-number of 0 MUST be used. 12. The initiator of the session may begin transmitting messages under protection of the newly created session at this point. 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. 13. 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. 6.5.4 Reception of the SBSMInit3 message 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 cache is examined to determine if a session exists where the local-identifier field matches the resp-identifier field of the SBSMInit3 message. If not, the message is dropped and processing is ceased. If one is found but the session-status field is already set to up(2) the message is dropped and processing is ceased. Hardaker Expires April 2, 2004 [Page 24] Internet-Draft A Security based session model for SNMP October 2003 2. The init-information field is decrypted using the encryptionType and incomingEncryptionKey fields from the session cache 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. 3. The init-identity field is examined, according to the security model and associated parameters (see section XXX) and if it does not match a acceptable identity for the other side of the session, processing is stopped and an error indication (authenticationFailed?) is returned. XXX: inc counter? 4. the 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 XXX. If the signature in the init-proof1 field does not match the output of the signature alogrithm, then processing is stopped and an error indication (authenticationFailed?) is returned. XXX: inc counter? 5. the init-proof2 field value is checked to ensure it matches the expected HMAC signature as described in Section Section 6.5.2 using the authentication mode described by the authenticationType session cache field along with the incomingAuthenticationKey. If the signature in the init-proof1 field does not match the output of the authentication alogrithm, then processing is stopped and an error indication (authenticationFailed?) is returned. XXX: inc counter? 6. Now that the SBSMInit3 message has been deemed authentic, the responder can fully establish the remaining portions of its side of the session parameters. A. The window-size is set to the minimum of: + the locally supported maximum + the window-size value from the SBSMInit3Encr portion of the incoming message. B. The session-status field of the session cache is set to up(2). C. The outgoingSequenceNumber is set to 1, as is the incomingMinSequenceNumber. Hardaker Expires April 2, 2004 [Page 25] Internet-Draft A Security based session model for SNMP October 2003 D. The securityName field is filled in using the mapping described by the security model to extract it from the init-identity field. E. The startTime is set to the value indicating the local time. F. The legalSessionLength field is filled in using local policy. G. The remoteEngineID cache field is filled in using the value of the init-engineID field value. 7. The responder of the session may begin transmitting messages under protection of the newly created session at this point. 8. Success is returned to the calling module but processing is stopped and the packet is dropped. The application MUST NOT process anything related to this incoming packet. 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 cachedSecurityData. The cachedSecurityData 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 Hardaker Expires April 2, 2004 [Page 26] Internet-Draft A Security based session model for SNMP October 2003 indication (unknownSBSMSession) is returned to the calling module. 4. If the current time minus the startTime is greater than the number of seconds from the legalSessionLength field (or any other value from a policy that restricts session time lengths), then the session MUST be immediately closed and it's session state deleted 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 cachedSecurityData 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. 5. If the 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. 7. The to-identifier field is filled in using the remote-identifier value from the session cache. 8. Increment the session state's outgoingSequenceNumber field by one. If it's value wraps, the session MUST be immediately closed and it's session state deleted and an unknownSBSMSession error returned to the calling module. Otherwise, sequence-number field is filled in using the new value of the outgoingSequenceNumber field of the session state. 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 encryption-parameters field of the sbsm-running field and the plaintext scopedPDU serves as the payload of the message being prepared. Hardaker Expires April 2, 2004 [Page 27] Internet-Draft A Security based session model for SNMP October 2003 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 session's encryption protocol (see Section Section 6.4 for more details) . To do so a call is made to the encryption module that implements the session's encryption protocol using the outgoingEncryptionKey as the secret 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 encryption-parameters field of the sbsm-running and the encryptedPDU serves as the payload of the message being prepared. 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 session's authentication protocol using the outgoingAuthenticationKey as the secret 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. If the incoming message was a response class PDU, and thus a from-sequence-number value is available, and the from-sequence-number is greater than or equal to the value of the incomingMinSequenceNumber field, then: A. The value N is calculated to be equal to from-sequence-number mod window-size. B. The from-sequence-number is stored in messageCache[N].sequence-number. C. The ScopedPDU value from the outgoing message (not encrypted)is stored in messageCache[N].message Hardaker Expires April 2, 2004 [Page 28] Internet-Draft A Security based session model for SNMP October 2003 12. 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 contextEngineID or contextName 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 to-identifier is used to look up a session cache with a local-identifier equal to the to-identifier. If no such session cache is found, processing is stopped and a unknownSBSMSession is returned to the calling module. 3. If the current time minus the startTime is greater than the number of seconds from the legalSessionLength field (or any other value from a policy that restricts session time lengths), then the session MUST be immediately closed and it's session state deleted and a unknownSBSMSession error returned to the calling module. 4. If the 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, Authentication is a requirement of this Hardaker Expires April 2, 2004 [Page 29] Internet-Draft A Security based session model for SNMP October 2003 model. 5. If the sequence-number contained in the message is less than the session cache's incomingMinSequenceNumber, then an error indication (authenticationFailure) is returned to the calling module and processing is stopped. 6. If the message is not a response class message, and the sequence-number contained in the message is less than the value of the incomingMinSequenceNumber plus the value of the window-size, and the messageCacheList[sequence-number mod window-size].sequence-number value is equal to the incoming sequence-number, then: the scopedPDU stored in the messageCacheList[sequence-number mod window-size].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 class message contained within the response message MUST be used to generate a duplicate response. Processing should then continue through the processing outgoing steps outlined in Section Section 6.6.1 but using the .message value as the returned message. 7. If the message is a response class message, and the sequence-number contained in the message is less than the value of the incomingMinSequenceNumber plus the value of the window-size, and the messageCacheList[sequence-number mod window-size].sequence-number field is equal to the sequence-number field from the message, then the message is dropped as it has already been previously received. 8. The message's authentication is checked according to the session's authentication protocol and incomingAuthenticationKey. To do so a call is made to the authentication module that implements the session's authentication protocol using the incomingAuthenticationKey as the secret key. If the authentication module returns failure, then the message cannot be trusted, so the sbsmStatsWrongDigests counter is incremented and an error indication (authenticationFailure) 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. 9. The session cache's incomingMinSequenceNumber is then updated to be the maximum of: Hardaker Expires April 2, 2004 [Page 30] Internet-Draft A Security based session model for SNMP October 2003 * the current incomingMinSequenceNumber field * the sequence-number field of the incoming message minus the window-size from the session cache. If the new incomingMinSequenceNumber number wraps or is set to 2^32-1, then the session MUST be closed after 300 seconds. 10. If the securityLevel indicates that the message was not protected from disclosure, then the scopedPDU is assumed to be in plain text format. 11. If the securityLevel indicates that the message was protected from disclosure, then the OCTET STRING representing the encryptedPDU is decrypted according to the session's encryption protocol and incomingEncryptionKey to obtain an unencrypted serialized scopedPDU value. To do so a call is made to the encryption module that implements the session's encryption protocol using the incomingEncryptionKey as the 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 (decryptionError) 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 the message payload to be returned to the calling module. 12. 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. 13. The securityName for the user is retrieved from the session cache. 14. The security data is cached as cachedSecurityData, so that a possible response to this message can and will use the same authentication and encryption parameters. Information to be saved/cached is as follows: local-identifier sequence-number Hardaker Expires April 2, 2004 [Page 31] Internet-Draft A Security based session model for SNMP October 2003 15. The messageCacheList[sequence-number mod window-size].sequence-number field from the session cache is set to the sequence-number of the incoming message. 16. 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 cache. IE, a 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. 7. MIB Definitions XXX: Write one. Known items to at least be discussed: 1. established sessions. 2. session parameters and default policy (times, etc). 3. error counters 4. notifications 5. configuration of policy. eg: user A using algorthim B/C is different than user X using Y/Z. 8. Identification Mechanisms overall picture: TBD 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. Hardaker Expires April 2, 2004 [Page 32] Internet-Draft A Security based session model for SNMP October 2003 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 (1..32)) OF OCTET STRING END Where: certificateUser: The local account the certificate is expected to be authorized to grant access for. 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 Hardaker Expires April 2, 2004 [Page 33] Internet-Draft A Security based session model for SNMP October 2003 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. 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 ::= Hardaker Expires April 2, 2004 [Page 34] Internet-Draft A Security based session model for SNMP October 2003 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: KEY = ALGORITHM_HASH(passPhrase | 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. 8.2.4 Security Name Mapping Mapping a local account user name into a securityName for storage in the session cache 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 9. 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. Hardaker Expires April 2, 2004 [Page 35] Internet-Draft A Security based session model for SNMP October 2003 XXX: Write more. 10. 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) 11. Acknowledgments Much of the work in this document directly derived from both the SIGMA protocol [SIGMA] and the IKEv2 specification [IKEv2]. Additionally, large quantities of the text were plagiarized from the User Based Security module document [RFC3414]. Large portions of this specification were developed during discussions or as the result of comments made by David Perkins. His motivation (prodding) and continuous commentary as the draft has developed have been very useful. Discussions with or feedback from the following people helped influence the contents of this document: David Harrington Chris Elliot Thanks also to Michael Baer, who read an early copy of this document. Appendix A. Diffie-Helman Group information The Diffie-Helman properties to be used for Diffie-Helman calculations 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 Hardaker Expires April 2, 2004 [Page 36] Internet-Draft A Security based session model for SNMP October 2003 The generator is 2. 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. Author's Address Wes Hardaker Sparta P.O. Box 382 Davis 95617 US EMail: hardaker@tislabs.com Hardaker Expires April 2, 2004 [Page 37] Internet-Draft A Security based session model for SNMP October 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Hardaker Expires April 2, 2004 [Page 38] Internet-Draft A Security based session model for SNMP October 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Hardaker Expires April 2, 2004 [Page 39]