[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [KEYPROV] Comments on PSKC I-D
<hatoff>
Best avoid mention of any vendor product. Symmetric keyed authentication token.
</hatoff>
> -----Original Message-----
> From: Doherty, Andrea [mailto:adoherty at rsasecurity.com]
> Sent: Monday, May 07, 2007 4:54 PM
> 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