rfc1825.txt

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


RFC 1825              Security Architecture for IP           August 1995


   small, static environments but does not scale.  It is not a viable
   medium-term or long-term approach, but might be appropriate and
   useful in many environments in the near-term.  For example, within a
   small LAN it is entirely practical to manually configure keys for
   each system.  Within a single administrative domain it is practical
   to configure keys for each router so that the routing data can be
   protected and to reduce the risk of an intruder breaking into a
   router.  Another case is where an organisation has an encrypting
   firewall between the internal network and the Internet at each of its
   sites and it connects two or more sites via the Internet.  In this
   case, the encrypting firewall might selectively encrypt traffic for
   other sites within the organisation using a manually configured key,
   while not encrypting traffic for other destinations.  It also might
   be appropriate when only selected communications need to be secured.

4.2 Some Existing Key Management Techniques

   There are a number of key management algorithms that have been
   described in the public literature.  Needham & Schroeder have
   proposed a key management algorithm which relies on a centralised key
   distribution system [NS78, NS81].  This algorithm is used in the
   Kerberos Authentication System developed at MIT under Project Athena
   [KB93].  Diffie and Hellman have devised an algorithm which does not
   require a centralised key distribution system [DH76].  Unfortunately,
   the original Diffie-Hellman technique is vulnerable to an active "man
   in the middle" attack [Sch93, p. 43-44].  However, this vulnerability
   can be mitigated by using signed keys to authentically bootstrap into
   the Diffie-Hellman exchange [Sch93, p. 45].

4.3 Automated Key Distribution

   Widespread deployment and use of IP security will require an
   Internet-standard scalable key management protocol.  Ideally such a
   protocol would support a number of protocols in the Internet protocol
   suite, not just IP security.  There is work underway within the IETF
   to add signed host keys to the Domain Name System [EK94] The DNS keys
   enable the originating party to authenticate key management messages
   with the other key management party using an asymmetric algorithm.
   The two parties would then have an authenticatible communications
   channel that could be used to create a shared session key using
   Diffie-Hellman or other means [DH76] [Sch93].

4.4 Keying Approaches for IP

   There are two keying approaches for IP.  The first approach, called
   host-oriented keying, has all users on host 1 share the same key for
   use on traffic destined for all users on host 2.  The second
   approach, called user-oriented keying, lets user A on host 1 have one



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


   or more unique session keys for its traffic destined for host 2; such
   session keys are not shared with other users on host1.  For example,
   user A's ftp session might use a different key than user A's telnet
   session.  In systems claiming to provide multi-level security, user A
   will typically have at least one key per sensitivity level in use
   (e.g., one key for UNCLASSIFIED traffic, a second key for SECRET
   traffic, and a third key for TOP SECRET traffic).  Similarly, with
   user-oriented keying one might use separate keys for information sent
   to a multicast group and control messages sent to the same multicast
   group.

   In many cases, a single computer system will have at least two
   mutually suspicious users A and B that do not trust each other.  When
   host-oriented keying is used and mutually suspicious users exist, it
   is sometimes possible for user A to determine the host-oriented key
   via well known methods, such as a Chosen Plaintext attack.  Once user
   A has improperly obtained the key in use, user A can then either read
   user B's encrypted traffic or forge traffic from user B.  When user-
   oriented keying is used, certain kinds of attack from one user onto
   another user's traffic are not possible.

   IP Security is intended to be able to provide Authentication,
   Integrity, and Confidentiality for applications operating on
   connected end systems when appropriate algorithms are in use.
   Integrity and Confidentiality can be provided by host-oriented keying
   when appropriate dynamic key management techniques and appropriate
   algorithms are in use.  However, authentication of principals using
   applications on end-systems requires that processes running
   applications be able to request and use their own Security
   Associations.  In this manner, applications can make use of key
   distribution facilities that provide authentication.

   Hence, support for user-oriented keying SHOULD be present in all IP
   implementations, as is described in the "IP Key Management
   Requirements" section below.

