rfc2409.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 1,489 行 · 第 1/5 页

Network Working Group                                         D. Harkins
Request for Comments: 2409                                     D. Carrel
Category: Standards Track                                  cisco Systems
                                                           November 1998


                    The Internet Key Exchange (IKE)

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Table Of Contents

   1 Abstract........................................................  2
   2 Discussion......................................................  2
   3 Terms and Definitions...........................................  3
   3.1 Requirements Terminology......................................  3
   3.2 Notation......................................................  3
   3.3 Perfect Forward Secrecty......................................  5
   3.4 Security Association..........................................  5
   4 Introduction....................................................  5
   5 Exchanges.......................................................  8
   5.1 Authentication with Digital Signatures........................ 10
   5.2 Authentication with Public Key Encryption..................... 12
   5.3 A Revised method of Authentication with Public Key Encryption. 13
   5.4 Authentication with a Pre-Shared Key.......................... 16
   5.5 Quick Mode.................................................... 16
   5.6 New Group Mode................................................ 20
   5.7 ISAKMP Informational Exchanges................................ 20
   6 Oakley Groups................................................... 21
   6.1 First Oakley Group............................................ 21
   6.2 Second Oakley Group........................................... 22
   6.3 Third Oakley Group............................................ 22
   6.4 Fourth Oakley Group........................................... 23
   7 Payload Explosion of Complete Exchange.......................... 23
   7.1 Phase 1 with Main Mode........................................ 23
   7.2 Phase 2 with Quick Mode....................................... 25
   8 Perfect Forward Secrecy Example................................. 27
   9 Implementation Hints............................................ 27



Harkins & Carrel            Standards Track                     [Page 1]

RFC 2409                          IKE                      November 1998


   10 Security Considerations........................................ 28
   11 IANA Considerations............................................ 30
   12 Acknowledgments................................................ 31
   13 References..................................................... 31
   Appendix A........................................................ 33
   Appendix B........................................................ 37
   Authors' Addresses................................................ 40
   Authors' Note..................................................... 40
   Full Copyright Statement.......................................... 41

1. Abstract

   ISAKMP ([MSST98]) provides a framework for authentication and key
   exchange but does not define them.  ISAKMP is designed to be key
   exchange independant; that is, it is designed to support many
   different key exchanges.

   Oakley ([Orm96]) describes a series of key exchanges-- called
   "modes"-- and details the services provided by each (e.g. perfect
   forward secrecy for keys, identity protection, and authentication).

   SKEME ([SKEME]) describes a versatile key exchange technique which
   provides anonymity, repudiability, and quick key refreshment.

   This document describes a protocol using part of Oakley and part of
   SKEME in conjunction with ISAKMP to obtain authenticated keying
   material for use with ISAKMP, and for other security associations
   such as AH and ESP for the IETF IPsec DOI.

2. Discussion

   This memo describes a hybrid protocol. The purpose is to negotiate,
   and provide authenticated keying material for, security associations
   in a protected manner.

   Processes which implement this memo can be used for negotiating
   virtual private networks (VPNs) and also for providing a remote user
   from a remote site (whose IP address need not be known beforehand)
   access to a secure host or network.

   Client negotiation is supported.  Client mode is where the
   negotiating parties are not the endpoints for which security
   association negotiation is taking place.  When used in client mode,
   the identities of the end parties remain hidden.







Harkins & Carrel            Standards Track                     [Page 2]

RFC 2409                          IKE                      November 1998


   This does not implement the entire Oakley protocol, but only a subset
   necessary to satisfy its goals. It does not claim conformance or
   compliance with the entire Oakley protocol nor is it dependant in any
   way on the Oakley protocol.

   Likewise, this does not implement the entire SKEME protocol, but only
   the method of public key encryption for authentication and its
   concept of fast re-keying using an exchange of nonces. This protocol
   is not dependant in any way on the SKEME protocol.

3. Terms and Definitions

3.1 Requirements Terminology

   Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
   "MAY" that appear in this document are to be interpreted as described
   in [Bra97].

3.2 Notation

   The following notation is used throughout this memo.

     HDR is an ISAKMP header whose exchange type is the mode.  When
     writen as HDR* it indicates payload encryption.

     SA is an SA negotiation payload with one or more proposals. An
     initiator MAY provide multiple proposals for negotiation; a
     responder MUST reply with only one.

     <P>_b indicates the body of payload <P>-- the ISAKMP generic
     vpayload is not included.

     SAi_b is the entire body of the SA payload (minus the ISAKMP
     generic header)-- i.e. the DOI, situation, all proposals and all
     transforms offered by the Initiator.

     CKY-I and CKY-R are the Initiator's cookie and the Responder's
     cookie, respectively, from the ISAKMP header.

     g^xi and g^xr are the Diffie-Hellman ([DH]) public values of the
     initiator and responder respectively.

     g^xy is the Diffie-Hellman shared secret.

     KE is the key exchange payload which contains the public
     information exchanged in a Diffie-Hellman exchange. There is no
     particular encoding (e.g. a TLV) used for the data of a KE payload.




