< draft-bellovin-mandate-keymgmt-02.txt   draft-bellovin-mandate-keymgmt-03.txt >
Network Working Group Steven M. Bellovin Network Working Group Steven M. Bellovin
Internet Draft Columbia University Internet Draft Columbia University
January 2005 Russell Housley January 2005 Russell Housley
Expires in six months Vigil Security Expires in six months Vigil Security
Guidelines for Cryptographic Key Management Guidelines for Cryptographic Key Management
draft-bellovin-mandate-keymgmt-02.txt draft-bellovin-mandate-keymgmt-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668. disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 38 skipping to change at page 2, line 38
These guidelines are for use by IETF working groups and protocol These guidelines are for use by IETF working groups and protocol
authors who are determining whether to mandate automated key authors who are determining whether to mandate automated key
management and whether manual key management is acceptable. Informed management and whether manual key management is acceptable. Informed
judgment is needed. judgment is needed.
The term "key management" is the establishment of cryptographic The term "key management" is the establishment of cryptographic
keying material for use with a cryptographic algorithm to provide keying material for use with a cryptographic algorithm to provide
protocol security services, especially integrity, authentication, and protocol security services, especially integrity, authentication, and
confidentiality. Automated key management derives one or more short- confidentiality. Automated key management derives one or more short-
term session key. The key derivation function may make use of long- term session keys. The key derivation function may make use of long-
term keys to incorporate authentication into the process. The manner term keys to incorporate authentication into the process. The manner
in which this long-term key is distributed to the peers and the type in which this long-term key is distributed to the peers and the type
of key used (pre-shared symmetric secret value, RSA public key, DSA of key used (pre-shared symmetric secret value, RSA public key, DSA
public key, and others) is beyond the scope of this document. public key, and others) is beyond the scope of this document.
However, it is part of the overall key management solution. Manual However, it is part of the overall key management solution. Manual
key management is used to distribute such values. Manual key key management is used to distribute such values. Manual key
management can also be used to distribute long-term session keys. management can also be used to distribute long-term session keys.
Automated key management and manual key management provide very Automated key management and manual key management provide very
different features. In particular, the protocol associated with an different features. In particular, the protocol associated with an
automated key management technique will confirm liveness of the peer, automated key management technique will confirm liveness of the peer,
protect against replay, authenticate the source of the short-term protect against replay, authenticate the source of the short-term
session key, associate protocol state information with the short-term session key, associate protocol state information with the short-term
session key, and ensure that a fresh short-term session key is session key, and ensure that a fresh short-term session key is
generated. Further, an automated key management protocol can improve generated. Further, an automated key management protocol can improve
interoperability by including negotiation mechanisms for interoperability by including negotiation mechanisms for
cryptographic algorithms. These valuable features are impossible or cryptographic algorithms. These valuable features are impossible or
extremely cumbersome with manual key management. extremely cumbersome with manual key management.
Implementations of some symmetric cryptographic algorithms Implementations of some symmetric cryptographic algorithms are
implementation are required to prevent the overuse of each key. An required to prevent the overuse of each key. An implementation of
implementation of such algorithms can make use of automated key such algorithms can make use of automated key management when the
management when the usage limits are nearly exhausted to establish usage limits are nearly exhausted to establish replacement keys
replacement keys before the limits are reached, thereby maintaining before the limits are reached, thereby maintaining secure
secure communications. communications.
Examples of automated key management systems include IPsec IKE and Examples of automated key management systems include IPsec IKE and
Kerberos. S/MIME and TLS also include automated key management Kerberos. S/MIME and TLS also include automated key management
functions. functions.
Key management schemes should not be designed by amateurs; it is Key management schemes should not be designed by amateurs; it is
almost certainly inappropriate for working groups to design their almost certainly inappropriate for working groups to design their
own. To put it in concrete terms, the very first key management own. To put it in concrete terms, the very first key management
protocol in the open literature was published in 1978 [NS]. A flaw protocol in the open literature was published in 1978 [NS]. A flaw
and a fix were published in 1981 [DS], and the fix was cracked in and a fix were published in 1981 [DS], and the fix was cracked in
1994 [AN]. In 1995 [L], a new flaw was found in the original 1978 1994 [AN]. In 1995 [L], a new flaw was found in the original 1978
version, in an area not affected by the 1981/1994 issue. All of version, in an area not affected by the 1981/1994 issue. All of
these flaws were blindingly obvious once described -- yet no one these flaws were blindingly obvious once described -- yet no one
spotted them earlier. Note that the original protocol (translated to spotted them earlier. Note that the original protocol (translated to
employ about certificates, which had not been invented at that time) employ certificates, which had not been invented at that time) was
was only three messages. only three messages.
Key management software is not always large or bloated; even IKEv1 Key management software is not always large or bloated; even IKEv1
[HC] can be done in less than 200 Kbytes of object code, and TLS [DA] [HC] can be done in less than 200 Kbytes of object code, and TLS [DA]
in half that space. (Note that this TLS estimate includes other in half that space. (Note that this TLS estimate includes other
functionality as well.) functionality as well.)
A session key is used to protect a payload. The nature of the A session key is used to protect a payload. The nature of the
payload depends on the layer where the symmetric cryptography is payload depends on the layer where the symmetric cryptography is
applied. applied.
In general, automated key management SHOULD be used to establish In general, automated key management SHOULD be used to establish
session keys. This is a very strong "SHOULD", meaning the session keys. This is a very strong "SHOULD", meaning the
justification is needed in the security considerations section of a justification is needed in the security considerations section of a
proposal that makes use of manual key management. proposal that makes use of manual key management.
2.1. Automated Key Management 2.1. Automated Key Management
Automated key management MUST be used if any of these conditions Automated key management MUST be used if any of these conditions
hold: hold:
A central party will have to manage n^2 static keys, where n may A party will have to manage n^2 static keys, where n may become
become large. large.
Any stream cipher (such as RC4 [TK], AES-CTR [NIST], or AES-CCM Any stream cipher (such as RC4 [TK], AES-CTR [NIST], or AES-CCM
[WHF]) is used. [WHF]) is used.
An initialization vector (IV) might be reused, especially an An initialization vector (IV) might be reused, especially an
implicit IV. (Note that random or pseudo-random explicit IVs implicit IV. (Note that random or pseudo-random explicit IVs
are not a problem unless the probability of repetition is high.) are not a problem unless the probability of repetition is high.)
Large amounts of data might need to be encrypted in a short Large amounts of data might need to be encrypted in a short
time, causing frequent change of the short-term session key. time, causing frequent change of the short-term session key.
skipping to change at page 5, line 15 skipping to change at page 5, line 15
management is appropriate falls to the proponents -- and it is a management is appropriate falls to the proponents -- and it is a
fairly high hurdle. fairly high hurdle.
Systems that employ manual key management need provisions for key Systems that employ manual key management need provisions for key
changes. There MUST be some way to indicate which key is in use, to changes. There MUST be some way to indicate which key is in use, to
avoid problems during transition. Designs SHOULD sketch plausible avoid problems during transition. Designs SHOULD sketch plausible
mechanisms for deploying new keys and replacing old ones, which might mechanisms for deploying new keys and replacing old ones, which might
have been compromised. If done well, such mechanisms can later be have been compromised. If done well, such mechanisms can later be
used by an add-on key management scheme. used by an add-on key management scheme.
Lack of clarity about who the principals are is not a valid reason Lack of clarity about the parties involved in authentication is not a
for avoiding key management. Rather, it tends to indicate a deeper valid reason for avoiding key management. Rather, it tends to
problem with the underlying security model. indicate a deeper problem with the underlying security model.
2.3. Key Size and Random Values 2.3. Key Size and Random Values
Guidance on cryptographic key size for public keys used for Guidance on cryptographic key size for public keys used for
exchanging symmetric keys can be found in BCP 86 [OH]. exchanging symmetric keys can be found in BCP 86 [OH].
When manual key management is used, long-term shared secret values When manual key management is used, long-term shared secret values
SHOULD be at least 128 bits. SHOULD be at least 128 bits.
Guidance on random number generation can be found in RFC 1750 [ECS]. Guidance on random number generation can be found in RFC 1750 [ECS].
 End of changes. 6 change blocks. 
15 lines changed or deleted 15 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/