Subject: Re: [KEYPROV] Examples in PSKC

From: "Pei, Mingliang" <[email-masked]>
Date: Mon, 12 Jan 2009 01:38:24 -0800

Yes, I have done AES128-CBC examples. The padding and iv are well considered in the example now, and I will update the draft to reflect the specifications and example data. The mac key choice is the encryption key by default and we need to come out a way to allow other mac key as we discussed during 73th ietf.

I am working on the rsa example, and hope to get most results before Tuesday's call.

- Ming

----- Original Message -----
From: Hannes Tschofenig <[email-masked]>
To: Pei, Mingliang; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Sent: Sat Jan 10 09:22:36 2009
Subject: RE: [KEYPROV] Examples in PSKC

Ming, 

Are you making progress with the examples? 
 
Ciao
Hannes

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Pei, Mingliang
	Sent: 15 December, 2008 09:25
	To: [email-masked]; [email-masked]
	Subject: Re: [KEYPROV] Examples in PSKC

	I am one. Philip also suggested that it better has two versions so
that they can verify each other. Hope to get another reference check.
	
	- Ming
	
	----- Original Message -----
	From: [email-masked] <[email-masked]>
	To: [email-masked] <[email-masked]>
	Sent: Sun Dec 14 04:55:43 2008
	Subject: [KEYPROV] Examples in PSKC
	
	Hi all,
	
	during the IETF#73 KEYPROV meeting Ming mentioned that the examples
will be
	extended in such a way that they can actually be verified, i.e.,
when there
	is a digital signature then enough information is provided in the
document
	so that it can be checked for correctness.
	
	What I have in mind is something similar to what is done in
	http://www.ietf.org/rfc/rfc4474.txt (see also Appendix B)
	
	So, who is working on this aspect?
	
	Ciao
	Hannes

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

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

---

From: "Philip Hoyer" <[email-masked]>
Date: Mon, 12 Jan 2009 11:31:11 +0100

Ming,

We agreed on previous call that the KW version AES 128 will be the
mandatory algorithm for PSKC and DSKPP so we need examples using
KW-AES-128

Philip

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Pei, Mingliang
Sent: Monday, January 12, 2009 9:38 AM
To: [email-masked]; [email-masked]
Subject: Re: [KEYPROV] Examples in PSKC

Yes, I have done AES128-CBC examples. The padding and iv are well
considered in the example now, and I will update the draft to reflect
the specifications and example data. The mac key choice is the
encryption key by default and we need to come out a way to allow other
mac key as we discussed during 73th ietf.

I am working on the rsa example, and hope to get most results before
Tuesday's call.

- Ming

----- Original Message -----
From: Hannes Tschofenig <[email-masked]>
To: Pei, Mingliang; [email-masked]
<[email-masked]>; [email-masked] <[email-masked]>
Sent: Sat Jan 10 09:22:36 2009
Subject: RE: [KEYPROV] Examples in PSKC

Ming,

Ciao
Hannes

        From: [email-masked] [mailto:[email-masked]]
On

        I am one. Philip also suggested that it better has two versions
so
that they can verify each other. Hope to get another reference check.
       
        - Ming
       
        ----- Original Message -----
        From: [email-masked] <[email-masked]>
        To: [email-masked] <[email-masked]>
        Sent: Sun Dec 14 04:55:43 2008
        Subject: [KEYPROV] Examples in PSKC
       
        Hi all,
       
        during the IETF#73 KEYPROV meeting Ming mentioned that the
examples
will be
        extended in such a way that they can actually be verified, i.e.,
when there
        is a digital signature then enough information is provided in
the
document
        so that it can be checked for correctness.

       
        Ciao
        Hannes

---

From: "Pei, Mingliang" <[email-masked]>
Date: Mon, 12 Jan 2009 10:00:53 -0800

It was an issue raised during 73-th IETF. I wasn't aware that the
decision to KW has been made in the follow up calls. Thanks for the
update. I will make changes to AES-128-KW.
 
- Ming

	From: Philip Hoyer [mailto:[email-masked]] 
	Sent: Monday, January 12, 2009 2:31 AM
	To: Pei, Mingliang; [email-masked]; [email-masked]
	Subject: RE: [KEYPROV] Examples in PSKC

	Ming,

	We agreed on previous call that the KW version AES 128 will be
the mandatory algorithm for PSKC and DSKPP so we need examples using
KW-AES-128

	Philip

