management agenda item -- automated key management (fwd)

[Steve Bellovin <smb@research.att.com>]

I forgot to cc the iesg on this note.


------- Forwarded Message

X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4
From: Steve Bellovin <smb@research.att.com>
To: iesg-secretary@ietf.org
Subject: management agenda item -- automated key management
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 28 Mar 2003 12:07:19 -0500

Please add "automated key management" to Thursday's agenda.
It's the outcome of discussions within the security directorate.


- --------
These are a set of guidelines, not rules, for evaluating when automated 
key management should or shouldn't be used.  Informed judgment is 
necessary when applying them.

In this context, "key management" is automatic derivation of
session key(s), as opposite to long-term keys used to
authenticate the derived key(s). How this long-term
key gets to the talking entities and what kind of
a key it is (pre-shared secret, RSA public key, DSA, you-name-it)
is beyond the scope of this document.  Examples of key management
systems include IKE and Kerberos; S/MIME and TLS include key
management functions.

A session key is used to protect application data.

In general, automated key management SHOULD be used.  This is a
very strong "SHOULD".

Key management MUST be used if:

	A central party will have to manage n^2 static keys.

	A stream cipher (i.e., RC4) is used.

	Long-lived session keys are used by more than two parties.
	(Except for multicast, this is a dubious situation in the first
	place, and should generally be discouraged no matter what.)

	The likely operational environment is one where personnel
	(or device) turnover is reasonably frequent, thus creating
	a requirement for frequent rekeying.

Even manually-keyed systems need some provision for key changes;
there must be some way to indicate which key is in use, to avoid
problems during transition.  Designs should sketch plausible
mechanisms for deploying new keys and/or revoking compromised keys.
If done well, such mechanisms can later be used by an add-on key
management scheme.

Lack of automated key management can lead to vulnerabilities,
including (but not limited to) cryptographic weaknesses or loss of
some functionality, such as replay protection.

Key management software is not always large or bloated; even IKEv1
can be done in <200K, and TLS in half that much space.  (TLS includes
other functionality as well.)

Lack of clarity about who the principals are is not a valid reason
for avoiding key management.  Rather, it tends to indicate a deeper
problem with the underlying security model.

Key management schemes should not be designed by amateurs; it is
almost certainly inappropriate for WGs to design their own.  To
put it in concrete terms, the very first key management protocol
in the open literature was published in 1978.  A flaw was published
in 1983.  The fix proposed in 1983 was cracked in 1994.  In 1996,
a new flaw was found in the original 1978 version, in an area not
affected by the 1983/1994 issue.  All of these flaws were blindingly
obvious once described -- but no one spotted them earlier.  Note
that the original protocol (translated to know about certificates, 
which hadn't been invented at the time) was only 3 messages.

Situations where a desire to avoid key mangement may be reasonable
include:

	Very limited available bandwidth or very high round-trip
	times.  There are interactions here -- public key systems
	tend to require long messages and lots of computation;
	symmetric key alternatives, such as Kerberos, often require 
	several round trips and interaction with third parties.

	Low value of the information

	Very limited scale of each deployment

Note that assertions about such things should often be viewed with
the skepticism afforded to claims that "this will only be used on
a LAN or two".  In other words, the burden of demonstrating that
manual key management is appropriate should be on the proponents
- --- and it's a fairly high barrier that they need to overcome.




		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com (2nd edition of "Firewalls" book)



------- End of Forwarded Message



		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com (2nd edition of "Firewalls" book)