I-D Action:draft-ietf-btns-core-07.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Better-Than-Nothing Security Working Group of the IETF.

	Title           : Better-Than-Nothing-Security: An Unauthenticated Mode of IPsec
	Author(s)       : N. Williams, M. Richardson
	Filename        : draft-ietf-btns-core-07.txt
	Pages           : 16
	Date            : 2008-08-05

This document specifies how to use the Internet Key Exchange (IKE)
protocols, such as IKEv1 and IKEv2, to setup "unauthenticated"
security associations (SAs) for use with the IPsec Encapsulating
Security Payload (ESP) and the IPsec Authentication Header (AH).  No
changes to IKEv2 bits-on-the-wire are required, but Peer
Authorization Database (PAD) and Security Policy Database (SPD)
extensions are specified.  Unauthenticated IPsec is herein referred
to by its popular acronym, "BTNS" (Better Than Nothing Security).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-btns-core-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

I-D ACTION:draft-ietf-btns-prob-and-applic-07.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Better-Than-Nothing Security Working Group of the IETF.

	Title		: Problem and Applicability Statement for Better Than Nothing Security (BTNS)
	Author(s)	: J. Touch, D. Black, Y. Wang
	Filename	: draft-ietf-btns-prob-and-applic-07.txt
	Pages		: 30
	Date		: 2008-7-8
	
The Internet network security protocol suite, IPsec, requires 
   authentication, usually of network layer entities, to enable access 
   control and provide security services. This authentication can be 
   based on mechanisms such as pre-shared symmetric keys, certificates 
   with associated asymmetric keys, or the use of Kerberos (via KINK). 
The need to deploy authentication information and its associated 
   identities can be a significant obstacle to the use of IPsec. 

   This document explains the rationale for extending the Internet 
   network security protocol suite to enable use of IPsec security 
   services without authentication. These extensions are intended to 
   protect communication, providing "better than nothing security" 
   (BTNS). The extensions may be used on their own (this use called 
   Stand Alone BTNS, or SAB), or may be used to provide network layer 
   security that can be authenticated by higher layers in the protocol 
   stack (this use is called Channel-Bound BTNS, or CBB). The document 
   also explains situations for which use of SAB and/or CBB extensions 
   are applicable.

A URL for this Internet-Draft is:

ML moving to ietf.org servers

Folks,

The BTNS mailing list will be moved from postel.org to ietf.org in 
the near future.

Current subscribers will be automatically subscribed to the new list and 
you'll be notified by the mailing list daemon. You will probably need 
to update your mail filters configuration to reflect that change.

We'll keep you updated with the progress of the move.

--julien & love, BTNS chairs
_______________________________________________

Asymmetric SAB

Hi,
I was looking for details on Asymmetric SAB (A-SAB),  but I did not find
any reference to it in draft-ietf-btns-core-06. Is there some other
document describing it?
Thanks,
Csaba
_______________________________________________

[WGLC]

Folks,

Hereby we're issuing a a two weeks WGLC for the "IPsec Channels: 
Connection Latching" document, draft-ietf-btns-connection-latching. You 
can find it there:

<http://www.ietf.org/internet-drafts/draft-ietf-btns-connection-latching-07.txt>

Please send to the list by 2008-05-27 a note stating whether you think 
the document is ready to be forwarded to IESG along with comments you 
might have.

Thanks.

--julien & love, BTNS chairs.
_______________________________________________

Changes for draft-ietf-btns-connection-latching-07

At Philadelphia I had a conversation with Daniel Migault about
connection latching.  Daniel's main insight was that the key task for us
in this I-D was to make absolutely clear what is the impact of this work
on the IPsec architecture, and that that impact is minimal, or none
even.

Daniel subsequently posted suggested text and ASCII art, and though I
used very little of that text as is, Daniel's text and art inspired me
to follow along those lines.

So I made the following changes:

 - Simplified and clarified the connection latch state machine,
   including a state machine diagram.

 - Tailored the description of the normative model of connection
   latching to make clear that at its bare minimum it's just a purely
   local conflict detection and notification mechanism.

 - All features whereby local policy is logically updated are now
   optional, with clear warnings that no such logical policy updates
   survive reboots.

 - Added text to the security considerations section about the impact of
   this feature on the IPsec architecture.  The impact of optional
   features is described in a separate section.

 - Added an informative diagram showing the relationships between
   various components of an IPsec w/ connection latching system, all in
   terms likely to be understood by operating systems developers.

I-D Action:draft-ietf-btns-connection-latching-07.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Better-Than-Nothing Security Working Group of the IETF.

	Title           : IPsec Channels: Connection Latching
	Author(s)       : N. Williams
	Filename        : draft-ietf-btns-connection-latching-07.txt
	Pages           : 28
	Date            : 2008-04-14

