Internet Draft U. Blumenthal draft-blumenthal-aes-usm-02.txt Lucent Technologies Expires: August 2002 F. Maino Andiamo Systems, Inc. K. McCloghrie Cisco Systems, Inc. February 2002 The AES 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]. 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. Abstract This document describes a set of authentication and symmetric encryption protocols that supplement the protocols described in the User-based Security Model (USM) [RFC2574], which is a Security Subsystem for version 3 of the Simple Network Management Protocol for use in the SNMP Architecture [RFC2571]. The authentication protocol described in this document is based on SHA256 [FIPS-180-2] and the symmetric encryption protocols are based on the AES 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 the 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 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 the HMAC-SHA256-96 Authentication Module......................................................10 3.3. Elements of 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 the AES 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 the 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 Key Algorithm..................................22 A.1.1 Password to Localized Key Sample Code for SHA256......22 A.2 Password to Key Sample Results.............................23 A.3 Sample keyChange results using SHA256......................24 A.4 Sample Results of Extension of Localized Keys shorter than 384 bits.......................................................25 Blumenthal, Maino, McCloghrie Expires August 2002 [Page 2]
Internet Draft The AES Cipher Algorithm in 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 is defined as a Security Subsystem within an SNMP engine. [RFC2574] describes the use of HMAC-MD5-96 and HMAC-SHA-96 as the (initial) authentication protocols and the use of CBC-DES as the (initial) privacy protocol. The User-based Security Model however allows for other such protocols to be used instead of or concurrent with these protocols. This memo describes the use of HMAC-SHA256-96 as an alternative authentication protocol and the use of CFB128-AES-128/192/256 as three alternative privacy protocols for the User-based Security Model. This memo describes also the 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 "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.1. Goals and Constraints The main goals of this memo are as follows. 1) Provide a set of new privacy protocols for USM based on the Advanced Encryption Standard. 2) Provide a new authentication protocol for USM based on SHA256, the AES companion hash algorithm. 3) Provide a key localization mechanism that generates an adequate amount of key material for the new authentication and privacy protocols. A further important goal of the key localization mechanism described in this memo, is to guarantee that different key material is generated for the authentication protocol and for the privacy protocol of a user, even when the same password is used both for authentication and for privacy. In fact, even if discouraged in [RFC2574], it's common practice today that an SNMP user uses the same password for authentication and privacy protection ending up with the same localized key used both for authentication and encryption. The major constraint is to maintain a complete interchangeability of the 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 this memo. 1.2. Key Localization As defined in [RFC2574] a localized key is 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 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 one of the authentication protocols defined on [RFC2574], the key localization is performed according to the two steps process described in section 2.6 of [RFC2574]. If the authentication protocol defined for a user U at the authoritative SNMP engine E, is the new authentication protocol described in this memo (HMAC-SHA256-96), the user password is converted into a localized key Kul according to the 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 input password, the 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 strings that 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 secret key to be used by the decryption algorithm. The length of this key MUST be 16/24/32 octets for AES 128/192/256. privParameters The 64-bit integer to be used to calculate the IV. encryptedData The data to be decrypted. decryptedData The decrypted data. 4.3. Elements of Procedure. This section describes the procedures for the AES privacy protocols. 4.3.1. Processing an Outgoing Message This section describes the procedure followed by an SNMP engine whenever it must encrypt part of an outgoing message using the usmAesCfbxxxPrivProtocol (where xxx can be any of 128, 192, or 256). Blumenthal, Maino, McCloghrie Expires August 2002 [Page 18]
Internet Draft The AES Cipher Algorithm in the February 2002 SNMP's User-based Security Model 1) The secret cryptKey is used to construct the AES encryption key, as described in section 4.1.2.2. 2) The privParameters field is set to the serialization according to the rules in [RFC1906] of an OCTET STRING representing the the 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 encrypted scopedPDU together with the privParameters and statusInformation indicating success is returned to the calling module. 4.3.2. Processing an Incoming Message This section describes the procedure followed by an SNMP engine whenever it must decrypt part of an incoming message using the usmAesCfbxxxPrivProtocol (where xxx can be any of 128, 192, or 256). 1) If the privParameters field is not an 8-octet OCTET STRING, then an error indication (decryptionError) is returned to the 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 to construct the AES decryption key and the IV that is computed as described in section 4.1.2.2. [??? this should be aligned with 4.1.2.2] 4) The encryptedPDU is then decrypted (as described in section 4.1.4). 5) If the encryptedPDU cannot be decrypted, then an error indication (decryptionError) is 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 key size of 128 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 IESG include usmAesCfb128PrivProtocol and usmHmacSha256AuthProtocol within the default and mandatory-to-implement authentication and privacy algorithms for USM. For more information regarding the necessary use of random IV values, see [CRYPTO-B]. For further security considerations, the reader is encouraged to read the documents that describe the actual cipher algorithms. 6. Intellectual Property Rights Statement Pursuant to the provisions of [RFC2026], the authors represent that they have disclosed the existence of any proprietary or intellectual property rights in the contribution that are reasonably and personally known to the authors. The authors do not represent that they personally know of 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 implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. 7. Acknowledgements Portions of this text, as 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 IP Security Protocols", Proceedings of the Symposium on Network and Distributed System Security, San Diego, CA, pp. 155-160, February 1997. [FIPS-180-2] Draft of the "Specification for the SECURE HASH STANDARD", Federal Information Processing Standard Blumenthal, Maino, McCloghrie Expires August 2002 [Page 20]
Internet Draft The AES Cipher Algorithm in the 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 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 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 Indicate Requirement Levels", RFC2119, March 1997. [RFC2574] Blumenthal, U., Wijnen, B., "User-based Security Model (USM) 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 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 21]
Internet Draft The AES Cipher Algorithm in 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 password to key algorithm, which can be used when mapping an SNMP user password to a localized key using SHA256. The specification of SHA256 is contained in [NIST-180-2]. A.1.1 Password to Localized Key Sample Code for 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 snmpEngineID */ u_char *key) /* OUT - pointer to 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 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 next octet of the engineID, wrapping */ /* to the beginning of the 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 next octet of the password, wrapping */ /* to the beginning of the password as necessary.*/ Blumenthal, Maino, McCloghrie Expires August 2002 [Page 22]
Internet Draft The AES Cipher Algorithm in the 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 localized key */ memcpy(key+(id*64), buf, 64); } return; } A.2 Password to Key Sample Results The following shows a sample output of the password to key algorithm using SHA256 as hash function. Let's assume the user U has the password "maplesyrup" and the snmpEngineID is the OCTECT STRING: '00000000 00000000 00000002'H Then the user password is concatenated in the 512-bit long string P_512: "maplesyrupmaplesyrupmaplesyrupmaplesyrupmaplesyrupmaplesyrupmapl" The snmpEngineID is concatenated in the 512-bit long OCTECT STRING S_512: '00000000 00000000 00000002 00000000 00000000 00000002 00000000 00000000 00000002 00000000 00000000 00000002 00000000 00000000 00000002 00000000'H The result of the hash computation with the diversifier ID=1 is the value: enc_256 = '97a44030 8b7042c4 d7fc1779 daeca6c1 27681f23 2a205666 f2a58cf3 c35d9206'H The result of the hash computation with the diversifier ID=2 is 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 the value: Blumenthal, Maino, McCloghrie Expires August 2002 [Page 23]
Internet Draft The AES Cipher Algorithm in the February 2002 SNMP's User-based Security Model int_256 = 'a15acac2 0a12a73f 00db7410 61350d15 07e58d25 17359a35 2b0533f9 34a026a7'H The localized key Kul is the 768-bit long concatenation of the 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 snmpEngineID of 12 octets: '00000000 00000000 00000002'H If we now want to change the password to "newsyrup", then we first calculate the localized key for the new password. It is 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 the 768-bit long Kul that can be used to derive a new authKey for an USM authentication protocol, or a new privKey for an USM privacy protocol. If the authentication protocol is usmHmacSha256AuthProtocol the new authentication key is the last 256 bits of the 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 privacy Key of the usmAesCfb128PrivProtocol is obtained from the new privacy key derived from Kul (the first 384 bits of Kul): Blumenthal, Maino, McCloghrie Expires August 2002 [Page 24]
Internet Draft The AES Cipher Algorithm in 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 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 the algorithm that would be 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 usmAesCfb128PrivProtocol and a 256-bit authKey for usmHmacSha256AuthProtocol). Let's assume that the user U has a password of "maplesyrup" and that the key kas been localized using SHA for the SNMP engine whose snmpEngineID is: '00000000 00000000 00000002'H The localized key will be the 160 bit long hex number: '6695febc 9288e362 82235fc7 151f1284 97b38f3f'H The 768-bit extended localized key will be generating applying the mechanism described in 4.1.2.1, using the 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 exactly 768- bit long. Blumenthal, Maino, McCloghrie Expires August 2002 [Page 25]