On Behalf Of Pei, Mingliang

	Yes, I have done AES128-CBC examples. The padding and iv are
well considered in the example now, and I will update the draft to
reflect the specifications and example data. The mac key choice is the
encryption key by default and we need to come out a way to allow other
mac key as we discussed during 73th ietf.
	
	I am working on the rsa example, and hope to get most results
before Tuesday's call.
	
	- Ming

	----- Original Message -----
	From: Hannes Tschofenig <[email-masked]>
	To: Pei, Mingliang; [email-masked]
	
	Ming,

	Ciao
	Hannes

	        From: [email-masked]
[mailto:[email-masked]] On
	Behalf Of ext Pei, Mingliang
	        Sent: 15 December, 2008 09:25
	        To: [email-masked]; [email-masked]
	        Subject: Re: [KEYPROV] Examples in PSKC

	        I am one. Philip also suggested that it better has two
versions so
	that they can verify each other. Hope to get another reference
check.
	       
	        - Ming
	       
	        ----- Original Message -----
	        From: [email-masked]
<[email-masked]>
	        To: [email-masked] <[email-masked]>
	        Sent: Sun Dec 14 04:55:43 2008
	        Subject: [KEYPROV] Examples in PSKC
	       
	        Hi all,
	       
	        during the IETF#73 KEYPROV meeting Ming mentioned that
the examples
	will be
	        extended in such a way that they can actually be
verified, i.e.,
	when there
	        is a digital signature then enough information is
provided in the
	document
	        so that it can be checked for correctness.
	       
	        What I have in mind is something similar to what is done
in
	        http://www.ietf.org/rfc/rfc4474.txt (see also Appendix
B)

	        Ciao
	        Hannes

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 12 Jan 2009 21:34:54 +0200

Actually, no decision can be made during our calls. 
 
We discussed this issue during the IETF meeting and it was recorded in our
meeting minutes. In the room, if I recall it correctly, there was nobody
that raised objections. I need to check again. 

	From: Pei, Mingliang [mailto:[email-masked]] 
	Sent: 12 January, 2009 20:01
	To: Philip Hoyer; [email-masked]; [email-masked]
	Subject: RE: [KEYPROV] Examples in PSKC

	It was an issue raised during 73-th IETF. I wasn't aware that the
decision to KW has been made in the follow up calls. Thanks for the update.
I will make changes to AES-128-KW.
	 
	- Ming

		From: Philip Hoyer [mailto:[email-masked]] 
		Sent: Monday, January 12, 2009 2:31 AM
		To: Pei, Mingliang; [email-masked];
[email-masked]
		Subject: RE: [KEYPROV] Examples in PSKC

		Ming,

		We agreed on previous call that the KW version AES 128 will
be the mandatory algorithm for PSKC and DSKPP so we need examples using
KW-AES-128

		Philip

[mailto:[email-masked]] On Behalf Of Pei, Mingliang

		Yes, I have done AES128-CBC examples. The padding and iv are
well considered in the example now, and I will update the draft to reflect
the specifications and example data. The mac key choice is the encryption
key by default and we need to come out a way to allow other mac key as we
discussed during 73th ietf.
		
		I am working on the rsa example, and hope to get most
results before Tuesday's call.
		
		- Ming

		----- Original Message -----
		From: Hannes Tschofenig <[email-masked]>
		To: Pei, Mingliang; [email-masked]
		
		Ming,

		Ciao
		Hannes

		
		        I am one. Philip also suggested that it better has
two versions so
		that they can verify each other. Hope to get another
reference check.
		       
		        - Ming
		       
		        ----- Original Message -----
		       
		        Hi all,
		       
		        during the IETF#73 KEYPROV meeting Ming mentioned
that the examples
		will be
		        extended in such a way that they can actually be
verified, i.e.,
		when there
		        is a digital signature then enough information is
provided in the
		document
		        so that it can be checked for correctness.
		       
		        What I have in mind is something similar to what is
done in
		        http://www.ietf.org/rfc/rfc4474.txt (see also
Appendix B)

		        Ciao
		        Hannes

---

From: "Pei, Mingliang" <[email-masked]>
Date: Mon, 12 Jan 2009 12:02:37 -0800

That was my recall too in the room. - Ming 

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Monday, January 12, 2009 11:35 AM
To: Pei, Mingliang; 'Philip Hoyer'; [email-masked]
Subject: RE: [KEYPROV] Examples in PSKC

