[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Last Call: The AES Cipher Algorithm in the SNMP's User-basedSecurity Model to Proposed Standard
Greetings,
Developers at SNMP Research (namely Matt Hecht <hecht@snmp.com> and
Brian Park <park@snmp.com>) have encountered some issues
with draft-blumenthal-aes-usm-05.txt that should be addressed before
the document proceeds.
1) It would be very helpful to have a worked example, showing
the construction of the initialization vector and
the input and output of the encryption for a short message.
This is very helpful in verifying an implementation before
going to interoperability testing. It would be unnecessary
to show key construction and localization steps, as those
are very well covered in RFC3414.
2) In section 3.1.1, the text implies that the document specifying
AES has not been published. Either I misunderstand
http://www.nist.gov/aes, or it appears that the document
has been published as FIPS 197.
3) Several editorial changes are noted below.
Since FIPS 197 gives 192 and 256 bit encryption algorithms, it would
have been helpful to have the document address the key extensions. I
anticipate that there will be implementations using longer
key lengths; addressing them in this document would help address
interoperability.
These concern aside, the developers feel that this is a useful and
well-written document.
Best Regards,
Steve Moulton
----------------------------------------------------------------------
Note:
I was unsure of the edit in section 1.3 below (changing
"parameter s" to "parameters", but was unable to find a
parameter "s" in FIPS 800-38B.
--- /home6/moulton/ids/draft-blumenthal-aes-usm-05.txt Fri Mar 7 13:51:00 2003
+++ aes-draft-edits Thu Mar 27 17:18:02 2003
@@ -38,12 +38,12 @@
Abstract
This document describes a symmetric encryption protocol that
- supplement the protocols described in the User-based Security
+ supplements the protocols described in the User-based Security
Model (USM), which is a Security Subsystem for version 3 of the
Simple Network Management Protocol for use in the SNMP
Architecture. The symmetric encryption protocol described in this
document is based on the AES cipher algorithm, used in Cipher
- FeedBack Mode (CFB), with key size of 128 bits.
+ FeedBack Mode (CFB), with a key size of 128 bits.
Table of Contents
@@ -102,7 +102,7 @@
USM based on the Advanced Encryption Standard.
The major constraint is to maintain a complete interchangeability of
- the new protocol defined on this memo with existing authentication
+ the new protocol defined in this memo with existing authentication
and privacy protocols already defined in USM.
For a given user, the AES-based privacy protocol MAY be used with
@@ -125,8 +125,8 @@
If the authentication protocol defined for a user U at the
authoritative SNMP engine E is one of the authentication protocols
- defined on [RFC3414], the key localization is performed according to
- the two steps process described in section 2.6 of [RFC3414].
+ defined in [RFC3414], the key localization is performed according to
+ the two step process described in section 2.6 of [RFC3414].
1.3 Password Entropy and Storage
@@ -139,11 +139,11 @@
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 lengths SHOULD be at least 12 bytes.
- Password sharing SHOULD be limited so that passwords aren't shared
among multiple SNMP users.
- It is worth to remember that, as specified in [RFC3414], if user's
+ It is worth to remember that, as specified in [RFC3414], if a 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
@@ -235,15 +235,15 @@
Codebook (ECB), Cipher Block Chaining (CBC), Cipher Feedback (CFB),
Output Feedback (OFB), and Counter (CTR).
- The symmetric encryption protocol described in this memo use AES in
- CFB mode with the parameter s set to 128 according to the definition
+ The symmetric encryption protocol described in this memo uses AES in
+ CFB mode with the parameters set to 128 according to the definition
of CFB mode given in [AES-MODE]. This mode requires an
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 protocol described by this memo AES is used with
+ In the encryption protocol described by this memo AES is used with a
key size of 128 bits.
3.1.1.3 Block Size and Padding
@@ -254,7 +254,7 @@
3.1.1.4 Rounds
This parameter determines how many times a block is encrypted. The
- encryption protocol described on this memo uses 10 rounds.
+ encryption protocol described in this memo uses 10 rounds.
3.1.2 Localized Key, AES Encryption Key and Initialization Vector
@@ -262,8 +262,8 @@
[RFC3414], depends on the authentication protocol defined for that
user U at the authoritative SNMP engine E.
- The encryption protocol defined on this memo MUST be used with an
- authentication protocol that generates a localized key with of at
+ The encryption protocol defined in this memo MUST be used with an
+ authentication protocol that generates a localized key with at
least 128 bits. The authentication protocols described in [RFC3414]
satisfy the requirement above.
@@ -298,12 +298,12 @@
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. This 64-bit value is called "salt" in this document.
+ the message. This 64-bit value is called the "salt" in this document.
See RFC 3414.
3.1.3 Data Encryption.
- The data to be encrypted is treated as sequence of octets.
+ The data to be encrypted is treated as a 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-
@@ -388,7 +388,9 @@
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
+ modules expect and produce when the User-based Security module
+ -or-
+ module expects and produces when the User-based Security module
invokes one of the AES Privacy modules for services.
3.2.4.1 Services for Encrypting Outgoing Data