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