Guidelines for Cryptographic Key Management
RFC 4107 устанавливает рекомендации для рабочих групп IETF и авторов протоколов при выборе между автоматизированным и ручным управлением ключами. В общем случае для установления сеансовых ключей СЛЕДУЕТ (SHOULD) применять автоматизированное управление ключами; предложение ручного управления требует веского обоснования в разделе рассмотрения безопасности. Документ определяет условия, при которых автоматизированное управление ключами ДОЛЖНО (MUST) использоваться, включая масштабирование числа статических ключей, потоковые шифры, риск повторного использования IV и частую смену ключей. Ручное управление может быть приемлемо в ограниченных средах, однако требует средств смены ключей и особенно строгих требований к долговременным общим секретам.
Рабочая группа сети S. Bellovin
Запрос комментариев: 4107 Columbia University
BCP: 107 R. Housley
Категория: Лучшая современная практика Vigil Security
Июнь 2005
Руководство по управлению криптографическими ключами
Статус данного меморандума
Этот документ определяет Лучшую современную практику Интернета для
интернет-сообщества и запрашивает обсуждение и предложения по
улучшениям. Распространение этого меморандума не ограничено.
Уведомление об авторских правах
Copyright (C) The Internet Society (2005).
Аннотация
Часто возникает вопрос, требует ли данная система безопасности
некоторой формы автоматизированного управления ключами или достаточно
ручного управления ключами. Этот меморандум содержит руководство для
принятия таких решений. Когда в протоколе используются симметричные
криптографические механизмы, предполагается, что автоматизированное
управление ключами обычно, но не всегда необходимо. Если предлагается
ручное управление ключами, бремя доказательства того, что
автоматизированное управление ключами не требуется, ложится на
предлагающего.
1. Введение
Часто возникает вопрос, требует ли данная система безопасности
некоторой формы автоматизированного управления ключами или достаточно
ручного управления ключами.
На этот вопрос нет единственного ответа; обстоятельства различаются.
В общем случае следует (SHOULD) использовать автоматизированное
управление ключами. Иногда полагаться на ручное управление ключами
разумно; мы предлагаем некоторое руководство для вынесения такого
суждения.
С другой стороны, опора на ручное управление ключами имеет
существенные недостатки, и мы излагаем соображения безопасности,
обосновывающие предпочтение автоматизированного управления ключами.
Однако существуют ситуации, в которых ручное управление ключами
приемлемо.
Bellovin & Housley Лучшая современная практика [Страница 1]
RFC 4107 Руководство по управлению криптографическими ключами Июнь 2005
1.1. Терминология
Ключевые слова ДОЛЖЕН (MUST), НЕ ДОЛЖЕН (MUST NOT), ДОЛЖЕН (REQUIRED),
ДОЛЖЕН (SHALL), НЕ ДОЛЖЕН (SHALL NOT), СЛЕДУЕТ (SHOULD), НЕ СЛЕДУЕТ
(SHOULD NOT), СЛЕДУЕТ (RECOMMENDED), МОЖЕТ (MAY) и НЕОБЯЗАТЕЛЬНО
(OPTIONAL) при их появлении в этом документе подлежат толкованию,
описанному в RFC 2119 [B].
2. Руководство
Это руководство предназначено для использования рабочими группами
IETF и авторами протоколов, определяющими, следует ли предписывать
автоматизированное управление ключами и приемлемо ли ручное управление
ключами. Требуется осведомлённое суждение.
Термин «управление ключами» относится к установлению криптографического
ключевого материала для использования с криптографическим алгоритмом
с целью предоставления служб безопасности протокола, особенно
целостности, аутентификации и конфиденциальности. Автоматизированное
управление ключами выводит один или несколько краткосрочных сеансовых
ключей. Функция вывода ключей может использовать долгосрочные ключи
для включения аутентификации в этот процесс. Способ распределения этого
долгосрочного ключа между сторонами взаимодействия и тип используемого
ключа (предварительно распределённое симметричное секретное значение,
открытый ключ RSA, открытый ключ DSA и другие) выходят за рамки данного
документа. Однако это является частью общего решения по управлению
ключами. Для распространения таких значений используется ручное
управление ключами. Ручное управление ключами также может
использоваться для распространения долгосрочных сеансовых ключей.
Автоматизированное и ручное управление ключами предоставляют весьма
разные возможности. В частности, протокол, связанный с методом
автоматизированного управления ключами, подтвердит активность стороны
взаимодействия, защитит от воспроизведения, аутентифицирует источник
краткосрочного сеансового ключа, свяжет информацию о состоянии
протокола с краткосрочным сеансовым ключом и обеспечит создание нового
краткосрочного сеансового ключа. Кроме того, протокол
автоматизированного управления ключами может улучшить взаимодействие,
включая механизмы согласования криптографических алгоритмов. Эти ценные
возможности невозможно или чрезвычайно обременительно реализовать с
помощью ручного управления ключами.
Для некоторых симметричных криптографических алгоритмов реализации
должны предотвращать чрезмерное использование данного ключа. Реализация
таких алгоритмов может использовать автоматизированное управление
ключами, когда пределы использования почти исчерпаны, чтобы установить
заменяющие ключи до достижения пределов, тем самым сохраняя безопасную
связь.
Примеры систем автоматизированного управления ключами включают IPsec
IKE и Kerberos. S/MIME и TLS также включают функции автоматизированного
управления ключами.
Bellovin & Housley Лучшая современная практика [Страница 2]
RFC 4107 Руководство по управлению криптографическими ключами Июнь 2005
Схемы управления ключами не следует разрабатывать любителям; рабочим
группам почти наверняка неуместно разрабатывать собственные схемы. Если
выразить это конкретно, самый первый протокол управления ключами в
открытой литературе был опубликован в 1978 году [NS]. Ошибка и её
исправление были опубликованы в 1981 году [DS], а исправление было
взломано в 1994 году [AN]. В 1995 году [L] в исходной версии 1978 года
была обнаружена новая ошибка в области, не затронутой проблемой
1981/1994 годов. Все эти ошибки были очевидны после их описания, — но
никто не заметил их раньше. Обратите внимание, что исходный протокол
(переведённый на использование сертификатов, которые в то время ещё не
были изобретены) состоял всего из трёх сообщений.
Программное обеспечение управления ключами не всегда велико или
раздуто. Даже IKEv1 [HC] можно реализовать менее чем в 200 Kbytes
объектного кода, а TLS [DA] — в половине этого объёма. Обратите
внимание, что эта оценка для TLS также включает другую функциональность.
Сеансовый ключ используется для защиты полезной нагрузки. Характер
полезной нагрузки зависит от уровня, на котором применяется
симметричная криптография.
В общем случае для установления сеансовых ключей следует (SHOULD)
использовать автоматизированное управление ключами. В разделе
соображений безопасности предложения, использующего ручное управление
ключами, требуется веское обоснование.
2.1. Автоматизированное управление ключами
Автоматизированное управление ключами должно (MUST) использоваться,
если выполняется любое из следующих условий:
Стороне придётся управлять n^2 статическими ключами, где n может
стать большим.
Используется любой потоковый шифр (например, RC4 [TK], AES-CTR
[NIST] или AES-CCM [WHF]).
Вектор инициализации (IV) может быть использован повторно, особенно
неявный IV. Обратите внимание, что случайные или псевдослучайные
явные IV не являются проблемой, если только вероятность повторения
не высока.
Большие объёмы данных могут нуждаться в шифровании за короткое
время, вызывая частую смену краткосрочного сеансового ключа.
Долгосрочные сеансовые ключи используются более чем двумя сторонами.
Многоадресная рассылка является необходимым исключением, но для
предотвращения этого в будущем формируются стандарты управления
ключами многоадресной рассылки. Совместное использование
долгосрочных сеансовых ключей в общем случае следует не поощрять.
Bellovin & Housley Лучшая современная практика [Страница 3]
RFC 4107 Руководство по управлению криптографическими ключами Июнь 2005
Вероятная эксплуатационная среда такова, что смена персонала (или
устройств) происходит часто, вызывая частую смену краткосрочного
сеансового ключа.
2.2. Ручное управление ключами
Ручное управление ключами может быть разумным подходом в любой из
следующих ситуаций:
Среда имеет очень ограниченную доступную полосу пропускания или
очень высокое время кругового обхода. Системы с открытым ключом
обычно требуют длинных сообщений и большого объёма вычислений;
альтернативы на симметричных ключах, такие как Kerberos, часто
требуют нескольких круговых обходов и взаимодействия с третьими
сторонами.
Защищаемая информация имеет низкую ценность.
Общий объём трафика за весь срок существования долгосрочного
сеансового ключа будет очень мал.
Масштаб каждого развёртывания весьма ограничен.
Обратите внимание, что к утверждениям о таких вещах часто следует
относиться скептически. Бремя демонстрации того, что ручное управление
ключами уместно, ложится на сторонников — и это довольно высокий барьер.
Системам, использующим ручное управление ключами, необходимы положения
для смены ключей. Должен (MUST) существовать некоторый способ указать,
какой ключ используется, чтобы избежать проблем при переходе. В проектах
следует (SHOULD) набросать правдоподобные механизмы для развёртывания
новых ключей и замены старых, которые могли быть скомпрометированы.
При хорошем исполнении такие механизмы впоследствии могут быть
использованы схемой управления ключами, добавляемой как дополнение.
Неясность относительно сторон, участвующих в аутентификации, не
является веской причиной избегать управления ключами. Напротив, она
обычно указывает на более глубокую проблему с базовой моделью
безопасности.
2.3. Размер ключа и случайные значения
Руководство по размеру криптографического ключа для открытых ключей,
используемых для обмена симметричными ключами, можно найти в BCP 86
[OH].
Когда используется ручное управление ключами, долгосрочные совместно
используемые секретные значения следует (SHOULD) иметь длину не менее
128 бит.
Руководство по генерации случайных чисел можно найти в BCP 106 [ESC].
Bellovin & Housley Лучшая современная практика [Страница 4]
RFC 4107 Руководство по управлению криптографическими ключами Июнь 2005
Когда используется ручное управление ключами, долгосрочные совместно
используемые секреты должны (MUST) быть непредсказуемыми «случайными»
значениями, обеспечивая, что ожидаемая вероятность нахождения значения
противником после перебора половины пространства поиска ключа будет не
более 50%.
3. Соображения безопасности
Этот документ содержит руководство для рабочих групп и разработчиков
протоколов. Безопасность Интернета повышается при использовании
автоматизированного управления ключами.
Включение автоматизированного управления ключами не означает, что
интерфейс для ручного управления ключами запрещён. Фактически ручное
управление ключами очень полезно для отладки. Поэтому реализации
следует предоставлять интерфейс ручного управления ключами для таких
целей, даже если он не определён протоколом.
4. Ссылки
Этот раздел содержит нормативные и информационные ссылки.
4.1. Нормативные ссылки
[B] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[ESC] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
[OH] Orman, H. and P. Hoffman, "Determining Strengths For Public
Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766,
April 2004
4.2. Информационные ссылки
[AN] M. Abadi and R. Needham, "Prudent Engineering Practice for
Cryptographic Protocols", Proc. IEEE Computer Society
Symposium on Research in Security and Privacy, May 1994.
[DA] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[DS] D. Denning and G. Sacco. "Timestamps in key distributed
protocols", Communication of the ACM, 24(8):533--535, 1981.
[HC] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
Bellovin & Housley Лучшая современная практика [Страница 5]
RFC 4107 Руководство по управлению криптографическими ключами Июнь 2005
[L] G. Lowe. "An attack on the Needham-Schroeder public key
authentication protocol", Information Processing Letters,
56(3):131--136, November 1995.
[NIST] National Institute of Standards and Technology.
"Recommendation for Block Cipher Modes of Operation -- Methods
and Techniques," NIST Special Publication SP 800-38A, December
2001.
[NS] R. Needham and M. Schroeder. "Using encryption for
authentication in large networks of computers", Communications
of the ACM, 21(12), December 1978.
[TK] Thayer, R. and K. Kaukonen. "A Stream Cipher Encryption
Algorithm", Work in Progress.
[WHF] Whiting, D., Housley, R., and N. Ferguson , "Counter with
CBC-MAC (CCM)", RFC 3610, September 2003.
Адреса авторов
Steven M. Bellovin
Department of Computer Science
Columbia University
1214 Amsterdam Avenue, M.C. 0401
New York, NY 10027-7003
Phone: +1 212-939-7149
EMail: bellovin@acm.org
Russell Housley
Vigil Security, LLC
918 Spring Knoll Drive
Herndon, VA 20170
Phone: +1 703-435-1775
EMail: housley@vigilsec.com
Bellovin & Housley Лучшая современная практика [Страница 6]
RFC 4107 Руководство по управлению криптографическими ключами Июнь 2005
Полное заявление об авторских правах
Copyright (C) The Internet Society (2005).
Этот документ подпадает под действие прав, лицензий и ограничений,
содержащихся в BCP 78, и, за исключением установленного в нём, авторы
сохраняют все свои права.
Этот документ и содержащаяся в нём информация предоставляются по
принципу «КАК ЕСТЬ», И УЧАСТНИК, ОРГАНИЗАЦИЯ, КОТОРУЮ ОН/ОНА
ПРЕДСТАВЛЯЕТ ИЛИ КОТОРОЙ СПОНСИРУЕТСЯ (ЕСЛИ ТАКОВАЯ ИМЕЕТСЯ), INTERNET
SOCIETY И INTERNET ENGINEERING TASK FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ЯВНО
ВЫРАЖЕННЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ ГАРАНТИЙ, ВКЛЮЧАЯ, ПОМИМО ПРОЧЕГО,
ЛЮБУЮ ГАРАНТИЮ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ СОДЕРЖАЩЕЙСЯ ЗДЕСЬ ИНФОРМАЦИИ
НЕ НАРУШИТ КАКИХ-ЛИБО ПРАВ, ЛИБО ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ
ТОВАРНОЙ ПРИГОДНОСТИ ИЛИ ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЁННОЙ ЦЕЛИ.
Интеллектуальная собственность
IETF не занимает позиции относительно действительности или объёма
каких-либо прав интеллектуальной собственности или иных прав, которые
могут заявляться как относящиеся к реализации или использованию
технологии, описанной в этом документе, либо относительно того, может
ли быть доступна какая-либо лицензия на основании таких прав; также
она не заявляет, что предпринимала какие-либо независимые усилия по
выявлению любых таких прав. Информацию о процедурах, касающихся прав в
документах RFC, можно найти в BCP 78 и BCP 79.
Копии раскрытий IPR, сделанных Секретариату IETF, и любых заверений о лицензиях, которые будут предоставлены, либо результат попытки получить общую лицензию или разрешение на использование таких прав собственности разработчиками или пользователями данной спецификации можно получить в онлайновом репозитории IPR IETF по адресу
http://www.ietf.org/ipr.
IETF приглашает любую заинтересованную сторону довести до сведения IETF любые авторские права, патенты или заявки на патенты либо иные права собственности, которые могут распространяться на технологию, которая может потребоваться для реализации данного стандарта. Просьба направлять эту информацию в IETF по адресу ietf-
ipr@ietf.org.
Благодарность
Финансирование функции RFC Editor в настоящее время предоставляется
Internet Society.
Bellovin & Housley Лучшая современная практика [Страница 7]
Network Working Group S. Bellovin
Request for Comments: 4107 Columbia University
BCP: 107 R. Housley
Category: Best Current Practice Vigil Security
June 2005
Guidelines for Cryptographic Key Management
Status of This Memo
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The question often arises of whether a given security system requires
some form of automated key management, or whether manual keying is
sufficient. This memo provides guidelines for making such decisions.
When symmetric cryptographic mechanisms are used in a protocol, the
presumption is that automated key management is generally but not
always needed. If manual keying is proposed, the burden of proving
that automated key management is not required falls to the proposer.
1. Introduction
The question often arises of whether or not a given security system
requires some form of automated key management, or whether manual
keying is sufficient.
There is not one answer to that question; circumstances differ. In
general, automated key management SHOULD be used. Occasionally,
relying on manual key management is reasonable; we propose some
guidelines for making that judgment.
On the other hand, relying on manual key management has significant
disadvantages, and we outline the security concerns that justify the
preference for automated key management. However, there are
situations in which manual key management is acceptable.
Bellovin & Housley Best Current Practice [Page 1]
RFC 4107 Guidelines for Cryptographic Key Management June 2005
1.1. Terminology
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in RFC 2119 [B].
2. Guidelines
These guidelines are for use by IETF working groups and protocol
authors who are determining whether to mandate automated key
management and whether manual key management is acceptable. Informed
judgment is needed.
The term "key management" refers to the establishment of
cryptographic keying material for use with a cryptographic algorithm
to provide protocol security services, especially integrity,
authentication, and confidentiality. Automated key management
derives one or more short-term session keys. The key derivation
function may make use of long-term keys to incorporate authentication
into the process. The manner 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 public key, and others)
is beyond the scope of this document. However, it is part of the
overall key management solution. Manual key management is used to
distribute such values. Manual key management can also be used to
distribute long-term session keys.
Automated key management and manual key management provide very
different features. In particular, the protocol associated with an
automated key management technique will confirm the liveness of the
peer, protect against replay, authenticate the source of 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 generated. Further, an automated key management protocol can
improve interoperability by including negotiation mechanisms for
cryptographic algorithms. These valuable features are impossible or
extremely cumbersome to accomplish with manual key management.
For some symmetric cryptographic algorithms, implementations must
prevent overuse of a given key. An implementation of such algorithms
can make use of automated key management when the usage limits are
nearly exhausted, in order to establish replacement keys before the
limits are reached, thereby maintaining secure communications.
Examples of automated key management systems include IPsec IKE and
Kerberos. S/MIME and TLS also include automated key management
functions.
Bellovin & Housley Best Current Practice [Page 2]
RFC 4107 Guidelines for Cryptographic Key Management June 2005
Key management schemes should not be designed by amateurs; it is
almost certainly inappropriate for working groups to design their
own. To put it in concrete terms, the very first key management
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
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
these flaws were obvious once described -- yet no one spotted them
earlier. Note that the original protocol (translated to employ
certificates, which had not been invented at that time) was only
three messages.
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]
in half that space. Note that this TLS estimate includes other
functionality as well.
A session key is used to protect a payload. The nature of the
payload depends on the layer where the symmetric cryptography is
applied.
In general, automated key management SHOULD be used to establish
session keys. Strong justification is needed in the security
considerations section of a proposal that makes use of manual key
management.
2.1. Automated Key Management
Automated key management MUST be used if any of these conditions
hold:
A party will have to manage n^2 static keys, where n may become
large.
Any stream cipher (such as RC4 [TK], AES-CTR [NIST], or AES-CCM
[WHF]) is used.
An initialization vector (IV) might be reused, especially an
implicit IV. Note that random or pseudo-random explicit IVs are
not a problem unless the probability of repetition is high.
Large amounts of data might need to be encrypted in a short time,
causing frequent change of the short-term session key.
Long-term session keys are used by more than two parties.
Multicast is a necessary exception, but multicast key management
standards are emerging in order to avoid this in the future.
Sharing long-term session keys should generally be discouraged.
Bellovin & Housley Best Current Practice [Page 3]
RFC 4107 Guidelines for Cryptographic Key Management June 2005
The likely operational environment is one where personnel (or
device) turnover is frequent, causing frequent change of the
short-term session key.
2.2. Manual Key Management
Manual key management may be a reasonable approach in any of these
situations:
The environment has very limited available bandwidth or very high
round-trip times. 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.
The information being protected has low value.
The total volume of traffic over the entire lifetime of the long-
term session key will be very low.
The scale of each deployment is very limited.
Note that assertions about such things should often be viewed with
skepticism. The burden of demonstrating that manual key management
is appropriate falls to the proponents -- and it is a fairly high
hurdle.
Systems that employ manual key management need provisions 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 replacing old ones that might
have been compromised. If done well, such mechanisms can later be
used by an add-on key management scheme.
Lack of clarity about the parties involved in authentication is not a
valid reason for avoiding key management. Rather, it tends to
indicate a deeper problem with the underlying security model.
2.3. Key Size and Random Values
Guidance on cryptographic key size for public keys that are used for
exchanging symmetric keys can be found in BCP 86 [OH].
When manual key management is used, long-term shared secret values
SHOULD be at least 128 bits.
Guidance on random number generation can be found in BCP 106 [ESC].
Bellovin & Housley Best Current Practice [Page 4]
RFC 4107 Guidelines for Cryptographic Key Management June 2005
When manual key management is used, long-term shared secrets MUST be
unpredictable "random" values, ensuring that an adversary will have
no greater expectation than 50% of finding the value after searching
half the key search space.
3. Security Considerations
This document provides guidance to working groups and protocol
designers. The security of the Internet is improved when automated
key management is employed.
The inclusion of automated key management does not mean that an
interface for manual key management is prohibited. In fact, manual
key management is very helpful for debugging. Therefore,
implementations ought to provide a manual key management interface
for such purposes, even if it is not specified by the protocol.
4. References
This section contains normative and informative references.
4.1. Normative References
[B] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[ESC] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
[OH] Orman, H. and P. Hoffman, "Determining Strengths For Public
Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766,
April 2004
4.2. Informative References
[AN] M. Abadi and R. Needham, "Prudent Engineering Practice for
Cryptographic Protocols", Proc. IEEE Computer Society
Symposium on Research in Security and Privacy, May 1994.
[DA] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[DS] D. Denning and G. Sacco. "Timestamps in key distributed
protocols", Communication of the ACM, 24(8):533--535, 1981.
[HC] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
Bellovin & Housley Best Current Practice [Page 5]
RFC 4107 Guidelines for Cryptographic Key Management June 2005
[L] G. Lowe. "An attack on the Needham-Schroeder public key
authentication protocol", Information Processing Letters,
56(3):131--136, November 1995.
[NIST] National Institute of Standards and Technology.
"Recommendation for Block Cipher Modes of Operation -- Methods
and Techniques," NIST Special Publication SP 800-38A, December
2001.
[NS] R. Needham and M. Schroeder. "Using encryption for
authentication in large networks of computers", Communications
of the ACM, 21(12), December 1978.
[TK] Thayer, R. and K. Kaukonen. "A Stream Cipher Encryption
Algorithm", Work in Progress.
[WHF] Whiting, D., Housley, R., and N. Ferguson , "Counter with
CBC-MAC (CCM)", RFC 3610, September 2003.
Authors' Addresses
Steven M. Bellovin
Department of Computer Science
Columbia University
1214 Amsterdam Avenue, M.C. 0401
New York, NY 10027-7003
Phone: +1 212-939-7149
EMail: bellovin@acm.org
Russell Housley
Vigil Security, LLC
918 Spring Knoll Drive
Herndon, VA 20170
Phone: +1 703-435-1775
EMail: housley@vigilsec.com
Bellovin & Housley Best Current Practice [Page 6]
RFC 4107 Guidelines for Cryptographic Key Management June 2005
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Bellovin & Housley Best Current Practice [Page 7]