[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 RFC 3826

   Internet Draft                                         U. Blumenthal
   draft-blumenthal-aes-usm-04.txt                  Lucent Technologies
   Expires: April 2003                                         F. Maino
                                                  Andiamo Systems, Inc.
                                                          K. McCloghrie
                                                    Cisco Systems, Inc.
                                                           October 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.

   Copyright (C) The Internet Society (2002).  All Rights Reserved.


Abstract

   This document describes a set of 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 symmetric encryption protocols described in this
   document are based on the AES cipher algorithm [FIPS-AES], used in
   Cipher FeedBack Mode (CFB), with key size of 128 (mandated), 192,
   and 256 bits.

Table of Contents

   1. Introduction....................................................2
      1.1. Goals and Constraints......................................2
      1.2. Key Localization...........................................3
      1.3. Password Entropy and Storage...............................3

   Blumenthal/Maino/McCloghrie Expires April 2003                [Page 1]


   2. Definitions.....................................................3
   3. CFB128-AES-128/192/256 Symmetric Encryption Protocols...........5
      3.1. Mechanisms.................................................5
         3.1.1. The AES-based Symmetric Encryption Protocols..........6
         3.1.2. Localized Key, AES Encryption Key and Initialization
         Vector.......................................................7
         3.1.3. Data Encryption.......................................8
         3.1.4. Data Decryption.......................................8
      3.2. Elements of the AES Privacy Protocols......................9
         3.2.1. Users.................................................9
         3.2.2. msgAuthoritativeEngineID..............................9
         3.2.3. SNMP Messages Using this Privacy Protocol.............9
         3.2.4. Services provided by the AES Privacy Modules..........9
      3.3. Elements of Procedure.....................................11
         3.3.1. Processing an Outgoing Message.......................11
         3.3.2. Processing an Incoming Message.......................11
   4. Security Considerations........................................12
   5. Intellectual Property Rights Statement.........................12
   6. Acknowledgements...............................................13
   7. References.....................................................13
   8. Authors Addresses..............................................13
   Appendix A........................................................14
      A.1.Sample Results of Extension of Localized Keys..............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
   concurrently with these protocols.

   This memo describes 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
   the new authentication protocol.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in [RFC2119].

1.1.Goals and Constraints

   The main goals of this memo are as follows.
   1)Provide a set of new privacy protocols for USM based on the
     Advanced Encryption Standard.



lumenthal/Maino/McCloghrie  Expires April 2003                  [Page 2]


   2)Provide a key localization mechanism that generates an adequate
     amount of key material for the privacy protocols.


   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, the AES-based privacy protocols MAY be used with
   the authentication protocols described in [RFC2574].
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 consequently only one pair of keys) for the whole network, the
   actual secrets shared between the user and each authoritative SNMP
   engine will be different. This is achieved by key localization.

   If the authentication protocol defined for a user U at the
   authoritative SNMP engine E is one of the authentication protocols
   defined on [RFC2574], the key localization is performed according to
   the two steps process described in section 2.6 of [RFC2574].


1.3.Password Entropy and Storage

   The security of various cryptographic functions lies both in the
   strength of the functions themselves against various forms of
   attack, and also, perhaps more importantly, in the keying material
   that is used with them.  While theoretical attacks against the
   cryptographic functions specified by this document are possible, it
   is vastly more probable that key guessing is the main threat.

   The following can be suggested with regard to the user password:
   - Passwords lengths SHOULD be at least 12 bytes.
   - Password sharing SHOULD be limited so that 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 localization will not help and
   network security may be compromised in this case. Therefore a user's
   password or non-localized key MUST NOT be stored on a managed
   device/node. Instead the localized key SHALL be stored (if at all),
   so that, in case a device does get compromised, no other managed or
   managing devices get compromised.

2.Definitions

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

   IMPORTS
       MODULE-IDENTITY, OBJECT-IDENTITY      FROM SNMPv2-SMI

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


       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 use of AES by SNMP's User-based Security
                     Model."
       REVISION     "200110120000Z"
       DESCRIPTION  "Initial version, published as RFCnnnn"

       ::= { xxx nn }          -- to be assigned by TBD


   snmpUsmAesProtocols OBJECT IDENTIFIER ::= { snmpUsmAesMIB 1 }

   -- Identification of Privacy Protocols


   usmAesCfb128Protocol OBJECT-IDENTITY
       STATUS        current
       DESCRIPTION  "The CFB128-AES-128 Privacy Protocol."
       REFERENCE    "- Specification for the ADVANCED ENCRYPTION
                       STANDARD (DRAFT). Federal Information Processing
                       Standard (FIPS) Publication 197.
                       (November 2001).

                     - Dworkin, M., NIST Recommendation for Block
                       Cipher Modes of Operation, Methods and
                       Techniques (DRAFT).
                       NIST Special Publication 800-38A
                       (December 2001).

