Subject: Re: [karp] Why automatic key management

From: "Dan Harkins" <[email-masked]>
Date: Thu, 29 Jul 2010 01:21:24 -0700 (PDT)

It was noted in Gregory's presentation today that "why automatic
key management?" is still an open issue. I can't quibble with Eric's
text below but let me add another reason: we cannot build a secure
system without an automatic key management protocol.

  The cryptographic primitives we're all planning on using to protect
routing protocols-- HMAC-whatever, AES in whatever mode, KDFs, etc-- are
all secure under certain assumptions about the properties of the key
being provided to that primitive, namely that it is a uniformly random
string of bits. It is infeasible for identical uniformly random strings
of bits to be obtained by N people where N > 1 without a key management
protocol. If we cannot guarantee that the keys we're using with these
primitives have the required properties then we shouldn't be using them
with these primitives. In other words, if you don't want automated key
management then you should just stick with statically keyed MD5.

  regards,

  Dan.

On Sat, April 3, 2010 7:20 am, Eric Rescorla wrote:
> I promised to provide some text. Here it is:
>
> The use of automatic key management mechanisms offers a number of
> benefits over manual keying. First, it provides fresh traffic keying
> material for each session, thus helping to prevent a number of attacks
> such as inter-connection replay and two-time pads. Second, it allows
> for the negotiation of algorithms, modes, and parameters, thus
> providing interoperability between endpoints with disparate
> capabilities and configurations. This second point is especially
> important because it enables incremental deployment of endpoints with
> new capabilities while retaining backward compatibility.
>
> -Ekr
> _______________________________________________
> karp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/karp
>

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 29 Jul 2010 08:51:29 -0400

On Sat, Apr 3, 2010 at 8:16 PM, Vishwas Manral <[email-masked]> wrote:
> Ekr,
>
> If Manual Keys are not changed it is a clear vulnerability that is
> introduced. Then this is an even bigger issue with manual keying.

to be very clear here, today in a network of more than a few routers
you can not change keys without bouncing sessions, potentially all
sessions which share a common key.

by 'key' here I mean 'long term key'

> If however the manual keys are changed by administrator it leads to
> administrative overhead.
>
> There is still overhead of changing long-term keys if we use
> Keytables. It however would not be the issue if we were using a DH or
> EC-DH.

these will only offer session level keys, yes? (which is fine, but
still the long term key needs to be updatable in a sane fashion)

-chris

> I guess from the discussion as well as mails from Joel it is clear to
> probably define what we mean by "Automatic Key Management". Once we
> have that clear we can define the positives/ negatives of a compared
> to the other.
>
> Thanks,
> Vishwas
>
> On Sat, Apr 3, 2010 at 4:56 PM, Eric Rescorla <[email-masked]> wrote:
>> On Sat, Apr 3, 2010 at 4:54 PM, Vishwas Manral <[email-masked]> wrote:
>>> Manual Keying requires more administrative overhead of actually
>>> configuring/ changing the Keys etc, which can be done automatically
>>> using automatic keying.
>>
>> I don't agree with this claim, since (1) people typically don't change their
>> manual keys often at all (2) you still have overhead if you want to
>> change the long-term keys, which is what happens if, for instance,
>> an employee leaves.
>>
>> -Ekr
>>