NOTE: This charter is a snapshot of the 42nd IETF Meeting in Chicago, Illinois. It may now be out-of-date. Last Modified: 23-Jul-98
Chair(s):
Theodore Ts'o <tytso@mit.edu>
Robert Moskowitz <rgm@icsa.net>
Security Area Director(s):
Jeffrey Schiller <jis@mit.edu>
Marcus Leech <mleech@nortel.ca>
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 OR ftp.ans.net/pub/archive/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 Interenet-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 Interent-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
· The Internet Key Exchange (IKE)
· The Internet IP Security Domain of Interpretation for ISAKMP
· Implementation of Virtual Private Network (VPNs) with IP Security
· 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 DES-XEX3-CBC Transform
· IP Encapsulating Security Payload (ESP)
· 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
· The NULL Encryption Algorithm and Its Use With IPsec
· The Pre-Shared Key for the Internet Protocol
· A DH-less encryption mode for IKE
· A Framework for Group Key Management for Multicast Security
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 |
Chicago IETF (August, 1998) IPsec Working Group Meeting Minutes
The WG met on Tuesday at the IETF meeting in Chicago, from 14:15 to 15:15.
Approximately 120 people attended. This was MBONE broadcast.
The Agenda was:
* Workgroup status
* Workshop announcement
* Charter revision
* Discovered problems with Ipsec/IKE based on current implementation experience ---
Lifetime discussion
* ICMP messages, standardized error codes, and MIBs
* Policy/tunnel endpoint discovery
* Policy-based Security Management
Workgroup status
Ted gave a report on the status of the IPSEC working group. The full suite of Internet
Drafts have been approved by the IESG. They are currently being processed by the
RFC editor and should be published shortly. It is now time to revisit the IPSEC charter
since we have met almost all of the goals and milstones in the original charter.
Workshop announcement
Microsoft will be sponsoring an IPSEC interoperability testing workshop in Redmond
on Aug 31 -- Sep 3rd. Approximately 20-25 companies have signed up for the workshop.
William Dixon (wdixon@microsoft.com) is the contact person for this workshop.
IBM is also sponsoring another round of interoperability testing in Binghamtom, NY
on October 27--30. This test will also include L2TP. The $300 fee has been waived
by IBM.
Charter revision
Bob Moskowitz led a discussion on new items for work goals for revising the charter.
These items included:
* address errors and improvements; errata to be maintained on MIT web site
* add functionality
* remote client support
* policy and tunnel endpoint discovery (Bill Simpson votes to remove, since this is a
complex non-security issue already being dealt with elsewhere)
* complex tunnel management
* ICMP messages, error codes, MIBs
* Additional algorithms
* IPsec over non-IP protocols (IPX? "Running shoes?")
* Key recovery: excluded to the sound of cheers and hisses
* Integration of IPsec and certificate frameworks, DNSsec
* Cleaning up the host-host (non-VPN) case; not sure what's missing
* results implemented from Secure Multicast IRTF activity
The working group chairs will compose a new proposed charter based on these
suggestions, and present it to the working group.
Lifetime discussion
Although there is a default value established for Phase 2 lifetimes, there is no similar
default for Phase 1 lifetimes. There is unfortunately is conflicting interpretations
regarding how to proceed in the absence of an explicitly specified PHase 1 lifetime.
There is an optional notification facility, but it's unclear what happens if the notified
value ins't acceptable. There is an interoperability impact caused by this
underspecification. (This will need to be corrected in a protocol errata.)
ICMP messages, standardized error codes, and MIB's
Michael Richardson gave a presentation on a two problems which he has been
concentrating on. One is the issue of Path MTU discovery across a IPSEC tunnel;
which could be ignored in IPV4, but not in IPV6. (Since IPV6 drops packets greater
than the MTU, instead of fragmenting them; on the other hand, the IPV6 minimum
MTU is also much bigger, so perhaps the problem can be ignored).
The other area of concern is ICMP messages and IPSEC, to support diagnostic tools
such as traceroute and PING.
Policy/tunnel endpoint discovery
Roy Perieira has some drafts forthcoming which will cover IPSEC policy and tunnel
endpoint discovery issues. These include how a new machine on the network
bootstraps itself by obtaining its first policy, and secure route discovery in the face of
complex topologies and multiple secure paths for load-balancing and/or redundancy.
Policy-based Security Management
Luis Sanchez gave a presentation on some Security Policy Management going on at BBN.
(Slides included)
Policy Based Security Management for IPSec