Blumenthal/Maino/McCloghrie  Expires April 2003                  [Page 4]


                    "
       ::= { snmpUsmAesProtocols 2 }

   usmAesCfb192Protocol OBJECT-IDENTITY
       STATUS        current
       DESCRIPTION  "The CFB128-AES-192 Privacy Protocol."
       REFERENCE    "- Specification for the ADVANCED ENCRYPTION
                       STANDARD (DRAFT). Federal Information Processing
                       Standard (FIPS) Publication 197.
                       (November 2001).

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

   usmAesCfb256Protocol OBJECT-IDENTITY
       STATUS        current
       DESCRIPTION  "The CFB128-AES-256 Privacy Protocol."
       REFERENCE    "- Specification for the ADVANCED ENCRYPTION
                       STANDARD (DRAFT). Federal Information Processing
                       Standard (FIPS) Publication 197
                       (November 2001).

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

   END

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

3.1.Mechanisms


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


   - 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 and a 64-bit
   integer 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.

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

   The following subsections contain description of the relevant
   characteristics of the AES ciphers used in the symmetric encryption
   protocols described in this memo.

3.1.1.1.Mode of operation

   The NIST Special Publication 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.

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



Blumenthal/Maino/McCloghrie  Expires April 2003                  [Page 6]


   The block size of the AES cipher algorithms used in the 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 AES-128;
   -12 rounds for AES-192;
   -14 rounds for AES-256

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

3.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. At the
   time of this writing an authentication protocol with such
   characteristics has not been defined within the USM model for the
   SNMPv3 architecture.

   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:
   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 bits for MD5, or
      nnn=160 bits for SHA1).
   2)Set c = ceil ( 256 / 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 bits. The algorithm will
   generate a localized key 480-bit long:

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

3.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-bit 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 a pseudo-random value at boot time.

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


   The IV is concatenated 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 msgPrivacyParameters 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 measures are taken to avoid producing a duplicate IV.

   The 64-bit integer must be placed in the msgPrivacyParameters field
   to enable the receiving entity to compute the correct IV and to
   decrypt the message.

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

   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.

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




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


   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.

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

3.2.2.msgAuthoritativeEngineID

   The msgAuthoritativeEngineID value contained in an authenticated
   message specifies the authoritative SNMP engine for that particular
   message (see the definition of SnmpEngineID in the SNMP Architecture
   document [RFC2571]).

   The user's (private) 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 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.

Blumenthal/Maino/McCloghrie  Expires April 2003                  [Page 9]


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

3.2.4.2.Services for Decrypting Incoming Data

   This AES 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)
           )

Blumenthal/Maino/McCloghrie  Expires April 2003                 [Page 10]


   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.

3.3.Elements of Procedure.

   This section describes the procedures for the AES privacy protocols.

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

   1)The secret cryptKey is used to construct the AES encryption key,
       as described in section .

   2)The privParameters field is set to the serialization according to
       the rules in [RFC1906] of an OCTET STRING representing the 64-
       bit integer that will be used in the IV as described in

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


Blumenthal/Maino/McCloghrie  Expires April 2003                 [Page 11]


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

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

   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.

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

   At the recommendation of cryptographic experts, we will recommend
   that the IESG include usmAesCfb128PrivProtocol 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.

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


Blumenthal/Maino/McCloghrie  Expires April 2003                 [Page 12]


6.Acknowledgements

   Portions of this text, as well as its general structure, were
   unabashedly lifted from [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
               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 the
               IP Security Protocols", Proceedings of the 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

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


   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

   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 256-
   bit localized key (e.g. to have enough key material to generate a
   256-bit privKey for the usmAesCfb256PrivProtocol.

   Let's assume that the user U has a password of "maplesyrup" and that
   the key has 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 256-bit extended localized key will be generating applying the
   mechanism described in 1.2, using the SHA algorithm. The resulting
   extended localized key is:

   Kul = '6695febc 9288e362 82235fc7 151f1284 97b38f3f 505e07eb
   9af25568 fa1f5dbe'H

   Note that the last 64 bits of the result of the extended key
   algorithm have been truncated to obtain a Kul that is exactly 256-
   bit long.











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


   Full Copyright Statement

   Copyright (C) The Internet Society (2002).  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.


























lumenthal/Maino/McCloghrie  Expires April 2003                 [Page 15]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/