rfc2411.txt

RFC 的详细文档！

   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:[e-mail]


   Naganand Doraswamy
   Bay Networks

   EMail: [e-mail]


   Rob Glenn
   NIST

   EMail: [e-mail]































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]