rfc1827.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.


RFC 1827             Encapsulating Security Payload          August 1995


   receiving process and the security level associated with this
   Security Association.  If those mandatory access controls fail, then
   the packet SHOULD be discarded and the failure SHOULD be logged using
   implementation-specific procedures.

4.2 ESP in Transport-mode

   In Transport-mode ESP, the ESP header follows the end-to-end headers
   (e.g., Authentication Header) and immediately precedes a transport-
   layer (e.g., UDP, TCP, ICMP) header.

   The sender takes the original transport-layer (e.g., UDP, TCP, ICMP)
   frame, encapsulates it into the ESP, uses at least the sending userid
   and Destination Address to locate the appropriate Security
   Association, and then applies the appropriate encryption transform.
   If host-oriented keying is in use, then all sending userids on a
   given system will have the same Security Association for a given
   Destination Address. If no key has been established, then the key
   management mechanism is used to establish a encryption key for this
   communications session prior to the encryption.  The (now encrypted)
   ESP is then encapsulated as the last payload of a cleartext IP
   datagram.

   The receiver processes the cleartext IP header and cleartext optional
   IP headers (if any) and temporarily stores pertinent information
   (e.g., source and destination addresses, Flow ID, Routing Header).
   It then decrypts the ESP using the session key that has been
   established for this traffic, using the combination of the
   destination address and the packet's Security Association Identifier
   (SPI) to locate the correct key.

   If no key exists for this session or the attempt to decrypt fails,
   the encrypted ESP MUST be discarded and the failure MUST be recorded
   in the system log or audit log.  If such a failure occurs, the
   recorded log data SHOULD include the SPI value, date/time received,
   clear-text Sending Address, clear-text Destination Address, and the
   Flow ID.  The log data MAY also include other information about the
   failed packet.  If decryption does not work properly for some reason,
   then the resulting data will not be parsable by the implementation's
   protocol engine.  Hence, failed decryption is generally detectable.

   If decryption succeeds, the original transport-layer (e.g., UDP, TCP,
   ICMP) frame is removed from the (now decrypted) ESP.  The information
   from the cleartext IP header and the now decrypted transport-layer
   header is jointly used to determine which application the data should
   be sent to.  The data is then sent along to the appropriate
   application as normally per IP protocol specification.  In the case
   of a system claiming to provide multilevel security (for example, a



Atkinson                    Standards Track                     [Page 7]

RFC 1827             Encapsulating Security Payload          August 1995


   B1 or Compartmented Mode Workstation), additional Mandatory Access
   Controls MUST be applied based on the security level of the receiving
   process and the security level of the received packet's Security
   Association.

4.3. Authentication

   Some transforms provide authentication as well as confidentiality and
   integrity.  When such a transform is not used, then the
   Authentication Header might be used in conjunction with the
   Encapsulating Security Payload.  There are two different approaches
   to using the Authentication Header with ESP, depending on which data
   is to be authenticated.  The location of the Authentication Header
   makes it clear which set of data is being authenticated.

   In the first usage, the entire received datagram is authenticated,
   including both the encrypted and unencrypted portions, while only the
   data sent after the ESP Header is confidential.  In this usage, the
   sender first applies ESP to the data being protected.  Then the other
   plaintext IP headers are prepended to the ESP header and its now
   encrypted data. Finally, the IP Authentication Header is calculated
   over the resulting datagram according to the normal method.  Upon
   receipt, the receiver first verifies the authenticity of the entire
   datagram using the normal IP Authentication Header process.  Then if
   authentication succeeds, decryption using the normal IP ESP process
   occurs.  If decryption is successful, then the resulting data is
   passed up to the upper layer.

   If the authentication process were to be applied only to the data
   protected by Tunnel-mode ESP, then the IP Authentication Header would
   be placed normally within that protected datagram.  However, if one
   were using Transport-mode ESP, then the IP Authentication Header
   would be placed before the ESP header and would be calculated across
   the entire IP datagram.

   If the Authentication Header is encapsulated within a Tunnel-mode ESP
   header, and both headers have specific security classification levels
   associated with them, and the two security classification levels are
   not identical, then an error has occurred.  That error SHOULD be
   recorded in the system log or audit log using the procedures
   described previously.  It is not necessarily an error for an
   Authentication Header located outside of the ESP header to have a
   different security classification level than the ESP header's
   classification level.  This might be valid because the cleartext IP
   headers might have a different classification level after the data
   has been encrypted using ESP.





