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


Russ,

By this argument are you saying that RSA Labs has incorrectly defined
RSA-OAEP?  Remember this method of transporting keys does not make any
statements about their indended usage.  Additionally, if this is to be a
check that needs to be made by programs it needs to be placed in the
documents as as explicit step.  I.e. part of the key unwrap algorithm
should be that the CEK algorithm and the KEK algorithm identifiers are
consistant with each other.  I don't believe that the Microsoft
implementations do this check, I can't say if others do or do not, but I
would not be supprised if they do not.  

Also please address the question I raised in #3 - should the CEK (hmac)
or KEK bulk algorithm (3DES, AES...) be the one used in the key
derivation process.

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 Housley, 
Russ
Sent: Wednesday, March 06, 2002 2:09 PM
To: jimsch(_at_)exmsft(_dot_)com
Cc: pgut001(_at_)cs(_dot_)aucKland(_dot_)ac(_dot_)nz; 
ietf-smime(_at_)imc(_dot_)org
Subject: RE: I-D ACTION:draft-ietf-smime-hmac-key-wrap-00.txt

Jim:

Once the key is unwrapped, we want the recipient to know that it is 
appropriate for use with the intended algorithm.  Some checks are 
obvious.  In Triple-DES, the key size must be either 128 bits or 192 
bits.  In AES, the the key size must be either 128 bits, 192 
bits, or 256 
bits.  Such checks are not so obvious with algorithms that 
allow a variable 
key size, like RC2 and HMAC.

The key wrap algorithm provides integrity of the keying 
material, so the 
recipient knows that the received key has not been modified.  
The way that 
the HMAC key wrap algorithms are defined, the recipient 
should know that 
the wrapped key is intended for use with HMAC.  I suppose 
that this feature 
could be lost if the structure that we have defined is copied 
for many 
other purposes.

Russ

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.