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)
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.
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.
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:
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.
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)
)
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
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.
11. Output the result of the previous step as IVK.
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.