WDIFF

draft-blumenthal-aes-usm-02.txt --> draft-blumenthal-aes-usm-03.txt

Internet Draft U. Blumenthal
draft-blumenthal-aes-usm-02.txt
draft-blumenthal-aes-usm-03.txt Lucent Technologies
Expires: August 2002 January 2003 F. Maino
Andiamo Systems, Inc.
K. McCloghrie
Cisco Systems, Inc.
February
July 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 symmetric encryption protocols 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, 128 (mandated), 192,
and 256 bits.

Table of Contents

1. Introduction....................................................3 Introduction....................................................2
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.

Blumenthal/Maino/McCloghrie Expires August 2002 January 2003 [Page 1]
Internet Draft The AES Cipher Algorithm in the February 2002
SNMP's User-based Security Model

1.2. Key Localization...........................................3
1.3. Password Entropy and Storage...............................3
2. Definitions.....................................................5 Definitions.....................................................4
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. Protocols...........5
3.1. Mechanisms.................................................6
3.1.1. The AES based AES-based Symmetric Encryption Protocols.........13
4.1.2. Protocols..........6
3.1.2. Localized Key, AES Encryption Key and Initialization
Vector......................................................14
4.1.3.
Vector.......................................................7
3.1.3. Data Encryption......................................15
4.1.4. Encryption.......................................8
3.1.4. Data Decryption......................................16
4.2. Decryption.......................................9
3.2. Elements of the AES Privacy Protocols.....................16
4.2.1. Users................................................16
4.2.2. msgAuthoritativeEngineID.............................17
4.2.3. Protocols......................9
3.2.1. Users.................................................9
3.2.2. msgAuthoritativeEngineID..............................9
3.2.3. SNMP Messages Using this Privacy Protocol............17
4.2.4. Protocol............10
3.2.4. Services provided by the AES Privacy Modules.........17
4.3. Modules.........10
3.3. Elements of Procedure.....................................18
4.3.1. Procedure.....................................11
3.3.1. Processing an Outgoing Message.......................18
4.3.2. Message.......................11
3.3.2. Processing an Incoming Message.......................19
5. Message.......................12
4. Security Considerations........................................19
6. Considerations........................................12
5. Intellectual Property Rights Statement.........................20 Statement.........................13
6. Acknowledgements...............................................13
7. Acknowledgements...............................................20 References.....................................................13
8. References.....................................................20
9. Author's Addresses.............................................21 Authors Addresses..............................................14
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 A........................................................14
A.1.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 bits.......................................................14

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
concurrently 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 with
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

Blumenthal/Maino/McCloghrie Expires January 2003 [Page 2]

1.1.Goals and Constraints

