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:
· Internet Security Association and Key Management Protocol (ISAKMP)
· The OAKLEY Key Determination Protocol
· The ESP Triple DES Transform
· Security Architecture for the Internet Protocol
· IP Authentication Header
· The resolution of ISAKMP with Oakley
· The Internet IP Security Domain of Interpretation for ISAKMP
· Inline Keying within the ISAKMP Framework.
· Implementation of Virtual Private Network (VPNs) with IP Security
· The ESP RC5-CBC Algorithm
· The ESP CAST128-CBC Algorithm
· A revised encryption mode for ISAKMP/Oakley
· The ESP DES-CBC Transform
· IP Security Document Roadmap
· The Use of HMAC-SHA-1-96 within ESP and AH
· The Use of HMAC-MD5-96 within ESP and AH
· The ESP DES-CBC Cipher Algorithm With Explicit IV
· ESP with Cipher Block Chaining (CBC)
· The ESP ARCFOUR Algorithm
· The ESP DES-XEX3-CBC Transform
· The ESP Blowfish-CBC Algorithm Using an Explicit IV
· The ESP 3DES-CBC Algorithm Using an Explicit IV
· The ESP IDEA-CBC Algorithm Using Explicit IV
· IP Encapsulating Security Payload (ESP)
· The ESP CAST5-128-CBC Transform
· The ESP CBC-Mode Cipher Algorithms
· The ISAKMP Configuration Method
· The Use of HMAC-RIPEMD-160-96 within ESP and AH
· A GSS-API Authentication Mode for ISAKMP/Oakley
· Dynamic remote host configuration over IPSEC using DHCP
· Revised SA negotiation mode for ISAKMP/Oakley
· Extended Authentication Within ISAKMP/Oakley
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 |
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:
· agenda discussion moved to mailing list
· question about SNMP
· "I have a solution" guy draft: draft-ietf-firewallmib-19.txt?
· JI: IPsec currently good for vpns and remote access; several efforts in other groups to secure individual protocols. How can we take out the security done in other protocols, and make them use IPsec?
· Dan McDonald (Sun's IPsec guy): being good for vpn's isn't the way it was designed, this is how it was implemented
· Eric Rescorla: using IPsec may not be feasible for application protocols, even though you may be able to use IPsec key management for them
· disa guy: suggests focusing exclusively on IPv6
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