Harkins & Carrel            Standards Track                     [Page 3]

RFC 2409                          IKE                      November 1998


     Nx is the nonce payload; x can be: i or r for the ISAKMP initiator
     and responder respectively.

     IDx is the identification payload for "x".  x can be: "ii" or "ir"
     for the ISAKMP initiator and responder respectively during phase
     one negotiation; or "ui" or "ur" for the user initiator and
     responder respectively during phase two.  The ID payload format for
     the Internet DOI is defined in [Pip97].

     SIG is the signature payload. The data to sign is exchange-
     specific.

     CERT is the certificate payload.

     HASH (and any derivitive such as HASH(2) or HASH_I) is the hash
     payload. The contents of the hash are specific to the
     authentication method.

     prf(key, msg) is the keyed pseudo-random function-- often a keyed
     hash function-- used to generate a deterministic output that
     appears pseudo-random.  prf's are used both for key derivations and
     for authentication (i.e. as a keyed MAC). (See [KBC96]).

     SKEYID is a string derived from secret material known only to the
     active players in the exchange.

     SKEYID_e is the keying material used by the ISAKMP SA to protect
     the confidentiality of its messages.

     SKEYID_a is the keying material used by the ISAKMP SA to
     authenticate its messages.

     SKEYID_d is the keying material used to derive keys for non-ISAKMP
     security associations.

     <x>y indicates that "x" is encrypted with the key "y".

     --> signifies "initiator to responder" communication (requests).

     <-- signifies "responder to initiator" communication (replies).

      |  signifies concatenation of information-- e.g. X | Y is the
     concatentation of X with Y.

     [x] indicates that x is optional.






Harkins & Carrel            Standards Track                     [Page 4]

RFC 2409                          IKE                      November 1998


   Message encryption (when noted by a '*' after the ISAKMP header) MUST
   begin immediately after the ISAKMP header. When communication is
   protected, all payloads following the ISAKMP header MUST be
   encrypted.  Encryption keys are generated from SKEYID_e in a manner
   that is defined for each algorithm.

3.3 Perfect Forward Secrecy

   When used in the memo Perfect Forward Secrecy (PFS) refers to the
   notion that compromise of a single key will permit access to only
   data protected by a single key. For PFS to exist the key used to
   protect transmission of data MUST NOT be used to derive any
   additional keys, and if the key used to protect transmission of data
   was derived from some other keying material, that material MUST NOT
   be used to derive any more keys.

   Perfect Forward Secrecy for both keys and identities is provided in
   this protocol. (Sections 5.5 and 8).

3.4 Security Association

   A security association (SA) is a set of policy and key(s) used to
   protect information. The ISAKMP SA is the shared policy and key(s)
   used by the negotiating peers in this protocol to protect their
   communication.

4. Introduction

   Oakley and SKEME each define a method to establish an authenticated
   key exchange. This includes payloads construction, the information
   payloads carry, the order in which they are processed and how they
   are used.

   While Oakley defines "modes", ISAKMP defines "phases".  The
   relationship between the two is very straightforward and IKE presents
   different exchanges as modes which operate in one of two phases.

   Phase 1 is where the two ISAKMP peers establish a secure,
   authenticated channel with which to communicate.  This is called the
   ISAKMP Security Association (SA). "Main Mode" and "Aggressive Mode"
   each accomplish a phase 1 exchange. "Main Mode" and "Aggressive Mode"
   MUST ONLY be used in phase 1.

   Phase 2 is where Security Associations are negotiated on behalf of
   services such as IPsec or any other service which needs key material
   and/or parameter negotiation. "Quick Mode" accomplishes a phase 2
   exchange. "Quick Mode" MUST ONLY be used in phase 2.




Harkins & Carrel            Standards Track                     [Page 5]

RFC 2409                          IKE                      November 1998


   "New Group Mode" is not really a phase 1 or phase 2.  It follows
   phase 1, but serves to establish a new group which can be used in
   future negotiations. "New Group Mode" MUST ONLY be used after phase
   1.

   The ISAKMP SA is bi-directional. That is, once established, either
   party may initiate Quick Mode, Informational, and New Group Mode
   Exchanges.  Per the base ISAKMP document, the ISAKMP SA is identified
   by the Initiator's cookie followed by the Responder's cookie-- the
   role of each party in the phase 1 exchange dictates which cookie is
   the Initiator's. The cookie order established by the phase 1 exchange
   continues to identify the ISAKMP SA regardless of the direction the