Subject: pk-init alternative: how to proceed?

From: Marc Horowitz <[email-masked]>
Date: 02 Dec 1998 22:38:34 -0500

Sam Hartman and I have spent some time in the last week reviewing
pk-init, and our opinion is that it should be replaced with something
else.  We understand that such a statement is ludicrous by itself, and
so we have also spent some time developing an alternative.  Our
reasons for this are as follows:

 1) pk-init is extremely complex.  Public key is subtle, and while the
document describes what is necessary to implement it, it does not give
enough information to analyze it well.  We are not as confident as
we'd like that there are no problems.

 2) pk-init uses bits of various other specifications by value, rather
than by reference.  We believe that the document describing the use of
pk with kerberos should consume such specifications (CMS and/or PKIX)
normatively by reference.  Yes, CMS is still a little bit of a moving
target, but I think having kerberos be different from "everything
else" would be quite poor in the long run, even if the short term is a
little difficult.

 3) There are many ways that kerberos can benefit from public key
technology.  pk-init addresses only a few of them.  We believe a more
general approach (in particular, defining enctypes with public key
semantics instead of symmetric key semantics) will be simpler to
define, simpler to analyze, and more functional.

 4) pk-cross currently has some significant problems wrt contentions
issues in other documents.  We believe that our approach to pk-init
will allow pk-cross functionality to be implemented without causing
these problems.

Sam and I are working on a draft describing our proposal.  We hope to
complete it before the end of the week, and will definitely do so
before the CAT meeting.  We understand that this is late in the
process for such a massive change in direction, and apologize for
this, but we believe it is the best way to achieve a kerberos/public
key hybrid.

I will post the draft to these addresses as soon as it is available.

		Marc
==========================================================================
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: "Douglas E. Engert" <[email-masked]>
Date: Thu, 03 Dec 1998 09:16:52 -0600

Consider the use of SSL or SPKM as alternatives.

Using SSL mutual authentication and exchange of certificate chains
give you an encrypted channel to return an unecrypted TGT. 
Thus the client does not need a key. 
We have an implementation using SSLeay. The modified KDC checks
the certificate chain and database before returning the TGT. 

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444

---

From: Marc Horowitz <[email-masked]>
Date: 07 Dec 1998 09:51:42 -0500

>> I will post the draft to these addresses as soon as it is available.
 
Here is the current form of the document.  I have many more notes (if
you're in Orlando, find me, I'll show them to you), but they're not
really self-explanatory yet.  The draft is not complete (nor is it in
i-d form yet), but I'm still actively working on it.  All the concepts
are here, though.  Comments are highly appreciated.

		Marc

Kerberos has two fundamental security constructs.  The first is
EncryptedData.  When EncryptedData is used, two parties share a key.
One party encrypts and integrity protects plaintext using this key,
producing a ciphertext, and the other party decrypts and verifies this
ciphertext, producing the original plaintext.  The encryptor has high
assurance that only the other party holding the key can decrypt the
data.  The decryptor has high assurance that only the other party
holding the key could have created the ciphertext.  

The second is Checksum.  In this paragraph, we only discuss keyed and
collision-proof checksums (MACs).  Again, two parties share a key.
One party generates a Checksum over data.  The second party verifies
this Checksum.  The first party has no particular assurances.  The
second party has high assurance that the first party generated the
Checksum for the data.

All of the security in Kerberos derives from these assumptions.

In the common case, using symmetric algorithms, the key is a symmetric
key.  For EncryptedData, the encryptor encrypts the data and creates a
MAC using this key.  The decryptor decrypts the data, and verifies the
MAC, again using the same key.  For Checksum, the initiator creates a
keyed MAC of the plaintext, which is then verified by the recipient.

To use public keys with Kerberos, the simplest way is to define
transforms for which the same assumptions hold, but which use public
key cryptography, instead.  For EncryptedData, we define PK-ENCDATA.
This format takes plaintext, signs it in the public key of the
encryptor, and encrypts it in the public key(s) of the decryptor(s).
For Checksum, we define PK-CKSUM.  The data is simply signed in the
public key of the checksummer.

Keys for the PK transforms are never instantiated in the protocol.
Key data is either read from directories or local caches (for public
keys), or from the local private key store.

