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

[Russ Housley <[e-mail]>]

Jean-Francois:

>--- 1. Syntax of docsBpi2CmPublicKey and range limitations:
>    Per Eduardo and Rich's responses, the current object syntax of
>docsBpi2CmPublicKey is justified by the fact that DOCSIS BPI+ specifies
>a public modulus of 3 or 65537.
>Eduardo wrote:
> >  DOCSIS uses a subset of moduli values that matches the sizes
> > described by the MIB object.
>
>Rich added:
> > In general I am sure this is true, but for DOCSIS BPI+, a
> > specific public modulus is specified: 65537.
> >
> > Per
> > <http://www.cablemodem.com/downloads/specs/BPI+_I11-040407.pdf> >, 
> section 4.2.2.4 and elsewhere: "PKCS #1 v2.0 states that
> > the RSA public exponent may be standardized in specific
> > applications, and the document suggests values of 3 or 65537
> > (F4). Baseline Privacy Plus standardizes on F4 for a public
> > exponent and employs a 1024-bit modulus (Baseline Privacy
> > employed a 768-bit modulus)." Also see sections 7.5 and 7.6,
> > for example.
>
>Proposed resolution:
>   Even with the above justification, we (Rich and I) do not have any
>objection changing the syntax to not restrict the possible ranges in the
>MIB module. To allow the use of PCKS 4096 bits moduli, we (Eduardo,
>Oscar and I) would like to define the max limit to something like 524.
>The proposal is:
>
>    a) change the SYNTAX
>replace
><  docsBpi2CmPublicKey     OBJECT-TYPE
><       SYNTAX             OCTET STRING (SIZE (74|106|140|204|270))
>with
> >  docsBpi2CmPublicKey     OBJECT-TYPE
> >      SYNTAX             OCTET STRING (SIZE 0..524)
>
>    b) for existing 1.1 and 2.0 implementations, in the compliance
>statement, an OBJECT clause to say that DOCSIS 1.1 and 2.0 devices are
>not required to support any key with a size greater than 270.
>
>This proposal should suffice to address the comment: it adds flexibility
>in the generic object definition, yet reflects the reality of the
>underlying docsis 1.1 and 2.0 implementations and allow us to add a new
>compliance statement later for newer implementations without changing
>the mib definition. If this is not sufficient, let us know.

This is fine with me.

>--- 2. Lack of strong encryption & authentication mechanism in DOCSIS
>BPI+
>    The second comment raised by you both (Russ and Steve) is the lack of
>strong encryption & authentication mechanism in DOCSIS BPI+ and
>subsequently in the IPCDN DOCSIS BPI+ MIB module.
>    While the current DOCSIS specifications do not support any additional
>algorithms (and therefore, the underlying protocols supported by this
>MIB may not allow additional algorithm to be negotiated and used), we
>believe it is ok to add a couple of stronger encryption/auth algorithms
>for future use. Vendors may opt to support these additional algorithms
>and future DOCSIS specs may consider these for inclusion - TBD. In any
>case, today's implementations should reject any values outside the range
>allowed in docsis per standard error handling procedures so we don't see
>a pb with adding some better algo there.
>
>    Based on some input from Oscar Marcia, our chief security architect
>at CableLabs, Eric Rosenfeld, and Eduardo Cardona, we would like to
>propose that we add the following algorithms as optional to support:
>
>  Symmetric encryption:
>  AES (AES128CbcMode, AES256CbcMode), 3DES, DES
>  ^^^ new addition, optional to support

You need to specify a mode for 3DES too.  It will probably be CBC like the 
rest of the algorithms you support.

>  Public-key algorithms:
>  RSA (768, 1024, 2048, 3072 -bit key)

Okay.

>  Data integrity algorithms:
>  SHA-1, SHA-256, MD5
>  ^ new addition, optional to support

I expected HMAC-SHA-1.  This can be truncated as is done in IPsec.  Look at 
the HMAC-SHA1-96 definition for an example.

MD5 is certainly not a good thing to add at this point.

>  On the data integrity, as Eric and Oscar pointed out, please note that
>the MAC level protocol DOCSIS only support encryption today.
>Authentication is used on the key management messages and all DOCSIS
>Dynamic Service Flow DSA, DSC, and DSD exchanges, but the actual data
>transport security only uses encryption. So proposing authentication
>algorithms is a clear stretch based on the current protocol and
>implementations. That said, we would be ok with adding a couple for
>potential future use.
>
>
>   We would also like to add some text in the compliance statement of the
>MIB to specify what algs are mandatory to support for DOCSIS 1.1 and 2.0
>to eliminate any potential confusions.

Okay.

Russ 


_______________________________________________
IPCDN mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ipcdn