Subject: Re: [KEYPROV] MAC key support in PSKC

From: "Pei, Mingliang" <[email-masked]>
Date: Fri, 1 May 2009 11:31:47 -0700

Hi Yehuda,
 
Thank you for your comment. Good to know your native first name.
 
The concern is that knowing both the MAC value of the secret K and
cipher value of K may combine to lead to a hole someway depending on MAC
and encryption algorithm. Because the K_MAC itself is random and
independent of KEK, it looks to me that collision is remotely possible.
The overall security strength lies in the individual MAC algorithm and
encryption algorithm themselves and the strength of the KEK. We can
always recommend that a proper MAC algorithm and encryption algorithm
are used today and future. Currently, the MAC algorithm can be
HMAC-SHA256 or CMAC-AES-128 and the encryption algorithm can be
KW-AES-128 and AES-128-CBC etc. I think that we can achieve this in
future algorithm choice too.
 
If we choose MAC over ciphertext, a risk is that a man-in-the-middle may
set its own ciphertext value and corresponding MAC to the field. If this
is successful, a receiver would extract a bad secret that isn't sent by
the original sender. The risk isn't high though because the attack needs
to guess encryption key KEK to set a matching encrypted MAC value.
 
I would like to get your assessment input on this risk. How do you
consider it in comparison with the proposed approach? Do you think that
it is better if the recommendation is changed to apply MAC on the
ciphertext? Thanks,
 
- Ming

________________________________

	From: Andrew Lindell [mailto:[email-masked]] 
	Sent: Wednesday, April 29, 2009 11:00 PM
	To: Pei, Mingliang; Doron Cohen; Philip Hoyer; Salah Machani;
[email-masked]
	Subject: RE: MAC key support in PSKC

	Hi Ming,

	Choosing a separate random MAC key alleviates my main concern,
of course. 

	I'm still not too happy that the MAC is applied to the plaintext
and then encrypted, but we have already discussed this. I agree with you
that there is no specific problem here. My concern is that the method -
in general - is not sound, and so in the future when changing algorithms
etc. there is no guarantee that a hole won't be opened up.

	All the best,

	Yehuda (Andrew)

	From: Pei, Mingliang [mailto:[email-masked]] 
	Sent: Wednesday, April 29, 2009 05:12
	To: Andrew Lindell; Doron Cohen; Philip Hoyer; Salah Machani;
[email-masked]
	Subject: MAC key support in PSKC

	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"/
<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"/
<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"/
<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 **
	
************************************************************************
**************************

************************************************************************
**************************
	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 **
	
************************************************************************
**************************

---

From: "Pei, Mingliang" <[email-masked]>
Date: Tue, 5 May 2009 11:23:03 -0700

Hi Yehuda,

Thank you very much for your prompt input and the information about the paper. 
I am looking into the link and discussing it with a few others. I will follow up 
with you more on this in a day or two.

- Ming

