Subject: Re: [KEYPROV] [OATH Technical] FW: WGLC: draft-ietf-keyprov-pskc-02.txt

From: "Philip Hoyer" <[email-masked]>
Date: Tue, 10 Mar 2009 12:08:49 +0100

David,

Thanks for reviewing the spec.

You are right the example is incorrect.

The padding needs to be explicitly specified. In previous drafts and
comments we agreed on PKCS#5 padding.

The MAC is on the unencrypted value since it is an HMAC, thre will be a
response from Ming Pei on this issue going into more detail.

Philip

________________________________

From: David Dix [mailto:[email-masked]] 
Sent: Monday, March 09, 2009 3:41 PM
To: Philip Hoyer
Subject: Re: [OATH Technical] FW: [KEYPROV] WGLC:
draft-ietf-keyprov-pskc-02.txt

Hi Philip, 

I've taken a look at the spec and only have a couple of comments about
the XML sample on page 19: 

- The aes128-cbc encrypted cipher does not seem to be prepended with iv
as it should be 
- The padding of the plain data seems to be PKCS#7 format rather than
ISO. 
- The MAC is not applied to the encrypted fields but to the plain value.

Regards 

David Dix

Cryptomathic Ltd.
Direct:   +44 (0)1223 225 355
Mobile: +44 (0)7747 665 540
[email-masked]
www.cryptomathic.com 

From: 

"Philip Hoyer" <[email-masked]> 

To: 

[email-masked] 

Date: 

24/02/2009 20:11 

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]
<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/?member_id=9641533&id_secret=130688982-4
cef55>  Your Subscription 

<http://www.listbox.com/> 

_______________________________________________
KEYPROV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/keyprov
<https://www.ietf.org/mailman/listinfo/keyprov> 

-------------------------------------------
oath_technical
Archives: https://www.listbox.com/member/archive/1323/=now
<https://www.listbox.com/member/archive/1323/=now> 
RSS Feed: https://www.listbox.com/member/archive/rss/1323/
<https://www.listbox.com/member/archive/rss/1323/> 
Modify Your Subscription:
https://www.listbox.com/member/?member_id=9641533&id_secret=130688982-4c
ef55
<https://www.listbox.com/member/?member_id=9641533&id_secret=130688982-4
cef55> 
Powered by Listbox: http://www.listbox.com <http://www.listbox.com/>

---

From: "Philip Hoyer" <[email-masked]>
Date: Tue, 10 Mar 2009 12:13:20 +0100

Thanks Doron and Yehuda for your comments,

The MAC key issue (rightly spotted) is one of the few outstanding issues
we wanted to discuss at the IETF meeting.

For the MAC on the unencrypted value Ming Pei is currently drafting a
response to your comment.

Philip

From: Doron Cohen [mailto:[email-masked]] 
Sent: Thursday, March 05, 2009 12:58 PM
To: Philip Hoyer
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:

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, 

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/?member_id=8836086&id_secret=130688972-a
00706>  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
**
************************************************************************
**************************

---

From: "Pei, Mingliang" <[email-masked]>
Date: Mon, 16 Mar 2009 19:28:48 -0700

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.

			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

			 

			 

			From: Philip Hoyer
[mailto:[email-masked]] 

			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 

			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>

---

From: "Pei, Mingliang" <[email-masked]>
Date: Fri, 27 Mar 2009 18:42:04 -0700

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

		From: Pei, Mingliang 

		Thanks,

		- Ming

			From: Pei, Mingliang 

			Hi Doron and Andrew,

			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.

			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.

				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

				 

				 

				From: Philip Hoyer
				Subject: [OATH Technical] FW: [KEYPROV]

				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

				Hi all, 

				this is a KEYPROV Working Group Last
Call for comments on 

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

				Ciao 
				Hannes & Phillip 

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

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