Subject: [KEYPROV] Comments on PSKC I-D

From: "Doherty, Andrea" <[email-masked]>
Date: Mon, 7 May 2007 16:53:42 -0400

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.

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

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 7 May 2007 14:11:27 -0700

<hatoff>
Best avoid mention of any vendor product. Symmetric keyed authentication token.

</hatoff> 

> -----Original Message-----
> From: Doherty, Andrea [mailto:[email-masked]] 
> Sent: Monday, May 07, 2007 4:54 PM
> To: [email-masked]
> Subject: [KEYPROV] Comments on PSKC I-D
> 
> I reviewed 
> draft-vassilev-portable-symmetric-key-container-02.txt, which 
> 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 
> 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."  
> 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. "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. 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. Are these attributes mandatory or optional?  I would 
> assume Optional if the format is intended for broader 
> application than authentication tokens.
> 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.
> 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
> 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
> 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. HOTP is quite specific, and perhaps other OTP algorithm 
> types should be included.
> 
>