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

From: Marcus Watts <[email-masked]>
Date: Sat, 01 Mar 2003 02:59:29 -0500

Ken Raeburn <[email-masked]> writes:
> Marcus Watts <[email-masked]> writes:
> > 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.
> 
> 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 very much look forward to seeing what you have.

> 
> > I don't remember ever seeing anything about why 96 bit confounders
> > (vs. why 128 bit).
> 
> 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.

Sorry, yes, HMAC.  I guess I'm wondering what the are implications are
for having a truncated checksum that's < than the keysize & blocksize,
because it seems like that's been bad in the past.  Perhaps the confounder
makes up for that and the known plaintext bit that's going to pad out
the HMAC isn't an issue.  I think, though, I'd actually feel better
with the 96 bit HMAC if it were stored *first*, so that the random
confounder followed it and the ciphertext block the HMAC was in was
completely non-predictable.

> 
> > 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 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.

I don't think there's much room for negotiation anyways with string to
key parameters.  Either the client understands and accepts them, or it
doesn't.  It could easily be argued that the whole preauth/salt/enctype
things ought to be re-thought out (for instance, how would you use SRP
key material with K5?), but I don't think that's either necessary or
desirable to solve within the scope of AES.  What's here is klunky
and doesn't divide things up quite the way I think they should be.
But it is sufficient for my purposes and I can make it do what I want.

The main argument I have with pbkdf2 is that I think the default
iteration count adds too little security for the decrease in utility.

				-Marcus Watts

---

From: Ken Raeburn <[email-masked]>
Date: Tue, 04 Mar 2003 21:06:55 -0500

Marcus Watts <[email-masked]> writes:
> because it seems like that's been bad in the past.

I'm no cryptographer; I'm just going by what I've read (in this case,
RFC 2104 section 5), and I don't generally go digging up
crypto-cracking research papers.  I haven't read anything about
problems with an HMAC shorter than the key size.  When has it been a
problem?

>  Perhaps the confounder

The HMAC isn't encrypted; it's simply concatenated with the
encrypted-but-not-authenticated confounder-plus-message-plus-pad.

> doesn't.

If the s2k parm spec is fixed when the encryption type is defined,
then a client that doesn't understand it does not implement that
encryption type, and had better not include it in the list of possible
enctypes sent in the AS-REQ message.  So the KDC shouldn't try using
it in that case.

Extending the s2k parameters after the initial specification instead
would mean the KDC replies with AES-with-new-params and the client
completely fails to decode it.

Defining "AES with a different string-to-key scheme" as a different
enctype just transfers the mess to the client-server exchange, where
two implementations implementing different AES schemes differing only
in the s2k function may not be able to agree on an AES session key
even though no s2k operation is needed.

>  It could easily be argued that the whole preauth/salt/enctype

No argument here, though it's many years too late to fix some of it
cleanly without defining a lot of existing code as out of spec.

How preauth schemes might fit into key production is still pretty
haphazard.  Do we write preauth schemes that take passwords and
eventually give us keys?  Take keys generated "normally" (i.e., by
Kerberos cryptosystem specified means) and just do a more secure
exchange with the KDC?  Produce keying material to be combined in some
unspecified way with the password-derived key?  And can more than one
preauth scheme be used?  (Say, timestamp preauth plus
host-key-protected exchange?)  How would they interact?

> iteration count adds too little security for the decrease in utility.

I kind of agree, but Microsoft's position as related by John Brezak
was strongly in favor of doing it this way -- much more strongly than
I was opposed.

Ken