The IPSEC working group met on Tuesday, December 9th, 1997, at the IETF meeting in Washington, D.C.
The Agenda was as follows:
The following items were added to the agenda:
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, to be published 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.
There are currently 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.
Dan Harkins from Cisco and Naganand Doraswamy from Bay Networks presented a proposal for a multicast key management, MKMP. Slides of their presentation are available.
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.
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 agrees. 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.
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.
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.
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 interopability sessions, other vendors are stepping up to sponsor these activities. Other interoperability session is being planned for mid-Febuary; Cisco as offered facilities for this session.
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.
Back to the IPSEC resources page.