Subject: [KEYPROV] MAC key support in PSKC

From: "Pei, Mingliang" <[email-masked]>
Date: Tue, 28 Apr 2009 19:11:36 -0700

According to our online and offline discussions in this topic, we feel
that we can come to the following proposal for MAC key support in PSKC:
 
1. MAC key will be randomly generated data and passed in PSKC XML in an
encrypted form. The encryption uses the same encryption key and method
as that for OTP secret.
 
This is selected over key derivation for it can handle all three key
protection profiles: password based, preloaded symmetric key, and
transport profile with a RSA key.
 
2. MAC key material can be passed in two ways: 
 
a. it is included along with MAC algorithm.
b. it is passed along with the target secret key in a concatenated form
before the result is encrypted and set in the element
<Key>/<Data>/<Secret>. In other words, the key.secret.plaintext = K_MAC
|| key.secret and the combined value is encrypted. This is used to
support the way that DSKPP protocol sets a random K_MAC.
 
3. The same MAC key and algorithm will be used by all key packages in a
KeyContainer if it contains more than one key package.
 
Schema:
 
 <xs:complexType name="KeyContainerType">
  <xs:sequence>
   <xs:element name="EncryptionKey" type="ds:KeyInfoType"
minOccurs="0"/>
   <xs:element name="MACMethod" type="pskc:MACMethodType"
minOccurs="0"/>
   <xs:element name="KeyPackage" type="pskc:KeyPackageType"
maxOccurs="unbounded"/>
   <xs:element name="Signature" type="ds:SignatureType" minOccurs="0"/>
   <xs:element name="Extensions" type="pskc:ExtensionsType"
minOccurs="0" maxOccurs="unbounded"/>
  </xs:sequence>
  <xs:attribute name="Version" type="pskc:VersionType" use="required"/>
  <xs:attribute name="id" type="xs:ID" use="optional"/>
 </xs:complexType>

 <xs:complexType name="MACMethodType">
  <xs:sequence>
   <xs:choice>
     <xs:element name="MACKey" type="xenc:EncryptedValue"
minOccurs="0"/>
     <xs:element name="MACKeyReference" type="xs:string" minOccurs="0"/>
   </xs:choice>
   <xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
  </xs:sequence>
  <xs:attribute name="Algorithm" type="xs:anyURI" use="required"/>
 </xs:complexType>

where
 
  MACKey: the element carries the encrypted MAC key K_MAC.
  MACKeyReference: the value is set to the KeyID of the KeyPackage
inside which the K_MAC was combined with key secret before encryption.
 
If both are absent, the first KeyPackage is assumed to contain the MAC
key in its encrypted secret field.
 
Example:
 
<?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1" xmlns="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
    <EncryptionKey>
        <ds:KeyName>Pre-shared-key</ds:KeyName>
    </EncryptionKey>
    <MACMethod Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1">
        <MACKey>
           <EncryptedValue>
               <xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
               <xenc:CipherData>
 
<xenc:CipherValue>MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=</xenc:CipherValue>
               </xenc:CipherData>        
            </EncryptedValue>        
         </MACKey>
    </MACMethod>
    <KeyPackage>
        ...
        <Key KeyId="12345678"
KeyAlgorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">
            ...
            <Data>
                <Secret>
                    <EncryptedValue>
                        <xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
                        <xenc:CipherData>
 
<xenc:CipherValue>pgznhXdDh4LJ2G3mOY2RL7UA47yizMlXX3ADDcZd8Vs=</xenc:Cip
herValue>
                        </xenc:CipherData>
                    </EncryptedValue>
                    <ValueMAC>zdrZbGBj9BDZJzunbfAG3kyZyYc=</ValueMAC>
                </Secret>
          ...
</KeyContainer>
 
<?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1" xmlns="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
    <EncryptionKey>
        <ds:KeyName>Pre-shared-key</ds:KeyName>
    </EncryptionKey>
    <MACMethod Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>
    <KeyPackage>
        ...
        <Key KeyId="22345678"
KeyAlgorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">
            ...
            <Data>
                <Secret>
                    <EncryptedValue>
                        <xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
                        <xenc:CipherData>
 
<xenc:CipherValue>qw2ewasde312asder394jwfdauiiowujfpouipgznhXdDh4LJ2G3mO
Y2RL7UA47yizMlXX3ADDcZd8Vs=</xenc:CipherValue>
                        </xenc:CipherData>
                    </EncryptedValue>
                    <ValueMAC>zdrZbGBj9BDZJzunbfAG3kyZyYc=</ValueMAC>
                </Secret>
          ...
</KeyContainer>
 
Comments? Thanks,
 
- Ming

________________________________

	From: Andrew Lindell [mailto:[email-masked]] 
	Sent: Sunday, March 29, 2009 9:37 PM
	To: Pei, Mingliang
	Cc: Doron Cohen
	Subject: RE: [OATH Technical] FW: [KEYPROV] WGLC:
draft-ietf-keyprov-pskc-02.txt

	Dear Ming,

	Either of the approaches are fine in my opinion. I also agree
with Hugo that this is a good derivation function.

	Thanks,

	Andrew

	From: Pei, Mingliang [mailto:[email-masked]] 
	Sent: Saturday, March 28, 2009 04:42
	To: Andrew Lindell; [email-masked];
[email-masked]
	Cc: Doron Cohen
	Subject: RE: [OATH Technical] FW: [KEYPROV] WGLC:
draft-ietf-keyprov-pskc-02.txt

	Hi Andrew,

	Yes, we thought of using key derivation to obtain two keys from
some discussions this week in IETF. The option to derive a MAC key from
KEK itself is considered not a choice because in principle we don't want
to use the same key for two purpose - encryption and derivation.
Treating pre-shared key as a master key to derive KEK and K_MAC is a
feasible choice.

	When two key derivation is chosen, we would need to define KDF
in PSKC, handling both password derived key and pre-shared master key.
For password derived key, maybe we can use the same derivation function
but different salts respectively for KEK and K_MAC. It is under
discussion. Using a different KDF for pre-shared master key may add more
complexity than the random chosen K_MAC. The KDF could be simply HMAC of
K_master with some different constant string for KEK and K_MAC, for
example, KEK = HMAC(K_master, "0000") and K_MAC = HMAC(K_master,
"1111"), thanking Hugo Krawczyk for the suggestion. Alternatively PSKC
can easily pass encrypted K_MAC with KEK in payload.

	I favor more the random chosen K_MAC for now than the KDF
approach for two keys in terms of one approach for both password and
pre-shared key case. KDF is good that it doesn't need to pass additional
parameter in payload. Comments are appreciated on the choice and best
practices in other specifications.

	Thank you,

	- Ming

________________________________

		From: Andrew Lindell [mailto:[email-masked]]

		Sent: Monday, March 23, 2009 11:13 PM
		To: Pei, Mingliang; [email-masked];
[email-masked]
		Cc: Doron Cohen
		Subject: RE: [OATH Technical] FW: [KEYPROV] WGLC:
draft-ietf-keyprov-pskc-02.txt

		Hi Ming,

		Thank you for your response. One thing however is not
clear to me now. Is the hashed key (ValueMAC) encrypted together with
the key? If yes, then I agree with you that it's not really a concern.
This also solves the problem of integrity (albeit not cryptographically,
where a MAC is really needed). However, if the hashed value is not
encrypted, then this can be a problem if someone uses a procedure that
results in a relatively low entropy key. Although such a procedure
within itself is bad, this would make it worse and so it would be better
to encrypt the hashed value as well.

		One other thing, regarding item (1). When two keys
cannot be provided, have you thought of using key derivation to obtain
two keys from the one. Although you keep the same entropy, this is more
cryptographically sound than using the same key for both tasks.

		Thanks,

		Andrew

		From: Pei, Mingliang [mailto:[email-masked]] 
		Sent: Tuesday, March 17, 2009 04:29
		To: Pei, Mingliang; [email-masked];