4.5 Multicast Key Distribution

   Multicast key distribution is an active research area in the
   published literature as of this writing.  For multicast groups having
   relatively few members, manual key distribution or multiple use of
   existing unicast key distribution algorithms such as modified
   Diffie-Hellman appears feasible.  For very large groups, new scalable
   techniques will be needed.  The use of Core-Based Trees (CBT) to
   provide session key management as well as multicast routing might be
   an approach used in the future [BFC93].





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


4.6 IP Key Management Requirements

   This section defines key management requirements for all IPv6
   implementations and for those IPv4 implementations that implement the
   IP Authentication Header, the IP Encapsulating Security Payload, or
   both.  It applies equally to the IP Authentication Header and the IP
   Encapsulating Security Payload.

   All such implementations MUST support manual configuration of
   Security Associations.

   All such implementations SHOULD support an Internet standard Security
   Association establishment protocol (e.g., IKMP, Photuris) once such a
   protocol is published as an Internet standards-track RFC.

   Implementations MAY also support other methods of configuring
   Security Associations.

   Given two endpoints, it MUST be possible to have more than one
   concurrent Security Association for communications between them.
   Implementations on multi-user hosts SHOULD support user granularity
   (i.e., "user-oriented") Security Associations.

   All such implementations MUST permit the configuration of host-
   oriented keying.

   A device that encrypts or authenticates IP packets originated other
   systems, for example a dedicated IP encryptor or an encrypting
   gateway, cannot generally provide user-oriented keying for traffic
   originating on other systems.  Such systems MAY additionally
   implement support for user-oriented keying for traffic originating on
   other systems.

   The method by which keys are configured on a particular system is
   implementation-defined.  A flat file containing security association
   identifiers and the security parameters, including the key(s), is an
   example of one possible method for manual key distribution.  An IP
   system MUST take reasonable steps to protect the keys and other
   security association information from unauthorised examination or
   modification because all of the security lies in the keys.

5. USAGE

   This section describes the possible use of the security mechanisms
   provided by IP in several different environments and applications in
   order to give the implementer and user a better idea of how these
   mechanisms can be used to reduce security risks.




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


5.1 USE WITH FIREWALLS

   Firewalls are not uncommon in the current Internet [CB94].  While
   many dislike their presence because they restrict connectivity, they
   are unlikely to disappear in the near future.  Both of these IP
   mechanisms can be used to increase the security provided by
   firewalls.

   Firewalls used with IP often need to be able to parse the headers and
   options to determine the transport protocol (e.g., UDP or TCP) in use
   and the port number for that protocol.  Firewalls can be used with
   the Authentication Header regardless of whether that firewall is
   party to the appropriate Security Assocation, but a firewall that is
   not party to the applicable Security Association will not normally be
   able to decrypt an encrypted upper-layer protocol to view the
   protocol or port number needed to perform per-packet filtering OR to
   verify that the data (e.g., source, destination, transport protocol,
   port number) being used for access control decisions is correct and
   authentic.  Hence, authentication might be performed not only within
   an organisation or campus but also end to end with remote systems
   across the Internet.  This use of the Authentication Header with IP
   provides much more assurance that the data being used for access
   control decisions is authentic.

   Organisations with two or more sites that are interconnected using
   commercial IP service might wish to use a selectively encrypting
   firewall.  If an encrypting firewall were placed between each site of
   a company and the commercial IP service provider, the firewall could
   provide an encrypted IP tunnel among all the company's sites.  It
   could also encrypt traffic between the company and its suppliers,
   customers, and other affiliates.  Traffic with the Network
   Information Center, with public Internet archives, or some other
   organisations might not be encrypted because of the unavailability of
   a standard key management protocol or as a deliberate choice to
   facilitate better communications, improved network performance, and
   increased connectivity.  Such a practice could easily protect the
   company's sensitive traffic from eavesdropping and modification.

   Some organisations (e.g., governments) might wish to use a fully
   encrypting firewall to provide a protected virtual network over
   commercial IP service.  The difference between that and a bulk IP
   encryption device is that a fully encrypting firewall would provide
   filtering of the decrypted traffic as well as providing encryption of
   IP packets.







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