We discussed this issue during the IETF meeting and it was recorded in
our meeting minutes. In the room, if I recall it correctly, there was
nobody that raised objections. I need to check again. 

	It was an issue raised during 73-th IETF. I wasn't aware that
the decision to KW has been made in the follow up calls. Thanks for the
update.
I will make changes to AES-128-KW.
	 
	- Ming

		From: Philip Hoyer
[mailto:[email-masked]] 
		Sent: Monday, January 12, 2009 2:31 AM
		To: Pei, Mingliang; [email-masked];
[email-masked]
		Subject: RE: [KEYPROV] Examples in PSKC

		Ming,

		We agreed on previous call that the KW version AES 128
will be the mandatory algorithm for PSKC and DSKPP so we need examples
using
KW-AES-128

		Philip

		Yes, I have done AES128-CBC examples. The padding and iv
are well considered in the example now, and I will update the draft to
reflect the specifications and example data. The mac key choice is the
encryption key by default and we need to come out a way to allow other
mac key as we discussed during 73th ietf.

		- Ming

		----- Original Message -----
		From: Hannes Tschofenig <[email-masked]>
		To: Pei, Mingliang; [email-masked]
		
		Ming,

		Ciao
		Hannes

		
		        I am one. Philip also suggested that it better
has two versions so
		that they can verify each other. Hope to get another
reference check.
		       
		        - Ming
		       
		        ----- Original Message -----
		       
		        Hi all,
		       
		        during the IETF#73 KEYPROV meeting Ming
mentioned that the examples
		will be
		        extended in such a way that they can actually be
verified, i.e.,
		when there
		        is a digital signature then enough information
is provided in the
		document
		        so that it can be checked for correctness.
		       
		        What I have in mind is something similar to what
is done in
		        http://www.ietf.org/rfc/rfc4474.txt (see also
Appendix B)

		        Ciao
		        Hannes

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 13 Jan 2009 01:06:38 +0200

Hi all, 

Section 6.1.1. of
http://www.ietf.org/internet-drafts/draft-ietf-keyprov-portable-symmetric-ke
y-container-06.txt describes the AES-128-CBC encryption algorithm as
mandatory to implement.

It was suggested to switch from AES-128-CBC to KW-AES-128 as the mandatory
algorithm. 

During the meeting we had a very brief chat about this topic, see (and
hear):
http://www.ietf.org/proceedings/08nov/slides/keyprov-2/keyprov-2.htm
ftp://videolab.uoregon.edu/pub/videolab/media/ietf73/ietf73-ch8-wed-am2.mp3
 
I checked the meeting minutes and noticed that they do not capture a lot:
http://www.ietf.org/proceedings/08nov/minutes/keyprov.txt
 
So, let's us do a quick poll. 

Please indicate your preference (if possible with arguments why you want one
or the other). 
  
--> Deadline for your response: 20th Jan. 2009 <--

Ciao
Hannes

	 
	- Ming

		Ming,

		Philip

		
		
		- Ming

		----- Original Message -----
		From: Hannes Tschofenig <[email-masked]>
		To: Pei, Mingliang; [email-masked]
		
		Ming,

		Ciao
		Hannes

		
		       
		        - Ming
		       
		        ----- Original Message -----
		       
		        Hi all,

		       
		       
		        Ciao
		        Hannes

---

From: Sean Turner <[email-masked]>
Date: Tue, 13 Jan 2009 07:48:55 -0500

KW-AES-128

---

From: "Pei, Mingliang" <[email-masked]>
Date: Tue, 13 Jan 2009 07:29:21 -0800

I have updated AES / PBE examples and some descriptions proceeding the
example sections in the draft with my reference implementation. Please
review the attached.

- Ming

>Sent: 12 January, 2009 22:03
>To: Hannes Tschofenig; Philip Hoyer; [email-masked]
the 
[email-masked]
>		We agreed on previous call that the KW version AES 128
will be the 
>mandatory algorithm for PSKC and DSKPP so we need examples using
are well 
>		I am working on the rsa example, and hope to get most
results before 
>		Are you making progress with the examples?
has two 
reference check.
>		        during the IETF#73 KEYPROV meeting Ming
mentioned that the 
>		        extended in such a way that they can actually be
verified, 
>i.e.,
is provided in 
is done in

---

From: "Anders Rundgren" <[email-masked]>
Date: Tue, 13 Jan 2009 21:24:55 +0100

Isn't the choice really between
http://www.w3.org/2001/04/xmlenc#kw-aes128 and
http://www.w3.org/2001/04/xmlenc#aes128-cbc ?

