Subject: [anonsec] Draft BTNS BOF minutes from IETF-62

From: weiler at tislabs.com (Samuel Weiler)
Date: Thu, 7 Apr 2005 14:54:45 -0400 (EDT)

Apologies for not getting these to the list earlier.  Please send any
corrections to me by tomorrow, Friday, April 8th.

-------

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.