PK-ENCDATA and PK-CKSUM are defined in terms of commonly used PK
formats, with associated etype and cksumtype assigned numbers.  In the
IETF, there are two different standards-track public key message
formats, CMS and OpenPGP.  This document uses CMS; OpenPGP will follow
later.

The last primitive necessary is a type for carrying public keys and
their associated certificates.  PK-CERT is defined for this purpose.

Certificate data is also part of the PK-ENCDATA and PK-CKSUM types.

Given the public key versions of EncryptedData and Checksum, many of
the basic Kerberos operations can use PK cryptography.

 * The client can use public key to preauthenticate itself to the KDC.

The client creates a Checksum of the current time, using a public key
checksum type, and encodes this in padata.  The KDC verifies the
Checksum and confirms that the public key holder is authorized to get
tickets as the requested client name, then issues the encrypted
ticket.  The KDC-REP enc-part can be encrypted in the public key of
the user, or in a DH-derived key.

 * The KDC can create a Ticket signed by the KDC and encrypted in the
service public key.

The KDC uses a public key enctype, and applies the straightforward
transforms.

 * The KDC can encrypt TGS-REP's in the client public key

The client specifies a PK enctype in the TGS-REQ etype list,
optionally a PK-CERT.  The KDC encrypts the TGS-REP enc-part with this
public key.

These are just illustrative examples.  All EncryptedData and Checksum
may use public key types if appropriate.

================================================================

ASN.1 types:

PK-ENCDATA ::= SEQUENCE {
	edType		[0] INTEGER,
			-- 1 is CMS
			-- 2 is OpenPGP
			-- additional types can be registered
	edData		[1] OCTET STRING
}

For CMS, edData contains an EnvelopedData.  The encryptedContentInfo
of this EnvelopedData has contentType id-signedData, and the
recipientInfo is the decryptor.  This is usually the tgs, service, or
principal, but may be the tgs and service.  The signedData
encapContentInfo eContentType is id-data, which contains the
encoded plaintext.  The signedData signerInfo is for the encryptor.

PK-CKSUM ::= SEQUENCE {
	cksumType	[0] INTEGER,
			-- 1 is CMS
			-- 2 is OpenPGP
			-- additional types can be registered
	cksumData	[1] OCTET STRING
}

For CMS, cksumData contains a SignedData.  The signedData
encapContentInfo eContentType is id-data, the signedData
encapContentInfo eContent is omitted, and the signedData signerInfo is
for the checksummer.  The signature is computed over the implicit
plaintext data.

PK-CERT ::= SEQUENCE {
	certType	[0] INTEGER,
			-- 1 is CMS
			-- 2 is OpenPGP
			-- additional types can be registered
	certData	[1] OCTET STRING
}

================================================================

Diffie-Hellman is orthogonal to the public key encryption mechanisms
described above.  Two preauth types are defined which exchange DH key
values from which a secret is derived.

This is all orthogonal to the public key stuff.  These preauth types
can be used to set up the session key, giving PFS.  The Checksum can
be symmetric.

PA-DH-REQ ::= SEQUENCE {
	clientAuth		[0] ClientAuthenticator,
	clientAuthChecksum	[1] Checksum
				-- computed over ClientAuthenticator, 
				-- Checksum key is client key for AS-REQ,
				-- or Ticket key for TGS-REQ
				-- In the former case, the Checksum may be
				-- symmetric, with the principal's long-term
				-- secret, or a PK Checksum, signed with
				-- the principal's private key.
}

ClientAuthenticator ::= SEQUENCE {
	clientPublicValue	[0] OriginatorPublicKey,
	kdcRealm		[1] Realm,
	ctime			[2] KerberosTime,
	cusec			[3] INTEGER
}

The ClientAuthenticator has two purposes.  The first is to carry the
client's half of the DH exchange.  The second is to provide enough
information to avoid replay to another realm (kdcRealm) or later
replay (ctime, cusec) should an attacker derive the private value from
the DH public value.  The checksum prevents modification and
demonstrates the identity of the client to the KDC.

PA-DH-REP ::= SEQUENCE {
	serverAuth		[0] OriginatorPublicKey,
	serverAuthChecksum	[1] Checksum
}

The server message is just a signed DH public key.  Once the DH key
exchange is complete, the resulting secret must be converted to a
symmetric key for use by the two peers.  This is done via a simple
modification to key derivation:

      Key = DK(k-fold(DH shared secret), Well-Known Constant)