Subject: [KEYPROV] Comments about dkspp-01

From: <[email-masked]>
Date: Thu, 13 Dec 2007 15:01:14 +0200

Some random comments about the dskpp-01 draft (not a review in 
any sense):

1) Is there a difference between URL_S and ID_S? And between
ID_C (mentioned only once in whole document) and ClientID? 

2) There doesn't seem to be MACs covering all messages/payloads?
Although the most critical elements seem to be included in some MACs,
this certainly limits the future extensibility quite a bit.
(Typically, in key exchange protocols the first messages don't have
MACs, but once a key has been agreed on, it's used to MAC all the
preceeding messages -- e.g. Finished messages in TLS and AUTH 
payloads in IKEv2.)

3) Section 5.3.3: "The Authentication Data, AUTHDATA, may be derived
from the AUTHCODE..." Is the intent to say "is derived", or are other
ways of deriving AUTHDATA from AUTHCODE allowed?  Similarly, earlier 
in same section, is "The Issuer may generate the Authentication Code 
as follows"; does this mean "is generated", or are other formats
of authentication code allowed?

(If these are example, it's hard to see how interoperability is
achieved. If these are not examples, I have some more comments...)

4) Section 4.4, in KeyProvClientHello, is R_S optional? (If not,
how it is known when Trigger is not used?)

5) At least the following references look normative to me: FIPS180-SHA,
PKCS-1, PKCS-5, RFC2104, RFC2119.

6) Reference FSE2003 should probably be replaced by NIST SP 800-38B
(although FSE2003 OMAC1 is "equivalent" to 800-38B CMAC from
cryptography point-of-view, it looks like FSE2003 actually doesn't
specify all the constants required to get interoperable
implementations).

7) Appendix B.2, is this AES with 128-bit keys, or is the key length
determined somehow from other context?

8) The message flows in Section 4 would be more readable if it was
explicitly stated what information/state the parties are expected
to have before the first message is sent. (This might include
stuff needed by TLS as well.)

Best regards,
Pasi

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