RE: FW: DISCUSS: draft-ietf-ipcdn-bpiplus-mib-14
Russ Housley <[email protected]>
| Newsgroups | gmane.ietf.ipcdn |
|---|---|
| Message-ID | <[email protected]> |
Jean-Francois: > > >--- 2. Lack of strong encryption & authentication mechanism in DOCSIS > > >BPI+ >[snip] > > > Symmetric encryption: > > > AES (AES128CbcMode, AES256CbcMode), 3DES, DES > > > ^^^ new addition, optional to support Fine. >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 I seriously doubt that t3DES128EdeMode is useful in this context. ECB had some properties that are probably bad in this environment. >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)? I do not think this is needed. It certainly does not belong in this document. > > > 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 Fine. > > MD5 is certainly not a good thing to add at this point. >Ok. Good. Russ