Subject: [KEYPROV] Comments on draft-ietf-keyprov-dskpp-00.txt

From: "Turner, Sean P." <[email-masked]>
Date: Mon, 27 Aug 2007 19:14:14 -0400

Here are some comments/questions on draft-ietf-keyprov-dskpp-00 (note that I
only skimmed the schema section):

* Which variant(s) is(are) the MUSTs for the client? for the server?  Does
someone claiming conformance to this document need to support 4, 2, and
1-pass or can they claim conformance for just 4, 2, or 1-pass?

* The term symmetric cryptographic module is used in many places, suggest
changing it to symmetric key cryptography module? A symmetric modules makes
it sound like both sides are the same ;)

* The concept of an issuer is first introduced in 3.3.  It should be
described in section 2. (and maybe 4.1?) 

* (sec 4.2.1) Step c indicates the CM should verify the server's certificate
before using it to encrypt R_C, add reference to [RFC3280] for step's
necessary to verify the server's certificate.

* (sec 4.2.2 and sec 4.2.3) In the 2-pass and 1-pass descriptions, they
mention that the scenarios can be used when adminstrator approval is
required.  For me that would entail a <ClientHello>, a <ServerHello> that
indicates waiting-on-approval (pending or whatever state), then either
another client generated <ClientHello> to ask about the previous
<ClientHello> or a server generated response <ServerFinished>.  Does this
match what you were thinking? If so is it worth, having a section that
describes the 'wait I'm getting approval' scenarios? 

* (sec 4.3.1) Which of the 3 client authentication mechanism is the MUST and
which are the SHOULDs for the client? for the server?

* (sec 4.4) Can we add a reference to the ASN.1 based symmetric key content
type ID?

* (sec 4.5.1) What is the MUST DSKPP-PRF for the client? for the server? The
last sentence points to Annex E for realizations of the DSKPP-PRF but it is
unclear whether the appendix is normative and which realization is required.

* (sec 4.5.2) The last sentence indicates the secret key k 'MUST be 16
octets long' shouldn't it be 'MUST be at least 16 octets long'?

* (sec 4.7) What is the MUST algorithm for encryption of the pseudorandom
Nonces sent from the client?

* (sec 4.6 and 4.7) I'm not a cryptographer but why not pick osmething more
useful than 'Encryption' and 'Key Generation' as the thing to concatenate
with - maybe Time?

* (sec 4.9.2) Should the Version be set to 1.0 like para 4.9.1.  That is,
should we add: Version MUST be set to "1.0".

* (sec 4.9.5) Is there a way to make at least of the values in StatusCode be
present - or is this taken care of in the use="required" in
AbstractResponseType?

* (sec 4.9.10, 4.9.11, 4.9.12, and 4.10.2) OPTIONALLY is not a key word.
Suggest something along the lines of "The ProtocolVariantsType type is
OPTIONAL for clients. It is used by DSKPP clients to indicate the number of
passes of the DSKPP protocol that is supports (see Section 4.2)."

* (sec 4.9.11) Add space between two types in title. Add ")" to end of
paragraph.

* (sec 4.10.2) Delete "optional" from title and add "This section is
optional for both clients and servers." Assuming it's true.

* (sec 7) Should considerations be added for when the issuer acts a proxy
between the provisioning server?

* Are Annexes A-E information or normative?  Please indicate as much.

* With the definition of the authenticated-encrypted algorithms is there any
thought to using these algorithms here?

* Do we need to support internationalization of the string concatenated in
the DSKPP-PRF, K_Token, and MACs ;)

spt

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