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

From: [email-masked]
Date: Wed, 07 Jul 1999 10:09:52 -0700

John,

We defined two different D-H modes: Ephermal-Ephermal and Static-Ephermal,
where the client side is static and requires a DH certificate (chain).

The mandatory Ephermal-Ephermal D-H mode does not utilize DH certificates.
In that case, the client's certificate chain is for its signature
verification key, not the D-H key.  Instead, the client public D-H value is
included in the data that is signed by the client.

The optional Static-Ephermal D-H mode was added in the last revision, based
on comments that we received.  In this case, the client will send two
certificate chains: one for the DH key and one for its RSA signature
verification key.  This is where we refer to the client's D-H certificate.
This D-H certificate replaces the D-H public value inside the AuthPack data
structure. 

We did not refer to KDC's D-H certificates, as far as I know.  In the D-H
modes, KDC always generates an ephermal D-H public value and returns it
inside SignedData.

Regards,

Sasha.

	-----Original Message-----
	From:	Linn, John [SMTP:[email-masked]]
	Sent:	Wednesday, July 07, 1999 8:39 AM
	To:	'Matt Hur'; Linn, John; 'CAT-WG List'
	Cc:	Cliff Neuman; 'Brian Tung'; 'Sasha Medvinsky'
	Subject:	RE: draft-ietf-cat-kerberos-pk-init-09.txt

	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]
==========================================================================
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]