Subject: Re: PKINIT "Design Team" update...

From: Ken Raeburn <[email-masked]>
Date: Fri, 05 Sep 2003 17:29:08 -0400

"Eric Rosenfeld" <[email-masked]> writes:
> - Open issues:
> 	- Confirm alignment with K Crypto, CMS, and Clarifications

Alignment with the crypto framework will probably take some effort.
It doesn't allow for a cryptosystem used only for encrypting and
decrypting, with a key supplied from elsewhere; it wants full support,
including generation of keys from pass phrases and salt strings, key
usage values influencing encryption, etc.  Maybe the encryption
systems do have all that, but they need to be rolled up into a
description that makes it clear that it conforms to the framework.

Maybe this is a drawback in kcrypto.  Maybe we should have allowed for
a class of cryptosystems useable only for some sort of transient
one-session or one-message keys, without some of the stuff associated
with long-term Kerberos keys.  But figuring out where to draw the
lines for that (for general use -- not just "what PKINIT does") would
take some work, and it's kind of late for that now.  And I'm not
convinced that throwing together a string-to-key function or whatever
and letting the key be used long-term is likely to be that onerous a
task.

> 	- Internationalization

Heh.  If you actually get there, you'll be ahead of Kerberos.  Making
it compatible with both Clarifications and Extensions could be tricky.
I suppose you could cheat and say, here's how you get the UTF-8
string, and if you use non-ASCII data with Clarifications and hurt
yourself, we'll all feel sorry for you for about three seconds.

> Brian Tung, the principal editor, is working on an updated draft and
> should have it ready by Sept 8, one week before the Interim meeting.

I'm looking forward to reading it.

Ken

---

From: "Joel N. Weber II" <[email-masked]>
Date: Sun, 07 Sep 2003 01:13:56 -0400

Ignoring for a minute that I'm not terribly convinced that a
passphrase really has enough entropy for a general-purpose symetric
encryption key, the situation is going to be even worse for a public
key cryptosystem, since modern systems typically use 128-256 bits for
symetric encryption keys, and 1024-4096 bits for public keys.

My opinion is that there are basically three classes of things we care
about:

1) Traditional cryptosystems that support the full kcrypto stuff,
doing symetric cryptography; basically, the functionality that we
currently have with AES.

2) Public key algorithms.  You generally don't want to pass large
amounts of data through public key algorithms for performance reasons,
among other things.  You generally only use public keys to sign hashes
of messages, and to encrypt session keys.

sshv2 uses signing in public key authentication, and in theory someday
it might also support encryption, but as far as I know, no current
implementation of sshv2 does public key encryption.

I don't quite have a clear understanding of whether we care about
supporting RSA encryption at all in Kerberos.  It may be that we need
it for PKCROSS.  It may also be that there's a deployed base of users
who already have encryption keys that they want to use for
PKINIT.

3) Diffie-hellman, where I think it's fairly clear that you want to do
a diffie-hellman exchange and then feed the resulting key to a
traditional kcrypto system, and use the traditional kcrypto system for
all subsequent operations.

Diffie-Hellman could probably be implemented as a preauthentication
handshake (and maybe someday an AP-REQ handshake), and not assigned
any enctype value.

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 7 Sep 2003 00:01:19 -0700

> yourself, we'll all feel sorry for you for about three seconds.

The question is how to word it so we don't have to revise the spec later
when extensions happens.  This also applies to the change/set passwd
draft - so far I've weaseled:

"
...
   Kerberos principal and realm names used in this protocol MUST be
   constrained as per the specification of the version of Kerberos V
   used by the client.
...
   No normalization form is required for string types other than
   for PrincipalName and Realm, which two types are constrained by the
   specification of the version of Kerberos V used by the client, and
   the password fields in the change password operation, which MUST be
   normalized according to [k5stringprep].
...
"

IIRC Sam expressed some concern that such language won't cut it.

Comments?

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Sun, 07 Sep 2003 08:19:36 -0400

> IIRC Sam expressed some concern that such language won't cut it.

Let's get extensions _done_ so this doesn't become an issue. :-)