rfc1825.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,236 行 · 第 1/4 页

   The Encapsulating Security Payload can be combined with appropriate
   key policies to provide full multi-level secure networking.  In this
   case each key must be used only at a single sensitivity level and
   compartment.  For example, Key "A" might be used only for sensitive
   Unclassified packets, while Key "B" is used only for Secret/No-
   compartments traffic, and Key "C" is used only for Secret/No-Foreign
   traffic.  The sensitivity level of the protected traffic MUST NOT
   dominate the sensitivity level of the Security Association used with
   that traffic.  The sensitivity level of the Security Association MUST
   NOT dominate the sensitivity level of the key that belongs to that
   Security Association.  The sensitivity level of the key SHOULD be the
   same as the sensitivity level of the Security Association.  The
   Authentication Header can also have different keys for the same
   reasons, with the choice of key depending in part on the sensitivity
   level of the packet.

   Encryption is very useful and desirable even when all of the hosts
   are within a protected environment.  The Internet-standard encryption
   algorithm could be used, in conjunction with appropriate key
   management, to provide strong Discretionary Access Controls (DAC) in
   conjunction with either implicit sensitivity labels or explicit
   sensitivity labels (such as IPSO provides for IPv4 [Ken91]). Some



Atkinson                    Standards Track                    [Page 17]

RFC 1825              Security Architecture for IP           August 1995


   environments might consider the Internet-standard encryption
   algorithm sufficiently strong to provide Mandatory Access Controls
   (MAC).  Full encryption SHOULD be used for all communications between
   multi-level computers or compartmented mode workstations even when
   the computing environment is considered to be protected.

6. SECURITY CONSIDERATIONS

   This entire memo discusses the Security Architecture for the Internet
   Protocol.  It is not a general security architecture for the
   Internet, but is instead focused on the IP layer.

   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].

   If more than one sender uses shares a Security Association with a
   destination, then the receiving system can only authenticate that the
   packet was sent from one of those systems and cannot authenticate
   which of those systems sent it.  Similarly, if the receiving system
   does not check that the Security Association used for a packet is
   valid for the claimed Source Address of the packet, then the
   receiving system cannot authenticate whether the packet's claimed
   Source Address is valid.  For example, if senders "A" and "B" each
   have their own unique Security Association with destination "D" and
   "B" uses its valid Security Association with D but forges a Source
   Address of "A", then "D" will be fooled into believing the packet
   came from "A" unless "D" verifies that the claimed Source Address is
   party to the Security Association that was used.

   Users need to understand that the quality of the security provided by
   the mechanisms provided by these two IP security mechanisms depends
   completely on the strength of the implemented cryptographic
   algorithms, the strength of the key being used, the correct
   implementation of the cryptographic algorithms, the security of the
   key management protocol, and the correct implementation of IP and the
   several security mechanisms in all of the participating systems.  The
   security of the implementation is in part related to the security of
   the operating system which embodies the security implementations.
   For example, if the operating system does not keep the private
   cryptologic keys (that is, all symmetric keys and the private
   asymmetric keys) confidential, then traffic using those keys will not
   be secure.  If any of these is incorrect or insufficiently secure,
   little or no real security will be provided to the user.  Because
   different users on the same system might not trust each other, each
   user or each session should usually be keyed separately.  This will



Atkinson                    Standards Track                    [Page 18]

RFC 1825              Security Architecture for IP           August 1995


   also tend to increase the work required to cryptanalyse the traffic
   since not all traffic will use the same key.

   Certain security properties (e.g., traffic analysis protection) are
   not provided by any of these mechanisms.  One possible approach to
   traffic analysis protection is appropriate use of link encryption
   [VK83].  Users must carefully consider which security properties they
   require and take active steps to ensure that their needs are met by
   these or other mechanisms.

   Certain applications (e.g., electronic mail) probably need to have
   application-specific security mechanisms.  Application-specific
   security mechanisms are out of the scope of this document.  Users
   interested in electronic mail security should consult the RFCs
   describing the Internet's Privacy-Enhanced Mail system.  Users
   concerned about other application-specific mechanisms should consult
   the online RFCs to see if suitable Internet Standard mechanisms
   exist.

ACKNOWLEDGEMENTS

   Many of the concepts here are derived from or were influenced by the
   US Government's SDNS security protocol specifications, the ISO/IEC's
   NLSP specification, or from the proposed swIPe security protocol
   [SDNS, ISO, IB93, IBK93].  The work done for SNMP Security and SNMPv2
   Security influenced the choice of default cryptological algorithms
   and modes [GM93].  Steve Bellovin, Steve Deering, Richard Hale,
   George Kamis, Phil Karn, Frank Kastenholz, Perry Metzger, Dave
   Mihelcic, Hilarie Orman and Bill Simpson provided careful critiques
   of early versions of this document.

