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]
