Subject: RE: AES draft...

From: "Paul Leach" <[email-masked]>
Date: Mon, 5 May 2003 13:31:24 -0700

> -----Original Message-----
> From: Paul Leach 
> Sent: Monday, May 05, 2003 10:53 AM
> To: 'Sam Hartman'
> Cc: Ken Raeburn; [email-masked]
> Subject: RE: AES draft...
> 
> I'm working on a longer answer, but the gist of it will be that,
> although I'd prefer a "safe" recommmendation, I'll be OK with almost any
> recommended value for optimitistic preauth is as long as
> 1. we provide adequate guidance in the security considerations section
> about the consequences of a given choice

IMO, adequate guidance would include
1. For some representative choices of iteration count, a rough estimate of
the amount of time to break a password, or the number of machines needed
to break the password in 45 days (or some other reasonable password change
interval)
It should include the assumptions used to make the estimate, such as speed
of machine, the maximum entropy that user's might be expected to choose
given automated checking for "complex" passwords (which, as I noted, I
think is around 2**32), etc, (i.e., assumptions such as the ones in my
simple timing model)
2. It should note that the iteration count would need to be increased by
40-60% a year to keep the cost to an attacker constant
3. A recommendation that the above kind of info be passed along in the
documentation of any implementation.

In addition, it would be usful to note that some older but still in use
machines can easily be ten times slower, and PDAs etc slower still...

And perhaps a note that new preauth schemes that don't have this problem
should be looked for in the future and considered when they become
available.

The idea is just to give implementors and ultimate users the info they
need to make a rational tradeoff.

I'll volunteer to provide draft-ready text if everyone agrees about the
general principle.

Paul

---

From: Sam Hartman <[email-masked]>
Date: Mon, 05 May 2003 17:19:18 -0400

If I'm understanding what you propose now, I think I agree with it.

1) We should separate out the recommendation for optimistic preauth
   from the recommendation for no-s2k-params.  Currently we give no
   recommendation for optimistic preauth, you believe we should do so.

2) We pick a number.  So far I don't think anyone has objected to to
   45056 for optimistic preauth.  I think my objections for default
   s2k params being large don't apply as much to the optimistic
   preauth number because there are fewer situations when you are
   forced to use the optimistic number.  If it is not right for your
   environment, you can avoid it.  Especially on the KDC side, it is
   simpler to implement initially using the no s2k params number.

3) We pick a different number for the no s2kparams case.  Ken proposed
   4096.  I'm uncomfortable with 16, because it seems you wouldn't
   want to use a number that slow in practice.

4) We add significant text to security considerations giving the
     guidance you recommend and discussing your timing model.

Will this make everyone happy?

---

From: Ken Raeburn <[email-masked]>
Date: Tue, 06 May 2003 16:29:24 -0400

>    recommendation for optimistic preauth, you believe we should do so.

For optimistic preauth, we give a recommendation, and make clear that
it is no more than that, and that implementations may use other
information or configuration settings to pick other numbers.  A
specific example I'd recommend of such information would be the
iteration count last successfully used to authenticate the same client
principal, or perhaps any principal in the realm, provided the
long-term key is unlikely to have been changed since (possible
heuristics including time since last login, a stored very short hash
of the password, or just retaining the data through a single login
session).  The salt string for a principal may be cached the same way.

For no-s2k-params, it's a specification, not a recommendation.  Any
disagreement will lead to a lack of interoperability in the
no-s2k-params case.

> Will this make everyone happy?

Aside from the above details, yes, I think so.

Ken