2.6.1 Better-Than-Nothing Security (btns)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date.

Last Modified: 2005-02-04


Samuel Weiler <weiler+ietf@watson.org>

Security Area Director(s):

Russell Housley <housley@vigilsec.com>
Sam Hartman <hartmans-ietf@mit.edu>

Security Area Advisor:

Russell Housley <housley@vigilsec.com>

Mailing Lists:

General Discussion:
To Subscribe:

Description of Working Group:

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 (unauthenticated) keying for IPsec to create
security associations
(SAs) with peers who do not possess authentication credentials that
can be validated. Examples of such credentials include self-signed
certificates or "bare" public keys. 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
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, to enable and encourage the use of network security where
it has been difficult to deploy--notably, to enable simpler, more
rapid deployment.

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. To avoid duplication of effort, 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
anonymous keying of security associations in general, and IPsec and IKE in

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

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 complement work going on elsewhere in
establishing best current practice for higher layer protocols secured
by IPsec.

Goals and Milestones:

No Current Internet-Drafts

No Request For Comments

Current Meeting Report

Minutes from the BTNS BOF
IETF-62, Minneapolis
Monday, 7 March 2005
Recorded by Yushun Wang

Sam Weiler (chair): Today is mostly for charter bashing. Joe will give a brief overview presentation Then we'll go through list of items in the charter, milestones.

Joe Touch - (Overview Presentation)

Sam Hartman (AD) (respond to one of the slides) - From mailing list discussion: self-sign cert & raw RSA keys are only things we are doing, others not in charter.

(end of slides)

Steve Kent (Kent) - IKE is essentially supporting IPsec, so changing IKE is the same as changing IPsec. IPsec also does access control in SPD which seemed missing. Why not start with TLS. Why start (or target) only with IPsec?

Joe Touch (Joe) - Attack against transport, we could either protect the network layer or change all transport layers. Transport layer headers also have copies of network header layer as the authentication of network identities.

Kent - How about IPsec access control, exactly about who you are talking to.

Joe - Identity in this case means "network layer" identity.

Chair - Is this too dangerous?

Kent - No, but starting from changing IPsec/IKE is not good.

AD - Should focus on the charter. The decision/scope from DC bof is narrower than what Joe would like to do. But since we focus on IPsec, there is a sense of access control based on the first pkt.

Kent - That's not access control, that's continuation of auth or session association.

Chair - ...(?)

Pekka Salova (Savola) - Please clarify how this deal with issues where valid (RST?) packets generated by firewall on path.

Joe - Third party should not be sending packet to me. That should be considered an attack.

Paul Hoffman (Paul) - We should reset the discussion according to the charter, not Joe's presentation.

Kent - What is the purpose of the presentation?

Chair - for those who weren't in dc, or who lost the context.

Kent - go back to agenda, why are we discussion details?

Chair - To find out if items are of sufficient interests and find people to work on.

Kent - we should do charter bashing now.

Chair - I want to show the list, and let people say we want to do this.

Eric Resocorla (Eric) - Something has been snuck in there: "various security protocols in general". We have somewhere btn 10-57 security protocols.

Chair - Real work items are c & d.

Eric - Should we strike everything and change those to IKE/IPsec?

Joe - Basically says that it will not just work/apply to IPsec/IKE, but also to all other security protocols.

Chair - Is that ok?

Eric - Fine. But "framework" is misleading, Don't think it's a framework.

Chair - Do we need a framework according Joe's anonsec doc, or is problem statement ok?

AD - App statement is also needed, there are times we do care about identities. it's important to scope the work.

Eric - This is a problem, this is a app statement, I don't know what it is so can't decide what i want or not.

Chair - Do we want problem statement & framework in the charter?

Kent - Why do we say changing IPsec/IKE?

Paul - (c) specifically says profile, it's not changing or extending IPsec/IKE. I don't see changing IPsec/IKE.

Kent - Profile is part of standard.

Chair - Other security protocols are also in the target, why is IPsec sacred?

Kent - Should clarify what we want to do with IPsec.

Sam - DC BOF already discussed all these issues and most wanted this work. From a process standpoint, want to see how to process your objection without stopping the progress.

Kent - Someone who want to do this overall thing...(?)

Nicolas William (Nico) - IPsec is the right thing to do here. We heard the arguments, there may be issues.

Charlie Kauffman (Charlie) Issue 1 is a bit vague. Does it say we look at IPsec or include other possibilities? And whether now or later to look at other protocols.

Chair - Just IPsec for this group and move forward or re-charter.

Charlie - Should prevent other people from hijacking this group to do others.

Joe - I do this because DC BOF asked what Steve said, don't make it too broad or it will be like IRTF. I also want to continue draft-anonsec, address Steve's concerns on why IPsec. I believe other protocols are already doing/allowing this. I'll address why not transport layer do this problem.

Chair - Who else wants to work?

Uri Blumenthal(?) - Will read drafts.

Paul - Should discuss (d) first.

Salova - (b) is the really important. (something about framework...)

Chair - Who think this is important enough to take on. Write, not review.

Nico - c, d, e

Chair - Ff we don't do c/d/e, a/b may be lost.

Chair - Blue sheet?

David Black (David) - Half a hand for b & e.

Chair - Protocol work:

Paul - Strong preference on profiles over extensions, easier to implement. But which IKE? Probably IKEv2. Lets decide on which works. Must clarify. IKEv2 already had a bake-off. So should also be considered.