[email-masked]
		Cc: Andrew Lindell
		Subject: RE: [OATH Technical] FW: [KEYPROV] WGLC:
draft-ietf-keyprov-pskc-02.txt

		Copying keyprov mailing list... - Ming

________________________________

			From: Pei, Mingliang 
			Sent: Monday, March 16, 2009 7:26 PM
			To: Pei, Mingliang;
[email-masked]'
			Cc: 'Andrew Lindell'
			Subject: RE: [OATH Technical] FW: [KEYPROV]
WGLC: draft-ietf-keyprov-pskc-02.txt

			I need to clarify that the strong hash is good
when the cleartext to be encrypted is some long random secret bytes. If
the value is within some known finite integer values, some simple hash
lookup over all possible values will reveal the cleartext itself.

			Thanks,

			- Ming

________________________________

				From: Pei, Mingliang 
				Sent: Monday, March 16, 2009 7:22 PM
				To: [email-masked]
				Cc: Andrew Lindell
				Subject: RE: [OATH Technical] FW:
[KEYPROV] WGLC: draft-ietf-keyprov-pskc-02.txt

				Hi Doron and Andrew,

				Thank you very much for the review and
comments.

				1. It is actually a working item in the
draft per earlier comment. We agree with you that using the same key for
MAC and encryption isn't a good practice. We thought of options that
allow one to specify a separate MAC key by extending the current
definition on the MAC algorithm type. Asking two keys isn't ideal for
those pre-shared encryption key devices. In DSKPP, a MAC key was
randomly generated and encrypted along with the secret. We have not had
deep discussions on this. Thank you for raising the issue, and it will
help us to make sure it is addressed in the final version.

				2. The purpose of the ValueMAC is to
serve integrity check of the data. It isn't intended for any sender
authentication. On one hand, our initial version simply pass a hash
value of the data to be encrypted, for example, ValueMAC =
SHA_256(cleartext). Note that hashing over ciphertext doesn't serve the
purpose. A man-in-the-middle may alter the ciphertext and generate hash
accordingly. Therefore it is necessary to calculate it over the
cleartext. 

				When HMAC was chosen for the integrity
check purpose, we still felt that the hash over the original data was
good. The essential argument goes back to the first item: should the MAC
key be a separate one. If it is a separate one, the security concern
doesn't seem to exist.

				For simplicity, I consider that
SHA_256(cleartext) is fine without requiring complexity in choosing MAC
key for HMAC. Using the same key again isn't good. There are other ways
to serve the integrity check, for example, encryption is over
<cleartext> + <Encrypted(random data) with the cleartext>. The simpliest
is <hash(cleartext)> with a strong hash function such as SHA_256. I
don't think a strong hash and encrypted value together will reveal the
cleartext.

				Suggestions are welcomed for making this
choice.

				Thank you,

				- Ming

________________________________

				From: Doron Cohen
[mailto:[email-masked]] 
				Sent: Thursday, March 05, 2009 4:58 AM
				To: [email-masked]
				Cc: Andrew Lindell;
[email-masked]
				Subject: RE: [OATH Technical] FW:
[KEYPROV] WGLC: draft-ietf-keyprov-pskc-02.txt

				Hi Philip,

				Below are a couple of comments I
received from Aladdin's Chief Cryptographer, Yehuda (Andrew) Lindell .
Yehuda will be glad to provide more clarifications if required.

				"When algorithms without integrity