If http://www.w3.org/2001/04/xmlenc#kw-aes128 is selected
it is worth noting that http://www.w3.org/TR/xmlenc-core says:
 "This algorithm is defined only for inputs which are a multiple of 64 bits"

However, http://www.ietf.org/rfc/rfc4226.txt (HOTP) says:
 "The algorithm MUST use a strong shared secret.  The length of
  the shared secret MUST be at least 128 bits.  This document
  RECOMMENDs a shared secret length of 160 bits"

Since 160 bit isn't a multiple of 64 bits I would personally choose
http://www.w3.org/2001/04/xmlenc#aes128-cbc as the default
key-encryption algorithm to not run into problems or have to
use less established variants of KW-AES algorithms.

Anders

----- Original Message ----- 
From: "Hannes Tschofenig" <[email-masked]>
To: "'Pei, Mingliang'" <[email-masked]>; "'Philip Hoyer'" <[email-masked]>; 
<[email-masked]>
Sent: Tuesday, January 13, 2009 00:06
Subject: [KEYPROV] KW-AES-128 vs. AES-128-CBC

Hi all,

Section 6.1.1. of

Ciao
Hannes

- Ming

Ming,

Philip

- Ming

----- Original Message -----
From: Hannes Tschofenig <[email-masked]>
To: Pei, Mingliang; [email-masked]

Ming,

Ciao
Hannes

        - Ming

        ----- Original Message -----

        Hi all,

        Ciao
        Hannes

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 13 Jan 2009 22:29:27 +0200

Hi Anders, 

as usual, you raise very good points. 

>http://www.w3.org/2001/04/xmlenc#aes128-cbc ?

Correct. I should have added the URLs. 

>
>If http://www.w3.org/2001/04/xmlenc#kw-aes128 is selected it 
>is worth noting that http://www.w3.org/TR/xmlenc-core says:
>Since 160 bit isn't a multiple of 64 bits I would personally 
>choose http://www.w3.org/2001/04/xmlenc#aes128-cbc as the 
>default key-encryption algorithm to not run into problems or 
>have to use less established variants of KW-AES algorithms.
>

That's indeed an issue. 

In our phone conference call today Ming got the action item to check with
Russ on how this is accomplished with kw-aes128. He will post a mail to the
list. 

Ciao
Hannes

>To: "'Pei, Mingliang'" <[email-masked]>; "'Philip Hoyer'" 
><[email-masked]>; <[email-masked]>
>y-container-06.txt describes the AES-128-CBC encryption 
>algorithm as mandatory to implement.
>
>It was suggested to switch from AES-128-CBC to KW-AES-128 as 
>the mandatory algorithm.
>
>Please indicate your preference (if possible with arguments 
>why you want one or the other).
>
>the decision to KW has been made in the follow up calls. 
>Thanks for the update.
>well considered in the example now, and I will update the 
>draft to reflect the specifications and example data. The mac 
>key choice is the encryption key by default and we need to 
>come out a way to allow other mac key as we discussed during 73th ietf.
>
>versions so that they can verify each other. Hope to get 
>another reference check.
>
>        - Ming
>
>the examples will be
>verified, i.e., when there
>provided in the document

---

From: "Matt Ball" <[email-masked]>
Date: Wed, 14 Jan 2009 05:29:29 -0700

Hi Folks,

>From a NIST (i.e., FIPS 140-2) point-of-view, the only currently approved
symmetric algorithm for protecting keys is AES Key Wrap (e.g., KW-AES-128).
NIST will likely expand the list of approved algorithms in the next couple
years, but I'm sure that they will always have a requirement to include both
confidentiality and integrity.  For this reason, if the decision is for
AES-128-CBC, I would recommend adding an HMAC-SHA for integrity.  AES Key
Wrap already adds in a 64-bit integrity check, so this comes for 'free'.

Preferences:
1) AES Key Wrap
2) AES-CBC with HMAC-SHA

Cheers,
-Matt

On Mon, Jan 12, 2009 at 4:06 PM, Hannes Tschofenig <
[email-masked]> wrote:

> y-container-06.txt<http://www.ietf.org/internet-drafts/draft-ietf-keyprov-portable-symmetric-key-container-06.txt>describes the AES-128-CBC encryption algorithm as
> mandatory to implement.
>

-- 
Thanks!
-Matt

