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

From: "Housley, Russ" <[email-masked]>
Date: Wed, 06 Mar 2002 17:09:23 -0500

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: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Peter Gutmann
> > Sent: Saturday, February 16, 2002 12:08 AM
> > To: [email-masked]
> > Subject: RE: I-D ACTION:draft-ietf-smime-hmac-key-wrap-00.txt
> >
> >
> >
> > "Jim Schaad" <[email-masked]> 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.
> >

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 8 Mar 2002 00:26:56 -0800

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

> [mailto:[email-masked]] On Behalf Of Housley, Russ
> Sent: Wednesday, March 06, 2002 2:09 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]

---

From: "Housley, Russ" <[email-masked]>
Date: Fri, 08 Mar 2002 10:50:30 -0500

>would not be supprised if they do not.

No.  Neither PKCS#1 v1.5 nor OAEP provides key type information inside the 
wrapping.  My understanding is that this was done to avoid structure that 
would be helpful to in a cryptanalytic attack.  This does not bean that the 
unwrapped key should not be checked for consistency with the expected 
outcome.  I was suggesting that key size and parity (for Triple-DES) are 
reasonable checks.

Perhaps I was confusing in my comments about the HMAC key wrap 
algorithm.  Right now, no other key wrap algorithm has the same structure, 
so if the unwrap is successful, the recipient cane be sure that the 
originator intended that the wrapped key be used with HMAC.

>or KEK bulk algorithm (3DES, AES...) be the one used in the key

I do not know what the working group consensus will be yet.  Once the 
consensus in clear, then we can figure out what documents need to address it.

This whole issue surfaced when trying to address AuthenticatedData with 
Static-Static Diffie-Hellman (S-S D-H) key agreement.  S-S D-H is used 
since it provides data origin authentication when the originator's public 
keys is certified.  Let me summarize the steps (assuming one recipient for 
simplicity).  These steps come from rfc2630bis, section 9.

1.  Originator generates a random HMAC key.

2.  Originator generates a random value.  It will be transferred to the 
recipient in the ukm field.  Originator uses the random value, her private 
D-H key and the Recipient's D-H public key to compute a pairwise 
key-encryption key (KEK).  The random value ensures that unique KEK is 
generated for this operation.  In this case, the KEK is a Triple-DES 
key.  Next, the originator wraps the HMAC key generated in step 1 with the KEK.

3.  The originator uses the recipient's certificate identification 
information, the wrapped HMAC key, the ukm, the appropriate algorithm 
identifiers, and so on are collected into a RecipientInfo value.

4.  Using the HMAC key, the originator computes a MAC value on the content 
or the authenticated attributes.  If the HMAC is computed on authenticated 
attributes, then one of them must be a message digest of the content.

Now, given this context, all of the issues raised by this thread are 
associated with step 2 (and perhaps the algorithm identifiers that are 
selected for step 3.

Jim, you seem to be looking for parallel situations in the RSA and D-H 
cases.  However, they do not exist in the AuthenticatedData 
context.  Neither RSA nor Ephemeral-Static D-H (E-S D-H) provides data 
origin authentication.  Anyone can wrap an HMAC key with the recipient' 
public key.  The whole point of AuthenticatedData is to know the origin of 
the content, and you cannot know the origin of the content unless you know 
the origin of the HMAC key.

I hope this helps clarify the situation.

>[SNIP]