Atkinson                    Standards Track                     [Page 8]

RFC 1827             Encapsulating Security Payload          August 1995


5. CONFORMANCE REQUIREMENTS

   Implementations that claim conformance or compliance with this
   specification MUST fully implement the header described here, MUST
   support manual key distribution with this header, MUST comply with
   all requirements of the "Security Architecture for the Internet
   Protocol" [Atk95a], and MUST support the use of DES CBC as specified
   in the companion document entitled "The ESP DES-CBC Transform"
   [KMS95].  Implementors MAY also implement other ESP transforms.
   Implementers should consult the most recent version of the "IAB
   Official Standards" RFC for further guidance on the status of this
   document.

6. SECURITY CONSIDERATIONS

   This entire document discusses a security mechanism for use with IP.
   This mechanism is not a panacea, but it does provide an important
   component useful in creating a secure internetwork.

   Cryptographic transforms for ESP which use a block-chaining algorithm
   and lack a strong integrity mechanism are vulnerable to a cut-and-
   paste attack described by Bellovin and should not be used unless the
   Authentication Header is always present with packets using that ESP
   transform [Bel95].

   Users need to understand that the quality of the security provided by
   this specification depends completely on the strength of whichever
   encryption algorithm has been implemented, the correctness of that
   algorithm's implementation, upon the security of the key management
   mechanism and its implementation, the strength of the key [CN94]
   [Sch94, p233] and upon the correctness of the ESP and IP
   implementations in all of the participating systems.

   If any of these assumptions do not hold, then little or no real
   security will be provided to the user.  Use of high assurance
   development techniques is recommended for the IP Encapsulating
   Security Payload.

   Users seeking protection from traffic analysis might consider the use
   of appropriate link encryption.  Description and specification of
   link encryption is outside the scope of this note.

   If user-oriented keying is not in use, then the algorithm in use
   should not be an algorithm vulnerable to any kind of Chosen Plaintext
   attack.  Chosen Plaintext attacks on DES are described in [BS93] and
   [Mat94]. Use of user-oriented keying is recommended in order to
   preclude any sort of Chosen Plaintext attack and to generally make
   cryptanalysis more difficult.  Implementations SHOULD support user-



Atkinson                    Standards Track                     [Page 9]

RFC 1827             Encapsulating Security Payload          August 1995


   oriented keying as is described in the IP Security Architecture
   [Atk95a].

ACKNOWLEDGEMENTS

   This document benefited greatly from work done by Bill Simpson, Perry
   Metzger, and Phil Karn to make general the approach originally
   defined by the author for SIP, SIPP, and finally IPv6.

   Many of the concepts here are derived from or were influenced by the
   US Government's SP3 security protocol specification, the ISO/IEC's
   NLSP specification, or from the proposed swIPe security protocol
   [SDNS89, ISO92a, IB93, IBK93, ISO92b].  The use of DES for
   confidentiality is closely modeled on the work done for the SNMPv2
   [GM93].  Steve Bellovin, Steve Deering, Dave Mihelcic, and Hilarie
   Orman provided solid critiques of early versions of this memo.

REFERENCES

   [Atk95a] Atkinson, R., "Security Architecture for the Internet
            Protocol", RFC 1825, NRL, August 1995.

   [Atk95b] Atkinson, R., "IP Authentication Header", RFC 1826, NRL,
            August 1995.

   [Bel89]  Steven M. Bellovin, "Security Problems in the TCP/IP
            Protocol Suite", ACM Computer Communications Review, Vol. 19,
            No. 2, March 1989.

   [Bel95]  Steven M. Bellovin, Presentation at IP Security Working
            Group Meeting, Proceedings of the 32nd Internet Engineering
            Task Force, March 1995, Internet Engineering Task Force,
            Danvers, MA.

   [BS93]   Eli Biham and Adi Shamir, "Differential Cryptanalysis of the
            Data Encryption Standard", Springer-Verlag, New York, NY,
            1993.

   [CN94]   John M. Carroll & Sri Nudiati, "On Weak Keys and Weak Data:
            Foiling the Two Nemeses", Cryptologia, Vol. 18, No. 23,
            July 1994. pp. 253-280

   [CERT95] Computer Emergency Response Team (CERT), "IP Spoofing Attacks
            and Hijacked Terminal Connections", CA-95:01, January 1995.
            Available via anonymous ftp from info.cert.org.






