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]