[ipcdn] FW: DISCUSS: draft-ietf-ipcdn-bpiplus-mib-14

I am forwarding IESG comments as I receive them.

Answers are fine. Pls do not yet submit a changed document untill
we get ALL the IESG comments. Should be around Tuesday next week.

Bert

-----Original Message-----
From: Russ Housley [mailto:housley@vigilsec.com]
Sent: Wednesday, September 22, 2004 21:51
To: iesg@ietf.org
Subject: DISCUSS: draft-ietf-ipcdn-bpiplus-mib-14

Management Information Base for DOCSIS Cable Modems and Cable Modem Termination
Systems for Baseline Privacy Plus (Proposed Standard)

DISCUSS

   The definition of docsBpi2CmPublicKey begins:
   :
   :  docsBpi2CmPublicKey     OBJECT-TYPE
   :       SYNTAX             OCTET STRING (SIZE (74|106|140|204|270))
   :
   The selection of these few octet string sizes is inappropriate.
   PKCS #1 encoding of an RSA public key is a SEQUENCE of two
   INTEGERs.  One example of an acceptable RSA public key that
   cannot be accommodated by this definition follows.  It is 139
   octets.

        0 30  137: SEQUENCE {
        3 02  129:   INTEGER
                 :     00 DD D8 49 85 DD 76 BE 9C 64 D2 6A 0C B3 3A 14
                 :     0B 37 A5 60 97 90 40 3D C0 C6 9C 01 FB D0 6F B6
                 :     49 56 E5 1A 44 F7 C7 1D 23 4C 91 A2 6F BE F7 9A
                 :     D0 5F F0 88 9A 01 A2 0A 20 78 22 45 1A 9D 77 8F
                 :     CA 14 3E 75 44 3C D6 67 16 21 E5 42 B5 EC BF 62
                 :     6C 09 0E 4D D9 79 D0 55 82 5C 9C FD B1 B9 B6 A6
                 :     5B 42 83 FA 90 1E 74 3F 5C 1C 1F D8 73 40 94 3C
                 :     9A 9F 2A 04 FE ED 8C 69 C3 0E 10 A6 3B 0B A7 A4
                 :     CD
      135 02    3:   INTEGER 65537
                 :   }

   I do not believe that a five (or even ten) specific sizes can be
   chosen that accommodate all valid RSA public keys.

   The definition of docsBpi2CmtsAuthCmPublicKey has the same problem.

   The definition of docsBpi2CmTEKDataEncryptAlg begins:
   :
   :  docsBpi2CmTEKDataEncryptAlg   OBJECT-TYPE
   :       SYNTAX         INTEGER {
   :                              none(0),
   :                              des56CbcMode(1),
   :                              des40CbcMode(2)
   :                              }
   :
   And, the definition of docsBpi2CmTEKDataAuthentAlg begins:
   :
   : docsBpi2CmTEKDataAuthentAlg   OBJECT-TYPE
   :      SYNTAX         INTEGER {
   :                             none(0)
   :                             }
   :
   These same values are also used in the docsBpi2CmCryptoSuiteDataEncryptAlg,
   docsBpi2CmCryptoSuiteDataAuthentAlg, docsBpi2CmtsTEKDataEncryptAlg,
   docsBpi2CmtsTEKDataAuthentAlg, docsBpi2CmtsIpMulticastDataEncryptAlg,
   and docsBpi2CmtsIpMulticastDataAuthentAlg definitions.

   None of the encryption algorithm choices is a strong encryption
   algorithm.  Also, the encryption algorithm choice do not
   provide integrity, so they ought to be used with an integrity
   algorithm, but none are specified.  Can we get a strong
   encryption algorithm added to the list?  Can we get an strong
   integrity algorithm specified?  If not, the last few paragraphs of
   of the Security Considerations need to be made much more forceful.

   COMMENT

   Please delete the second paragraph of the Abstract prior to publication
   as an RFC.

   In the Abstract: s/DOCSIS1.1/DOCSIS 1.1/

_______________________________________________
IPCDN mailing list
IPCDN@ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn