Subject: RE: [KEYPROV] Comments on Section 2 and 3 of DSKPP draft

From: "Doherty, Andrea" <[email-masked]>
Date: Wed, 4 Jul 2007 14:57:53 -0400

Uli,
Thanks for your excellent comments.  Please see responses below.
Andrea

________________________________

From: Meyer, Ulrike [mailto:[email-masked]] 
Sent: Tuesday, June 19, 2007 8:17 AM
To: [email-masked]
Subject: [KEYPROV] Comments on Section 2 and 3 of DSKPP draft

Hi Andrea, Pei, all,
 
here are some review comments on Section 3 of the DSKPP draft
 
Best regards,
Uli
 
General:
------------
* The relation between the different types of client authentication, server authentication and protocol variants is not very clear to me. In particular it is unclear what is mandatory and what optional, when the "secure channel" assumption is made and when not, and when the security of the protocol relies on the security properties of the underlying transport protocol. 
[Doherty, Andrea] Ok...I'll try to clarify this in the next draft. 
* The relation between the different protocol variants and the use cases / purposes for which they are designed is not clear
[Doherty, Andrea] Plan to add a section and/or table to indicate when to apply which protocol variant to which use case. 
 
Section2:
-------------
* Page 13: Definition of R_C and R_S could be completed with "and used as input to the generation of K_TOKEN"
[Doherty, Andrea] Agree, and will add. 
* Page 13: Definition of R could mention "mandatory for 2-pass, optional for 4-pass"
[Doherty, Andrea] Agree, and will add. 
* The notation K_MAC' is used in Sections 3.9.3.1 and 3.9.3.2 but not defined here 
[Doherty, Andrea]  Good catch; will add.
 
Section 3.3.1 in general:
-----------------------------------
* What is meant by "provisioning of legacy keys"?
[Doherty, Andrea] "Legacy keys" are the same thing as pre-generated keys except that "legacy" implies a situation wherein the keys were generated and available for issuance before the protocol was ever implemented.  I'll either add these words, or simply state "provisioning pre-generated keys". 
* Paragraph a.: there seems to be a repetition: "cryptographic algorithms supported by the token" and "encryption and MAC algorithms supported by the cryptographic token"
[Doherty, Andrea]Good catch - this is a typo that made it all the way through to RFC in the original CT-KIP spec! 
* it is described that the ClientHello includes the MAC algorithms supported by the token, but ServerHello and ServerFinished do not mention MAC1 and MAC2. This makes it difficult to understand immediately how the 4-pass-protocol is protected against Server impersonation
[Doherty, Andrea] Good point - will add. 
* the optional client nonce R seems to be missing in the description of ClientHello
[Doherty, Andrea] Yes, you're right.  This will be added (if even to point out that it is not required for 4-pass, although required for 2-pass). 
* the supported variants of DSKPP (4-pass, 2-pass) is missing in the description of ClientHello (mentioned in 3.11.3)
[Doherty, Andrea] Will add. 
* in c. the verification of the server certificate (if K_SERVER is used) could be mentioned
[Doherty, Andrea] Ok. 
* Client authentication should somehow be mentioned in this general description of the 4-pass protocol, as otherwise it is unclear how the protocol protects against client impersonation
[Doherty, Andrea] Ok. 
* Splitting R_C in the two components R_C1 and R_C2 protects against token impersonation in the case K_SERVER is used. If this split is not used, and there is no authenticated channel between client and server, and K_SERVER is used, then the protocol is vulnerable against token impersonation as in this case anyone (not only the token as in the case of K_SHARED) can compute R_C and therefore anyone would be able to request a new K_TOKEN from the server on behalf of the token and compute the token. In particular the sentence "The inclusion of the encryption key K ensures that no man-in-the-middle MAY be present, or else the cryptographic token will end up with a key different from the one stored by the legitimate DSKPP server" does therefore not seem to hold
[Doherty, Andrea] In the scenario you describe you are correct, i.e., one where there was not an authenticated channel.  Even if this could not/did not exist, user pre-authentication should help to ensure that K_TOKEN is not delivered to a MITM. 
 
Section 3.3.2 in general:
-----------------------------------
* The message content of ClientHello and ServerFinished should be described here again, as it differs greately from the messages in Section 3.3.1 
[Doherty, Andrea] I think this is a great idea, and will incorporate. 
* It could be mentioned for which use case teh 2-pass variant is suiteable
[Doherty, Andrea] Agree. 
 
