Subject: [secdir] review of draft-ietf-keyprov-symmetrickeyformat-07

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Sun, 25 Apr 2010 13:30:00 -0700

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

The document defines an ASN.1 container for symmetric keys.  This seems
useful.  For the most part the document is clear.  I have the following
comments (I also copied the authors of draft-ietf-keyprov-pskc-05 since
some of the comments may more pertain to that document). 

1. Is the sKey value encrypted or clear text?  

2. Section 3.2.12 Value MAC

I was not clear to me how this MAC was calculated.  What exactly does it
cover?  I assume it is the octet string in the sKey field in the
OneSymmetricKey sequence.  Does it include the ASN.1 encoding or not.  

3. Why is section 4 necessary in
draft-ietf-keyprov-symmetrickeyformat-07 and not in
http://tools.ietf.org/html/draft-ietf-keyprov-pskc-05?  

Thanks,

Joe

---

From: Sean Turner <[email-masked]>
Date: Sun, 25 Apr 2010 18:55:22 -0400

> 1. Is the sKey value encrypted or clear text?  

It can be either.  If it's in the cleartext then an encapsulation 
mechanism is needed to provide confidentiality (DSKPP provides one and 
CMS is another).  But, you could also encrypt just the key and add an 
attribute that gives you the information needed to decrypt it.

> OneSymmetricKey sequence.  Does it include the ASN.1 encoding or not.  

This attribute is necessary because PSKC supports encryption of just the 
key but the required key encryption algorithms does not provide an 
integrity check (i.e., they're requiring AES-128-CBC and not AES Key 
Wrap or AES Key Wrap with Padding).  If the key is encrypted with an 
algorithm that doesn't support an integrity check, then you do a MAC 
over the encrypted key (the text uses "encrypted value") and this 
attribute identifies the MAC algorithm and includes the MAC value.  Does 
the following make more sense:

OLD:

The Value MAC attribute is a Message Authentication Code (MAC) generated 
from the encrypted value in case the encryption algorithm does not 
support integrity checks (e.g., AES-CBC does not provide integrity while 
AES Key Wrap with MLI does).

NEW:

The Value MAC attribute is a Message Authentication Code (MAC) generated 
over the encrypted key in case the key encryption algorithm does not 
support integrity checks (e.g., AES-CBC does not provide integrity while 
AES Key Wrap with MLI does).  The MAC is over the value portion of the 
sKey field.

> http://tools.ietf.org/html/draft-ietf-keyprov-pskc-05?  

I don't see why it couldn't go in PSKC.  I think I just forgot to 
suggest that they include it.