The main goals of this memo are as follows.
1) Provide
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
2)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, user, 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
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
(and consequently only one pair of keys 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, 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

1.3.Password Entropy and Storage

The security of various cryptographic functions lies both in this memo (HMAC-SHA256-96), the user password is
converted into a localized key Kul according to
strength of the general method
for deriving keys and IVs from password functions themselves against various forms of
attack, and salt described also, perhaps more importantly, in
Appendix B.2 of PKCS #12 [PKCS-12]. That method the keying material
that is used with them. While theoretical attacks against the
SNMP user password as input password,
cryptographic functions specified by this document are possible, it
is vastly more probable that key-guessing is the snmpEngineID as salt,
SHA256 as hash function with output length u=256 and intermediate
blocks size v=512. main threat.

The generated Kul will following can be suggested with regard to the concatenation of
three 256 bits strings user password:
- Passwords lengths SHOULD be between 12 and 24 bytes.
- Password sharing SHOULD be limited so that will provide encryption passwords aren't shared
among multiple SNMP users.
-Password SHOULD be changed at least every 90 days.

It worth to remember that, as specified in [RFC2574], if user's
password is disclosed, then key material,
pre-IV data localization will not help and integrity
network security may be compromised in this case. Therefore a user's
password or non-localized key material for the encryption and
authentication protocols of USM.

1.2.1. Kul generation (for HMAC-SHA256-96)

The procedure described here generates MUST NOT be stored on a 768 bit long Kul derived
from the SNMP user password, the snmpEngineID and the hash algorithm
SHA256, according to managed
device/node. Instead the localized key and IV derivation general method
described SHALL be stored (if at all),
so that, 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 case a 512 bits string S_512 (the final copy device does get compromised, no other managed or
managing devices get compromised.

Blumenthal/Maino/McCloghrie Expires January 2003 [Page 3]

2.Definitions

SNMP-USM-AES-MIB DEFINITIONS ::= BEGIN

IMPORTS
MODULE-IDENTITY, OBJECT-IDENTITY FROM SNMPv2-SMI
xxx FROM XXX-MIB;

snmpUsmAesMIB MODULE-IDENTITY
LAST-UPDATED "200206300000Z"
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
salt s may be truncated to create S_512).

The appropriate number of copies use of the password p are concatenated
together AES by SNMP User-based Security
Model."
REVISION "200110120000Z"
DESCRIPTION "Initial version, published as RFCnnnn"

::= { xxx nn } -- to create a 512 bits string P_512 (the final copy be assigned by TBD

snmpUsmAesProtocols OBJECT IDENTIFIER ::= { snmpUsmAesMIB 1 }

-- Identification of Privacy Protocols

usmAesCfb128Protocol OBJECT-IDENTITY
STATUS current
DESCRIPTION "The CFB128-AES-128 Privacy Protocol."
REFERENCE "- Specification for the
password p may be truncated to create P_512).
Blumenthal,
Maino, McCloghrie ADVANCED ENCRYPTION
STANDARD (DRAFT). Federal Information Processing

Blumenthal/Maino/McCloghrie Expires August 2002 January 2003 [Page 4]
Internet Draft The AES

Standard (FIPS) Publication 197.
(November 2001).

- Dworkin, M., NIST Recommendation for Block
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 Modes of the diversifiers Operation, Methods and
Techniques (DRAFT).
NIST Special Publication 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 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 ADVANCED ENCRYPTION
STANDARD (DRAFT). Federal Information Processing
Standard (FIPS) Publication 197
(November 2001).

- Dworkin, M., NIST Recommendation for Block
Cipher Modes of Kul SHOULD be Operation, Methods and
Techniques (DRAFT).
NIST Special Publication 800-38A
(December 2001).
"
::= { snmpUsmAesProtocols 4 }

END

3.CFB128-AES-128/192/256 Symmetric Encryption Protocols

This section describes three Symmetric Encryption Protocols based on
the AES Cipher Algorithm [FIPS-AES], used by privacy
protocols to generate, respectively, in Cipher Feedback Mode as
described in [AES-MODE], using encryption keys and IV
material, while the last section with a size of Kul SHOULD be used by
authentication 128,
192, and 256 bits.

Blumenthal/Maino/McCloghrie Expires January 2003 [Page 5]

These protocols are identified by:
-usmAesCfb128PrivProtocol;
-usmAesCfb192PrivProtocol;
-usmAesCfb256PrivProtocol;

These protocols are alternatives to derive authentication and integrity
keys. However, how the Kul is used by each authentication or privacy protocol defined in
[RFC2574].

3.1.Mechanisms

- In support of data confidentiality, an encryption algorithm is left to
required. An appropriate portion of the protocol specification. message is encrypted prior
to being transmitted. The privacy protocols described in this memo use User-based Security Model specifies that
the first
128/192/256 bits of scopedPDU is the first section portion of Kul as encryption key, 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 last section of Kul as authentication key. initialization vector. The preIV section of
Kul,
secret value is not used shared by all SNMP engines authorized to originate
messages on behalf of the privacy protocols described appropriate user.

3.1.1.The AES-based Symmetric Encryption Protocols

The Symmetric Encryption Protocols defined in this memo.
However the 256 bits preIV section of Kul, will memo provide
support future
privacy protocols that may require preIVs for data confidentiality. The designated portion of size up to 256 bits.

An implementation an SNMP
message is encrypted and included as part of the localization algorithm message sent to the
recipient.

The AES (Advanced Encryption Standard) is in Appendix A.1.1 the symmetric cipher
algorithm that the NIST (National Institute of this memo.

1.3. Key Update

The TEXTUAL CONVENTION KeyChange, defined Standards and
Technology) has selected 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 four-year competitive process.

The AES homepage, http://www.nist.gov/aes, contains a localized key wealth of an
SNMP engine.
information on AES including the Federal Information Processing
Standard [FIPS-AES] that will finally specify the Advanced
Encryption Standard.

The TC still applies for user U when following subsections contain description of the protocol P is one relevant
characteristics of the AES ciphers used in the symmetric encryption
protocols described on in this memo. In this case the hash algorithm H
will be SHA256, and the size

3.1.1.1.Mode 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 operation

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 NIST Special Publication 800-38A [AES-MODE]recommends five
confidentiality modes of Object Identities needed operation for
the use of 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 by SNMP's User-based Security
Model."
REVISION "200110120000Z"
DESCRIPTION "Initial version, published as RFCnnnn"

::= { xxx nn } -- in
CFB mode with the parameter s set to 128 according 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 definition
of CFB mode given in [AES-MODE]. This mode requires a Initialization

Blumenthal/Maino/McCloghrie Expires August 2002 January 2003 [Page 6]
Internet Draft

Vector (IV) that is the same size as the block size of the cipher
algorithm.

3.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.

3.1.1.3.Block Size and Padding

The block size of the AES Cipher Algorithm cipher algorithms used 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 encryption
protocols described by this memo is 128 bits.

3.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 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 AES-128;
-12 rounds for the ADVANCED ENCRYPTION
STANDARD (DRAFT). Federal Information Processing
Standard (FIPS) Publication 197.
(November 2001).

- Dworkin, M., NIST Recommendation AES-192;
-14 rounds for Block
Cipher Modes of Operation, Methods AES-256

3.1.2.Localized Key, AES Encryption Key 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 Initialization Vector

The size of the ADVANCED ENCRYPTION
STANDARD (DRAFT). Federal Information Processing
Standard (FIPS) Publication 197
(November 2001).

- Dworkin, M., NIST Recommendation for Block
Cipher Modes Localized Key (Kul) 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 an SNMP user, as described in
[RFC2574], depends on 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 defined for that
user U at the draft of the Secure Hash Standard FIPS[FIPS-180-2], authoritative SNMP engine E.

3.1.2.1.Short Localized Keys

The encryption protocols defined on this memo SHOULD be used in HMAC
mode as described in [RFC2104], truncating the output to 96 bits.

This protocol is identified by usmHmacSha256AuthProtocol.

This protocol is with an alternative to the
authentication protocols
described in [RFC2574].

3.1. Mechanisms

- In support of data integrity, protocol that generates a message digest algorithm is
required. A digest is calculated over an appropriate portion of an
SNMP message and included localized key with enough
key material to derive a 128/192/256 bits encryption key, such as part of
the message sent to usmHmacSha256AuthProtocol.

However, if the
recipient.

- In support size of data origin authentication and data integrity, a
secret value the localized key is prepended not large enough to
generate an encryption key the SNMP message prior following algorithm is applied to computing
extend the
digest; localized key:
1)Let Hnnn() the calculated digest is then partially inserted into hash function of the
message prior to transmission. The prepended secret is not
transmitted. The secret value is shared by all SNMP engines
authorized to originate messages authentication protocol for
the user U on behalf of the appropriate user.

