Last Modified: 2003-01-22
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.
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-Drafts on AES/SHA-2, sequence number expansion, and IKE re-keying to working group last call. | |
DEC 01 | Internet-Draft on IKE v2 Requirements 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 |
RFC | Status | Title |
---|---|---|
RFC1829 | PS | The ESP DES-CBC Transform |
RFC1827 | PS | IP Encapsulating Security Payload (ESP) |
RFC1828 | PS | IP Authentication using Keyed MD5 |
RFC1826 | PS | IP Authentication Header |
RFC1825 | PS | Security Architecture for the Internet Protocol |
RFC2104 | I | 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 | I | IP Security Document Roadmap |
RFC2402 | PS | IP Authentication Header |
RFC2412 | I | 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 Minutes March 2003 IETF, San Francisco, CA Recorded by: Jesse Walker 1. Agenda bashing Agenda accepted without change. 2. A word from the ADs Russ Housley: Let's get it done. Oscillating on mail list. If it is in document, don't change it unless it is breaking something. 3. Draft status Barbara Fraser: modp group completed last call, RFC editor queue aes xcbc-mac completed last call, waiting for IESG aes-cbc completed last call, waiting for AD writeup sctp completed, kicked back from IESG, but they had wrong version; being rereviewed ESP, 2402bis esn ready for last call nat traversal ready for last call MIB documents ready for last call, but can't find them Dead Peer Detection document ready for last call IKEv2 coming to closure? IKEv2 tutorial 4. Update on ESP, AH, 2401 Steve Kent: ESP & AH changes: revised identification text to better accommodate multicast; clarified anti-replay requirements for multicast; moved discussion of when to use tunnel and transport mode to 2401bis Q: Remove mandatory algorithm references from AH & ESP? No response. SA identification: unicast, SPI is sufficient. Multicast: should support demuxing based on SPI & dest addr, optionally use source addr too. Now SAD flags to cover unicast and multicast: SPI only, SPI + destination addr, SPI + dest addr + src addr Q: What about protocol field in multicast case? Anti-replay: transmitter always increments; receiver can ignore it. Receiver should tell transmitter to ignore seq counter wrap-around if not going to perform anti-replay check. 2401bis: reconciling with IKEv2 selector, relaxing specs on when to use tunnel v. transport; add forwarding/routing lookup prior to SPD lookup. Q: remove mandatory algorithm references? Comment: Forwarding lookup also must return next hop address. Q: Ready for last call? Comment: If aligning 2401bis with IKEv2, does this mean it won't work with IKEv1? Answer: There are new SPD entries can't negotiate with IKEv1. Comment: That is a real issue. Since adding lots of valuable things, it might behoove us to find a way to construct an IKEv1 profile. Answer: it's ESP/AH that are ready to move forward, not 2401bis. 5. High Level Interop There was a miscommunication between the working group chairs. This topic should not have been on the agenda. 6. Backend Config Payload handling Greg Lebovitz/Darren Dukes (Darren presents): Use backend server to assign IP address. IRAC Config Problem -- IPsec remote access client needs private IP address before creating child SAs. How? Config Payload -- allow config payload to do this. Put config payload in IKE-AUTH exchange messages 3 and 4. Can backend with your favorite server. On-IRAS Pools -- not scalable but work for small deployment Off-IRAS Pools -- offload onto backend server; scales better: use DHCP, RADIUS or other backend server Requirements: be able to use DHCP, RADIUS and LDAP to get addresses. Question: Not suggesting changes to IKEv2? Answer: No, augments IKEv2 using IKEv2 mechanisms. 7. IKE DHCP encapsulation Michael Richardson: Requirements: no new namespaces, provide client with info it needs; minimize # of exchanges; interfaces to existing infrastructure; preserves end-to-end security of DHCP; permit independent DHCP evolution. Three methods: DHCP-over-IPsec; ModeCFG over IKE; proposed DHCP over IKE DHCP-over IPsec: product of IPSRA; easy for bump-in-stack, all-in-one gateway; leverages existing DHCP server ModeCFG: occurs in IKE msg 3, uses custom payload; if you need DHCP info, do it over IPsec; easy to interface to RADIUS/COPS/DHCP Why bother? DHCP the defacto standard; don't reinvent DHCP-over-IKE v. over IPsec: creating 0/0 tunnel is hard when crypto offloaded; client systems without virtual i/fs cannot do this easily; may have to leave 0/0 SA around for renewals DHCP-over-IKE v. ModeCFG: same as DHCP-over-IKE, except format bits; ModeCFG needs an IKE 1.5 exchange; DHCP-over-IKE preserves client-server security; extensible; plugs into RADIUS/COPS with mini-DHCP server/proxy; talks to real DHCP server with no glue 8. IKEv2 issues Ted Ts'o: Posted open issues last call to determine how far away from getting IKEv2 out the door. Time to shoot the engineers and ship the product: if not broken, don't fix; some recently introduced problems should be remanded to an IKEv2 extensions WG; otherwise will suffer scope creep What's left: AH and ESPbis; 2401bis; then we can shut down! Want to finish this year. Issues recently resolved: Secure legacy authentication; cipher suites document needed--Jeff Schiller has volunteered; Hugo's key derivation objections; suites v. a la carte; Charlies question about IKE suite #5. Issues recently discussed (no closure): Multiple tunnels for QoS; multiple tunnels for outsourced VPNs; mobility peer address management; kill me-Tarzan-you-Jane; revised identity; DHCP v. config payload. Outsourced VPNs: is this important to handle now? Solutions exist that require no changes to the draft Mobility peer addr mgmt: support for changing IP addresses during SA lifetime. Important now? assertion: move this into separate WG. Comment: Defect in current draft about IP address. Can move this to another WG. Charlie: if clarifications to existing text, please send suggested text and section changes apply to. Comment: Combine NAT traversal, mobility? Ted: Don't see how the two are related. Comment (Mark Duffy): Include VPN ID in IKEv2. Within PPP have ways to discover identities of VPN members. VPN ID will facilitate this within IPsec. Comment: Suites v. a la carte: no idea what to do to support legacy combinations that aren't in a defined suite. Can't use IKEv2 with these. Want to auto-upgrade configuration, but can't. Response: It will have to be allowed to use both suites and a la carte. We will leave IKEv1 customers as IKEv1 until they can upgrade. Comment (Dan Harkins): Will have to double suites because no way to indicate PFS. Ted: Don't understand. Comment: If we go with suites, consider what other WGs have called out as mandatory to implement. Comment (Charlie Kaufman): You can identify suite you want with vendor ID if single vendor; if multiple vendors want this, then they can ask for this to be added to suites document. Diffie-Hellman group is part of the suite. Comment: Let's propose suite for every combination possible in IKEv1. Comment (Paul Hoffman): Everyone in IKEv1 has GUI that lets them pick what they want. No consistent defaults. People are really using DES, because it is mandatory to implement in IKEv1. Upgrade cannot be direct, because we won't support DES going forward. Comment: Need more active discussion on peer addresses than just a few comments, or we won't handle the problem. Comment (Radia Perlman): Curious whether there is passion behind suites? Charlie: Only losing side shows up. Ted: 80% of room in Atlanta wanted suites. Charlie: heard requirement to negotiate any combination in IKEv1. Russ: Charlie's story: two bales of hay and a donkey. Donkeys are not too dumb not to decide which to eat from. Comment: WG list came to consensus with a la carte suites. VPNID is just another name, and we don't need to do anything about it. Just agree upon a name; just use them. Comment: (Paul Hoffman) 80% people speaking did not support suites, but the vote was 80%. Developers more evenly split on a la carte. Comment: v1 has a la carte, and it ain't broke Comment: What happened to discussion about GUIs? Charlie: Asked a la carte party which a la carte they want. The question of "ands" and "ors" has to be addressed. Changing is tiresome. There is always consensus we can make it better Uri: main reason to have a la carte is it is simpler. main reason to have suites is it is analyzable. This is the main reason to select a la carte. Comment: In the protocol define as a la carte but draft 3 suites. This gives benefits of both. 3 is the right number for interoperability testing. Charlie: Can do this; a la carte text is escrowed. Ted: We don't want to debate this one. Current draft: 5; some form of a la carte: 25; some form of a la carte in v2 '02 draft v v1 encoding scheme: unanimous in favor of v2 '02. Ted: we need to lock this decision in stone. Ted: Want consensus that we won't do QoS, outsourced VPN, mobility support in a new WG. Everyone agrees. 9. Kill off me-Tarzan-you-Jane: argument for: initiator id sufficient to demux multiple VPNs. Comment: But this is not a problem for VPNs. It is a problem for end-to-end use. Don't know what it means to remove it. Comment: Right. Keep me-Tarzan-you-Jane, because useful outside of VPN. Comment: But do we need two different payloads to do same thing? What we need to kill off is optional ID payload. Comment: No. The way the initiator wants to refer to responder identity might not be a raw key. Better to use identity name space rather than key name space. Need to keep identity across key roll-over. Comment: Can't use CERTREQ with anything other than PKIX signing certs. Comment: But then why do we have these other types? Comment: Other types need to be specified; no semantics for them. Comment: Can express remote identity by certificate you want to receive. You will get that certificate. We will always do this, so always pass certificate chains. We won't get the performance optimization we thought. We need a bit saying whether the ID payload refers to requestor or responder. Requirement to specify remote end is a non-negotiable requirement. CERTREQ is for getting certs. This is premature optimization. Charlie: There is confusion. Me-Tarzan-You-Jane solves one problem, but people try to solve other problems, but doesn't work there, so want to remove it. If you don't use it to solve the wrong problem, it is fine and shouldn't be used. Comment (Derek Atkins): Keep what's there. Comment (Dan Harkins): Payload is not non-critical. It is a mandatory option. The problem it solves is never stated. Ted: How many believe current language be kept? Removed? Don't care? Vote was to keep it. If you want it clarified, send text to Charlie. 10. Revised identity Is there anything left to do? Paul Hoffman: Charlie clarified when to send cert. Only open issue is to define what identity means. Do we want to clarify this? Comment: Tarzan-Jane discussion arose because of no identity notion. Comment: We don't know how to build certificates for IKE. We can't change PKIX. Does ID payload contents need to match something in CERT payload? Can solve this problem with one sentence. Need to make this explicit to close this issue. Charlie: Devil is in details. Yes they have to match, but we don't know what matching means. Ted: In Kerberos, you specify name, ticket, and access control check. This problem is never addressed in Kerberos. Similarly in SSH. Because of Cert structure, people think they don't have to check access control list but rather only check some magical field in cert. Interop problems arise from this. Draft haven't done this. Paul: Can't decide this in IKEv2 timeframe. Let's defer it. Comment: Don't want to go through same as last 4 years. Comment: There are implementations that check ACL. Name is just a hint to find right key. People are looking for way to contact random machine and make decisions. Steve Kent: Agree with Paul; too complicated to get resolved. There is an ACL; it is the SPD. Problem people run into is we haven't nailed down SPD syntax well enough to remove these problems. Intent was precisely to establish entries in form that cert will map to SPD entries. This is a 2401bis problem Comment: Two issues: access policy, which is user's decision. Interoperability problems because of configuration. Not trying to solve these problems which is protocol interoperability. What we need to insure is protocol interoperability: do you have to match something in cert to something in ID payload or not. Comment: Try: "after you have authenticated the dude on the other end, you MUST decide whether this matches the access control criteria on your end." Comment: Deal with this in 2401bis. Short term solution is to say that what goes in ID v CERT payload is a local matter for now. It need not match. Comment: SO we will put in sentence that ID payload is for policy lookup and does not need to match anything in CERT payload. Both fields may be used for access control decisions, but need not be correlated. 2-1 in favor. Steve Kent: Don't think this clarifies anything, other than allows a vendor to claim compliance. It doesn't solve the problem. Ted: alternate proposal? Paul Hoffman: Do this on the list. What implementers claim their implementations do doesn't match debug log. Comment: We have opened can of worms best closed on list. 11. DHCP v. CFG payload Summary: Both solutions are technically workable. IKEv2-05 allows server to refuse CFG request and uses fallback to 3456bis. DHCP encapsulation within IKE recent submission. DHCP encapsulation might be suitable compromise, but not fleshed out. If consensus in WG to pursue this new idea, give them limited time, then decide to fallback to IKEv2-05. If people want 3456bis, give people short time to produce text, otherwise fall back to IKEv2-05 CFG payload. 5 or 6 happy with current, 3 or 4 unhappy. Comment: growth of DHCP indicates configuration is a hard problem; let someone solve it. That speaks to just reusing DHCP. Don't reinvent the wheel; just use DHCP. Pursue this with a reasonable timeout with fallback. Comment: CFG payload has fallback mechanism built in for implementations that want to do something else. Keep CFG payload as is to allow DHCP or whatever else. Comment: Getting into trouble with IPv6. Already have several, creating yet another one. Comment: DHCP INFORM gives options not given by CFG payload. This would satisfy problems. Yeah; we do need to think more about v6. Comment: Makes sense to give DHCP 3 weeks to flesh out document. Comment: DHCP is still evolving. CFG payload would not allow use of DHCP end-to-end security. In many cases DHCP options influence address assignment, so need this information before CFG payload. Better to restrict ourselves to one way. Comment: Alternative scenario. Authentication might influence address assignment. Push to restrict this to bootstrap and not generalize it. DHCP is not interoperable in terms of options. Comment: Not clear how DHCP will work with RADIUS or LDP; CFG option superior for this. Comment: Security Gateway acts as proxy for client; it is responsible for authentication. Comment: But this is not end-to-end. Comment: In DHCP-over-IKE, Server is DHCP relay, not a proxy. There are proposals to carry EAP within DHCP, too. While server does have to interpret DHCP bits, we don't want it to modify them. Ted: Seems to be a number of people speaking in favor of allowing DHCP-over-IKE 3 weeks. Strong interest in pursuing this? Comment: in 3 weeks we will compare. Need a few days specifying what scenarios have to be addressed. Comment: More problems being raised now that there is a proposal. IKEv1 was successful because (1) there was a freeware implementation as a starting point and (2) we did interoperability testing before going to RFC. We are not ready to go to RFC, because we have neither of these. The nature of the market is people will believe there is interoperability because it is an RFC. Need to have something more baked. Need to have a bakeoff first. Need to seriously consider doing so before going to RFC. Ted: Problem space WG says we should go to proposed standard sooner. From process viewpoint, we need some way to prevent flip-flop, so implementers can implementers. Comment: Flip-flop occurs because we don't understand problem. Comment: We haven't started IKEv2 implementation. It would be good to have a discussion about this to express opinion about draft. Ted: Let's close on DHCP first before talking about this. Sense of room to try DHCP-within-IKE for 3 weeks and fallback to CFG payload if this doesn't pan out. Comment: There are a lot of ModeCFG in IKEv1. CFG payload is near to this, so there will have to be new code and understanding. Straw vote: CFG payload, DHCP-within-IKE with fallback, something else: 10-14-0. Too close to call; take it to the list. Comment: Let's have straw vote in 3 weeks. Ted: Michael Richardson is the stuckee. We want to get draft ready for WG last call by April 15. Goal to publish this as an RFC before Austria IETF. Issue is whether baking occurs for draft standard or proposed standard. We need to have draft locked down, however. Comment: what happens with 2401bis? Do we want to divorce IKEv2 from 2401bis? are there linkages? Ted: Should we publish IKEv2 and 2401bis simultaneous or in serial. Comment: They should be "simultaneous" Ted: That's what we did with IKEv1, but caused problems because there were 12 docs. Comment: The hairball is not as large this time. Not convinced we have thought through problems we have solved. Comment: Sympathize, but we should try the IETF thing. This is a better goal. Comment: Companies are under travel restrictions. we should make bakeoff affordable and easy to get to. |