Last Modifield: 05/16/2002
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 |
|---|---|---|
| RFC1827 | PS | IP Encapsulating Security Payload (ESP) |
| RFC1828 | PS | IP Authentication using Keyed MD5 |
| RFC1829 | PS | The ESP DES-CBC Transform |
| RFC1826 | PS | IP Authentication Header |
| RFC1825 | PS | Security Architecture for the Internet Protocol |
| RFC2085 | PS | HMAC-MD5 IP Authentication with Replay Prevention |
| RFC2104 | I | HMAC: Keyed-Hashing for Message Authentication |
| RFC2402 | PS | IP Authentication Header |
| RFC2451 | PS | The ESP CBC-Mode Cipher Algorithms |
| RFC2401 | PS | Security Architecture for the Internet Protocol |
| RFC2403 | PS | The Use of HMAC-MD5-96 within ESP and AH |
| RFC2412 | I | The OAKLEY Key Determination Protocol |
| 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) |
| RFC2411 | I | IP Security Document Roadmap |
| RFC2410 | PS | The NULL Encryption Algorithm and Its Use With IPsec |
| RFC2857 | PS | The Use of HMAC-RIPEMD-160-96 within ESP and AH |
scenarioss.Minutes for IPsec WG November 18, 2002 Agenda was considered and accepted Minutes taker: Paul Hoffman, VPN Consortium Apologies in advance for spelling errors, particularly in people's names. ID Status AES Related Drafts draft-ietf-ipsec-ciph-aes-xcbc-mac-02.txt in IESG wait (AD writeup) draft-ietf-ike-modp-groups-04.txt in IESG wait (AD writeup) draft-ietf-ipsec-ciph-sha-256-01.txt not going to be advanced draft-ietf-ipsec-ciph-aes-cbc-04.txt submitted for IETF last call Extended sequence number docs draft-ietf-ipsec-esp-v3-03.txt ready for wg last call (one last round of editing by authors) draft-ietf-ipsec-rfc2402bis-01.txt ready for wg last call (one last round of editing by authors) draft-ietf-ipsec-esn-addendum-00.tx ready for wg last call NAT Traversal docs draft-ietf-ipsec-udp-encaps-04.txt ready for IETF last call for proposed standard draft-ietf-ipsec-nat-t-ike-04.txt ready for IETF last call for proposed standard draft-ietf-ipsec-udp-encaps-justification-01.txt ready for IETF last call for informational RFC MIB docs Discussion has been non-existent since November. Plan to forward all of them to WG last call draft-ietf-ipsec-doi-tc-mib-06.txt draft-ietf-ipsec-flow-monitoring-mib-02.txt draft-ietf-ipsec-ike-monitor-mib-04.txt draft-ietf-ipsec-isakmp-di-mon-mib-05.txt draft-ietf-ipsec-monitor-mib-06.txt Others draft-ietf-ipsec-ike-ecc-groups-04.txt Moribund; no WG interest draft-ietf-ipsec-sctp-04.txt Proposed standard IESG wait (point raised by some AD; awaiting writeup) DPD draft - to WG last call soon IPsec properties - prepared to help with SOI Needs more work to be publishable Andrew wants to do work Ted and Barb view as a distraction VoIP Security Requirements - Eric Nielsen draft-jacobs-signaling-security-requirements VoIP is really across many protocols How can they leverage IPsec as the underlying security mechanism? Describes the view of a consumer of IPsec Please review it SIGMA paper announcement - Hugo Krawczyk New paper was published http://www.ee.technion.ac.il/~hugo/sigma.ps Gives the crypto rationale for IKEv1 signature modes and IKEv2 cryptographic key exchange. Covered ancient history (1995-1996) regarding the development of SIGMA and its inclusion in IKE Summary: don't just do a signature, also MAC the identity of the signer (the MAC is essential for the key exchange security!). This paper is informal and intended to a broad audience of designers and practitioners. A formal mathematical analysis was done in a paper with Ran Canetti presented at Crypto'2002. PKI profile draft - Brian Korver Profile PKIX for IKE Compliments IKE -00 and -01 were straw proposals Types of issues CRL processing Empty CERTREQ Using ID payload for policy Which fields in the cert should be used as ID Out of band exchange of keying material Want comments for -02 Gregory Lebovitz - Project DPloy earlier this year did much of the requirements Paul Hoffman talked about previous document in this space. This should not make IKEv1 implementations non-conformant. Brian said he wasn't sure how he wanted it to apply to v1 or v2 Michael Richardson - thinks it should apply to IKEv1 and IKEv2 Digital signatures for ESP and AH - Brian Weis Main need for this is source origin authentication This is needed for multicast or anycast ESP and AH don't specify any particular authentication mechanism, they just say where to do it. Digital signatures are very well understood RSA is widely implemented and is free Also fast for verification, which is good in multicast because the receivers do less work Still some issues Authentication data is larger Performance is big issue, but not so much if you have hardware acceleration DoS vulnerability: RSA verification is much slower than HMAC Bill Sommerfeld - Key size needs to be balanced against how long you are going to use the key Hilarie Orman - It's about time! The demultiplexing is done in a different place. And why not use elliptic curves? Andrea Colegrove - How do you tell IPsec who can send (and therefore sign) the messages? Is this of interest to the WG? IPv6 and IPsec Deployment Issues - Tomoaki KOBAYAKAWA Deployment scenario, not a proposal for a solution Need a solution in order to help IPv6 get deployed IPv6 deployment status Definitely been deployed, especially in Japan Lots of home appliances using it But many IPv4 users think that IPv4 is enough If IPv6 is cheaper than IPv4, it will cause greater IPv6 deployment IPv6 plug-and-play can be help Authentication can come from the ISP instead of from the end user, making devices and games easier to start from scratch IPv6 autoconf can also help with sensors and devices that need strong authentication If we make IPv6 always use IPsec, it will appear to be more secure Security policy should be maintained by an external trusted third party PKI avoidance is good Need plug-and-play IPsec for IPv6 for peer-to-peer, so please think about proposals Hugh Daniel - Won't buy a device that he cannot set the keys in Scott Fanning - How do you get a credential for a device from the factory? Steve Bellovin - Doubts about plug-and-play because the lack of authorization. How would an ISP know who is the end user for connecting particular devices? Charlie Kaufman - Protect against passive eavesdropping but others in the crypto field don't want this Gregory Lebovitz - Consumer devices already have less security and people buy it all the time Eric Nielsen - VoIP has similar problems of weighing the plug-and-play vs. flexibility Atsushi Inoue - What is the next step for this proposal? Will you make a key management protocol that matches this? Kobayakawa wants to do this. Counter Mode Security Analysis and Recommendations - Dave McGrew Wants to raise issues for discussion CM can be implemented securely Properties are different but not worse CM is more vulnerable to some precomputation attacks Lacks per-packet random input that CBC has Attacker precomputes and stores a database Amortizes the computation across many breaks lowering the expected work per break Protections against this attack It has to be unpredictable to the adversary To do this, use a larger key Use AES-192 to get 128-bit strength This requires more computation and mandates using multiple key sizes Instead, use a random or uniform field in the initial counter Shrink the SPI field Won't allow protection of jumbograms Comparison Table showed comparison of equivalent strengths Asked for limits of memory, some disagreement was heard Requires a very, very rich advisory Questions Is 85 or fewer bits of security acceptable? Is inability to encrypt jumbograms OK? Is it OK to require AES-192 acceptable? Is an explicit IV needed? For 10 Gbs message authentication, CM is the only non-encumbered system known Uri Blumenthal - Not related to the A5 attack. Wants more time to review the numbers to see if this is really an 85-bit attack. Russ Housley - Appreciates bringing the issue to the wider group. Ron Rivest said just the longer key. Ted Ts'o - Wants people who know crypto to help analyze whether it is really a practical attack. IKEv2 status discussion - Charlie Kaufman New draft in October Changed many things that became controversial: Suites replaced ala carte Went to always 4 messages Simplified traffic selector (no one has complained) Other controversies NAT traversal Tunnel vs. transport negotiation Key sizes and algorithms Legacy auth not covered Revised identity proposal NAT Traversal Not in IKEv1, but now there is a draft Should the new extensions be included in IKEv2? Tunnel vs. transport No negotiation in IKEv2 Charlie needs to understand why this is needed If inner and outer IP addresses are the same, MAY use transport MUST key size and algorithms 1024 vs. 1023 bit keys It's hard to have this debate until we know suites vs. ala carte Number of messages 4 messages except a few cases Always-4 is more complicated to be stateless Messages are larger, which causes UDP fragmentation issues May impact legacy authentication CRACK-style does better with 4/6 than with always-4 Legacy authentication Road warrior configurations Passwords, SecureID, challenge-response cards, etc. All have subtle differences History includes, XAUTH, CRACK, PIC Use legacy auth to get a cert Recursion problem Need a PKI What to do Ignore it -- not Don't hold up IKEv2: do it later Use password as a shared key Has dictionary attack Design it in Reference an existing multiplexer like SASL/EAP or GSSAPI Modify one of the IKEv1 solutions Start over Suites vs. ala carte IKEv1: propose a subset and responder selects Old IKEv2: same things but with a better encoding JFK: responder decrees Current IKEv2: defines suites, responder selects Why people like suites Easier to implement if the number is manageable Why people like ala carte Easier to implement if the number is large Easier to add new parts Options Leave it as suites Change it back to ala carte Cleverly-chosen multi-byte suite IDs Do both: MUST do suites but can do ala carte Only good idea if believe many implementations don't do ala carte Revised identity Several proposals wrapped together CERTREQ renamed TrustedRoot Used to listing trust anchors Instead of DN of trust anchor, use SHA1 of public key Charlie wants to copy TLS Allow URLs to certificates instead of the certs themselves Some certs are very large The other end might know it But can't always use the URL What are the MUST/MAY/SHOULDs to guarantee interop Negotiate authentication algorithms New IDAccepted field Needed if there are multiple ways that you are capable of authenticating and want to autoselect Merge ID and CERT into FullID Today IDs is required but CERT is optional Unstated what the relation between ID and cert are Whatever is in the cert is the ID: need to translate for your SADB OK, how do we become an RFC? Choose between multiple bales of hay (bad joke elided) Integrate NAT traversal now or later? Integrate legacy auth now or later? Charlie's preference Add some crypto tweaks from Hugo Decide now on the choices Work on other things in parallel that can be folded into this document if it doesn't hold up the document Ted Ts'o - If it is NAT-traversal friendly, we can do that in another document that describes how. If you leave holes in the spec, it has to be filled fast, otherwise a vendor will do it for us and we won't be able to fix it. Tero Kivinen - It isn't NAT-traversal friendly now but it can be made so easily. David Black - People designing suites have forgotten some things, so we need either ala carte or have a well-defined extension mechanism. Phil Hallam-Baker- Must work with NATs or don't bother. We should think about keys, not certs. Get rid of policy from key negotiation. Hilarie Orman - AA Milne was quoted. Suggested negotiating key policy in protocol from the IP Security Policy WG. Eric Rescorla - TLS doesn't negotiate trust anchors at all; this is not a raging success. Maybe assume that you only have one certificate. Cheryl Madsen - If we split off items from a single document, we lose momentum and it can take years. William Dixon - Noticed that requirements draft died. No one was giving any feedback so there was no interest in a requirements document. The requirements are inherent in the protocol design and on the mailing list, but he wanted to be sure that the WG wanted this. Jeff Schiller wearing his AD hat - Rest of the IETF wants to consume this technology soon. It's time. If this effort is to succeed, it must terminate. If this doesn't finish soon, we will terminate the WG and everyone has to use IKEv1. Wants a timeline that finishes by Feb. 15, 2003. Ted Ts'o - We negotiated that date. Cheryl Madsen - The scope of IKEv2 is VPNs and remote access. William Dixon - What are doing that is different than IKEv1? Paul Hoffman - We need remote access or else it looks like IKEv1. Jeff Schiller - Can the WG decided between always-4 or 4/6 in the next 15 minutes? Paul Hoffman - 4/6 is much better for CRACK-like. Michael Richardson - Doesn't care about always-4 or 4/6. We should embed remote access, just take it from IPSRA. If we got good cert stuff, we don't need legacy auth, but if we are going to do it, do it now. Bill Sommerfeld - Good if we can do always-4 if we don't do legacy auth. This might push against legacy auth. Tero Kivinen - NAT traversal is more complicated if we do always-4, but simple to add in 4/6. We need to do port floating. Eric Rescorla - Because 4/6 takes less thinking, we should use it. Ted Ts'o took a straw poll. Humming happened. The consensus was 4/6. Barbara Fraser wanted to have a meeting about legacy authentication this week. Gregory Lebovitz - Are we also including remote configuration? Jeff Schiller - Can you decided suites vs. ala carte in 4 minutes? David Black and Cheryl Madsen - There is also a way to do a hybrid mechanism. William Dixon - Needs to be able to swap in a different algorithm. Magnus Nystrom - Prefers suites because of interaction between algorithms. Jeff Schiller - Just decide between suites or ala carte for crypto only; other items will be decided later. Ted Ts'o took a straw poll on crypto suite or suites. Humming happened, but it sounded close. Hands were raised. The chairs saw three times as many for suites than for ala carte. Jeff Schiller asked who cared a great deal about the way that they voted. Only a few hands went up. Meeting was adjourned only a few minute over time. Many folks said they would work on the remote access problem, the suites extension issue, NAT traversal, and other problems. |