Subject: FW: [KEYPROV] DSKPP

From: "Doherty, Andrea" <[email-masked]>
Date: Wed, 17 Oct 2007 21:23:19 -0400

Here are some off-mailing list comments that I received on the current
version of the DSKPP I-D:
========================================================================
========================

TECHNICAL COMMENTS

In 4.6 and subsequent cases (e.g., 4.8.1.1, 4.8.1.2), I think a little
more specification is needed for interoperability.  At 4.6, when
constructing the s input to DSKPP-PRF, just how are k and R_S converted
to strings?  What radix, and are there spaces or other delimiters
between them?  An example and a few more rules would be helpful at this
point. 

Per 7.2.4, would a means in the 4-pass protocol for the server to
perform key confirmation of the client be feasible or useful?  Could,
e.g., <ClientNonce> carry a MAC? 

At A.4, is it feasible and acceptable for the server to retain the
K_DERIVED form rather than the input passphrase?  If so, suggest
restating the first paragraph to correspond. 

SPECIFIC POINTS

Sec. 1.2, 1st para: the examples in the first sentence should be clearly
stated as examples.  As written, the list could be misconstrued as
prescriptive.

Sec. 3.3: Suggest emphasizing that the validity period construct is
something within an endpoint, NOT an aspect of the protocol per se. 

Sec. 3.6, 1st para: don't think that we should be presuming to state
requirements for classified government modules; suggest dropping that
reference. 

Sec. 3.8: How can the cryptographic module provide assurance for SMS?
Isn't this really a judgment to be made by deployers? 

Sec. 4.1, figure legend: Do devices necessarily need to be
hardware-based?  Can't modules be hosted within a software framework?

Sec. 4.1, figure legend: Can a cryptographic module also reside outside
the application, somewhere else within its processing environment? 

Sec. 4.3.1.3, shortly after Fig. 7, under the heading
"AuthenticationData = Hash (AC)", the text describes a case where the
authentication data may be plaintext.  Given the heading, this structure
is confusing. 

At 4.8.1.1 (and similarly in 4.8.1.2), is the choice of alternatives
necessary?  If so, should the choice of key be tagged somehow so that
the recipient doesn't need to guess? 

At 4.9.8, is the intent to constrain a nonce to at least 16 octets of
base64 representation (which I think this does), or to 16 octets of
underlying binary value before base64 encoding? 

4.10.3, <DeviceIdentifierData>: "... identifier MUST only be present if
such shared secrets exist..."  Which shared secrets? 

7.2.2, 3rd para: "Clients will protect" -> "Clients MAY protect"? 

7.6.4, "When an Authentication Code..." bullet reads oddly, seeming to
suggest that use of SSL or TLS adds the ability to perform a guessing
attack that would be infeasible if SSL/TLS weren't present. 

App C, Req-8, requirement seems vague.  Is the intent for the 2nd
sentence to require symmetric method support or, as it reads, just
anything that's not PKI?

App C, Req-9, "SHOULD NOT only rely on" -> "SHOULD NOT require".

App C, Req-10, citation to Global Platform (who?) seems out of place
without a reference.  If this is really an i.e. (therefore defining, not
an example), it shouldn't be a SHOULD without a specification or more
detail. (And, if it's going to be, there's room for IETF argument as to
why...) 

App C, Req-16: Isn't this an implementation limit, not something within
the protocol? 

EDITORIAL

Sec. 1.2, 2nd paragraph, 1st sentence: seems strange to describe a
server as a "mechanism".  "... makes use of a symmetric key provisioning
server", maybe? 

Sec. 3.2, text: A trademark reference may be needed to accompany "RSA
SecurID", but that's a question for Legal. 

p. 17, last 2 paragraphs: believe that these upper case MAYs should be
down-cased, as they don't (per RFC-2119)  refer to implementation
requirements. 

Sec. 4.3.1.2, 1st sentence, suggest added clause at end: "corresponding
to a particular cryptographic module".  

4.3.1.3, there's an apparently garbled phrase "K_AUTH MAY be derived AES
key from..."

4.9.5, 1st full para, last line, "MUST not" -> "MUST NOT". 

4.9.5, error descriptions: in NoSupportedEncryptionAlgorithms through
NoSupportedKeyContainer descriptions, the last sentences seem redundant.
If they're not actually adding value relative to their preceding texts,
suggest deleting them. 

4.10.3, <KeyID>, 2nd sentence: suggest "exists or was" -> "exists or if
the identifier was" 

7.2.2, 1st sentence, suggest "or the DSKPP client" -> "or will cause the
DSKPP client". 

7.6.4, 3rd bullet, "length the of" -> "length of the". 

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