Network Working Group U. Blumenthal Internet Draft Lucent Technologies Document: draft-blumenthal-aes-usm-00.txt December 2000 Rijndael Encryption Protocol with SNMPv3 USM Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. For potential updates to the above required-text see: http://www.ietf.org/ietf/1id-guidelines.txt 1. Abstract This document describes the use of Rijndael encryption protocol with User-based Security Model (USM) for SNMP version 3. This protocol provides data confidentiality. This document augments and should be used with RFC 2574 [1]. 2. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. 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 RFC-2119 [2]. K _ secret key for the encryption engine IV _ Initialization Vector for the encryption engine Si _ the input value in the shift register (on i-th step) <Title> <month> <year> Oi _ the output value computed via encrypting the shift register Ti _ 64 leftmost bits of Oi Pi _ i-th 64-bit block of the plaintext Ci _ i-th 64-bit block of the ciphertext (last block may be shorter) Ek(P) _ encrypting P in ECB mode under key K A^b - A raised in power b XOR - bitwise operation eXclusive OR A * B _ A multiplied by B 3. Overview At the time of writing of this document, Rijndael [4] has been declared the proposed AES (Advanced Encryption Standard) [5] 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 to base them on. The protocol is very similar to CBC-DES Symmetric Encryption Protocol described in RFC 2574 [3], with some exceptions: . Rijndael uses longer keys (USM permits 128-, 192- and 256-bit long keys, and recommends 128-bit key for most applications); . Rijndael block size is 128 bits (instead of 64 bits in DES), which affects the resulting message size; . Recommended encryption mode is CFB, for the purpose of non- increasing the message size; . Initialization Vector (IV) is twice as long (128 bits) and is generated differently (the procedure is outlined below). Due to increased block length, 4. 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 and reference implementation code are available on the AES NIST Web site [5]. Rijndael takes 128-, 192- and 256-bit long keys. For USM it is believed that 128-bit keys are sufficient. However neither USM [3] nor the Rijndael protocol as specified here, mandate any particular key length - thus all the three key length options are acceptable. Rijndael encryption algorithm is used to encrypt the designated portion of an SNMP message, which along with Rijndael Initialization Vector is included as a part of the message sent to the recipient. <Title> <month> <year> 4.1. Rijndael Key Rijndael key is an octet string of 16, 24, or 32 bytes. The recommended length is 16 bytes, which is deemed enough for most applications. The key is (implicitly) stored in the USM User table and can be manipulated using SNMPv3 protocol via access to USM User Table [3]. The whole length of the octet string representing the secret privacy key is used as a Rijndael key (see usmUserPrivKeyChange and usmUserOwnPrivKeyChange in [3]). If a password or other variable-length user input needs to be converted to a Rijndael key, follow the algorithm given in RFC 2574. 4.2. Rijndael Initialization Vector It is up to the entity in question how to obtain/compute the Initialization Vector (IV). On Unix operating systems one can use reasonably secure random number sources such as /dev/random. IV should satisfy the following requirements: . Unique (non-repeating from one packet to another); . Varying _rapidly_ (considerable amount of bits change from one IV to another). It is preferable but not required, that IV is unpredictable. If a good source of randomness is unavailable, one can generate IV's running Rijndael in FCB (filtered counter) mode, following the below procedure. When the SNMPv3 entity is activated, it obtains one 128-bit random number to use it as the enciphering key for the Rijndael encryption engine. Then it sets an 8-byte octet string A to the concatenation of 32-bit octet strings agentBoots and agentTime. Then the octet string A is padded with zeroes to 16-byte length. Octet string A is used as input for Rijndael encryption engine. This completes initialization of Rijndael-based Pseudo-Random Number Generator. From now on, when a message needs to be encrypted, the following steps are performed: 1.Rijndael engine performs one iteration. 2.IV is set to the 128-bit result of step 1. 3.Treating octet string A as a 128-bit integer number, increment it by one (to prepare for the next request for IV). 4.3. Message encryption The data to be encrypted is treated as sequence of octets. <Title> <month> <year> The data is encrypted in Cipher feedback (CFB) mode. The plaintext is divided into a sequence of n 64-bit blocks P1, P2, P3, _, Pi, _, Pn. Possibly the last block Pn is shorter than 64 bits. Let Si (i=1) be the input value of the shift register. Assign the value of IV to S1. for (i=1; i <= n; i++) do: 1. Pi = next 64-bit block of the plaintext (of the message) 2. Oi = Ek(Ii) 3. Ti = 64 leftmost bits of Oi 4. Ci = Pi XOR Ti 5. S[i+1] = ((2^64 * Ii) + Ci ) mod 2^128 Algorithmically it means: for as long as there are input blocks 1. Rijndael-encrypt the value of the register Si with secret key; 2. Take the next plaintext block Pi; 3. r is the length in bits of the plaintext block Pi being currently processed; 4. Assign 64 leftmost bits of the result to Oi; 5. XOR them with the plaintext block (Ci = Pi XOR Oi), if the plaintext block is only r-bits long (r < 64) use the leftmost r bits of Oi; 6. Output the result of the step 3, as the next ciphertext block Ci, and if r is less than 64, stop. 7. Shift the shift-register 64 bits to the left, discarding the leftmost 64 bits; 8. Fill the rightmost 64 bits of the shift register with the ciphertext block obtained at the step 3. This prepares the Rijndael CFB engine to process the next plaintext block. 4.4. Message decryption The data to be decrypted is treated as sequence of octets. The data is decrypted in Cipher feedback (CFB) mode. The ciphertext is divided into a sequence of n 64-bit blocks C1, C2, C3, _, Ci,_, Cn. Possibly the last block Cn is shorter than 64 bits. Let Si (i=1) be the input value of the shift register. Assign the value of IV retrieved from the privParameters to S1. for (i=1; i <= n; i++) do: <Title> <month> <year> 1. Ci = next 64-bit block of the plaintext (of the message) 2. Oi = Ek(Ii) 3. Ti = 64 leftmost bits of Oi 4. Pi = Ci XOR Ti 5. S[i+1] = ((2^64 * Ii) + Ci ) mod 2^128 Algorithmically it means: for as long as there are input blocks 1. Rijndael-encrypt the value of the register Si with secret key; 2. Take the next ciphertext block Ci; 3. r is the length in bits of the ciphertext block Ci being currently processed; 4. Take 64 leftmost bits of the result (Oi) 5. XOR them with the ciphertext block (Pi = Ci XOR Oi), if the ciphertext block is only r-bits long and r<64, use the leftmost r bits of Oi; 6. Output the result of the step 3, as the next plaintext block Pi, and if r is less than 64, stop; 7. Shift the shift-register 64 bits to the left, discarding the leftmost 64 bits; 8. Fill the rightmost 64 bits of the shift-register with the ciphertext block obtained at the step 3. This prepares the Rijndael CFB engine to process the next ciphertext block. 1. 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 } 5. Rijndael Encryption Services Here we describe the Rijndael-based privacy services, which are called upon by User-based Security Model (USM) to encrypt and decrypt SNMPv3 message payload. These are the same as described in RFC 2574. 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 IV. <Title> <month> <year> 5.1. Services for encrypting outgoing data This Rijndael 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. To encrypt the payload (scopedPDU _ see [6]) the User-based Security Model (USM) will pass the payload and the encryption key to the privacy service 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 an OCTET STRING. The abstract service primitive is: statusInformation = encryptData( IN encryptKey -- secret key for encryption IN dataToEncrypt -- data to encrypt (scopedPDU) OUT encryptedData -- encrypted data (encryptedPDU) OUT privParamets -- filled in by service provider ) 5.2. Services for decrypting incoming data This Rijndael 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. To decrypt the payload (encryptedPDU - see[4]) the USM will pass the encryptedPDU, secret key and privParameters to the privacy service, receiving back the decrypted plaintext scopedPDU. statusInformation indicates whether the decryption was successful. 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 decrypting IN privParameters -- as received on the wire IN encryptedData -- encrypted data (encryptedPDU) OUT decryptedData -- decrypted data (scopedPDU) ) <Title> <month> <year> 2. Elements of the procedure This section describes the procedure followed by an SNMP engine whenever it must encrypt part of an outgoing message using the usmAESPrivProtocol. 3. Processing an Outgoing Message 1. IV is computed. 2. privParameters field is set to the serialization according to the rules in [RFC1906] of the OCTET STRING representing the 16- octet-long IV. 3. The scopedPDU is encrypted (as described above) 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. 3. Processing an Incoming Message 1. If the privParameters field is not an 16-octet OCTET STRING, then an error indication (decryptionError) is returned to the calling module. 2. IV is extracted from privParameters. 3. The encryptedPDU is decrypted as described above. 4. The decrypted scopedPDU and the statusInformation are returned to the caller. 6. Security Considerations The strength of this protocol depends on the cryptographic strength of SHA-1 hash-function and of Rijndael block cipher. An adversary can predictably change the plaintext bits by modifying the corresponding ciphertext bits when encryption in CFB mode is used. Therefore it is vital to adhere to USM requirement given in RFC 2574 and always use authentication with encryption. 7. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 <Title> <month> <year> 1.RFC 2026. 2.RFC 2119. 3.U. Blumenthal, B. Wijnen "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3). RFC2574, April 1999. 4.J. Daemen, V. Rijmen "The Block Cipher Rijndael" http://www.esat.kuleuven.ac.be/~rijmen/rijndael/ 5.Rijndael: NIST's Selection for the AES http://csrc.nist.gov/encryption/aes/rijndael/ 6.RFC 2571. 10. Acknowledgments Help of the members of Wireless Security Group at Lucent Technologies, SAGE group, SNMPv3 WG and Security Area Directorate is gratefully acknowledged. 4. 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 12. Appendix 1. Creating IV-generating Key The procedure described here helps obtaining an IV-generating key IVK when no good source of randomness is available. 1. Obtain a 128-bit random number R of poor quality. 2. Encrypt is using the user's secret key. 3. XOR the result with R itself and assign it to W = R XOR Ek(R) 4. Concatenate agentBoots with agentTime and snmpEngineId of this entity (if it exists) and pad the results with 0xBE to 16 bytes. Assign the result to RND. 5. XOR the result of the previous step with W. 6. Encrypt the result of the previous step using secret key K. 7. XOR the result of the previous step with W. 8. Cyclic-rotate the result of the previous step to the left by 53 bits. 9. Encrypt the result of the previous step using secret key K. 10. XOR the result of the previous step with W. <Title> <month> <year> 11. Output the result of the previous step as IVK. <Title> <month> <year> 5. Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. <Title> <month> <year>
Datatracker
draft-blumenthal-aes-usm-00
Internet-Draft