3.1.1. Digest Authentication Mechanism

The Digest Authentication Mechanism defined in this memo provides
for:

- verification SNMP authoritative engine E. nnn being the size
of the integrity output of a received message, i.e., that the message received hash function (e.g. nnn=128 bits for MD5, or
nnn=160 bits for SHA1).
2)Set c = ceil ( 384 / nnn )
3)For i = 1, 2, ..., c
a.Set Kul = Kul || Hnnn(Kul); Where Hnnn() is the message sent.

The integrity hash
function of the message is protected by computing a digest over authentication protocol defined for that user

As an appropriate portion of example if the message. The digest user authentication protocol is computed by
the originator of HMAC-SHA1-96,
the message, transmitted hash function Hnnn is SHA1 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 nnn=160 bits. The algorithm will
generate
messages on behalf of a user is used in HMAC mode (see [RFC2104]).
It also recommends localized key 480-bit long:

Kul' = Kul || SHA1(Kul) || SHA1(Kul||SHA1(Kul))

Blumenthal/Maino/McCloghrie Expires January 2003 [Page 7]

3.1.2.2.AES Encryption Key and IV

The first 128/192/256 bits of the hash-function output localized key Kul are used as Message
Authentication Code, the
AES encryption key, according to be truncated.

This mechanism uses the SHA256 [FIPS-180-2] message digest
algorithm. A 256-bit SHA256 digest AES cipher algorithm key size
of the encryption protocol used.
The 128-bit IV is calculated in a special
(HMAC) way over obtained as the designated portion concatenation of an the generating
SNMP message and engine's 32-bit snmpEngineBoots, the
first 96 bits of this digest SNMP engine's 32-bit
snmpEngineTime, and a local 64-bit integer. The 64-bit integer is included
initialized to an arbitrary value at boot time.

