From hartmans-ietf at mit.edu Tue Feb 8 14:31:22 2005 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Tue Feb 8 14:32:52 2005 Subject: [anonsec] BOF requested Message-ID: FYI, I've approved a BOF request for IETF 62. This does not mean there will be a BOF, simply there is an option of a BOF. I definitely don't mind having a BOF if there are open charter issues at the time of the IETf meeting. We probably won't get a working group approved in time for IETf 62, although if we are lucky we may be in IETF-wide review at that point. If we don't have any open charter issues then we can either not have a meeting or have a meeting and try to do working-groupish things assuming that the WG will get approved. That depends on the preference of the chairs and the participants of the list. We can discuss that issue if it becomes important. This is just a heads up; I hope to have a proposed charter to the list this week or next Monday. From hartmans-ietf at mit.edu Tue Feb 15 12:53:27 2005 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Tue Feb 15 12:55:20 2005 Subject: [anonsec] Proposed BTNS charter Message-ID: 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 Tue Feb 15 13:21:03 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue Feb 15 13:23:10 2005 Subject: [anonsec] Proposed BTNS charter In-Reply-To: References: Message-ID: <20050215212103.GE17068@binky.Central.Sun.COM> 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. Presumably we may conclude that there must also be a mechanism for deliver such information to the applications, and associated requirements, which I think would fall under goal (e) below: > 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 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 Tue Feb 15 15:18:56 2005 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Tue, 15 Feb 2005 18:18:56 -0500 Subject: [anonsec] Proposed BTNS charter In-Reply-To: <20050215212103.GE17068@binky.Central.Sun.COM> (Nicolas Williams's message of "Tue, 15 Feb 2005 15:21:03 -0600") References: <20050215212103.GE17068@binky.Central.Sun.COM> Message-ID: >>>>> "Nicolas" == Nicolas Williams 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 Black_David at emc.com Tue Feb 15 16:07:37 2005 From: Black_David at emc.com (Black_David@emc.com) Date: Tue, 15 Feb 2005 19:07:37 -0500 Subject: [anonsec] Proposed BTNS charter Message-ID: Sam and Nico, > 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. Can I agree with both of you? I agree that API work, and requirements work sufficient to drive API work do not belong here. OTOH, for channel bindings to be usable, a statement of the form "this is the material that a higher level protocol needs from an IPsec SA in order to bind to it" is needed (and possibly in a standard-track document) to avoid having the discussion of how to channel binding (in document E) become irrelevant because implementers didn't know *what* to expose. I agree that *how* to expose it (e.g., an API) and what to do after the info is exposed (e.g., how the binding interacts with application authentication protocols) should be out of scope, with the possible exception of examples in document E. FWIW, 2401 and 2401bis make a similar distinction in that their databases (e.g., SAD, SPD) are specified from a functional standpoint (*what* to do) without specifying APIs or implementation algorithms (*how* to do it). Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david at emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: anonsec-bounces at postel.org > [mailto:anonsec-bounces at postel.org] On Behalf Of Sam Hartman > Sent: Tuesday, February 15, 2005 6:19 PM > To: Discussions of anonymous Internet security. > Subject: Re: [anonsec] Proposed BTNS charter > > >>>>> "Nicolas" == Nicolas Williams 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 Tue Feb 15 16:22:33 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 15 Feb 2005 18:22:33 -0600 Subject: [anonsec] Proposed BTNS charter In-Reply-To: References: <20050215212103.GE17068@binky.Central.Sun.COM> Message-ID: <20050216002233.GI17068@binky.Central.Sun.COM> On Tue, Feb 15, 2005 at 06:18:56PM -0500, Sam Hartman wrote: > 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. 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 -- From sommerfeld at sun.com Tue Feb 15 17:24:19 2005 From: sommerfeld at sun.com (Bill Sommerfeld) Date: Tue, 15 Feb 2005 20:24:19 -0500 Subject: [anonsec] Proposed BTNS charter In-Reply-To: References: Message-ID: <1108517058.20920.178.camel@thunk> On Tue, 2005-02-15 at 19:07, Black_David at emc.com wrote: > Can I agree with both of you? I agree that API work, and requirements > work sufficient to drive API work do not belong here. OTOH, for channel > bindings to be usable, a statement of the form "this is the material that > a higher level protocol needs from an IPsec SA in order to bind to it" > is needed (and possibly in a standard-track document) moreover, any such efforts will be necessarily incomplete unless someone actually builds an API and reports on how well it matched with the abstract architecture before we finalize the document.