2.6.4 IP Security Protocol (ipsec)

NOTE: This charter is a snapshot of the 58th IETF Meeting in Minneapolis, Minnesota USA. It may now be out-of-date.

Last Modified: 2003-10-16

Barbara Fraser <byfraser@cisco.com>
Theodore Ts'o <tytso@mit.edu>
Security Area Director(s):
Russell Housley <housley@vigilsec.com>
Steven Bellovin <smb@research.att.com>
Security Area Advisor:
Russell Housley <housley@vigilsec.com>
Technical Advisor(s):
Angelos Keromytis <angelos@cs.columbia.edu>
Tero Kivinen <kivinen@ssh.fi>
Mailing Lists:
General Discussion: ipsec@lists.tislabs.com
To Subscribe: ipsec-request@lists.tislabs.com
Archive: ftp://ftp.tislabs.com/pub/lists/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.
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
  • - draft-ietf-ipsec-esp-v3-06.txt
  • - draft-ietf-ipsec-nat-reqts-06.txt
  • - draft-ietf-ipsec-nat-t-ike-07.txt
  • - draft-ietf-ipsec-udp-encaps-06.txt
  • - draft-ietf-ipsec-dpd-04.txt
  • - draft-ietf-ipsec-ikev2-11.txt
  • - draft-ietf-ipsec-ciph-camellia-01.txt
  • - draft-ietf-ipsec-rfc2402bis-05.txt
  • - draft-ietf-ipsec-pki-profile-03.txt
  • - draft-ietf-ipsec-esn-addendum-02.txt
  • - draft-ietf-ipsec-ciph-aes-ctr-05.txt
  • - draft-ietf-ipsec-ciph-aes-ccm-04.txt
  • - draft-ietf-ipsec-flowmon-mib-tc-00.txt
  • - draft-ietf-ipsec-ikev2-algorithms-04.txt
  • - draft-ietf-ipsec-ui-suites-04.txt
  • - draft-ietf-ipsec-aes-xcbc-prf-01.txt
  • - draft-ipsec-rfc2401bis-00.txt
  • - draft-ietf-ipsec-rfc2401bis-00.txt
  • Request For Comments:
    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

    Current Meeting Report

    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 algorithms
    		IKEv2 UI suites
    	Waiting for IESG telechat
    		AES CCM
    		NAT Traversal
    	RFC Editor queue
    		AES CTR mode
    		All MIBs except the flow monitoring MIB
    	Back from the IESG, returned with changes
    		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
    		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


    Strong Identity Protection Using Hidden Credentials
    2401bis: Revised Processing Model (v2)
    Bound End-to-End Tunnel