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

From: "Meyer, Ulrike" <[email-masked]>
Date: Tue, 19 Jun 2007 14:16:42 +0200

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. 
* The relation between the different protocol variants and the use cases / purposes for which they are designed is not clear
 
Section2:
-------------
* Page 13: Definition of R_C and R_S could be completed with "and used as input to the generation of K_TOKEN"
* Page 13: Definition of R could mention "mandatory for 2-pass, optional for 4-pass"
* The notation K_MAC' is used in Sections 3.9.3.1 and 3.9.3.2 but not defined here 
 
Section 3.3.1 in general:
-----------------------------------
* What is meant by "provisioning of legacy 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"
* 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
* the optional client nonce R seems to be missing in the description of ClientHello
* the supported variants of DSKPP (4-pass, 2-pass) is missing in the description of ClientHello (mentioned in 3.11.3)
* in c. the verification of the server certificate (if K_SERVER is used) could be mentioned
* 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
* 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
 
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 
* It could be mentioned for which use case teh 2-pass variant is suiteable
 
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
 
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?
* 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? 
 
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? 
* What is the relation between K_SHARED and K_AUTH? Shouldn't they be mandated to be different? 
* In case K_AUTH and K_TOKEN are equal, K_AUTH is updated with the new K_TOKEN at the end of DSKPP?
* 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
 
Section 3.9.1.2:
-----------------------
* How is K_MAC provided to the token "together with K_TOKEN"? Does this mean that both are sent in the ServerFinished message?
 
Section 3.11.3:
----------------------
* Does the server check the KeyID provided by the client in the ClientHello?
 
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?

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