FW: Last Call: The AES Cipher Algorithm in the SNMP's User-based Security Model to Proposed Standard

FYI and possible reaction.

Thanks,
Bert 

-----Original Message-----
From: Steve Moulton [mailto:[email protected]]
Sent: vrijdag 28 maart 2003 18:28
To: [email protected]
Cc: [email protected]; [email protected]
Subject: RE: Last Call: The AES Cipher Algorithm in the SNMP's
User-based Security Model to Proposed Standard



Greetings,

Developers at SNMP Research (namely Matt Hecht <[email protected]> and
Brian Park <[email protected]>) 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