Current Meeting Report
Slides
2.5.2 IP Security Protocol (ipsec)
NOTE: This charter is a snapshot of the 52nd IETF Meeting in Salt Lake City, Utah USA. It
may now be out-of-date. Last Modified:
02-Nov-01
Chair(s):
Barbara Fraser <byfraser@cisco.com>
Theodore Ts'o <tytso@mit.edu>
Security Area Director(s):
Jeffrey Schiller <jis@mit.edu>
Marcus Leech <mleech@nortelnetworks.com>
Security Area Advisor:
Jeffrey Schiller <jis@mit.edu>
Technical Advisor(s):
Uri Blumenthal <uri@lucent.com>
Mailing Lists:
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
Description of Working Group:
Note: The Technical Advisor has the task to advice on technical
matters related to all the MIB work in this WG.
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 IPSEC working group will restrict itself to the following
short-term work items to improve the existing key management protocol
(IKE) and IPSEC encapsulation protocols:
1. Changes to IKE to support NAT/Firewall traversal
2. Changes to IKE to support SCTP
3. New cipher documents to support AES-CBC, AES-MAC, SHA-2, and
a fast AES mode suitable for use in hardware encryptors
4. IKE MIB documents
5. Sequence number extensions to ESP to support an expanded sequence
number space.
6. Clarification and standardization of rekeying procedures in IKE.
The working group will also update IKE to clarify the specification and
to reflect implementation experience, new requirements, and protocol
analysis of the existing protocol. The requirements for IKE V2 will be
revised and updated as the first step in this process.
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. |
| 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. |
| Oct 01 | | Internet Drafts on NAT and Firewall traversal, IKE MIBs, and requirements for IPsec and IKE for use with SCTP, to working group last call. |
| Oct 01 | | Submit revised Internet-Drafts of NAT and Firewall traversal, IKE MIBs, and SCTP support for considerations as Draft Standards. |
| Nov 01 | | Internet-Drafts on sequence number expansion in IKE, and IKE re-keying completed. |
| Dec 01 | | Internet-Draft on IKE v2 Requirements to working group last call |
| Dec 01 | | Internet-Drafts on AES/SHA-2, sequence number expansion, and IKE re-keying to working group last call. |
| Dec 01 | | Internet-Drafts describing candidate IKE v2 approaches submitted to the working group. |
| Feb 02 | | Submit revised Internet-Drafts on AES/SHA-2, sequence number expansion, and IKE rekeying for consideration as Draft Standards. |
| Apr 02 | | Discuss and select the IKE v2 design from candidate approaches. |
| Sep 02 | | IKE |
| Dec 02 | | Submit |
Internet-Drafts:
Request For Comments:
| 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 |
Current Meeting Report
Minutes of IPSEC wg Meeting, December 2001
These minutes were based off of notes graciously taken and submitted by David Black, from EMC.
Wednesday, December 12, 2001 (15:30 -- 17:30)
Agenda Bashing (Ts'o)
The following agenda was presented and discussed:
Wednesday, December 12, 2001 (15:30 -- 17:30)
* Agenda Bashing (Ts'o)
* SCTP/IPsec draft (Angelos)
* IPSEC over NAT (Dixon)
* IP Storage Security (Aboba)
* AES Cipher document(s) (Herbert / Frankel)
* Revised ESP (Kent)
* IPSEC performance (Angelos)
* Suggested Identity draft (Sommerfeld)
* Transport Mode for Virtual Networks (Touch)
* IKE Implementation Issues (Richardson)
* Son-Of-Ike Requirements (Madson)
Thursday, December 13, 2001 (9:00 -- 11:30)
* JFK proposal (Angelos / Bellovin)
* IKE V2 proposal (Radia / Dan Harkins)
* IKE-SIGMA (Hugo / Bitan)
* Requirements and Comparison of SOI approaches (Kaufman)
* SOI Performance comparison (Rescorla)
* Son-Of-Ike Requirements (Madson)
* Open Mike Period
SCTP/IPsec draft (Angelos Keromytis, Columbia University)
=========================================================
Slides available in postscript.
Angelos gave a description of the issues raised in WG last call. The main issue was to rename ID_RECURSE to ID_LIST for clarity. A new draft will be issued to address this and a few other minor issues, and the document will then be sent to the IESG.
IPSEC over NAT (William Dixon, Microsoft)
The NAT Traversal documents are in last call. There was recently implementation testing among 8 vendors against various NAT devices. What was tested was L2TP in IPsec transport mode and in tunnel mode based on IKE extensions of IKE-CFG/XAUTH or IPSRA DHCP.
The results from this testing revealed some problems. Certificate fragmentation was a major cause of problems. In addition, some devices seem to be looking at IKE cookie states and hence cause NAT traversal not to work.
A list of possible approaches to avoid fragmentation was discussed. Some testers implemented fragmentation avoidance via multiple UDP packets (fragment above UDP to avoid IP fragmenting below UDP). Something will likely need to be done here, since fragmentation will be a real deployment obstacle.
IP Storage Security (Bernard Aboba, Microsoft)
==============================================
Slides available in Powerpoint format.
IP Storage WG has adopted IKE and IPsec as basic security mechanisms. The IPS working group has dependencies on various IPSEC and IPSRA wg I-D's, including IPsec transforms (3DES, HMAC-SHA1, AES-CTR, and AES CBC MAC w/XCBC), and tunnel mode config/auth (draft-ietf-ipsec-dhcp-13.txt - being done in IPSRA WG)
A number of issues are under discussion. Please read draft-ietf-ips-security-06.txt and send comments to the IPS WG mailing list (ips@ece.cmu.edu) or the draft authors (iscsi-security@external.cisco.com).
AES Cipher document(s) (Sheila Frankel, NIST and Howard Herbert, Intel)
Three AES Cipher documents were discussed (one encryption, and two MAC algorithms):
1. AES cipher: CBC with random IV. 128 bit key is mandatory, 192 and 256 are optional, key length attribute is mandatory in IKE Phase 1 and Phase 2. Have suggested DH groups for various AES key lengths, and authors will resolve this with other different key length recommendations (e.g., Hilary Orman's key length comparison draft).
2. HMAC-SHA-256: Motivation is to increase the key space so that rekeying frequency can be reduced. The hash is truncated to 96 bits to avoid packet size changes.
3. AES-XCBC-MAC-96: Problem is that CBC MAC isn't secure for variable length messages. XCBC corrects this and has no patent issues --- do not confuse this with a new proposed "combined" AES confidentiality+integrity mode that does have serious IP issues. Comments from one of the original XCBC authors will be incorporated, test vectors added, and next version of draft is due in January 2002.
Revised ESP (Steve Kent, BBN/Verizon)
=====================================
Steve presented some proposed changes to ESP. The changes had a few clarifications (such as using "integrity" instead of "authentication"), and a number of substantive changes:
* Sequence number extension - This is needed to support higher speed systems, and anticipates AES and its longer lived connections. New sequence numbers are 64 bits, but only 32 bits are carried in each packet. The next version of the draft will have in its appendix a suggestion on how to deal with the rare case where 2^32 packets from one SA are dropped.
* Support for combined modes - New algorithms have emerged that can do integrity and confidentiality in one pass. This requires slight changes to ESP packet format - algorithm has to specify how it checks integrity, as this can't be specified once for all possible combined modes.
* Improved traffic flow confidentiality - only for tunnel mode, most effective between a pair of security gateways. Have expanded the allowed padding (put "junk" behind the IP packet, and encapsulated IP header's length field will automatically cause receiver to ignore the "junk"). Also suggest a convention that the next header field of "59" in the ESP frame be used to indicate that there is no IP packet --- this allows dummy packets to be sent and discarded quickly to obfuscate traffic analysis.
There were some discussions about fragmentation, and whether we can "just say no" to fragments. Steve Kent observed that fragmentation in IPsec has disastrous performance implications, and causes receiver administration issues because port selectors can't be applied to fragments (have to reassemble), which in turn leads to a denial of service vulnerability based on consumption of reassembly resources (e.g., buffers). Also see NAT discussion about other problems caused by fragments.
Several problems with simply getting rid of fragments were raised as the discussion continued:
* Some systems still don't do Path MTU discovery and this is made worse by firewalls that discard ICMP and hence break Path MTU discovery.
* IKE/NAT problem only affects IKE messages that carry certificates. That's a much smaller scope than ESP in general.
* We have no choice but to deal with fragments on reception, as one can't be sure sender send DF or some intermediate system paid attention to it. Not sending fragments is a good idea.
* Some firewalls don't like either fragmentation or ICMP, making the situation impossible as fragments get dropped and Path MTU discovery doesn't work. (Steve Kent observed that if the firewall is broken regardless, we should do the simplest thing in ESP.
Steve then discussed other document revisions which he is planning to do:
* AH - revision early next year based on ESP revisions (e.g., extended sequence numbers)
* Architecture document - revision before Yokohama to simplify processing model, reduce requirements for nested SAs, remove MUST for AH, selector changes (e.g., along lines SCTP needs, plus allow ICMP selectors).
There was a discussion about whether or not the distinction between tunnel and transport modes could be eliminated. Steve Kent responded that the problem is making sure that the right selector checks happen; Joe Touch's VPN draft is a good model to follow. Steve rejected a proposal to remove the tunneling specification from IPSEC, and to simply reference some other specification (such as IP-IP tunnel), on the grounds that encapsulation/decapsulation decision on whether or not to propagate fields have security consequences, and thus need to be made based on local security policy decisions.
IPSEC performance (Angelos Keromytis, Columbia University)
==========================================================
Slides available in postscript format.
Angelos gave a presentation which measured the performance of IPSEC using DES, 3DES, and AES in various scenarios, using both hardware and software implementations.
Suggested Identity draft (Bill Sommerfeld, Sun)
===============================================
Bill Sommerfeld discussed an individual I-D submission (draft-keromytis-ike-id-00.txt) which adds a suggested identity field to the IKE negotiation. This addresses the problem of how to figure out which IKE identity to use when there's more than one. The field is added to initiator's message 5 and HASH_I. Allows initiator to suggest which id responder should use to avoid confusion. This is needed for for User-to-User keying and Responder-initiated rekeying.
Bill would like this to be adopted as a WG draft. He requested that the working group read the I-D and comment on mailing list.
Transport Mode for Virtual Networks (Joe Touch, USC/ISI)
========================================================
Slides are available in Powerpoint and PDF format.
Joe gave a presentation on issues relating to using tunnel-mode IPSEC and hop-by-hop routing. This causes complications because you either need to violate layering one way or another (for example, the routing layer has to update IPSEC configuration as the routing changes).
Joe presented a solution which uses IP-IP encapsulation (RFC 2003) and IPSEC transport mode. The result is syntactically identical to IPSEC tunnel mode, although security checks which are done upon receipt and decapsulation of the packet are different.
Joe then asked the question of how the working group should handle draft-touch-ipsec-vpn-*.txt. Should it become an informational RFC, or a BCP? He also requested that the next revision of RFC2401 require transport mode in gateways and allow the approach which he outlined. He also requested that in the son-of-ike proposals, that tunnel configuration be separated from keying.
There was then a discussion about the order in which key selection and forwarding should be done. The resolution is that having forwarding select a virtual interface and using SPD per virtual interface is allowable by current documents (this is what Joe wants), but the current 2401 text could be clarified.
IKE Implementation Issues (Michael Richardson)
==============================================
Slides available in Postscript format.
Michael Richardson discussed draft-spencer-ike-implementation-00.txt, which documents a number of implementation issues noted by the Free S/WAN developers. The first major issue is whether "unique" IKE message Id's have to be truly unique, or whether they just need to be generated in a pseudo-random fashion, and simply "probably unique". Many implementations do the latter, and the RFC's are ambiguous on this point. Michael would like the RFC's to be changed to make it clear that implementations must keep track of every message id ever issued by an implementation to guarantee uniqueness.
The second issue related to how rekeying phase 2 SA's should be handled, and Michael proposed a scheme where the new Phase 2 SA is starts getting used immediately for transmission as it is negotiated, but the old SA is kept for in-flight messages.
The Draft also contains a bunch of other things about IKE (e.g., pieces of IKE that Free S/WAN didn't implement, and whose absence has not caused interoperability issues).
Son-Of-Ike Requirements (Cheryl Madson, Cisco)
==============================================
Cheryl Madson discussed her I-D, draft-ietf-ipsec-son-of-ike-requirements-00.txt. The goals of this document were to describe the characteristics of an optimal protocol, and to provide scoping by describing the scenarios which the protocol must be able to accommodate. Explicit non-goals were (a) discussing security requirements (which is tough to do in a fashion which is meaningful, but which doesn't favor one proposal or another), and (b) determining the exact split of responsibility between Son-of-Ike and other protocols for the entire set of things that are needed to set up a secure connection.
Cheryl listed the following desirable characteristics:
1. Extensibility. Can't add payloads to IKEv1, as it results in failure of negotiation. Vendor-ID has been used to work around this, but it's not a good solution.
2. Modularity.
3. Improved Convergence. It's too easy for IKEv1 participants to get out of sync with each other (e.g., SA deletion, error conditions)
4. Simplicity, both in terms of overall protocol functionality extent, and ease of accomplishing a particular function.
5. Better discussion/specification of authentication to deal with "IKE requires X.509" myth and remove sources of interoperability problems.
A proposed way of accommodating this would be to allow authentication to be plugged in via companion drafts, while keeping the base draft as simple as possible.
Document currently contains the following scenarios (list is incomplete):
* Site to site VPN
* Remote access
* End to end
* Mobile IP
The working group is asked to review the document, and propose additional scenarios as appropriate.
Thursday, December 13, 2001 (9:00 -- 11:30)
==========================================
JFK proposal (Angelos / Bellovin)
=================================
JFK Design Process - Steve Bellovin, AT&T Labs - Research
---------------------------------------------------------
Slides available in Postscript and PDF format.
Steve Bellovin started by describing the design principles that were used in writing JFK.
The JFK team decided that patching code to preserve IKE is the wrong thing to do - IKE is already too complex, and complexity leads to security bugs. Wanted provable correctness, DoS mitigation, no negotiation. Orthogonal design and clean, well-defined interfaces to cryptographic core. IKEv2 authors have done a great job in simplifying IKE, but the result is still too complex.
Current draft documents only the cryptographic core, if WG views this direction as valuable, a complete version of the draft will be available for Minneapolis.
JFK currently requires certificates. IKE's multiple modes were also removed. Current pre-shared (secret) key approaches are to be replaced with self-signed certificates or IPSRA certificate retrieval. For legacy authentication, IPSRA or KINK should be used.
Phase 1 vs. phase 2 distinction was also removed. This was motivated in part by DES weakness that required frequent rekeying - AES does not have this problem.
The JFK design team is prepared to modify JFK to match developing state of requirements, since the requirements draft is still a work-in-progress.
JFK Protocol - Angelos Keromytis, Columbia University
-----------------------------------------------------
Slides available in Postscript format.
Angelos described the actual details of the JFK protocol. In essence, JFK uses a two round trip protocol. The responder keeps no state between receipt of messages 1 and 3 to avoid denial of service attacks. More details are present in the slides and in JFK I-D. Angelos noted that the draft describes keying a unidirectional SA, but it would be straightforward to key a pair of keys (one for each direction) as IKEv2 does.
One notational error was noted in the slides; there were four exponentials used (g^x, g^y, g^i, and g^r), but there should have been only two exponentials in use. (g^x and g^y should have been g^i and g^j, respectively).
In JFK, the Responder exposes her identity in Message 2, but the Initiator's identity is protected. To protect responder's identity, pick up Hugo Krawczyk and Ran Cannetti's suggestion to incorporate SIGMA ideas into JFK - this protocol is being called LBJ.
4 implementations of JFK are being done by students at Columbia - 2 in Java, 1 in C, 1 in Perl. The Java implementations are interoperating, C and Perl aren't quite there yet. About 3 weeks of student effort so far. C and Perl implementations are running into crypto library issues (e.g., padding is different in different libraries). Converting a JFK implementation to LBJ took a student about a day.
The sizes of the messages are at most a few hundred bytes plus the certificates. Comment: JFK has imperfect forward secrecy. Same D-H exponent used across multiple exchanges with forward secrecy established once that exponent is replaced. Perfect forward secrecy would require state to be kept after receipt of message 1.
Comment: Can IKE payload formats be used? Yes, message format in JFK draft was chosen for expediency and is simpler than IKE's, but can use IKE's payload formats.
Comment: Phase 2 can be useful for more than rekeying, and ability to amortize cost of public key operations is valuable. This needs to be taken up in requirements discussion.
Proof of security is in the works - not completely done yet.
IKE V2 proposal (Radia / Dan Harkins)
=====================================
Slides available in Postscript format.
Most of the work in IKEv2 was in the rest of the stuff that surrounds the cryptographic exchange. IKEv2 also has a 4-message exchange, but this other stuff is at least as important.
The goals of IKEv2 were listed as follows:
* Consolidate RFCs 2407, 2408, and 2409 into a single document.
* No gratuitous changes, but simplify as appropriate (e.g., phase 2 has been kept, now 1 possible phase 1 exchange as opposed to 8 in IKEv1).
* Fix ambiguities and bugs.
* Add flexibility where necessary (e.g., selectors)
* Reduce latency by reducing message count.
* Allow stateless cookies
IKE SA + IPsec SA in established in 4 messages based on public signature keys. Both identities are hidden from passive attackers. Subsequent child SA's require two messages to set up. All messages are request/response, and messages have sequence numbers. Multiple concurrent requests can be issued in parallel.
Version numbers and critical flag defined to enable future changes and extensions, to provide for forward compatibility.
Traffic selectors have been generalized. Responder can narrow ranges.
Cookies (initiator-responder pair) are used to identify IKE SAs.
In IKEv2 SA lifetimes are NOT negotiated. Either side can rekey at any time, and rekeying the IKE SA inherits all of the child SA's. No dangling SA's are allowed. If an unauthenticated ICMP/IKE message raises a suspicion about a dead peer, this is checked by sending a reliable IKE message; if there is no response, the SA is deleted.
The way IKEV2 messages are encrypted and integrity protected is done using the ESP format, but this was simply a reuse of the syntax, and not the protocol. This caused some confusion because some people thought this resulted in a bootstrapping problem, where as it was merely the intention of the document authors to be lazy and not need to reinvent the wheel. The next version of the IKEv2 draft will copy the ESP syntax by value instead of by reference to eliminate this confusion.
IKEv1 has a problem with security parameter negotiation in that each additional parameter to be negotiated results in an exponential explosion of possibilities. To address this, IKEv2 uses a "chinese menu" approach --- i.e., any of these encryption transforms with any of these integrity transforms.
The following comments were made by members of the working group:
* Rekeying IKE SA should use PFS.
* Critical bit on options has been abused to defeat interoperability in other protocols
IKE-SIGMA (Sara Bitan, Technion)
================================
Sara Bitan gave this presentation since Hugo was not able to attend the IETF meeting.
The focus of IKE-SIGMA is crypto design, similar to JFK. Get this right, then add the rest of the structure, which is orthogonal to the core key exchange crypto protocol.
SIGMA supplies full or windowed PFS, identity protection (against active or passive attacks) and DoS resistance. The protocol is flexible to allow choices in these areas.
The presentation was a walk through of the cryptographic thinking that leads to the design of the SIGMA exchanges. Strong binding of identities of the participants to the key exchange is an important theme - leads to a requirement for each sender to MAC its own identity in the protocol. Several variants of SIGMA protocol based on different choices of security properties/features were described.
Requirements and Comparison of SOI approaches (Kaufman)
=======================================================
Slides available in Powerpoint format.
Charlie Kaufman gave a presentation which compared the security properties of the various SOI approaches, as described in the I-D at the time of the meeting.
The differences between the various protocols' security properties can be broken into a number of different areas:
Performance - number of messages, number of exponentiations, size of messages, amount of data that needs processing. There were no major performance difference in computational time among proposed new protocols.
Stateless cookie - defense against computational denial of service attack. This is easy to do with two extra messages. IKEv1 doesn't support this. JFK can piggyback this (no extra messages). SIGMA puts in two extra messages when under attack. IKEv2 can do either.
Identity hiding - again, easy to do with extra messages. Discussion of identity hiding properties, consequences. JFK exposes Bob's identity, no other protocol exposes either identity. JFK and SIGMA as published are subject to polling attacks (poll IP address, discover Bob is there), but IKEv1 and IKEv2 allow Alice to be tricked into revealing her identity - this is a "no-free-lunch" tradeoff as one or the other has to be possible based on who reveals their identity first.
Dead Peer detection - relying on ICMP opens up a denial of service attack based on forging ICMP messages. IKEv2 bans dangling SAs and relies on ping over IKE SA to avoid this. Other protocols don't say anything, but this is also not a problem in practice (yet). Putting ping into ESP and AH may be an alternative.
Plausible Deniability. JFK - can prove that the two named parties intentionally talked to each other. Others can prove that each named party talked to someone. Use of pre-shared key (or IKE encryption key) can make it impossible to ever prove anything.
Parameter Negotiation - seems to be necessary for various reasons. Need to avoid active attack that results in weakened crypto. JFK has Bob choose IKE parameters, will add ESP/AH negotiation later. IKEv2 has same abilities as IKEv1, SIGMA continues IKEv1 approach.
IKEv2 intends to replace RFC 2407, 2408, and 2409. Other two currently supplement them, but JFK intends to get to same level of completeness as IKEv2
SOI Performance comparison (Eric Rescorla)
==========================================
Eric Rescorla gave a presentation which counted the number of messages and cryptographic operations (i.e., D-H key agreement, RSA private key operations, etc.) to give a comparison of the various SOI proposals.
Son-Of-Ike Requirements (Cheryl Madson, Cisco)
==============================================
After the presentation of the SOI proposals, Cheryl Madson returned to lead a continued discussion on the requirements draft. One of the key areas which still needs more effort in the requirements draft is the scenarios description to provide protocol scoping. The individual scenarios need refinement; in addition a model to evaluate the scenario is still needed.
There is also a need to figure out where the homes are for things that IKE will not do that are still important and get those specs done in the same timeframe as Son-of-IKE. If some of this is involved in connection establishment, the state machine specification should accommodate this.
In general, we want minimal message size and count, minimal processing expense (including light-weight devices and restart hit after crash on a large server).
Open Mike Period
================
Jeff Wong (Cisco): Limit amount of policy provisioning in IKE to stuff absolutely required to set up IPsec SA and tunnel (if used). Policy provisioning in general is arbitrarily complex.
Hilarie Orman (Novell/Volera): Move all policy stuff into a separate protocol, e.g., see the IPSRA work.
William Dixon (Microsoft): Scenarios are the most important piece of the requirement discussion.
Cheryl: Want all the help that I can get in this area.
Michael Thomas (Cisco): Most IKE problems are in the mundane protocol operations stuff, not the crypto itself. Recovery from restart avalanches is an important issue in practice today - KINK is in better shape on this than IKE, and needs to be looked to for examples.
Phil Hallam-Baker (Verisign): XKASS is a serious proposal in XML world - may or may not be appropriate for IPsec based on requirements. Need to think about whether credential needs to include identity information, as identity hiding is easy if there's no identity to hide.
Paul Hoffman (VPN Consortium): Transition from and coexistence with IKEv1 in a non-confusing fashion is important.
Steve Bellovin (AT&T Labs Research): Strongly agree that the non-crypto stuff needs attention (Steve is one of the JFK folks).
Cathy Meadows (??): Wants clarity on JFK vs. IKEv2 requirements/philosophies/approaches to SA negotiation.
Steve Bellovin: Can WG please tell us what the requirements are? Absent that, JFK will pursue an approach of "here's what I want" responded to with "Yes" or "No and here's why". Aim is to reduce options/negotiations.
Radia Perlman: IKEv2 follows general approach of IKEv1 with compaction and simplification. Could also follow TLS approach of offering entire suites as opposed to independently negotiating components. Locking down to a single crypto suite seems to be too restrictive.
William Dixon (Microsoft): A real scenario for identity hiding is that Microsoft would not like to reveal that a home PC is owned by MS and used by an MS employee, as hackers are specifically targeting those.
Eric Rescorla (??): Have seen four key exchange protocols and four variants, and they are similar at a high level (e.g., number of round trips). What if we started with the protocol infrastructure and then plugged in the crypto (any of these proposals seems workable)?
Uri Blumenthal (Lucent Bell Labs): Legacy authentication will live on for a long time - please do not limit new algorithm to public key.
Markku Saavla (sp? Siemens): Can we identify scenarios that are out-of-scope in addition to scenarios that we do need to support?
Cheryl: Something like that - scenarios in requirements draft were intended as the "absolutely crucial to support" ones.
Charlie Kaufman (IBM): IKEv2 copied IKEv1 syntax to avoid changing things. JFK picked up a new, cleaner syntax, but this issue is fundamentally a matter of taste. How can we avoid spending too much time in this sort of rathole? Suggests that negotiation approach needs to be resolved early (e.g., reduce everything to a small number of crypto suites, and force things like "vanity crypto" to use vendor payloads).
Cheryl: Use of suites simplifies protocol analysis.
???: Managed IP service provider is concerned about credential management and delivery - need a pre-shared mode of some form, as this is easy to manage. Please consider credential delivery and management as part of Son-of-IKE.
John Ionnadis (??): Split requirements into three categories -
Cryptographic, Operational, and Policy (e.g., negotiation). Pursue these more or less independently and in parallel.
Barbara Fraser (Cisco, co-chair): Yes, something like that is important to structuring the discussion and draft (or drafts). Scenario discussion is also important to this.
Ted Ts'o (IBM, co-chair): Yes, discuss these independently on mailing list and close them independently.
Dan Harkins (??): Would like to delete some of the proposal parsing stuff from IKE (AH and/or ESP and/or IPcomp).
Kathy Meadows (??): Supports this, suggests formal language for expressing proposals.
Jeff Schiller (Security AD): If WG spends too long debating proposals, AD will consider shutting it down. This area is reasonably well-understood and hence coming up with a reasonable solution should happen in short order. WG chairs will be asked to come up with a schedule, and hold WG to it.
Slides
The AES-XCBC-MAC-96 Algorithm and Its Use with IPsec
Overview of IKEv2
Some IPsec Performance Indications
Just Fast Keying (JFK)
SCTP and IPsec
'draft-spencer-ipsec-ike-implementation-01'
AES-Related Drafts
Engineering Trade-offs in Authentication Protocols
IPSec over NAT Testing
ESP v2- What’s New?
IPsec Transport Mode for Virtual Networks
Requirements Discussion
Son of IKE Protocol Reqts
SIGMA: SIGN-and-MAC
Overview of IKEv2
Some IPsec Performance Indications
Just Fast Keying (JFK)
SCTP and IPsec
'draft-spencer-ipsec-ike-implementation-01'