Subject: RE: AES draft...

From: "Paul Leach" <[email-masked]>
Date: Thu, 1 May 2003 19:46:58 -0700

> -----Original Message-----
> From: Ken Raeburn [mailto:[email-masked]] 
> Sent: Wednesday, April 30, 2003 4:58 PM
> To: [email-masked]
> Subject: AES draft...
> 
> Okay, it looks like the main issue for the AES draft is the 
> iteration count for PBKDF2 when the KDC chooses not to send 
> you the s2k-params data for AES in an ETYPE-INFO2 message.
> 
> I phrased that carefully.  It's not a number we're insisting 
> you assume when doing optimistic PA-ENC-TIMESTAMP 
> preauthentication without having heard from the KDC.

As it turns out, all I'm really interested in is the number that should be
assumed when doing optimistic PA-ENC-TIMESTAMP preauthentication without
having heard from the KDC.

I think we should RECOMMEND two numbers: one for use when the password is
weak and no other protection is being used, and one for use either when
the password is strong (e.g. services) or when some other mechanism is
being used to prevent the preauth from being sniffed.

For the first case, I think we should choose one that is a compromise
between how long it takes to log in on the feebler machines that are
commonly in use, and how much work we think is "enough" to deter an
attacker by making it cost too much to crack it in a reasonable amount of
time.

For the second case, a small number like 16 would be fine.

I think the security considerations section should note that, _if_
encrypted timestamp preath is going to be used (perhaps mentioning that
better preauth mechanisms might be coming down the pike), then the "first
case" recommendation will need to be increased by 40% to 60% per year if
they want to keep the cost to the attacker constant. (Presumably, older
slower machines get retired, so raising the iteration count won't increase
the time to logon for the average machine in use.)

Having said that, I think that the default (in the sense of your first
paragraph) might as well be the "first case" number.

Now, as to the number itself. I'd like to drive it by a concensus on how
much we think it should cost an attacker today to buy enough machines to
crack the password before it expires, using reasonable assumptions about
how much the most cost effective machine cost today, and how fast they
are. (The fact that machines are getting faster every year is covered by
the recommendation to raise the count by 40-60%/year if they want to keep
the cost constant.)

My cost model led to a conclusion that the attacker would have to spend
$150,000 to crack a password in 45 days given the current iteration count
in the draft. If we get rough concensus that we don't need to have that
high a cost, then we can reduce the iteration count. But the decision
ought to be made with everyone being aware and comfortable with what it
would cost an attacker to break it, and we ought to state in the security
considerations section how much we think it will cost to crack a preauth
using whatever number we pick (i.e. we shouldn't be embarrassed with how
low it is). This cost model information would also help users make
informed decisions should they decide that performance requirements for
their environment dictated a lower iteration count.

Paul

---

From: Ken Hornstein <[email-masked]>
Date: Fri, 02 May 2003 00:17:11 -0400

>For the second case, a small number like 16 would be fine.

Just as a data point: I think an iteration count > 1 is at best shoving
back the tide and at worst a serious performance impact on machines
we still expect to be getting 5-10 years more service out of, so _I_
think the default should be 1 (and in any realm I adminstrate, that is
what I'm going to set it at).

While I think good crypto is important, I try to keep a sense of
real-world perspective.  I don't even lose that much sleep about
the preponderance of single-DES in our realm.  Yes, we're in the middle
of a transition to 3DES now, but if it takes another year, I'm not
really worried.  The simple truth is that brute-force attacks against
our Kerberos realm are simply non-existant.  Yes, I think about it
in the long run, and that's why we're deploying a hardware-preauth based
solution to this problem.  But really, brute-force attacks simply
don't happen to us; there are always more interesting targets.

My other concern about a high iteration count is this: I could very
easily see a case where turning on AES makes login "too slow" on many
machines and as a result lead to sites where AES is NEVER adopted because
of the problems it causes.  That would be very unfortunate IMHO.

>high a cost, then we can reduce the iteration count.

It's been my experience that people attacking us spend around $0
(aside from their personal computer), so again, this reflects in
my desire for a low default.  I fully realize that this threat
model doesn't apply to everybody, but I have to believe that it's
not atypical.  I'm sympathetic to installations that have concerns
like industrial espionage where real money might be spent attacking
their realm, but it just seems like we're solving this problem the
wrong way.  But again, I'm just one guy.

--Ken

---

From: Michael Thomas <[email-masked]>
Date: Thu, 1 May 2003 22:35:09 -0700 (PDT)

FWIW, I place a lot of credence in a guy who runs
a site that ostensibly ought to be a target and
who doesn't lose sleep over all of this. So long
as there are ways to dial up security for
paranoids, I'd prefer we err on the side of
usability too.

	   Mike

---

From: Ken Raeburn <[email-masked]>
Date: Fri, 02 May 2003 03:53:16 -0400

> what I'm going to set it at).

I was wondering if anyone would argue for 1. :-)

>   Yes, I think about it
> solution to this problem.

I think any site worrying about the Paul's attacker with $150K to
throw around today is going to use preauth, and some scheme other than
PA-ENC-TIMESTAMP.  And for the long run, we do have two or three other
schemes on the back burner; after we get Clarifications out, they
should get more attention.

I would hope the non-preauth exchange, and PA-ENC-TIMESTAMP, start
getting phased out within some very small number of years, to the
point where any Kerberos 5.4 specification (anything after Extensions,
which would presumably be 5.3, as Clarifications is 5.2) would
recommend or require using something better, eliminating these kinds
of offline attacks.

Ken

---

From: Sam Hartman <[email-masked]>
Date: Sat, 03 May 2003 21:21:39 -0400

Paul, Do you think we can get consensus on a recommendation for
optimistic preauth?  If not, then we should not hold up the draft for
this issue as it is something that can be left up to implementations.

Would you be happy with the current 47??? number as a recommendation
for optimistic preauth at the current time?  Would anyone object to
this?

I 'd actually prefer a larger number than 16 for the no-s2k-params
case although I'm not sure I can justify that recommendation.  Would
anyone actually object to 4096?