rfc2408.txt

RFC 的详细文档！

   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
   certificate authorities, certificate types (e.g.  X.509, PKCS #7,
   PGP, DNS SIG and KEY records), and the exchange of the certificates
   identified.

   ISAKMP utilizes digital signatures, based on public key cryptography,
   for authentication.  There are other strong authentication systems
   available, which could be specified as additional optional
   authentication mechanisms for ISAKMP. Some of these authentication
   systems rely on a trusted third party called a key distribution
   center (KDC) to distribute secret session keys.  An example is
   Kerberos, where the trusted third party is the Kerberos server, which
   holds secret keys for all clients and servers within its network
   domain.  A client's proof that it holds its secret key provides
   authenticaton to a server.

   The ISAKMP specification does not specify the protocol for
   communicating with the trusted third parties (TTP) or certificate
   directory services.  These protocols are defined by the TTP and
   directory service themselves and are outside the scope of this
   specification.  The use of these additional services and protocols
   will be described in a Key Exchange specific document.

1.6 Public Key Cryptography

   Public key cryptography is the most flexible, scalable, and efficient
   way for users to obtain the shared secrets and session keys needed to
   support the large number of ways Internet users will interoperate.
   Many key generation algorithms, that have different properties, are



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


   available to users (see [DOW92], [ANSI], and [Oakley]).  Properties
   of key exchange protocols include the key establishment method,
   authentication, symmetry, perfect forward secrecy, and back traffic
   protection.

   NOTE: Cryptographic keys can protect information for a considerable
   length of time.  However, this is based on the assumption that keys
   used for protection of communications are destroyed after use and not
   kept for any reason.

1.6.1 Key Exchange Properties

   Key Establishment (Key Generation / Key Transport): The two common
   methods of using public key cryptography for key establishment are
   key transport and key generation.  An example of key transport is the
   use of the RSA algorithm to encrypt a randomly generated session key
   (for encrypting subsequent communications) with the recipient's
   public key.  The encrypted random key is then sent to the recipient,
   who decrypts it using his private key.  At this point both sides have
   the same session key, however it was created based on input from only
   one side of the communications.  The benefit of the key transport
   method is that it has less computational overhead than the following
   method.  The Diffie-Hellman (D-H) algorithm illustrates key
   generation using public key cryptography.  The D-H algorithm is begun
   by two users exchanging public information.  Each user then
   mathematically combines the other's public information along with
   their own secret information to compute a shared secret value.  This
   secret value can be used as a session key or as a key encryption key
   for encrypting a randomly generated session key.  This method
   generates a session key based on public and secret information held
   by both users.  The benefit of the D-H algorithm is that the key used
   for encrypting messages is based on information held by both users
   and the independence of keys from one key exchange to another
   provides perfect forward secrecy.  Detailed descriptions of these
   algorithms can be found in [Schneier].  There are a number of
   variations on these two key generation schemes and these variations
   do not necessarily interoperate.

   Key Exchange Authentication: Key exchanges may be authenticated
   during the protocol or after protocol completion.  Authentication of
   the key exchange during the protocol is provided when each party
   provides proof it has the secret session key before the end of the
   protocol.  Proof can be provided by encrypting known data in the
   secret session key during the protocol echange.  Authentication after
   the protocol must occur in subsequent commu nications.
   Authentication during the protocol is preferred so subsequent
   communications are not initiated if the secret session key is not
   established with the desired party.



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


   Key Exchange Symmetry: A key exchange provides symmetry if either
   party can initiate the exchange and exchanged messages can cross in
   transit without affecting the key that is generated.  This is
   desirable so that computation of the keys does not require either
   party to know who initated the exchange.  While key exchange symmetry
   is desirable, symmetry in the entire key management protocol may
   provide a vulnerablity to reflection attacks.

   Perfect Forward Secrecy: As described in [DOW92], an authenticated
   key exchange protocol provides perfect forward secrecy if disclosure
   of longterm secret keying material does not compromise the secrecy of
   the exchanged keys from previous communications.  The property of
   perfect forward secrecy does not apply to key exchange without
   authentication.

1.6.2 ISAKMP Requirements

   An authenticated key exchange MUST be supported by ISAKMP. Users
   SHOULD choose additional key establishment algorithms based on their
   requirements.  ISAKMP does not specify a specific key exchange.
   However, [IKE] describes a proposal for using the Oakley key exchange
   [Oakley] in conjunction with ISAKMP. Requirements that should be
   evaluated when choosing a key establishment algorithm include
   establishment method (generation vs.  transport), perfect forward
   secrecy, computational overhead, key escrow, and key strength.  Based
   on user requirements, ISAKMP allows an entity initiating
   communications to indicate which key exchanges it supports.  After
   selection of a key exchange, the protocol provides the messages
   required to support the actual key establishment.

1.7 ISAKMP Protection

