Subject: [KEYPROV] FW: New Version Notification for draft-ietf-keyprov-pskc-06

From: "Philip Hoyer" <[email-masked]>
Date: Fri, 14 May 2010 16:20:16 +0200

Please note the new version and also attached xml source.

No Schema changes from -05.

This addresses:

*	SecDir comments (ALL)
*	Sean Turner comments (MOST)
*	Russ Housley comments (MOST)
*	Alexey Melnikov comments (MOST)
*	Pete SaintAndre comments (MOST) TODO and discuss:
o	Globally unique KeyId
o	Version number increment (needs alignment with DSKPP I think)
o	Normative reference to TLS?
o	Definition of PIN algorithm

Let's keep up the work get this finished.

Philip

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: Friday, May 14, 2010 3:13 PM
To: Philip Hoyer
Cc: [email-masked]; [email-masked]
Subject: New Version Notification for draft-ietf-keyprov-pskc-06 

A new version of I-D, draft-ietf-keyprov-pskc-06.txt has been
successfully submitted by Philip Hoyer and posted to the IETF
repository.

Filename:	 draft-ietf-keyprov-pskc
Revision:	 06
Title:		 Portable Symmetric Key Container (PSKC)
Creation_date:	 2010-05-14
WG ID:		 keyprov
Number_of_pages: 63

Abstract:
This document specifies a symmetric key format for transport and
provisioning of symmetric keys to different types of crypto modules.
For example, One Time Password (OTP) shared secrets or symmetric
cryptographic keys to strong authentication devices.  A standard key
transport format enables enterprises to deploy best-of-breed
solutions combining components from different vendors into the same
infrastructure.

The IETF Secretariat.

---

From: Sean Turner <[email-masked]>
Date: Mon, 17 May 2010 12:28:55 -0400

> No Schema changes from -05.

I think Vincent suggested some additional text for Section 13.3:

"Authenticity guarantee may be provided by [...]. However, no 
authenticity verification is possible once [...]. Since the TLS 
endpoints could differ from the key provisioning endpoints, this 
solution is weaker than the previous solution that relies on a digital 
signature of the PSKC."

I think if you make this tweak all of his comments are addressed.

> *	Sean Turner comments (MOST)

The two outstanding comments I have:

#1) You're pointing to the List of OATH Manufacturer Prefixes.  There 
are two columns in that list: prefixes and the manufacturer name. 
It's not entirely clear which column the values should be taken from. 
  It's either:

Values for Manufacturer SHOULD be taken from [OATHMAN] prefixes (i.e., 
the left column).

or

Values for Manufacturer SHOULD be taken from [OATHMAN] manufacturer 
list (i.e., the right column).

#2) Add a normative pointer to Section 4 of the ASN.1 document for how 
to encode a key prior to it being encrypted.

> *	Russ Housley comments (MOST)

I think you're mostly waiting for Russ to respond right?

> *	Alexey Melnikov comments (MOST)

I think you've done all but two, but you're waiting on Alexey to 
respond - right?

> *	Pete SaintAndre comments (MOST) TODO and discuss:

Do we really need a globally unique KeyId? The examples in the 
document definitely don't use one.  If we do, then I'd suggest we 
generate the keyId using a hash algorithm and be done with it.

> o	Normative reference to TLS?

I think he read:

  The second approach to protecting the confidentiality of the key data
  payload is based on using transport layer security.  The secure
  channel established between the source secure perimeter (the
  provisioning server from the example above) and the target perimeter
  (the device attached to the end-user computer) utilizes encryption to
  transport the messages that travel across.  No key data payload
  encryption is required in this mode.  Secure channels that encrypt
  and digest each message provide an extra measure of security.

and reacted to "transport layer security" and "secure channel" because 
they strongly imply TLS.  I think if we tweaked it to say the 
following then we'd be okay:

  The second approach to protecting the confidentiality of the key data
  is based on using lower layer security mechanisms (e.g., [TLS],
  [IPsec]).  The secure connection established between the source
  secure perimeter (the provisioning server from the example above) and
  the target perimeter (the device attached to the end-user computer)
  utilizes encryption to protect the messages that travel across that
  connection.  No key data payload encryption is required in this mode.
  Secure connections that encrypt and digest each message provide an
  extra measure of security.

And add two informative references to TLS and IPSEC and we're done.

> o	Definition of PIN algorithm

I think we're probably going to have to add it here.  Otherwise, we're 
going to have to wait for a new draft and that'll take forever.

---

From: "Philip Hoyer" <[email-masked]>
Date: Tue, 18 May 2010 15:30:24 +0200

Sean,
[PH] inline

-----Original Message-----
From: Sean Turner [mailto:[email-masked]] 
Sent: Monday, May 17, 2010 5:29 PM
To: Philip Hoyer
Cc: KEYPROV; [email-masked]
Subject: Re: [KEYPROV] FW: New Version Notification for
draft-ietf-keyprov-pskc-06

[PH] changed this but wanted to put [TLS] or [IPsec] in the first [...]

[PH] adopted prefixes

or

> *	Russ Housley comments (MOST)

[PH] I addressed his Comment and waiting for him to respond on the
Discuss items

[PH] correct

Do we really need a globally unique KeyId? The examples in the 
document definitely don't use one.  If we do, then I'd suggest we 
generate the keyId using a hash algorithm and be done with it.
[PH] I believe this is one item that warrants wider discussion. Do you
know what they have done in KMIP? 

I think he read:

[PH] changed the text but could you point me at the right references for
TLS and IPsec?

[PH] what should we say here.
It is a PIN in ASCII (1 byte per character) and a straight octet
comparison? Or should we support UTF-8? What is your feeling?

---

From: Sean Turner <[email-masked]>
Date: Tue, 18 May 2010 09:49:23 -0400

Philip,

I cut out the ones I think we're square on.  Note that sending an 
email to those authors you're waiting on will probably pop it to the 
top of their stack.

Additional thoughts below with [spt].

Andrea,

There's one DSKPP/PSKC alignment issue.

> know what they have done in KMIP? 

[spt]  I took this text from KMIP.  It's out for public comment:

Unique Identifier

The Unique Identifier is generated by the key management system to 
uniquely identify a Managed Object. It is only REQUIRED to be unique 
within the identifier space managed by a single key management system, 
however it is RECOMMENDED that this identifier be globally unique in 
order to allow for a key management domain export of such objects. 
This attribute SHALL be assigned by the key management system at 
creation or registration time, and then SHALL NOT be changed or 
deleted before the object is destroyed.

If we want to be globally unique then we're going to need to use 
something provides a reasonable distribution.  We could follow the 
PKIX lead and pick a couple of fields to hash (possibly truncating it).

>> o	Version number increment (needs alignment with DSKPP I think)

Andrea - any thoughts here?

> [PH] changed the text but could you point me at the right references for

[spt] sent in another email.

> comparison? Or should we support UTF-8? What is your feeling?

The minute you use ASCII they're going to be all over you about 
character set support.  Because we've already got to do UTF-8 for 
other things - we should probably just go with that.