Subject: [anonsec] draft BTNS minutes for IETF 63

From: lha at kth.se (Love Hörnquist Åstrand)
Date: Tue, 16 Aug 2005 13:27:08 +0200

Please check for accuracy and completeness.

Love

---

BTNS meeting notes

These are the minutes for the Better then nothing security (BTNS)
working group meeting, held at IETF-63 on Thursday, August 4, 2005, in
Paris.  Thanks to Tero Kivinen and Jeffrey Altman for the notes on
which these minutes are based.  Note that these minutes do not
follow the typical IETF minutes format, transcribing the discussion,
but are on a more condensed format.

Chairs: Love H?rnquist ?strand and Pekka Nikander

* Working group background

	Three different groups/interests:

	* protection against off-path attackers
	* working towards channel binding
	* SSH-like leap-of-faith use of IPsec

	The working group was chartered to:
	* specify extensions to IPsec so that IPsec will support
	  creation of unauthenticated SAs.
	* enable and encourage simpler and more rapid deployment of
          IPsec.

* Goals for the meeting

	* get WG feeling for problem and applicability statement.
	* Initiate work on SPD/PAD/IKE extensions.
	* Need to update the milestones to more realistic goals.
	* Other technical discussion.

* Decisions made

 	1. Need to support tunnel mode where inner address is the same
	as outer address.

		This is because of requirements of other protocols,
		such as iSCSI.

	2. Start to Work on IKE v2, and got back and see what changes
	   is needed for IKE v1.

* Current outstanding issues

	Some of these question where asked during the meeting (by
	group and chairs):

	- what details for the SPD/PAD extensions?
	- how do you detect BTNS?
	- should self-signed certificates or raw keys be used?
	- Is it OK to allow clear text traffic and then later kick in
          BTNS ?

* Current work

	- SPD/PAD extensions

	For the next item the WG will work on is the SPD/PAD
	extensions draft, target is to have it out well before
	Vancouver meeting. 

	The people volunteering to be on the design team, if one is
	formed, are: Nico Williams, Bill Sommerfeld, Stephen Kent,
	Charlie Kaufmann, Soichi Sakane, Tero Kivinen, Joe (Touch ?).

	Sam Hartman is willing to participate but cannot be part of a
	design team due to conflict of role. To avoid that conflict
	the discussion need to be on the list.

	The WG will attempt to proceed without a formal design team,
	but if that fails, the chairs will form and announce a design
	team as it becomes necessary.

* Points to pay attention to

	Charlie Kaufmann: Its not should I send authentication but does
	the other care what the authentication info is?

	Sam Hartman (AD) considers it breaking IPsec if the users
	doesn't upgrade to full IKE to keep BTNS. Its in the group
	charter to not break IPsec.

* Updating milestones

	These are the proposed dates by the chairs based on the discussing
	in the meeting, the dates are pushed forward 3 months.

	Sep 05	  	First version of SPD and/or PAD extensions draft 			(if needed)
	Oct 05		WG LC on problem and applicability statement (a+b)
	Oct 05	  	First version of IKE extensions draft (if needed)
	Nov 05	  	First version of IPsec interfaces draft (e)
	Nov 05	  	Submit problem and applicability statement
			to IESG (a+b)
	Jan 05	  	WG LC on IKE extensions (c)
	Jan 05	  	WG LC on SPD and/or PAD extensions (d)
	Feb 05	  	Submit IKE extensions to the IESG
	Feb 05	  	Submit SPD and/or PAD extensions to the IESG
	Mar 06	  	WG LC on IPsec interfaces draft
	Mar 06	  	Submit IPsec interfaces draft to the IESG
	May 06	  	Re-charter or close the WG

