2.6.5 IP Security Protocol (ipsec)

NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 01-Nov-97


Theodore Ts'o <tytso@mit.edu>
Robert Moskowitz <rgm3@chrysler.com>

Security Area Director(s):

Jeffrey Schiller <jis@mit.edu>

Security Area Advisor:

Jeffrey Schiller <jis@mit.edu>

Mailing Lists:

General Discussion:ipsec@tis.com
To Subscribe: ipsec-request@tis.com
Archive: ftp://ftp.tis.com/pub/lists/ipsec

Description of Working Group:

Rapid advances in communication technology have accentuated the need for security in the Internet. The IP Security Protocol Working Group (IPSEC) will develop mechanisms to protect client protocols of IP. A security protocol in the network layer will be developed to provide cryptographic security services that will flexibly support combinations of authentication, integrity, access control, and confidentiality.

The protocol formats for the IP Authentication Header (AH) and IP Encapsulating Security Payload (ESP) will be independent of the cryptographic algorithm. The preliminary goals will specifically pursue host-to-host security followed by subnet-to-subnet and host-to-subnet topologies.

Protocol and cryptographic techniques will also be developed to support the key management requirements of the network layer security. The Internet Key Management Protocol (IKMP) will be specified as an application layer protocol that is independent of the lower layer security protocol. The protocol will be based on the ISAKMP/Oakley work begun in:


draft-ietf-ipsec-oakley-01.txt, and


A follow on work item may incorporate mechanisms based on SKIP as defined in:


and related documents. Flexibility in the protocol will allow eventual support of Key Distribution Centers (KDC), such as are used by Kerberos.

Goals and Milestones:



Post as an Internet-Draft the IP Security Protocol.



Post as an Internet-Draft the specification for Internet key management.



Submit the Internet Key Management Protocol to the IESG for consideration as a Proposed Standard.



Conduct initial interoperability testing of Encapsulating Security payload (ESP) and Authentication Header (AH).



Submit revised Internet-Drafts for ESP, AH, and IP Security Architecture.



Submit revised Internet-Drafts of IP Security Architecture, ESP, and AH to the IESG for consideration as Draft Standards.

Dec 96


Submit revised Internet-Drafts of IP Security Architecture, ESP, and AH to the IESG for consideration as Draft Standards.



Submit Internet-Draft of the Internet Key Management Protocol (IKMP) based on ISAKMP/Oakley to the IESG for consideration as a Proposed Standard.



Submit Internet-Draft of Internet Key Management Protocol to the IESG for consideration as a Proposed Standard.

Jul 97


Submit IKMP to IESG for consideration as a Draft Standard.


Request For Comments:







IP Authentication using Keyed MD5



IP Authentication Header



Security Architecture for the Internet Protocol



IP Encapsulating Security Payload (ESP)



The ESP DES-CBC Transform



HMAC: Keyed-Hashing for Message Authentication



HMAC-MD5 IP Authentication with Replay Prevention

Current Meeting Report

Minutes of the IP Security Protocol (ipsec) Working Group

The IPSEC working group met on Tuesday, December 9th, 1997, at the IETF meeting in Washington, D.C. The Agenda was as follows:

Agenda Review 1545-1550
Results of Document Reading Party 1550-1620
Next Steps on Documents 1620-1630


Multicast key management 1630-1645
Policy management 1645-1705
Tunnel Management 1705-1710
MIB 1710-1715
IANA Registration 1715-1720
IPSECOND Scoping 1720-1735

The following items were added to the agenda:

SSH ISAKMP test web page
Next workshop
SecureID Draft Convergence

I. Results of the Document Reading Party

Bob Moscowitz reviewed the procedure which we followed the previous night to review the documents.

In total, approximately 25-30 people attended, and split up into teams to review sets of two or three documents, checking for consistency amongst the set of the documents, as well as problems internal to the documents. Notes from the various teams were collected for publication to the IPsec mailing list.

A large number of issues that were identified were related to the Architecture document, and Stephen Kent presented those issues in his presentation. (Slides to be included in the minutes.)

II. Next Step on Documents

Currently, there is a set of 12 documents. Document editors will make another last set of changes, ask for comments to the list, and we will be entering last call on the documents very shortly.

III. Multicast Key Management

Dan Harkins from Cisco and Naganand Doraswamy from Bay Networks presented a proposal for a multicast key management, MKMP.

MKMP is intended to provide scalable and secure distribution of multicast keys. It assures liveness, key doesn't cross wire (even encrypted), except on rekey operation. Routers do not need join secure multicast group, and it is independent of underlying m-cast routing. MKMP uses IPsec to secure multicast traffic and ISAKMP/Oakley-type messages for KM. MKMP-aware routers can become Group Key Distributors; the Group Information Tuple enforces access and delegates key distribution authority. Uses an ALL-MKMP-BOXES group. Key acquisition is separate from group join. To create a secure group, group key manager creates key, list of candidate key distributors, and access control info. Periodic key distributor solicitations sent to multicast group address; if message reaches candidate group key distributor, it obtains key from group key manager using key distribution protocol. Only routers already on the distribution tree become GKDs. Next steps are to clean up and issue draft MKMP specification. MKMP may require a separately chartered WG, but won't be considered by IESG until current IPsec docs passed.

IV. Policy Management

Policy means different things to different people. It was referenced in the original documents, but there was only modest support in the protocols. Does there need to be a protocol to support policy management? Straw poll indicates a modest number of people agree. Someone pointed out that there is ongoing work in this area within the Radius group. Others are concerned that this is not purely a protocol issue, and that policy management may not be well understood enough for us to design a protocol, let alone standardize it. BBN has some on-going work in this area. IBM also is doing some work in describing policies within LDAP. Note: this area can be an unbounded research topic unless strict requirements are used to bound the problem.

V. Tunnel Management

There have been several drafts that have been submitted on this topic. There is some overlap between tunnel management and the work in the VPN BOF. Someone from Timestep commented that we must understand what we want to accomplish, we must do this in a standard way so that we don't have all these proprietary methods to configure.


There's not much to say about MIB's, except that one is required for elevation to Draft Standard. (Since we will be elevating the current drafts to Proposed Standard, this is not an immediate issue.) Rodney Thayer and Uri Blumenthal are interested in working on this.

VII. IANA Registration

Rodney is looking into the requirements for IANA registrations; we need to specify procedures for allocating algorithm identifiers for the future. [Note: after the meeting, I have learned that we need to this before we the drafts go to the IESG. This is an issue which can't wait for IPSECOND. --- Ted]


Ted then led a brain-storming session about future work items which should be included in the IPSECOND work. The following items were identified by the working group as being additional items follow-on work should consider:

IX. ISAKMP Test Web Page

Tero Kivinen gave a presentation of an ISAKMP test web page which has been made available by SSH Communications Security in Finland. The URL for the web page is: "http://isakmp-test.ssh.fi/". All of the popular algorithms are available. For demonstration purposes can be used to test against itself.

In answer to questions about future interoperability sessions, Bob Moscowitz indicated that while the ANX (as a customer) was not intending to sponsor any further interoperability sessions, other vendors are stepping up to sponsor these activities. Other interoperability session is being planned for mid-February; Cisco as offered facilities for this session.

X. Secure ID and ISAKMP

Roy Pereira from TimeStep had published an ISAKMP/SecurID integration I-D shortly before the meeting. There is another I-D written by New Oak as well. The authors are planning to align the drafts.


Multicast Key Management Protocol
Old Versus New Selectors

Attendees List

go to list

Previous PageNext Page