Subject: Re: [KEYPROV] PSKC

From: "Salah Machani" <[email-masked]>
Date: Sun, 6 Apr 2008 13:03:16 -0400

Philip,

I reviewed the spec in general and have few comments.  Overall it looks good. One of the items we discussed during the last f2f meeting was to generalize the use cases to cover symmetric keys in general and not only OTP tokens.  I tried to cover this as well in my comments below. I will review the schema and samples separately and send you comments if any. 

Section 3. Use Cases

-	Change the second statement to read as "These use cases were used to derive the primary requirements..." Instead of "These requirements...".

Section 3.1.1 -  Key migration by end-user

Change the first paragraph to read as follows: 

A user wants to migrate a key from one device to another device.  For example, the first device may be a desktop computer and the second device may be a mobile phone with an authentication SoftToken.  The user can export the key and related data in a standard format from the first device for import into the second device.

Section 3.1.2 Bulk import of new keys

   Change the first paragraph to read as follows: 

Devices with pre-loaded symmetric keys such as authentication tokens are manufactured in bulk and associated keys and algorithm data need to be loaded into the company system through a file on portable media.  The manufacturer provides the keys and related data in the form of a file containing records in standard format, typically on a CD.  Note that the device manufacturer and the vendor for the company system may be the same or different.

Section 3.1.3 bulk migration of existing keys

   A company wants to port keys and related data from an existing system A into another system B and preserve the same devices that are provisioned with these keys.  System A provides the company with a functionality that enables export of keys and related data (e.g. OTP Token key records) in a standard format.  Since the key records related data are in the standard format, the company can import the key records into the new system B and start using the existing devices.  Note that the vendors for the two systems may be the same or different.

Section 3.1.4 - key upload use case

- Change title to: key upload

- Change the first paragraph to read as follows: 

User wants to activate and use a new key and related data against a company system such as an Authentication system that is not aware of this key.  This key may be embedded in the user's device (e.g.  SD card, USB drive) that the user has purchased at the local electronics retailer.  Along with the device, the user may get the key on a CD or a floppy in a standard format.  The user can now upload via a secure online channel or import this key and related data into the new company system and start using the key.

- Change second paragraph to read as follows:

The key protection mechanism may rely on password-based encryption,  or a pre-placed hardware-protected transfer key shared between the device manufacturer and the company system(s) if available.

Section 3.2.1 online provisioning of key to end user's authentication token

- Change title to: online provisioning of key to end user's device

- Change the first paragraph to read as follows:

A mobile device user wants to obtain a symmetric key for use with a client application on the device such as a SoftToken application.  The application from vendor A initiates the provisioning process against a provisioning system from vendor B using a standards-based provisioning protocol such as [DSKPP].  The provisioning system delivers one or more keys in a standard format that can be processed by the mobile device.  The user can download a payload that contains more than one key.

Section 3.2.2 - server to server provisioning of keys

- Change the first paragraph to read as follows:

Sometimes, instead of importing keys from a manufacturer using a file, a company system such an authentication system may download the keys using an online  protocol.  The keys can be downloaded in a standard format that can   be processed by the company system.

- Change the second paragraph to read as follows:

In another scenario, an over-the-air (OTA) key provisioning gateway that provisions keys to mobile phones may obtain key material from a key issuer using an online protocol.  The keys are delivered in a standard format that can be processed by the OTA key provisioning gateway and subsequently sent to the end-user's mobile phone.

Section 3.2.3 - online update of an existing authentication token key

- Change title to: online update of an existing end user device keys

- Change the first paragraph to read as follows:
  
 The end-user or the key issuer wants to update or configure an
   existing key in the user's device requests a replacement
   key container.  The container may or may not include a new key and
   may include new or updated key attributes such as a new counter value
   in HOTP key case, a modified response format or length, a new
   friendly name, etc.

Section 5.2.1

1st paragraph, 4 statement: change '...two different token manufacturers...' to '...two different device manufacturers...' 

Section 5.3.2 Usage

- what this reason for making the key usage element mandatory?  If for example the key container is used to update one or more of the existing key attributes but not the key data (e.g. FriendlyName or the PINpolicy),  why do we need to have the keyUsage set? Should the recipient of the container override the existing keyUsage of the identified key?  

Section 5.3.3