> -----Original Message-----
> Sent: Sunday, May 03, 2009 6:27 AM
> The concern that you raise regarding a man-in-the-middle 
> attack is infeasible because it requires forging a MAC, which 
> is exactly what MACs are there to prevent. (I'm also assuming 
> that you have a typo; the attacker would have to guess the 
> random K_MAC key to set a matching encrypted MAC value, not 
> the encryption key KEK.)
>  
> Coming back to computing the MAC over the secret K directly 
> and then encrypting the key together with the MAC. I stress 
> that I am not claiming a problem with the proposed modes 
> (indeed AES-128-CBC has been proven to be secure under this 
> mode; see 
> http://www.iacr.org/archive/crypto2001/21390309.pdf) Now, 
> although I don't know of any problem with KW-AES-128 in this 
> mode (and I would be very surprised if there were a problem), 
> I KNOW that it is secure when you apply the MAC to the 
> ciphertext. Furthermore, I know that it will ALWAYS be secure 
> for any secure encryption method. Thus, I strongly prefer to 
> apply the MAC to the ciphertext and be sure that we will 
> never fall into a trap. 
>  
> I therefore do think that it's better to apply the MAC to the 
> ciphertext.
>  
> All the best,
>  
> Yehuda
> 
> Sent: Fri 5/1/2009 9:31 PM
> The concern is that knowing both the MAC value of the secret 
> K and cipher value of K may combine to lead to a hole someway 
> depending on MAC and encryption algorithm. Because the K_MAC 
> itself is random and independent of KEK, it looks to me that 
> collision is remotely possible. The overall security strength 
> lies in the individual MAC algorithm and encryption algorithm 
> themselves and the strength of the KEK. We can always 
> recommend that a proper MAC algorithm and encryption 
> algorithm are used today and future. Currently, the MAC 
> algorithm can be HMAC-SHA256 or CMAC-AES-128 and the 
> encryption algorithm can be KW-AES-128 and AES-128-CBC etc. I 
> think that we can achieve this in future algorithm choice too.
>  
> If we choose MAC over ciphertext, a risk is that a 
> man-in-the-middle may set its own ciphertext value and 
> corresponding MAC to the field. If this is successful, a 
> receiver would extract a bad secret that isn't sent by the 
> original sender. The risk isn't high though because the 
> attack needs to guess encryption key KEK to set a matching 
> encrypted MAC value.
>  
> I would like to get your assessment input on this risk. How 
> do you consider it in comparison with the proposed approach? 
> Do you think that it is better if the recommendation is 
> changed to apply MAC on the ciphertext? Thanks,
>  
> - Ming
> 
> 
> 	To: Pei, Mingliang; Doron Cohen; Philip Hoyer; Salah 
> Machani; [email-masked]
> 	Choosing a separate random MAC key alleviates my main 
> concern, of course. 
> 
> 	 
> 
> 	I'm still not too happy that the MAC is applied to the 
> plaintext and then encrypted, but we have already discussed 
> this. I agree with you that there is no specific problem 
> here. My concern is that the method - in general - is not 
> sound, and so in the future when changing algorithms etc. 
> there is no guarantee that a hole won't be opened up.
> 
> 	 
> 
> 	All the best,
> 
> 	 
> 
> 	Yehuda (Andrew)
> 
> 	 
> 
> 	To: Andrew Lindell; Doron Cohen; Philip Hoyer; Salah 
> Machani; [email-masked]
> 	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.
> 
> 	 
> 
> 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: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="Extensions" 
> type="pskc:ExtensionsType" minOccurs="0" maxOccurs="unbounded"/>
> 	  </xs:sequence>
> 	     <xs:element name="MACKey" 
> type="xenc:EncryptedValue" minOccurs="0"/>
> 	     <xs:element name="MACKeyReference" 
> type="xs:string" minOccurs="0"/>
> 	   </xs:choice>
> 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:
> 
> 	 
> 
> xmlns:ds="http://www.w3.org/2000/09/xmldsig 
> <http://www.w3.org/Web/2000/09/xmldsig> #" 
> xmlns:xenc="http://www.w3.org/2001/04/xmlenc 
> <http://www.w3.org/Web/2001/04/xmlenc> #">
> 	    <EncryptionKey>
> Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1 
> <http://www.w3.org/Web/2000/09/xmldsig#hmac-sha1> ">
> 
> 	        <MACKey>
> 
> 	           <EncryptedValue>
> 	               <xenc:EncryptionMethod 
> <http://www.w3.org/Web/2001/04/xmlenc#aes128-cbc> >
> 	               <xenc:CipherData>
> 	                   
> <http://www.w3.org/Web/2001/04/xmlenc#aes128-cbc> >
> 	                        <xenc:CipherData>
> 	                            
> <xenc:CipherValue>pgznhXdDh4LJ2G3mOY2RL7UA47yizMlXX3ADDcZd8Vs=
> </xenc:CipherValue>
> 	                        </xenc:CipherData>
> 	                    </EncryptedValue>
> 	                    
> xmlns:ds="http://www.w3.org/2000/09/xmldsig 
> <http://www.w3.org/Web/2000/09/xmldsig> #" 
> xmlns:xenc="http://www.w3.org/2001/04/xmlenc 
> <http://www.w3.org/Web/2001/04/xmlenc> #">
> 	    <EncryptionKey>
> Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1 
> <http://www.w3.org/Web/2000/09/xmldsig#hmac-sha1> "/>
> 
> 	    <KeyPackage>
> 
> 	        ...
> 	        <Key KeyId="22345678" 
> <http://www.w3.org/Web/2001/04/xmlenc#aes128-cbc> >
> 	                        <xenc:CipherData>
> 	                            
> <xenc:CipherValue>qw2ewasde312asder394jwfdauiiowujfpouipgznhXd
> Dh4LJ2G3mOY2RL7UA47yizMlXX3ADDcZd8Vs=</xenc:CipherValue>
> 	                        </xenc:CipherData>
> 	                    </EncryptedValue>
> 	                    
> 		Either of the approaches are fine in my 
> opinion. I also agree with Hugo that this is a good 
> derivation function.
> 
> 		 
> 
> 		Thanks,
> 
> 		 
> 
> 		Andrew
> 
> 		 
> 
> 		To: Andrew Lindell; 
> 		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
> 
> 			 
> 
> 			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
> 
> 			 
> 
> 				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
> 
> 					 
> 
> 					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
> 
> 					 
> 
> 					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 
> 					[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 
> 					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] 
> 					this is a KEYPROV 
> Working Group Last Call for comments on 
> 					
> <http://www.ietf.org/Web/internet-drafts/draft-ietf-keyprov-ps
> kc-02.txt>  
> 
> 					Please send your 
> comments to the list by March 6, 2009. 
> 
> 					Ciao 
> 					Hannes & Phillip 
> 
> <https://www.listbox.com/Web/member/archive/1323/=now>   
> <https://www.listbox.com/Web/member/archive/rss/1323/> | 
> Modify <https://www.listbox.com/Web/member/?&>  Your Subscription
> 
>  <http://www.listbox.com/Web/> 
> 
> 					 
> 
> 					
> 					
> **************************************************************
> ************************************
> 					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 **
> 					
> **************************************************************
> ************************************
> 
> <https://www.listbox.com/Web/member/archive/1323/=now>   
> <https://www.listbox.com/Web/member/archive/rss/1323/> | 
> Modify 
> <https://www.listbox.com/Web/member/?member_id=2265756&id_secr
> et=2265756-d89c009d>  Your Subscription 
> 
>  <http://www.listbox.com/Web/> 
> 
> 					 
> 
> 			
> 			
> **************************************************************
> ************************************
> 			If you have received this email in 
> error please notify the system manager or  the 
> 			** eSafe scanned this email for 
> viruses, vandals and malicious content **
> 			
> **************************************************************
> ************************************
> 
> 		
> 		
> **************************************************************
> ************************************
> **************************************************************
> ************************************
> 
> 
> 	
> **************************************************************
> ************************************
> **************************************************************
> ************************************
> 	
> **************************************************************
> ********************************
> 
> system manager or  the sender immediately and do not disclose 
> **************************************************************
> ********************************
> 
>

---

From: "Pei, Mingliang" <[email-masked]>
Date: Tue, 12 May 2009 15:52:00 -0700

Hi Yehuda,

After reviewing the paper and discussing with a few others, we agree with you that let us adopt the MAC calculation over cipher text instead of clear text. The attack mentioned in the paper rooted in actually the weak encryption - the encryption alone can reveal bits of information. Regardless, it is good to be more cautions by using MAC over encryption.

Thank you very much for your suggestion. We will incorporate this in the next draft.

- Ming

> Sent: Tuesday, May 05, 2009 11:23 AM
> I am looking into the link and discussing it with a few 
> others. I will follow up with you more on this in a day or two.
> 
> - Ming
> 
> > The concern that you raise regarding a man-in-the-middle attack is 
> > infeasible because it requires forging a MAC, which is exactly what 
> > MACs are there to prevent. (I'm also assuming that you have a typo; 
> > the attacker would have to guess the random K_MAC key to set a 
> > matching encrypted MAC value, not the encryption key KEK.)
> >  
> and then 
> > encrypting the key together with the MAC. I stress that I am not 
> > claiming a problem with the proposed modes (indeed AES-128-CBC has 
> > been proven to be secure under this mode; see
> although I 
> > don't know of any problem with KW-AES-128 in this mode (and 
> I would be 
> > very surprised if there were a problem), I KNOW that it is 
> secure when 
> > you apply the MAC to the ciphertext. Furthermore, I know 
> that it will 
> > ALWAYS be secure for any secure encryption method. Thus, I strongly 
> > prefer to apply the MAC to the ciphertext and be sure that we will 
> > never fall into a trap.
> >  
> > cipher value of K may combine to lead to a hole someway 
> depending on 
> > MAC and encryption algorithm. Because the K_MAC itself is 
> random and 
> > independent of KEK, it looks to me that collision is remotely 
> > possible. The overall security strength lies in the individual MAC 
> > algorithm and encryption algorithm themselves and the 
> strength of the 
> > KEK. We can always recommend that a proper MAC algorithm and 
> > encryption algorithm are used today and future. Currently, the MAC 
> > algorithm can be HMAC-SHA256 or CMAC-AES-128 and the encryption 
> > algorithm can be KW-AES-128 and AES-128-CBC etc. I think 
> that we can 
> > achieve this in future algorithm choice too.
> >  
> man-in-the-middle 
> > may set its own ciphertext value and corresponding MAC to 
> the field. 
> > If this is successful, a receiver would extract a bad secret that 
> > isn't sent by the original sender. The risk isn't high 
> though because 
> > the attack needs to guess encryption key KEK to set a matching 
> > encrypted MAC value.
> >  
> > consider it in comparison with the proposed approach?
> > Do you think that it is better if the recommendation is changed to 
> > apply MAC on the ciphertext? Thanks,
> >  
> > - Ming
> > 
> > 
> concern, of 
> > course.
> plaintext and 
> > then encrypted, but we have already discussed this. I agree 
> with you 
> > that there is no specific problem here. My concern is that 
> the method 
> > - in general - is not sound, and so in the future when changing 
> > algorithms etc.
> topic, we 
> > feel that we can come to the following proposal for MAC key 
> support in 
> > PSKC:
> > 
> > 	 
> > 
> in PSKC XML in 
> > an encrypted form. The encryption uses the same encryption key and 
> > method as that for OTP secret.
> > 
> > 	 
> > 
> all three key 
> > protection profiles: password based, preloaded symmetric key, and 
> 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.
> > 
> > 	 
> > 
> key packages in 
> > a KeyContainer if it contains more than one key package.
> > 
> > 	 
> > 
> > 	Schema:
> > 
> > 	 
> > 
> KeyPackage 
> > inside which the K_MAC was combined with key secret before 
> encryption.
> > 
> > 	 
> > 
> opinion. I also agree with 
> > Hugo that this is a good derivation function.
> > 
> > 		 
> > 
> > 		Thanks,
> > 
> > 		 
> > 
> > 		Andrew
> > 
> > 		 
> > 
> 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.
> > 
> > 		 
> > 
> 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.
> 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.
> > 
> > 		 
> > 
> 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
> > 
> > 			 
> > 
> 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 
> 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.
> > 
> > 			 
> >