rfc2408.txt

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

   ISAKMP.

1.1 Requirements Terminology

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [RFC-2119].

1.2 The Need for Negotiation

   ISAKMP extends the assertion in [DOW92] that authentication and key
   exchanges must be combined for better security to include security
   association exchanges.  The security services required for



Maughan, et. al.            Standards Track                     [Page 5]

RFC 2408                         ISAKMP                    November 1998


   communications depends on the individual network configurations and
   environments.  Organizations are setting up Virtual Private Networks
   (VPN), also known as Intranets, that will require one set of security
   functions for communications within the VPN and possibly many
   different security functions for communications outside the VPN to
   support geographically separate organizational components, customers,
   suppliers, sub-contractors (with their own VPNs), government, and
   others.  Departments within large organizations may require a number
   of security associations to separate and protect data (e.g.
   personnel data, company proprietary data, medical) on internal
   networks and other security associations to communicate within the
   same department.  Nomadic users wanting to "phone home" represent
   another set of security requirements.  These requirements must be
   tempered with bandwidth challenges.  Smaller groups of people may
   meet their security requirements by setting up "Webs of Trust".
   ISAKMP exchanges provide these assorted networking communities the
   ability to present peers with the security functionality that the
   user supports in an authenticated and protected manner for agreement
   upon a common set of security attributes, i.e.  an interoperable
   security association.

1.3 What can be Negotiated?

   Security associations must support different encryption algorithms,
   authentication mechanisms, and key establishment algorithms for other
   security protocols, as well as IP Security.  Security associations
   must also support host-oriented certificates for lower layer
   protocols and user- oriented certificates for higher level protocols.
   Algorithm and mechanism independence is required in applications such
   as e-mail, remote login, and file transfer, as well as in session
   oriented protocols, routing protocols, and link layer protocols.
   ISAKMP provides a common security association and key establishment
   protocol for this wide range of security protocols, applications,
   security requirements, and network environments.

   ISAKMP is not bound to any specific cryptographic algorithm, key
   generation technique, or security mechanism.  This flexibility is
   beneficial for a number of reasons.  First, it supports the dynamic
   communications environment described above.  Second, the independence
   from specific security mechanisms and algorithms provides a forward
   migration path to better mechanisms and algorithms.  When improved
   security mechanisms are developed or new attacks against current
   encryption algorithms, authentication mechanisms and key exchanges
   are discovered, ISAKMP will allow the updating of the algorithms and
   mechanisms without having to develop a completely new KMP or patch
   the current one.





Maughan, et. al.            Standards Track                     [Page 6]

RFC 2408                         ISAKMP                    November 1998


   ISAKMP has basic requirements for its authentication and key exchange
   components.  These requirements guard against denial of service,
   replay / reflection, man-in-the-middle, and connection hijacking
   attacks.  This is important because these are the types of attacks
   that are targeted against protocols.  Complete Security Association
   (SA) support, which provides mechanism and algorithm independence,
   and protection from protocol threats are the strengths of ISAKMP.

1.4 Security Associations and Management

   A Security Association (SA) is a relationship between two or more
   entities that describes how the entities will utilize security
   services to communicate securely.  This relationship is represented
   by a set of information that can be considered a contract between the
   entities.  The information must be agreed upon and shared between all
   the entities.  Sometimes the information alone is referred to as an
   SA, but this is just a physical instantiation of the existing
   relationship.  The existence of this relationship, represented by the
   information, is what provides the agreed upon security information
   needed by entities to securely interoperate.  All entities must
   adhere to the SA for secure communications to be possible.  When
   accessing SA attributes, entities use a pointer or identifier refered
   to as the Security Parameter Index (SPI). [SEC-ARCH] provides details
   on IP Security Associations (SA) and Security Parameter Index (SPI)
   definitions.

1.4.1 Security Associations and Registration

   The SA attributes required and recommended for the IP Security (AH,
   ESP) are defined in [SEC-ARCH].  The attributes specified for an IP
   Security SA include, but are not limited to, authentication
   mechanism, cryptographic algorithm, algorithm mode, key length, and
   Initialization Vector (IV).  Other protocols that provide algorithm
   and mechanism independent security MUST define their requirements for
   SA attributes.  The separation of ISAKMP from a specific SA
   definition is important to ensure ISAKMP can es tablish SAs for all
   possible security protocols and applications.

   NOTE: See [IPDOI] for a discussion of SA attributes that should be
   considered when defining a security protocol or application.

   In order to facilitate easy identification of specific attributes
   (e.g.  a specific encryption algorithm) among different network
   entites the attributes must be assigned identifiers and these
   identifiers must be registered by a central authority.  The Internet
   Assigned Numbers Authority (IANA) provides this function for the
   Internet.




Maughan, et. al.            Standards Track                     [Page 7]

RFC 2408                         ISAKMP                    November 1998