The IV is concatenated as part of follows: the message sent 32-bit snmpEngineBoots is
converted to the recipient. The size of first 4 octets (Most Significant Byte first), the digest carried in a message
32-bit snmpEngineTime is 12
Blumenthal,
Maino, McCloghrie Expires August 2002 [Page 8]
Internet Draft The AES Cipher Algorithm in converted to the February 2002
SNMP's User-based Security Model

octets. The size of subsequent 4 octets (Most
Significant Byte first), and the private authentication key (the secret) 64-bit integer is
32 octets. For then converted to
the details see section 3.3.

3.1.1.1. Localized Key and Private Authentication Key

The last 32 8 octets (256 bits) of the Localized Key Kul, generated
from the SNMP user password and (Most Significant Byte first).

The 64-bit integer is then put into the snmpEngineID privParameters field encoded
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 an OCTET STRING of length 8 octets. The integer is then modified
for the HMAC-SHA256-96 Authentication Protocol

This section contains definitions required to realize subsequent message. We recommend that it be incremented by
one and wrap when it reaches 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 maximum value.

How exactly the value of userNames. For any user on whose behalf the IV varies is an implementation issue,
as long as measures are taken to avoid producing a message duplicate IV.

The 64-bit integer must be authenticated at a particular SNMP engine, that SNMP engine
must have knowledge of that user. An SNMP engine that wishes placed in the privParameters field to
communicate with another SNMP engine must also have knowledge of a
user known
enable the receiving entity to that engine, including knowledge of compute the applicable
attributes of that user.

A user correct IV and its attributes are defined as follows:

<userName>
A string representing the name of to decrypt
the user.
<authKey>
A user's secret key message.

3.1.3.Data Encryption.

The data to be used when calculating a digest.
It MUST be 32 octets long for SHA256.

3.2.2. msgAuthoritativeEngineID encrypted is treated as sequence of octets.

The msgAuthoritativeEngineID value contained data is encrypted in an authenticated
message specifies Cipher Feedback mode with the authoritative SNMP engine for that particular
message (see parameter s
set to 128 according to the definition of SnmpEngineID CFB mode given in the SNMP Architecture
document [RFC2571]). [AES-
MODE].

The user's (private) authentication key plaintext is normally different at
each authoritative SNMP engine divided into 128-bit blocks. The last block may
have less than 128 bits, and so the snmpEngineID is used to
select no padding is required.

The first input block is the proper key for IV, and the authentication process.

3.2.3. SNMP Messages Using this Authentication Protocol

Messages using this authentication protocol carry a
msgAuthenticationParameters field as part of forward cipher operation is
applied to the
msgSecurityParameters. For this protocol, IV to produce the
msgAuthenticationParameters field first output block. The first
ciphertext block is produced by exclusive-ORing the serialized OCTET STRING
representing first plaintext
block with the first 12 octets of HMAC-SHA256-96 output done over
the wholeMsg.
Blumenthal,
Maino, McCloghrie Expires August 2002 [Page 9]
Internet Draft block. The AES Cipher Algorithm in ciphertext block is also used
as the February 2002
SNMP's User-based Security Model input block for the subsequent forward cipher operation.

The digest process is calculated over repeated with the wholeMsg so if successive input blocks until a message
ciphertext segment 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 produced from every plaintext segment.

Blumenthal/Maino/McCloghrie Expires January 2003 [Page 8]

The last ciphertext block is produced by exclusive-ORing the HMAC-SHA256-96 Authentication Module

This section describes last
plaintext segment of r bits (r is less or equal to 128) with the inputs and outputs that
segment of the HMAC-SHA256-
96 Authentication module expects and produces when r most significant bits of the User-based
Security module calls last output block.

