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

Chair(s):

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-isakmp-05.txt,

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

draft-ietf-ipsec-isakmp-oakley-00.txt

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

draft-ietf-ipsec-skip-07.txt

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:

Done

  

Post as an Internet-Draft the IP Security Protocol.

Done

  

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

Done

  

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

Done

  

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

Done

  

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

Done

  

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.

Done

  

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

Done

  

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.

Internet-Drafts:

Request For Comments:

RFC

Status

Title

 

RFC1828

PS

IP Authentication using Keyed MD5

RFC1826

PS

IP Authentication Header

RFC1825

PS

Security Architecture for the Internet Protocol

RFC1827

PS

IP Encapsulating Security Payload (ESP)

RFC1829

PS

The ESP DES-CBC Transform

RFC2104

  

HMAC: Keyed-Hashing for Message Authentication

RFC2085

PS

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

IPSECOND Issues

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.

VI. MIB

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]

VIII. IPSECOND Scoping

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.

Slides

Multicast Key Management Protocol
Old Versus New Selectors

Attendees List

go to list

Previous PageNext Page