Subject: [KEYPROV] DSKPP - Some more comments of last draft

From: "Salah Machani" <[email-masked]>
Date: Mon, 24 Sep 2007 07:49:24 -0400

All - 

Here are some additional comments on the DSKPP draft.   Let me know if I
should post this to the KEYPROV mailing list.

Section 2: Defines K_AUTH as the secret key used for server
authentication purposes in 4-pass DSKPP 

Are going to use K_MAC for server auth in 4-pass the same way it is done
in 1-pass and 2-pass?

Section 4.2.2 - Passphrase-based Key Wrap, statement "... which is known
in advance by both the cryptographic module and

                               DSKPP server", rephrase to state that the
passphrase "the passphrase is known by the 2 parties"

Item b. statement: "The DSKPP server generates a key K from which two
keys, K_TOKEN" - note that the key may be pre-generated as indicated in
use case 3.1

Item c. statement: "..two MACs whose values are calculated with
contribution from the client nonce, R_C, ..." to be more precise and
consistent with the description, R_C should be changed to R.  R_C which
is only used is 4-pass DSKPP is different from R.

Item d. statement: "uses the two MAC values to perform key confirmation
and server authentication and stores the key".  Note the second MAC may
only be present when replacing an existing key. 

Section 4.3.1.2 - last sentence: "a unique key for the identified device
and that key will be used in the

   Protocol"  should this be unique ID of the device?.

Section 4.3.1.3 - Diagram - provisioning client and provisioning server
- change to DSKPP client and DSKPP server

Section 4.3.1.3 List of possible authentication forms

- 1st bullet - "....If the underlying transport channel is secure, the
authentication data MAY contain the plaintext format or the hashed
format.." why do we need the plaintext format here? Is this to support
the case the Auth_code is sent in the Trigger message as a TriggerNonce
(see first paragraph of 4.3.1.3)? 

- 2nd bullet -  K_AUTH in the calculation of AuthData is derived from
Auth_Code and is different from the K_AUTH that is defined in section 2
and which used in 4-pass dskpp for server authentication. So that there
is no confusion, can we rename it to some thing else e.g KAcode.

        This subsection (AuthenticationData=HMAC(authenticationCode,
K_Auth) needs to be reworked a bit to use the same abbreviations as in
the rest of the document.

- 3rd bullet - states "..Authentication data MAY be omitted if client
certificate authentication has been provided by the

      transport channel such as TLS"  Should this be another case and
moved to a separate paragraph?.

4.8.1.1:- server authentication - refers to the use of K_AUTH for server
authentication - suggest to use K_MAC for server authentication as in
2-pass and 1-pass

Section 4.9.12 - Last bullet <AuthenticationCertificate>: A device
certificate sent to the

      DSKPP server. -  section 4.3.1.3 indicates to send a signature -
can we clarify throughout the document what exactly should the client
send to the server, the certificate only or signed data? And which data
should be signed if signed data is sent?

Thanks,

Salah Machani

Diversinet Corp., 

[O] +1 (416) 756 2324 x321| [M] +1 (647) 284 7816
|http://www.diversinet.com <http://www.diversinet.com> 

Notice to Recipient:  The information in this message is meant only for the intended recipient of the transmission and may contain confidential or privileged information. 
Any copying, retransmittal, taking of action in reliance on, or other use of the information in this communication by persons other than the addressees is prohibited.  
If you received this email in error, please immediately notify us and please delete or destroy all copies of this message.
This message may have been altered without your or our knowledge and the sender does not accept any liability for any errors.  Thank you.

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