Internet DRAFT - draft-shin-pki4ipsec-ixc
draft-shin-pki4ipsec-ixc
Pki4ipsec Working Group Yongtae Shin
Internet-Draft Sangchul Son
Expires: May 10, 2006 Kwangkyum Lee
ICN LAB of Soongsil UNIV
Jongwon Choe
Sookmyung UNIV
October 2005
Appling PKI for The Initial Exchange in IKE
draft-shin-pki4ipsec-ixc-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 six 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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on may 10, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
This document is describes version 1 of the Internet Key Exchange
Protocol. IKE is a component of IPSec used for performing mutual
authentication and establishing and maintaining security associations
(SAs).
Initial exchange information during IKE Processing must be protected
with PKI.
Shin&Son&Lee&Choe Expires May 10, 2006 [Page 1]
Internet-Draft Appling PKI for The Initial Exchange in IKE October 2005
Table of Contents
1.Introduction......................................................1
2.Exchanges in IKE..................................................1
3.Phase 1 Authenticated With Public Key Encryption..................4
4.About Diffie-Hellman..............................................5
5.The Initial Exchange with Public Key Encryption in IKE ...........5
Security Considerations ............................................7
Reference ..........................................................7
Author's Addresses .................................................8
1. Introduction
IP Security (IPSec) provides confidentiality, data integrity, access
control, and data source authentication to IP datagrams.
These services are provided by maintaining shared state between the
source and the sink of an IP datagram. This state defines, among
other things, the specific services provided to the datagram, which
cryptographic algorithms will be used to provide the services, and
the keys used as input to the cryptographic algorithms.
This document is Apply to the initial exchange in IPSec with PKI.
2. Exchanges in IKE
There are two basic methods used to establish an authenticated key
exchange: Main Mode and Aggressive Mode. Each generates authenticated
keying material from an ephemeral Diffie-Hellman exchange. Main Mode
MUST be implemented; Aggressive Mode SHOULD be implemented.
In Addition, Quick Mode MUST be implemented as a mechanism to
generate fresh keying material and negotiate non-ISAKMP security
services.
In addition, New Group Mode SHOULD be implemented as a mechanism to
define private groups for Diffie-Hellman exchanges. Implementations
MUST NOT switch exchange types in the middle of an exchange.
Exchanges conform to standard ISAKMP payload syntax, attribute
encoding, timeouts and retransmits of messages, and informational
messages-- e.g a notify response is sent when, for example, a
proposal is unacceptable, or a signature verification or decryption
was unsuccessful, etc.
The SA payload MUST precede all other payloads in a phase 1 exchange.
Except where otherwise noted, there are no requirements for ISAKMP
payloads in any message to be in any particular order.
The Diffie-Hellman public value passed in a KE payload, in either a
phase 1 or phase 2 exchange, MUST be the length of the negotiated
Diffie-Hellman group enforced, if necessary, by pre-pending the value
with zeros.
Shin&Son&Lee&Choe Expires May 10, 2006 [Page 2]
Internet-Draft Appling PKI for The Initial Exchange in IKE October 2005
The length of nonce payload MUST be between 8 and 256 bytes
inclusive.
Main Mode is an instantiation of the ISAKMP Identity Protect
Exchange: The first two messages negotiate policy; the next two
exchange Diffie-Hellman public values and ancillary data (e.g.
nonces) necessary for the exchange; and the last two messages
authenticate the Diffie-Hellman Exchange.
The authentication method negotiated as part of the initial ISAKMP
exchange influences the composition of the payloads but not their
purpose. The XCHG for Main Mode is ISAKMP Identity Protect.
Similarly, Aggressive Mode is an instantiation of the ISAKMP
Aggressive Exchange. The first two messages negotiate policy,
exchange Diffie-Hellman public values and ancillary data necessary
for the exchange, and identities. In addition the second message
authenticates the responder. The third message authenticates the
initiator and provides a proof of participation in the exchange.
The XCHG for Aggressive Mode is ISAKMP Aggressive. The final message
MAY NOT be sent under protection of the ISAKMP SA allowing each party
to postpone exponentiation, if desired, until negotiation of this
exchange is complete. The graphic depictions of Aggressive Mode show
the final payload in the clear; it need not be.
Exchanges in IKE are not open ended and have a fixed number of
messages. Receipt of a Certificate Request payload MUST NOT extend
the number of messages transmitted or expected.
Security Association negotiation is limited with Aggressive Mode.
Due to message construction requirements the group in which the
Diffie-Hellman exchange is performed cannot be negotiated.
In addition, different authentication methods may further constrain
attribute negotiation. For example, authentication with public key
encryption cannot be negotiated and when using the revised method of
public key encryption for authentication the cipher and hash cannot
be negotiated. For situations where the rich attribute negotiation
capabilities of IKE are required Main Mode may be required.
Main Mode, Aggressive Mode, and Quick Mode do security association
negotiation. Security Association offers take the form of Transform
Payload(s) encapsulated in Proposal Payload(s) encapsulated in
Security Association (SA) payload(s). If multiple offers are being
made for phase 1 exchanges (Main Mode and Aggressive Mode) they MUST
take the form of multiple Transform Payloads for a single Proposal
Payload in a single SA payload. To put it another way, for phase 1
exchanges there MUST NOT be multiple Proposal Payloads for a single
SA payload and there MUST NOT be multiple SA payloads. This document
does not proscribe such behavior on offers in phase 2 exchanges.
Shin&Son&Lee&Choe Expires May 10, 2006 [Page 3]
Internet-Draft Appling PKI for The Initial Exchange in IKE October 2005
There is no limit on the number of offers the initiator may send to
the responder but conformant implementations MAY choose to limit the
number of offers it will inspect for performance reasons.
During security association negotiation, initiators present offers
for potential security associations to responders. Responders MUST
NOT modify attributes of any offer, attribute encoding excepted.
If the initiator of an exchange notices that attribute values have
changed or attributes have been added or deleted from an offer made,
that response MUST be rejected.
Four different authentication methods are allowed with either Main
Mode or Aggressive Mode-- digital signature, two forms of
authentication with public key encryption, or pre-shared key.
The value SKEYID is computed seperately for each authentication
method.
3. Phase 1 Authenticated With Public Key Encryption
Using public key encryption to authenticate the exchange, the
ancillary information exchanged is encrypted nonces. Each party's
ability to reconstruct a hash (proving that the other party decrypted
the nonce) authenticates the exchange.
In order to perform the public key encryption, the initiator must
already have the responder's public key. In the case where the
responder has multiple public keys, a hash of the certificate the
initiator is using to encrypt the ancillary information is passed as
part of the third message. In this way the responder can determine
which corresponding private key to use to decrypt the encrypted
payloads and identity protection is retained.
In addition to the nonce, the identities of the parties (IDii and
IDir) are also encrypted with the other party's public key. If the
authentication method is public key encryption, the nonce and
identity payloads MUST be encrypted with the public key of the other
party. Only the body of the payloads are encrypted, the payload
headers are left in the clear.
Shin&Son&Lee&Choe Expires May 10, 2006 [Page 4]
Internet-Draft Appling PKI for The Initial Exchange in IKE October 2005
When using encryption for authentication, Main Mode is defined as
follows.
Initiator Responder
----------- -----------
HDR, SA -->
<-- HDR, SA
HDR, KE, [ HASH(1), ]
<IDii_b>PubKey_r,
<Ni_b>PubKey_r -->
HDR, KE, <IDir_b>PubKey_i,
<-- <Nr_b>PubKey_i
HDR*, HASH_I -->
<-- HDR*, HASH_R
4. About Diffie-Hellman
Diffie-Hellman requires two parties to interact to derive keying
information which can then be used for authentication. Since DNS SIG
RRs are primarily used as stored authenticators of zone information
for many different resolvers, no Diffie-Hellman algorithm SIG RR is
defined. For example, assume that two parties have local secrets "i"
and "j". Assume they each respectively calculate X and Y as follows:
X = g**i ( mod p ) Y = g**j ( mod p )
They exchange these quantities and then each calculates a Z as
follows:
Zi = Y**i ( mod p ) Zj = X**j ( mod p )
shared secret between the two parties that an adversary who does not
know i or j will not be able to learn from the exchanged messages
unless the adversary can derive i or j by performing a discrete
logarithm mod p which is hard for strong p and g).
The private key for each party is their secret i (or j). The public
key is the pair p and g, which must be the same for the parties, and
their individual X (or Y).
5. The Initial Exchange with Public Key Encryption in IKE
Communication using IKE always begins with IKE_SA_INIT and IKE_AUTH
exchanges (known in IKEv1 as Phase 1). These initial exchanges
normally consist of four messages, though in some scenarios that
number can grow. All communications using IKE consist of
request/response pairs. We'll describe the base exchange first,
followed by variations. The first pair of messages (IKE_SA_INIT)
negotiate cryptographic algorithms, exchange nonces, and do a Diffie-
Hellman exchange.
Shin&Son&Lee&Choe Expires May 10, 2006 [Page 5]
Internet-Draft Appling PKI for The Initial Exchange in IKE October 2005
The second pair of messages (IKE_AUTH) authenticate the previous
messages, exchange identities and certificates, and establish the
first CHILD_SA. Parts of these messages are encrypted and integrity
protected with keys established through the IKE_SA_INIT exchange, so
the identities are hidden from eavesdroppers and all fields in all
the messages are authenticated.
In the following description, the payloads contained in the message
are indicated by names such as SA. The details of the contents of
each payload are described later. Payloads which may optionally
appear will be shown in brackets, such as [CERTREQ], would indicate
that optionally a certificate request payload can be included.
The initial exchanges are as follows:
Initiator Responder
----------- -----------
HDR, SAi1, KEi, Ni -->
HDR contains the SPIs, version numbers, and flags of various sorts.
The SAi1 payload states the cryptographic algorithms the initiator
supports for the IKE_SA. The KE payload sends the initiator's
Diffie-Hellman value. Ni is the initiator's nonce.
<-- HDR, SAr1, KEr, Nr, [CERTREQ]
The responder chooses a cryptographic suite from the initiator's
offered choices and expresses that choice in the SAr1 payload,
completes the Diffie-Hellman exchange with the KEr payload, and sends
its nonce in the Nr payload.
At this point in the negotiation each party can generate SKEYSEED,
from which all keys are derived for that IKE_SA. All but the headers
of all the messages that follow are encrypted and integrity
protected. The keys used for the encryption and integrity protection
are derived from SKEYSEED and are known as SK_e (encryption) and SK_a
(authentication, a.k.a. integrity protection). A separate SK_e and
SK_a is computed for each direction. In addition to the keys SK_e
and SK_a derived from the DH value for protection of the IKE_SA,
another quantity SK_d is derived and used for derivation of further
keying material for CHILD_SAs. The notation SK { ... } indicates
that these payloads are encrypted and integrity protected using that
direction's SK_e and SK_a.
HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,]
AUTH, SAi2, TSi, TSr} -->
The initiator asserts its identity with the IDi payload, proves
knowledge of the secret corresponding to IDi and integrity protects
the contents of the first message using the AUTH payload. It might
also send its certificate(s) in CERT payload(s) and a list of its
Shin&Son&Lee&Choe Expires May 10, 2006 [Page 6]
Internet-Draft Appling PKI for The Initial Exchange in IKE October 2005
trust anchors in CERTREQ payload(s). If any CERT payloads are
included, the first certificate provided MUST contain the public key
used to verify the AUTH field. The optional payload IDr enables the
initiator to specify which of the responder's identities it wants
to talk to. This is useful when the machine on which the responder is
running is hosting multiple identities at the same IP address. The
initiator begins negotiation of a CHILD_SA using the SAi2 payload.
The final fields (starting with SAi2) are described in the
description of the CREATE_CHILD_SA exchange.
<-- HDR, SK {IDr, [CERT,] AUTH,
SAr2, TSi, TSr}
The responder asserts its identity with the IDr payload, optionally
sends one or more certificates (again with the certificate containing
the public key used to verify AUTH listed first), authenticates its
identity and protects the integrity of the second message with the
AUTH payload, and completes negotiation of a CHILD_SA with the
additional fields described below in the CREATE_CHILD_SA exchange.
The recipients of messages 3 and 4 MUST verify that all signatures
and MACs are computed correctly and that the names in the ID payloads
correspond to the keys used to generate the AUTH payload.
Security Considerations
The focus of this document is security; hence security considerations
permeate this specification.
Reference
1 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
2 Piper, D., "The Internet IP Security Domain Of
Interpretation for ISAKMP", RFC 2407, November 1998.
3 D. Harkins, "The Internet Key Exchange" (RFC 2409) November 1998
4 R. Housley, "Internet X.509 Public Key Infrastructure Certificate
and CRL Profile" (RFC 2459) January 1999
5 Charlie Kaufman, "Internet Key Exchange (IKEv2) Protocol"
September 2004
Shin&Son&Lee&Choe Expires May 10, 2006 [Page 7]
Internet-Draft Appling PKI for The Initial Exchange in IKE October 2005
Author's Addresses
Yongtae Shin
Room 422 Information Science B/D,
Soongsil University Sangdo5-dong
Dongjak-gu Seoul, 156-743,
South Korea
Email: shin@cherry.ssu.ac.kr
Sangchul Son
Room 402 Information Science B/D,
Soongsil University Sangdo5-dong
Dongjak-gu Seoul, 156-743,
South Korea
Email: yelhorse@cherry.ssu.ac.kr
Kwangkyum Lee
Room 402 Information Science B/D,
Soongsil University Sangdo5-dong
Dongjak-gu Seoul, 156-743,
South Korea
Email: goodwin77@cherry.ssu.ac.kr
Jongwon Choe
Room 410A Information Science B/D,
Sookmyung University Hyochangwon St.52
Yongsan-gu Seoul, 140-742,
South Korea
Email: choejn@sookmyung.ac.kr
Shin&Son&Lee&Choe Expires May 10, 2006 [Page 8]
Internet-Draft Appling PKI for The Initial Exchange in IKE October 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Shin&Son&Lee&Choe Expires May 10, 2006 [Page 9]
