Subject: I-D ACTION:draft-raeburn-krb-rijndael-krb-03.txt

From: [email-masked]
Date: Thu, 27 Feb 2003 07:42:43 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: AES Encryption for Kerberos 5
	Author(s)	: K. Raeburn
	Filename	: draft-raeburn-krb-rijndael-krb-03.txt
	Pages		: 12
	Date		: 2003-2-26
	
Recently the US National Institute of Standards and Technology chose
a new Advanced Encryption Standard [AES], which is significantly
faster and (it is believed) more secure than the old DES algorithm.
This document is a specification for the addition of this algorithm
to the Kerberos cryptosystem suite [KCRYPTO].
Comments should be sent to the author, or to the IETF Kerberos
working group ([email-masked]).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-raeburn-krb-rijndael-krb-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-raeburn-krb-rijndael-krb-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-raeburn-krb-rijndael-krb-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Marcus Watts <[email-masked]>
Date: Fri, 28 Feb 2003 06:59:52 -0500

I just had a look at Raeburn's draft
 
> 	Filename	: draft-raeburn-krb-rijndael-krb-03.txt

So far as the CTS stuff goes.  I still think I have the more elegant
solution, but I'm clearly alone here.  I went looking for other
implementations of CTS, and found an implementation of aes-cbc-cts in
libgcrypt -- which works just as Raeburn has specified here.  I don't
think the world needs 2 ways to do CTS, so I'm willing to concede.

I dusted off my pbkdf2 code, and got it to produce the same values as
the string to key test vectors at the end.  I think, so far as the
accuracy and language in the draft goes, I'm basically happy with it
(excepting one nit -- later here.)

There was some discussion last november about RFC1964 and AES.  I don't
think that it's necessary to do anything with "qop_req".  It is certainly
possible to have different seal and sign algorithmic identifiers, like the
existing des3 stuff, although it's not actually necessary.  Raeburn
proposed in Nov having seal and sign values that say "the encryption
type of the ticket", which is fine.  I'm very interested in seeing
whatever Raeburn has for all this, since I expect to be in a position
to try AES out w/ gssapi *very* soon.

I don't remember ever seeing anything about why 96 bit confounders
(vs. why 128 bit).

I think the biggest bone I have to pick is still the iteration count.
I guess 45096 == 1 sec is fine for a workstation.  But here are
some other enviroments I see or think would be of interest:
	PDA -- I think this is probably really the interesting
		lower limit for hardware.  Mobile phones don't
		have good alphanumeric interfaces, but people
		*do* use PDA's to run s/key, web browsers, and
		ought to be able to use them with k5 too.
	umich login pool -- about 10 machines where people
		log in, check mail, and do other unixy stuff.
	busy imap server with stupid user authenticating once a second
		(grumble, politics, grumble -- but there it is... )
	cosign web server doing user authentication w/ cookies and ssl.
	"free" public access unix machine -- basically a timesharing
		system with >60 people logged in, limited hardware
		budget.
I'm concerned that people here are only thinking of dedicated workstations.
While that's a great ideal, and certainly the model of how one *ought*
to use kerberos, there are plenty of real-world applications where the
CPU is being shared with other things.  preauth is something else worth
shooting for, and there's no guarantee that won't have CPU requirements
of its own.  Also, any numbers people can pick today are bound to go
quickly obselete.  If 45096 is correct today, 7053950 is going to be
the correct number in a decade -- and people that assume 45096 gives
them security will be wrong.

I very much want some way to specify an alternate string to key function
"somehow".  I guess I can do disgusting things with the "string to key"
parameter block and etype-info-2, so maybe this won't matter to anybody else.
It would have been nice to see more attractive hooks for this though,
say, a string to key parameter framework that allowed for more
extensibility.

But perhaps there is a nit here -- probably Raeburn's draft meant to
say that the "string to key parameter block" is to be interpreted
as a 32-bit int stored in little-endian mode.  Perhaps it should say
this.  Also, it might be nice if the spec warned people that if
they put limits in code on unreasonable iteration counts (certainly
3611622603 is "unreasonable" == approximately 1 day of CPU), then this
limit should be configurable by the system administrator (and not
left as a compile-time option on source code buried somewhere inside
MicroSoft :-) )

Basically, though, it looks good, and I hope this means it's very
close to being done.

					-Marcus Watts
					UM ITCS Umich Systems Group

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 28 Feb 2003 15:49:35 +0100

> think the world needs 2 ways to do CTS, so I'm willing to concede.

Libgcrypt is based on Raeburn's draft, so it isn't a parallel
invention and thus not an argument to drop your idea.

