Subject: RE: AES and SHA-1 timing

From: "Paul Leach" <[email-masked]>
Date: Wed, 16 Apr 2003 17:03:26 -0700

>
> -----Original Message-----
> From: Ken Raeburn [mailto:[email-masked]]
> Sent: Wednesday, April 16, 2003 3:03 PM
> To: Paul Leach
> Cc: [email-masked]
>
> > A (very small) new standard could periodically be issued
> > with the new default.
>
> It would need to specify a new enctype number.  Otherwise, we
> invalidate existing compliant implementations every time we do it.

I may be missing something, but it's only specifying a default.

I think I had the mental model that the iteration count was handled like
(as part of?) the salt -- if you used the wrong one, you got told what the
right one to use is.

If that's correct, then changing the default wouldn't cause
non-compliance.

If not, can it be made to be correct?

>
> > At the very least, there should be a RECOMMENDATION that
> the values in
> > use get increased every year.
>
> I'd be fine with this, as long as it's mentioned in
> conjunction with the use of the count as a means to dissuade
> offline attacks.  If a site is requiring a strong preauth
> system that reveals nothing encrypted in the user's key, the
> recommendation doesn't really apply.

Maybe we can do even better. IIRC, the only time the high iteration count
needs to be used is for the PA-ENC-TIMESTAMP _and_ the key is dereived
from human-usable password _and_ the PA-ENC-TIMESTAMP isn't protected some
other way from being sniffed. Services whose accounts have randomly
generated passwords wouldn't need a high iteration count. If IPSEC were
being used to protect the traffic to the KDC, there would not need to be a
high iteration count. If some other preauth scheme were used that wasn't
subject to offline parallelizable dictionary attacks, then there would not
need to be a high iteration count. Etc.

Is it possible to have two defaults (high and low), one for each case?

Paul

---

From: Marcus Watts <[email-masked]>
Date: Wed, 16 Apr 2003 22:27:21 -0400

> If not, can it be made to be correct?

My understanding is that iteration count works just like salt.  But
really, there should be a check for minimal & maximal values on the
client side at least - minimal if an attacker can supply a count too
small and get keyed preauth data, maximal to prevent an attacker for
tying up somebody's workstation or web server for the next 26,000
years.  Both should be configurable not hard-wired into binaries.

There is a related issue of how does the user or administrator set the
iteration count when *changing* passwords - I don't know what hoooks
are in the setpassword protocol to do that.  There should be analogous
hooks - one of the reasons I was keen on making the wire salt a list of
per-crypto system values rather than uninterpreted binary data was to
avoid having to make protocol changes and instead make this
cryptosystem specific.  With etype_info2, we have a different place to
put this (which is adequate, but not so elegant) but now all those
administrative front-ends that can set the salt also needs a way to set
parameter values in etype_info2.  Of course, anything that expects to
set iteration count (or I have one application where I need to kludge
in alternate string to key parameters for transition) also ought to
have syntax for those alternate crypto systems which is yet another
implementation complexity.

> Is it possible to have two defaults (high and low), one for each case?

The default should ordinary only apply when *setting* a password
using an "out of the box" implementation.  "hi"/"low" limits ought
to apply when looking at the aggregate of offered pre-authentication
data or actual ticket, and deciding how much data the client will "leak"
to the server or other observers on the wire.

For instance, several cases:

[1] server actually suppplies a ticket, already encrypted under the
	user's AES key.  The client need not impose a min limit, since
	it won't be leaking any information.  The client should impose
	a max limit, to avoid DOS attacks.  Of course, the KDC might
	not want to blindly give out tickets for users who don't have
	large iteration counts.

[2] client decides to use PA-TIME-ENC.  Client should impose a min
	limit, since the data it supplies in the packet would allow any
	observer to mount an offline crack attack.

[3] client has a sufficiently strong local host or session key, and has
	some preauth method that can use this to encrypt data in transit.
	(Several have been proposed; I don't think any have yet been
	standardized, but this is not difficult technically...)
	Since this protects everything on the wire, there's no
	reason to impose a min limit.  A max limit still matters.

[3] client has a weak local host or session key (say, des), and has
	some preauth method that can use this to encrypt data in
	transit.  This obviously strengthens the exchange.  Probably
	some intermediate min value is appropriate.

	Note, even a weak key improves security more than increasing
	the iteration count.  Using DES appropriately increases the
	attacker's work function by the difficulty of breaking DES.  So
	using DES is roughly equivalent to using an iteration count of
	at least 1E15, but without all the slowness for legitimate
	users.