* Discussion on Applicability and Problem statement

	Joe Touch made a presentation on the Applicability and Problem
	statement. The initial draft was issued the first of July.

	Joe requested more feedback on the document, questions asked was:
	
	Style feedback:
	- Are there issues missing?
	- Are there issues that should be dropped?

	Items to be addressed:
	- auto detect
	- auto upgrade to security as needed
	- Any aspect of solution requirements

	Issues needed to be clarified:
	* why application security is not good enough
	* the costs of redundancy
	* why are we starting with IPsec

	Current feedback
	Style:
	-repetitions, acronyms
	Content:
	- more info on why application layer isn't sufficient
	- add redundancy of cost, as well as configuration
	- explain why IKE was chosen.

	There was agreement in the room that Joe should use the right
	terminology following the WG that created the terminology. It
	might be good to add a glossary.

	Joe asks contributors to mark what kind of comment they are making
	style, structure, or clarifications.

	Joe will put off changes until we know what we are keeping. He
	plans to integrate current comments and issue a new draft in
	3-4 weeks.

	The PS/AS statement will need 1-3 cycles before we can send it
	to WGLC. The target for WGLC is late sept/early October.

	Sam Hartman (AD) considers it breaking IPsec if the users
	doesn't upgrade to full IKE to keep BTNS. It would violate
	the charter of the group.

	Russ Housley: The question of asymmetric case was up during
	charter discussion in the BOF, needs to be supported. Pekka
	proposes that we should start with no authentication case and
	work of the other parts later. Provide guidance in the
	document as to witch problems should be dealt with first.

* Nico Williams' presentation - Thinking about BTNS

	Slides:

	* Basics
	- Forget what I have in my -00 individual submission ID on BTNS.
	- Just do IKE with base public key as CERT and with ID type to
          assert the base public key as the ID.
	- Add a bit of the PAD to allow for rules that say "any BTNS
          peer can use the IP addresses from these ranges".
	- If anyone care, a "this bare public key , use this address".

	Properties
	- No real authentication
	- Protects against passive attackers
	- Protects against off-path injection attacks
	- Active attackers that can take over a victim's DIP can
	  negotiate new SAs and go from there
	  - But it can't take over existing connections
	  - This is only slightly worse than plain IPsec in that at
	    least in plain IPsec one can tie non-mobile devices' IDs
	    to their static IP address; not so easy for BTNS

	Nico also presented ideas for an API/connection latching, this
	is for a slight out of charter/later work item, but was
	allowed to continue because there was still time left and this
	was the last issue.

	* IPsec APIs: Connection Latching
	- Latch all packets send/received by a transport (e.g., TCP) for a
   	  given connection to all SAs with some algs/IDs/etc...
   	- record algs/IDs of SA negotiated and used for the first packet
          sent or received for a connection
	- Subsequently send or accept only packets protected with
	  similar SAs
	- In KAME, Solaris, a socket option
	- Add more protection against active attacks

	* IPsec APIs: Connection Latching
	- Even UDP data-grams can be latches, through without a UDP
	"connection" you probably only want to bind each datagram
	(and its fragments) to a single SA.

	* IPsec APIs: Retrieve IDs/CERTs for latched connection

	- if applications can latch connections then applications
	  could ask the transports for information about the ends
	  of the connections
	- Latched IDs, CERTs and certificates chain used in 
	  certificate validation for initial connection packet.
	- Then ...

	* IPsec Channels and Channel Bindings
	- Much more protection against active attackers.
	  As strong as upper layer authentication, against early
	  active attacks ...

* Other issues

	Joe Touch: If you are going to turn on IPsec, it is possible
	to produce a DoS by sending junk. There is a new mailing list
	"triage" to address this issue.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 477 bytes
Desc: not available
Url : http://www.postel.org/pipermail/anonsec/attachments/20050816/a3729bbb/attachment.bin

---

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Wed, 17 Aug 2005 17:04:25 -0400

>>>>> "Love" == Love H?rnquist ?strand <lha at kth.se> writes:

    Love> 	Sam Hartman is willing to participate but cannot be
    Love> part of a design team due to conflict of role. To avoid that
    Love> conflict the discussion need to be on the list.

To clarify.  The conflict comes with significant involvement in the
document, not with what mailing list it takes place on or any specific
label.  It seems clear to me that being part of a design team and
making useful contributions to that team would be crossing the line
where I would need to recuse myself from the document for IESG
processing.

I believe it is reasonable to comment on technical issues and offer
opinions on the list and to review the document.  If I get too heavily
involved, I'll still need to recuse myself but I believe I can avoid
that.

I was not meaning to imply that a design team should not form or have
a list.  It's just that if such a team forms, I won't be part of it.
But if I had the same level of involvement on a public list I'd still
probably have a conflict.