REFERENCES

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

   [Atk95b] Atkinson, R., "IP Encapsulating Security Payload", RFC 1827,
            NRL, August 1995.

   [BCCH94] Braden, R., Clark, D., Crocker, S., and C. Huitema, "Report
            of IAB Workshop on Security in the Internet Architecture",
            RFC 1636, USC/Information Sciences Institute, MIT, Trusted
            Information Systems, INRIA, June 1994.

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




Atkinson                    Standards Track                    [Page 19]

RFC 1825              Security Architecture for IP           August 1995


   [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.

   [BFC93]  A. Ballardie, P. Francis, & J. Crocroft, "Core Based Trees:
            An Architecture for Scalable Inter-Domain Multicast Routing",
            Proceedings of ACM SIGCOMM 93, ACM Computer Communications
            Review, Volume. 23, Number 4, October 1993, pp. 85-95.

   [BL73]   Bell, D.E. & LaPadula, L.J., "Secure Computer Systems:
            Mathematical Foundations and Model", Technical Report
            M74-244, The MITRE Corporation, Bedford, MA, May 1973.

   [CB94]   William R. Cheswick & Steven M. Bellovin, Firewalls &
            Internet Security, Addison-Wesley, Reading, MA, 1994.

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

   [DoD85]  US National Computer Security Center, "Department of Defense
            Trusted Computer System Evaluation Criteria", DoD
            5200.28-STD, US Department of Defense, Ft. Meade, MD.,
            December 1985.

   [DoD87]  US National Computer Security Center, "Trusted Network
            Interpretation of the Trusted Computer System Evaluation
            Criteria", NCSC-TG-005, Version 1, US Department of Defense,
            Ft. Meade, MD., 31 July 1987.

   [DH76]   W. Diffie & M. Hellman, "New Directions in Cryptography",
            IEEE Transactions on Information Theory, Vol. IT-22, No. 6,
            November 1976, pp. 644-654.

   [EK94]   D. Eastlake III & C. Kaufman, "Domain Name System Protocol
            Security Extensions", Work in Progress.

   [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.

   [HA94]   Haller, N., and R. Atkinson, "On Internet Authentication",
            RFC 1704, Bell Communications Research, NRL, October 1994.

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



Atkinson                    Standards Track                    [Page 20]

RFC 1825              Security Architecture for IP           August 1995



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

   [IB93]  John Ioannidis and Matt Blaze, "Architecture and
           Implementation of Network-layer Security Under Unix",
           Proceedings of 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.

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

   [Ken93] Kent, S., "Privacy Enhancement for Internet Electronic Mail:
           Part II: Certificate-Based Key Management", RFC 1422,
           BBN Communications, February 1993.

   [KB93]  Kohl, J., and B. Neuman, "The Kerberos Network Authentication
           Service (V5)", RFC 1510, Digital Equipment Corporation,
           USC/Information Sciences Institute, September 1993.

   [MS95]  Metzger, P., and W. Simpson, "IP Authentication with Keyed
           MD5", RFC 1828, Piermont, Daydreamer, August 1995.

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

   [NS78]  R.M. Needham & M.D. Schroeder, "Using Encryption for
           Authentication in Large Networks of Computers", Communications
           of the ACM, Vol. 21, No. 12, December 1978, pp. 993-999.

   [NS81]  R.M. Needham & M.D. Schroeder, "Authentication Revisited",
           ACM Operating Systems Review, Vol. 21, No. 1., 1981.

   [OTA94] US Congress, Office of Technology Assessment, "Information
           Security & Privacy in Network Environments", OTA-TCT-606,
           Government Printing Office, Washington, DC, September 1994.

   [Sch94] Bruce Schneier, Applied Cryptography, Section 8.6,
           John Wiley & Sons, New York, NY, 1994.






Atkinson                    Standards Track                    [Page 21]

RFC 1825              Security Architecture for IP           August 1995


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

   [VK83]  V.L. Voydock & S.T. Kent, "Security Mechanisms in High-level
           Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983.

   [ZDESZ93] Zhang, L., Deering, S., Estrin, D., Shenker, S., and
             D. Zappala, "RSVP: A New Resource ReSerVation Protocol",
             IEEE Network magazine, September 1993.

DISCLAIMER

   The views expressed in this note 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
   design.

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 22]