[4] There are plenty of authenticated key exchanges that directly use
	PK and weak symmetric keys.  Ignoring the many patent issues,
	most of these will greatly improve the security.  There is a
	bit of a time/space/security tradeoff; one might chose to use
	weaker keys to achieve acceptable packet size & run time, in
	which case some min value might be appropriate.  With longer
	keys, a min value might not be necessary.  Of course, given
	the software patent issues, this is probably only of academic
	interest, for now...

"hi"/"low" values could conceivably also apply when changing one's
password, or when an adminstrator sets a new value.  It probably makes
sense for the server daemon to reject any value that will never be
acceptable (ie, max value).  The default value should be one that is
larger than any min value that any combination of preauth methods might
impose.  Presumably, a user or administrator who explicitly sets a
lower min value is saying that that particular user will only be using
"more secure" authentication methods that do not leak information, or
has picked an extra long and complicated password that presumably has
more entropy in it than average.  (I know of *one* person in my
experience who has a password > 30 characters.)

The default, min and max values here should all be configurable on the
server side, allowing sites to decide where they want to spend their
security beans.  Fancy software could provide an option to specify a
default value that is in part a function of time. (if you believe in
moore's law, perhaps default=45056+30000*(year-2002)).

Making the iteration count variable in this way does not make the
iteration count issue go away.  The "min" count will result in
applications where there is no acceptable solution; that is, it will
rule out AES completely for certain applications.  The "default" rule
sets people's perception of the speed of AES.  If they see sluggish
login times vs. using DES3 or RC4, they may decide AES is unacceptably
slow.

> Paul
				-Marcus Watts
				UM ITCS Umich Systems Group

---

From: Ken Raeburn <[email-masked]>
Date: Wed, 16 Apr 2003 23:36:42 -0400

> (as part of?) the salt -- if you used the wrong one, you got told what the

Yes, you should.  Not that the KDC knows what parameter you got wrong,
it just gives them to you and should basically ignore the wrong
preauth data you sent.

But the iteration count we're talking about isn't the number the
client should assume when sending preauth data in the first exchange
with the KDC.  It's the iteration count that should be considered to
be specified if the KDC does *not* send you the ETYPE-INFO2 data
indicating a specific count -- what iteration count is implied by its
absence?  (Similarly, we indicate the default salt string to use in
Clarifications, in case ETYPE-INFO2 and other preauth data don't
specify it.)

If you want to send a PA-ENC-TIMESTAMP using AES in your first
message, and you want to assume 45056 iterations, fine.  If you want
to assume 4096 iterations, and a salt string of "wonton soup", that's
fine too.  You could also re-use the values you were given the last
time, and hope that they haven't changed.  But until you hear from the
KDC, you're just guessing at how the KDC -- or your entry in the
database -- is configured.

> If that's correct, then changing the default wouldn't cause

It would change the key computation in the case with no ETYPE-INFO2
preauth data in the AS-REP.  That case needs to have a specific
meaning, not one we change when we feel like it.  (That meaning could
involve a schedule of values increasing at various specific times
based on Moore's Law, but there are several reasons I'd be opposed to
such an approach.)

The ETYPE-INFO2 data is not required, at the protocol level.  We have
a default salt string, and each cryptosystem indicates the default
additional parameters to use.  A particular implementation or
installation may have policies that in effect always require
ETYPE-INFO2 to be sent, because one or more of the default parameters
from the specification are never (or not normally) used; that's a
different matter.

> Is it possible to have two defaults (high and low), one for each case?

If we do that, then the client-side Kerberos code needs to know
whether IPSEC is being used (and in some non-anonymous mode, to ensure
the KDC really is the KDC, and not in tunnel mode, unless we can
guarantee that the KDC is the other endpoint of the tunnel so no
eavesdropping can happen at that end).

Seems like an ugly layering problem to me.  Is there even a standard
way in the sockets API to find out if a UDP packet exchange is
protected with IPSEC, and how it's configured?  Or attempt to do an
exchange but require that it fail if IPSEC protection isn't available?
If not, how should the client know?

Ken

---

From: Derek Atkins <[email-masked]>
Date: 17 Apr 2003 11:05:08 -0400

> If not, how should the client know?

It gets even worse...  How do you key the IPsec SAs?  Either you're
running IKE, which means a bunch of Diffie-Hellman and RSA operations,
or you're using Kerberos, which would imply a chicken-and-egg problem.
Just imagine the DoS attacks you could mount against the KDC by setting
up tons of IPsec state!

So much for the KDC being "fast"....

> Ken

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 17 Apr 2003 09:03:17 -0700

> implementation complexity.

Should set-password clients be able to specify the salt and/or
s2kparams?  If so I'll add that to the draft.

Nico
--

---

From: Ken Raeburn <[email-masked]>
Date: Thu, 17 Apr 2003 15:29:03 -0400

> s2kparams?  If so I'll add that to the draft.

I would say probably not...

Ken