checks are used, such as AES-128-CBC, a keyed MAC value using the same
key as the key encryption key MUST be placed in the <ValueMAC> element
of the <Data> element.  In this case the MAC algorithm type MUST be set
in the <MACAlgorithm> element of the <KeyContainer> element.
Implementations of PSKC MUST support HMAC-SHA1 (with the URI of
http://www.w3.org/2000/09/xmldsig#hmac-sha1) as the
mandatory-to-implement MAC algorithm.

				[Yehuda Lindell] This is very bad
practice. You should not use the same key for different tasks. The
solution to this (where an authenticated-encryption scheme is not used)
is to use key derivation to obtain two keys from the single one, and
then use the first for encryption and the second for the MAC.

				In section 4.2 the following appears:

				Additionally, a <ValueMac> element,
which is populated with a MAC generated from the unencrypted value in
case the encryption algorithm does not support integrity checks, MAY be
included as a child element.  The example shown at Figure 2 illustrates
the usage of the <Data> element with two child elements, namely <Secret>
and <Counter>.  Both elements carry plaintext value within the
<PlainValue> child element.

				[Yehuda Lindell] This says that the MAC
is applied to the unencrypted value. This is bad practice (it is not
always secure) and it's far better to generate the MAC by applying it to
the encrypted ciphertext. In any case, this contradicts what appears
below in Section 6.1 (Section 6.1 explicitly states that the MAC is
applied to the encrypted value, which is the correct way to work).

				Best Regards

				Doron

				Doron Cohen

				CTO, Authentication Business Unit

				Aladdin Knowledge Systems

				 

				From: Philip Hoyer
[mailto:[email-masked]] 
				Sent: Tuesday, February 24, 2009 22:14
				To: [email-masked]
				Subject: [OATH Technical] FW: [KEYPROV]
WGLC: draft-ietf-keyprov-pskc-02.txt

				Ladies and Gentlemen:

				Could I invite the participants on the
list please to review the PSKC spec as below as the work started in OATH
and it would be great to see what you think of it now.

				Philip

________________________________

				From: [email-masked]
[mailto:[email-masked]] On Behalf Of Tschofenig, Hannes (NSN -
FI/Espoo)
				Sent: Monday, February 23, 2009 12:14 PM
				To: KEYPROV
				Subject: [KEYPROV] WGLC:
draft-ietf-keyprov-pskc-02.txt

				Hi all, 

				this is a KEYPROV Working Group Last
Call for comments on 
	
http://www.ietf.org/internet-drafts/draft-ietf-keyprov-pskc-02.txt
<http://www.ietf.org/internet-drafts/draft-ietf-keyprov-pskc-02.txt>  

				Please send your comments to the list by
March 6, 2009. 

				Ciao 
				Hannes & Phillip 

________________________________

oath_technical | Archives
<https://www.listbox.com/member/archive/1323/=now>
<https://www.listbox.com/member/archive/rss/1323/> | Modify
<https://www.listbox.com/member/?&>  Your Subscription

 <http://www.listbox.com> 

	
************************************************************************
**************************
				The contents of this email and any
attachments are confidential.
				It is intended for the named
recipient(s) only.
				If you have received this email in error
please notify the system manager or? the 
				sender immediately and do not disclose
the contents to anyone or make copies.
				** eSafe scanned this email for viruses,
vandals and malicious content **
	
************************************************************************
**************************

________________________________

oath_technical | Archives
<https://www.listbox.com/member/archive/1323/=now>
<https://www.listbox.com/member/archive/rss/1323/> | Modify
<https://www.listbox.com/member/?member_id=2265756&id_secret=2265756-d89
c009d>  Your Subscription 

 <http://www.listbox.com> 

	
************************************************************************
**************************
		The contents of this email and any attachments are
confidential.
		It is intended for the named recipient(s) only.
		If you have received this email in error please notify
the system manager or  the 
		sender immediately and do not disclose the contents to
anyone or make copies.
		** eSafe scanned this email for viruses, vandals and
malicious content **
	
************************************************************************
**************************

************************************************************************
**************************
	The contents of this email and any attachments are confidential.
	It is intended for the named recipient(s) only.
	If you have received this email in error please notify the
system manager or  the 
	sender immediately and do not disclose the contents to anyone or
make copies.
	** eSafe scanned this email for viruses, vandals and malicious
content **
	
************************************************************************
**************************