Subject: RE: [KEYPROV] Some comments on Section 1 of DSKPP draft

From: "Doherty, Andrea" <[email-masked]>
Date: Tue, 3 Jul 2007 14:08:30 -0400

Uli,
Thank you for your comments.  Please see my responses below.
Andrea 

-----Original Message-----
From: Meyer, Ulrike [mailto:[email-masked]] 
Sent: Monday, June 18, 2007 3:37 AM
To: [email-masked]
Subject: [KEYPROV] Some comments on Section 1 of DSKPP draft

Hi Andrea, Pei, all,

here are some review comments on Section 1 of the DSKPP draft. Please excuse, if I bring up anything that has already
been discussed on the list before.

* Page 5 (Scope): what is meant by "without exposing generated, secret
material to any other entities than the server and the cryptographic
token itself" mean? In particular: doesn't the user at least in some
application scenarios have access to the content of the token? And doesn't in use case 1.3.4 the issuer get
hold of the provisioned key as well?

What is meant is that the secret material is protected during provisioning, i.e.,
A. 4-pass: The secret is not transferred between the server and the token; rather, it is generated on each side via key agreement.
B. 2-pass, 1-pass: The secret is transferred between the server and the token; however, it is encrypted and therefore not "exposed" to the server or token.  

The quote that you referred to does apply more to 4-pass in that with 4-pass one can definitely state the secret is not (and cannot be) exposed since it is not transferred.

With respect to application scenarios that have access to the content of the token, these are out-of-scope for the protocol, which is specific to provisioning.

With respect to use case 1.3.4, it is the third party provisioning service that generates and provisions the key using the protocol.  If the issuer acquires symmetric keys on behalf of its users, then it is acting as a client of the protocol.  To then push the key to the token would mean that the issuer is the manufacturer of the token, or would become the server in the keyprov protocol (1- or 2-pass).  Perhaps Ming would have more to say on this scenario?

* Page 5 (Scope): The term "connected cryptographic tokens" should be
explained already here, e.g. by "remotely accessible". "Connected
could be misinterpreted as interconnected tokens

Good point.

* Page 6 (Background, second paragraph, last sentence): "This is the strongest approach
to symmetric key provisioning, as the key  is not transported between systems, and is
therefore not vulnerable to man-in-the-middle attacks". Could be missunderstood, as man-in-the-middle attacks
can not only possible if a key itself is transported between systems, but also is any input (such as nonces, DH-parameters etc.) to a key derivation function are transported between systems.

You are correct.  It is a stretch to imply the protocol is not vulnerable to MITM attacks.

* Page 6 (Background): "Direct" communication should be explained more
precisely. In addition, it is a little unclear from the text which scenarios (both, the
direct and the indirect one or only one of them??) are addressed by
DSKPP

Yes, this should be cleaned up.

* Page 6 (Use case): An example for why a client would want to be
provisioned a symmetric key would be nice

Agree; will add.

* Page 6 (Use cases 1.3.2 and 1.3.3) these use cases sound more like
requirements then like use cases.

Yes, esp. with the use of the RFC2119 terminology ("MAY", "MAY NOT", etc).  Hannes pointed out that this language does not belong until Section 3 and beyond.  This will be fixed for the -01 submission.

* Page 7 (Use case 1.3.4) In this use case: which entities are to end
up with the newly generated symmetric key? The user (in form of the
token) and the issuer? If yes, how does the issuer obtain the key from
the provisioning server? Is this covered by the protocol or not?

More clarification is needed in this section.  For answers to specific questions, see response to first comment above.

* Page 8 (2nd last paragraph before 1.3.8): Sentence incomplete

Ok, will fix.

* Page 8 (Section 1.3.8) Last sentence does not make sense

Agree; will clean up.

* Page 8 (Section 1.4.8): It highly depends on the application if SMS
can provide an exceptable level of protection for the transport of
secret keys.

Good point that will be added to the section.

* Page 9 (R1): What is meant by different key types? Differnt lengths?

Key types here refer to different types of shared secrets (e.g., one that supports signatures, one that supports encryption, one that support OTP generation/verification).  A different length could be associated with each key type but that is not what is being referred to in this section.

* Page 9 (R2 and R3): what is the difference between re-generated and
mutually generated keys??

R2 is derived from use case 1.3.1; "re-generated" is a typo that should read "pre-generated".  "mutually generated keys" refers to key generation using the four-pass protocol, wherein the keys are generated on the client and server, but not transmitted in between.  "pre-generated" keys correspond with 1-pass or 2-pass protocol variants since these are capable of handling transport of pre-existing (or legacy) keys).

* Page 9 (R6) What is the difference between cryptographic and
security capabilities?

This section needs cleanup.  The use of "security capabilities" does not make sense here.

* Page 9 (R7) why is this requirement not a MUST

It should be; actually all of the "Mandatory Requirements" in this section are MUST's.

* Page 11: The document structure section seems a little superflouse as the same information can be gathered
from the table of content

Agree; will remove.

Best regards,
Uli

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

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