1.7.1 Anti-Clogging (Denial of Service)

   Of the numerous security services available, protection against
   denial of service always seems to be one of the most difficult to
   address.  A "cookie" or anti-clogging token (ACT) is aimed at
   protecting the computing resources from attack without spending
   excessive CPU resources to determine its authenticity.  An exchange
   prior to CPU-intensive public key operations can thwart some denial
   of service attempts (e.g.  simple flooding with bogus IP source
   addresses).  Absolute protection against denial of service is
   impossible, but this anti-clogging token provides a technique for
   making it easier to handle.  The use of an anti-clogging token was
   introduced by Karn and Simpson in [Karn].






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


   It should be noted that in the exchanges shown in section 4, the
   anticlogging mechanism should be used in conjuction with a garbage-
   state collection mechanism; an attacker can still flood a server
   using packets with bogus IP addresses and cause state to be created.
   Such aggressive memory management techniques SHOULD be employed by
   protocols using ISAKMP that do not go through an initial, anti-
   clogging only phase, as was done in [Karn].

1.7.2 Connection Hijacking

   ISAKMP prevents connection hijacking by linking the authentication,
   key exchange and security association exchanges.  This linking
   prevents an attacker from allowing the authentication to complete and
   then jumping in and impersonating one entity to the other during the
   key and security association exchanges.

1.7.3 Man-in-the-Middle Attacks

   Man-in-the-Middle attacks include interception, insertion, deletion,
   and modification of messages, reflecting messages back at the sender,
   replaying old messages and redirecting messages.  ISAKMP features
   prevent these types of attacks from being successful.  The linking of
   the ISAKMP exchanges prevents the insertion of messages in the
   protocol exchange.  The ISAKMP protocol state machine is defined so
   deleted messages will not cause a partial SA to be created, the state
   machine will clear all state and return to idle.  The state machine
   also prevents reflection of a message from causing harm.  The
   requirement for a new cookie with time variant material for each new
   SA establishment prevents attacks that involve replaying old
   messages.  The ISAKMP strong authentication requirement prevents an
   SA from being established with anyone other than the intended party.
   Messages may be redirected to a different destination or modified but
   this will be detected and an SA will not be established.  The ISAKMP
   specification defines where abnormal processing has occurred and
   recommends notifying the appropriate party of this abnormality.

1.8 Multicast Communications

   It is expected that multicast communications will require the same
   security services as unicast communications and may introduce the
   need for additional security services.  The issues of distributing
   SPIs for multicast traffic are presented in [SEC-ARCH].  Multicast
   security issues are also discussed in [RFC-1949] and [BC].  A future
   extension to ISAKMP will support multicast key distribution.  For an
   introduction to the issues related to multicast security, consult the
   Internet Drafts, [RFC-2094] and [RFC-2093], describing Sparta's
   research in this area.




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


2 Terminology and Concepts

2.1 ISAKMP Terminology

   Security Protocol: A Security Protocol consists of an entity at a
   single point in the network stack, performing a security service for
   network communication.  For example, IPSEC ESP and IPSEC AH are two
   different security protocols.  TLS is another example.  Security
   Protocols may perform more than one service, for example providing
   integrity and confidentiality in one module.

   Protection Suite: A protection suite is a list of the security
   services that must be applied by various security protocols.  For
   example, a protection suite may consist of DES encryption in IP ESP,
   and keyed MD5 in IP AH. All of the protections in a suite must be
   treated as a single unit.  This is necessary because security
   services in different security protocols can have subtle
   interactions, and the effects of a suite must be analyzed and
   verified as a whole.

   Security Association (SA): A Security Association is a security-
   protocol- specific set of parameters that completely defines the
   services and mechanisms necessary to protect traffic at that security
   protocol location.  These parameters can include algorithm
   identifiers, modes, cryptographic keys, etc.  The SA is referred to
   by its associated security protocol (for example, "ISAKMP SA", "ESP
   SA", "TLS SA").

   ISAKMP SA: An SA used by the ISAKMP servers to protect their own
   traffic.  Sections 2.3 and 2.4 provide more details about ISAKMP SAs.

   Security Parameter Index (SPI): An identifier for a Security
   Assocation, relative to some security protocol.  Each security
   protocol has its own "SPI-space".  A (security protocol, SPI) pair
   may uniquely identify an SA. The uniqueness of the SPI is
   implementation dependent, but could be based per system, per
   protocol, or other options.  Depending on the DOI, additional
   information (e.g.  host address) may be necessary to identify an SA.
   The DOI will also determine which SPIs (i.e.  initiator's or
   responder's) are sent during communication.

   Domain of Interpretation: A Domain of Interpretation (DOI) defines
   payload formats, exchange types, and conventions for naming
   security-relevant information such as security policies or
   cryptographic algorithms and modes.  A Domain of Interpretation (DOI)
   identifier is used to interpret the payloads of ISAKMP payloads.  A
   system SHOULD support multiple Domains of Interpretation
   simultaneously.  The concept of a DOI is based on previous work by