[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [KEYPROV] MAC key support in PSKC

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

> -----Original Message-----
> From: Pei, Mingliang 
> Sent: Tuesday, May 05, 2009 11:23 AM
> To: Andrew Lindell; Doron Cohen; Philip Hoyer; Salah Machani; 
> keyprov at ietf.org
> Subject: RE: MAC key support in PSKC
> 
> 
> 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-----
> > From: Andrew Lindell [mailto:Andrew.Lindell at aladdin.com]
> > Sent: Sunday, May 03, 2009 6:27 AM
> > To: Pei, Mingliang; Doron Cohen; Philip Hoyer; Salah Machani; 
> > keyprov at ietf.org
> > Subject: RE: MAC key support in PSKC
> > 
> > Hi 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.)
> >  
> > 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
> > 
> > ________________________________
> > 
> > From: Pei, Mingliang [mailto:mpei at verisign.com]
> > Sent: Fri 5/1/2009 9:31 PM
> > To: Andrew Lindell; Doron Cohen; Philip Hoyer; Salah Machani; 
> > keyprov at ietf.org
> > Subject: RE: MAC key support in PSKC
> > 
> > 
> > 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:Andrew.Lindell at aladdin.com] 
> > 	Sent: Wednesday, April 29, 2009 11:00 PM
> > 	To: Pei, Mingliang; Doron Cohen; Philip Hoyer; Salah Machani; 
> > keyprov at ietf.org
> > 	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:mpei at verisign.com] 
> > 	Sent: Wednesday, April 29, 2009 05:12
> > 	To: Andrew Lindell; Doron Cohen; Philip Hoyer; Salah Machani; 
> > keyprov at ietf.org
> > 	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
> > <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>
> > 	        <ds:KeyName>Pre-shared-key</ds:KeyName>
> > 	    </EncryptionKey>
> > 	    <MACMethod
> > Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1
> > <http://www.w3.org/Web/2000/09/xmldsig#hmac-sha1> ">
> > 
> > 	        <MACKey>
> > 
> > 	           <EncryptedValue>
> > 	               <xenc:EncryptionMethod 
> > Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/
> > <http://www.w3.org/Web/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/Web/2001/04/xmlenc#aes128-cbc> >
> > 	                        <xenc:CipherData>
> > 	                            
> > <xenc:CipherValue>pgznhXdDh4LJ2G3mOY2RL7UA47yizMlXX3ADDcZd8Vs=
> > </xenc:CipherValue>
> > 	                        </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
> > <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>
> > 	        <ds:KeyName>Pre-shared-key</ds:KeyName>
> > 	    </EncryptionKey>
> > 	    <MACMethod
> > Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1
> > <http://www.w3.org/Web/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/Web/2001/04/xmlenc#aes128-cbc> >
> > 	                        <xenc:CipherData>
> > 	                            
> > <xenc:CipherValue>qw2ewasde312asder394jwfdauiiowujfpouipgznhXd
> > Dh4LJ2G3mOY2RL7UA47yizMlXX3ADDcZd8Vs=</xenc:CipherValue>
> > 	                        </xenc:CipherData>
> > 	                    </EncryptedValue>
> > 	                    
> > <ValueMAC>zdrZbGBj9BDZJzunbfAG3kyZyYc=</ValueMAC>
> > 	                </Secret>
> > 
> > 	          ...
> > 	</KeyContainer>
> > 
> > 	 
> > 
> > 	Comments? Thanks,
> > 
> > 	 
> > 
> > 	- Ming
> > 
> > 		 
> > 
> > ________________________________
> > 
> > 		From: Andrew Lindell
> > [mailto:Andrew.Lindell at aladdin.com] 
> > 		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:mpei at verisign.com] 
> > 		Sent: Saturday, March 28, 2009 04:42
> > 		To: Andrew Lindell;
> > oath_technical at v2.listbox.com; keyprov at ietf.org
> > 		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:Andrew.Lindell at aladdin.com] 
> > 			Sent: Monday, March 23, 2009 11:13 PM
> > 			To: Pei, Mingliang;
> > oath_technical at v2.listbox.com; keyprov at ietf.org
> > 			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:mpei at verisign.com] 
> > 			Sent: Tuesday, March 17, 2009 04:29
> > 			To: Pei, Mingliang; 
> > oath_technical at v2.listbox.com; keyprov at ietf.org
> > 			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; 
> > 'oath_technical at v2.listbox.com'
> > 				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: 
> > oath_technical at v2.listbox.com
> > 					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:doronc at aladdin.com] 
> > 					Sent: Thursday, March 
> > 05, 2009 4:58 AM
> > 					To: 
> > oath_technical at v2.listbox.com
> > 					Cc: Andrew Lindell; 
> > oath_technical at v2.listbox.com
> > 					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:philip.hoyer at actividentity.com] 
> > 					Sent: Tuesday, February 
> > 24, 2009 22:14
> > 					To: 
> > oath_technical at v2.listbox.com
> > 					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: 
> > keyprov-bounces at ietf.org [mailto:keyprov-bounces at ietf.org] 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/Web/internet-drafts/draft-ietf-keyprov-ps
> > kc-02.txt>  
> > 
> > 					Please send your 
> > comments to the list by March 6, 2009. 
> > 
> > 					Ciao 
> > 					Hannes & Phillip 
> > 
> > ________________________________
> > 
> > oath_technical | Archives 
> > <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 **
> > 					
> > **************************************************************
> > ************************************
> > 
> > ________________________________
> > 
> > oath_technical | Archives 
> > <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/> 
> > 
> > 					 
> > 
> > 			
> > 			
> > **************************************************************
> > ************************************
> > 			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 **
> > 	
> > **************************************************************
> > ************************************
> > 	
> > **************************************************************
> > ********************************
> > 
> > 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 **
> > 
> > **************************************************************
> > ********************************
> > 
> >