3.1.4.Data Decryption

In CFB decryption, 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 IV is the selection of first input block, the authKey first
ciphertext is done by used for the caller and that second input block, the caller passes second ciphertext
is used for the
secret key third input block, etc. The forward cipher function
is applied to be used.

Upon completion each input block to produce the authentication module returns statusInformation
and, if the message digest was correctly calculated, the wholeMsg output blocks. The
output blocks are exclusive-ORed with the digest inserted at corresponding ciphertext
blocks to recover the proper place. plaintext blocks.

The abstract service
primitive is:

statusInformation = -- success last ciphertext block (whose size r is less or failure
authenticateOutgoingMsg(
IN authKey -- secret key for authentication
IN wholeMsg -- unauthenticated complete
message
OUT authenticatedWholeMsg -- complete authenticated 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.

3.2.Elements of the AES Privacy Protocols

This section contains definitions required to realize the privacy
modules defined by this memo.

3.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
)
The abstract data elements are:

statusInformation must be en/decrypted at a particular SNMP engine, that SNMP
engine must have knowledge of that user. An indication 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 whether the authentication process was
successful. If not it is an indication
applicable attributes of that user.

A user and its attributes are defined as follows:

<userName>
An octet string representing the name of the problem.
authKey
The user.

<privKey>
A user's secret key to be used by as the authentication algorithm. AES key.
The length of this key MUST be 32 octets.
wholeMsg
The message to be authenticated.
authenticatedWholeMsg be:
- 128 bits (16 octets) for AES-128
- 192 bits (24 octets) for AES-192
- 254 bits (32 octets) for AES-256

3.2.2.msgAuthoritativeEngineID

The msgAuthoritativeEngineID value contained in an authenticated
message (including inserted digest) on output.

Note, that authParameters field is filled by specifies the authentication
module and this field should be already present in authoritative SNMP engine for that particular
message (see the wholeMsg
before definition of SnmpEngineID in the Message Authentication Code (MAC) is generated.

3.2.4.2. Services for Processing an Incoming SNMP Message

Blumenthal,
Maino, McCloghrie Architecture
document [RFC2571]).

Blumenthal/Maino/McCloghrie Expires August 2002 January 2003 [Page 10]
Internet Draft 9]

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.

3.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.

3.2.4.Services provided by the AES Cipher Algorithm in Privacy Modules

This section describes the inputs and outputs that the AES Privacy
modules expects and produces when the February 2002
SNMP's User-based Security Model

HMAC-SHA256-96 authentication protocol assumes module
invokes one of the AES Privacy modules for services.

3.2.4.1.Services for Encrypting Outgoing Data

The AES privacy protocols assume that the selection of the authKey privKey
is done by the caller and that the caller passes the secret key to
be used.

Upon completion the authentication privacy module returns statusInformation and, if
the message digest encryption process was correctly calculated, successful, the encryptedPDU and the wholeMsg
msgPrivacyParameters encoded as
it was processed. an OCTET STRING. The abstract
service primitive is:

statusInformation = -- success or failure
authenticateIncomingMsg(
encryptData(
IN authKey encryptKey -- secret key for authentication encryption
IN authParameters dataToEncrypt -- as received on the wire
IN wholeMsg data to encrypt (scopedPDU)
OUT encryptedData -- as received on the wire encrypted data (encryptedPDU)
OUT authenticatedWholeMsg privParameters -- complete authenticated
message filled in by service provider
)

The abstract data elements are:

statusInformation
An indication of whether the authentication process was
successful. If not success or failure of the encryption
process. In case of failure, it is an indication of the problem.
authKey error.
encryptKey
The secret key to be used by the authentication encryption algorithm.
The length of this key MUST be 32 octets.
authParameters
The authParameters from the incoming message.
wholeMsg 16/24/32 octets for AES
128/192/256.
dataToEncrypt
The message to data that must be authenticated on input and the authenticated
message on output.
authenticatedWholeMsg encrypted.
encryptedData
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) encrypted data upon successful completion.
privParameters
The msgAuthenticationParameters field is set to the
serialization, according to the rules in [RFC1906], of privParameters encoded as 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 STRING.

