Subject: [KEYPROV] [issue22] PSKC: work on clarifications and updates for comments received

From: Mingliang Pei <[email-masked]>
Date: Wed, 20 Jun 2007 14:41:17 +0000

New submission from Mingliang Pei <[email-masked]>:

Quoted Andrea's comments about PSKC:

I reviewed draft-vassilev-portable-symmetric-key-container-02.txt, which is 
essentially the same as draft-hoyer-keyprov-portable-symmetric-key-container-
00.txt, and have the following comments:

General
1. Should draft be scrubbed of "OATH" and made more generic to types of 
authentication tokens, such as RSA SecurID, which are not produced by OATH?
2. Although the first application of the PSKC will be for authentication 
tokens, it could be applicable to other symmetric key management use cases 
(e.g., those considered in IEEE P1619.3.  As such, it would be good to 
generalize where possible, with provisioning of authentication tokens as a near-
term goal and/or as an example application, rather than as the target 
application.
3. XML schema itself needs to be more carefully reviewed, but waiting until 
comments are addressed.

Section 1
1. "The goal is that the format will facilitate dynamic provisioning of OTP 
credentials using an OTP provisioning protocol to different flavors of embedded 
tokens ...from different vendors into the same infrastructure."  
*	This is very specific; perhaps it would better to mention this
as a sample use case rather that a goal for the format.  
2. Why is a "more explicit attribute schema definition" more desirable than 
PKCS#12?  Doesn't that also make the format more heavyweight?

Section 4.
1. Would be good to generalize the "event counter value" and "time value" OTP 
attributes.

Section 5.1
1. Friendly Name is missing.

Section 5.1.1
1. The attribute names are repeated in Section 6.1.1.
2. Attribute list should be extensible.

Section 5.1.4
1. "global identifier" --- relative to what?  What is the base of the 
hierarchy?  For example, could it be the IEEE registry?

Section 5.1.5
1. Please provide an example of what is meant by "Issuer".

Section 5.1.6
1. Although not necessarily applicable here, where would a PIN policy be 
defined?  In other words, if the symmetric key is loaded on an authentication 
token, will the token be a PIN-less or PIN-full one --- and where can that be 
set as an attribute?

Section 5.1.7
1. The EncryptionMethod is only Mandatory when the
SecretContainer->SecretType->Data->Value is encrypted (also, please
refer to last paragraph of Section 6.1.1).

Section 5.1.9
1. Are these attributes mandatory or optional?  I would assume Optional if the 
format is intended for broader application than authentication tokens.
2. OTP attributes are not covered in any sub-sections of 5.1.9...

Section 6.1.1
1. "Usage" implies that each secret in a "Device" could support a different 
algorithm.  Correct?
2. "userPIN" - is the intent to have a different PIN for each secret stored in 
a Device?  If no PIN is provided, the assumption is no PIN is required?  Is 
this a correct interpretation?  Where might a PIN policy fit here (also refer 
to comment on Section 5.1.6, above)?
3. "SecretId" - perhaps this should have a more structured type than "string", 
esp. one that could be represented as a URI should this be a global identifier.
4. "Issuer" - is this the same thing as "ServiceID" used in DSKPP (see draft-
pei-keyprov-dynamic-symkey-prov-protocol-00.txt, Sec. 6.2)?

Section 6.1.2
1. UsageType->AlgorithmIdentifier should be defined by an IANA identifier or a 
URI rather than an OCRA one.
2. Is UsageType->AlgorithmIdentifier the same identifier as described in 
Section 6.1.9 as "OTPAlgorithmIdentifier"?  Judging by the schema 
for "UsageType" described in Sec 6.1.2, it appears that Usage is limited to
OTP.   Is that really the goal?
2. "Access Rules" -- typo - "weather" should be "whether".

Section 6.1.3
1. There is a constraint specified here that could get lost, and should 
probably be added to the description of the Secret Container in Section 6.0.  
That is "a shared secret MUST be bound to one Device only".  The only 
implications of this constraint that I can think of are  applicable to the 
provisioning system than the container format (e.g., the secrets in a device 
may not be cloned).  Perhaps there are some that are specific to the container?

Section 6.1.4
1. "Since OATH devices" is too specific...
2. "identifying criteria" should be specified consistently along with 
applicability information, e.g., by registering IANA numbers.
3. "SerialNo" -- is this what is used to comply with statement that "criteria 
MUST identify uniquely the device"?  If so, is the SerialNo also going to have 
global scope?  To satisfy the use cases around cross-vendor credential 
migration, it would seem this is a requirement.

Section 6.1.9
1. Where does this fit?  See comments under Section 6.1.2, above.
2. "OCRA-HOTP", etc. --- see comment under Section 6.1.2, above.

Section 6.5
1. HOTP is quite specific, and perhaps other OTP algorithm types should be 
included.

----------
assignedto: mpei
messages: 37
nosy: keyprov, mpei
priority: urgent
status: in-progress
title: PSKC: work on clarifications and updates for comments received

_________________________________________________________
KEYPROV Roundup Issue Tracker <[email-masked]>
<http://www.tschofenig.priv.at:8080/keyprov/issue22>
_________________________________________________________

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

---

From: Philip Hoyer <[email-masked]>
Date: Wed, 27 Jun 2007 18:18:42 +0200

Please find below comments from the authors

-----Original Message-----
From: Doherty, Andrea [mailto:[email-masked]]
Sent: 07 May 2007 21:54
To: [email-masked]
Subject: [KEYPROV] Comments on PSKC I-D

I reviewed draft-vassilev-portable-symmetric-key-container-02.txt, which
is essentially the same as
draft-hoyer-keyprov-portable-symmetric-key-container-00.txt, and have
the following comments:

General
1. Should draft be scrubbed of "OATH" and made more generic to types of
authentication tokens, such as RSA SecurID, which are not produced by
OATH?
[Comment] Yes we will scrub OATH and add generic mentions to tokens not
produced by OATH

2. Although the first application of the PSKC will be for authentication
tokens, it could be applicable to other symmetric key management use
cases (e.g., those considered in IEEE P1619.3.  As such, it would be
good to generalize where possible, with provisioning of authentication
tokens as a near-term goal and/or as an example application, rather than
as the target application.
[Comment] Philip will re-phrase and editors will review

3. XML schema itself needs to be more carefully reviewed, but waiting
until comments are addressed.
[Comment] Agreed

Section 1
1. "The goal is that the format will facilitate dynamic provisioning of
OTP credentials using an OTP provisioning protocol to different flavors
of embedded tokens ...from different vendors into the same
infrastructure."  
*	This is very specific; perhaps it would better to mention this
as a sample use case rather that a goal for the format.  
[Comment] We agree that this is one of the most common use cases but
there are others. Philip will re-phrase and editors will review

2. Why is a "more explicit attribute schema definition" more desirable
than PKCS#12?  Doesn't that also make the format more heavyweight?
[Comment] For the main use case for OTP secret provisioning, more
explicit attributes such as those for OTP specific configuration 
attribute names and XML schema are helpful for inter-op and clarity. The
specification of key attributes for known key types such as OTP
won't significantly add complexity or size. Instead, we think that it
helps to provide simplicity without using opaque structures. 
Secondly, it doesn't need to support the asymmetric key related portion
in PKCS#12, which makes it more lightweight. 

Well, there is also the debate on the consideration that XML is more
heavyweight than ASN.1 format in general. For a provisioning protocol
in XML, the key container format in XML is a natural choice as well,
which I believe that you are not questioning. Using even some
XML version of converted PKCS#12 was considerd not an optimal way to
support this symmetric key oriented format. Let us know if you feel 
that the above statement may not be sufficient and prefer some more
sentences similar to the information given here.

Section 4.
1. Would be good to generalize the "event counter value" and "time
value" OTP attributes.
[Comment] could you please clarify what you mean with 'generalizing'. Do
you mean the name for example event counter value call it moving factor?

Section 5.1
1. Friendly Name is missing.
[Comment] Noted and will be added

Section 5.1.1
1. The attribute names are repeated in Section 6.1.1.
[Comment] the purpose for the section is different, 5.1.1 is a more
generic description whereas 6.1.1 describes the schema type

2. Attribute list should be extensible.
[Comment] The list of attributes is already extensible. The attributes
are name value pairs and the name can be chosen by the implementer
besides the reserved names already present. We will add a more clear
description of how to extend the attributes. 
Our idea is to use the concept of profiles, which for specific algorithm
defines the set of attributes names and their semantic definition of
values.

Section 5.1.4
1. "global identifier" --- relative to what?  What is the base of the
hierarchy?  For example, could it be the IEEE registry?
[Comment] After a discussion we are thinking that SecretId should not be
globally unique but the combination of issuer and SecretId MUST be
unique.
This should also be joined with the consolidation of DeviceId and KeyId.

We suggest to the group to rename Secret to Key to be more aligned with
KEYPROV, DSKPP and the title of the spec.

Section 5.1.5
1. Please provide an example of what is meant by "Issuer".
[Comment] will add example but we mean the organization issuing the keys
to the end users eg a bank issuing hardware tokens (the bank) would be
the issuer.

Section 5.1.6
1. Although not necessarily applicable here, where would a PIN policy be
defined?  In other words, if the symmetric key is loaded on an
authentication token, will the token be a PIN-less or PIN-full one ---
and where can that be set as an attribute?
[Comment] we do not undesratdn the question since the section you are
referring to explains where the policy should be defined (eg setting
userPIN to true). Our current definition of PIN policy is the protection of
use of the key by a PIN eg a token with a PIN pad where the entry of the
correct PIN unlocks the functionality of the token (read generate OTP or
challenge response. Are you referring to the possibility of a more complex
PIN policy definition, or the possibility of defining how the PIN has to be
used within the OTP calculation? 

Section 5.1.7
1. The EncryptionMethod is only Mandatory when the
SecretContainer->SecretType->Data->Value is encrypted (also, please
refer to last paragraph of Section 6.1.1).
[Comment] Noted and will be corrected

Section 5.1.9
1. Are these attributes mandatory or optional?  I would assume Optional
if the format is intended for broader application than authentication
tokens.
[Comment] Noted and need to be added

2. OTP attributes are not covered in any sub-sections of 5.1.9...
[Coment] ResponseFormat is an OTP attribute and we define the Response
Format as format of an OTP wven if not in challenge response algorithm.
Maybe we need to make that more explicit.

Section 6.1.1
1. "Usage" implies that each secret in a "Device" could support a
different algorithm.  Correct?
[Comment] correct
2. "userPIN" - is the intent to have a different PIN for each secret
stored in a Device?  
[Comment] we support a different PIN for each secret.

If no PIN is provided, the assumption is no PIN is required?  
[Comment] yes
Is this a correct interpretation?  Where might a PIN policy fit here
(also refer to comment on Section 5.1.6, above)?
[Comment] currently we only support the policy that the PIN MUST be
checked if the 5.1.6 boolean is set to true

3. "SecretId" - perhaps this should have a more structured type than
"string", esp. one that could be represented as a URI should this be a
global identifier.
[Comment] Please see comment on KeyId

4. "Issuer" - is this the same thing as "ServiceID" used in DSKPP (see
draft-pei-keyprov-dynamic-symkey-prov-protocol-00.txt, Sec. 6.2)?
[Comment] Please see comment above

Section 6.1.2
1. UsageType->AlgorithmIdentifier should be defined by an IANA
identifier or a URI rather than an OCRA one.
2. Is UsageType->AlgorithmIdentifier the same identifier as described in
Section 6.1.9 as "OTPAlgorithmIdentifier"?  Judging by the schema for
"UsageType" described in Sec 6.1.2, it appears that Usage is limited to
OTP.   Is that really the goal?
[Comment] we will discuss this regarding the issue in the KEYPROV issue
tracker

2. "Access Rules" -- typo - "weather" should be "whether".
[Comment] Noted and will be changed

Section 6.1.3
1. There is a constraint specified here that could get lost, and should
probably be added to the description of the Secret Container in Section
6.0.  That is "a shared secret MUST be bound to one Device only".  The
only implications of this constraint that I can think of are  applicable
to the provisioning system than the container format (e.g., the secrets
in a device may not be cloned).  Perhaps there are some that are
specific to the container?
[Comment] After discussion we should not mandate the constraint but
recommend it. Also the recommendation should be moved to the 6.0
section.

Section 6.1.4
1. "Since OATH devices" is too specific...
2. "identifying criteria" should be specified consistently along with
applicability information, e.g., by registering IANA numbers.
3. "SerialNo" -- is this what is used to comply with statement that
"criteria MUST identify uniquely the device"?  If so, is the SerialNo
also going to have global scope?  To satisfy the use cases around
cross-vendor credential migration, it would seem this is a requirement.
[Comment] 1. Yes, word "OATH" will be removed, and the sentence will be
revised. 2. It is good to do so but not sure it should be a requirement.
In a certificate world, a certificate issuer and serial number together
is supposed to be unique. Certificate Authority name isn't in IANA while
signer can be identified. 3. The combination of the elements 
in the type including SerialNo is unique. SerialNo alone may not be
unique across vendors or even within the same vendor where different
models may reuse some serial number.
Based on your query we understand that the section is not clear enough and
will rephrase it.

Section 6.1.9
1. Where does this fit?  See comments under Section 6.1.2, above.
2. "OCRA-HOTP", etc. --- see comment under Section 6.1.2, above.
[Comment] Please see comment above for 6.1.2. The OTPAlgorithmIdentifier
in title is a typo, which will be fixed. The overall content will be
worked under the issue tracker for this.

Section 6.5
1. HOTP is quite specific, and perhaps other OTP algorithm types should
be included.
[Comment] Noted and will be added. The issue is tracked under KEYPROV
issuer track.

-----Original Message-----
From: Mingliang Pei [mailto:[email-masked]] 
Sent: 20 June 2007 15:41
To: [email-masked]
Subject: [KEYPROV] [issue22] PSKC: work on clarifications and updates for
comments received

I reviewed draft-vassilev-portable-symmetric-key-container-02.txt, which is 
essentially the same as
draft-hoyer-keyprov-portable-symmetric-key-container-
00.txt, and have the following comments:

General
generalize where possible, with provisioning of authentication tokens as a
near-

Section 1
credentials using an OTP provisioning protocol to different flavors of
embedded 

Section 4.
1. Would be good to generalize the "event counter value" and "time value"
OTP 
attributes.

Section 5.1

Section 5.1.1

Section 5.1.4

Section 5.1.5

Section 5.1.6
1. Although not necessarily applicable here, where would a PIN policy be 
defined?  In other words, if the symmetric key is loaded on an
authentication 
token, will the token be a PIN-less or PIN-full one --- and where can that
be 
set as an attribute?

Section 5.1.7

Section 5.1.9
1. Are these attributes mandatory or optional?  I would assume Optional if
the 
format is intended for broader application than authentication tokens.
2. OTP attributes are not covered in any sub-sections of 5.1.9...

Section 6.1.1
1. "Usage" implies that each secret in a "Device" could support a different 
algorithm.  Correct?
2. "userPIN" - is the intent to have a different PIN for each secret stored
in 
a Device?  If no PIN is provided, the assumption is no PIN is required?  Is 
this a correct interpretation?  Where might a PIN policy fit here (also
refer 
to comment on Section 5.1.6, above)?
3. "SecretId" - perhaps this should have a more structured type than
"string", 
esp. one that could be represented as a URI should this be a global
identifier.
4. "Issuer" - is this the same thing as "ServiceID" used in DSKPP (see
draft-
pei-keyprov-dynamic-symkey-prov-protocol-00.txt, Sec. 6.2)?

Section 6.1.2
1. UsageType->AlgorithmIdentifier should be defined by an IANA identifier or
a 

Section 6.1.3

may not be cloned).  Perhaps there are some that are specific to the
container?

Section 6.1.4
1. "Since OATH devices" is too specific...
2. "identifying criteria" should be specified consistently along with 
applicability information, e.g., by registering IANA numbers.
3. "SerialNo" -- is this what is used to comply with statement that
"criteria 
MUST identify uniquely the device"?  If so, is the SerialNo also going to
have 
global scope?  To satisfy the use cases around cross-vendor credential 
migration, it would seem this is a requirement.

Section 6.1.9

Section 6.5

----------
assignedto: mpei
messages: 37
nosy: keyprov, mpei
priority: urgent
status: in-progress