[ipcdn] IESG review of: draft-ietf-ipcdn-bpiplus-mib-14.txt

["Wijnen, Bert (Bert)" <[e-mail]>]

OK, below is the complete set of IESG comments.

I know that discussion on the security issues is already underway.
Pls make sure to address both Steve Bellovin's and Russ' Housleys
DISCUSS comments.

Pls also take a look at the other comments.

And you may want to check statements like:

           ************************************************************
           * NOTES TO RFC Editor (to be removed prior to publication) *
           *                                                          *
           *     The I-D <draft-ietf-ipcdn-docs-rfmibv2-11.txt> (or a *
           * successor) is expected to eventually replace RFC 2670.   *
           * If that draft (or a successor) is published as an RFC    *
           * prior to or concurrently with this document, then the    *
           * normative reference [RFC2670] should be updated to       *
           * point to the replacement RFC, and the reference tag      *
           * [RFC2670] should be updated to match.                    *
           *                                                          *
           ************************************************************

cause I am not sure that that document is making real progress is it?

The IANA of course was concerned about the IANA considerations and
the assignment under ::= { docsIfMib yy }
I believe we agreed that this one can go underneath mib-2, right?

ANother nit I noticed:

       docsBpi2MIB    MODULE-IDENTITY
            LAST-UPDATED "200409071700Z" -- September 7th, 2004
            ORGANIZATION "IETF IP over Cable Data Network (IPCDN)
    >                     Working Group"
            CONTACT-INFO "---------------------------------------

you may want to remove that ">" sign at the beginning of line:
    >                     Working Group"

Bert
------------ IESG comments and dsicusses

Steve Bellovin:
Discuss:
[2004-09-24] The Security Considerations section says

    The time to crack DES could be additionally
    mitigated by a compromised value for the TEK lifetime and Grace Time
    (up to a minimum of 30 minutes for the TEK lifetime, see
    Appendix A [1]).

That's only partially correct.  These keys are confidentiality keys; they're still valuable even after they're no longer in active use, because they can be used to decrypt old traffic.  (By contrast, old authentication keys are useless to an attacker.)

Comment:
[2004-09-24] I concur in Russ' comments about the lack of any suitably strong crypto algorithms.  40-bit DES is, frankly, an embarrassment at this point.  Yes, I realize that DOCSIS isn't doing it right yet; that's no reason for us to do it wrong.  We should put the code points into the MIB now, and let them catch up.  But I'll let Russ hold that part of the DISCUSS (as well as the note that authentication algorithms are needed.)

Russ Housley:
Discuss:
[2004-09-23] 
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  135: SEQUENCE {
    3 02  129:  INTEGER
              :    00 B0 B3 67 A7 96 B5 76 83 E9 16 03 D9 1A A0 76
              :    D5 74 E7 9C 05 D2 51 3F DB 4F 19 A1 A8 39 4E CB
              :    24 7D 61 C4 1E 6A 20 AE 0F 81 DE EA B8 39 FD 1B
              :    1F 6B 36 40 ED 4D 21 25 F2 A3 D9 A1 51 D8 6C C0
              :    1B 96 F8 D4 42 94 D4 A7 CE 1B 8F D3 54 26 A2 84
              :    EF 32 85 AF 4A 3F F1 32 36 AF 3D E6 3A 27 EB 03
              :    C2 25 7E F4 61 2B AD 8A 1A 4B E6 9B 36 68 D4 2F
              :    E5 D2 88 94 DC 16 AA DA C2 15 4C 6C C3 E1 19 91
              :    C9
  135 02    1:  INTEGER 3
              :  }

  I do not believe that a five (or even ten) specific sizes can be
  chosen that accomodate 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:
[2004-09-22] 
  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
[e-mail]
https://www1.ietf.org/mailman/listinfo/ipcdn