Subject: RE: draft-ietf-cat-kerberos-pk-init-09.txt

From: "Linn, John" <[email-masked]>
Date: Wed, 7 Jul 1999 11:39:29 -0400

I'd like to get some further clarification about the intended Diffie-Hellman
usage mode(s) in pk-init.  As an independent reader, I'm still perceiving
some inconsistency, and am uncertain as to whether it's at the terminology
level or more fundamental. I'd appreciate any commentary, whether from the
document editors and/or from others who've been reviewing recent pk-init
drafts.

Here's the situation as I see it:

(1) pk-init-09 states that the mandatory D-H operating mode is
ephemeral-ephemeral.  It also refers to the possibility of client-side and
KDC-side D-H certificates. 

(2) While it's possible in principle for ephemeral keys to be certified,
this isn't the common practice (it would, e.g., imply an interaction with a
CA whenever a new ephemeral key is generated). 

(3) The discussion of KDC validation suggests that a valid client request
needs (except possibly for the special case of an anonymous ticket request)
to be accompanied by an appropriate chain of certificates representing the
client.  Such certificates would provide a (valuable) means for the KDC to
authenticate the client, but (per (1) and (2) above) might not necessarily
exist within the mandatory-to-implement operating mode.  

Is the client's ephemerally-generated key required to be CA-certified in
order for the KDC to be able to authenticate the client, or is at least the
client's signature key actually static?

--jl

==========================================================================
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 08 Jul 1999 17:46:48 +0200

> document editors and/or from others who've been reviewing recent pk-init

Well, I am sharing some of the concerns raised by John about clarifications in
the document, but generally speaking I like it. We will certainly need one more
round for a few clarifications ... and we will need to discuss a concern not
yetl raised on the mailing list (the last one from my list).

I have read the version 09 and here are my comments. These comments are in
sequence along the text and not by order of importance.

1. In the introduction we should say that ephemeral-ephemeral Diffie-Hellman key
exchange is being used as the mandatory mechanism.

2. In section 3.1.1. "The fact that these are logically distinct does nor
preclude the assignment of bitwise identical keys" only applies to RSA keys are
this should be said.

3. In 3.2. trustedCertifiers, kdcCert and encrytionCert are not part of the
AuthPack. Why ? It would be beneficial to include them in the AuthPack to limit
the *undetectable* denial of service attacks.

4. In section 3.2. the use of static Diffie Hellman certificates is mentioned
but not advertised in the introduction. Since this is immediately followed in
the ASN1 by a clientPublicKey value used for an ephemeral Diffie Hellman key
exchange this is confusing.

5. In section 3.2.2. about the required algorithms 3-key triple DES is required.
For sure 3-key triple DES is better than DES and only a little better that 2-Key
triple DES. For some reasons - which are not technical - some countries limit
free use of key sizes under 128 bits. So it would be more appropriate to only
mandate 2-key triple DES for conforming implementations which is already "good
enough" in many applications.

Denis