ietf-smime
[Top] [All Lists]

RE: I-D ACTION:draft-ietf-smime-hmac-key-wrap-00.txt

2002-02-26 17:41:16

After long discussions with Russ and Peter over the last week, I have
come up with the following list of items that need clarification.

1. How OIDs are assigned for key wrap algorithms.  Under the current
naming scheme the following items are identified by the assigned OID:
1) The exact key wrap algorithm to be used (including padding done to
the data), 2) The block encryption cipher applied during the key wrap
algorithm and 3) The purpose for which the embedded key is to be used.

2. Should a common key algorithm (including padding) be used for all
128-bit block cipher algorithms.  (i.e. should the AES and the HMAC key
wrap algorithm be identical including padding).

3. Should we update any current or existing documents based on any new
understandings that we arrive at.

COMMENTARY:

1.  I find that the third item in assign a key OID to be at present
insecure and and not really enforcable.  It is a feature which is not
currently present in PKCS#1 v1.5 and is far better covered for the DH
case by the fact that the CEK (i.e. destination) algorithm is used for
the KEK derivation process.  I was not really aware until I spoke to
Russ that the third item was even present in the OID definition and have
therefore never even thought to enforce it in my code in any way.  

2.  Russ, please address the following for me.  Is it really the CEK not
the KEK block encryption algorithm that should be protected during the
DH key derivation process?  If they are the same as is presently true it
is not an issue, but is of interest if you use an HMAC algorithm rather
than a CEK algorithm.

3.  I believe that there is an element of simplicity gained from having
a common key wrap algorithm for the AES key sizes.  I do not currently
believe that there is a benefit to breaking backwards compatablility to
achive the same effect with the 64-bit block size algorithms.

Conclusions:

I think that changing the OID assignment method should be looked at for
the 128-bit block algorithms, but we should not change our current
course for 64-bit block algorithms.  This does mean that we need to
change both AES-keywrap and HMAC-keywrap, but need input from the list,
from Russ and Peter and from NIST (the current AES key wrap algorithm
definers).

jim

-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org 
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Peter 
Gutmann
Sent: Saturday, February 16, 2002 12:08 AM
To: ietf-smime(_at_)imc(_dot_)org
Subject: RE: I-D ACTION:draft-ietf-smime-hmac-key-wrap-00.txt



"Jim Schaad" <jimsch(_at_)nwlink(_dot_)com> writes:

It is true that the wrapping algorithm in RFC 3211 exists 
and could be used
for the HMAC wrapping process.  However the pure Triple-DES 
wrap algorithm was
required to implement CMS, and it is still a required algorithm for
impliementing Diffie-Hellman key management in the cmsalg. 

... which virtually nothing implements.  Hardly a strong 
argument for using it.

Given that it is a required algorithm, it seems to be a good 
base to expand
on.

But it still has the problem that every single little 
variation requires a
completely new RFC to handle it, whereas the RFC 3211 wrap 
covers any algorithm
type and key combination.  You implement it once, and it 
works for everything.

(In fact the 3211 wrap is parameterised, something I added at 
your insistence,
 so there's no reason it can't be adapted to do whatever you need).

The AES key wrap algorithm is currently on track to become 
the standard key
wrap algorithm for use with AES.  Again, given that it is 
expected to be the
standard algorithm, it seems to be a good base to expand on.

It's yet another special-case variation which people have to 
implement.

I personally have some security reservations about the key 
wrap algorithm
given in RFC 3211. Triple-DES key wrap received significant 
peer review.
[etc]

See my private reply.

Peter.