Skip to main content

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

Document Type Expired Internet-Draft (ipsec WG)
Expired & archived
Authors Dr. Baiju V. Patel , Michael Jeronimo
Last updated 1997-12-04
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status (None)
Formats
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state Expired
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:

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

Dr. Baiju V. Patel
Michael Jeronimo

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