Subject: RE: AES and SHA-1 timing

From: "Paul Leach" <[email-masked]>
Date: Thu, 17 Apr 2003 11:14:25 -0700

> 
> -----Original Message-----
> From: Derek Atkins [mailto:[email-masked]] 
> Sent: Thursday, April 17, 2003 8:05 AM
> To: Ken Raeburn
> Cc: Paul Leach; [email-masked]; Todd Stecher
> 
> 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"....

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.

There are lots of fascinating issues with using IPSEC to protect
AS-REQs, but I wasn't trying to get into them. There are other issues
with how the Kerberos client would know that it was OK to use the lower
iteration count, as well, but I believe that having such knowledge is
feasible.

Paul

---

From: "Derek Atkins" <[email-masked]>
Date: 17 Apr 2003 14:27:29 -0400

> network was physically secured from sniffing, for example.

Ok, that was unclear...  Personally, I can't see any reason to every
try to use IPsec to talk secure KDC requests.  It seems both counter-
intuitive and also a waste of computrons.  The whole KINK concept is
that Kerberos is fast, IKE is slow, let's use Kerberos to key IPsec...
If you had to use IPsec to get to the KDC that wouldn't work very well.

So, I'm glad we're on the same page here, but I think even mentioning
it is opening a can of worms.  Apples and Onions....  (oranges are
at least still a fruit).

> iteration count, as well, but I believe that having such knowledge is

Agreed, I dont think we should even go down this road -- as soon as
you talk about trying to protect AS-REQ with IPsec, the first question
is "how do you key your IPsec connection?"  Chicken and Egg...  I want
to key IPsec with Kerberos, but I need Kerberos to key IPsec.  How do
I get my TGT if I need a Kerberos ticket to key IPsec to make the
request of the KDC to get my TGT?  You get the point.  Yes, facinating
issues, but not ones we should contemplate..  :)

Kerberos should stand on its own and not depend on any other security
toolkit.  I think there are a number of ways to do this, either by
PKINIT, EKE/SPEKE/SRP, DCE-RFC-26, or something else.  We should focus
on those methods.

> Paul

-derek

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

---

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

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

> iteration count, as well, but I believe that having such knowledge is

Probably true.  But for things like IPSEC, I think requiring that all
implementations be able to obtain such knowledge, simply in order to
determine the correct iteration count if ETYPE-INFO2 is omitted, is
not reasonable.

Ken

---

From: "Douglas E. Engert" <[email-masked]>
Date: Tue, 22 Apr 2003 13:40:29 -0500

OK what is the consensus on this issue? I count 26 messages. 

Ken, any suggested text that will make everyone happy?

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444