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

["Jean-Francois Mule" <[e-mail]>]

Russ, Steve and Bert,

  Thanks for your comments on draft-ietf-ipcdn-bpiplus-mib-14.
  To summarize, you expressed 2 main comments, see below a proposed
resolution.


Ipcdn folks:
  Feel free to interject and comment.


--- 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.


--- 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

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

 Data integrity algorithms: 
 SHA-1, SHA-256, MD5
 ^ new addition, optional to support 
 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.
 

Are these proposals to resolve your comments ok with you? 
Do you see any other possible algorithms we should consider for
inclusion? Any one we should remove? 
Once we have your blessing on the above, Eduardo or I will propose the
exact text modifications for the Internet-Draft (we probably need to add
some text in the description clauses, compliance statement, the security
consideration section, references, etc.)


Let us know if this message addresses those IESG comments. Special
thanks all the folks in cc: for their input on this thread. Any
additional comments, please include the ipcdn list.

Thanks,
Jean-Francois 
IPCDN co-chair

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