Last Modified: 2003-10-16
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. | |
Done | Internet Drafts on NAT and Firewall traversal, IKE MIBs, and requirements for IPsec and IKE for use with SCTP, to working group last call. | |
Done | Submit revised Internet-Drafts of NAT and Firewall traversal, IKE MIBs, and SCTP support for considerations as Draft Standards. | |
Done | Internet-Drafts on sequence number expansion in IKE, and IKE re-keying completed. | |
Done | Internet-Drafts on AES/SHA-2, sequence number expansion, and IKE re-keying to working group last call. | |
Done | Internet-Draft on IKE v2 Requirements to working group last call | |
Done | Internet-Drafts describing candidate IKE v2 approaches submitted to the working group. | |
Done | Submit revised Internet-Drafts on AES/SHA-2, sequence number expansion, and IKE rekeying for consideration as Draft Standards. | |
Done | Discuss and select the IKE v2 design from candidate approaches. | |
Done | Submit IKEv2 for consideration as Draft Standard | |
Nov 03 | Revised draft on IPsec Architecture to working group last call | |
Jan 04 | Submit revised draft on IPsec Architecture for consideration as Draft Standard |
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 |
RFC3526 | PS | More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE) |
RFC3554 | PS | On the Use of Stream Control Transmission Protocol (SCTP) with IPsec |
RFC3566 | PS | The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec |
RFC3602 | PS | The AES-CBC Cipher Algorithm and Its Use with IPsec |
documentIPsec WG meeting 1300, November 10, 2003 Ted Tso and Barbara Fraser chaired the meeting Paul Hoffman took these minutes Agenda was bashed lightly Document status Publication Requested (waiting for Russ Housley's review) IKEv2 IKEv2 algorithms IKEv2 UI suites Waiting for IESG telechat AES CCM AES XCBC PRF NAT Traversal RFC Editor queue AES CTR mode Dead All MIBs except the flow monitoring MIB Back from the IESG, returned with changes DPD NAT requirements Need new drafts Need IANA registry seeding -- secretarial work Michael Richardson volunteered Many other drafts have minor changes such as references 2402bis and ESPv3 needs a document of required algorithms Donald Eastlake volunteered Ongoing work 2401bis, which is what we will talk most about today RFC 2401 issues Seven open issues from the issue tracker Also will discuss the revised processing model Issue 82 -- Creation of SAs Needs better text Text is available, not yet in the issue tracker Issue 85 -- What to do when you have an inbound packet if as a valid SA but not in the selectors Use an ICMP message, or use an IKEv2 message? 2401 is tied to IKEv2, so we can add to IKEv2 for this David Black supported using the IKEv2 method Michael Richardson concurred Issue 88 -- Mark Duffy proposed lifting the prohibition on red-side fragmentation by the SG Intervening gateways might fragment anyway Bill Sommerfeld pointed out that you might be defragmenting from different SAs Michael Richardson pointed out that there is a new PMTU list has been formed to discuss issues that might impinge on this Mark Duffy pointed out we couldn't rely on PMTU Bill Sommerfeld believes we need to discuss this more to make this doesn't affect future protocols Michael Richardson wants to make sure we don't break other people's protocols in the future Steve Kent sees this as a question of "if we are going to fragment, what should be the size". We don't know that now, but we can find that out later. Ted wants people to think hard about it this week. 10ish thought we should adopt it now, 10ish wanted this week to think about it. We will accept the resolution unless a group comes back within a week. Issue 89 -- Misunderstanding about the use of selector name New text is going to come this week Issue 90 -- Removed the selector "data sensitivity level" We don't have a way to negotiate it in IKEv2 Bill Sommerfeld agrees on cutting it out as long as those who want it can add it later Michael Richardson pointed out that there is lots of other things that we cannot yet negotiate that we might specify later Straw poll: many in favor, no opposition Issue 91 -- Handling ICMP error messages Some people think the text is complicated ASCII diagrams only reflect tunnel mode Request to look at issue 91 closely Michael Richardson thinks that it is important it gets done, and that the text is going in the right direction. It might be revised later after people adopt it. This is specified as a local implementation choice Paul Hoffman reported that he has seen unprotected ICMP messages cause gateways to do unpredictable and mysterious stuff Bill Sommerfeld said we should have recommended initial values for a couple of ICMP types, maybe with a GUI suites style Revised processing model Steve Kent described the new model in 2401bis No longer say that SPDs are tied to particular interfaces You can support as many as you need for your context Most folks will have just one Forwarding decisions are separate from SPD selection Many diagrams were shown and described Some of the diagrams will appear in the document as ASCII art Gregory Lebovitz asked about whole-system implementation that includes more than just IKE/IPsec Bill Sommerfeld made sure that "interface" could be part of an API Steve talked about decorrelating SPD entries into sub-entries Allows caching of the SPD for greater speed Can cause the database to get much bigger, but usually doesn't There are asymmetries between inbound and outbound processing Showed a photo of a pied oyster catcher (Haematopus ostralegus) Asked for questions Next step is to fold today's discussion into the next document Steve will try to come up text about who can assert identities Bill Sommerfeld liked that idea Proposed timeline for 2401bis from the WG chairs Close all issues by Nov. 30th Final draft of by December 15 Start WG last call December 15 through January 10 Please comment as soon as possible on the issues above Strong identity protection using hidden credentials Presented by Hilarie Orman Was presenting this now because the WG is about to shut down Identity protection in IKE was an original requirement for IKE The current methods are unsatisfactory Don't work against a MITM Always complicate the protocol New ideas based on Identity-Based Encryption The idea was originally proposed by Shamir around 1985 This is recent work by Boneh Steve Kent brought up some issues that were taken off-line Not that different than having to know the CA, but with big downsides Basic idea: the public part of the key is based on the identity Key protocol remains simple Neither party actual discloses whether they are in the same group Simplifies key management Uses a very different model than we are used to One party must generate all the private keys for a group These private keys must be distributed securely IPR issues Stanford has main patent, are thought to be generous Uses elliptic curve, which has additional IPR Might be able to use non-EC methods Could be a possible modification to IKE Richard Graveman had comments The trusted key can be split There are additional implementation ideas that might apply Could maybe use identity-based signature schemes This allows one CA per policy Lauri Tarkkala asked if identity protection is worth the tradeoff of not generating your own private key Camillia algorithm update Presented by Akihiro Kato Camillia is a 128-bit block cipher Has been scrutinized for a few years Already accepted as proposed standard in S/MIME WG Included in the NESSIE portfolio Already has IPR statements in the IETF directory Angelos Keromytis asked about hardware acceleration Asked why it might overtake AES Not expected to overtake AES in most places Some people talked about having only one algorithm If people want this to be more than just a MAY, they should talk about it on the list BEET -- Bound end-to-end tunnel Presented by Pekka Nikander Background Separating endpoint identifiers and locator There are many proposals for this It uses a transport mode header but has tunnel semantics Has its own BEET SAs Like transport mode plus HostNAT idea Saves header bytes, especially in IPv6: about 50% if ROCH is used Useful for wireless Step towards separating identifier and location Inner addresses are the identifiers Outer addresses are the locators Important for a new architecture Objections and their deflections Unnecessary complexity Adding to KAME stack only took an extra 100 lines Hard to add to existing implementations It's OK to be optional Adding a PF_KEY extension to look for it Not needed But many people are thinking about things like this New mode for ESP Proposed as an extension to ESP Would need a change to IKEv2 Does not need to change ESP specification, but would duplicate ESP and 2401 semantics for BEET Can be considered as an extension to IPsec (or ESP) Francis Dupont said that it is better just to use compression in ESP instead of this Related BOFs this week IKEv2 Mobility and Multihoming -- mobike Profile Use of PKIX -- pki4ipsec Request for review of the channel bindings draft, which was later presented in the SAAG meeting Barbara said it was probably our last meeting; people applauded Ran out of time, ran out for cookies |