Matt Ball, IEEE P1619.x SISWG Chair
Cell: 303-717-2717
http://www.linkedin.com/in/matthewvball
http://www.mavaball.net/
_______________________________________________
KEYPROV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/keyprov

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 14 Jan 2009 14:13:47 +0100

> It was suggested to switch from AES-128-CBC to KW-AES-128 as the mandatory
...
> So, let's us do a quick poll. 

KW-AES-128.  Integrity checking is useful to detect certain attacks or
attacks attempts.

/Simon

---

From: "Reddy, Raksha Patel" <[email-masked]>
Date: Wed, 14 Jan 2009 11:27:16 -0500

I prefer KW-AES-128.  It's better to use an algorithm specifically
designed to encrypt keys as opposed to ordinary data. 

Raksha Reddy
National Security Agency

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Sean Turner
Sent: Tuesday, January 13, 2009 7:49 AM
To: Hannes Tschofenig
Cc: [email-masked]
Subject: Re: [KEYPROV] KW-AES-128 vs. AES-128-CBC

KW-AES-128

Hannes Tschofenig wrote:
> Hi all,
> 
> Section 6.1.1. of
> http://www.ietf.org/internet-drafts/draft-ietf-keyprov-portable-symmet
> ric-ke y-container-06.txt describes the AES-128-CBC encryption 
> It was suggested to switch from AES-128-CBC to KW-AES-128 as the 
> mandatory algorithm.
> 
> Please indicate your preference (if possible with arguments why you 
> want one or the other).
>   
On 
the 
update.
[email-masked]
will be the 
are well 

results before 
has two 
> 		that they can verify each other. Hope to get another
reference 
mentioned that the 
verified, 
> 		        is a digital signature then enough information
is provided 
> in the
is done in
Appendix B)

---

From: <[email-masked]>
Date: Mon, 19 Jan 2009 16:49:00 -0500

I prefer KW-AES-128.  

Note that we originally did not specify KW-AES-128 as
mandatory-to-implement as we assumed that it was not widely implemented
by vendors, esp. HSM vendors.  Phillip Hoyer and I had an email exchange
about this in Dec 2008 wherein he said, "I checked with two vendors of
HSMs and AES keywrap seems to be supported.  It is also supported in
Java JCE since SDK 1.5."

Russ Housley and I also had an email exchange about this topic in Dec
2008, where Russ stated: "I Believe that AES Key Wrap is widely
supported by vendors that care about FIPS 140.  Beyond that, I do not
believe that AES CBC meets the security requirements.  A companion
integrity algorithm is needed.  That is one of the really nice
properties of AES Key Wrap; you get confidentiality and integrity. AES
Key Wrap with a 128-bit key is fine for protection of keys up to 128
bits.  This seems to be the right size for the KEYPROV work."

Note also the similarities between RFC-3394 and kw-aes128 from the W3C
XML Encryption spec; given several close resemblances between them, it
appears they are intended to be equivalent.  Assuming they are
well-aligned, not only is KW-AES-128 approved for FIPS140-2, but as
http://www.w3.org/2001/04/xmlenc#kw-aes128, it is also a standard for
the W3C.

Andrea

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hannes Tschofenig
Sent: Monday, January 12, 2009 6:07 PM
To: 'Pei, Mingliang'; 'Philip Hoyer'; [email-masked]
Subject: [KEYPROV] KW-AES-128 vs. AES-128-CBC

Hi all, 

Section 6.1.1. of
http://www.ietf.org/internet-drafts/draft-ietf-keyprov-portable-symmetri
c-ke
y-container-06.txt describes the AES-128-CBC encryption algorithm as
mandatory to implement.

mandatory
algorithm. 

During the meeting we had a very brief chat about this topic, see (and
hear):
http://www.ietf.org/proceedings/08nov/slides/keyprov-2/keyprov-2.htm
ftp://videolab.uoregon.edu/pub/videolab/media/ietf73/ietf73-ch8-wed-am2.
mp3
 
I checked the meeting minutes and noticed that they do not capture a
lot:
http://www.ietf.org/proceedings/08nov/minutes/keyprov.txt

Please indicate your preference (if possible with arguments why you want
one
or the other). 

Ciao
Hannes

	 
	- Ming

		From: Philip Hoyer

		Ming,

will

		Philip

are
reflect
encryption
key by default and we need to come out a way to allow other mac key as
we

		- Ming

		----- Original Message -----
		From: Hannes Tschofenig <[email-masked]>
		To: Pei, Mingliang; [email-masked]
		
		Ming,

		Ciao
		Hannes

		