This document specifies, abstractly, how to interface applications
and transport protocols with IPsec so as to create "channels" by
latching "connections" (packet flows) to certain IPsec Security
Association (SA) parameters for the lifetime of the connections.
Connection latching is layered on top of IPsec and does not modify
the underlying IPsec architecture.

Connection latching can be used to protect applications against
accidentally exposing live packet flows to unintended peers, whether
as the result of a reconfiguration of IPsec or as the result of using
weak peer identity to peer address associations.  Weak association of
peer ID and peer addresses is at the core of Better Than Nothing
Security (BTNS), thus connection latching can add a significant
measure of protection to BTNS IPsec nodes.

Finally, the availability of IPsec channels will make it possible to
use channel binding to IPsec channels.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-btns-connection-latching-07.txt

Fwd: Review of draft-ietf-btns-c-api-03

Folks,

Vijay Gurbani has reviewed the BTNS C API and kindly agreed to 
let me forward it to the mailing list, please see it below. 

Many thanks to Vijay!

--julien

From: Vijay K. Gurbani <vkg <at> alcatel-lucent.com>
Subject: Review of draft-ietf-btns-c-api-03
Date: 2008-04-12 22:36:16 GMT

Dr. Richardson et al.: I was asked by the Applications area to review
draft-ietf-btns-c-api-03.

Here is a review of it, following a similar one I did last week for
draft-ietf-btns-abstract-api-01.

draft-ietf-btns-c-api-03
-------------------------------
As a follow-up draft to draft-ietf-btns-abstract-api, the reasons
why this document is important are much the same as why the latter
one was important.  I do note that this document appears to be
more fleshed out than its abstract-api counterpart, whereas I would

Re: I-D Action:draft-ietf-btns-connection-latching-06.txt

On Wed, Apr 09, 2008 at 07:42:02PM +0200, Daniel Migault wrote:
> It sounds good for me, maybe we should also add dot lines with the 
> CREATE_CONNECTION_LATCH function.

Consider it done.

> Can the LISTEN state be considered as something like a "larval state"? 

Yes.

> Should we introduce in the same manner a CONNECTION state so that 
> listeners  and connections object have similar state architecture?

I guess I could.  I'll play with it.  This diagram is fairly busy though
and I want to keep it simple.  It needn't capture every subtlety :)

Nico
--

-- 
_______________________________________________

Re: I-D Action:draft-ietf-btns-connection-latching-06.txt

On Wed, Apr 09, 2008 at 04:56:13PM +0200, Daniel Migault wrote:
> Your figure is probably clearer than mine, and it is better to separate 
> the esp/ah layer from the key management layer.
> The logical SPD is the combination of decorrelated SPD and ULP-driven 
> SPD.  The figure mentions interaction between IKEv2 and the Logical SPD, 
> but I don't see interaction between UPL and the logical SPD. Maybe one 
> could add one arrow between ULP and the logical SPD.

Yes, I need to fix that.  It needs to be more like this:
   +--------------------------------------------+
   |                       +--------------+     |
   |                       |Administrator |     |
   |                       |apps          |     |
   |                       +--------------+     |
   |                            ^      ^        |
   |                            |      |        | user mode
   |                            v      v        |
   | +--------------+      +-------++--------+  |
   | |App           |      |IKEv2  ||        |  |
   | |              |      | +---+ || +----+ |  |
   | |              |      | |PAD| || |SPD | |  |
   | |              |      | +---+ || +--^-+ |  |
   | +--------------+      +-+-----++----+---+  |
   |   ^                     |           |      |
   +---|---------------------|-----------|------+  user/kernel mode
   |   |syscalls             |  PF_KEY   |      |  interface
   +---|---------------------|-----------|------+
   |   v                     |           |      |
   |+-------+   +------------|-----------|-----+|
   ||ULP    |   | IPsec   key|manager    |     ||

Re: I-D Action:draft-ietf-btns-connection-latching-06.txt

On Wed, Apr 09, 2008 at 04:57:19PM +0200, Daniel Migault wrote:
> >Never mind.  I've written one:
> >
> Here are my comments they might result from mis-interpretation of the 
> draft, but that how I understood it.
> 
> On the figure there is a transition from LISTEN to ESTABLISH state. I 
> might be wrong but I understood LISTEN state as an established state for 
> Listener connection Latch.  So I  would  not expect transition from 
> LISTEN to ESTABLISHED state. The only transition would be from LISTEN to 
> CLOSE state.

I didn't know how to draw this, but yes, LISTEN *spawns* ESTABLISHED
latches.  I thinkI'll just add text to the diagram, or use a different
style of line.

_______________________________________________