- In OCRA only NUMERIC, ALPHANUMERIC and HEX formats are supported.  

Section 5.3.4.1 - 

- Typos in last paragraph, <prepend> bullet - change the word hance to hence and the word chacked to checked.

Section 6.1.2

Should we add http://www.w3.org/2001/04/xmlenc#kw-aes192 algorithm uri as optional?

Section 6.3.2 - type in 1st paragraph : change the word 'comaparison' to comparison

Section 9.1 payload confidentiality

The section needs to be re-organized to make it more readable e.g. start new paragraph when describing the asymmetric key encryption, combine and rephrase the paragraphs covering password-based encryption, remove the word 'practical' in 'practical implementations' and just say implementations, etc.

These are my initial comments.

Regards,

Salah

-----Original Message-----
From: Philip Hoyer [mailto:[email-masked]] 
Sent: March 20, 2008 4:35 PM
To: Pei, Mingliang; Hannes Tschofenig; Salah Machani; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: PSKC

Ladies and Gentlemen,

Please note the main issues are the ones on the last slide of the presentation given at IETF that was sent around.

Can we try to split up the work as following please:

Ming
- Could you please look at generating a proper asymmetric example and add the example to section 6.2.
- change URI xxx/pskc#valuecompare to xxx/pskc#pin in section 6.3. #valuecompare is not a good name for type of credential (PIN).
- Clean up reference section (some reference may not be "Normative" such as OATHRefArch )

Salah
- Review the security considerations section based on the new spec
- Review and comment on following proposal for the schema that has a key template concept.
I was thinking we have a sequence of key objects in the KeyContainer Element with the name KeyTemplates. The KeyId would then be the unique Id of the template. We will then extend the Key entity with an attribute called KeyTemplate Id. If this attribute is set the default values for that key are taken out of that key template. If a value is present in the key instance itself it will override the template value.
- Generally review the spec

Hannes and Philip Hallam-Baker
- I need your help for the IANA section. Could you write the content for the IANA consideration section please. We agreed that we would ask IANA to create 2 registers one for algorithms URIs and one for the key-metadata semantics.

After we have the IANA section I can clean up the issue for:
-Clean up references to OTP algorithm URI in Section 6.3.1.2
Reference Eastlake informational RFC 
Specify some locally (RSA SecurID, ActivIdentity,others)?

I will do the rest:
- More clarification of ValueMac for specific transport security options (eg asymmetric, kw- algos not all HSMs)
- TODO: Extend definition of userId for user device binding, current proposal is DN style (OU=Engineering, CN=James...)
- TODO: Add definition of type in DerivedKey

We also need to discuss if we want to move to String for the plainparameter instead of base64binary, I am in favour of it.

Thanks for your help,
Philip

-----Original Message-----
From: Pei, Mingliang [mailto:[email-masked]] 
Sent: Tuesday, March 18, 2008 5:58 PM
To: Hannes Tschofenig; [email-masked]
Cc: Philip Hoyer
Subject: RE: PSKC

I am pretty busy this week as I am preparing two conferences next week
when I travel to Dulles from Monday to Thursday. I will try to work on
some issues though.

Can we have a quick meeting by this Thursday to go over list of open
issues, and see how we distribute the work? For some issues that I sent
to Philip before the IETF meeting, several are straight updates, and I
know where they are to change and I can changes in the draft before next
Tuesday.

- Ming

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: Tuesday, March 18, 2008 3:15 PM
> To: [email-masked]; Pei, Mingliang
> Cc: [email-masked]
> Subject: PSKC
> 
> Hi Salah,
> Hi Ming,
> 
> I met Philip last week in Philly. I told him that our SecAD 
> wants to see the work moving forward a bit faster.
> Hence, it would be great to see a draft update early next week.
> 
> Who of you has time to work through some open issues?
> 
> Ciao
> Hannes
> 
> 

Notice to Recipient: The information in this message (and attachments, if any) is meant only for the intended recipient of the transmission and may contain confidential or privileged information.  Any copying, retransmittal, taking of action in reliance on, or other use of the information in this communication by persons other than the addressees is prohibited.  If you received this email in error, please immediately notify us and please delete or destroy all copies of this message.  This message may have been altered without your or our knowledge and the sender does not accept any liability for any errors.  Thank you.
_______________________________________________
KEYPROV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/keyprov