Blumenthal/Maino/McCloghrie Expires August 2002 January 2003 [Page 11]
Internet Draft The AES Cipher Algorithm in the February 2002
SNMP's User-based Security Model

b) obtain IPAD by replicating 10]

3.2.4.2.Services for Decrypting Incoming Data

This DES privacy protocol assumes that the octet 0x36 64 times;
c) obtain K1 by XORing extendedAuthKey with IPAD;
d) obtain OPAD by replicating selection of the octet 0x5C 64 times;
e) obtain K2 privKey
is done by XORing extendedAuthKey with OPAD.

3) Prepend K1 to the wholeMsg caller and calculate the SHA256 digest over
it according to [FIPS-180-2].

4) Prepend K2 to that the result of caller passes the step 4 and calculate SHA256
digest over it according secret key to [FIPS-180-2]. Take
be used.

Upon completion the first 12 octets
of privacy module returns statusInformation and, if
the final digest - this is Message Authentication Code (MAC).

5) Replace decryption process was successful, the msgAuthenticationParameters field with MAC obtained scopedPDU in the step 4.

6) plain text.
The authenticatedWholeMsg is then returned to abstract service primitive is:

statusInformation =
decryptData(
IN decryptKey -- secret key for decryption
IN privParameters -- as received on the caller together
with wire
IN encryptedData -- encrypted data (encryptedPDU)
OUT decryptedData -- decrypted data (scopedPDU)
)

The abstract data elements are:

statusInformation indicating success.

3.3.2. Processing
An indication whether the data was successfully decrypted
and if not an Incoming Message

This section describes indication of the procedure followed error.
decryptKey
The secret key to be used 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

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 decryption algorithm.
The length of this key algorithm, which can MUST be 16/24/32 octets for AES
128/192/256.
privParameters
The 64-bit integer to be used when mapping an SNMP user password to a localized key using SHA256. calculate the IV.
encryptedData
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 data to snmpEngineID */
u_int engineLength,/* IN - length be decrypted.
decryptedData
The decrypted data.

3.3.Elements 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 Procedure.

This section describes 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; procedures for (i = 0; i < 64; i++) {
/*************************************************/
/* Take the next octet of AES privacy protocols.

3.3.1.Processing an Outgoing Message

This section describes the engineID, wrapping */
/* to procedure followed by an SNMP engine
whenever it must encrypt part of an outgoing message using the beginning
usmAesCfbxxxPrivProtocol (where xxx can be any of 128, 192, or 256).

1)The secret cryptKey is used to construct the engineID AES encryption key,
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 described in section .

2)The privParameters field is set to the password, wrapping */
/* serialization according to
the beginning rules in [RFC1906] of an OCTET STRING representing the password the
64-bit integer that will be used in the IV as necessary.*/
Blumenthal,
Maino, McCloghrie described in

Blumenthal/Maino/McCloghrie Expires August 2002 January 2003 [Page 22]
Internet Draft The AES Cipher Algorithm 11]

3)The scopedPDU is encrypted (as described in section ) and the
encrypted data is serialized according to the rules in [RFC1906]
as an OCTET STRING.

4)The serialized OCTET STRING representing 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 encrypted scopedPDU
together with the privParameters and statusInformation
indicating success is returned to the calling module.

3.3.2.Processing an Incoming Message

This section describes the procedure followed by an SNMP engine
whenever it must decrypt part of localized key */
memcpy(key+(id*64), buf, 64);
}

return;
}

A.2 Password to Key Sample Results

The following shows a sample output an incoming message using the
usmAesCfbxxxPrivProtocol (where xxx can be any of 128, 192, or 256).

1)If the password privParameters field is not an 8-octet OCTET STRING, then
an error indication (decryptionError) is returned to key algorithm
using SHA256 as hash function.

Let's assume the user U has calling
module.

2)The 64-bit integer is extracted from the password "maplesyrup" privParameters field.

3)The secret cryptKey and the
snmpEngineID is 64-bit integer are then used to
construct the OCTECT STRING:

'00000000 00000000 00000002'H

Then AES decryption key and the user password IV that is concatenated computed as
described in the 512-bit long string
P_512:

"maplesyrupmaplesyrupmaplesyrupmaplesyrupmaplesyrupmaplesyrupmapl"

