Subject: [anonsec] Revised BTNS charter

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Wed, 23 Mar 2005 23:08:38 -0500

Hi.  Steve Kent graciously revised the BTNS charter to take into
account things that happened at the BOF and sent his revised charter
to the IESG.

I've taken his rewording as a starting point and propose the following
new charter.  I believe it accomplishes the following things:

* Adds the requirement that BTNS play well with traditional IPsec

* Addresses some concerns about the word anonymous

* Adds text about IPsec's access control architecture

* Clarify goal e is the interface recommendations between IPsec and
  higher-layer protocols.  Note that this is expected to compliment
  draft-bellovin-use-appsec. 

* Remove the requirement that we finish in three IETF meetings.
  Timing should be handled through milestones not charters.

Better-Than-Nothing Security (btns)
===================================

Current Status: Proposed Working Group

DESCRIPTION:

The IPsec architecture (as described in RFC 2401 and its successor, soon to 
be issued) provides a comprehensive approach to IP layer security. 
The architecture and associated protocols (ESP, AH, and IKE) provide 
protection from a wide array of attacks ,based on a set of security 
services anchored by access control. It has been suggested that IPsec 
sometimes may not be deployed because of the requirement to generate 
and distribute authentication credentials, e.g., certificates or
pre-shared secrets. There is significant interest in enabling IPsec
to create security associations (SAs) with peers who do not possess 
authentication credentials that can be validated a priori. Examples 
of such credentials include self-signed certificates or "bare" public 
keys. This mode of IPsec operation would enable use of ESP to protect 
against purely passive attacks, but it would yield SAs that might be 
vulnerable to various forms of active attacks.

The primary purpose of this working group is to specify extensions to 
the IPsec architecture, and possibly extensions or profiles of IKE, 
so that IPsec will support creation of unauthenticated SAs. The goal 
of the resulting RFCs is to enable and encourage simpler and more 
rapid deployment of IPsec in contexts where use of unauthenticated 
SAs is deemed appropriate.

Any IKE and IPsec extensions/profiles developed in this WG MUST NOT 
undermine the security facilities already defined for IPsec. 
Specifically, the access control facilities that are central to IPsec 
must not be degraded when unauthenticated SAs are employed 
concurrently with authenticated SAs in the same IPsec implementation.

Two related problems emerged during the discussion of this problem.
First, there is a desire in the KITTEN, RDDP, NFSv4 and potentially
other working groups to make use of unauthenticated IPsec SAs, and
later cryptographically bind these SAs to applications, which perform
their own authentication. The specification of how this binding is
performed for IPsec and the specification of how the binding interacts
with application authentication protocols are out of scope for this
working group.  However, interactions
between this cryptographic channel binding and IPsec (e.g., the PAD,
SPD, SAD, etc.) are expected to be similar to those for the
unauthenticated mode with no binding. This working group needs to
consider how to support channel bindings when developing extensions to
IPsec, specifically the PAD and SPD elements.

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

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

The WG has the following specific goals:

a) Develop an informational framework document to describe the motivation and
goals for having security protocols that support unauthenticated 
security associations in general, and IPsec and IKE in particular

b) Develop an informational applicability statement, describing a
set of threat models with relaxed adversary capability assumptions, to
characterize the contexts in which use of unauthenticated SAs is
appropriate

c) If necessary, specify standards-track IKE extensions 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 unauthenticated SAs for IPsec and cryptographic channel bindings
for IPsec

e) Develop an informational document describing the interfaces that
IPsec implementations should provide to allow IPsec SAs to be used to
secure higher layer protocols

The final goal is expected to compliment work going on elsewhere in
establishing best current practice for higher layer protocols secured
by IPsec.

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed, 23 Mar 2005 21:57:01 -0800

> account things that happened at the BOF and sent his revised charter

It was my impression that we - as a group - had rough consensus on the 
bulk of the charter at least.

And - correct me if this is incorrect - wouldn't the appropriate step 
have been to get rough consensus on this variant before considering it 
in the IESG?

>   Timing should be handled through milestones not charters.

While I agree with *some* of these goals, I do not feel that this is the 
only thing the revision accomplishes, and I don't feel it is a step forward.

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/anonsec/attachments/20050323/d64e9e2f/signature.bin

