Subject: [anonsec] Proposed BTNS charter

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Tue Feb 15 12:55:20 2005

Hi.  Here is my proposal for a BTNS charter.  It's heavily based on
Joe's original charter, modified to reflect discussions with Sam Weiler who has agreed to chair the second BTNS bof.

Joe and sam are happy with this charter, although Sam is concerned
that deliverable A, B and E may suck up a lot of time.  I believe that
deliverables B and E are critical and believe that A is mostly
desirable and Joe has a lot of the text already.  Note that B does not
need to be its own document, it could easily be a section in C or D.

Sam does not want the IESG to approve this charter until we have
confirmed that we have enough participants to review documents and
edit documents and implement.  My personal preference would be to take
the charter far enough along the process to send it out for IETF wide
review, but hold it before the final approval step until we confirm
that we have sufficient people.

Note that in addition to having the list review the charter we will
need to have milestones before the charter goes to the IESG and IAB
for their internal review.  The milestones are easy to update so I
wouldn't worry much about the dates but I would like to get the text
of milestones firmed up.  (The dates will need to be firmed up before
final approval)

Better-Than-Nothing Security WG (btns)
Draft Charter
v1.0-hartmans1
Feb. 10, 2005

Mailing List info:
http://www.postel.org/anonsec

DESCRIPTION:

Current Internet Protocol security protocol (IPsec) and Internet Key
Exchange protocol (IKE) present somewhat of an all-or-nothing
alternative; these protocols provide protection from a wide array of
possible threats, but are sometimes not deployed because of the need
for pre-existing credentials. There is significant interest in providing anonymous keying for IPsec
between two parties who do not have credentials suitable for the
current profile of IKE.  This mode would protect against passive
attacks but  would be vulnerable to active attacks.
The primary purpose of this working group is to specify
extensions to or profiles of IKE to enable this mode of IPsec.
The goal of this relaxed varient of IPsec is to enable and encourage the use of network
security where it has been difficult to deploy - notably, to enable
simpler, more rapid deployment. 

Two related problems emerged during the discussion of this problem.
First, there is a desire in the KITTEN, RDDP, NFSv4 and potentially otherc
working groups to perform anonymous authentication at the IPsec layer
and later cryptographically bind the IPsec association to application
authentication.   The specification of how this binding is performed
for IPsec and the specification of how the binding interact with
application authentication protocols are out of scope for this working
group.  However, the interactions between this cryptographic channel
binding and the IPsec PAD will be similar to those for the anonymous
mode with no binding.  This working group needs to consider the
channel bindings use case when developing extensions to the PAD and
SPD.

Secondly, BTNS and the channel bindings work both encourage IPsec to
be used to secure higher layer protocols.  AS such we need to consider
what information these higher layer protocols need from IPsec.

Two proposals are under discussion for providing anonymous keing for
IPsec: bare RSA keys transported by IKE and self-signed certificates
transported by IKE.

The WG has the following specific goals over three IETF meetings: 

    a) develop a framework document to describe the motivation and
    goals of these infrastructure-free variants of security protocols
    in general, and IPsec and IKE in specific

    b) develop an applicability statement, characterizing a reasonable
    set of threat models with relaxed assumptions suitable for
    infrastructure-free use, and describing the limits and conditions
    of appropriate use of infrastructure-free variants

    c) develop standards-track  IKE extensions and/or profiles that
    support one or both of the bare RSA keys or self-signed certificates

    d) Specify standards-track extensions to the SPD and PAD  to
    support anonymous keying for IPsec and cryptographic channel bindings
for     IPsec

    e) Develop an informational document giving advice to IPsec
    implementers and higher-level protocol designers on the use of
    IPsec in securing higher-level protocols

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue Feb 15 13:23:10 2005

> what information these higher layer protocols need from IPsec.

Presumably we may conclude that there must also be a mechanism for
deliver such information to the applications, and associated

>     IPsec in securing higher-level protocols

Do you agree or do you think this needs clarification?

Note that I'm not proposing that BTNS design IPsec APIs.

Nico
--

---

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Tue, 15 Feb 2005 18:18:56 -0500

>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:

    Nicolas> Sam, I like this charter very much.  Question:
    >> Secondly, BTNS and the channel bindings work both encourage
    >> IPsec to be used to secure higher layer protocols.  AS such we
    >> need to consider what information these higher layer protocols
    >> need from IPsec.

    Nicolas> Presumably we may conclude that there must also be a
    Nicolas> mechanism for deliver such information to the
    Nicolas> applications, and associated requirements, which I think
    Nicolas> would fall under goal (e) below:

My intent was to make any API requirements work or actual API work
require a recharter operation.  So, if we find that the best advice we
can give is "we need this new mechanism," we should ask to revise the
charter.  I'd object to including such work in the charter now because
I don't believe we understand it well enough to agree to it, to
convince the IESG we know what we are doing and have things running
well enough to be sure we could do that work without derailing other
efforts.

However if you take a look at the RFC 2401bis comment log in the id
tracker you will see that I'm significantly concerned about these
issues.

Note however that Steve Kent and probably other participants in the
IPsec working group disagree with me.  Depending on how those
discussions go, we may be looking at use of IPsec to secure higher
level protocols very differently.  That's another reason I feel
uncomfortable with anything more than implementation advice in a
charter at this time.

--Sam

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 15 Feb 2005 18:22:33 -0600

On Tue, Feb 15, 2005 at 06:18:56PM -0500, Sam Hartman wrote:
> require a recharter operation.

Or some such operation (e.g., recharter another WG, charter a new WG,
close BTNS, or even no-op).

As I said, it is not my intent to include any document work items
related to IPsec APIs in the BTNS charter.  I believe we agree.

My concern is that it should be valid for the WG to conclude that such
APIs are a requirement.  I suppose that that goes without saying, but
new participants might find it useful to discover this possibility
through reading the charter.

Nico
--