5.2 USE WITH IP MULTICAST

   In the past several years, the Multicast Backbone (MBONE) has grown
   rapidly.  IETF meetings and other conferences are now regularly
   multicast with real-time audio, video, and whiteboards.  Many people
   are now using teleconferencing applications based on IP Multicast in
   the Internet or in private internal networks.  Others are using IP
   multicasting to support distributed simulation or other applications.
   Hence it is important that the security mechanisms in IP be suitable
   for use in an environment where multicast is the general case.

   The Security Parameters Indexes (SPIs) used in the IP security
   mechanisms are receiver-oriented, making them well suited for use in
   IP multicast [Atk95a, Atk95b].  Unfortunately, most currently
   published multicast key distribution protocols do not scale well.
   However, there is active research in this area.  As an interim step,
   a multicast group could repeatedly use a secure unicast key
   distribution protocol to distribute the key to all members or the
   group could pre-arrange keys using manual key distribution.

5.3 USE TO PROVIDE QOS PROTECTION

   The recent IAB Security Workshop identified Quality of Service
   protection as an area of significant interest [BCCH].  The two IP
   security mechanisms are intended to provide good support for real-
   time services as well as multicasting.  This section describes one
   possible approach to providing such protection.

   The Authentication Header might be used, with appropriate key
   management, to provide authentication of packets.  This
   authentication is potentially important in packet classification
   within routers.  The IPv6 Flow Identifier might act as a Low-Level
   Identifier (LLID).  Used together, packet classification within
   routers becomes straightforward if the router is provided with the
   appropriate keying material.  For performance reasons the routers
   might authenticate only every Nth packet rather than every packet,
   but this is still a significant improvement over capabilities in the
   current Internet.  Quality of service provisioning is likely to also
   use the Flow ID in conjunction with a resource reservation protocol,
   such as RSVP [ZDESZ93].  Thus, the authenticated packet
   classification can be used to help ensure that each packet receives
   appropriate handling inside routers.

5.4 USE IN COMPARTMENTED OR MULTI-LEVEL NETWORKS

   A multi-level secure (MLS) network is one where a single network is
   used to communicate data at different sensitivity levels (e.g.,
   Unclassified and Secret) [DoD85] [DoD87].  Many governments have



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


   significant interest in MLS networking [DIA].  The IP security
   mechanisms have been designed to support MLS networking.  MLS
   networking requires the use of strong Mandatory Access Controls
   (MAC), which ordinary users are incapable of controlling or violating
   [BL73].  This section pertains only to the use of these IP security
   mechanisms in MLS environments.

   The Authentication Header can be used to provide strong
   authentication among hosts in a single-level network.  The
   Authentication Header can also be used to provide strong assurance
   for both mandatory access control decisions in multi-level networks
   and discretionary access control decisions in all kinds of networks.
   If explicit IP sensitivity labels (e.g., IPSO) [Ken91] are used and
   confidentiality is not considered necessary within the particular
   operational environment, the Authentication Header is used to provide
   authentication for the entire packet, including cryptographic binding
   of the sensitivity level to the IP header and user data.  This is a
   significant improvement over labeled IPv4 networks where the label is
   trusted even though it is not trustworthy because there is no
   authentication or cryptographic binding of the label to the IP header
   and user data.  IPv6 will normally use implicit sensitivity labels
   that are part of the Security Association but not transmitted with
   each packet instead of using explicit sensitivity labels.  All
   explicit IP sensitivity labels MUST be authenticated using either
   ESP, AH, or both.