[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [KEYPROV] Comments on PSKC I-D
Andrea,
I will look at your comments and respond to them individually this coming
week. Thanks for your thorough review,
Philip
-----Original Message-----
From: Doherty, Andrea [mailto:adoherty at rsasecurity.com]
Sent: 07 May 2007 21:54
To: keyprov at ietf.org
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?
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
KEYPROV at ietf.org
https://www1.ietf.org/mailman/listinfo/keyprov
_______________________________________________
KEYPROV mailing list
KEYPROV at ietf.org
https://www1.ietf.org/mailman/listinfo/keyprov