has
		       
		        - Ming
		       
		        ----- Original Message -----
		       
		        Hi all,
		       
mentioned
is
		       
is

		        Ciao
		        Hannes

---

From: "Pei, Mingliang" <[email-masked]>
Date: Wed, 21 Jan 2009 19:06:30 -0800

Hi Russ,
 
Thank you very much for your inputs. I am just back from vacation trips
and get chance to reply this email thread. I am also copying keyprov
work group mailing list since another thread also rolled discussions
about the topic.
 
I agree that it is best to use the algorithm AES-KW that NIST endorses
and also is efficient. Since PSKC has to support any key length (20 byte
HOTP as an example), we need to finalize on the padding choice. From
this email thread, we have two action items to use AES-KW:
 
1. Padding standard that you plan to work with NIST and propose as a
RFC. The timeline looks fine to PSKC if it is resolved in a few weeks.
2. Register new URI that indicates the AES-KW-<padding>. The existing
one from xmlenc doesn't imply any padding. This might take a little bit
longer in order to get the URI from W3C.
 
We can try to resolve the above two items. It is right thing to do. If
we can get this done, I will recommend AES-KW-<padding> as the mandatory
one in PSKC. If not, your suggestion to list the three choice look good
to me with some variation. A server would have to implement two
algorithms - AES-CBC with HMAC-SHA1 and AES-KW without padding. A client
application usually only needs to support one of them according to the
key size it needs to provision. If we had AES-KW with padding, I would
prefer to not use AES-KW anymore, and always consistently use the
padding one where no padding is a special padding similar to the PKCS#7
padding scheme for AES-CBC.
 
This is also my vote to the question that Hannes posted in another
thread.
 
Shall we proceed with this plan?
 
Thanks,
 
- Ming

	From: Russ Housley [mailto:[email-masked]] 
	Sent: Friday, January 16, 2009 7:55 AM
	To: Philip Hoyer; Pei, Mingliang
	Cc: Hallam-Baker, Phillip; Hannes Tschofenig;
[email-masked]; Salah Machani; [email-masked]
	Subject: RE: Advice needed: how shall we use AES-128-KW to wrap
any length of keys?

	Yes, I am advocating the use of AES Key Wrap.  I am not trying
to prohibit the use of other algorithms by consenting peers.
	
	I would be very unhappy is the specification said that AES-CBC
along with HMAC-SHA1 as the MUST implement algorithm.  While this would
not be a problem for environments where HMAC-SHA1 was already being
used, it imposes the implementation of SHA1 on crypo modules that might
not otherwise needed it.  In all cases, the AES codebook is already
present.
	
	Some specifications in the security area do not pick a mandatory
to implement algorithm.  RFC 5280 is one example.  Instead the companion
specifications tell what algorithm is appropriate for a particular
environment.  So, in this case, at least three algorithm suites could be
specified:
	
	        - AES-CBC with HMAC-SHA1
	        - AES-KW without padding
	        - AES-KW with padding
	
	Then, specifications that make use of the key packages could
state which one(s) are appropriate for their application.
	
	Russ
	
	At 05:25 AM 1/16/2009, Philip Hoyer wrote:

		Russ,
		The question here is really about support to wrap any
kind of key with any length.
		 
		Especially since the OTP algorithm specifications in
IETF (HOTP, TOTP, OCRA) are HMAC-SHA1 based and hence have keys of 20
bytes which are not multiple of 8.
		 
		We wanted to make 1 key payload protection mechanism
mandatory in DSKPP and PSKC and the current draft indicates AES-128-CBC
with HMAC-SHA1 MAC for integrity.
		 
		Based on these considerations would you advise us to
change this and make KW-AES-128 the mandatory algorithm and if so what
do we need to consider in terms of protecting non 8 multiple length keys
such as the HOTP 20 byte keys.
		 
		Thanks for your help,
		 
		Philip

		From: Russ Housley [ mailto:[email-masked]
<mailto:[email-masked]> ] 
		Sent: Thursday, January 15, 2009 9:46 PM
		To: Pei, Mingliang
		Cc: Hallam-Baker, Phillip; Philip Hoyer; Hannes
Tschofenig; [email-masked]; Salah Machani; [email-masked]
		Subject: Re: Advice needed: how shall we use AES-128-KW
to wrap any length of keys?
		 
		Sorry for the delayed response.  It is important to me