Chair - Not a volunteer. Need volunteers.

Charlie - Don't believe this needs extension nor profiles, and happy to write down the couter-doc.

Chair - If tech analysis (shows it's not needed, ...?)

Paul - WIll co-write profiles, probably very short profile needed.

Chair - ...

Nico - Just a short ID/cert type, should be short. An issue of processing mode, not much work to do there.

AD - Didn't I get this text from you? Do you volunteer?

Nico - Will do c/d/e. Joe what are you working on?

Joe: (a), and maybe b which should be merged to (a). Not c/d/e. Not an expert and don't know how to make IPsec community happy.

Paul - Me and Charlie for c/d. not a,b,e.

AD - For (b). Russ pointed out what we asked for is unclear. If we want to do (d), we have to clarify. Assume 2401bis, one is a flag, not to be strongly auth. if two people want to talk securely, and flag set, they can communicate securely. Would not be susceptible to MITM attacks, once IKE is established, can do it securely. Another flag in SPD says I am willing to negotiate an SA for traffic that falls into this selector, but access bypass traffic. Implications for SAD/SPD caches. Another flag for SA, will bypass the traffic when failed. People had done this. But that's the 3 types of changes we should provide semantics for. In addition to asking if people want to do this, which of these SPD changes are important?

Nico - Too details. Many OS's have this. It is possible to involve link or transport for SA negotiations. Already similar binding to other objects. Just need some interfaces to IPsec. Bill Sommerfeld's draft on IPsec interface requirement. Either do it in this wg, or make sure it's revived.

Pekka Nikander (Nikander) - Interface to IPsec crypto services for identity is an important issue. Willing to work on (b).

Chair: thanks.

Russ Housley (Russ) - (c) is not huge, (d) is the one that concerned me. Where in the SPD & packet processing is unclear. Is it appropriate for DNS lookup? Another choice is plugging both together. A host that has some bypass, some auth, some the best we could do.

AD - Implicit to me that we must do that for this to be useful, alongside IPsec.

Chair: Who would be happy with ipsec but not this?

(about 10 people)

Chair: who want both ipsec & btns?

(about 40-50)

Bill - Produce implementations that could do either, but should not explode when seeing the other.

Greg Lebovitz (Greg) - Might need to change local implementations, store/read/match, don't mod the protocol bits-on-the-wire.

AD - Agree with the requirement, but stating would be complex.

Greg - IKEv2 is not mature enough. Could do this on IKEv2.

Chair - So it's bad for v1, why?

Greg - Would affect v1 users if we add new id types.

Nico - For unknown id type, would the responder blow up, or just doesn't care? The fomer is a bug, the later shouldn't matter for btns. Just mean that we can't do it. Why is that we can't add new id types for IKEv1?

Greg - Not can't, just would not like to.

Nico - This is optional, so failure is ok. Just don't do btns.

Chair - Move on.

Bill Sommerfeld (Bill) - (d) wouldn't be a simple extension. Extension to PAD(?) might be right.

Chair - Should move on to milestones. Why we don't need ...(?)

Paul - Even if BTNS can't coexist with IPsec VPNs, still would like to proceed.

AD - Can not guarentee apps to separate usage.

Chair - App that can do both?

Nico - btns must/must not co-exist?

Chair - Question: do we require them to co-exist?

AD - Want to place requirements on the 3 options that I said. No.

Chair: Nico/Bill/Pekka Nikander for c/d/e. Last one information doc.

AD - Won't get consenses on standard track for interfaces, so informational. Will move there.

Eric - If (e) is for general (security protocols), why here?

AD - For channel binding stuff, must do it somewhere.

Eric - Don't read that here.

David - Mostly channel binding, and giving advice to design of higher auth.

Bill - Standard track concerns. Either define an API or a model of API for information flow. Think it's critical to be on STD track.

Paul - Not STD track and not in this wg. Kent worry about we are too far down the track. Other can use non-IPsec. might be generating an API for what we are doing, might include others. might not be a working group.

Chair - Not here? how about infomational not API?

Chair - who wants (e)? Bill, Nico, Charlie, Pekka N.

Chair - who thinks it's bad? Steve?

Kent - Issues for secure gateways.

Nico - This is API, starts out abstract. Necessary for btns to be useful. Can be elsewhere.

AD - Issues for STD track(?), but we will find out when we are done. Don't want to do it here.

Chair - Who cares enough to read?

West(?): API is more than btns, should not be here. if it's optional, why do apps care? Argue against.

Bill - Need an abstract API to channel binding for interop. btns without API is still useful. But channel binding makes it much more useful. Not critical, but reasonable place to do that work.

Chair - Stop the line and go to milestones.

David - Need spec on what the bits are and what makes it work, not details. Could left for implementations.

Eric - don't want 2nd thing David said. Not sure about 1st.

Chair - What else do ADs need?

AD - Steve are you uncomfortable with this work?

Kent - Most people (3 groups) want different thing with same mechanism, but not overlapping motivation. Two of those three don't need IPsec. Joe did address the need for IPsec.

AD - charter?

Kent - As long as it's not affecting orig IPsec, I am not uncomfortable.

AD - Would-be chairs should email Russ & Sam.

Chair - Milestones: how long, might be unrealistic. First drafts in 2 month?

Nico - Some already exist. First draft (in two months) should be fine.

Chair - Like to see if authors agree.

Joe - Will write the first two.

Chair - Others? No one is saying not realistic.

AD - We are done.


Better-Than-Nothing Security Overview