[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01                                                         
IPSEC Working Group
INTERNET-DRAFT
NEC                                                     Shigeyoshi Shima
Expires in six months from                                  July,31 1998





          ISAKMP Certificate Key Exchange Type Specification
              <draft-shima-ipsec-isakmp-cke-type-00.txt>





Status of This Document


   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of 6 months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   To learn the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za(Africa), ftp.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
   ftp.isi.edu (US West Coast).



Abstract

   This document defines a new key exchange type of ISAKMP that reduce
   the number of transmission and encrypt message contents from first
   transmission.
   The Certificate Key Exchange is effective since it does not use
   Diffie-Hellman key exchange algorithm but public key cryptography.
   The Certificate Key Exchange use certificates as authentication
   information. Please send comments on this document to the
   ipsec@tis.com.









S.Shima                                                         [Page 1]


INTERNET-DRAFT                                             July 31, 1998



Table of Contents

      Status of This Document ...................................1

      Abstract ..................................................1
      Table of Contents .........................................2

      1.  Introduction ..........................................2
      2.  Definitions ...........................................3
          2.1. Certificate ......................................3
          2.2. Certification Authority ..........................3
      3.  Certificate Key Exchange ..............................4
          3.1. Overview .........................................4
          3.2. ISAKMP Exchange Type Field .......................4
          3.3. Notation .........................................5
          3.4. Certificate Key Exchange Type ....................5
      4.  Security Considerations ...............................7

          Reference .............................................8
          Acknowledgments .......................................8
          Editor's Address ......................................8



1. Introduction

   The IPSEC Working Group of the IETF has defined some key management
   protocols (ISAKMP, IKE, SKIP etc), which are used for the
   establishment of Security Association of AH (Authentication Header)
   and ESP (Encapsulation Security Payload Header). This document
   particularly describes about ISAKMP.

   ISAKMP is based on Diffie-Hellman key exchange algorithms as a key
   establishment method between hosts. Never the less, ISAKMP does not
   guarantee correct correspondence between the host and the public key
   used for Diffie-Hellman key exchange algorithms. If a host continues
   to use an unguaranteed public key with Diffie-Hellman key exchange
   algorithms, a cracker can wiretap message contents between hosts
   after gaining unauthorized access to the host and obtain the public
   key of the host. The public key cryptography has a similar problem.
   This problem is generally settled through the third party with CA.
   CA issue certificates to hosts. Certificates are guaranteed to
   correspond the host and the public key with certificates if the host
   verifies them. Only the host, which corresponds to the public key,
   can access message contents if the message is encrypted with the
   public key.

   This document defines the Certificate Key Exchange type as a new




S.Shima                                                         [Page 2]


Internet Draft                                             July 31, 1998


   ISAKMP Key Exchange type [ISAKMP], which uses a public key
   certificate. The Certificate Key Exchange does not use Diffie-Hellman
   key exchange algorithms but public key cryptography, which has an
   encryption and a signature mechanism. Therefore, the host can apply
   to both key exchange and encryption of a message at the first
   transmission, before the host shares secret information with a pair
   of host.


2. Definitions

2.1. Certificate

   For the contents of certificates that IPsec use, refer to
   [IPSEC-CERT]. [IPSEC-CERT] defines processes for handling IPsec
   certificates, including fulfillment, retrieval, validation, and
   management, to realize the
   IPsec certificate.

   o IPsec-aware devices have requirements to retrieve and to share
     certificates and CRLs.

   o There are two means of certificate exchange for IPsec devices

     1. Two IPsec devices exchange certificate information through
        a combination of out-of-band operations and IKE payload
        messages.

     2. IPsec devices may use PKIX protocols or other mechanisms
        such as LDAP or HTTP to retrieve PKI information.

   o This certificate is used to identify an IPsec entity with the
     IKE protocol and is based on the X.509 format {X.509], which
     contains the public key, cryptography algorithm information,
     and naming information.


2.2. Certification Authority (CA)

   CAs generally have mechanisms for generation, verification,
   revocation, management and distribution of certification as
   described in section 2.1.

   It is assumed that there exists multiple CAs on the Internet, with
   each belonging to an organization and an area and some of them
   forming a CA hierarchy. There are two types of CA; CA to issue
   certificates to hosts and CA to issue certificates to other CAs.
   Since a host obtains a CA certificate by off-line or through
   installation of software before the host communicates on the
   network, the host relies on the CA certificate.



S.Shima                                                         [Page 3]


Internet Draft                                             July 31, 1998


3 Certificate Key Exchange

3.1 Overview

   Key Exchange Types of ISAKMP can't encrypt a message from first
   transmission. The AGGRESSIVE Exchange Type of ISAKMP can encrypt a
   message from first transmission, if the host send a message in
   advance to share secret information with a pair of host.

   In the Certificate Key Exchange, the host can create an encrypted
   message with the public key using public key cryptography. The
   encrypted message can only be decrypted by a host which has the
   secret key. Since correspondence of the host and the public key
   of the responder is certified by a CA, the initiator verifies the
   responder's certificate with the CA certificate, then the initiator
   make an encrypted message with the public key of the responder in
   the responder's certificate.

   The Certificate Key Exchange can reduce the number of transmissions
   in the key exchange, since a common key (secret) and identification
   related information can be set to payloads from first transmission.
   For example, in comparison with the BASE Key Exchange and the
   IDENTITY PROTECTION Key Exchange the number of transmissions in the
   Certificate Key Exchange is fewer, and in comparison with the
   AGGRESSIVE Key Exchange, the number of transmissions is the same.

   In the Certificate Key Exchange it is possible to detect masquerade
   faster than with other types. In the case of the BASE Key Exchange,
   masquerade is detected after finishing the key exchange with
   Diffie-Hellman key exchange algorithms, while in the case of the
   Certificate Key Exchange they are detected at start point of the key
   exchange.

   The details of the Certificate Key Exchange will be explained in 3.4.


3.2 ISAKMP Exchange Field

   This section defines a new type of Exchange field for a ISAKMP
   header; the Certificate Key Exchange, which is assigned the value
   six(6).

   In the Certificate Key Exchange, the Key Exchange payload is set to
   ISAKMP packet of the first message before the all payloads and the
   common key of the Key Exchange payload is used for encryption and
   decryption of payloads. Therefore 4 as the Key Exchange payload(KE)
   MUST be set to payload type value of the ISAKMP Header MUST be set
   to 4 as the Key Exchange payload (KE).





S.Shima                                                         [Page 4]


Internet Draft                                             July 31, 1998


                       ____Exchange_Type______Value___
                        NONE                    0
                        Base                    1
                        Identity Protection     2
                        Authentication Only     3
                        Aggressive              4
                        Informational           5
                        Certificate             6 (New)
                        ISAKMP Future Use     7 - 31
                        DOI Specific Use     32 - 255


3.3 Notation

   The following notation is used throughout this draft.

   HDR is an ISAKMP header whose exchange type defines the payload
   orderings
      SA is an SA negotiation payload with one or more Proposal and
         Transform payloads. An initiator MAY provide multiple
         proposals for negotiation; a responder MUST reply with only
         one.
      KE is the key exchange payload.
      IDx is the identity payload for "x". x can be: "ii" or "ir"
          for the ISAKMP initiator and responder, respectively, or x
          can be: "ui", "ur" (when the ISAKMP daemon is a proxy
          negotiator), for the user initiator and responder,
          respectively.
      HASH is the hash payload.
      SIG is the signature payload. The data to sign is exchange-
          specific.
      AUTH is a generic authentication mechanism, such as HASH or SIG.
      NONCE is the nonce payload.
      CERT is the certificate payload.
      '( )*' signifies ISAKMP header and payloads in ( ) encryption
          with Common Key Cryptography.
      '**' signifies payload encryption with Public Key Cryptography.
           This encryption is generally used for KE.

      => signifies "initiator to responder" communication (requests).
      <= signifies "responder to initiator" communication (replies).


3.4 Certificate Key Exchange

   The Certificate Key Exchange is designed to allow the Security
   Association, Key Exchange, Nonce, Identification, and Certificate
   payloads to be transmitted together. The following diagram shows
   messages with possible payloads sent in each message and notes
   regarding an example of Certificate Exchange.



S.Shima                                                         [Page 5]


INTERNET DRAFT                                              July 31, 1998


                          CERTIFICATE EXCHANGE

_#______Initiator____Direction_____Responder______________________NOTE____________________

(1)  HDR; KE**; (SA      =>                       Begin ISAKMP-SA or Proxy negotiation
     NONCE; IDii; CERT)*                            and Key Exchange
(2)                      <=     HDR; KE**; (SA
                                NONCE; IDir; AUTH)*
                                                  Initiator Identity Verified by Responder
                                                  Key Generated
                                                  SA agreed upon
(3)  (HDR; AUTH)*
                                                  Responder Identity Verified by Initiator
                                                  SA established


   In the first message (1), It assume that the initiator already
   finished verifying the responder's certificate. The initiator
   generates a Proposal payload considered adequate to protect traffic
   in the preceding sessions. The Security Association, Proposal, and
   Transform payloads are included in the Security Association payload
   (for notation purposes). The initiator generates the common key to
   encrypt other payloads, such as SA, NONCE, IDx, and CERT, sets the
   Key Exchange payload to it, and encrypts the payload with the public
   key in the responder's certificate. Random information which is used
   to guarantee liveness and protect against replay attacks is also
   transmitted. Additionally, the initiator transmits identification
   information. The initiator can obtain the public key, public key
   cryptography attribute, and common key cryptography attribute with
   the responder's certificate. The initiator encrypts Security
   Association, Proposal, Transform, Nonce, Identification, and
   Certificate payloads with the generated common key. Since the ISAKMP
   Header is not encrypted with the public key, hosts prevented from
   wasting computation capacity by Denial of Service Attacks. The
   responder confirms that the header and payloads are data of the
   Certificate key Exchange and decrypts the Key Exchange payload with
   the secret key of the responder since the ISAKMP Header contains Key
   Exchange information. The responder decrypts other payloads with
   the common key that is set to Key Exchange Payload.

   In the second message (2), the responder indicates the protection
   suite that was accepted with the Security Association, Proposal, and
   Transform payloads. The initiator generates a common key to encrypt
   other payloads, such as SA, NONCE, IDx, and CERT, sets the Key
   Exchange payload to it, and encrypts the payload with the public key
   in the responder's certificate. Random information which is used to
   guarantee liveness and protect against replay attacks is also
   transmitted. Random information provided by both parties SHOULD be
   used by the authentication mechanism to provide shared proof of
   participation in the exchange. Additionally, the responder transmits



S.Shima                                                         [Page 6]


INTERNET DRAFT                                             July 31, 1998


   identification information. This information is transmitted under the
   protection of the agreed upon authentication function.
   The initiator encrypts Security Association, Proposal, Transform,
   Nonce, and Identification payloads as well as authentication
   information with the generated common key. Local security policy
   dictates the action of the responder if no proposed protection suite
   is accepted.  One possible action is the transmission of a Notify
   payload as part of an Informational Exchange. The initiator confirms
   that the header and payloads are the Certificate key Exchange data
   and decrypts the Key Exchange payload with the secret key of the
   initiator since the ISAKMP Header has the Key Exchange information.
   The initiator decrypts other payloads with the common key that is
   set to the Key Exchange payload.

   In the third message (3),  the initiator transmits the results of the
   agreed upon authentication function.  This information is transmitted
   under the protection of the common shared secret.  Local security
   policy dictates the action if an error occurs during these messages.
   One possible action is the transmission of a Notify payload as part
   of an Informational Exchange.


4.  Security Considerations

   This entire draft is based on the ISAKMP draft on security and
   discusses a new type of ISAKMP Key Exchange. If the Certificate Key
   Exchange applies to the following Internet-Drafts, it improves
   security and efficiency.

   1. Storing Certificates in the Domain Name System [DNSSEC-CERT]

   This document describes a mechanism whereby a CERT resource record
   (RR) is defined so that certificate and certificate revocation lists
   can be conveniently stored in the Domain Name System(DNS).
   The secure DNS distributes IPsec CA certificates
   to the host. The host can securely and efficiently obtain IPsec
   certificates.

   2. Key Exchange Delegation Record for the DNS [RFC2230]

   This document describes a mechanism whereby authorization for one
   node to act as key exchanger for a second node is delegated and made
   available via the Secure DNS.  This mechanism is intended to be used
   only with the Secure DNS.  It can be used with several security
   services. If the host wants to find the trusted CA, secure DNS can
   record access point of the correct CA on the network.







S.Shima                                                         [Page 7]


INTERNET DRAFT                                              July 31,1998


Reference

   [ISAKMP] D. Maughan, M. Schertler, M. Schneider, J. Turner,
            "Internet Security Association and Key Management
            Protocol", draft-ietf-ipsec-isakmp-09

   [IPSEC-CERT] Rodney Thayer, "PKI Processing Requirements for IP
                security", draft-thayer-ipsec-pki-00.txt

   [X.509] ITU-T Recommendation X.509 (1197 E):
           Information Technology - Open Systems Interconnection -
           The Directory: Authentication Framework

   [DNSSEC-CERT] Donald E. Easrlake 3rd olafur Gudmudsson,
                 "Storing Certificares in the Domain Name System",
                 draft-ietf-dnssec-cert-02.txt

   [RFC2230] R. Atkinson, "Key Exchange Delegation Record
             for the DNS", rfc2230.txt



Acknowledgments

    This document is the result of close consultation with Mine Sakurai,
    Takao Miyabe, and Shiuji Ishii. We would also like to thank the
    members of NEC Internet Technology Laboratories.


Editor's Address

     Shigeyoshi Shima
     shima@ccs.mt.nec.co.jp
     NEC Corporation
     +81 (03) 5476-1107


   The IPSec working group can be contacted via the IPSec working
   group's mailing list (ipsec@tis.com) or through its chairs:

     Robert Moskowitz
     rgm@icsa.net
     International Computer Security Association

     Theodore Y. Ts'o
     tytso@mit.edu
     Massachusetts Institute of Technology






S.Shima                                                         [Page 8]