I would prefer using an encryption mode that provides integrity and
have a security proof instead of a ad-hoc combination of a CBC derived
mode with padding hacks plus a keyed HMAC.  I.e. AES-CCM [1].  None of
the Kerberos cipher suites are proven secure, for confidentiality AND
integrity as far as I'm aware (I'd love to be corrected on this).  I'm
worried about variations of the recent TLS CBC mode attacks.  I have
been assuming it was too late for such a radical change though.

http://www.ietf.org/internet-drafts/draft-housley-ccm-mode-02.txt

> I guess 45096 == 1 sec is fine for a workstation.

Note that (1) PDAs, web servers etc can cache the key after computing
it once, and (2) you can use str2key parameters to set the iteration
count in severely limited situations.

I noticed this problem in a combined SASL and Kerberos server, that
creates Kerberos principals on the fly and authenticates using a
legacy password database, and the server computes the str2key
operation.  One solution is to use a PA-ETYPE-INFO2 to force the use
of a small iteration count parameter.  This worked for me since I can
supply a random salt every time, but using a small iteration count in
general is not a good idea.

---

From: Marcus Watts <[email-masked]>
Date: Fri, 28 Feb 2003 11:02:47 -0500

Simon Josefsson <[email-masked]> writes:
> Cc: [email-masked]
> To: Marcus Watts <[email-masked]>
> Subject: Re: I-D ACTION:draft-raeburn-krb-rijndael-krb-03.txt
> From: Simon Josefsson <[email-masked]>
> Date: Fri, 28 Feb 2003 15:49:35 +0100
> In-Reply-To: <[email-masked]> (Marcus Watts's
>  message of "Fri, 28 Feb 2003 06:59:52 -0500")
> Message-ID: <[email-masked]>
> User-Agent: Gnus/5.090016 (Oort Gnus v0.16) Emacs/21.3.50
>  (i686-pc-linux-gnu)
> 

Was it?  Eh well, I'm not sure how that helps my argument any.
At best it means I now have 2 sets of people to convince.

> http://www.ietf.org/internet-drafts/draft-housley-ccm-mode-02.txt

I noticed the ccm stuff, but haven't had a chance
to read through them yet.

cbc by itself certainly doesn't provide any sort of integrity check.
The main value it provides (with the confounder) is that it stops ecb
attacks.  The real integrity check in kerberos is the sha-1 checksum
(encrypted,truncated)  This is all pretty well known and been studied a
lot.  If you know of a weakness in it, I think there'd be general
interest.

At a *very* quick glance at ccm, it's relying on an encrypted truncated
checksum, just the same as what was proposed in the draft for k5 aes.
It's using Xor and strongly dependent on unique nonce values, much more
strongly than the random confounders used with k5 cbc.  The use of xor
means it has the same sorts of potential weakness as MicroSoft's k5 rc4
support.  The draft also claims ccm is "about as fast as cbc" in
hardware, but doesn't note if this is also true in software.  It also
appears to be very new.  The usual rule is to not rely on things until
people have had a chance to stare at them for at least a couple years
without finding big flaws.

> general is not a good idea.

Personally, I'd much rather use a small iteration count than store
long-term keys on a portable.

For the uses I envision, if you were using a PDA "occasionally", you'd
have to have the "bad" iteration count all the rest of the time.
That's one reason I don't think this is a good substitute for better
preauth.

This also doesn't answer any of my qualms regarding timesharing or
other non-dedicated sorts of systems.

				-Marcus Watts

---

From: Ken Raeburn <[email-masked]>
Date: Fri, 28 Feb 2003 18:20:43 -0500

> to try AES out w/ gssapi *very* soon.

Yep, I wrote up some notes to email to a guy at Microsoft a few days
ago, but I'm heading out of town for a couple days right now, maybe I
can get something to the list Monday.

> I don't remember ever seeing anything about why 96 bit confounders

You mean the truncated HMAC?  The HMAC spec I was looking at
recommended it, if I recall correctly.  The confounder should still be
full-size.

> say, a string to key parameter framework that allowed for more

But doesn't really allow for much negotiation in terms of what the
client supports, unless we're going to add required per-cryptosystem
preauth data to the initial AS_REQ message.

> this.

Hm, did I get that wrong?  I'll look this weekend.

> Basically, though, it looks good, and I hope this means it's very

Me too! :-)

> been assuming it was too late for such a radical change though.

Yes, I've been looking a little at CCM, and would like to investigate
further.  (I'm taking a copy of the draft when I head out.)  But it
may indeed be too late.  Still, if there's a lot of interest, I could
try to sketch something out and send it around before the meeting.

Ken