that NIST and the IETF proceed in the same manner here.  That is, we
want to make sure that the outcome will be considered a FIPS-approved
mode.
		
		RFC 3394 provides a solution where no padding is needed,
which is appropriate for wrapping all three AES key sizes.
		
		The initial value of the A register, described as A[0]
can be used to flag the use of padding.  I'm still discussing the
details with NIST.  Once resolved, I'm pleased to help write an RFC to
fully describe this padding technique.  I have every reason to believe
that this can be worked out in a week or so.
		
		I _greatly_ prefer the AES-KW as the mandatory to
implement, but I agree that a combination of an AES-CBC and MAC
algorithm can offer the same level of security.  Depending of the MAC
chosen, the use of AES-KW is a lot less code.
		
		Russ
		
		At 07:34 PM 1/13/2009, Pei, Mingliang wrote:
		
		Hi Russ,
		 
		Happy New Year!
		 
		On deciding between KW-AES vs. AES as the mandatory key
encryption algorithm in PSKC, Anders noted that KW-AES-128 by RFC3394
assumes the size of the key to be wrapped is multiple of block size. We
consider that some padding can be done to support any length of key (at
least two times of the block size of an encryption algorithm). You are
our expert in this area as the author of RFC3394. We believe that you
must have also thought of ways to support any size of keys for wrapping.

		Could you advise us on the following two questions?
		 
		1. What padding would you recommend when using
KW-AES-xxx algorithms?
		 
		I am thinking that PKCS7 padding would simply work as we
do for AES-CBC on any size of plaintext.
		 
		2. When PSKC already supports a MAC value along with
wrapped key value, the purpose of "key wrapping algorithm KW-AES-xxx" is
already served so that AES-128-CBC can serve the same security level as
KW-AES-xxx. By this argument, we are fine to recommend either
AES-128-CBC or KW-AES-128 as the mandatory one.
		 
		Is this right?
		 
		If the above is true, I would recommend AES-128-CBC as
the mandatory one: (1) we don't need to worry padding part as it is well
understood with this. (2) the security level is the same and AES-128-CBC
is more widely supported than KW- counterparts (my claim though).
		 
		We would appreciate your advice and help on this. I look
forward to hearing from you soon.
		 
		Thank you,
		 
		- Ming

		From: Pei, Mingliang 
		Sent: Monday, January 12, 2009 2:37 PM
		To: Anders Rundgren; Philip Hoyer; Hannes Tschofenig
		Cc: Hallam-Baker, Phillip; 'Doherty, Andrea';
[email-masked]
		Subject: RE: KW-AES-128 clashes with HOTP? Was:
[KEYPROV] Examples in PSKC
		Russ is the author of RFC3394 on this. Copying him for
more comments. Here is my understanding.
		 
		True that the original definition in RFC3394 and xmlenc
spec assumes the key length is multiple (n) of 64-bit data blocks.
		 
		http://tools.ietf.org/html/rfc3394
	
http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/Overview.html#kw-aes1
28 
		 
		I assume that padding can be independently applied on
the plaintext (key to be wrap) but cannot find a general standard yet.
One RFC that handles padding for key wrapping is the RFC3537 on wrapping
a HMAC key with 3DES and AES.
		 
		http://tools.ietf.org/html/rfc3537
		 
		The padding in that spec is new one, different from
known ones such as PKCS5 or PKCS7 padding. I was curious why PKCS5
cannot be simply used in key wrapping in the similar way to AES-CBC. 
		 
		Regardless, if we are determined to use kw-xxx, I think
that we could specify in PSKC how to do padding for any symmetric key
length. The key size should be at least 2 blocks for use of this per
RFC3394:
		 
		Quoted: "The only restriction the key wrap algorithm
places on n is that n be at least two.  (For key data with length less
than or equal to 64 bits, the constant field used in this specification
and the key data
		   form a single 128-bit codebook input making this key
wrap unnecessary.)"
		 
		On the other hand, the email reply by Hannes tried to
further clarify whether we are in agreement to change back to
KW-AES-128. AES-128-CBC is fine while we have ValueMAC for integrity
check in the schema.
		 
		- Ming

		From: Anders Rundgren [
mailto:[email-masked]] 
		Sent: Monday, January 12, 2009 1:29 PM
		To: Philip Hoyer; Pei, Mingliang; Hannes Tschofenig
		Subject: KW-AES-128 clashes with HOTP? Was: [KEYPROV]
Examples in PSKC
		Hi Guys,
		 
		Pardon my limited knowledge of "hardcore crypto" but
