One document matched: draft-ietf-ipsec-isakmp-SA-revised-00.txt
IP Security working group Baiju V. Patel,
Internet Draft Michael Jeronimo,
Intel Corp.
Document: draft-ietf-ipsec-isakmp-SA-revised-00.txt
November, 1997
Revised SA negotiation mode for ISAKMP/Oakley
Status of this Memo
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 six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a
"working draft" or "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 ds.internic.net, nic.nordu.net, ftp.isi.edu, or
munnari.oz.au.
A revised version of this draft document will be submitted to the
RFC editor as a Proposed Standard for the Internet Community.
Discussion and suggestions for improvement are requested. This
document will expire before February 1998. Distribution of this
draft is unlimited.
1. Abstract
ISAKMP/OAKLEY [2][3] is the key management protocol defined by IPSEC
working to be a framework for authentication, security association
negotiation and key management. The protocol defines two phases
whereby, in the phase 1, the peers are authenticates, the security
association (SA) for ISAKMP/Oakley, and keying material is agreed
upon by the peers to secure ISAKMP messages. The phase 2 is used to
negotiate security association for security applications (e.g.,
IPSEC AH and ESP). When perfect forward secrecy is required, phase 2
is also used to exchange keying material for the application.
However, when perfect forward secrecy is not a requirement, the
keying material from the phase 1 is used to generate session keys
for the secure communication applications.
The proposal in this document is based on the observation that when
perfect forward secrecy is not a requirement, if application
Patel 1
draft-ietf-ipsec-isakmp-SA-revised-00.txt 11/21/97
specific SA was negotiated during phase 1, the application can start
immediately after phase 1. The phase 2 can be used subsequently for
key refresh on per need bases in the future. Therefore, this
proposal reduces startup time for communication and improves the
efficiency of the protocol.
Remark: This document is NOT self-contained, it is intended as an
addendum to [2][3]. Thus, it is best read in conjunction with
[2][3].
2. Revised modes of ISAKMP/Oakley
2.1.
Notation
SA_App: is an SA negotiation payload with one or more proposals
specific to the application (e.g., IPSEC AH or ESP),
SA_App_p: is the entire body of the SA_App payload (minus the ISAKMP
generic header) -- i.e., the DOI, situation, all proposals, and all
transforms included in SA_App.
HASH_I =
prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | Sap | SA_App_p | IDii)
HASH_R =
prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAp | SA_App_p | IDir)
Observe that the HASH-I and HASH-R functions in this revised mode
include application specific SA's. This a change from the
specification in [3].
Unless otherwise specified, all the notations used in this document
are same as those in [3].
2.2.
Phase 1 authenticated with Signatures
Main Mode with signature authentication is described as follows:
Initiator Responder
---------- -----------
HDR, SA -->
<-- HDR, SA
HDR, KE, Ni -->
<-- HDR, KE, Nr
HDR*, IDii, SA_App [ CERT, ] SIG_I -->
<-- HDR*, IDir, [ CERT, ] SIG_R
Aggressive mode with signatures in conjunction with ISAKMP is
described as follows:
Initiator Responder
----------- -----------
HDR, SA, SA_App, KE, Ni, IDii -->
Patel and jeronimo 2
draft-ietf-ipsec-isakmp-SA-revised-00.txt 11/21/97
<-- HDR, SA, SA_App, KE, Nr,
IDir, [ CERT, ] SIG_R
HDR, [ CERT, ] SIG_I -->
2.3.
Phase 1 Authenticated With Public Key Encryption
When using encryption for authentication, Main Mode is defined as
follows.
Initiator Responder
----------- -----------
HDR, SA -->
<-- HDR, SA
HDR, KE, [ HASH(1), ]
<IDii>PubKey_r,
<Ni>PubKey_r -->
HDR, KE, <IDir>PubKey_i,
<-- <Nr>PubKey_i
HDR*, SA_App, HASH_I -->
<-- HDR*, SA_App, HASH_R
Aggressive Mode authenticated with encryption is described as
follows:
Initiator Responder
----------- -----------
HDR, SA, SA_App, [ HASH(1),] KE,
<IDii>Pubkey_r,
<Ni>Pubkey_r -->
HDR, SA, SA_App, KE,
<IDir>PubKey_i,
<-- <Nr>PubKey_r, HASH_R
HDR, HASH_I -->
Where HASH(1) is a hash (using the negotiated hash function) of
the certificate which the initiator is using to encrypt the nonce
and identity.
2.4. Phase 1 Authenticated With a Pre-Shared Key
When doing a pre-shared key authentication, Main Mode is defined
as follows:
Initiator Responder
---------- -----------
HDR, SA -->
<-- HDR, SA
HDR, KE, Ni -->
<-- HDR, KE, Nr
HDR*, SA_App IDii, HASH_I -->
<-- HDR*, SA_App, IDir, HASH_R
Patel and jeronimo 3
draft-ietf-ipsec-isakmp-SA-revised-00.txt 11/21/97
Aggressive mode with a pre-shared key is described as follows:
Initiator Responder
----------- -----------
HDR, SA, SA_App, KE, Ni, IDii -->
<-- HDR, SA, SA_App, KE, Nr, IDir, HASH_R
HDR, HASH_I -->
3. Security Considerations
This draft defines a security protocol.
4. References
[1].
Bradner, S, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, Harvard University, March 1997.
[2].
Maughhan, D., Schertler, M., Schneider, M., and Turner, J.,
"Internet Security Association and Key Management Protocol
(ISAKMP)", version 8, draft-ietf-ipsec-isakmp-08.{ps,txt}.
[3].
D. Harkins, D. Carrel, "The resolution of ISAKMP with
Oakley", Internet Draft, <draft-ietf-ipsec-isakmp-oakley-04.txt>,
July 1997
[4].
Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997.
[5].
Schneier, B., "Applied Cryptography, Protocols, Algorithms,
and Source Code in C", 2nd edition.
5. Acknowledgments
This draft is largely based on the Dan Harkin's IETF draft on
ISAKMP/OAKLEY resolution.
6. Author's Addresses
Baiju V. Patel
Intel Corp
2511 NE 25th Ave
Hillsboro, OR 97124
Phone: 503 264 2422
Email: baiju@mailbox.jf.intel.com
Michael Jeronimo
Intel Corp
2511 NE 25th Ave
Hillsboro, OR 97124
Phone: 503 264 5970
Email: jeronim@ccm.jf.intel.com
Patel and jeronimo 4
draft-ietf-ipsec-isakmp-SA-revised-00.txt 11/21/97
Patel and jeronimo 5
| PAFTECH AB 2003-2026 | 2026-04-23 04:21:12 |