Subject: RE: AES and SHA-1 timing

From: "Paul Leach" <[email-masked]>
Date: Tue, 22 Apr 2003 17:42:43 -0700

>
> -----Original Message-----
> From: Ken Raeburn [mailto:[email-masked]]
> Sent: Thursday, April 17, 2003 12:28 PM
> To: Paul Leach
> Cc: Derek Atkins; [email-masked]; Todd Stecher
>
> "Paul Leach" <[email-masked]> writes:
> > Whoa -- I wasn't actually suggesting putting anything in the spec
> > about using IPSEC! I was just using it as an example of
> where a high
> > iteration count wouldn't be needed. One also wouldn't need
> it if one
> > knew the network was physically secured from sniffing, for example.
>
> Yes, and I was just making the point that if you're proposing
> multiple defaults -- meaning multiple meanings for the absence of the
> ETYPE-INFO2 data -- based on external conditions, it makes
> things really messy.

That's not what I'm proposing -- I think we're using "default" in a
different way.

What I mean by "default" is the iteration count that a client, that has
not yet communicated with the KDC, should use in the string-to-key to
create the key to encrypt timestamp for the PA-ENC-TIMESTAMP preauth.

When I suggested that there be two defaults, I meant that a client that
knew that (e.g.) the preauth was safe from sniffing, or that its password
had high entropy, could use the small default iteration count (for
efficiency); otherwise it would use the higher default.

Discussion with developers here leads me to believe that having a
different cipher suite for each of these two cases would be preferable to
having two defaults for one cipher suite -- otherwise the KDC would have
to test the PA-ENC-TIMESTAMP against two keys, one derived from each
iteration count; and also that our schema for storing the keys has one key
per cipher suite, so two cipher suites would be more convenient there as
well.

> I'd have no problem with a KDC that
> specifies one iteration count when IPSEC is in use and
> another when it is not, or any other reasonable criteria.

Then I think we might be in agreement, as long as what I wrote above also
seems agreeable.

Paul

---

From: Ken Raeburn <[email-masked]>
Date: Wed, 23 Apr 2003 14:54:31 -0400

> That's not what I'm proposing -- I think we're using "default" in a

So do I...

> create the key to encrypt timestamp for the PA-ENC-TIMESTAMP preauth.

Ah, yes.  That's an interesting point.  On the one hand, it's only a
guess, so any number you pick can easily be wrong for a given
implementation, installation, or principal.  On the other hand, if you
pick a number here that's much lower than the KDC is using, it thwarts
this approach to protecting the user's key.  And if it's different in
any way from the KDC value, it's a waste of CPU time and the user's
time.

If we're going to specify this -- and I'm not 100% convinced that we
should -- it's still got all the security and useability issues we've
been discussing, but without the option of site configuration.  That
very lack is why I wonder if maybe we should leave it unspecified, and
allow implementations to use the default from the spec, record the
values from a previous exchange, permit site configuration, or
whatever, without specifically requiring any of those.  Perhaps we
could make suggestions (and security considerations) without making
requirements.

PA-ENC-TIMESTAMP is a dead end.  Once we get Clarifications out of the
way, we need to resume work on the various preauth schemes that have
been proposed.  So I think this only really matters in the short term.
And for the short term, I think even a small iteration count is
probably better than any string-to-key scheme we're using now.

> per cipher suite, so two cipher suites would be more convenient there as

Yes, having to test against N keys (why only two gradations of
security and not three or four depending on the quality of the ipsec
ciphersuite or of entropy for ipsec key generation?) would be
unfortunate.  Though if we allowed the client to send ETYPE-INFO2 to
the KDC, for the KDC to use to choose between several stored keys, we
might not have this problem.  (I haven't thought that idea through
yet.)

Ken