summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2411.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2411.txt')
-rw-r--r--doc/rfc/rfc2411.txt619
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc2411.txt b/doc/rfc/rfc2411.txt
new file mode 100644
index 0000000..cc0cf54
--- /dev/null
+++ b/doc/rfc/rfc2411.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group R. Thayer
+Request for Comments: 2411 Sable Technology Corporation
+Category: Informational N. Doraswamy
+ Bay Networks
+ R. Glenn
+ NIST
+ November 1998
+
+
+ IP Security
+ Document Roadmap
+
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1998). All Rights Reserved.
+
+
+Abstract
+
+ The IPsec protocol suite is used to provide privacy and
+ authentication services at the IP layer. Several documents are used
+ to describe this protocol suite. The interrelationship and
+ organization of the various documents covering the IPsec protocol are
+ discussed here. An explanation of what to find in which document,
+ and what to include in new Encryption Algorithm and Authentication
+ Algorithm documents are described.
+
+Table of Contents
+
+ 1. Introduction ................................................2
+ 2. Interrelationship of IPsec Documents ........................2
+ 3. Keying Material .............................................4
+ 4. Recommended Content of Algorithm Documents ..................5
+ 4.1 Encryption and Authentication Algorithms ...................5
+ 4.2 Encryption Algorithms ......................................6
+ 4.3 Authentication Algorithms ..................................7
+ 5. Security Considerations .....................................8
+ 6. Acknowledgments .............................................8
+ 7. References ..................................................9
+ 8. Authors' Addresses .........................................10
+ 9. Full Copyright Statement ...................................11
+
+
+
+Thayer, et. al. Informational [Page 1]
+
+RFC 2411 IP Security Document Roadmap November 1998
+
+
+1. Introduction
+
+ This document is intended to provide guidelines for the development
+ of collateral specifications describing the use of new encryption and
+ authentication algorithms with the ESP protocol, described in [ESP]
+ and new authentication algorithms used with the AH protocol,
+ described in [AH]. ESP and AH are part of the IP Security
+ architecture described in [Arch]. There is a requirement for a
+ well-known procedure that can be used to add new encryption
+ algorithms or authentication algorithms to ESP and AH, not only while
+ the initial document set is undergoing development but after the base
+ documents have achieved RFC status. Following the guidelines
+ discussed below simplifies adding new algorithms and reduces that
+ amount of redundant documentation.
+
+ The goal in writing a new Encryption Algorithm or Authentication
+ Algorithm document is to concentrate on the application of the
+ specific algorithm within ESP and AH. General ESP and AH concepts,
+ definitions, and issues are covered in the ESP and AH documents. The
+ algorithms themselves are not described in these documents. This
+ gives us the capability to add new algorithms and also specify how
+ any given algorithm might interact with other algorithms. The intent
+ is to achieve the goal of avoiding duplication of information and
+ excessive numbers of documents, the so-called "draft explosion"
+ effect.
+
+2. Interrelationship of IPsec Documents
+
+ The documents describing the set of IPsec protocols are divided into
+ seven groups. This is illustrated in Figure 1. There is a main
+ Architecture document which broadly covers the general concepts,
+ security requirements, definitions, and mechanisms defining IPsec
+ technology.
+
+ There is an ESP Protocol document and an AH Protocol document which
+ covers the packet format and general issues regarding the respective
+ protocols. These protocol documents also contain default values if
+ appropriate, such as the default padding contents, and mandatory to
+ implement algorithms. These documents dictate some of the values in
+ the Domain Of Interpretation document [DOI]. Note the DOI document
+ is itself part of the IANA Assigned Numbers mechanism and so the
+ values described in the DOI are well-known. See [DOI] for more
+ information on the mechanism.
+
+ The "Encryption Algorithm" document set, shown on the left, is the
+ set of documents describing how various encryption algorithms are
+ used for ESP. These documents are intended to fit in this roadmap,
+ and should avoid overlap with the ESP protocol document and with the
+
+
+
+Thayer, et. al. Informational [Page 2]
+
+RFC 2411 IP Security Document Roadmap November 1998
+
+
+ Authentication Algorithm documents. Examples of this document are
+ the [DES-Detroit] and [CBC] documents. When these or other
+ encryption algorithms are used for ESP, the DOI document has to
+ indicate certain values, such as an encryption algorithm identifier,
+ so these documents provide input to the DOI.
+
+ The "Authentication Algorithm" document set, shown on the right, is
+ the set of documents describing how various authentication algorithms
+ are used for both ESP and AH. These documents are intended to fit in
+ this roadmap, and should avoid overlap with the AH protocol document
+ and with the Encryption Algorithm documents. Examples of this
+ document are the [HMAC-MD5], and [HMAC-SHA-1] documents. When these
+ or other algorithms are used for either ESP or AH, the DOI document
+ has to indicate certain values, such as algorithm type, so these
+ documents provide input to the DOI.
+
+ The "Key Management Documents", shown at the bottom, are the
+ documents describing the IETF standards-track key management schemes.
+ These documents provide certain values for the DOI also. Note that
+ issues of key management should be indicated here and not in, for
+ example, the ESP and AH protocol documents. Currently this box
+ represents [ISAKMP], [Oakley], and [Resolution].
+
+ The DOI document, shown in the middle, contains values needed for the
+ other documents to relate to each other. This includes for example
+ encryption algorithms, authentication algorithms, and operational
+ parameters such as key lifetimes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thayer, et. al. Informational [Page 3]
+
+RFC 2411 IP Security Document Roadmap November 1998
+
+
+ +--------------+
+ | Architecture |
+ +--------------+
+ v v
+ +<-<-<-<-+ +->->->->+
+ v v
+ +----------+ +----------+
+ | ESP | | AH |
+ | Protocol | | Protocol |
+ +----------+ +----------+
+ v v v v
+ v +->->->->->->->->+ v v
+ v v v v v
+ v v v v v
+ v +------------+ +----------------+ v
+ v | +------------+ | +----------------+ v
+ v | | Encryption | | | Authentication | v
+ v +-| Algorithm | +-| Algorithm | v
+ v +------------+ +----------------+ v
+ v v v v
+ v v +-----+ v v
+ +>->->->-+->->->->| DOI |<-<-<-<-+-<-<-<-<-+
+ +-----+
+ ^
+ ^
+ +------------+
+ | KEY |
+ | MANAGEMENT |
+ +------------+
+
+
+ Figure 1. IPsec Document Roadmap.
+
+3. Keying Material
+
+ Describing the encryption and authentication algorithms in different
+ documents raises the issue of how the key management protocols knows
+ the required keying material length for the desired algorithms when
+ used together with ESP. It also raises the issue of how to divide
+ the keying material. This is known as the "slicing and dicing"
+ information.
+
+ Each Encryption Algorithm and Authentication Algorithm document
+ should specify their respective key attributes (e.g. how to pad,
+ location of parity bits, key order for multi-keyed algorithms, and
+ length). The key management protocols should use the length of the
+ keys specified in the respective Algorithm documents to generate the
+ keying material of required length.
+
+
+
+Thayer, et. al. Informational [Page 4]
+
+RFC 2411 IP Security Document Roadmap November 1998
+
+
+ The key management protocol generates keying material with enough
+ strength and size to generate keys for individual algorithms. The
+ IPsec Architecture document specifies how keys are extracted from a
+ single block of keying material when multiple keys are required (e.g.
+ ESP with authentication). The Encryption Algorithm and
+
+ Authentication Algorithm documents are responsible for specifying the
+ key sizes and strengths for each algorithm. However, whether the
+ entire keying material is passed down to the kernel to perform
+ slicing and dicing or if the keys are sliced and diced by key
+ management protocol is an implementation issue. The AH protocol
+ document has no such requirement.
+
+4. Recommended Content of Algorithm Documents
+
+ The document describing how a specific encryption or authentication
+ algorithm is used should contain information appropriate to that
+ encryption or authentication algorithm. This section enumerates what
+ information should be provided. It is the intention of the document
+ roadmap that:
+
+ . General protocol information goes in the respective ESP or AH
+ protocol documents.
+ . Key management information goes in the key management documents.
+ . Assigned values and constants of negotiable items go in the DOI
+ document.
+
+ Encryption and authentication algorithms require some set of optional
+ parameters or have optional modes of operation (e.g. IVs,
+ authentication data lengths, and key lengths). To help eliminate
+ some complexity involved with key management having to negotiate
+ large numbers of algorithm-specific parameters, encryption and
+ authentication algorithm documents will select fixed values for these
+ parameters when it is deemed technically reasonable and feasible.
+
+ Note, the following information is intended as a general guideline
+ only.
+
+4.1 Encryption and Authentication Algorithms
+
+ This section describes the information that should be included in
+ both Encryption Algorithm and Authentication Algorithm documents.
+
+ Keying Material
+
+ . Size of keys, including minimum, maximum, recommended and/or
+ required sizes. Note: the security considerations section should
+ address any weakness in specific sizes.
+
+
+
+Thayer, et. al. Informational [Page 5]
+
+RFC 2411 IP Security Document Roadmap November 1998
+
+
+ . Recommended or required pseudo-random number generator techniques
+ and attributes to provide sufficiently strong keys. [RANDOM]
+ provides recommendations on generating strong randomness for use
+ with security.
+ . Format of keying material.
+ . Known weak keys or references to documentation on known weak keys.
+ . Recommended or required processing of input keying material such
+ as parity generation or checking.
+ . Requirements and/or recommendations on how often the keying
+ material should be refreshed.
+
+ Performance Considerations
+ . Any available estimates on performance of this algorithm.
+ . Any available comparison data (e.g., compared against DES or
+ MD5).
+ . Input size or other considerations that could improve or degrade
+ performance.
+
+ ESP Environmental Considerations
+ . Any known issues regarding interactions between this algorithm and
+ other aspects of ESP, such as use of certain authentication
+ schemes. Note: As new encryption and authentication algorithms
+ are applied to ESP, the later documents will be required to
+ address interactions with previously specified algorithms.
+
+ Payload Content and Format Description
+ . Specification of size, placement, and content of algorithm-
+ specific fields not defined in the ESP or AH protocol documents
+ (e.g., IV).
+
+ Security Considerations
+ . Discuss any known attacks.
+ . Discuss any known common implementation pitfalls, such as use of
+ weak random number generators.
+ . Discuss any relevant validation procedures, such as test vectors.
+ [RFC-2202] is an example document containing test vectors for
+ a set of authentication algorithms.
+
+4.2 Encryption Algorithms
+
+ This section describes the information that should be included in the
+ Encryption Algorithm documents.
+
+ Encryption Algorithm Description
+ . General information how this encryption algorithm is to be used in
+ ESP.
+ . Description of background material and formal algorithm
+ description.
+
+
+
+Thayer, et. al. Informational [Page 6]
+
+RFC 2411 IP Security Document Roadmap November 1998
+
+
+ . Features of this encryption algorithm to be used by ESP, including
+ encryption and/or authentication.
+ . Mention of any availability issues such as Intellectual Property
+ considerations.
+ . References, in IETF style, to background material such as FIPS
+ documents.
+
+ Algorithm Modes of Operation
+ . Description of how the algorithm is operated, whether it is block
+ mode or streaming mode or other.
+ . Requirements for input or output block format.
+ . Padding requirements of this algorithm. Note: there is a default
+ for padding, specified in the base ESP document, so this is only
+ needed if the default cannot be used.
+ . Any algorithm-specific operating parameters, such as number of
+ rounds.
+ . Identify optional parameters and optional methods of operation and
+ pick reasonable fixed values and methods with explicit technical
+ explanations.
+ . Identify those optional parameters in which values and methods
+ should remain optional with explicit technical explanations on why
+ fixed values and methods should not be used.
+ . Defaults and mandatory ranges on algorithm-specific optional
+ parameters that could not be fixed.
+
+4.3 Authentication Algorithms
+
+ This section describes the information that should be included in the
+ Authentication Algorithm documents. In most cases, an authentication
+ algorithm will operate the same whether it is used for ESP or AH.
+ This should be represented in a single Authentication Algorithm
+ document.
+
+ Authentication Algorithm Description
+ . General information on how this authentication algorithm is to be
+ used with ESP and AH.
+ . Description of background material and formal algorithm
+ description.
+ . Features of this authentication algorithm.
+ . Mention of any availability issues such as Intellectual Property
+ considerations.
+ . References, in IETF style, to background material such as
+ FIPS documents and definitive descriptions of underlying
+ algorithms.
+
+ Algorithm Modes of Operation
+ . Description of how the algorithm is operated.
+
+
+
+
+Thayer, et. al. Informational [Page 7]
+
+RFC 2411 IP Security Document Roadmap November 1998
+
+
+ . Algorithm-specific operating parameters, such as number of
+ rounds, and input or output block format.
+ . Implicit and explicit padding requirements of this algorithm.
+ Note: There is a default method for padding of the
+ authentication data field specified in the AH protocol document.
+ This is only needed if the default cannot be used.
+ . Identify optional parameters and optional methods of operation and
+ pick reasonable fixed values and methods with explicit technical
+ explanations.
+ . Identify those optional parameters in which values and methods
+ should remain optional with explicit technical explanations on why
+ fixed values and methods should not be used.
+ . Defaults and mandatory ranges on algorithm-specific optional
+ parameters that could not be fixed.
+ . Authentication data comparison criteria for this algorithm. Note:
+ There is a default method for verifying the authentication data
+ specified in the AH protocol document. This is only needed if the
+ default cannot be used (e.g. when using a signed hash).
+
+5. Security Considerations
+
+ This document provides a roadmap and guidelines for writing
+ Encryption and Authentication Algorithm documents. The reader should
+ follow all the security procedures and guidelines described in the
+ IPsec Architecture, ESP Protocol, AH Protocol, Encryption Algorithm,
+ and Authentication Algorithm documents. Note that many encryption
+ algorithms are not considered secure if they are not used with some
+ sort of authentication mechanism.
+
+6. Acknowledgments
+
+ Several Internet drafts were referenced in writing this document.
+ Depending on where the documents are on (or off) the IETF standards
+ track these may not be available through the IETF RFC repositories.
+ In certain cases the reader may want to know what version of these
+ documents were referenced. These documents are:
+
+ . DES-Detroit: this is the ANX Workshop style of ESP, based on the
+ Hughes draft as modified by Cheryl Madson and published on the ANX
+ mailing list.
+ . DOI: draft-ietf-ipsec-ipsec-doi-02.txt.
+ . 3DES: this is <the Triple-DES shim document>.
+ . CAST: this is draft-ietf-ipsec-esp-cast-128-cbc-00.txt, as revised
+ to relate to this document.
+ . ESP: draft-ietf-ipsec-esp-04.txt, mailed to the IETF mailing list
+ in May/June 1997.
+ . AH: draft-ietf-ipsec-auth-05.txt, mailed to the IETF mailing list
+ in May/June 1997.
+
+
+
+Thayer, et. al. Informational [Page 8]
+
+RFC 2411 IP Security Document Roadmap November 1998
+
+
+ . HUGHES: this is draft-ietf-ipsec-esp-des-md5-03.txt
+ . ISAKMP: There are three documents describing ISAKMP. These are
+ draft-ietf-ipsec-isakmp-07.txt, draft-ietf-ipsec-isakmp-oakley-
+ 03.txt, and draft-ietf-ipsec-ipsec-doi-02.txt.
+
+7. References
+
+ [CBC] Periera, R., and R. Adams, "The ESP CBC-Mode Cipher
+ Algorithms", RFC 2451, November 1998.
+
+ [Arch] Kent, S., and R. Atkinson, "Security Architecture for
+ the Internet Protocol", RFC 2401, November 1998.
+
+ [DES-Detroit] Madson, C., and N. Doraswamy, "The ESP DES-CBC Cipher
+ Algorithm With Explicit IV", RFC 2405, November 1998.
+
+ [DOI] Piper, D., "The Internet IP Security Domain of
+ Interpretation for ISAKMP", RFC 2407, November 1998.
+
+ [AH] Kent, S., and R. Atkinson, "IP Authentication Header",
+ RFC 2402, November 1998.
+
+ [ESP] Kent, S., and R. Atkinson, "IP Encapsulating Security
+ Payload (ESP)", RFC 2406, November 1998.
+
+ [HMAC] Krawczyk, K., Bellare, M., and R. Canetti, "HMAC:
+ Keyed-Hashing for Message Authentication", RFC 2104,
+ February 1997.
+
+ [HMAC-MD5] Madson, C., and R. Glenn, "The Use of HMAC-MD5 within
+ ESP and AH", RFC 2403, November 1998.
+
+ [HMAC-SHA-1] Madson, C., and R. Glenn, "The Use of HMAC-SHA-1 within
+ ESP and AH", RFC 2404, November 1998.
+
+ [RANDOM] Eastlake, D., Crocker, S., and J. Schiller, "Randomness
+ Recommendations for Security", RFC 1750, December 1994.
+
+ [RFC-2202] Cheng, P., and R. Glenn, "Test Cases for HMAC-MD5 and
+ HMAC-SHA-1", RFC 2202, March 1997.
+
+
+
+
+
+
+
+
+
+
+
+Thayer, et. al. Informational [Page 9]
+
+RFC 2411 IP Security Document Roadmap November 1998
+
+
+8. Authors' Addresses
+
+ Rodney Thayer
+ Sable Technology Corporation
+ 246 Walnut Street
+ Newton, Massachusetts 02160
+
+ EMail: mailto:rodney@sabletech.com
+
+
+ Naganand Doraswamy
+ Bay Networks
+
+ EMail: naganand@baynetworks.com
+
+
+ Rob Glenn
+ NIST
+
+ EMail: rob.glenn@nist.gov
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thayer, et. al. Informational [Page 10]
+
+RFC 2411 IP Security Document Roadmap November 1998
+
+
+9. Full Copyright Statement
+
+ Copyright (C) The Internet Society (1998). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thayer, et. al. Informational [Page 11]
+