1.4.2 ISAKMP Requirements

   Security Association (SA) establishment MUST be part of the key
   management protocol defined for IP based networks.  The SA concept is
   required to support security protocols in a diverse and dynamic
   networking environment.  Just as authentication and key exchange must
   be linked to provide assurance that the key is established with the
   authenticated party [DOW92], SA establishment must be linked with the
   authentication and the key exchange protocol.

   ISAKMP provides the protocol exchanges to establish a security
   association between negotiating entities followed by the
   establishment of a security association by these negotiating entities
   in behalf of some protocol (e.g.  ESP/AH). First, an initial protocol
   exchange allows a basic set of security attributes to be agreed upon.
   This basic set provides protection for subsequent ISAKMP exchanges.
   It also indicates the authentication method and key exchange that
   will be performed as part of the ISAKMP protocol.  If a basic set of
   security attributes is already in place between the negotiating
   server entities, the initial ISAKMP exchange may be skipped and the
   establishment of a security association can be done directly.  After
   the basic set of security attributes has been agreed upon, initial
   identity authenticated, and required keys generated, the established
   SA can be used for subsequent communications by the entity that
   invoked ISAKMP.  The basic set of SA attributes that MUST be
   implemented to provide ISAKMP interoperability are defined in
   Appendix A.

1.5 Authentication

   A very important step in establishing secure network communications
   is authentication of the entity at the other end of the
   communication.  Many authentication mechanisms are available.
   Authentication mechanisms fall into two catagories of strength - weak
   and strong.  Sending cleartext keys or other unprotected
   authenticating information over a network is weak, due to the threat
   of reading them with a network sniffer.  Additionally, sending one-
   way hashed poorly-chosen keys with low entropy is also weak, due to
   the threat of brute-force guessing attacks on the sniffed messages.
   While passwords can be used for establishing identity, they are not
   considered in this context because of recent statements from the
   Internet Architecture Board [IAB].  Digital signatures, such as the
   Digital Signature Standard (DSS) and the Rivest-Shamir-Adleman (RSA)
   signature, are public key based strong authentication mechanisms.
   When using public key digital signatures each entity requires a
   public key and a private key.  Certificates are an essential part of
   a digital signature authentication mechanism.  Certificates bind a
   specific entity's identity (be it host, network, user, or



Maughan, et. al.            Standards Track                     [Page 8]

RFC 2408                         ISAKMP                    November 1998


   application) to its public keys and possibly other security-related
   information such as privileges, clearances, and compartments.
   Authentication based on digital signatures requires a trusted third
   party or certificate authority to create, sign and properly
   distribute certificates.  For more detailed information on digital
   signatures, such as DSS and RSA, and certificates see [Schneier].

1.5.1 Certificate Authorities

   Certificates require an infrastructure for generation, verification,
   revocation, management and distribution.  The Internet Policy
   Registration Authority (IPRA) [RFC-1422] has been established to
   direct this infrastructure for the IETF. The IPRA certifies Policy
   Certification Authorities (PCA). PCAs control Certificate Authorities
   (CA) which certify users and subordinate entities.  Current
   certificate related work includes the Domain Name System (DNS)
   Security Extensions [DNSSEC] which will provide signed entity keys in
   the DNS. The Public Key Infrastucture (PKIX) working group is
   specifying an Internet profile for X.509 certificates.  There is also
   work going on in industry to develop X.500 Directory Services which
   would provide X.509 certificates to users.  The U.S. Post Office is
   developing a (CA) hierarchy.  The NIST Public Key Infrastructure
   Working Group has also been doing work in this area.  The DOD Multi
   Level Information System Security Initiative (MISSI) program has
   begun deploying a certificate infrastructure for the U.S. Government.
   Alternatively, if no infrastructure exists, the PGP Web of Trust
   certificates can be used to provide user authentication and privacy
   in a community of users who know and trust each other.

1.5.2 Entity Naming

   An entity's name is its identity and is bound to its public keys in
   certificates.  The CA MUST define the naming semantics for the
   certificates it issues.  See the UNINETT PCA Policy Statements
   [Berge] for an example of how a CA defines its naming policy.  When
   the certificate is verified, the name is verified and that name will
   have meaning within the realm of that CA. An example is the DNS
   security extensions which make DNS servers CAs for the zones and
   nodes they serve.  Resource records are provided for public keys and
   signatures on those keys.  The names associated with the keys are IP
   addresses and domain names which have meaning to entities accessing
   the DNS for this information.  A Web of Trust is another example.
   When webs of trust are set up, names are bound with the public keys.
   In PGP the name is usually the entity's e-mail address which has
   meaning to those, and only those, who understand e-mail.  Another web
   of trust could use an entirely different naming scheme.





Maughan, et. al.            Standards Track                     [Page 9]

RFC 2408                         ISAKMP                    November 1998


1.5.3 ISAKMP Requirements

   Strong authentication MUST be provided on ISAKMP exchanges.  Without
   being able to authenticate the entity at the other end, the Security
   Association (SA) and session key established are suspect.  Without
   authentication you are unable to trust an entity's identification,
   which makes access control questionable.  While encryption (e.g.
   ESP) and integrity (e.g.  AH) will protect subsequent communications
   from passive eavesdroppers, without authentication it is possible
   that the SA and key may have been established with an adversary who
   performed an active man-in-the-middle attack and is now stealing all
   your personal data.

   A digital signature algorithm MUST be used within ISAKMP's
   authentication component.  However, ISAKMP does not mandate a
   specific signature algorithm or certificate authority (CA). ISAKMP
   allows an entity initiating communications to indicate which CAs it
   supports.  After selection of a CA, the protocol provides the
   messages required to support the actual authentication exchange.  The
   protocol provides a facility for identification of different