view Side-By-Side changes
Network Working Group U. Blumenthal
Internet Draft U. Blumenthal
draft-blumenthal-aes-usm-02.txt Lucent Technologies
Document: draft-blumenthal-aes-usm-01.doc July 2001
Category: Experimental
Expires: August 2002 F. Maino
Andiamo Systems, Inc.
K. McCloghrie
Cisco Systems, Inc.
February 2002
The AES (Rijndael) Encryption Protocol with SNMPv3 USM Cipher Algorithm in the SNMP's User-based Security Model
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026
[1]. [RFC2026].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts. Internet-
Drafts.
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 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.
For potential updates to the above required-text see:
http://www.ietf.org/ietf/1id-guidelines.txt
1.
Abstract
This document describes the use a set of Rijndael authentication and symmetric
encryption
protocol with protocols that supplement the protocols described in the
User-based Security Model (USM) [RFC2574], which is a Security
Subsystem for SNMP version 3. This protocol provides data confidentiality.
This document augments and should be used with RFC 2574
[1].
2. Conventions used 3 of the Simple Network Management Protocol
for use in this document the SNMP Architecture [RFC2571]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
"MAY", and "OPTIONAL" authentication
protocol described in this document are to be
interpreted as described in RFC-2119 [2].
K - secret key for is based on SHA256 [FIPS-180-2]
and the AES symmetric encryption engine.
IV - 32-bit Initialization Vector for protocols are based on the AES engine
Blumenthal Experimental cipher
algorithm [FIPS-AES], used in Cipher FeedBack Mode (CFB), with key
size of 128, 192, and 256 bits.
Table of Contents
1. Introduction....................................................3
1.1. Goals and Constraints......................................3
1.2. Key Localization...........................................4
1.2.1. Kul generation (for HMAC-SHA256-96)...................4
1.3. Key Update.................................................5
Blumenthal,
Maino, McCloghrie. Expires August 2002 [Page 1]
Internet Draft The AES Cipher Algorithm in USM SNMPv3 July 2001
i - 32-bit counter (initialized to one).
E(K,P) - encrypting P in ECB mode under key K.
P[i] - i-th block of the plaintext(all but last: 128-bit).
C[i] - i-th block February 2002
SNMP's User-based Security Model
2. Definitions.....................................................5
3. HMAC-SHA256-96 Authentication Protocol..........................8
3.1. Mechanisms.................................................8
3.1.1. Digest Authentication Mechanism.......................8
3.2. Elements of the ciphertext(size - same as above).
C[i][j] û j-th 4-byte word of O[i] (1 <= j <= 4).
S[i] - the encryptor input value for i-th step.
S[i][j] û j-th 4-byte word of S[i] (1 <= j <= 4).
O[i] û encryptor output value O[i]=E(K,S[i]).
A^b - A raised in power b.
XOR - bitwise operation eXclusive OR.
A * B - A multiplied by B.
When an integer value (i, snmpEngineTime, snmpEngineBoots)
is placed in the octet string such as S[i], it is
converted to Network Byte Order if necessary (Big-Endian),
and then copied byte HMAC-SHA256-96 Authentication Protocol.....9
3.2.1. Users.................................................9
3.2.2. msgAuthoritativeEngineID..............................9
3.2.3. SNMP Messages Using this Authentication Protocol......9
3.2.4. Services provided by byte from left to right.
3. Overview
At the time HMAC-SHA256-96 Authentication
Module......................................................10
3.3. Elements of writing Procedure.....................................11
3.3.1. Processing an Outgoing Message.......................11
3.3.2. Processing an Incoming Message.......................12
CFB128-AES-128/192/256 Symmetric Encryption Protocols.............13
4.1. Mechanisms................................................13
4.1.1. The AES based Symmetric Encryption Protocols.........13
4.1.2. Localized Key, AES Encryption Key and Initialization
Vector......................................................14
4.1.3. Data Encryption......................................15
4.1.4. Data Decryption......................................16
4.2. Elements of this document, Rijndael [4] has
been declared the proposed AES (Advanced Encryption
Standard) [5] Privacy Protocols.....................16
4.2.1. Users................................................16
4.2.2. msgAuthoritativeEngineID.............................17
4.2.3. SNMP Messages Using this Privacy Protocol............17
4.2.4. Services provided by NIST. This, together with the fact that
practical attacks on DES became feasible, makes it
necessary to define new privacy protocols for USM.
Rijndael is the natural candidate AES Privacy Modules.........17
4.3. Elements of Procedure.....................................18
4.3.1. Processing an Outgoing Message.......................18
4.3.2. Processing an Incoming Message.......................19
5. Security Considerations........................................19
6. Intellectual Property Rights Statement.........................20
7. Acknowledgements...............................................20
8. References.....................................................20
9. Author's Addresses.............................................21
Appendix A........................................................21
A.1 Password to base them on.
The protocol is very similar Key Algorithm..................................22
A.1.1 Password to CBC-DES Symmetric
Encryption Protocol described in RFC 2574 [3]. The
underlying cipher and protocol differ from RFC 2574 as
follows:
.Rijndael uses longer keys (AES permits 128-, 192- and
256-bit long keys, with USM we recommend 128-bit
key for most applications);
.Rijndael block size is 128 bits (instead of 64 bits
in DES), which may affect the resulting message
size, depending on what encryption mode is used;
.Recommended encryption mode is GCFB, Localized Key Sample Code for the purpose
of maximizing performance and preserving the
message size;
.Explicit Initialization Vector (IV) is truncated SHA256......22
A.2 Password to
32 bits, and the rest Key Sample Results.............................23
A.3 Sample keyChange results using SHA256......................24
A.4 Sample Results of the IV is filled according
to the algorithm described below;
.Encryption and decryption processes are the same,
thus the crypto engine must implement only
encryption and does not have to implement
decryption procedure.
3.1. Generalized Counter Feedback Mode
Blumenthal Experimental Extension of Localized Keys shorter than
384 bits.......................................................25
Blumenthal,
Maino, McCloghrie Expires August 2002 [Page 2]
Internet Draft The AES Cipher Algorithm in USM the February 2002
SNMP's User-based Security Model
1. Introduction
Within the Architecture for describing Internet Management
Frameworks [RFC2571], the User-based Security Model (USM) [RFC2574]
for SNMPv3 July 2001
GCFB is defined as a stream cipher mode. It combines Security Subsystem within an SNMP engine.
[RFC2574] describes the advantages use of CTR-mode (Counter) HMAC-MD5-96 and of CFB (Cipher Feedback) mode.
It is fast, does not increase HMAC-SHA-96 as the size of
(initial) authentication protocols and the ciphertext,
has property use of error propagation (due to CBC-DES as the feedback).
(initial) privacy protocol. The cipher engine is User-based Security Model however
allows for other such protocols to be used only in encryption mode (AES
decryption feature is not needed). It produces a
pseudorandom stream that is XOR-ed with the plaintext. To
create pseudorandom stream, a 128-bit input string is
encrypted. Like the CTR-mode, part of that string
comprises instead of a counter that increments by one or concurrent
with each
encryption iteration. Like CFB-mode, part these protocols.
This memo describes the use of HMAC-SHA256-96 as an alternative
authentication protocol and the resulting
ciphertext is fed back to use of CFB128-AES-128/192/256 as
three alternative privacy protocols for the 128-bit string, affecting User-based Security
Model. This memo describes also the next 128-bit of pseudorandom stream.
4. AES (Rijndael) Symmetric Encryption Protocol
Rijndael is a modern 128-bit block cipher developed by
Joan Deamen and Vincent Rijmen [4], declared by NIST a
proposed AES (successor to DES). Its description, modes of
operation, validation test suite Key Localization Algorithm for
use with/by the new authentication protocol.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and reference
implementation code "OPTIONAL" in
this document are available on the AES NIST Web site
[5].
Rijndael takes 128-, 192- to be interpreted as described in [RFC2119].
1.1. Goals and 256-bit long keys. For USM
it is believed that 128-bit keys Constraints
The main goals of this memo are sufficient. However
neither as follows.
1) Provide a set of new privacy protocols for USM [3] nor based on the Rijndael
Advanced Encryption Standard.
2) Provide a new authentication protocol as specified
here, mandate any particular key length - thus all for USM based on SHA256, the
three
AES companion hash algorithm.
3) Provide a key length options are acceptable.
Rijndael encryption algorithm is used to encrypt the
designated portion of localization mechanism that generates an SNMP message, which along with
Rijndael Initialization Vector is included as a part adequate
amount of key material for the message sent to new authentication and privacy
protocols.
A further important goal of the recipient.
4.1. Rijndael Key
Rijndael key localization mechanism described
in this memo, is an octet string of 16, 24, or 32 bytes.
The recommended length is 16 bytes, which is deemed enough
for most applications.
The to guarantee that different key material is (implicitly) stored in
generated for the USM User table authentication protocol and
can be manipulated using SNMPv3 for the privacy
protocol via access to USM
User Table [3].
The whole length of a user, even when the octet string representing the
secret privacy key same password is used as a Rijndael key (see
usmUserPrivKeyChange both for
authentication and usmUserOwnPrivKeyChange for privacy. In fact, even if discouraged in [3]).
KeyChange Textual Convention governs
[RFC2574], it's common practice today that an SNMP user uses the process,
same password for authentication and privacy protection ending up
with the
keys of 128-, 192- same localized key used both for authentication and 256-bit length. It is strongly
recommended that only SHA-1
encryption.
The major constraint is used, and not MD5 (SHA-256
and SHA-512 are good choices to replace SHA-1).
Blumenthal Experimental [Page 3]
Internet Draft AES in USM SNMPv3 July 2001
If maintain a password or other variable-length user input needs to
be converted to a Rijndael key, follow complete interchangeability of
the algorithm new protocols defined on this memo with existing authentication
and privacy protocols already defined in USM.
For a given user U, the AES-based privacy protocols SHOULD be used
together with the authentication protocol based on SHA-256, but they
MAY alternatively be used with the authentication protocols
described in [RFC2574]. Similarly, the DES based privacy protocol
Blumenthal,
Maino, McCloghrie Expires August 2002 [Page 3]
Internet Draft The AES Cipher Algorithm in the February 2002
SNMP's User-based Security Model
defined in [RFC2574] MAY be used with the new authentication
protocol described in RFC 2574.
Throughout this document it memo.
1.2. Key Localization
As defined in [RFC2574] a localized key is assumed that a secret key shared
between a user U and one authoritative SNMP engine E. Even though a
user may have only one pair of authentication and privacy passwords
and therefore one pair of keys for the whole network, the actual
secrets shared between the Rijndael user and each authoritative SNMP engine
will be different. This is achieved by key localization.
If the authentication protocol defined for a user U at the
authoritative SNMP engine E, is localized, as one of the authentication protocols
defined on [RFC2574], the key localization is performed according to
the two steps process described in RFC 2574.
4.2. Rijndael Initialization Vector
It section 2.6 of [RFC2574].
If the authentication protocol defined for a user U at the
authoritative SNMP engine E, is up to the entity new authentication protocol
described in question how this memo (HMAC-SHA256-96), the user password is
converted into a localized key Kul according to obtain/compute the 32-bit IV. On Unix operating systems one can use
reasonably secure random number sources such general method
for deriving keys and IVs from password and salt described in
Appendix B.2 of PKCS #12 [PKCS-12]. That method is used with the
SNMP user password as
/dev/random.
IV should satisfy input password, the following requirements:
.Unique (non-repeating from one packet to another);
.Varying "rapidly" (considerable amount snmpEngineID as salt,
SHA256 as hash function with output length u=256 and intermediate
blocks size v=512. The generated Kul will be the concatenation of
three 256 bits change
from one IV to another).
It is preferable but not required, strings that IV is
unpredictable.
4.3. Message will provide encryption key material,
pre-IV data and integrity key material for the encryption and
authentication protocols of USM.
1.2.1. Kul generation (for HMAC-SHA256-96)
The procedure described here generates a 768 bit long Kul derived
from the SNMP user password, the snmpEngineID and the hash algorithm
SHA256, according to the key and IV derivation general method
described in appendix B.2 of [PKCS-12].
First the SNMP user password, consisting of ASCII characters, is
used as the string p.
The value of snmpEngineID, an OCTET STRING, is used as the salt s.
Three "diversifiers" strings, each 512 bits long, are created:
- D1_512 concatenating 64 copies of the byte 0x01;
- D2_512 concatenating 64 copies of the byte 0x02;
- D3_512 concatenating 64 copies of the byte 0x03.
The appropriate number of copies of the salt s are concatenated
together to create a 512 bits string S_512 (the final copy of the
salt s may be truncated to create S_512).
The appropriate number of copies of the password p are concatenated
together to create a 512 bits string P_512 (the final copy of the
password p may be truncated to create P_512).
Blumenthal,
Maino, McCloghrie Expires August 2002 [Page 4]
Internet Draft The AES Cipher Algorithm in the February 2002
SNMP's User-based Security Model
The strings S_512 and P_512 are concatenated together to generate
the 1024 bits string I_1024 = S_512 || P_512.
The encryption key material, pre-IV material and authentication
material are generated hashing with the SHA256 function the
concatenation of the diversifiers and of the string I_1024:
- enc_256 = SHA256( D1_512 || I_1024);
- preIV_256 = SHA256( D2_512 || I_1024);
- int_256 = SHA256( D3_512 || I_1024);
The 768 bit long Kul is derived as the concatenation of three
sections, each containing one of the three strings above: Kul =
enc_256 || preIV_256 || int_256.
The first two 256-bit sections of Kul SHOULD be used by privacy
protocols to generate, respectively, encryption keys and IV
material, while the last section of Kul SHOULD be used by
authentication protocols to derive authentication and integrity
keys. However, how the Kul is used by each authentication or privacy
protocol is left to the protocol specification.
The privacy protocols described in this memo use the first
128/192/256 bits of the first section of Kul as encryption key, and
the last section of Kul as authentication key. The preIV section of
Kul, is not used by the privacy protocols described in this memo.
However the 256 bits preIV section of Kul, will support future
privacy protocols that may require preIVs of size up to 256 bits.
An implementation of the localization algorithm is in Appendix A.1.1
of this memo.
1.3. Key Update
The TEXTUAL CONVENTION KeyChange, defined in section 5 of [RFC2574],
describe a mechanism based on a protocol P, a secret key K, and and
hash algorithm H that can be used to update a localized key of an
SNMP engine.
The TC still applies for user U when the protocol P is one of the
protocols described on this memo. In this case the hash algorithm H
will be SHA256, and the size of the to be updated secret key K, is
768 bits as specified in 1.2.1
Appendix A.3 provides a sample KeyChange result using SHA256.
2. Definitions
SNMP-USM-AES-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-IDENTITY FROM SNMPv2-SMI
xxx FROM XXX-MIB;
Blumenthal,
Maino, McCloghrie Expires August 2002 [Page 5]
Internet Draft The AES Cipher Algorithm in the February 2002
SNMP's User-based Security Model
snmpUsmAesMIB MODULE-IDENTITY
LAST-UPDATED "200110120000Z"
ORGANIZATION "???"
CONTACT-INFO "Uri Blumenthal
Lucent Technologies / Bell Labs
67 Whippany Rd.
14D-318
Whippany, NJ 07981, USA
973-386-2163
uri@bell-labs.com
Fabio Maino
Andiamo Systems, Inc.
375 East Tasman Drive
San Jose, CA 95134, USA
408-853-7530
fmaino@andiamo.com
Keith McCloghrie
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706, USA
408-526-5260
kzm@cisco.com"
DESCRIPTION "Definitions of Object Identities needed for
the use of AES by SNMP's User-based Security
Model."
REVISION "200110120000Z"
DESCRIPTION "Initial version, published as RFCnnnn"
::= { xxx nn } -- to be assigned by TBD
snmpUsmAesProtocols OBJECT IDENTIFIER ::= { snmpUsmAesMIB 1 }
-- Identification of Authentication and Privacy Protocols
usmHmacSha256AuthProtocol OBJECT-IDENTITY
STATUS current
DESCRIPTION "The HMAC-SHA256-96 Digest Authentication
Protocol."
REFERENCE "- Specification for the SECURE HASH STANDARD
(DRAFT). Federal Information Processing
Standard (FIPS) Publication 180-2.
Supersedes FIPS Publication 180-1,
(May 2001).
- Bellare, M., Canetti, R., Krawczyk, H.,
HMAC: Keyed-Hashing for Message Authentication,
RFC2104, February 1997.
"
Blumenthal,
Maino, McCloghrie Expires August 2002 [Page 6]
Internet Draft The AES Cipher Algorithm in the February 2002
SNMP's User-based Security Model
::= { snmpUsmAesProtocols 1 }
usmAesCfb128Protocol OBJECT-IDENTITY
STATUS current
DESCRIPTION "The CFB128-AES-128 Privacy Protocol."
REFERENCE "- Specification for the ADVANCED ENCRYPTION
STANDARD (DRAFT). Federal Information Processing
Standard (FIPS) Publication 197.
(November 2001).
- Dworkin, M., NIST Recommendation for Block
Cipher Modes of Operation, Methods and
Techniques (DRAFT).
NIST Special Pubblication 800-38A
(December 2001).
"
::= { snmpUsmAesProtocols 2 }
usmAesCfb192Protocol OBJECT-IDENTITY
STATUS current
DESCRIPTION "The CFB128-AES-192 Privacy Protocol."
REFERENCE "- Specification for the ADVANCED ENCRYPTION
STANDARD (DRAFT). Federal Information Processing
Standard (FIPS) Publication 197.
(November 2001).
- Dworkin, M., NIST Recommendation for Block
Cipher Modes of Operation, Methods and
Techniques (DRAFT).
NIST Special Publication 800-38A
(December 2001).
"
::= { snmpUsmAesProtocols 3 }
usmAesCfb256Protocol OBJECT-IDENTITY
STATUS current
DESCRIPTION "The CFB128-AES-256 Privacy Protocol."
REFERENCE "- Specification for the ADVANCED ENCRYPTION
STANDARD (DRAFT). Federal Information Processing
Standard (FIPS) Publication 197
(November 2001).
- Dworkin, M., NIST Recommendation for Block
Cipher Modes of Operation, Methods and
Techniques (DRAFT).
NIST Special Publication 800-38A
(December 2001).
"
::= { snmpUsmAesProtocols 4 }
END
Blumenthal,
Maino, McCloghrie Expires August 2002 [Page 7]
Internet Draft The AES Cipher Algorithm in the February 2002
SNMP's User-based Security Model
3. HMAC-SHA256-96 Authentication Protocol
This section describes the HMAC-SHA256-96 authentication protocol.
This protocol uses the SHA256 hash-function which is described in
the draft of the Secure Hash Standard FIPS[FIPS-180-2], used in HMAC
mode as described in [RFC2104], truncating the output to 96 bits.
This protocol is identified by usmHmacSha256AuthProtocol.
This protocol is an alternative to the authentication protocols
described in [RFC2574].
3.1. Mechanisms
- In support of data integrity, a message digest algorithm is
required. A digest is calculated over an appropriate portion of an
SNMP message and included as part of the message sent to the
recipient.
- In support of data origin authentication and data integrity, a
secret value is prepended to the SNMP message prior to computing the
digest; the calculated digest is then partially inserted into the
message prior to transmission. The prepended secret is not
transmitted. The secret value is shared by all SNMP engines
authorized to originate messages on behalf of the appropriate user.
3.1.1. Digest Authentication Mechanism
The Digest Authentication Mechanism defined in this memo provides
for:
- verification of the integrity of a received message, i.e., that
the message received is the message sent.
The integrity of the message is protected by computing a digest over
an appropriate portion of the message. The digest is computed by
the originator of the message, transmitted with the message, and
verified by the recipient of the message.
- verification of the user on whose behalf the message was
generated.
A secret value known only to SNMP engines authorized to generate
messages on behalf of a user is used in HMAC mode (see [RFC2104]).
It also recommends the hash-function output used as Message
Authentication Code, to be truncated.
This mechanism uses the SHA256 [FIPS-180-2] message digest
algorithm. A 256-bit SHA256 digest is calculated in a special
(HMAC) way over the designated portion of an SNMP message and the
first 96 bits of this digest is included as part of the message sent
to the recipient. The size of the digest carried in a message is 12
Blumenthal,
Maino, McCloghrie Expires August 2002 [Page 8]
Internet Draft The AES Cipher Algorithm in the February 2002
SNMP's User-based Security Model
octets. The size of the private authentication key (the secret) is
32 octets. For the details see section 3.3.
3.1.1.1. Localized Key and Private Authentication Key
The last 32 octets (256 bits) of the Localized Key Kul, generated
from the SNMP user password and the snmpEngineID as described in
section 1.2.1 of this memo, are used as Private Authentication Key
for the HMAC-SHA256-96 authentication protocol.
3.2. Elements of the HMAC-SHA256-96 Authentication Protocol
This section contains definitions required to realize the
authentication module defined in this section of this memo.
3.2.1. Users
Authentication using this authentication protocol makes use of a
defined set of userNames. For any user on whose behalf a message
must be authenticated at a particular SNMP engine, that SNMP engine
must have knowledge of that user. An SNMP engine that wishes to
communicate with another SNMP engine must also have knowledge of a
user known to that engine, including knowledge of the applicable
attributes of that user.
A user and its attributes are defined as follows:
<userName>
A string representing the name of the user.
<authKey>
A user's secret key to be used when calculating a digest.
It MUST be 32 octets long for SHA256.
3.2.2. msgAuthoritativeEngineID
The msgAuthoritativeEngineID value contained in an authenticated
message specifies the authoritative SNMP engine for that particular
message (see the definition of SnmpEngineID in the SNMP Architecture
document [RFC2571]).
The user's (private) authentication key is normally different at
each authoritative SNMP engine and so the snmpEngineID is used to
select the proper key for the authentication process.
3.2.3. SNMP Messages Using this Authentication Protocol
Messages using this authentication protocol carry a
msgAuthenticationParameters field as part of the
msgSecurityParameters. For this protocol, the
msgAuthenticationParameters field is the serialized OCTET STRING
representing the first 12 octets of HMAC-SHA256-96 output done over
the wholeMsg.
Blumenthal,
Maino, McCloghrie Expires August 2002 [Page 9]
Internet Draft The AES Cipher Algorithm in the February 2002
SNMP's User-based Security Model
The digest is calculated over the wholeMsg so if a message is
authenticated, that also means that all the fields in the message
are intact and have not been tampered with.
3.2.4. Services provided by the HMAC-SHA256-96 Authentication Module
This section describes the inputs and outputs that the HMAC-SHA256-
96 Authentication module expects and produces when the User-based
Security module calls the HMAC-SHA256-96 Authentication module for
services.
3.2.4.1. Services for Generating an Outgoing SNMP Message
HMAC-SHA256-96 authentication protocol assumes that the selection of
the authKey is done by the caller and that the caller passes the
secret key to be used.
Upon completion the authentication module returns statusInformation
and, if the message digest was correctly calculated, the wholeMsg
with the digest inserted at the proper place. The abstract service
primitive is:
statusInformation = -- success or failure
authenticateOutgoingMsg(
IN authKey -- secret key for authentication
IN wholeMsg -- unauthenticated complete
message
OUT authenticatedWholeMsg -- complete authenticated
message
)
The abstract data elements are:
statusInformation
An indication of whether the authentication process was
successful. If not it is an indication of the problem.
authKey
The secret key to be used by the authentication algorithm. The
length of this key MUST be 32 octets.
wholeMsg
The message to be authenticated.
authenticatedWholeMsg
The authenticated message (including inserted digest) on output.
Note, that authParameters field is filled by the authentication
module and this field should be already present in the wholeMsg
before the Message Authentication Code (MAC) is generated.
3.2.4.2. Services for Processing an Incoming SNMP Message
Blumenthal,
Maino, McCloghrie Expires August 2002 [Page 10]
Internet Draft The AES Cipher Algorithm in the February 2002
SNMP's User-based Security Model
HMAC-SHA256-96 authentication protocol assumes that the selection of
the authKey is done by the caller and that the caller passes the
secret key to be used.
Upon completion the authentication module returns statusInformation
and, if the message digest was correctly calculated, the wholeMsg as
it was processed. The abstract service primitive is:
statusInformation = -- success or failure
authenticateIncomingMsg(
IN authKey -- secret key for authentication
IN authParameters -- as received on the wire
IN wholeMsg -- as received on the wire
OUT authenticatedWholeMsg -- complete authenticated
message
)
The abstract data elements are:
statusInformation
An indication of whether the authentication process was
successful. If not it is an indication of the problem.
authKey
The secret key to be used by the authentication algorithm. The
length of this key MUST be 32 octets.
authParameters
The authParameters from the incoming message.
wholeMsg
The message to be authenticated on input and the authenticated
message on output.
authenticatedWholeMsg
The whole message after the authentication check is complete.
3.3. Elements of Procedure
This section describes the procedures for the HMAC-SHA256-96
authentication protocol.
3.3.1. Processing an Outgoing Message
This section describes the procedure followed by an SNMP engine
whenever it must authenticate an outgoing message using the
usmHmacSha256AuthProtocol.
1) The msgAuthenticationParameters field is set to the
serialization, according to the rules in [RFC1906], of an OCTET
STRING containing 12 zero octets.
2) From the secret authKey, two keys K1 and K2 are derived:
a) extend the authKey to 64 octets by appending 32 zero octets;
save it as extendedAuthKey
Blumenthal,
Maino, McCloghrie Expires August 2002 [Page 11]
Internet Draft The AES Cipher Algorithm in the February 2002
SNMP's User-based Security Model
b) obtain IPAD by replicating the octet 0x36 64 times;
c) obtain K1 by XORing extendedAuthKey with IPAD;
d) obtain OPAD by replicating the octet 0x5C 64 times;
e) obtain K2 by XORing extendedAuthKey with OPAD.
3) Prepend K1 to the wholeMsg and calculate the SHA256 digest over
it according to [FIPS-180-2].
4) Prepend K2 to the result of the step 4 and calculate SHA256
digest over it according to [FIPS-180-2]. Take the first 12 octets
of the final digest - this is Message Authentication Code (MAC).
5) Replace the msgAuthenticationParameters field with MAC obtained
in the step 4.
6) The authenticatedWholeMsg is then returned to the caller together
with statusInformation indicating success.
3.3.2. Processing an Incoming Message
This section describes the procedure followed by an SNMP engine
whenever it must authenticate an incoming message using the
usmHmacSha256AuthProtocol.
1) If the digest received in the msgAuthenticationParameters field
is not 12 octets long, then a failure and an errorIndication
(authenticationError) is returned to the calling module.
2) The MAC received in the msgAuthenticationParameters field is
saved.
3) The digest in the msgAuthenticationParameters field is replaced
by the 12 zero octets.
4) From the secret authKey, two keys K1 and K2 are derived:
a) extend the authKey to 64 octets by appending 32 zero octets;
save it as extendedAuthKey
b) obtain IPAD by replicating the octet 0x36 64 times;
c) obtain K1 by XORing extendedAuthKey with IPAD;
d) obtain OPAD by replicating the octet 0x5C 64 times;
e) obtain K2 by XORing extendedAuthKey with OPAD.
5) The MAC is calculated over the wholeMsg:
a) prepend K1 to the wholeMsg and calculate the SHA256 digest over
it;
b) prepend K2 to the result of step 5.a and calculate the SHA256
digest over it;
c) first 12 octets of the result of step 5.b is the MAC.
The msgAuthenticationParameters field is replaced with the MAC value
that was saved in step 2.
Blumenthal,
Maino, McCloghrie Expires August 2002 [Page 12]
Internet Draft The AES Cipher Algorithm in the February 2002
SNMP's User-based Security Model
6) The newly calculated MAC is compared with the MAC saved in step
2. If they do not match, then a failure and an errorIndication
(authenticationFailure) are returned to the calling module.
7) The authenticatedWholeMsg and statusInformation indicating
success are then returned to the caller.
4. CFB128-AES-128/192/256 Symmetric Encryption Protocols
This section describes three Symmetric Encryption Protocols based on
the AES Cipher Algorithm [FIPS-AES], used in Cipher Feedback Mode as
described in [AES-MODE], using encryption keys with a size of 128,
192, and 256 bits.
These protocols are identified by:
- usmAesCfb128PrivProtocol;
- usmAesCfb192PrivProtocol;
- usmAesCfb256PrivProtocol;
These protocols are alternatives to the privacy protocol defined in
[RFC2574].
4.1. Mechanisms
- In support of data confidentiality, an encryption algorithm is
required. An appropriate portion of the message is encrypted prior
to being transmitted. The User-based Security Model specifies that
the scopedPDU is the portion of the message that needs to be
encrypted.
- A secret value in combination with a timeliness value is used to
create the en/decryption key and the initialization vector. The
secret value is shared by all SNMP engines authorized to originate
messages on behalf of the appropriate user.
4.1.1. The AES based Symmetric Encryption Protocols
The Symmetric Encryption Protocols defined in this memo provide
support for data confidentiality. The designated portion of an SNMP
message is encrypted and included as part of the message sent to the
recipient.
The AES (Advanced Encryption Standard) is the symmetric cipher
algorithm that the NIST (National Institute of Standards and
Technology) has selected in a four-year competitive process.
The AES homepage, http://www.nist.gov/aes, contains a wealth of
information on AES including the Federal Information Processing
Standard [FIPS-AES] that will finally specify the Advanced
Encryption Standard.
Blumenthal,
Maino, McCloghrie Expires August 2002 [Page 13]
Internet Draft The AES Cipher Algorithm in the February 2002
SNMP's User-based Security Model
The following subsections contain description of the relevant
characteristics of the AES ciphers used in the symmetric encryption
protocols described in this memo.
4.1.1.1. Mode of operation
The NIST Special Pubblication 800-38A [AES-MODE]recommends five
confidentiality modes of operation for use with AES: Electronic
Codebook (ECB), Cipher Block Chaining (CBC), Cipher Feedback (CFB),
Output Feedback (OFB), and Counter (CTR).
The symmetric encryption protocols described in this memo use AES in
CFB mode with the parameter s set to 128 according to the definition
of CFB mode given in [AES-MODE]. This mode requires a Initialization
Vector (IV) that is the same size as the block size of the cipher
algorithm.
4.1.1.2. Key Size
In the encryption protocols described by this memo AES is used with
key sizes of 128, 192, and 256 bits.
4.1.1.3. Block Size and Padding
The block size of the AES cipher algorithms used in the encryption
protocols described by this memo is 128 bits.
4.1.1.4. Rounds
This parameter determines how many times a block is encrypted. The
encryption protocols described on this memo use:
- 10 rounds for AES-128;
- 12 rounds for AES-192;
- 14 rounds for AES-256
4.1.2. Localized Key, AES Encryption Key and Initialization Vector
The size of the Localized Key (Kul) of an SNMP user, as described in
[RFC2574], depends on the authentication protocol defined for that
user U at the authoritative SNMP engine E.
4.1.2.1. Short Localized Keys
The encryption protocols defined on this memo SHOULD be used with an
authentication protocol that generates a localized key with enough
key material to derive a 128/192/256 bits encryption key, such as
the usmHmacSha256AuthProtocol.
However, if the size of the localized key is not large enough to
generate an encryption key the following algorithm is applied to
extend the localized key:
Blumenthal,
Maino, McCloghrie Expires August 2002 [Page 14]
Internet Draft The AES Cipher Algorithm in the February 2002
SNMP's User-based Security Model
1) Let Hnnn() the hash function of the authentication protocol for
the user U on the SNMP authoritative engine E. nnn being the size
of the output of the hash function (e.g. nnn=128 bit for MD5, or
nnn=160 bit for SHA1).
2) Set c = ceil ( 384 / nnn )
3) For i = 1, 2, ..., c
a. Set Kul = Kul || Hnnn(Kul); Where Hnnn() is the hash
function of the authentication protocol defined for that user
As an example if the user authentication protocol is HMAC-SHA1-96,
the hash function Hnnn is SHA1 with nnn=160 bit. The algorithm will
generate a localized key 480 bits long:
Kul' = Kul || SHA1(Kul) || SHA1(Kul||SHA1(Kul))
4.1.2.2. AES Encryption Key and IV
The first 128/192/256 bits of the localized key Kul are used as the
AES encryption key, according to the AES cipher algorithm key size
of the encryption protocol used.
The 128 bits IV is obtained as the concatenation of the generating
SNMP engine's 32-bit snmpEngineBoots, the SNMP engine's 32-bit
snmpEngineTime, and a local 64-bit integer. The 64-bit integer is
initialized to an arbitrary value at boot time.
The IV is composed as follows: the 32-bit snmpEngineBoots is
converted to the first 4 octets (Most Significant Byte first), the
32-bit snmpEngineTime is converted to the subsequent 4 octets (Most
Significant Byte first), and the 64-bit integer is then converted to
the last 8 octets (Most Significant Byte first).
The 64-bit integer is then put into the privParameters field encoded
as an OCTET STRING of length 8 octets. The integer is then modified
for the subsequent message. We recommend that it be incremented by
one and wrap when it reaches the maximum value.
How exactly the value of the IV varies, is an implementation issue,
as long as the measures are taken to avoid producing a duplicate IV.
The 64-bit integer must be placed in the privParameters field to
enable the receiving entity to compute the correct IV and to decrypt
the message.
4.1.3. Data Encryption.
The data to be encrypted is treated as sequence of octets.
The data is encrypted in Cipher Feedback mode with the parameter s
set to 128 according to the definition of CFB mode given in [AES-
MODE].
The plaintext is divided into 128-bit blocks. The last block may
have less than 128 bits, and no padding is required.
Blumenthal,
Maino, McCloghrie Expires August 2002 [Page 15]
Internet Draft The AES Cipher Algorithm in the February 2002
SNMP's User-based Security Model
The first input block is the IV, and the forward cipher operation is
applied to the IV to produce the first output block. The first
ciphertext block is produced by exclusive-ORing the first plaintext
block with the first output block. The ciphertext block is also used
as the input block for the subsequent forward cipher operation.
The process is repeated with the successive input blocks until a
ciphertext segment is produced from every plaintext segment.
The last ciphertext block is produced by exclusive-ORing the last
plaintext segment of r bits (r is less or equal to 128) with the
segment of the r most significant bits of the last output block.
4.1.4. Data Decryption
In CFB decryption, the IV is the first input block, the first
ciphertext is used for the second input block, the second ciphertext
is used for the third input block, etc. The forward cipher function
is applied to each input block to produce the output blocks. The
output blocks are exclusive-ORed with the corresponding ciphertext
blocks to recover the plaintext blocks.
The last ciphertext block (whose size r is less or equal to 128) is
exclusive-ORed with the segment of the r most significant bits of
the last output block to recover the last plaintext block of r bits.
4.2. Elements of the AES Privacy Protocols
This section contains definitions required to realize the privacy
modules defined by this memo.
4.2.1. Users
Data en/decryption using this Symmetric Encryption Protocol makes
use of a defined set of userNames. For any user on whose behalf a
message must be en/decrypted at a particular SNMP engine, that SNMP
engine must have knowledge of that user. An SNMP engine that wishes
to communicate with another SNMP engine must also have knowledge of
a user known to that SNMP engine, including knowledge of the
applicable attributes of that user.
A user and its attributes are defined as follows:
<userName>
An octet string representing the name of the user.
<privKey>
A user's secret key to be used as the AES key.
The length of this key MUST be:
- 128 bits (16 octets) for AES-128
- 192 bits (24 octets) for AES-192
- 254 bits (32 octets) for AES-256
Blumenthal,
Maino, McCloghrie Expires August 2002 [Page 16]
Internet Draft The AES Cipher Algorithm in the February 2002
SNMP's User-based Security Model
4.2.2. msgAuthoritativeEngineID
The msgAuthoritativeEngineID value contained in an authenticated
message specifies the authoritative SNMP engine for that particular
message (see the definition of SnmpEngineID in the SNMP Architecture
document [RFC2571]).
The user's (private) privacy key is normally different at each
authoritative SNMP engine and so the snmpEngineID is used to select
the proper key for the en/decryption process.
4.2.3. SNMP Messages Using this Privacy Protocol
Messages using this privacy protocol carry a msgPrivacyParameters
field as part of the msgSecurityParameters. For this protocol, the
msgPrivacyParameters field is the serialized OCTET STRING
representing the "salt" that was used to create the IV.
4.2.4. Services provided by the AES Privacy Modules
This section describes the inputs and outputs that the AES Privacy
modules expects and produces when the User-based Security module
invokes one of the AES Privacy modules for services.
4.2.4.1. Services for Encrypting Outgoing Data
The AES privacy protocols assume that the selection of the privKey
is done by the caller and that the caller passes the secret key to
be used.
Upon completion the privacy module returns statusInformation and, if
the encryption process was successful, the encryptedPDU and the
msgPrivacyParameters encoded as an OCTET STRING. The abstract
service primitive is:
statusInformation = -- success or failure
encryptData(
IN encryptKey -- secret key for encryption
IN dataToEncrypt -- data to encrypt (scopedPDU)
OUT encryptedData -- encrypted data (encryptedPDU)
OUT privParameters -- filled in by service provider
)
The abstract data elements are:
statusInformation
An indication of the success or failure of the encryption
process. In case of failure, it is an indication of the error.
encryptKey
The secret key to be used by the encryption algorithm.
The length of this key MUST be 16/24/32 octets for AES
Blumenthal,
Maino, McCloghrie Expires August 2002 [Page 17]
Internet Draft The AES Cipher Algorithm in the February 2002
SNMP's User-based Security Model
128/192/256.
dataToEncrypt
The data that must be encrypted.
encryptedData
The encrypted data upon successful completion.
privParameters
The privParameters encoded as an OCTET STRING.
4.2.4.2. Services for Decrypting Incoming Data
This DES privacy protocol assumes that the selection of the privKey
is done by the caller and that the caller passes the secret key to
be used.
Upon completion the privacy module returns statusInformation and, if
the decryption process was successful, the scopedPDU in plain text.
The abstract service primitive is:
statusInformation =
decryptData(
IN decryptKey -- secret key for decryption
IN privParameters -- as received on the wire
IN encryptedData -- encrypted data (encryptedPDU)
OUT decryptedData -- decrypted data (scopedPDU)
)
The abstract data elements are:
statusInformation
An indication whether the data was successfully decrypted
and if not an indication of the error.
decryptKey
The data secret key to be encrypted is treated as sequence of octets.
The data is encrypted in Generalized Counter Feedback
(GCFB) mode. used by the decryption algorithm.
The plaintext is divided into a sequence length of n 128-bit
blocks P[1], P[2], P[3], à , P[i], à , P[n]. Possibly the
last block P[n] is shorter than 128 bits.
Let i this key MUST be 32-bit counter, initialized to 1.
After 32-bit IV is selected (se 4.2), 128-bit S[i] 16/24/32 octets for i=1
is constructed in AES
128/192/256.
privParameters
The 64-bit integer to be used to calculate the following way:
1. First 32 bits are filled with 32-bit counter i.
2. Second 32 bits are filled with 32-bit IV.
3. Third 32 bits are filled with snmpEngineBoots.
4. Fourth 32 bits are filled with snmpEngineTime.
SnmpEngineBoots and snmpEngineTime must match those that
will
encryptedData
The data to be inserted in decrypted.
decryptedData
The decrypted data.
4.3. Elements of Procedure.
This section describes the SNMPv3 USM Message header. procedures for (i=1; i <= n; i++) do:
1.S[i][1] = i;
2.Obtain O the AES privacy protocols.
4.3.1. Processing an Outgoing Message
This section describes the procedure followed by encrypting S using key K:
O[i] = E(K,S[i]);
3.Ciphertext C is XOR an SNMP engine
whenever it must encrypt part of plaintext P and O (result an outgoing message using the
usmAesCfbxxxPrivProtocol (where xxx can be any of
encryption at step 1): C[i] = P[i] XOR O[i];
Blumenthal Experimental 128, 192, or 256).
Blumenthal,
Maino, McCloghrie Expires August 2002 [Page 4] 18]
Internet Draft The AES Cipher Algorithm in USM SNMPv3 July 2001
4.Copy the last 32 bits of C[i] February 2002
SNMP's User-based Security Model
1) The secret cryptKey is used to construct the second word
(second 32 bits of S: S[i+1][2] = C[i][4];
5.Output C[i] as AES encryption of P[i].
Algorithmically it means:
for as long key,
as there are input plaintext blocks
1.Fill described in section 4.1.2.2.
2) The privParameters field is set to the first 32 bits serialization according
to the rules in [RFC1906] of S[i] with an OCTET STRING representing the
value i;
2.Rijndael-encrypt
the value of S[i] with
secret key, obtaining O[i];
3.Take 64-bit integer that will be used in the IV as described in
4.1.2.2
3) The scopedPDU is encrypted (as described in section 4.1.3) and
the encrypted data is serialized according to the rules in
[RFC1906] as an OCTET STRING.
4) The serialized OCTET STRING representing the plaintext block P[i] and XOR it encrypted scopedPDU
together with O[i], obtaining C[i];
4.Take the rightmost 32 bits of C[i] privParameters and
replace with them second 32-bit word) of
S[i], obtaining S[i+1] (counter will also
be updated: here it statusInformation
indicating success is shown at step 1);
5.Output returned to the result of calling module.
4.3.2. Processing an Incoming Message
This section describes the step 3, as procedure followed by an SNMP engine
whenever it must decrypt part of an incoming message using the
next ciphertext block C[i].
usmAesCfbxxxPrivProtocol (where xxx can be any of 128, 192, or 256).
1) If the last block P[n] has length L that privParameters field is shorter than
128 bits, only not an 8-octet OCTET STRING, then
an error indication (decryptionError) is returned to the leftmost L bits of O[n] calling
module.
2) The 64-bit integer is extracted from the privParameters field.
3) The secret cryptKey and the 64-bit integer are then used at
step 3 to obtain C[n].
4.4. Message
construct the AES decryption
The data to be decrypted key and the IV that is treated computed as sequence of octets.
described in section 4.1.2.2. [??? this should be aligned with
4.1.2.2]
4) The data encryptedPDU is then decrypted (as described in Generalized Counter Feedback
(GCFB) mode.
The ciphertext section
4.1.4).
5) If the encryptedPDU cannot be decrypted, then an error
indication (decryptionError) is divided returned to the calling module.
6) The decrypted scopedPDU and statusInformation indicating success
are returned to the calling module.
5. Security Considerations
Implementations are encouraged to use the largest key sizes they can
when taking into account performance considerations for their
particular hardware and software configuration. However, a sequence key size
of n 128-bit
blocks C[1], C[2], C[3], à , C[i], à , C[n]. Possibly the
last block C[n] is shorter than 128 bits.
Form S[i] (i=1) bits is considered secure for the foreseeable future.
Because the AES and SHA256 algorithms are relatively new and have
only undergone limited cryptographic analysis, their use in SNMPv3's
USM implementations should be considered experimental. Once NIST has
published the AES FIPS and the SHS FIPS [FIPS-180-2], and at the
Blumenthal,
Maino, McCloghrie Expires August 2002 [Page 19]
Internet Draft The AES Cipher Algorithm in the February 2002
SNMP's User-based Security Model
recommendation of cryptographic experts, we will recommend that the following way:
1. Copy
IESG include usmAesCfb128PrivProtocol and usmHmacSha256AuthProtocol
within the 32-bit value default and mandatory-to-implement authentication and
privacy algorithms for USM.
For more information regarding the necessary use of random IV retrieved from
values, see [CRYPTO-B].
For further security considerations, the
privParameters reader is encouraged to second 32-bit word of S[1].
2. Copy
read the 32-bit msgSnmpEngineBoots value documents that describe the actual cipher algorithms.
6. Intellectual Property Rights Statement
Pursuant to the
third 32-bit word provisions of S[1].
3. Copy [RFC2026], the 32-bit msgSnmpEngineTime value to authors represent that
they have disclosed the
fourth 32-bit word of S[1].
for (i=1; i <= n; i++) do:
1.Complete S[i]: S[i][1] = i;
2.Encrypt S[i], obtaining O[i]: O[i] = E(K,S[i]);
3.Obtain i-th block of plaintext: P[i] = C[i] XOR
O[i];
4.Update S[i] to S[i+1]: S[i+1][2] = C[i][4];
5.Output P[i] as i-th block existence of plaintext.
Algorithmically it means:
Blumenthal Experimental [Page 5]
Internet Draft AES any proprietary or intellectual
property rights in USM SNMPv3 July 2001
for as long as there the contribution that are input ciphertext blocks
1. Fill reasonably and
personally known to the first 32 bits authors. The authors do not represent that
they personally know of S[i] with i (value all potentially pertinent proprietary and
intellectual property rights owned or claimed by the organizations
they represent or third parties.
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the counter);
2. Rijndael-encrypt implementation or use of the value S[i] using secret key
K, obtaining O[i];
3. XOR O[i] technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with C[i], obtaining plaintext block
P[i];
4. Take rightmost 32 bits of C[i] respect to rights in standards-track and replace with
them the current value
standards related documentation can be found in BCP-11. Copies of second word
claims of S[i],
obtaining S[i+1];
5. Output P[i] as i-th block rights made available for publication and any assurances
of plaintext.
If the last block C[n] has length L that is shorter than
128 bits, only licenses to be made available, or the leftmost L bits result of O[n] are used at
step 3 an attempt made
to obtain P[n].
5. MIB Definitions
usmAESPrivProtocol OBJECT-IDENTITY
STATUS current
DESCRIPTION "The Rijndael Symmetric Encryption
Protocol"
REFERENCE "Advanced Encryption Standard - NIST.
http://www.nist.gov/aes"
::= { snmpPrivProtocols 4 }
6. Rijndael Encryption Services
Here we describe a general license or permission for the Rijndael-based privacy services,
which are called upon use of such
proprietary rights by User-based Security Model (USM)
to encrypt and decrypt SNMPv3 message payload.
These are implementers or users of this specification
can be obtained from the same as described in RFC 2574.
Messages using IETF Secretariat.
7. Acknowledgements
Portions of this privacy protocol carry a
msgPrivacyParameters field text, as part well as its general structure, were
unabashedly lifted from [RFC2574].
8. References
[AES-MODE] Dworkin, M., "NIST Recommendation for Block Cipher
Modes of Operation, Methods and Techniques", NIST
Special Publication 800-38A, December 2001.
[CRYPTO-B] Bellovin, S., "Probable Plaintext Cryptanalysis of the
msgSecurityParameters. For this protocol, the
msgPrivacyParameters field is
IP Security Protocols", Proceedings of the serialized OCTET STRING
representing Symposium on
Network and Distributed System Security, San Diego, CA,
pp. 155-160, February 1997.
[FIPS-180-2] Draft of the IV.
6.1. Services "Specification for encrypting outgoing data
This Rijndael privacy protocol assumes that the caller
does the selection of SECURE HASH
STANDARD", Federal Information Processing Standard
Blumenthal,
Maino, McCloghrie Expires August 2002 [Page 20]
Internet Draft The AES Cipher Algorithm in the privKey and that February 2002
SNMP's User-based Security Model
(FIPS) Publication xxx, May 2001.
http://csrc.nist.gov/encryption/tkhash.html
[FIPS-AES] "Specification for the caller
passes ADAVANCED ENCRYPTION STANDARD
(AES)", Federal Information Processing Standard (FIPS)
Publication 197, November 2001.
[PKCS-12] "PKCS 12 v1.0: personal Information Exchange Syntax",
RSA Laboratories, June 1999.
[RFC1906] Case, J., McCloghrie, K., Rose, M., Waldbusser, S.,
"Transport Mappings for Version 2 of the secret key Simple Network
Management Protocol (SNMPv2)", RFC1906, January 1996.
[RFC2026] Bradner, S., "The Internet Standards Process --
Revision 3", RFC2026, October 1996.
[RFC2104] Bellare, M., Canetti, R., Krawczyk, H., "HMAC: Keyed-
Hashing for Message Authentication", RFC2104, February
1997.
[RFC2119] Bradner. S., "Key words for use in RFCs to be used.
To encrypt the payload (scopedPDU - see [6]) the User-
based Indicate
Requirement Levels", RFC2119, March 1997.
[RFC2574] Blumenthal, U., Wijnen, B., "User-based Security Model
(USM) will pass the payload and for version 3 of the Simple Network Management
Protocol (SNMPv3)",.RFC2574, April 1999.
[RFC2571] Wijnen, B., Harrington, D., Presuhn, R., "An
Architecture for Describing SNMP Management
Frameworks", RFC2571, April 1999.
9. Author's Addresses
Uri Blumenthal Experimental
Lucent Technologies / Bell Labs
67 Whippany Rd. Phone: 1-973-386-2163
14D-318 Email: uri@bell-labs.com
Whippany, NJ 07981, USA
Fabio Maino
Andiamo Systems, Inc.
375 East Tasman Drive Phone: 1-408-853-7530
San Jose, CA. 95134 USA Email: fmaino@andiamo.com
Keith McCloghrie
Cisco Systems, Inc.
170 East Tasman Drive Phone: 1-408-526-5260
San Jose, CA. 95134-1706 USA Email: kzm@cisco.com
Appendix A
Blumenthal,
Maino, McCloghrie Expires August 2002 [Page 6] 21]
Internet Draft The AES Cipher Algorithm in USM SNMPv3 July 2001
encryption key the February 2002
SNMP's User-based Security Model
A.1 Password to Key Algorithm
A sample code fragment (section A.1.1) demonstrates the privacy service password to
key algorithm, which implements
Rijndael protocol, receiving back the encryptedPDU (see
[6]) and the privParameters containing IV (see [3]).
Upon completion, the privacy service returns
statusInformation and, if the encryption process was
successful, the encryptedPDU and the msgPrivacyParameters
encoded as can be used when mapping an OCTET STRING.
The abstract service primitive is:
statusInformation =
encryptData(
IN encryptKey -- secret key for encryption
IN dataToEncrypt -- data SNMP user password
to encrypt (scopedPDU)
OUT encryptedData -- encrypted data (encryptedPDU)
OUT privParamets -- filled a localized key using SHA256. The specification of SHA256 is
contained in by service provider
)
6.2. Services [NIST-180-2].
A.1.1 Password to Localized Key Sample Code for decrypting incoming data
This Rijndael privacy protocol assumes that the caller
does the selection SHA256
void password_to_key_sha256(
u_char *password, /* IN */
u_int passwordlen, /* IN */
u_char *engineID, /* IN - pointer to snmpEngineID */
u_int engineLength,/* IN - length of the privKey and that the caller
passes the secret key snmpEngineID */
u_char *key) /* OUT - pointer to be used.
To decrypt caller 96-octet buffer
*/
{
SHA256_CTX SH;
u_char *cp, buf[64];
u_long i, id = 0;
for (id = 0; id < 3; id++) {
/* Compute the payload (encryptedPDU - see[4]) diversifier Dx_512 with ID=id+1 */
cp = buf;
for (i = 0; i < 64; i++)
*cp++ = id+1;
SHA256_Init (&SH); /* initialize SHA */
/* Compute SHA256(D || ...) */
SHA256_Update (&SH, buf, 64);
/* create S_512 */
memcpy(buf, engineID, engineLength);
cp = buf;
for (i = 0; i < 64; i++) {
/*************************************************/
/* Take the USM
will pass next octet of the encryptedPDU, secret key and privParameters engineID, wrapping */
/* to the privacy service, receiving back beginning of the decrypted
plaintext scopedPDU.
statusInformation indicates whether engineID as necessary.*/
/*************************************************/
*cp++ = engineID[i % engineLength];
}
/* Compute SHA256(D || S || ...) */
SHA256_Update (&SH, buf, 64);
/* create P_512 */
memcpy(buf, password, engineLength);
cp = buf;
for (i = 0; i < 64; i++) {
/*************************************************/
/* Take the decryption was
successful.
Upon completion next octet of the privacy module returns
statusInformation and, if password, wrapping */
/* to the decryption process was
successful, beginning of the scopedPDU in plain text.
The abstract service primitive is:
statusInformation =
decryptData(
IN decryptKey -- secret key for decrypting
IN privParameters -- password as received on the wire
IN encryptedData -- encrypted data (encryptedPDU)
OUT decryptedData -- decrypted data (scopedPDU)
)
Blumenthal Experimental necessary.*/
Blumenthal,
Maino, McCloghrie Expires August 2002 [Page 7] 22]
Internet Draft The AES Cipher Algorithm in USM SNMPv3 July 2001
7. Elements of the procedure
This section describes the procedure followed by an SNMP
engine whenever it must encrypt part February 2002
SNMP's User-based Security Model
/*************************************************/
*cp++ = password[i % passwordlen];
}
/* Compute SHA256(D || S || P) */
SHA256_Update (&SH, buf, 64);
SHA256_End (&SH, buf); /* tell SHA we're done */
/* Copy 256 bit of an outgoing
message using the usmAESPrivProtocol.
7.1. Processing an Outgoing Message
1.IV is computed.
2.privParameters field is set localized key */
memcpy(key+(id*64), buf, 64);
}
return;
}
A.2 Password to Key Sample Results
The following shows a sample output of the serialization
according password to key algorithm
using SHA256 as hash function.
Let's assume the rules in [RFC1906] of user U has the OCTET
STRING representing password "maplesyrup" and the 4-octet-long IV.
3.The scopedPDU
snmpEngineID is encrypted (as described above in 4.3)
and the encrypted data OCTECT STRING:
'00000000 00000000 00000002'H
Then the user password is serialized according to concatenated in the
rules 512-bit long string
P_512:
"maplesyrupmaplesyrupmaplesyrupmaplesyrupmaplesyrupmaplesyrupmapl"
The snmpEngineID is concatenated in [RFC1906] as an OCTET STRING.
4.The serialized OCTET the 512-bit long OCTECT STRING representing
S_512:
'00000000 00000000 00000002 00000000 00000000 00000002 00000000
00000000 00000002 00000000 00000000 00000002 00000000 00000000
00000002 00000000'H
The result of the encrypted
scopedPDU together hash computation with the privParameters and
statusInformation indicating success diversifier ID=1 is returned to the calling module.
7.2. Processing an Incoming Message
1.If
value:
enc_256 = '97a44030 8b7042c4 d7fc1779 daeca6c1 27681f23 2a205666
f2a58cf3 c35d9206'H
The result of the privParameters field is not a 4-octet OCTET
STRING, then an error indication (decryptionError)
is returned to hash computation with the calling module.
2.IV diversifier ID=2 is extracted from privParameters.
3.The encryptedPDU the
value:
preIV_256 = 'fb5ccedc c7e7a95d 388d4efe a45d26dc 5c5edf41 a83735ae
ea294e64 690d4f6b'H
The result of the hash computation with the diversifier ID=3 is decrypted, as described above
in 4.4.
4.The decrypted scopedPDU and the statusInformation
are returned to
value:
Blumenthal,
Maino, McCloghrie Expires August 2002 [Page 23]
Internet Draft The AES Cipher Algorithm in the caller.
8. February 2002
SNMP's User-based Security Considerations Model
int_256 = 'a15acac2 0a12a73f 00db7410 61350d15 07e58d25 17359a35
2b0533f9 34a026a7'H
The strength of this protocol depends on localized key Kul is the cryptographic
strength of SHA-1 hash-function (properties 768-bit long concatenation of the
generated key) and of Rijndael block cipher (security three
numbers above:
Kul = '97a44030 8b7042c4 d7fc1779 daeca6c1 27681f23 2a205666
f2a58cf3 c35d9206 fb5ccedc c7e7a95d 388d4efe a45d26dc 5c5edf41
a83735ae ea294e64 690d4f6b a15acac2 0a12a73f 00db7410 61350d15
07e58d25 17359a35 2b0533f9 34a026a7'H
A.3 Sample keyChange results using SHA256
Let us assume that a user has a current password of "maplesyrup" as
in section A.2. and let us also assume the encryption). It will be better to use SHA-256 or SHA-
512 for AES key generation, but snmpEngineID of 12
octets:
'00000000 00000000 00000002'H
If we now want to give more time
to their studying by the world cryptographic community.
An adversary can predictably change the plaintext bits by
modifying password to "newsyrup", then we first
calculate the corresponding ciphertext bits when
encryption in GCFB mode localized key for the new password. It is used. Therefore it as follows:
'00fc0fe7 f4ef921b abae4492 a85a6391 3e5bd059 65cb2e07 a20be4d6
b1b986a5 cbeca2bd bc54215a ffaacd73 8c0b8128 3c1a158a b6987029
948eb40c b72db3ed e3121e80 d653f276 4d135697 10320f89 25484d17
62aafd88 4c5e0838 df40597c'H
This is vital to
adhere the 768-bit long Kul that can be used to derive a new
authKey for an USM requirement given in RFC 2574 and always use authentication with encryption.
Blumenthal Experimental [Page 8]
Internet Draft AES in protocol, or a new privKey for an
USM SNMPv3 July 2001
9. References
1.S. Bradner ôThe Internet Standard Process û Revision 3ö,
RFC 2026. Oct 1996.
2.S. Bradner ôKey words to use in privacy protocol.
If the RFCsö, RFC 2119. Mar
1997.
3.U. Blumenthal, B. Wijnen ôUser-based Security Model
(USM) for version 3 authentication protocol is usmHmacSha256AuthProtocol the new
authentication key is the last 256 bits of the Simple Network Management
Protocol (SNMPv3)ö, RFC 2574, April 1999.
4.J. Daemen, V. Rijmen "The Block Cipher Rijndael"
http://www.esat.kuleuven.ac.be/~rijmen/rijndael/
5.Rijndael: NIST's Selection new localized key
Kul:
newkey = 'e3121e80 d653f276 4d135697 10320f89 25484d17 62aafd88
4c5e0838 df40597c'H
If we then use a (not so good, but easy to test) random value of:
'00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000'H
Then the value "delta" we must send for authentication keyChange is:
'd9d91e39 76a96666 1e4643d5 870bf8db 64d59f15 4830fa14 14a79a1c
0ceceb9c'H
Similarly the keyChange that has to be sent in order to update the AES
http://csrc.nist.gov/encryption/aes/rijndael/
6.D. Harrington, R. Presuhn, B. Wijnen ôAn Architecture
for Describing SNMP Management Frameworkö, RFC 2571.
April 1999.
10. Acknowledgments
Help
privacy Key of the members of Wireless Security Group at Lucent
Technologies, especially of Dr. Ganesh Sundaram, SNMPv3 WG
and Security Area Directorate usmAesCfb128PrivProtocol is gratefully acknowledged.
Special thanks go to Wes Hardaker and Randy Presuhn for
detailed review and helpful comments.
11. Author's Addresses
Uri Blumenthal
Lucent Technologies / Bell Labs
14D-318
67 Whippany Rd
Whippany, NY 07981
USA
Phone: +1.973.386.2163
Email: uri@lucent.com
Blumenthal Experimental obtained from the new
privacy key derived from Kul (the first 384 bits of Kul):
Blumenthal,
Maino, McCloghrie Expires August 2002 [Page 9] 24]
Internet Draft The AES Cipher Algorithm in USM SNMPv3 July 2001
12.Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights
Reserved. This document and translations of it may be
copied and furnished the February 2002
SNMP's User-based Security Model
newkey = '00fc0fe7 f4ef921b abae4492 a85a6391 3e5bd059 65cb2e07
a20be4d6 b1b986a5 cbeca2bd bc54215a ffaacd73 8c0b8128'H
If we then use a (not so good, but easy to others, and derivative works that
comment on or otherwise explain it or assist in its
implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction test) random value of:
'00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000'H
Then the value "delta" we must send for privacy keyChange is:
'6967c4f6 3961b426 dd175490 ae5e0f0d 2469a05f 4d89d7da 018a9f7c
261d7f52 e402861d eda30bc2 49891bd0 f36c39bb'H
A.4 Sample Results of Extension of Localized Keys shorter than 384 bits
The following shows a sample output of
any kind, provided that the above copyright notice and
this paragraph are included on all such copies and
derivative works. However, this document itself may not algorithm that would be
modified in any way, such as by removing the copyright
notice or references
used to extend a 160-bit localized key generated with SHA, to a 768-
bit localized key (e.g. to have enough key material to generate a
384-bit privKey for the Internet Society or other
Internet organizations, except as needed usmAesCfb128PrivProtocol and a 256-bit
authKey for usmHmacSha256AuthProtocol).
Let's assume that the purpose user U has a password of developing Internet standards in which case "maplesyrup" and that
the
procedures key kas been localized using SHA for copyrights defined in the Internet
Standards process must SNMP engine whose
snmpEngineID is:
'00000000 00000000 00000002'H
The localized key will be followed, or as required to
translate it into languages other than English. the 160 bit long hex number:
'6695febc 9288e362 82235fc7 151f1284 97b38f3f'H
The
limited permissions granted above are perpetual and 768-bit extended localized key will
not be revoked by generating applying the Internet Society or its successors
or assigns. This document and
mechanism described in 4.1.2.1, using the information contained
herein SHA algorithm. The
resulting extended localized key is:
Kul = '6695febc 9288e362 82235fc7 151f1284 97b38f3f 505e07eb
9af25568 fa1f5dbe 1bf2e6a0 e36ea40a aa0f656e 819227e8 a6ca3f99
75e4f56b 85313d30 fdf58c3c 6b9301ef 389ae41a 28d7234b 0feeca5f
cfe18261 1cd8ac8e aea3830e 91e60109'H
Note that the last 32 bits of the result of the extended key
algorithm have been truncated to obtain a Kul that is provided on an "AS IS" basis and THE INTERNET
SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS
ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.
Blumenthal Experimental exactly 768-
bit long.
Blumenthal,
Maino, McCloghrie Expires August 2002 [Page 10] 25]
----