Section 3.3.3. in general:
------------------------------------
* The content of the ServerFinished message should be described here again, as it differs greately form the messages in Section 3.3.1 and it relation to the ServerFinished message in Secion 3.3.2 is unclear
[Doherty, Andrea] Agree. 
 
Section 3.4.1.3:
-----------------------
* by "The DSKPP client includes the authentication data in its request message..." do you mean the ClientHello message? This means that this meachnism is not usable in connection with 1-pass DSKPP, right?
[Doherty, Andrea] Yes, that is correct.  I will make this more evident to avoid confusion. 
* does "...the client MUST use both the server nonce R_S and the Authentication Code to derive authentication data" mean, that if the underlying transport channel is insecure, then only 4-pass DSKPP can be used, as only then there is an R_S? 
[Doherty, Andrea]Yes, this is true.
This calculation for AuthenticationData should be changed in accordance with the attached from Salah.
 
Section 3.9.1.1:
-----------------------
* Does this mean that K_AUTH is a secret key shared between the token and the server and that it may be the old K_TOKEN or a seperate key? I.e. for the 4-pass case, server and token are required to share at least one secret key namely K_AUTH even if the server's publiv key is used to encrypt R_C?
[Doherty, Andrea] Please refer to Section 3.11.4 for a description of the <Mac> element.  The primary use of the MAC is for when the protocol run results in key renewal, and therefore K_TOKEN would be available.  However, if this a MAC is desired and there is not a pre-existing K_TOKEN, then the Trigger message (i.e., "DSKPP Initialization", sec. 3.11.2) could be used to provide K_AUTH in the form of a trigger nonce.  The value of this would depend, however, on whether the channel is secure.
* What is the relation between K_SHARED and K_AUTH? Shouldn't they be mandated to be different? 
[Doherty, Andrea]Yes, I agree that they should.  This note provides some rationale for this (taken from last paragraph of Section 3.8).
* In case K_AUTH and K_TOKEN are equal, K_AUTH is updated with the new K_TOKEN at the end of DSKPP?
[Doherty, Andrea] In this case, K_AUTH is no longer needed at the end of the protocol run. A new K_AUTH should be used for the next protocol run if K_TOKEN is used as in the key renewal scenario.
* What happens if there is no K_AUTH (in Section 3.9.1.2 this case is treated, but in this section it is not covered)? The new K_TOKEN cannot be used to protect the ServerHello message as the server cannot generate it before receiving the ClientNonce
[Doherty, Andrea] This case should be addressed in this section.  If there is no K_AUTH and no K_TOKEN (as would be the case if the old K_TOKEN is not available; we cannot rely on the new K_TOKEN as you mention), then there can be no MAC.
 
Section 3.9.1.2:
[Doherty, Andrea] I think you meant Section 3.9.2.1. 
-----------------------
* How is K_MAC provided to the token "together with K_TOKEN"? Does this mean that both are sent in the ServerFinished message?
[Doherty, Andrea] Yes, as this is the two-pass case, wherein K_TOKEN is transported to the client.
 
Section 3.11.3:
----------------------
* Does the server check the KeyID provided by the client in the ClientHello?
[Doherty, Andrea]Yes, it should...I'll make mention of this. 
 
3.11.4:
----------
* <Mac>: Does the client check whether an old K_TOKEN exisits and if it does, reject ServerHello messages that do not have a MAC?
[Doherty, Andrea] Good point; I'll add this as a "SHOULD". 

Dr. Ulrike Meyer

Nokia Siemens Networks GmbH & Co. KG

RTP NT NAS

Otto-Hahn-Ring 6

D-81730 Muenchen 

Phone: +49 89 636 41496

Fax: +49 89 636 48000

[email-masked]

Nokia Siemens Networks GmbH & Co. KG - Sitz der Gesellschaft/ Registered office: München (Munich) - Registergericht /Commercial register: München (Munich), HRA 88537 - WEEE-Reg.-No. DE 52984304. Persönlich haftende Gesellschafterin /General Partner: Nokia Siemens Networks Management GmbH - Geschäftsführer /Board of Directors: Christian Unterberger, Joachim Malterer, Roland Meinzer - Sitz der Gesellschaft / Registered office: München (Munich) - Registergericht /Commercial register: München (Munich), HRB 163416 ------ 

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