Atkinson                    Standards Track                    [Page 10]

RFC 1827             Encapsulating Security Payload          August 1995


   [DIA]    US Defense Intelligence Agency (DIA), "Compartmented Mode
            Workstation Specification", Technical Report
            DDS-2600-6243-87.

   [GM93]   Galvin J., and K. McCloghrie, "Security Protocols for
            version 2 of the Simple Network Management Protocol
            (SNMPv2)", RFC 1446, Trusted Information Systems, Hughes LAN
            Systems, April 1993.

   [Hin94]  Bob Hinden (Editor), Internet Protocol version 6 (IPv6)
            Specification, Work in Progress, October 1994.

   [IB93]   John Ioannidis & Matt Blaze, "Architecture and Implementation
            of Network-layer Security Under Unix", Proceedings of the USENIX
            Security Symposium, Santa Clara, CA, October 1993.

   [IBK93]  John Ioannidis, Matt Blaze, & Phil Karn, "swIPe:
            Network-Layer Security for IP", presentation at the Spring
            1993 IETF Meeting, Columbus, Ohio.

   [ISO92a] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC
            DIS 11577, International Standards Organisation, Geneva,
            Switzerland, 29 November 1992.

   [ISO92b] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC
            DIS 11577, Section 13.4.1, page 33, International Standards
            Organisation, Geneva, Switzerland, 29 November 1992.

   [Ken91]  Kent, S., "US DoD Security Options for the Internet
            Protocol", RFC 1108, BBN Communications, November 1991.

   [KMS95]  Karn, P., Metzger, P., and W. Simpson, "The ESP DES-CBC
            Transform", RFC 1829, Qualcomm, Inc., Piermont, Daydreamer,
            August 1995.

   [Mat94]  Matsui, M., "Linear Cryptanalysis method for DES Cipher",
            Proceedings of Eurocrypt '93, Berlin, Springer-Verlag, 1994.

   [NIST77] US National Bureau of Standards, "Data Encryption Standard",
            Federal Information Processing Standard (FIPS) Publication
            46, January 1977.

   [NIST80] US National Bureau of Standards, "DES Modes of Operation"
            Federal Information Processing Standard (FIPS) Publication
            81, December 1980.






Atkinson                    Standards Track                    [Page 11]

RFC 1827             Encapsulating Security Payload          August 1995


   [NIST81] US National Bureau of Standards, "Guidelines for Implementing
            and Using the Data Encryption Standard", Federal Information
            Processing Standard (FIPS) Publication 74, April 1981.

   [NIST88] US National Bureau of Standards, "Data Encryption Standard",
            Federal Information Processing Standard (FIPS) Publication
            46-1, January 1988.

   [STD-2]  Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
            RFC 1700, USC/Information Sciences Institute, October 1994.

   [Sch94]  Bruce Schneier, Applied Cryptography, John Wiley & Sons,
            New York, NY, 1994.  ISBN 0-471-59756-2

   [SDNS89] SDNS Secure Data Network System, Security Protocol 3, SP3,
            Document SDN.301, Revision 1.5, 15 May 1989, as published
            in NIST Publication NIST-IR-90-4250, February 1990.

DISCLAIMER

   The views and specification here are those of the author and are not
   necessarily those of his employer.  The Naval Research Laboratory has
   not passed judgement on the merits, if any, of this work.  The author
   and his employer specifically disclaim responsibility for any
   problems arising from correct or incorrect implementation or use of
   this specification.

AUTHOR'S ADDRESS

   Randall Atkinson
   Information Technology Division
   Naval Research Laboratory
   Washington, DC 20375-5320
   USA

   Phone:  [phone]
   Fax:    [phone]
   EMail:  [e-mail]













Atkinson                    Standards Track                    [Page 12]