datatracker.ietf.org
Sign in
Version 5.3.0, 2014-04-12
Report a bug

Revised SA negotiation mode for ISAKMP/Oakley
draft-ietf-ipsec-isakmp-SA-revised-00

Document type: Expired Internet-Draft (ipsec WG)
Document stream: IETF
Last updated: 1997-12-04
Intended RFC status: Unknown
Other versions: (expired, archived): plain text, pdf, html

IETF State: WG Document
Consensus: Unknown
Document shepherd: No shepherd assigned

IESG State: Expired
Responsible AD: (None)
Send notices to: No addresses provided

This Internet-Draft is no longer active. Unofficial copies of old Internet-Drafts can be found here:
http://tools.ietf.org/id/draft-ietf-ipsec-isakmp-SA-revised

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 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].

Authors

Baiju Patel <baiju.v.patel@intel.com>
Michael Jeronimo <jeronim@ccm.jf.intel.com>

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid)