rfc2408.txt

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

       determine the required security services.

    o  The set of security policies that must, and may, be supported.

    o  A syntax for the specification of proposed security services.

    o  A scheme for naming security-relevant information, including
       encryption algorithms, key exchange algorithms, security policy
       attributes, and certificate authorities.

    o  The specific formats of the various payload contents.

    o  Additional exchange types, if required.

   The rules for the IETF IP Security DOI are presented in [IPDOI].
   Specifications of the rules for customized DOIs will be presented in
   separate documents.

   Situation: A situation contains all of the security-relevant
   information that a system considers necessary to decide the security
   services required to protect the session being negotiated.  The
   situation may include addresses, security classifications, modes of
   operation (normal vs.  emergency), etc.

   Proposal: A proposal is a list, in decreasing order of preference, of
   the protection suites that a system considers acceptable to protect
   traffic under a given situation.

   Payload: ISAKMP defines several types of payloads, which are used to
   transfer information such as security association data, or key
   exchange data, in DOI-defined formats.  A payload consists of a
   generic payload header and a string of octects that is opaque to
   ISAKMP. ISAKMP uses DOI- specific functionality to synthesize and
   interpret these payloads.  Multiple payloads can be sent in a single
   ISAKMP message.  See section 3 for more details on the payload types,
   and [IPDOI] for the formats of the IETF IP Security DOI payloads.

   Exchange Type: An exchange type is a specification of the number of
   messages in an ISAKMP exchange, and the payload types that are
   contained in each of those messages.  Each exchange type is designed
   to provide a particular set of security services, such as anonymity
   of the participants, perfect forward secrecy of the keying material,
   authentication of the participants, etc.  Section 4.1 defines the



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


   default set of ISAKMP exchange types.  Other exchange types can be
   added to support additional key exchanges, if required.

2.2 ISAKMP Placement

   Figure 1 is a high level view of the placement of ISAKMP within a
   system context in a network architecture.  An important part of
   negotiating security services is to consider the entire "stack" of
   individual SAs as a unit.  This is referred to as a "protection
   suite".

     +------------+        +--------+                +--------------+
     !     DOI    !        !        !                !  Application !
     ! Definition ! <----> ! ISAKMP !                !    Process   !
     +------------+    --> !        !                !--------------!
    +--------------+   !   +--------+                ! Appl Protocol!
    ! Key Exchange !   !     ^  ^                    +--------------+
    !  Definition  !<--      !  !                           ^
    +--------------+         !  !                           !
                             !  !                           !
            !----------------!  !                           !
            v                   !                           !
        +-------+               v                           v
        !  API  !        +---------------------------------------------+
        +-------+        !                Socket Layer                 !
            !            !---------------------------------------------!
            v            !        Transport Protocol (TCP / UDP)       !
     +----------+        !---------------------------------------------!
     ! Security ! <----> !                     IP                      !
     ! Protocol !        !---------------------------------------------!
     +----------+        !             Link Layer Protocol             !
                         +---------------------------------------------+


                     Figure 1:  ISAKMP Relationships

2.3 Negotiation Phases

   ISAKMP offers two "phases" of negotiation.  In the first phase, two
   entities (e.g.  ISAKMP servers) agree on how to protect further
   negotiation traffic between themselves, establishing an ISAKMP SA.
   This ISAKMP SA is then used to protect the negotiations for the
   Protocol SA being requested.  Two entities (e.g.  ISAKMP servers) can
   negotiate (and have active) multiple ISAKMP SAs.







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


   The second phase of negotiation is used to establish security
   associations for other security protocols.  This second phase can be
   used to establish many security associations.  The security
   associations established by ISAKMP during this phase can be used by a
   security protocol to protect many message/data exchanges.

   While the two-phased approach has a higher start-up cost for most
   simple scenarios, there are several reasons that it is beneficial for
   most cases.

   First, entities (e.g.  ISAKMP servers) can amortize the cost of the
   first phase across several second phase negotiations.  This allows
   multiple SAs to be established between peers over time without having
   to start over for each communication.

   Second, security services negotiated during the first phase provide
   security properties for the second phase.  For example, after the
   first phase of negotiation, the encryption provided by the ISAKMP SA
   can provide identity protection, potentially allowing the use of
   simpler second-phase exchanges.  On the other hand, if the channel
   established during the first phase is not adequate to protect
   identities, then the second phase must negotiate adequate security
   mechanisms.

   Third, having an ISAKMP SA in place considerably reduces the cost of
   ISAKMP management activity - without the "trusted path" that an
   ISAKMP SA gives you, the entities (e.g.  ISAKMP servers) would have
   to go through a complete re-authentication for each error
   notification or deletion of an SA.

   Negotiation during each phase is accomplished using ISAKMP-defined
   exchanges (see section 4) or exchanges defined for a key exchange
   within a DOI.

   Note that security services may be applied differently in each
   negotiation phase.  For example, different parties are being
   authenticated during each of the phases of negotiation.  During the
   first phase, the parties being authenticated may be the ISAKMP
   servers/hosts, while during the second phase, users or application
   level programs are being authenticated.

