NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01
Barbara Fraser <byfraser@cisco.com>
Theodore Ts'o <tytso@mit.edu>
Jeffrey Schiller <jis@mit.edu>
Marcus Leech <mleech@nortelnetworks.com>
Jeffrey Schiller <jis@mit.edu>
General Discussion:ipsec@lists.tislabs.com
To Subscribe: ipsec-request@lists.tislabs.com
Archive: ftp://ftp.tis.com/pub/lists/ipsec OR ftp.ans.net/pub/archive/ipsec
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.
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. |
· A GSS-API Authentication Method for IKE
· IPsec DOI Textual Conventions MIB
· ISAKMP & IKE Extensions Methods
· Additional ECC Groups For IKE
· ISAKMP DOI-Independent Monitoring MIB
· Content Requirements for ISAKMP Notify Messages
· Fixing IKE Phase 1 & 2 Authentication HASH
· The Candidate AES Cipher Algorithms and Their Use With IPsec
· IKE Authentication Using ECDSA
· More MODP Diffie-Hellman groups for IKE
· On the Use of SCTP with IPsec
· IPsec-NAT Compatibility Requirements
· Negotiation of NAT-Traversal in the IKE
· IPsec over NAT Justification for UDP Encapsulation
· UDP Encapsulation of IPsec Packets
· A Traffic-Based Method of Detecting Dead IKE Peers
· Code-preserving Simplifications and Improvements to IKE
· Security Properties of the IPsec Protocol Suite
RFC |
Status |
Title |
RFC1828 |
PS |
IP Authentication using Keyed MD5 |
RFC1829 |
PS |
The ESP DES-CBC Transform |
RFC2104 |
HMAC: Keyed-Hashing for Message Authentication | |
RFC2085 |
PS |
HMAC-MD5 IP Authentication with Replay Prevention |
RFC2401 |
PS |
Security Architecture for the Internet Protocol |
RFC2410 |
PS |
The NULL Encryption Algorithm and Its Use With IPsec |
RFC2411 |
IP Security Document Roadmap | |
RFC2402 |
PS |
IP Authentication Header |
RFC2412 |
The OAKLEY Key Determination Protocol | |
RFC2451 |
PS |
The ESP CBC-Mode Cipher Algorithms |
RFC2403 |
PS |
The Use of HMAC-MD5-96 within ESP and AH |
RFC2404 |
PS |
The Use of HMAC-SHA-1-96 within ESP and AH |
RFC2405 |
PS |
The ESP DES-CBC Cipher Algorithm With Explicit IV |
RFC2406 |
PS |
IP Encapsulating Security Payload (ESP) |
RFC2407 |
PS |
The Internet IP Security Domain of Interpretation for ISAKMP |
RFC2408 |
PS |
Internet Security Association and Key Management Protocol (ISAKMP) |
RFC2409 |
PS |
The Internet Key Exchange (IKE) |
RFC2857 |
PS |
The Use of HMAC-RIPEMD-160-96 within ESP and AH |
IPsec Working Group Meeting Minutes
[ Minutes compiled from notes taken by Barbara Fraser, John Linn and Geoff Huang.]
Monday, August 6, 2001
Document status/updates
=======================
IPsec MIB doc had a few edits and they'll soon be ready to go to working group last call. The GSSAPI-IKE has a new draft just posted and it should go to wg last call immediately. This will be informational. The other one is the mod-p DH group definitions. Tero said it's ready to go, and it's ready to go to wg last call. We'll move all three of these immediately after the wg.
Motivations for including an IV in AES counter modes
======================================================
Steve Kent presented why you might want to use IV in counter mode. Counter modes offer improved performance. Two counters: per packet and intrapacket counters. System perspective to get a nice number of bits to change each time, and have something you can do on the chip to stay within the current evaluation requirements. No less than 32 bits and may have to bring it up to 64 bits.
AES cipher document
===================
Current status of the AES cipher document was discussed by Sheila Frankel. It's (AES and CBC mode) been around for awhile. There are multiple implementations. They are planning a draft of AES MAC, and there has been interest in a draft for AES SHA.
Son of Ike / Immediate Changes to Ike
=====================================
Ted Ts'o made some opening comments to frame the discussion. Marcus, Jeff, and Steve's note to the list was a restatement of the position they set a year or so ago. The two things that require near term changes to IKE are SCTP compatibility and NAT/Firewall traversal. There haven't been many changes to the SCTP draft and Barbara and Ted will be talking to the editors after the meeting to see how we can move the document forward. NAT/firewall traversal drafts now exist that harmonize the previous drafts. The only problem remaining is AH. The AH part in encapsulation draft is incorrect. Question is do we need AH? About a dozen folks are implementing. Only one person in the room supported including AH, all others were against including AH. This topic will be taken to the list to allow for comment and within 3 weeks we should be able to go to wg last call.
Opportunistic IPSEC
===================
Hugh discussed the opportunistic keying, which is being pursued by the Freeswan project, and discussed in draft-richardson-ipsec-opportunistic-00.txt. It uses secure DNS to discover that two systems have keys out there that can be used for communications. It allows most hosts to communicate opportunistically. Freeswan v 1 came out about a month ago. They don't do any verification of the keys, assuming that's done by DNS-sec.
Matt Blaze asked what the killer argument is for why someone should run this? Answer: A way to get encryption going on the net. Discussion continued on the motivation for using such a protocol. Hugh suggested that we need to get confidentiality deployed and then worry about authorization.
Question asked as to whether most sites can afford it. For example, most people don't stay on a single site for lengthy periods of time. Can most hosts handle the CPU load given that are sites even now that want to use SSL but can't even handle that. Two things that make this difficult: very short transactions.
Another issue is concern that the DNS SEC folks won't be happy about using DNS to pass around keys that are not DNS keys. Bill Sommerfeld responded to the DNS SEC comment saying that they are supporting Secure Shell wg and they also support IPsec. A comment was made that benchmarking showed that IPsec can be a win over SSL, etc. because of the use of kernel space. Comments made supporting the experimental use of this protocol and see what the activity and performance characteristics are.
Tuesday, August 7, 2001
=======================
Clarification of IESG/IAB message
=================================
Last week, Jeff Schiller, Marcus Leech, and Steve Bellovin published a position statement on the ground rules for further development of IKE. Marcus noted that its premises were well known to the Ipsec community, but others took it more critically than was intended. Steve and Marcus stated that no exploitable attacks on IKE are currently known.
The main point that was meant in the position statement: IKE is too complex to analyze and determine whether or not it's bug-free. The intent is not to preclude progression of PIC in IPSRA, but rather to reiterate that IPSRA shouldn't change IKE. The message wasn't anything new; just a reiteration of what's been said for over a year: i.e., that there should be no drastically new changes to IKE. The issue, now, is what needs to be done to address the shortcomings of IKE.
During the brief question and answer period, William Dixon raised a question about unpublished analysis of IPSEC; where they analysis of implementations or the protocol. The answer was that most of the analysis, especially the early ones, such as the one done by Cathy Meadows, focused on the protocol, and in some cases on draft versions of the documents.
Steve Bellovin stated that a complex protocol requires complex implementations, and complex implementations lend themselves to bugs and security problems. He pointed out the majority of CERT advisories are just bugs. Marcus stated that no one has asserted that any particular implementation is known to be insecure; it's just that complex implementations, by nature, tend to have security problems.
Introducing Son-of-Ike Discussion
==================================
Barbara Fraser introduced the discussion by making the following observations: IPSec is entering a new phase, looking into IKE based on experience to filter requests into design requirements for how to move forward. It is premature to judge whether to modify or replace IKE. The two proposals to be discussed subsequently are proposed first steps in this direction. Open mike discussion will need to be followed up on the mailing list.
Improving IKE
=============
Improving IKE (Radia Perlman): The primary goal is simplification, that's code-preserving where possible, but also considering improvements. The draft is a summary of a paper co-authored with Charlie Kaufman (url available in the draft).
Proposals:
*) Remove aggressive mode, rather than expecting users to choose between main and aggressive and reducing the number of sub-protocols. Either identity hiding is important, or it isn't; removing aggressive mode would remove half the protocol.
*) Remove public-key encryption variants, leaving signature modes; among other reasons, they're less likely to be escrowed, few will have encryption keys without signature keys, and everyone knows their signature keys before performing any protocol. This further reduces the set of sub-protocols.
*) Allow stateless cookies, as provided in Photuris but not preserved in IKE.
*) More compact parameter negotiation than possible in ISAKMP, with smaller number of negotiation proposals.
*) Fix main mode preshared key operation, or remove preshared keys
*) Remove Phase 2? This is recognized as a more contentious suggestion. If there aren't to be a lot of Phase 2s, amortizing a smaller number of Phase 1s, it's more efficient to combine the phases.
*) Invert identity protection, hiding originator's rather than target's identity. The target's identity is generally less important to keep secret, since the identity is usually know due to a fixed IP address.
*) Additional suggestion: SSL-like unidirectional authentication or strong password-based authentication (e.g., EKE).
Implementation Cleanups
=======================
Andrew Krywaniuk presented some protocol cleanup proposals from an implementors perspective. Primary concern: Don't destroy the existing code base.
Andrew doesn't believe we should remove phase 2. However, he believes that Phase 2 PFS is superfluous given phase 1. The commit bit may also not be necessary. We should adopt Tero's revised authentication hash.
Rekeying has been a major operational problem, since it's unspecified in the documents, and people try to do it in different ways.
We need to clarify the use of certificate request/vendor ID payloads.
Things which Andrew believes we should add include: Dead peer detection, replay protection into phase 2 exchange, distributed denial of service attack protection, and Reliable notification messages.
Open Mike
=========
Matt Blaze noted that he and his team is still working on Just Fast Keying (JFK). It should be ready for presentation by the next IETF.
Various people noted that if we are creating a new protocol, or even modifying an existing one, we need to be clear about defining requirements and scope. (Who knew when we started that a protocol like iSCSI would want to use IPSEC?)
A number of commentors (Steve Kent, HI, William Dixon) agreed that paring down the IKE feature list would be a good thing. Besides simplifying implementations, it improves the likelihood of interoperability.
David Black from the iSCSI working group noted that iSCSI was sensitive to roundtrip counts, and so he thought aggressive mode might be needed. Howard from Intel noted that iSCSI would require fast rekeying, since with 10GB wire speed, rekeying might need to happen after 5 minutes.
There was discussion both in favor and against preserving existing implementations. Some people believe it was important; others did not. Ted Ts'o noted that at the previous IETF meeting, a straw poll was taken, and a clear majority at that time believed that code preservation was important. At the end of the open mike session, another straw poll was taken; this time a clear majority (45) believed that code preservation was NOT important. Approximately 15 people believed that code preservation was important. Interestingly, these percentages were almost exactly reversed in Minneapolis.
None received.