during some experiments with KW-AES-128 I found out that it seems to
require that the keys to be wrapped are a multiple of 8 bytes which
seems to clash with HOTP's recommended 20 byte-keys.
		 
		Anders
		----- Original Message ----- 
		From: Philip Hoyer
<mailto:[email-masked]>  
		To: Pei, Mingliang <mailto:[email-masked]>  ;
[email-masked] ; [email-masked] 
		Sent: Monday, January 12, 2009 11:31
		Subject: Re: [KEYPROV] Examples in PSKC
		Ming,
		We agreed on previous call that the KW version AES 128
will be the mandatory algorithm for PSKC and DSKPP so we need examples
using KW-AES-128
		 
		Philip

		From: [email-masked] [
mailto:[email-masked]] On Behalf Of Pei, Mingliang
		Sent: Monday, January 12, 2009 9:38 AM
		To: [email-masked]; [email-masked]
		Subject: Re: [KEYPROV] Examples in PSKC

		----- Original Message -----
		From: Hannes Tschofenig <[email-masked]>
		To: Pei, Mingliang; [email-masked]
		
		________________________________
		        From: [email-masked] [
<mailto:[email-masked]> mailto:[email-masked]] On
		Behalf Of ext Pei, Mingliang
		        Sent: 15 December, 2008 09:25
		        To: [email-masked]; [email-masked]
		        Subject: Re: [KEYPROV] Examples in PSKC

		        - Ming
		       
		        ----- Original Message -----
		       
		        Hi all,

		       
		       
		        Ciao
		        Hannes

---

From: "Pei, Mingliang" <[email-masked]>
Date: Wed, 21 Jan 2009 19:22:21 -0800

key to be wrapped isn't multiple blocks. Russ suggested a route to solve
this. I have described my vote in that email reply:

- Assess and try to define AES-KW-<padding> in the time frame we expect.

Thanks,

- Ming

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Monday, January 19, 2009 1:49 PM
> To: [email-masked]; Pei, Mingliang; 
> [email-masked]; [email-masked]
> Subject: RE: [KEYPROV] KW-AES-128 vs. AES-128-CBC
> 
> I prefer KW-AES-128.  
> 
> mandatory-to-implement as we assumed that it was not widely 
> implemented by vendors, esp. HSM vendors.  Phillip Hoyer and 
> I had an email exchange about this in Dec 2008 wherein he 
> said, "I checked with two vendors of HSMs and AES keywrap 
> seems to be supported.  It is also supported in Java JCE 
> since SDK 1.5."
> 
> Russ Housley and I also had an email exchange about this 
> topic in Dec 2008, where Russ stated: "I Believe that AES Key 
> Wrap is widely supported by vendors that care about FIPS 140. 
>  Beyond that, I do not believe that AES CBC meets the 
> security requirements.  A companion integrity algorithm is 
> needed.  That is one of the really nice properties of AES Key 
> Wrap; you get confidentiality and integrity. AES Key Wrap 
> with a 128-bit key is fine for protection of keys up to 128 
> Note also the similarities between RFC-3394 and kw-aes128 
> from the W3C XML Encryption spec; given several close 
> resemblances between them, it appears they are intended to be 
> equivalent.  Assuming they are well-aligned, not only is 
> KW-AES-128 approved for FIPS140-2, but as 
> http://www.w3.org/2001/04/xmlenc#kw-aes128, it is also a 
> standard for the W3C.
> 
> Andrea
> 
> [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
> 	It was an issue raised during 73-th IETF. I wasn't 
> aware that the decision to KW has been made in the follow up 
> calls. Thanks for the update.
> 		We agreed on previous call that the KW version 
> AES 128 will be the mandatory algorithm for PSKC and DSKPP so 
> we need examples using
> KW-AES-128
> 
> 		 
> 
> 		Philip
> 
> 		 
> 
> 		Yes, I have done AES128-CBC examples. The 
> padding and iv are well considered in the example now, and I 
> will update the draft to reflect the specifications and 
> example data. The mac key choice is the encryption key by 
> default and we need to come out a way to allow other mac key 
> as we discussed during 73th ietf.
>

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 23 Jan 2009 10:44:42 +0200

>[mailto:[email-masked]] On Behalf Of ext Simon Josefsson
>Sent: 14 January, 2009 15:14
>To: [email-masked]
>KW-AES-128.  Integrity checking is useful to detect certain 
>attacks or attacks attempts.
>
>/Simon