The snmpEngineID section . [??? this should be aligned with 4.1.2.2]

4)The encryptedPDU is concatenated then decrypted (as described in section ).

5)If 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 encryptedPDU cannot be decrypted, then an error indication
(decryptionError) is returned to the hash computation with calling module.

6)The decrypted scopedPDU and statusInformation indicating success
are returned to the diversifier ID=1 is calling module.

4.Security Considerations

Implementations are encouraged to use the
value:

enc_256 = '97a44030 8b7042c4 d7fc1779 daeca6c1 27681f23 2a205666
f2a58cf3 c35d9206'H

The result 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 hash computation with foreseeable future.

Because the diversifier ID=2 AES algorithm is relatively new and has only undergone
limited cryptographic analysis, its use in SNMPv3 USM
implementations should be considered experimental. At the
value:

preIV_256 = 'fb5ccedc c7e7a95d 388d4efe a45d26dc 5c5edf41 a83735ae
ea294e64 690d4f6b'H

The result
recommendation of cryptographic experts, we will recommend that the hash computation with the diversifier ID=3 is
IESG include usmAesCfb128PrivProtocol within the
value:
Blumenthal,
Maino, McCloghrie 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].

Blumenthal/Maino/McCloghrie Expires August 2002 January 2003 [Page 23]
Internet Draft The AES Cipher Algorithm in 12]

For further security considerations, the February 2002
SNMP's User-based Security Model

int_256 = 'a15acac2 0a12a73f 00db7410 61350d15 07e58d25 17359a35
2b0533f9 34a026a7'H

The localized key Kul reader is encouraged to
read 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 documents that a user has a current password of "maplesyrup" as
in section A.2. and let us also assume describe the snmpEngineID of 12
octets:

'00000000 00000000 00000002'H

If we now want actual cipher algorithms.

5.Intellectual Property Rights Statement

Pursuant to change the password to "newsyrup", then we first
calculate provisions of [RFC2026], the localized key for authors represent that
they have disclosed 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 existence of any proprietary or intellectual
property rights in the 768-bit long Kul contribution that can be used are reasonably and
personally known 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 authors. The authors do not represent that
they personally know of all potentially pertinent proprietary and
intellectual property rights owned or claimed by the new
authentication key is organizations
they represent or third parties.

The IETF takes no position regarding the last 256 bits validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the new localized key
Kul:

newkey = 'e3121e80 d653f276 4d135697 10320f89 25484d17 62aafd88
4c5e0838 df40597c'H

If we then implementation or use a (not so good, but easy to test) random value of:

'00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000'H

Then of the value "delta" we must send for authentication keyChange is:

'd9d91e39 76a96666 1e4643d5 870bf8db 64d59f15 4830fa14 14a79a1c
0ceceb9c'H

Similarly technology described in
this document or the keyChange 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 sent found in order BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to update be made available, or the
privacy Key result of an attempt made
to obtain a general license or permission for the usmAesCfb128PrivProtocol is use of such
proprietary rights by implementers or users of this specification
can be obtained from the new
privacy key derived IETF Secretariat.

6.Acknowledgements

Portions of this text, as well as its general structure, were
unabashedly lifted from Kul (the first 384 bits [RFC2574].

7.References

Normative References

[AES-MODE] Dworkin, M., "NIST Recommendation for Block Cipher Modes
of Operation, Methods and Techniques", NIST Special
Publication 800-38A, December 2001.

[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

Blumenthal/Maino/McCloghrie Expires January 2003 [Page 13]

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.

Informative References

[CRYPTO-B] Bellovin, S., "Probable Plaintext Cryptanalysis of Kul):
Blumenthal,
Maino, McCloghrie Expires August 2002 [Page 24]
Internet Draft The AES Cipher Algorithm in the February 2002
SNMP's User-based
IP 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 Protocols", Proceedings of 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 Symposium on
Network and Distributed System Security, San Diego, CA,
pp. 155-160, February 1997.

8.Authors 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

A.1.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

Blumenthal/Maino/McCloghrie Expires January 2003 [Page 14]

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

Full Copyright Statement

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

Blumenthal/Maino/McCloghrie Expires August 2002 January 2003 [Page 15]

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.

Blumenthal/Maino/McCloghrie Expires January 2003 [Page 25] 16]
----