---

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Thu, 24 Mar 2005 01:38:18 -0500

>>>>> "Joe" == Joe Touch <touch at ISI.EDU> writes:

    Joe> Sam Hartman wrote:
    >> Hi.  Steve Kent graciously revised the BTNS charter to take
    >> into account things that happened at the BOF and sent his
    >> revised charter to the IESG.

    Joe> It was my impression that we - as a group - had rough
    Joe> consensus on the bulk of the charter at least.

Yep.  We did and do.

    Joe> And - correct me if this is incorrect - wouldn't the
    Joe> appropriate step have been to get rough consensus on this
    Joe> variant before considering it in the IESG?

No.  The IESG had sent the old charter out for external review and
requested comments be sent to the IESG.  That's how external WG review works.

    >> I've taken his rewording as a starting point and propose the
    >> following new charter.  I believe it accomplishes the following
    >> things: * Adds the requirement that BTNS play well with
    >> traditional IPsec * Addresses some concerns about the word
    >> anonymous * Adds text about IPsec's access control architecture
    >> * Clarify goal e is the interface recommendations between IPsec
    >> and higher-layer protocols.  Note that this is expected to
    >> compliment draft-bellovin-use-appsec. * Remove the requirement
    >> that we finish in three IETF meetings.  Timing should be
    >> handled through milestones not charters.

    Joe> While I agree with *some* of these goals, I do not feel that
    Joe> this is the only thing the revision accomplishes, and I don't
    Joe> feel it is a step forward.

OK, then feel free to provide an alternate revision that you like
better.  I'll note that we discussed a need for a charter change
regarding working with traditional IPsec at the BOF and Steve is the
only one who has proposed any text.  I'm not particularly attached to
Steve's text, but I do weigh existing text over no action.

Take whatever path you believe is most efficient: provide comments on
Steve's text or provide an alternative.  I'd just like to actually
reach closure.

--Sam

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 24 Mar 2005 13:13:01 -0600

On Wed, Mar 23, 2005 at 11:08:38PM -0500, Sam Hartman wrote:
[...]
> IPsec, specifically the PAD and SPD elements.
[...]
> The WG has the following specific goals:
[...]
> secure higher layer protocols

I see (d) and (e) as being in conflict with the paragraph quoted above,
specifically the third sentence -- items (d) and (e) clearly bring into
scope that which is ruled to be out of scope above.

Please clarify,

Nico
--

---

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Thu, 24 Mar 2005 16:32:05 -0500

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

    Nicolas> On Wed, Mar 23, 2005 at 11:08:38PM -0500, Sam Hartman
    Nicolas> wrote: [...]
    >> Two related problems emerged during the discussion of this
    >> problem.  First, there is a desire in the KITTEN, RDDP, NFSv4
    >> and potentially other working groups to make use of
    >> unauthenticated IPsec SAs, and later cryptographically bind
    >> these SAs to applications, which perform their own
    >> authentication. The specification of how this binding is
    >> performed for IPsec and the specification of how the binding
    >> interacts with application authentication protocols are out of
    >> scope for this working group.  However, interactions between
    >> this cryptographic channel binding and IPsec (e.g., the PAD,
    >> unauthenticated mode with no binding. This working group needs
    >> to consider how to support channel bindings when developing
    >> extensions to IPsec, specifically the PAD and SPD elements.
    Nicolas> [...]
    >> The WG has the following specific goals:
    Nicolas> [...]
    >> support unauthenticated SAs for IPsec and cryptographic channel
    >> bindings for IPsec
    >> 
    >> e) Develop an informational document describing the interfaces
    >> that IPsec implementations should provide to allow IPsec SAs to
    >> be used to secure higher layer protocols

    Nicolas> I see (d) and (e) as being in conflict with the paragraph
    Nicolas> quoted above, specifically the third sentence -- items
    Nicolas> (d) and (e) clearly bring into scope that which is ruled
    Nicolas> to be out of scope above.

The intent is that channel bindings is in scope only when there is a
likelihood of conflicts if the channel bindings and
non-channel-bindings solutions are pursued separately.  I believe the
SPD/PAD interactions and the interface requirements are both examples
where you want only one solution--a solution that works with BTNS and
channel bindings.  So that solution will be developed here.