Subject: Re: [KEYPROV] Comments about dkspp-01

From: [email-masked]
Date: Fri, 22 Feb 2008 17:22:18 -0500

Pasi,
Thanks for your comments.  Please see responses below.
Andrea

________________________________

From: [email-masked] [mailto:[email-masked]]
Sent: Thu 12/13/2007 8:01 AM
To: [email-masked]
Subject: [KEYPROV] Comments about dkspp-01

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? 

adoherty>>This was fixed in the latest draft.

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.) 

adoherty>>I ping'd Magnus on this one and here was his reply:

*	
	mnystrom>>The MAC was only intended for key confirmation and fullfills this need. I
	agree however that it probably would be (would have been) better if the
	final MAC included all components sent and received by the server. This
	way one would get integrity protection of other protocol elements even
	outside of a tunnel, like in EAP-POTP. There's no MAC in the client's
	second message (in 4-pass) either but there could be altough I don't see a
	similar strong need for it.

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...) 

adoherty>>"is derived" is more correct; text was fixed in the -02 version of the draft.   Originally, the AUTHCODE generation description was an example.  We found problems with this as you did.  In the soon to be submitted -03 version, the AuthCode format has been relaxed.  The only MUST is that the Authenticaiton Code contains a client identifier and a password.  A checksum element is optional.  

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

adoherty>>This was an error in the -01 version of the draft.  Please refer to the -02 (or -03) version.

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

adoherty>>Here is our take:

FIPS180-SHA: No, it is just in an informative appendix
PKCS-1: Agree
PKCS-5: This is most likely normative even though it is only used in an
optional alternative.
RFC2104: Informative as FIPS180-SHA
RFC2119: Normative, yes.

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). 

adoherty>>Agree.  Will make the change in the -03 draft.

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

adoherty>>Right, willidentify this in the urn, e.g....#dskpp-prf-aes-128

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.) 

adoherty>>The message flows were updated to be more readable.

Best regards, 
Pasi 

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

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