RE: [ipcdn] FW: DISCUSS: draft-ietf-ipcdn-bpiplus-mib-14
"Eduardo Cardona" <e.cardona@CableLabs.com> Thu, 23 September 2004 16:57 UTC
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00990 for <ipcdn-archive@ietf.org>; Thu, 23 Sep 2004 12:57:49 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAX1b-0004Tt-Oo for ipcdn-archive@ietf.org; Thu, 23 Sep 2004 13:04:56 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAWhr-0001F7-7k; Thu, 23 Sep 2004 12:44:31 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAWYC-0005nZ-DN for ipcdn@megatron.ietf.org; Thu, 23 Sep 2004 12:34:33 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28279 for <ipcdn@ietf.org>; Thu, 23 Sep 2004 12:34:29 -0400 (EDT)
Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAWex-0003aK-0O for ipcdn@ietf.org; Thu, 23 Sep 2004 12:41:35 -0400
Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id i8NGXskH002381; Thu, 23 Sep 2004 10:33:54 -0600 (MDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [ipcdn] FW: DISCUSS: draft-ietf-ipcdn-bpiplus-mib-14
Date: Thu, 23 Sep 2004 10:33:54 -0600
Message-ID: <5259D0D7419C6149B347837A2E64F46F03E8F8@srvxchg.cablelabs.com>
Thread-Topic: [ipcdn] FW: DISCUSS: draft-ietf-ipcdn-bpiplus-mib-14
Thread-Index: AcShZ6uO0bvYOCs/T0eA+x9m9M2IsAAGpqfg
From: Eduardo Cardona <e.cardona@CableLabs.com>
To: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>, "Ipcdn (E-mail)" <ipcdn@ietf.org>
X-Approved: ondar
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e367d58950869b6582535ddf5a673488
Content-Transfer-Encoding: quoted-printable
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>, <mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>, <mailto:ipcdn-request@ietf.org?subject=subscribe>
Sender: ipcdn-bounces@ietf.org
Errors-To: ipcdn-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f
Content-Transfer-Encoding: quoted-printable
Bert, I am not sure if this is just perception from the parser output: Below is a similar public key pair that indicates the offsets line by line Ofsset 135 (zero based) indicates the start of the public exponent (5 bytes) Offset 140 indicates the offset of byte 141 Here is a 140 octets PKCS#1 public key pair Off 0 30 81 89 3 02 81 81 6 00 cf 32 d2 0b 31 d5 47 f9 73 98 8a 83 62 e1 fb 22 dc e6 3b 0b 4b b8 d6 3b 35 31 5d dc 7a 72 89 fe 38 e9 18 20 c7 83 7b 76 d7 75 36 91 72 f6 17 8f 5a 54 59 68 28 87 0d 9b 25 88 52 7b cb a2 52 10 26 89 70 69 4f 0d d1 d9 2d 71 aa 03 35 e2 81 5d b0 31 8b 86 4c 3d e9 0a df b4 8c e4 99 7f d1 47 86 5b 9e 3d 102 07 c3 a8 58 f3 2f f2 d3 09 a6 e3 e5 4c 53 23 44 118 46 6c 6b 03 ae 90 76 38 60 de 23 02 f9 c0 3b e4 134 ed 135 02 03 01 00 01 140 Bytes size = 3 + 3 + 129 + 5 = 140 And the output from for the equivalent binary file from openssl asn1parse command: 0:d=0 hl=3 l= 137 cons: SEQUENCE 3:d=1 hl=3 l= 129 prim: INTEGER :CF32D20B31D547F973988A8362E1FBDC E63B0B4BB8D63B35315DDC7A7289FEE9 1820C7837B76D775369172F6178F5A59 6828870D9B2588527BCBA25210268969 4F0DD1D92D71AA0335E2815DB0318B4C 3DE90ADFB48CE4997FD147865B9E3D07 C3A858F32FF2D309A6E3E54C53234446 6C6B03AE90763860DE2302F9C03BE4ED 135:d=1 hl=2 l= 3 prim: INTEGER :010001 > > I do not believe that a five (or even ten) specific sizes can be > chosen that accommodate all valid RSA public keys. DOCSIS uses a subset of moduli values that matches the sizes described by the MIB object After the explanations above, is this still an issue? > 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. I can't disclosure current spec work around DOCSIS protocols in IPCDN who includes persons probably not under CableLabs NDAs. Perhaps a reference to section 7.7 of BPI+ specification (available at http://www.cablelabs.com/specifications/archives/SP-BPI+_I10-030730.pdf ) will that be sufice by indicate the Protocol extensibility for strong algorithms which are highly recommended. 7.7 Supporting Alternative Algorithms The current BPI+ specification requires the use of 56-bit DES for encrypting packet data, two-key triple DES for encrypting traffic encryption keys, 1024-bit [RSA] for encrypting Authorization keys, and 1024-to-2048-bit [RSA] for signing BPI+ X.509 certificates. The choice of key lengths and algorithms, while appropriate for current threat models and hardware capabilities, may be inappropriate in the future. For example, it is generally agreed that DES is approaching the end of its practical usefulness as the industry standard for symmetric encryption. NIST is currently overseeing the development and adoption of a new standard encryption algorithm, commonly referred to as the Advanced Encryption Standard, or AES. Given the nature of the security services BPI+ is being asked to support (basic privacy at a level better than or equal to that possible over dedicated wires, and conditional access to RF data transport services) as well as the protocol's flexible key management policy (i.e., setting of key lifetimes), DOCSIS-based service providers will be justified in the continued reliance on DES for, at least, the next five years. Nevertheless, at some future date, DOCSIS Cable modems will need to adopt a stronger traffic encryption algorithm, possibly AES. Adopting a new algorithm for packet data encryption will not require a redesign of BPI+. The protocol's consistent use of Type/Length/Value encoding of BPKM attributes, MAC Header Extended Header elements, and security capabilities selection in the authorization exchange guarantee BPI+'s extensibility. In fact, changes in any of BPI+'s cryptographic algorithms, or associated key lengths, will have no impact on the overall structure and operation of the protocol. -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Thursday, September 23, 2004 6:12 AM To: Ipcdn (E-mail) Subject: [ipcdn] FW: DISCUSS: draft-ietf-ipcdn-bpiplus-mib-14 > COMMENT > > Please delete the second paragraph of the Abstract prior to publication > as an RFC. > > In the Abstract: s/DOCSIS1.1/DOCSIS 1.1/ OK Thanks Eduardo 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 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn
- [ipcdn] FW: DISCUSS: draft-ietf-ipcdn-bpiplus-mib… Wijnen, Bert (Bert)
- RE: [ipcdn] FW: DISCUSS: draft-ietf-ipcdn-bpiplus… Eduardo Cardona
- RE: [ipcdn] FW: DISCUSS: draft-ietf-ipcdn-bpiplus… Eduardo Cardona
- RE: [ipcdn] FW: DISCUSS: draft-ietf-ipcdn-bpiplus… Jean-Francois Mule
- RE: [ipcdn] FW: DISCUSS: draft-ietf-ipcdn-bpiplus… Russ Housley
- RE: [ipcdn] FW: DISCUSS: draft-ietf-ipcdn-bpiplus… Eduardo Cardona
- Re: [ipcdn] FW: DISCUSS: draft-ietf-ipcdn-bpiplus… Steven M. Bellovin
- RE: [ipcdn] FW: DISCUSS: draft-ietf-ipcdn-bpiplus… Jean-Francois Mule
- RE: [ipcdn] FW: DISCUSS: draft-ietf-ipcdn-bpiplus… Russ Housley
- RE: [ipcdn] FW: DISCUSS: draft-ietf-ipcdn-bpiplus… Jean-Francois Mule
- RE: [ipcdn] FW: DISCUSS: draft-ietf-ipcdn-bpiplus… Russ Housley