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

	See more inline, sorry for the delay in responding to you.

> -----Original Message-----
> From: Russ Housley [mailto:[email protected]] 
> Sent: Friday, September 24, 2004 4:41 PM
> To: Jean-Francois Mule; Steven M. Bellovin; 
> [email protected]; [email protected]
> Cc: Eduardo Cardona; Greg White; Oscar Marcia; Richard Woundy 
> @ Comcast; Eric Rosenfeld
> Subject: RE: [ipcdn] FW: DISCUSS: draft-ietf-ipcdn-bpiplus-mib-14
> 
> 
> Jean-Francois:
> 
> >--- 1. Syntax of docsBpi2CmPublicKey and range limitations:
[snip], the proposed resolution on issue #1 was fine with you.
> This is fine with me.


> >--- 2. Lack of strong encryption & authentication mechanism in DOCSIS
> >BPI+
[snip]
> >  Symmetric encryption:
> >  AES (AES128CbcMode, AES256CbcMode), 3DES, DES
> >  ^^^ new addition, optional to support

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

Yes. The following has been proposed:
 t3DES128EdeMode - equivalent to openssl's DES_ecb2_encrypt() two-key Triple-DES ECB
 t3DES128CbcMode - equivalent to openssl's DES_ede2_cbc_encrypt() two-key Triple-DES CBC

PS: as a separate note, should the IETF be defining a set of crypto MIB textual-conventions for the crypto libraries (like some of the ones in the openssl lib http://www.openssl.org/docs/crypto/crypto.html)?



[snip]


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


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

The following has been proposed:
HMAC-SHA1-96 and HMAC-SHA1-128


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


This response should close all the comments received from Russ. Let us know if this is good to go and we will draft the ID changes accordingly.

Jean-François