2.4 Identifying Security Associations

   While bootstrapping secure channels between systems, ISAKMP cannot
   assume the existence of security services, and must provide some
   protections for itself.  Therefore, ISAKMP considers an ISAKMP
   Security Association to be different than other types, and manages
   ISAKMP SAs itself, in their own name space.  ISAKMP uses the two



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


   cookie fields in the ISAKMP header to identify ISAKMP SAs.  The
   Message ID in the ISAKMP Header and the SPI field in the Proposal
   payload are used during SA establishment to identify the SA for other
   security protocols.  The interpretation of these four fields is
   dependent on the operation taking place.

   The following table shows the presence or absence of several fields
   during SA establishment.  The following fields are necessary for
   various operations associated with SA establishment: cookies in the
   ISAKMP header, the ISAKMP Header Message ID field, and the SPI field
   in the Proposal payload.  An 'X' in the column means the value MUST
   be present.  An 'NA' in the column means a value in the column is Not
   Applicable to the operation.

  #             Operation            I-Cookie  R-Cookie  Message ID  SPI
 (1)  Start ISAKMP SA negotiation    X         0         0           0
 (2)  Respond ISAKMP SA negotiation  X         X         0           0
 (3)  Init other SA negotiation      X         X         X           X
 (4)  Respond other SA negotiation   X         X         X           X
 (5)  Other (KE, ID, etc.)           X         X         X/0         NA
 (6)  Security Protocol (ESP, AH)    NA        NA        NA          X

   In the first line (1) of the table, the initiator includes the
   Initiator Cookie field in the ISAKMP Header, using the procedures
   outlined in sections 2.5.3 and 3.1.

   In the second line (2) of the table, the responder includes the
   Initiator and Responder Cookie fields in the ISAKMP Header, using the
   procedures outlined in sections 2.5.3 and 3.1.  Additional messages
   may be exchanged between ISAKMP peers, depending on the ISAKMP
   exchange type used during the phase 1 negotiation.  Once the phase 1
   exchange is completed, the Initiator and Responder cookies are
   included in the ISAKMP Header of all subsequent communications
   between the ISAKMP peers.

   During phase 1 negotiations, the initiator and responder cookies
   determine the ISAKMP SA. Therefore, the SPI field in the Proposal
   payload is redundant and MAY be set to 0 or it MAY contain the
   transmitting entity's cookie.

   In the third line (3) of the table, the initiator associates a
   Message ID with the Protocols contained in the SA Proposal.  This
   Message ID and the initiator's SPI(s) to be associated with each
   protocol in the Proposal are sent to the responder.  The SPI(s) will
   be used by the security protocols once the phase 2 negotiation is
   completed.





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


   In the fourth line (4) of the table, the responder includes the same
   Message ID and the responder's SPI(s) to be associated with each
   protocol in the accepted Proposal.  This information is returned to
   the initiator.

   In the fifth line (5) of the table, the initiator and responder use
   the Message ID field in the ISAKMP Header to keep track of the in-
   progress protocol negotiation.  This is only applicable for a phase 2
   exchange and the value MUST be 0 for a phase 1 exchange because the
   combined cookies identify the ISAKMP SA. The SPI field in the
   Proposal payload is not applicable because the Proposal payload is
   only used during the SA negotiation message exchange (steps 3 and 4).

   In the sixth line (6) of the table, the phase 2 negotiation is
   complete.  The security protocols use the SPI(s) to determine which
   security services and mechanisms to apply to the communication
   between them.  The SPI value shown in the sixth line (6) is not the
   SPI field in the Proposal payload, but the SPI field contained within
   the security protocol header.

   During the SA establishment, a SPI MUST be generated.  ISAKMP is
   designed to handle variable sized SPIs.  This is accomplished by
   using the SPI Size field within the Proposal payload during SA
   establishment.  Handling of SPIs will be outlined by the DOI
   specification (e.g.  [IPDOI]).

   When a security association (SA) is initially established, one side
   assumes the role of initiator and the other the role of responder.
   Once the SA is established, both the original initiator and responder
   can initiate a phase 2 negotiation with the peer entity.  Thus,
   ISAKMP SAs are bidirectional in nature.

   Additionally, ISAKMP allows both initiator and responder to have some
   control during the negotiation process.  While ISAKMP is designed to
   allow an SA negotiation that includes multiple proposals, the
   initiator can maintain some control by only making one proposal in
   accordance with the initiator's local security policy.  Once the
   initiator sends a proposal containing more than one proposal (which
   are sent in decreasing preference order), the initiator relinquishes
   control to the responder.  Once the responder is controlling the SA
   establishment, the responder can make its policy take precedence over
   the initiator within the context of the multiple options offered by
   the initiator.  This is accomplished by selecting the proposal best
   suited for the responder's local security policy and returning this
   selection to the initiator.