From julien.IETF at laposte.net Mon Jul 2 01:23:35 2007 From: julien.IETF at laposte.net (Julien Laganier) Date: Mon, 2 Jul 2007 10:23:35 +0200 Subject: [anonsec] BTNS draft Agenda for IETF69 In-Reply-To: <200703021437.59586.julien.IETF@laposte.net> References: <26477.1171596804@sandelman.ottawa.on.ca> <20070223141541.GZ18346@binky.central.sun.com> <200703021437.59586.julien.IETF@laposte.net> Message-ID: <200707021023.35378.julien.IETF@laposte.net> Folks, Below is a draft agenda for IETF 69 based on our current working items. Please sends us changes/addons. -- julien / btns co-chair --------------------------------------------------------- Better-Than-Nothing Security (btns) Agenda at IETF-69 ==================================== Chairs: Love Hornquist Astrand Julien Laganier AGENDA: Preliminaries - Chairs Connection Latching - Nico Williams draft-ietf-btns-connection-latching-01.txt IPsec APIs - Michael Richardson & Miika Komu draft-ietf-btns-ipsec-abstract-api draft-ietf-btns-ipsec-c-api From Internet-Drafts at ietf.org Mon Jul 9 12:15:02 2007 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Mon, 09 Jul 2007 15:15:02 -0400 Subject: [anonsec] I-D ACTION:draft-ietf-btns-c-api-01.txt Message-ID: ENCODING mime FILE /internet-drafts/draft-ietf-btns-c-api-01.txt -------------- next part -------------- From julien.IETF at laposte.net Thu Jul 12 00:30:25 2007 From: julien.IETF at laposte.net (Julien Laganier) Date: Thu, 12 Jul 2007 09:30:25 +0200 Subject: [anonsec] BTNS draft agenda for IETF69 posted In-Reply-To: <200703021437.59586.julien.IETF@laposte.net> References: <26477.1171596804@sandelman.ottawa.on.ca> <20070223141541.GZ18346@binky.central.sun.com> <200703021437.59586.julien.IETF@laposte.net> Message-ID: <200707120930.26044.julien.IETF@laposte.net> Folks, The draft agenda has been posted: Please sends us changes/addons before July 16th. -- julien / btns co-chair From mcr at sandelman.ca Thu Jul 19 11:24:24 2007 From: mcr at sandelman.ca (Michael Richardson) Date: Thu, 19 Jul 2007 14:24:24 -0400 Subject: [anonsec] I-D ACTION:draft-ietf-btns-c-api-00.txt In-Reply-To: <1EF1E44200D82B47BD5BA61171E8CE9D0439AF95@NT-IRVA-0750.brcm.ad.broadcom.com> References: <1EF1E44200D82B47BD5BA61171E8CE9D0439AF95@NT-IRVA-0750.brcm.ad.broadcom.com> Message-ID: Caitlin Bestler wrote: > This draft makes many assumptions about the execution environment. > Far too many, in my opinion, for anything beyond an informational RFC. > > In particular the requirements that the objects be "opaque" and > non-copyable are problematic in embedded and/or virtualized > environments. You are mis-understanding the requirements. The requirements are there in order to free the API developer to be able to do what make sense in a multitude of environments. An object is said to be opaque to make sure that the *APPLICATION* does not depend upon the ability to look into the object in order to function. An object is said to be non-copyable, in order that you do not assume that you can copy it trivially by doing a structure copy. In both cases, if your choose to implement the accessor functions as #define macros, and the copy function as *foostruct=*barstruct, that's just fine. However, in a Posix environment, I can not assume that > Not allowing the client to copy the object to another location in the > same process, or to an entirely different process is quite reasonable. I don't think it says that. What it says is that if you have a handle in one process, that it will not be transparently valid in another process. If you want to move the object to another process, then you have to have cooperation of the object. It's just like a file handle or a socket. > But can the process itself be migrated? Are these objects expected > to work after a Unix style fork? What if the entire IP host is > migrated to another physical machine? Do sockets work after you do these things? > What needs to be stated is what expectations there are about > this memory. Are normal operations on the entire memory space, > such as swap-out/swap-in and virtualization migration, compatible > with these objects or not? We were also very specific in the requirements document (I think you didn't read it), that we never let the application processes see keying material. They have no business knowing about that. From caitlinb at broadcom.com Thu Jul 19 15:21:10 2007 From: caitlinb at broadcom.com (Caitlin Bestler) Date: Thu, 19 Jul 2007 15:21:10 -0700 Subject: [anonsec] I-D ACTION:draft-ietf-btns-c-api-00.txt In-Reply-To: Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D049A701C@NT-IRVA-0750.brcm.ad.broadcom.com> > -----Original Message----- > From: anonsec-bounces at postel.org > [mailto:anonsec-bounces at postel.org] On Behalf Of Michael Richardson > Sent: Thursday, July 19, 2007 11:24 AM > To: anonsec at postel.org > Subject: Re: [anonsec] I-D ACTION:draft-ietf-btns-c-api-00.txt > > Caitlin Bestler wrote: > > This draft makes many assumptions about the execution environment. > > Far too many, in my opinion, for anything beyond an > informational RFC. > > > > In particular the requirements that the objects be "opaque" and > > non-copyable are problematic in embedded and/or virtualized > > environments. > > You are mis-understanding the requirements. > The requirements are there in order to free the API > developer to be able to do what make sense in a multitude of > environments. An object is said to be opaque to make sure > that the *APPLICATION* does not depend upon the ability to > look into the object in order to function. > An object is said to be non-copyable, in order that you do > not assume that you can copy it trivially by doing a structure copy. > > In both cases, if your choose to implement the accessor > functions as #define macros, and the copy function as > *foostruct=*barstruct, that's just fine. > > However, in a Posix environment, I can not assume that > Would you be ok with explicitly clarifying that the requirements described are only intended for the application layer code, and are not intended to constrain implementaion of the operating environment? Or if there are constraints on the operating environment, to list those separately? For example, it is concievable that there is a requirement that the key material not be place in swap eligible memory. If so, that should be separate and explicit. (Personally, I think that falls under "quality of implementation" and is not something that should be standardized, but I could see valid arguments to the contrary). From Nicolas.Williams at sun.com Thu Jul 19 15:54:20 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 19 Jul 2007 17:54:20 -0500 Subject: [anonsec] I-D ACTION:draft-ietf-btns-c-api-00.txt In-Reply-To: <1EF1E44200D82B47BD5BA61171E8CE9D049A701C@NT-IRVA-0750.brcm.ad.broadcom.com> References: <1EF1E44200D82B47BD5BA61171E8CE9D049A701C@NT-IRVA-0750.brcm.ad.broadcom.com> Message-ID: <20070719225420.GY25464@Sun.COM> On Thu, Jul 19, 2007 at 03:21:10PM -0700, Caitlin Bestler wrote: > > You are mis-understanding the requirements. > > The requirements are there in order to free the API > > developer to be able to do what make sense in a multitude of > > environments. An object is said to be opaque to make sure > > that the *APPLICATION* does not depend upon the ability to > > look into the object in order to function. > > An object is said to be non-copyable, in order that you do > > not assume that you can copy it trivially by doing a structure copy. > > > > In both cases, if your choose to implement the accessor > > functions as #define macros, and the copy function as > > *foostruct=*barstruct, that's just fine. Well, I would hope not -- implementing accessor functions as macros makes the structure of the object part of the ABI, even though not part of the API. :) > > However, in a Posix environment, I can not assume that > > > > Would you be ok with explicitly clarifying that the requirements > described are only intended for the application layer code, and are > not intended to constrain implementaion of the operating environment? I think it should be quite clear already that "opaque" here means "with respect to the application" since we're defining an API. (And certainly when the language is compared with that of other Internet RFCs that describe APIs.) But adding a simple qualifier like "with respect to the application" should be no problem. Michael? > Or if there are constraints on the operating environment, to list those > separately? For example, it is concievable that there is a requirement > that the key material not be place in swap eligible memory. If so, that > should be separate and explicit. (Personally, I think that falls under > "quality of implementation" and is not something that should be > standardized, > but I could see valid arguments to the contrary). Nothing in this API deals directly with cryptographic key material. Nico -- From mcr at sandelman.ca Mon Jul 23 07:40:46 2007 From: mcr at sandelman.ca (Michael Richardson) Date: Mon, 23 Jul 2007 09:40:46 -0500 Subject: [anonsec] I-D ACTION:draft-ietf-btns-c-api-00.txt In-Reply-To: <1EF1E44200D82B47BD5BA61171E8CE9D049A701C@NT-IRVA-0750.brcm.ad.broadcom.com> References: <1EF1E44200D82B47BD5BA61171E8CE9D049A701C@NT-IRVA-0750.brcm.ad.broadcom.com> Message-ID: Caitlin Bestler wrote: > Would you be ok with explicitly clarifying that the requirements > described are only intended for the application layer code, and are > not intended to constrain implementaion of the operating environment? I would be happy to clarify anything. In the IETF tradition, you can send text. If you send patches, I will apply them. I just want to be clear that you want me to clarify that the Application Programming Interface is a set of requirements on an interface that Applications use. They aren't constraints on the application, or on the operating environment. They are constraints are the interface only. And we aren't creating an ABI either, or promising that a change in the implementation of the API won't require a recompilation of the applications. (It is certainly is a nice feature if you have, but it certainly isn't required) > Or if there are constraints on the operating environment, to list those > separately? For example, it is concievable that there is a requirement > that the key material not be place in swap eligible memory. If so, that Keys never traverse this API. That is a requirement. Where the IPsec "kernel" puts keys is it's own business. From mcr at sandelman.ca Mon Jul 23 07:42:06 2007 From: mcr at sandelman.ca (Michael Richardson) Date: Mon, 23 Jul 2007 09:42:06 -0500 Subject: [anonsec] I-D ACTION:draft-ietf-btns-c-api-00.txt In-Reply-To: <20070719225420.GY25464@Sun.COM> References: <1EF1E44200D82B47BD5BA61171E8CE9D049A701C@NT-IRVA-0750.brcm.ad.broadcom.com> <20070719225420.GY25464@Sun.COM> Message-ID: Nicolas Williams wrote: >>> In both cases, if your choose to implement the accessor >>> functions as #define macros, and the copy function as >>> *foostruct=*barstruct, that's just fine. > > Well, I would hope not -- implementing accessor functions as macros > makes the structure of the object part of the ABI, even though not part > of the API. :) Not our problem, it's an implementation concern. Some systems do not have ABIs. It's all one source tree. From kent at bbn.com Wed Jul 25 12:25:54 2007 From: kent at bbn.com (Stephen Kent) Date: Wed, 25 Jul 2007 15:25:54 -0400 Subject: [anonsec] comments on the BTNS core I-D Message-ID: Sorry I didn't get these out sooner. Steve -------------- next part -------------- A non-text attachment was scrubbed... Name: draft-ietf-btns-core-03.pdf Type: application/octet-stream Size: 219583 bytes Desc: not available Url : http://mailman.postel.org/pipermail/anonsec/attachments/20070725/76d81da0/draft-ietf-btns-core-03-0001.obj From hartmans-ietf at mit.edu Wed Jul 25 13:38:32 2007 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Wed, 25 Jul 2007 16:38:32 -0400 Subject: [anonsec] comments on the BTNS core I-D In-Reply-To: (Stephen Kent's message of "Wed, 25 Jul 2007 15:25:54 -0400") References: Message-ID: This document has already been submitted for AD review. Chairs, if you want me to return to the WG then please instruct me to do so. From Black_David at emc.com Wed Jul 25 13:52:29 2007 From: Black_David at emc.com (Black_David@emc.com) Date: Wed, 25 Jul 2007 16:52:29 -0400 Subject: [anonsec] Finishing off the Problem and Applicability Statement draft Message-ID: As discussed in this afternoon's btns meeting, Sam's AD review of draft-ietf-btns-prob-and-applic-05.txt turned up a couple of areas that need serious attention: 1) Leap of Faith discussion (Section 5.7) 2) NAT Traversal, mobility and multihoming issues (Sections 6.1 and 6.2) The purpose of this message is to explain what the authors propose to do about these areas, so that the WG chairs can determine the rough consensus of the WG on what should be done. Taking the areas in reverse order, the current sections 6.1 and 6.2 of the draft essentially say that NAT, mobility and multihoming issues are out of scope. Whether they are out of scope is a longer discussion, but the approach agreed to in this afternoon's btns meeting is to remove Sections 6.1 and 6.2 from the problem and applicability statement draft, and deal with whether the issues are in scope and what to do about them if they are in the context of the WG's other drafts. The Leap of Faith concerns are somewhat more involved. Sam's original review comments were: >> I wonder if the working group has adequately reviewed section >> 5.7. In particular do we actually have a strong consensus that >> caching of BTNS credentials is inappropriate? We certainly >> have a lot of issues to work through before we can recommend >> this caching. But if there is no caching how is that leap of >> faith at all? The first problem is that the "Yes" and "No" in the last line of the Section 5.7 table don't capture what's really going on; it's not that BTNS credentials can't be cached, but rather that there is no security advantage to doing so. Here's the proposed change to correct that. OLD: -------------------------------+---------+---------+ Cache unauthenticated | Yes | No | credential for future refs | | | -------------------------------+---------+---------+ SSH requires proper warnings and options in the applications to reject unauthenticated credentials, while BTNS will accept those automatically if they match the corresponding policy entries. Once SSH accepts a credential for the first time, it should be cached, and can be reused automatically without further warnings. NEW: -------------------------------+---------+---------+ Cache unauthenticated |Required | Allowed | credential for future refs | | | -------------------------------+---------+---------+ SSH requires proper warnings and options in the applications to reject unauthenticated credentials, while BTNS will accept those automatically if they match the corresponding policy entries. Once SSH accepts a credential for the first time, it should be cached, and can be reused automatically without further warnings. BTNS credentials can be cached for future use, but there is no security advantage to doing so, as a new unauthenticated credential that is allowed by the policy entries will be automatically accepted, and BTNS-IPsec does not require IPsec to reuse credentials in a manner similar to SSH. When IPsec does reuse unauthenticated credentials, there may be implementation advantages to caching them in BTNS-IPsec. The next problem is that the last paragraph in the section speculates about extending BTNS to duplicate SSH's functionality. It needs to be clearer that it is speculating about this, and acknowledge Sam's point that if one wants SSH-like functionality, one runs into issues. OLD: On the other hand, there are two key issues with BTNS-IPsec: whether to cache credentials and if so, how to treat cached credentials. The main reason to cache a credential is to treat it differently the next time it appears. For SAB without Channel Binding, the credentials should not be cached because they remain unauthenticated, and BTNS- IPsec does not require IPsec to reuse credentials in a manner similar to SSH. For CBB, credential caching and verification are usually done at the higher layer protocols or applications, as well be discussed in the next section. Caching credentials at the BTNS-IPsec is not as important because the channel binding will bind whatever credentials are presented (new or cached) to the higher layer protocol identity. NEW: SSH-style credential caching for reuse with SAB could be addressed by future extension(s) to BTNS-IPsec; such extension(s) would need to provide warnings about and a mechanism for user acceptance of unauthenticated credentials in order to establish a level of assurance of authentication comparable to SSH's "Leap of Faith", and would also need to deal with issues caused by the absence of identities in BTNS-IPsec. At best a cached BTNS-IPsec credential reauthenticates the network-layer source of traffic when the credential is reused - in contrast, SSH credential reuse reauthenticates an identity. Network layer re-authentication is further complicated by the ability of NATs to cause multiple independent network layer sources of traffic to appear to be one source (potentially requiring acceptance and caching of multiple BTNS-IPsec credentials), the ability of multihoming to cause one network layer source of traffic to appear to be multiple sources (potentially triggering unexpected warnings and requiring a user to re-accept the same BTNS-IPsec credential), and interactions with both mobility and address ownership changes (potentially requiring controlled BTNS-IPsec credential reassignment and invalidation). These issues are left to be addressed by possible future work on addition of "Leap of Faith" functionality to BTNS-IPsec. In contrast, for CBB, credential caching and verification are usually done at the higher layer protocols or applications, as will be discussed in the next section. Caching credentials for CBB at the BTNS-IPsec level is not as important because the channel binding will bind whatever credentials are presented (new or cached) to the higher layer protocol identity. Sam has reviewed these proposed changes and pronounced them acceptable. The authors propose to produce a -06 version of the draft with these changes (plus some other minor edits) that Sam would then take forward for IESG approval. Thanks, --David (for the draft authors) ---------------------------------------------------- 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 ---------------------------------------------------- From mcr at sandelman.ca Wed Jul 25 14:55:25 2007 From: mcr at sandelman.ca (Michael Richardson) Date: Wed, 25 Jul 2007 16:55:25 -0500 Subject: [anonsec] nat traversal scoping In-Reply-To: References: Message-ID: Black_David at emc.com wrote: > Taking the areas in reverse order, the current sections 6.1 and > 6.2 of the draft essentially say that NAT, mobility and multihoming > issues are out of scope. Whether they are out of scope is a longer I am going to deal with each one seperately. This email is about NAT. Q: If you remove the statement that they are out of scope, does this force us to deal with these issues now? I would prefer not to deal with the issue of NAT-traversal until after we have some running, interoperable code that does connection-latching. I think that that connection-latching + transport mode solves some NAT traversal issues. The remaining concerns are that we have to be very clear about what kind of phase 1 IDs that we use --- on that we can get rough consensus after we have running code. As far as I understand process, deciding to make NAT in scope and the deal with it in later documents requires adding milestone items to our charter. I believe that it is therefore the same as excluding NAT from scope and then rechartering later on? From mcr at sandelman.ca Wed Jul 25 22:20:09 2007 From: mcr at sandelman.ca (Michael Richardson) Date: Thu, 26 Jul 2007 00:20:09 -0500 Subject: [anonsec] comments on the BTNS core I-D In-Reply-To: References: Message-ID: Stephen Kent wrote: > Sorry I didn't get these out sooner. thank you very much. Nico and I printed your PDF and worked with it from 4pm to 9pm tonight. (diff -u output would have been much easier to deal with) Trivial stuff: We fixed all the [A] notation to consistently talk about hosts with [] around them. Thank you for your suggestions on slightly different choices in english. Most importantly, we did split up most of the 4-line sentences. Important things: a number of things we removed because references to documents which now say things better made sense. I attach a diff below. The only thing we didn't resolve was your comment: "No mention of what form of ID C asserted (i)n its IKE exchange with SG-A" (this refers to page 7, point 4, "C does not match PAD entries..." This is an important question. We weren't sure we understood the question. We aren't sure that it matters, but we want to understand what concerns you might have behind the question. We think that the the only things that matters is that [C] can't assert [Q]'s identity, or [B]'s identity, because those IDs are in the PAD as non-BTNS, and therefore [SG-A] must have some way to positively identify those nodes public keys. So, C can't assert itself as being [C] or [Q] without the appropriate private key. That's standard IPsec processing. Was that your concern? Or something else. The diff, change bar version at: http://www.sandelman.ca/SSW/ietf/ipsec/btns/ietf-btns-core-04-change.txt --- ietf-btns-core-03.txt 2007-07-25 22:41:12.000000000 -0500 +++ ietf-btns-core-04.txt 2007-07-25 20:41:14.000000000 -0500 @@ -1,16 +1,15 @@ - NETWORK WORKING GROUP N. Williams Internet-Draft Sun Intended status: Standards Track M. Richardson -Expires: October 3, 2007 SSW - April 2007 +Expires: January 26, 2008 SSW + July 25, 2007 Better-Than-Nothing-Security: An Unauthenticated Mode of IPsec - draft-ietf-btns-core-03.txt + draft-ietf-btns-core-04.txt Status of this Memo @@ -35,7 +34,7 @@ The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on October 3, 2007. + This Internet-Draft will expire on January 26, 2008. Copyright Notice @@ -53,9 +52,9 @@ -Williams & Richardson Expires October 3, 2007 [Page 1] +Williams & Richardson Expires January 26, 2008 [Page 1] -Internet-Draft BTNS IPsec April 2007 +Internet-Draft BTNS IPsec July 2007 Abstract @@ -64,10 +63,10 @@ protocols, such as IKEv1 and IKEv2, to setup "unauthenticated" security associations (SAs) for use with the IPsec Encapsulating Security Payload (ESP) and the IPsec Authentication Header (AH). No - IKE extensions are needed, but Peer Authorization Database (PAD) and - Security Policy Database (SPD) extensions are specified. - Unauthenticated IPsec is herein referred to by its popular acronym, - "BTNS" (Better Than Nothing Security). + changes to IKEv2 bits-on-the-wire are required, but Peer + Authorization Database (PAD) and Security Policy Database (SPD) + extensions are specified. Unauthenticated IPsec is herein referred + to by its popular acronym, "BTNS" (Better Than Nothing Security). Table of Contents @@ -75,20 +74,20 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions used in this document . . . . . . . . . . . . . 3 2. BTNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . 6 - 3.1. Example #1: sgA . . . . . . . . . . . . . . . . . . . . . . 6 - 3.2. Example #2: Q . . . . . . . . . . . . . . . . . . . . . . . 8 - 3.3. Example #3: C . . . . . . . . . . . . . . . . . . . . . . . 9 - 3.4. Miscaellaneous examples . . . . . . . . . . . . . . . . . . 9 + 3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . 5 + 3.1. Example #1: A security gateway . . . . . . . . . . . . . . . 5 + 3.2. Example #2: A mixed end-system . . . . . . . . . . . . . . . 7 + 3.3. Example #3: A BTNS-only system . . . . . . . . . . . . . . . 8 + 3.4. Miscellaneous comments . . . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . 10 4.1. Connection-Latching and Channel Binding . . . . . . . . . . 10 4.2. Leap-of-Faith (LoF) for BTNS . . . . . . . . . . . . . . . . 10 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 - 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 6.1. Normative References . . . . . . . . . . . . . . . . . . . . 13 - 6.2. Informative References . . . . . . . . . . . . . . . . . . . 13 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14 - Intellectual Property and Copyright Statements . . . . . . . 15 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11 + 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 6.1. Normative References . . . . . . . . . . . . . . . . . . . . 12 + 6.2. Informative References . . . . . . . . . . . . . . . . . . . 12 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 13 + Intellectual Property and Copyright Statements . . . . . . . 14 @@ -109,27 +108,33 @@ -Williams & Richardson Expires October 3, 2007 [Page 2] +Williams & Richardson Expires January 26, 2008 [Page 2] -Internet-Draft BTNS IPsec April 2007 +Internet-Draft BTNS IPsec July 2007 1. Introduction Here we describe how to establish unauthenticated IPsec SAs using - IKEv1 [RFC2408] [RFC2409] or IKEv2 [RFC4306] and unauthenticated - public keys. No new on-the-wire protocol elements are added to IKE - or IKEv2. + IKEv2 [RFC4306] and unauthenticated public keys. No new on-the-wire + protocol elements are added to IKEv2. The [RFC4301] processing model is assumed. This document does not define an opportunistic BTNS mode of IPsec - whereby nodes may fallback on unprotected IP when their peers do not - support IKE or IKEv2, nor does it describe "leap-of-faith" modes, or + whereby nodes may fallback to unprotected IP when their peers do not + support IKEv2, nor does it describe "leap-of-faith" modes, or "connection latching." See [I-D.ietf-btns-prob-and-applic] for the applicability and uses of - BTNS. + BTNS and definitions of these terms. + + This document describes BTNS in terms of IKEv2 and [RFC4301]'s + concepts. There is no reason why the same methods cannot be used + with IKEv1 [RFC2408] [RFC2409] and [RFC2401], however, those + specifications do not include the PAD concepts, and therefore it may + not be possible to implement BTNS on all compliant RFC2401 + implementations. 1.1. Conventions used in this document @@ -159,136 +164,74 @@ - - - - - - -Williams & Richardson Expires October 3, 2007 [Page 3] +Williams & Richardson Expires January 26, 2008 [Page 3] -Internet-Draft BTNS IPsec April 2007 +Internet-Draft BTNS IPsec July 2007 2. BTNS - The IPsec processing model, IKE and IKEv2 are hereby modified as - follows: + The IPsec processing model is hereby modified as follows: o A new ID type is added, 'PUBLICKEY'; IDs of this type have public keys as values. This ID type is not used on the wire. - o A BTNS-specific PAD entry. This entry is intended to be the last - entry in the PAD when BTNS is enabled. A peer that matches no - other PAD entries is to be "authenticated" by verifying that the - signature in its AUTH (or SIG) payload in the IKEv2 (or v1) - exchange with the public key from the peer's CERT payload. The - peer's ID MUST then be coerced to be of 'PUBLICKEY' type with the - peer's public key as its value. + o A BTNS-specific PAD entry. This entry MUST be the last entry in + the PAD when BTNS is enabled. A peer that matches no other PAD + entries is to be "authenticated" by verifying that the signature + in its AUTH payload in the IKEv2 exchange with the public key from + the peer's CERT payload. The peer's ID MUST then be coerced to be + of 'PUBLICKEY' type with the peer's public key as its value. o A new flag for SPD entries: 'BTNS_OK'. Traffic to/from peers that - match the BTNS PAD entry will only match SPD entries that have the + match the BTNS PAD entry will match only SPD entries that have the BTNS_OK flag set. The SPD may be searched by address or by ID (of - type PUBLICKEY, of course, for BTNS peers), as per the IPsec - processing model [RFC4301]; searching by ID in this case requires - creation of SPD entries that are bound to public key values (this - could be used to build "leap-of-faith" behaviour, for example). + type PUBLICKEY, for BTNS peers), as per the IPsec processing model + [RFC4301]; searching by ID in this case requires creation of SPD + entries that are bound to public key values (this could be used to + build "leap-of-faith" [I-D.ietf-btns-prob-and-applic] Section 4.2 + behaviour, for example). Nodes MUST reject IKE_SA proposals from peers that match non-BTNS PAD entries but fail to authenticate properly. - Nodes wishing to be treated as BTNS nodes by their peers SHOULD use - bare RSA key CERT payloads and MAY use certificates known not to have - been pre-shared with their peers or outside their trust anchors - (e.g., self-signed certificates). RSA keys for use in BTNS may be - generated at any time, but "connection latching" - [I-D.ietf-btns-connection-latching] requires that they remain - constant between IKE exchanges setting up SAs for latched - connections. - - To preserve standard IPsec access control semantics BTNS responders - MUST NOT allow BTNS peers to assert addresses which could be asserted - by non-BTNS peers. This can be achieved by processing the PAD in - order both, when peers authenticate and when BTNS peers negotiate - child SAs -- in the first case the PAD is searched for a matching PAD + Nodes wishing to be treated as BTNS nodes by their peers MUST include + bare RSA key CERT payloads. Nodes MAY also include any number of + certificates that bind the same public key. These certificates need + not to have been pre-shared with their peers (e.g., because ephermal, + self-signed). RSA keys for use in BTNS may be generated at any time, + but "connection latching" [I-D.ietf-btns-connection-latching] + requires that they remain constant between IKEv2 exchanges that are + used to establish SAs for latched connections. + + To preserve standard IPsec access control semantics the BTNS PAD + entry MUST be last (lowest priority), and it MUST have ID constraints + that do not overlap those of other PAD entries. + + This can easily be implemented by searching the PAD twice. Once when + BTNS peers authenticate and a second time when BTNS peers negotiate + child SAs. In the first pass the PAD is searched for a matching PAD entry as usual, and in the second it is searched to make sure that BTNS peers' asserted child SA traffic selectors do not conflict with - non-BTNS PAD entries. Note that in general, if there are multiple - PAD entries with wildcard matching on peer ID then all but the last - one should constrain the traffic selectors for matching peers. - - Note that nodes may unwittingly match peers' BTNS PAD entries and be - - - -Williams & Richardson Expires October 3, 2007 [Page 4] - -Internet-Draft BTNS IPsec April 2007 - - - authenticated as BTNS nodes. This may be used in specifying the - "latching" of traffic flows to peer IDs - [I-D.ietf-btns-connection-latching]. - - - - - - - - - - - - - - - - - + non-BTNS PAD entries. - - - - - - - - - - - - - - - - - - - - - - - - - -Williams & Richardson Expires October 3, 2007 [Page 5] +Williams & Richardson Expires January 26, 2008 [Page 4] -Internet-Draft BTNS IPsec April 2007 +Internet-Draft BTNS IPsec July 2007 3. Usage Scenarios In order to explain the above rules a number of scenarios will be - postulated. The goal here is to demonstrate that the above rules are - both sufficient and required. + examined. The goal here is to persuade the reader that the above + rules are both sufficient and necessary. - To explain the scenarios a reference diagram describing a canonical + To explain the scenarios a reference diagram describing an example network will be used. It is as follows: [Q] [R] @@ -305,45 +248,50 @@ systems are security gateways: SG-A, SG-B, protecting networks on which [A] and [B] reside. There is a node [Q] which is IPsec and BTNS capable, and node [R] is a simple node, with no IPsec or BTNS - capability. Nodes [C] and [D] are BTNS capable. We will examine - interactions between the BTNS enabled nodes, and the IPsec enabled - nodes. + capability. Nodes [C] and [D] are BTNS capable. + + Nodes [C] and [Q] have fixed addresses. Node [D] has a non-fixed + address. - Nodes C and Q have a fixed addresses. Node D non-fixed addresses. + We will examine how these various nodes communicate with node SG-A, + and/or how SG-A rejects communications with some such nodes. In the + first example, we examine SG-A's point of view. In the second + example we look at Q's point of view. In the third example we look + at C's point of view. PI is the Public Internet ("The Wild"). -3.1. Example #1: sgA +3.1. Example #1: A security gateway - The machine that we will care about will be [SG-A], a firewall device - of some kind which we wish to configure to respond to BTNS - connections from [C] + The machine that we will care in this example is [SG-A], a firewall + device of some kind which we wish to configure to respond to BTNS + connections from [C]. - SG-A has the following "VPN" PAD and SPD entries: + SG-A has the following PAD and SPD entries: Child SA Rule Remote ID IDs allowed SPD Search by ---- --------- ----------- ------------- - 1 by-IP - 2 by-IP - 3 PUBLICKEY:any ANY by-IP - - The last entry is the BTNS entry. -Williams & Richardson Expires October 3, 2007 [Page 6] +Williams & Richardson Expires January 26, 2008 [Page 5] -Internet-Draft BTNS IPsec April 2007 +Internet-Draft BTNS IPsec July 2007 + + 1 by-IP + 2 by-IP + 3 PUBLICKEY:any ANY by-IP + + The last entry is the BTNS entry. Figure 2: SG-A PAD table - Here is any address that is not part of A's network, and is not - claimed by any other entry. Note that sgA's PAD entry has one and - only one wildcard PAD entry: the BTNS catch-all PAD entry, so, as - described in Section 2. + Note that [SG-A]'s PAD entry has one and only one wildcard PAD entry: + the BTNS catch-all PAD entry as the last entry, as described in + Section 2. and are from [RFC4301] section 4.4.3 @@ -352,108 +300,114 @@ Rule Local Remote Next Layer BTNS Action addr addr Protocol ok ---- ----- ------ ---------- ---- ----------------------- - 1 A R ANY N/A BYPASS - 2 A Q ANY no PROTECT(ESP,tunnel,AES, + 1 [A] [R] ANY N/A BYPASS + 2 [A] [Q] ANY no PROTECT(ESP,tunnel,AES, SHA256) - 3 A B-net ANY no PROTECT(ESP,tunnel,AES, + 3 [A] B-net ANY no PROTECT(ESP,tunnel,AES, SHA256) - 4 A ANY ANY yes PROTECT(ESP,transport, + 4 [A] ANY ANY yes PROTECT(ESP,transport, integr+conf) - Figure 3: SG-A SPD table + Figure 3: [SG-A] SPD table - The processing by sgA of various peers then is as follows: + The processing by [SG-A] of SA establishment attempts by various + peers is as follows: - o Q does not match PAD entry #1, but does match PAD entry #2; PAD - processing stops, then the SPD is searched by Q's ID to find entry - #2; CHILD SAs are then allowed that have sgA's and Q's addresses - as the end-point addresses. + o [Q] does not match PAD entry #1, but does match PAD entry #2; PAD + processing stops, then the SPD is searched by [Q]'s ID to find + entry #2; CHILD SAs are then allowed that have [SG-A]'s and [Q]'s + addresses as the end-point addresses. + + o [SG-B] matches PAD entry #1; PAD processing stops, then the SPD is + searched by [SG-B]'s ID to find SPD entry #3; CHILD SAs are then + allowed that have [SG-A]'s address and any addresses from B's + network as the end-point addresses. - o sgB matches PAD entry #1; PAD processing stops, then the SPD is - searched by sgB's ID to find SPD entry #3; CHILD SAs are then - allowed that have sgA's address and any addresses from B's network - as the end-point addresses. + o [R] does not initiate any IKE SAs; its traffic to [A] is bypassed + by SPD entry #1. - o R does not initiate any IKE_SAs; its traffic to A is bypassed by - SPD entry #1. - - o C does not match PAD entries #1 or #2, but does match entry #3, - the BTNS wildcard PAD entry; the SPD is searched by C's address + o [C] does not match PAD entries #1 or #2, but does match entry #3, + the BTNS wildcard PAD entry; the SPD is searched by [C]'s address and SPD entry #4 is matched. CHILD SAs are then allowed that have - sgA's address and C's address as the end-point addresses provided - that C's address is neither Q's nor any of B's (see Section 2). - - o Rogue BTNS nodes attempting to assert Q's or B's addresses will - either match the PAD entries for Q or B and fail to authenticate - as Q or B, in which case they are rejected, or they will match PAD -Williams & Richardson Expires October 3, 2007 [Page 7] +Williams & Richardson Expires January 26, 2008 [Page 6] -Internet-Draft BTNS IPsec April 2007 +Internet-Draft BTNS IPsec July 2007 - entry #3 but will not be allowed to create CHILD SAs with Q's or - B's addresses as traffic selectors. + [SG-A]'s address and [C]'s address as the end-point addresses + provided that [C]'s address is neither [Q]'s nor any of [B]'s (see + Section 2). - o Rogue BTNS nodes attempting to assert C's address are allowed. - Protection for C requires additional bindings of C's specific BTNS - ID (that is, its public key) to its traffic flows through - connection-latching and channel binding, or leap-of-faith, none of - which are described here. + o A rogue BTNS node attempting to assert [Q]'s or [B]'s addresses + will either match the PAD entries for [Q] or [B] and fail to + authenticate as [Q] or [B], in which case they are rejected, or + they will match PAD entry #3 but will not be allowed to create + CHILD SAs with [Q]'s or [B]'s addresses as traffic selectors. -3.2. Example #2: Q + o A rogue BTNS nodes attempting to assert [C]'s address will + succeed. Protection for [C] requires additional bindings of [C]'s + specific BTNS ID (that is, its public key) to its traffic flows + through connection-latching and channel binding, or leap-of-faith, + none of which are described here. - Q is either a BITS or native IPsec implementation; if it is a native - implementation it may have IPsec-aware applications, specifically - NFSv4 (TCP port 2049). +3.2. Example #2: A mixed end-system - In any case, Q wants to communicate with A generally, and with BTNS - peers for NFSv4 only. It's PAD and SPD are configured as follows: + [Q] is an NFSv4 server. + + [Q] is a native IPsec implementation, and it's NFSv4 implementation + is IPsec-aware. + + [Q] wants to protect all traffic with [A]. [Q] also wants to protect + NFSv4 traffice with all peers. It's PAD and SPD are configured as + follows: Child SA Rule Remote ID IDs allowed SPD Search by ---- --------- ----------- ------------- - 1 by-IP + 1 <[A]'s ID> <[A]'s address> by-IP 2 PUBLICKEY:any ANY by-IP The last entry is the BTNS entry. - Figure 4: Q PAD table + Figure 4: [Q] PAD table Rule Local Remote Next Layer BTNS Action addr addr Protocol ok ---- ----- ------ ---------- ---- ----------------------- - 1 Q A ANY no PROTECT(ESP,tunnel,AES, + 1 [Q] [A] ANY no PROTECT(ESP,tunnel,AES, SHA256) - 2 Q ANY ANY yes PROTECT(ESP,transport, - and integr+conf) - port - 2049 - - Figure 5: SG-A SPD table + 2 [Q] ANY ANY yes PROTECT(ESP,transport, + with integr+conf) + port 2049 - The same analysis shown above in Section 3.1 applies here with - respect to sgA, C and rogue peers, except that C is allowed only - access to the NFSv4 service on Q. Additionally sgB is treated as a - BTNS peer as it is not known to Q, and therefore any host behind sgB - can access the NFSv4 service on Q (and, because Q has no formal - relationship with sgB, rogues can impersonate B). -Williams & Richardson Expires October 3, 2007 [Page 8] +Williams & Richardson Expires January 26, 2008 [Page 7] -Internet-Draft BTNS IPsec April 2007 +Internet-Draft BTNS IPsec July 2007 + + Figure 5: [Q] SPD table -3.3. Example #3: C + The same analysis shown above in Section 3.1 applies here with + respect to [SG-A], [C] and rogue peers. The second SPD entry permits + any BTNS capable node to negotiate a port-specific SA to port 2049, + the port on which NFSv4 runs. Additionally [SG-B] is treated as a + BTNS peer as it is not known to [Q], and therefore any host behind + [SG-B] can access the NFSv4 service on [Q]. As [Q] has no formal + relationship with [SG-B], rogues can impersonate [B] (i.e., assert + [B]'s addresses). + +3.3. Example #3: A BTNS-only system - C only supports BTNS and wants to use BTNS to protect NFSv4 traffic. - It's PAD and SPD are configured as follows: + [C] supports only BTNS and wants to use BTNS to protect NFSv4 + traffic. It's PAD and SPD are configured as follows: Child SA @@ -461,7 +415,7 @@ ---- --------- ----------- ------------- 1 PUBLICKEY:any ANY by-IP - The last entry is the BTNS entry. + The last (and only) entry is the BTNS entry. Figure 6: Q PAD table @@ -469,101 +423,53 @@ Rule Local Remote Next Layer BTNS Action addr addr Protocol ok ---- ----- ------ ---------- ---- ----------------------- - 1 C ANY ANY yes PROTECT(ESP,transport, - and integr+conf) + 1 [C] ANY ANY yes PROTECT(ESP,transport, + with integr+conf) port 2049 - 2 C ANY ANY N/A BYPASS + 2 [C] ANY ANY N/A BYPASS Figure 7: SG-A SPD table -3.4. Miscaellaneous examples - - If sgA were not BTNS-capable then it would not have PAD and SPD - entries #3 and #4, respectively. Then C would be rejected as usual - under the standard IPsec model [RFC4301]. + The analysis from Section 3.1 applies as follows: - Similarly, if Q were not BTNS-capable then it would not have PAD and - SPD entries #2. Then C would be rejected as usual under the standard - IPsec model [RFC4301]. + o Communication with [Q] on port 2049 matches SPD entry number 1. + This causes [C] to initiate an IKEv2 exchange with [Q]. The PAD + entry on [C] causes it to not care what identity [Q] asserts. + Further authentication (and channel binding) could occur within + the NFSv4 protocol. + o Communication with [A], [B] or any other internet machine - - - - - - - - - - -Williams & Richardson Expires October 3, 2007 [Page 9] +Williams & Richardson Expires January 26, 2008 [Page 8] -Internet-Draft BTNS IPsec April 2007 +Internet-Draft BTNS IPsec July 2007 -4. Security Considerations + (including [Q]), occurs in the clear, so long as it is not on port + 2049. - Unauthenticated security association negotiation is subject to MITM - attacks and should be used with care. Where security infrastructures - are lacking this may indeed be better than nothing. + o All analysis about rogue BTNS nodes applies, but they can only + assert SAs for port 2049. - Use with applications that bind authentication at higher network - layers to secure channels at lower layers may provide one secure way - to use unauthenticated IPsec, but this is not specified herein. - - Use of multiple wildcard PAD entries can be problematic. Where it is - important that addresses and node identities be tightly bound it is - important that such PAD entries limit the addresses that matching - peers can assert for their CHILD SAs to non-overlapping address - spaces. In practice this may be difficult to configure; if it is not - feasible to configure systems in this way then either BTNS should not - be used or BTNS PAD entries should constrain matching peers only to - using services for which authentication is not normally necessary or - where IPsec-aware/connection-latching applications are used. - -4.1. Connection-Latching and Channel Binding +3.4. Miscellaneous comments - BTNS is subject to MITM attacks. One way to protect against MITM - attacks subsequent to initial communications is to use "connection - latching" [I-D.ietf-btns-connection-latching], whereby ULPs cooperate - with IPsec in native IPsec implementations to bind individual packet - flows to sequences of SAs whose end-point IDs (public keys, in the - case of BTNS end-points) and other characteristics (e.g., quality of - protection) must all be the same. - - MITMs can be detected by using application-layer authentication - frameworks and/or mechanisms, such as the GSS-API [RFC2743], with - channel binding [I-D.williams-on-channel-binding], where the channels - to be bound to application-layer authentication are latched - connections and where the channel bindings data strongly identify the - end-points of the latched connection (e.g., the public keys of the - end-points). + If [SG-A] were not BTNS-capable then it would not have PAD and SPD + entries #3 and #4, respectively in example #1. Then [C] would be + rejected as usual under the standard IPsec model [RFC4301]. -4.2. Leap-of-Faith (LoF) for BTNS + Similarly, if [Q] were not BTNS-capable then it would not have PAD + and SPD entries #2 in example #2. Then [C] would be rejected as + usual under the standard IPsec model [RFC4301]. - "Leap of faith" is the term generally used for the habit of accepting - that a given key identifies a peer that one wanted to talk to without - strong evidence for that proposition. Specifically this is a common - mode of operation for Secure Shell [RFC4251] clients where, when a - server is encountered for the first time the client may ask the user - whether to accept the server's public key as its identity and, if so, - records the server's name (as given by the user) and public key in a - database. -Williams & Richardson Expires October 3, 2007 [Page 10] - -Internet-Draft BTNS IPsec April 2007 - Leap of Faith can work in a similar way for BTNS nodes, but it is - currently still being designed and specified by the IETF BTNS WG. @@ -594,17 +500,54 @@ +Williams & Richardson Expires January 26, 2008 [Page 9] + +Internet-Draft BTNS IPsec July 2007 +4. Security Considerations + Unauthenticated security association negotiation is subject to MITM + attacks and should be used with care. Where security infrastructures + are lacking this may indeed be better than nothing. + Use with applications that bind authentication at higher network + layers to secure channels at lower layers may provide one secure way + to use unauthenticated IPsec, but this is not specified herein. + The BTNS PAD entry must be last and its child SA ID constraints must + be non-overlapping with any other PAD entry, as described in section + 2, in order to ensure that no BTNS peer can impersonate another IPsec + non-BTNS peer. +4.1. Connection-Latching and Channel Binding + BTNS is subject to MITM attacks. One way to protect against MITM + attacks subsequent to initial communications is to use "connection + latching" [I-D.ietf-btns-connection-latching]. In connection + latching, ULPs cooperate with IPsec to bind discrete packet flows to + sequences of similar SAs. Connection latching requires native IPsec + implementations. + MITMs can be detected by using application-layer authentication + frameworks and/or mechanisms, such as the GSS-API [RFC2743], with + channel binding [I-D.williams-on-channel-binding]. IPsec "channels" + are nothing other than latched connnections. +4.2. Leap-of-Faith (LoF) for BTNS + "Leap of faith" is the term generally used when a user accepts the + assertion that a given key identifies a peer on the first + communication, despite a lack of strong evidence for that assertion, + and then remembers this association for future communications. + Specifically this is a common mode of operation for Secure Shell + [RFC4251] client. When a server is encountered for the first time + the Secure Shell client may ask the user whether to accept the + server's public key. If so, records the server's name (as given by + the user) and public key in a database. + Leap of faith can work in a similar way for BTNS nodes, but it is + currently still being designed and specified by the IETF BTNS WG. @@ -613,9 +556,9 @@ -Williams & Richardson Expires October 3, 2007 [Page 11] +Williams & Richardson Expires January 26, 2008 [Page 10] -Internet-Draft BTNS IPsec April 2007 +Internet-Draft BTNS IPsec July 2007 5. IANA Considerations @@ -669,9 +612,9 @@ -Williams & Richardson Expires October 3, 2007 [Page 12] +Williams & Richardson Expires January 26, 2008 [Page 11] -Internet-Draft BTNS IPsec April 2007 +Internet-Draft BTNS IPsec July 2007 6. References @@ -694,14 +637,17 @@ [I-D.ietf-btns-prob-and-applic] Touch, J., "Problem and Applicability Statement for Better Than Nothing Security (BTNS)", - draft-ietf-btns-prob-and-applic-05 (work in progress), - February 2007. + draft-ietf-btns-prob-and-applic-03 (work in progress), + June 2006. [I-D.williams-on-channel-binding] Williams, N., "On the Use of Channel Bindings to Secure Channels", draft-williams-on-channel-binding-00 (work in progress), August 2006. + [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the + Internet Protocol", RFC 2401, November 1998. + [RFC2408] Maughan, D., Schneider, M., and M. Schertler, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998. @@ -722,12 +668,9 @@ - - - -Williams & Richardson Expires October 3, 2007 [Page 13] +Williams & Richardson Expires January 26, 2008 [Page 12] -Internet-Draft BTNS IPsec April 2007 +Internet-Draft BTNS IPsec July 2007 Authors' Addresses @@ -781,9 +724,9 @@ -Williams & Richardson Expires October 3, 2007 [Page 14] +Williams & Richardson Expires January 26, 2008 [Page 13] -Internet-Draft BTNS IPsec April 2007 +Internet-Draft BTNS IPsec July 2007 Full Copyright Statement @@ -837,6 +780,5 @@ -Williams & Richardson Expires October 3, 2007 [Page 15] +Williams & Richardson Expires January 26, 2008 [Page 14] - From mcr at sandelman.ca Wed Jul 25 23:18:38 2007 From: mcr at sandelman.ca (Michael Richardson) Date: Thu, 26 Jul 2007 01:18:38 -0500 Subject: [anonsec] multihoming and btns In-Reply-To: References: Message-ID: Black_David at emc.com wrote: > Taking the areas in reverse order, the current sections 6.1 and > 6.2 of the draft essentially say that NAT, mobility and multihoming > issues are out of scope. Whether they are out of scope is a longer I believe that we should make mobility out of scope. Actually, I am uncertain I know what it means to have mobility and BTNS. Someone could comtemplate mixing MOBIKE and BTNS. I don't initially see a reason why this can't be done at the protocol level. The issue is that you can't construct a sane/safe security policy. The major concern is that I think that BTNS will mostly be used for host/32<->host/32 connections, or in transport mode. I.e. BTNS will be constrained to permit some remote host to assert it's own IP. MOBIKE, however, deals with someip/32===changingip/32...host connections, and deals with how to change "changingip". I don't see how you can mix these things. If you write a security policy that says that anyone out there can assert any IP... well, it's not much of a policy. The only other kind of mobility that I can see being mixed in with BTNS is stuff described in the IFARE stuff. Let's leave that out of scope for BTNS as well. I don't think we can make mobility in scope. From mcr at sandelman.ca Wed Jul 25 23:37:40 2007 From: mcr at sandelman.ca (Michael Richardson) Date: Thu, 26 Jul 2007 01:37:40 -0500 Subject: [anonsec] multihoming and BTNS In-Reply-To: References: Message-ID: Black_David at emc.com wrote: > Taking the areas in reverse order, the current sections 6.1 and > 6.2 of the draft essentially say that NAT, mobility and multihoming > issues are out of scope. Whether they are out of scope is a longer > discussion, but the approach agreed to in this afternoon's btns > meeting is to remove Sections 6.1 and 6.2 from the problem and > applicability statement draft, and deal with whether the issues > are in scope and what to do about them if they are in the context > of the WG's other drafts. What could it mean for BTNS to be multihomed? Let's assume that we have a ULP that deals well with being multihomed... SCTP, and it wants to use channel bindings to secure all of the routes. A security concern might be that something like this might happen: +-------+ b2 | B |---\ +-------+ \ 2 b1 | \ | +-----+ | 1 | M | a1| +-----+ +------+ / | A |----/ 3 +------+ a2 Let's say we start the connection on link 1, using SCTP. They do IPsec, and with a channel binding, bind link 1 (a1...b1) SCTP exchanges addresses a2/b2, and at some point decides to failover to that link. Traffic across that link causes a new IPsec connection, but it is intersepted by M. As the application had used channel binding to offload the privacy and integrity protection to IPsec, the link through M can now be intercepted. Either the application must become aware that a new channel binding is necessary, or the IPsec connection for a2...b2 must be related to the one for a1..b1. What this really means is that connection latching must in fact latch the identities used in a1...b1 to identities to be used for a2...b2. This is really no different from the case where a1...b1 must be rekeyed. The new SA must use the same identities as the old one. I don't think that the connection latching document addresses this issue directly, but I think that it could spell out this case, and a connection latching capable SCTP stack would be able to do the right thing. So, I don't have a problem keeping this in scope. From mcr at sandelman.ca Thu Jul 26 00:01:40 2007 From: mcr at sandelman.ca (Michael Richardson) Date: Thu, 26 Jul 2007 02:01:40 -0500 Subject: [anonsec] mobility and btns In-Reply-To: References: Message-ID: wrong subject. sorry. Michael Richardson wrote: > Black_David at emc.com wrote: >> Taking the areas in reverse order, the current sections 6.1 and >> 6.2 of the draft essentially say that NAT, mobility and multihoming >> issues are out of scope. Whether they are out of scope is a longer > > I believe that we should make mobility out of scope. > Actually, I am uncertain I know what it means to have mobility and BTNS. > > Someone could comtemplate mixing MOBIKE and BTNS. I don't initially see > a reason why this can't be done at the protocol level. > The issue is that you can't construct a sane/safe security policy. > The major concern is that I think that BTNS will mostly be used for > host/32<->host/32 connections, or in transport mode. I.e. BTNS will be > constrained to permit some remote host to assert it's own IP. > > MOBIKE, however, deals with someip/32===changingip/32...host connections, > and deals with how to change "changingip". I don't see how you can mix these > things. If you write a security policy that says that anyone out there can > assert any IP... well, it's not much of a policy. > > The only other kind of mobility that I can see being mixed in with BTNS > is stuff described in the IFARE stuff. Let's leave that out of scope for > BTNS as well. > > I don't think we can make mobility in scope. > > > > > _______________________________________________ > From kent at bbn.com Thu Jul 26 11:48:23 2007 From: kent at bbn.com (Stephen Kent) Date: Thu, 26 Jul 2007 14:48:23 -0400 Subject: [anonsec] comments on the BTNS core I-D In-Reply-To: References: Message-ID: At 12:20 AM -0500 7/26/07, Michael Richardson wrote: >Stephen Kent wrote: >> Sorry I didn't get these out sooner. > >thank you very much. > >Nico and I printed your PDF and worked with it from 4pm to 9pm tonight. >(diff -u output would have been much easier to deal with) sorry. I always import the text version of an I-D into MS Word, where I can mark it up and add comments and have both sorts of changes be easily visible. I then convert to a PDF, so everyone can read the results, and still see the changes. As someone who does not regularly use Unix for text editing, I don't find diff's helpful, something reaffirmed by looking at the diff you provided at the end of this message :-). >... >The only thing we didn't resolve was your comment: "No mention of what form >of ID C asserted (i)n its IKE exchange with SG-A" >(this refers to page 7, point 4, "C does not match PAD entries..." > >This is an important question. We weren't sure we understood the question. >We aren't sure that it matters, but we want to understand what concerns >you might have behind the question. > >We think that the the only things that matters is that >[C] can't assert [Q]'s identity, or [B]'s identity, because those IDs are in >the PAD as non-BTNS, and therefore [SG-A] must have some way to positively >identify those nodes public keys. So, C can't assert itself as being [C] or >[Q] without the appropriate private key. That's standard IPsec processing. > >Was that your concern? Or something else. > my comment appears on page 7, in reference to example #1. I asked the question because the PAD description in 4301 says how to search the PAD based on matching the ID asserted in IKE against the PAD. there are words early in this document (page 4) about the new ID type "PUBLICKEY" and the need to coerce the ID offered by a BTNS peer into this new ID type, which is never transferred over the wire via IKE. (That raises the question of whether we ought to describe this as an IKE ID type, but I'll let Charlue Kaufman comment on that later, if he wishes.) So, I was wondering if the kind of ID asserted by C in KE was relevant to the example, or any example, based on the wording here. maybe what should happen is to refine the description of the modified PAD search algorithm in section 2, which is rather brief. Maybe it could say something along the lines of: - If the ID asserted by a peer does not match any PAD entry, then a BTNS-enabled IPsec implementation replaces the ID with into the new ID of type "PUBLICKEY" that is created by extracting the public key from the IKE CERT (or ??) payload - the PAD is searched again, using this new ID type and value - if there is a match, the associated PAD entry (which will be a BTNS entry) is used to control the SPD search - if there is no match, the IKE SA is rejected That sort of text would avoid the ambiguity that triggered my question. Steve From mcr at sandelman.ca Thu Jul 26 12:19:28 2007 From: mcr at sandelman.ca (Michael Richardson) Date: Thu, 26 Jul 2007 14:19:28 -0500 Subject: [anonsec] comments on the BTNS core I-D In-Reply-To: References: Message-ID: Stephen Kent wrote: > easily visible. I then convert to a PDF, so everyone can read the > results, and still see the changes. As someone who does not > regularly use Unix for text editing, I don't find diff's helpful, > something reaffirmed by looking at the diff you provided at the end > of this message :-). I understand. For those of us who do use it, it is very immediately visible what is going on, and there are some who can apply diffs in their head. >> We think that the the only things that matters is that >> [C] can't assert [Q]'s identity, or [B]'s identity, because those IDs are in >> the PAD as non-BTNS, and therefore [SG-A] must have some way to positively >> identify those nodes public keys. So, C can't assert itself as being [C] or [B] >> [Q] without the appropriate private key. That's standard IPsec processing. >> >> Was that your concern? Or something else. >> > > my comment appears on page 7, in reference to example #1. I asked the > question because the PAD description in 4301 says how to search the > PAD based on matching the ID asserted in IKE against the PAD. there > are words early in this document (page 4) about the new ID type > "PUBLICKEY" and the need to coerce the ID offered by a BTNS peer into > this new ID type, which is never transferred over the wire via IKE. > (That raises the question of whether we ought to describe this as an > IKE ID type, but I'll let Charlue Kaufman comment on that later, if > he wishes.) The public key *is* transmitted on the wire in a slightly mis-named "CERT" payload, of type "Raw RSA Key 11". This was first stated on page 4 of btns-core, (and page 59 of RFC2406). > - If the ID asserted by a peer does not match any PAD entry, > then a BTNS-enabled IPsec implementation replaces the ID with into > the new ID of type "PUBLICKEY" that is created by extracting the > public key from the IKE CERT (or ??) payload > > - the PAD is searched again, using this new ID type and value > > - if there is a match, the associated PAD entry (which will > be a BTNS entry) is used to control the SPD search > > - if there is no match, the IKE SA is rejected Good text. We'll use it. Q: does this relax the requirement for the PAD entry to be lowest priority? The two searches can be implemented with a single scan, with a priority based comparison (i.e. keep on the best match). From mcr at sandelman.ca Thu Jul 26 12:32:38 2007 From: mcr at sandelman.ca (Michael Richardson) Date: Thu, 26 Jul 2007 14:32:38 -0500 Subject: [anonsec] comments on the BTNS core I-D In-Reply-To: References: Message-ID: Stephen Kent wrote: > - If the ID asserted by a peer does not match any PAD entry, > then a BTNS-enabled IPsec implementation replaces the ID with into > the new ID of type "PUBLICKEY" that is created by extracting the > public key from the IKE CERT (or ??) payload Index: ietf-btns-core.xml =================================================================== RCS file: /l/users/nico/btns/drafts/ietf-btns-core.xml,v retrieving revision 1.20 retrieving revision 1.21 diff -u -5 -r1.20 -r1.21 --- ietf-btns-core.xml 26 Jul 2007 01:40:52 -0000 1.20 +++ ietf-btns-core.xml 26 Jul 2007 19:29:13 -0000 1.21 @@ -132,20 +132,35 @@ The IPsec processing model is hereby modified as follows: A new ID type is added, 'PUBLICKEY'; IDs of this type have public keys as values. This ID type is not used on the wire. + A BTNS-specific PAD entry. This entry MUST be the last entry in the PAD when BTNS is enabled. A peer that matches no other PAD entries is to be "authenticated" by verifying that the signature in its AUTH payload in the IKEv2 exchange with the public key from the peer's CERT payload. The peer's ID MUST then be coerced to be of 'PUBLICKEY' type with the peer's public key as its value. + + To accomplish the above, search the PAD as normal, + with the ID provided by the peer. If it matches do + normal processing. If the ID asserted by a peer does + not match any PAD entry, then a BTNS-enabled IPsec + implementation replaces the ID with into the new ID of type "PUBLICKEY" + that is created by extracting the public key from the IKE CERT payload. + + The PAD is searched again, using this new ID type and value. + If there is a match, the associated PAD entry (which will be a BTNS entry) + is used to control the SPD search. + + If there is no match, the IKE SA is rejected + A new flag for SPD entries: 'BTNS_OK'. Traffic to/from peers that match the BTNS PAD entry will match only SPD entries that have the BTNS_OK flag set. The SPD may be searched by address or by ID (of type PUBLICKEY, for BTNS @@ -184,11 +199,12 @@ SAs. In the first pass the PAD is searched for a matching PAD entry as usual, and in the second it is searched to make sure that BTNS peers' asserted child SA traffic - selectors do not conflict with non-BTNS PAD entries. + selectors do not conflict with non-BTNS PAD entries. +
In order to explain the above rules a number of scenarios will be examined. The goal here is to persuade the reader @@ -498,10 +514,14 @@ to create new registrations nor new registries. (The new ID type is not used on the wire, therefore it need not be assigned a number from the IANA IKEv2 Identification Payload ID Types registry.)
+ +
+ Thanks for the following reviewers: Stephen Kent +
&rfc2119; &rfc4301; From Nicolas.Williams at sun.com Thu Jul 26 12:37:31 2007 From: Nicolas.Williams at sun.com (Nico) Date: Thu, 26 Jul 2007 14:37:31 -0500 Subject: [anonsec] comments on the BTNS core I-D In-Reply-To: References: Message-ID: <20070726193730.GB2444@Sun.COM> On Thu, Jul 26, 2007 at 02:19:28PM -0500, Michael Richardson wrote: > Stephen Kent wrote: > > - If the ID asserted by a peer does not match any PAD entry, > > then a BTNS-enabled IPsec implementation replaces the ID with into > > the new ID of type "PUBLICKEY" that is created by extracting the > > public key from the IKE CERT (or ??) payload > > > > - the PAD is searched again, using this new ID type and value Indeed, if there are any PAD entries matching a specific public key, then those must take precedence over the catch-all BTNS PAD entry. > > - if there is a match, the associated PAD entry (which will > > be a BTNS entry) is used to control the SPD search > > > > - if there is no match, the IKE SA is rejected > > Good text. We'll use it. > Q: does this relax the requirement for the PAD entry to be lowest priority? No. PAD entries that match specific PUBLICKEY IDs must come before the catch-all BTNS PAD entry (which MUST be last); they must also come logically after any PAD entries matching other ID types. > The two searches can be implemented with a single scan, with a priority based > comparison (i.e. keep on the best match). Indeed. We need only describe a canonical approach though, but we could certainly say that a one-pass optimization is feasible. Nico -- From Internet-Drafts at ietf.org Thu Jul 26 13:00:01 2007 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Thu, 26 Jul 2007 16:00:01 -0400 Subject: [anonsec] I-D Action:draft-ietf-btns-core-04.txt Message-ID: ENCODING mime FILE /internet-drafts/draft-ietf-btns-core-04.txt -------------- next part -------------- From ynir at checkpoint.com Fri Jul 27 04:50:46 2007 From: ynir at checkpoint.com (Yoav Nir) Date: Fri, 27 Jul 2007 06:50:46 -0500 Subject: [anonsec] Fwd: [openikev2-announce] New versions released !!! References: <1185527796.7989.10.camel@localhost.localdomain> Message-ID: <2A4BFA8D-DCDD-4DE9-B898-F2503130FFC2@checkpoint.com> Hi. Thought this would be of interest to the list. Apparently they have BTNS support. Begin forwarded message: > From: Alejandro Perez Mendez > Date: July 27, 2007 4:16:36 AM CDT > To: OpenIKEv2 announces > Subject: [openikev2-announce] New versions released !!! > > New versions released !!! > * libopenikev2 0.4: > * Huge code refactoring, including: > * Intensive use of the RAII programming idiom > (autopointers, autolocks, autovectors...), > avoiding the use of the "delete". > * Use of references when there was no need for > more. > * Name classes changes, to avoid the "_" at most > as possible. > * Code factorization, reusing the code for the > CHILD SA negotiation from the IKE_AUTH and the > CREATE_CHILD_SA exchanges. Also the code > for the > IKE_SA negotiation from the IKE_SA_INIT and > CREATE_CHILD_SA exchanges has been factorized. > * BTNS support added (that's is, no authentication at > all > at IKEv2 level) > * Lot of bug fixes. > * libopenikev2_impl 0.4: > * Huge code refactoring, including: > * Intensive use of the RAII programming idiom > (autopointers, autolocks, autovectors...), > avoiding the use of the "delete". > * Use of references when there was no need for > more. > * Name classes changes, to avoid the "_" at most > as possible. > * Disabled PFKEYv2 IPsec management interface. It may be > available in future versions. > * Certificate support has been improved: > * Alternate name is now consulted to match with > the ID payload. > * Improved DN management (subject name and > issuer > name). Now they are shown propertly. > * Lot of bug fixes. > * openikev2 0.94: > * Addded support for BTNS in the configuration file. > * PFKEYv2 is not available in this version, so if you > want > to use it ,keep using 0.93 version (and 0.3 library > versions). > * Addapted to the new libopenikev2 an libopenikev2_impl > API (0.4 version). > * tests 0.4 > * Changed in order to be compatible to libopenikev2 and > libopenikev2_impl 0.4 version. > See the libopenikev2 ChangeLog, the libopenikev2_impl ChangeLog, > openikev2 ChangeLog and test ChangeLog to see a more complete change > list. Remember to make backups of the configuration files before > install > the new release. They will be overwritten. > > > You can download it here > > > _______________________________________________ > openikev2-announce mailing list > openikev2-announce at dif.um.es > https://correo.dif.um.es/cgi-bin/mailman/listinfo/openikev2-announce > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/anonsec/attachments/20070727/523da547/attachment-0001.html From gregorio at dif.um.es Fri Jul 27 09:28:49 2007 From: gregorio at dif.um.es (Gregorio Martinez) Date: Fri, 27 Jul 2007 18:28:49 +0200 Subject: [anonsec] Fwd: [openikev2-announce] New versions released !!! In-Reply-To: <2A4BFA8D-DCDD-4DE9-B898-F2503130FFC2@checkpoint.com> References: <1185527796.7989.10.camel@localhost.localdomain> <2A4BFA8D-DCDD-4DE9-B898-F2503130FFC2@checkpoint.com> Message-ID: <46AA1D41.2060800@dif.um.es> Hi Yoav, hi all, thanks for forwarding this message to the Anonsec/BTNS mailing list ... and you are right; we are currently supporting BTNS as part of our implementation of the IKEv2 protocol (http://openikev2.sourceforge.net/); it is working well with SAB mode and we are finishing now the coding of the Channel Binding (CBB) mode. Thanks, regards, Gregorio Gregorio Martinez, PhD University of Murcia (UMU), Spain Yoav Nir wrote: > Hi. > > Thought this would be of interest to the list. > > Apparently they have BTNS support. > > Begin forwarded message: > >> *From: * Alejandro Perez Mendez > > >> *Date: * July 27, 2007 4:16:36 AM CDT >> *To: * OpenIKEv2 announces > > >> *Subject: * *[openikev2-announce] New versions released !!!* >> >> New versions released !!! >> * libopenikev2 0.4: >> * Huge code refactoring, including: >> * Intensive use of the RAII programming idiom >> (autopointers, autolocks, autovectors...), >> avoiding the use of the "delete". >> * Use of references when there was no need for >> more. >> * Name classes changes, to avoid the "_" at most >> as possible. >> * Code factorization, reusing the code for the >> CHILD SA negotiation from the IKE_AUTH and the >> CREATE_CHILD_SA exchanges. Also the code for the >> IKE_SA negotiation from the IKE_SA_INIT and >> CREATE_CHILD_SA exchanges has been factorized. >> * BTNS support added (that's is, no authentication at all >> at IKEv2 level) >> * Lot of bug fixes. >> * libopenikev2_impl 0.4: >> * Huge code refactoring, including: >> * Intensive use of the RAII programming idiom >> (autopointers, autolocks, autovectors...), >> avoiding the use of the "delete". >> * Use of references when there was no need for >> more. >> * Name classes changes, to avoid the "_" at most >> as possible. >> * Disabled PFKEYv2 IPsec management interface. It may be >> available in future versions. >> * Certificate support has been improved: >> * Alternate name is now consulted to match with >> the ID payload. >> * Improved DN management (subject name and issuer >> name). Now they are shown propertly. >> * Lot of bug fixes. >> * openikev2 0.94: >> * Addded support for BTNS in the configuration file. >> * PFKEYv2 is not available in this version, so if you want >> to use it ,keep using 0.93 version (and 0.3 library >> versions). >> * Addapted to the new libopenikev2 an libopenikev2_impl >> API (0.4 version). >> * tests 0.4 >> * Changed in order to be compatible to libopenikev2 and >> libopenikev2_impl 0.4 version. >> See the libopenikev2 ChangeLog, the libopenikev2_impl ChangeLog, >> openikev2 ChangeLog and test ChangeLog to see a more complete change >> list. Remember to make backups of the configuration files before install >> the new release. They will be overwritten. >> >> >> You can download it here >> >> >> _______________________________________________ >> openikev2-announce mailing list >> openikev2-announce at dif.um.es >> https://correo.dif.um.es/cgi-bin/mailman/listinfo/openikev2-announce >> > > > ------------------------------------------------------------------------ > > _______________________________________________ From kent at bbn.com Fri Jul 27 11:18:49 2007 From: kent at bbn.com (Stephen Kent) Date: Fri, 27 Jul 2007 14:18:49 -0400 Subject: [anonsec] Fwd: [openikev2-announce] New versions released !!! In-Reply-To: <2A4BFA8D-DCDD-4DE9-B898-F2503130FFC2@checkpoint.com> References: <1185527796.7989.10.camel@localhost.localdomain> <2A4BFA8D-DCDD-4DE9-B898-F2503130FFC2@checkpoint.com> Message-ID: At 6:50 AM -0500 7/27/07, Yoav Nir wrote: >Hi. > >Thought this would be of interest to the list. > >Apparently they have BTNS support. > > Since no BTNS documents are final yet, the above statement seems a bit premature :-). Steve From kent at bbn.com Fri Jul 27 14:15:22 2007 From: kent at bbn.com (Stephen Kent) Date: Fri, 27 Jul 2007 17:15:22 -0400 Subject: [anonsec] comments on the BTNS core I-D In-Reply-To: References: Message-ID: At 2:19 PM -0500 7/26/07, Michael Richardson wrote: >S... > > my comment appears on page 7, in reference to example #1. I asked the >> question because the PAD description in 4301 says how to search the >> PAD based on matching the ID asserted in IKE against the PAD. there >> are words early in this document (page 4) about the new ID type >> "PUBLICKEY" and the need to coerce the ID offered by a BTNS peer into >> this new ID type, which is never transferred over the wire via IKE. >> (That raises the question of whether we ought to describe this as an >> IKE ID type, but I'll let Charlue Kaufman comment on that later, if >> he wishes.) > > The public key *is* transmitted on the wire in a slightly mis-named "CERT" >payload, of type "Raw RSA Key 11". This was first >stated on page 4 of btns-core, (and page 59 of RFC2406). I didn't say that the key isn't transmitted; I just noted the wording in the document that says that the new IKE ID type is not carried on the wire. The new text on page 4 also says "Nodes wishing to be treated as BTNS nodes by their peers MUST include bare RSA key CERT payloads. Nodes MAY also include any number of certificates that bind the same public key. These certificates need not to have been pre-shared with their peers (e.g., because ephermal, self-signed)." first, "ephemeral" is misspelled and there seems to be a word missing in that parenthetical phrase. Second, the text refers to bare RSA key payloads, plural, but I assume is it acceptable to send just one such payload, right? in fact, would it make sense to send more than one? also, the text allows additional cert payloads, but only of they contain the same key as the bare RSA payload, but the wording is confusing. I suggest the following rewording, if my assumptions about your intent are correct: A node that wishes to be treated as BTNS node by a peer MUST include at least one Raw RSA Key CERT payload. A node also MAY include one or more certificate payloads of types other than Raw RSA Key, but only if they contain the same public key as the Raw RSA Key CERT payload. These additional certificates need not have been pre-shared with the peer in (e.g., because they may be ephemeral, or self-signed). A final question re this text: why allow sending additional certs? > >> - If the ID asserted by a peer does not match any PAD entry, >> then a BTNS-enabled IPsec implementation replaces the ID with into >> the new ID of type "PUBLICKEY" that is created by extracting the >> public key from the IKE CERT (or ??) payload >> >> - the PAD is searched again, using this new ID type and value >> >> - if there is a match, the associated PAD entry (which will >> be a BTNS entry) is used to control the SPD search >> >> - if there is no match, the IKE SA is rejected > >Good text. We'll use it. >Q: does this relax the requirement for the PAD entry to be lowest priority? >The two searches can be implemented with a single scan, with a priority based >comparison (i.e. keep on the best match). I think you and Nico should agree on this point, and clarify the text if needed. Nico's message refers to the potential for additional PAD entries that match PUBLICKEY, but if this ID type was created only to support BTNS entries, then his message is saying that there can be multiple such entries. Right now the text seems to indicate just one BTNS PAD entry, and requires it to be in the last slot. Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/anonsec/attachments/20070727/8476e0c6/attachment.html From ynir at checkpoint.com Fri Jul 27 14:55:15 2007 From: ynir at checkpoint.com (Yoav Nir) Date: Fri, 27 Jul 2007 16:55:15 -0500 Subject: [anonsec] Fwd: [openikev2-announce] New versions released !!! In-Reply-To: References: <1185527796.7989.10.camel@localhost.localdomain> <2A4BFA8D-DCDD-4DE9-B898-F2503130FFC2@checkpoint.com> Message-ID: As long as it's running code... We've had IKEv2 interoperability workshops months before RFC 4306. There are also lots of implementations of SCEP and that hasn't made it to historic yet. On Jul 27, 2007, at 1:18 PM, Stephen Kent wrote: > At 6:50 AM -0500 7/27/07, Yoav Nir wrote: >> Hi. >> >> Thought this would be of interest to the list. >> >> Apparently they have BTNS support. >> >> > > Since no BTNS documents are final yet, the above statement seems a > bit premature :-). > > Steve > From kent at bbn.com Mon Jul 30 07:58:54 2007 From: kent at bbn.com (Stephen Kent) Date: Mon, 30 Jul 2007 10:58:54 -0400 Subject: [anonsec] Fwd: [openikev2-announce] New versions released !!! In-Reply-To: References: <1185527796.7989.10.camel@localhost.localdomain> <2A4BFA8D-DCDD-4DE9-B898-F2503130FFC2@checkpoint.com> Message-ID: At 4:55 PM -0500 7/27/07, Yoav Nir wrote: >As long as it's running code... Windows is running code too, but it's not an IETF standard :-). If CheckPoint wants to declare something it implemented as being BTNS, despite the lack of an IESG-approved document, and in light of the ongoing changes to the document, I guess it's a good marketing ploy, if not good IETF behavior. >We've had IKEv2 interoperability workshops months before RFC 4306. Before the RFC was issued (after several months in the RFC Editor's queue), or before the document was approved by the IESG? >There are also lots of implementations of SCEP and that hasn't made >it to historic yet. That's an irrelevant example, i.e., a protocol developed outside the IETF which may be published as historic, as a compromise. Steve From Nicolas.Williams at sun.com Mon Jul 30 08:24:49 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 30 Jul 2007 10:24:49 -0500 Subject: [anonsec] Fwd: [openikev2-announce] New versions released !!! In-Reply-To: References: <1185527796.7989.10.camel@localhost.localdomain> <2A4BFA8D-DCDD-4DE9-B898-F2503130FFC2@checkpoint.com> Message-ID: <20070730152449.GA1199@Sun.COM> On Fri, Jul 27, 2007 at 02:18:49PM -0400, Stephen Kent wrote: > At 6:50 AM -0500 7/27/07, Yoav Nir wrote: > >Hi. > > > >Thought this would be of interest to the list. > > > >Apparently they have BTNS support. > > Since no BTNS documents are final yet, the above statement seems a > bit premature :-). Maybe. There were SSHv2 implementations long before there were SSHv2 RFCs. C'est la vie. From Nicolas.Williams at sun.com Mon Jul 30 08:47:51 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 30 Jul 2007 10:47:51 -0500 Subject: [anonsec] comments on the BTNS core I-D In-Reply-To: References: Message-ID: <20070730154751.GC1199@Sun.COM> On Fri, Jul 27, 2007 at 05:15:22PM -0400, Stephen Kent wrote: > I didn't say that the key isn't transmitted; I just noted the wording > in the document that says that the new IKE ID type is not carried on > the wire. Correct. A new IKE ID would be primarily useful as an implementation detail, but probably useful enough to be worthy of having an assignment for it. > The new text on page 4 also says "Nodes wishing to be treated as BTNS > nodes by their peers MUST include bare RSA key CERT payloads. Nodes > MAY also include any number of certificates that bind the same public > key. These certificates need not to have been pre-shared with their > peers (e.g., because ephermal, self-signed)." > > first, "ephemeral" is misspelled and there seems to be a word missing > in that parenthetical phrase. It was misspelled, and no word is missing ("because " is a legitimate English language idiom, as in "Joe was lazy because spoiled"). It is an odd idiom, but one that I'm fond of. > Second, the text refers to bare RSA key payloads, plural, but I > assume is it acceptable to send just one such payload, right? in It is plural because the nodes will be doing multiple IKE exchanges with many peers thus there will be multiple bare RSA key payloads. But in one IKE exchange there should be a single payload because there can be only one AUTH payload so there can really only be one public key. > fact, would it make sense to send more than one? also, the text Having multiple CERT payloads per-exchange all using the same public key, as in different certs for the same key, seems OK, and even useful. > allows additional cert payloads, but only of they contain the same > key as the bare RSA payload, but the wording is confusing. I suggest > the following rewording, if my assumptions about your intent are > correct: > > A node that wishes to be treated as BTNS node by a peer MUST include > at least one Raw RSA Key CERT payload. A node also MAY include one > or more certificate payloads of types other than Raw RSA Key, but > only if they contain the same public key as the Raw RSA Key CERT > payload. These additional certificates need not have been pre-shared > with the peer in (e.g., because they may be ephemeral, or > self-signed). I like it, thanks. > A final question re this text: why allow sending additional certs? Because it would allow a node to do better than BTNS with some peer if that peer could authenticate it; the node need not know a priori that its peer can do so. RFC4306 doesn't seem to disallow multiple CERT payloads, but the structure of the protocol is such that only one AUTH payload makes sense, thus all CERT payloads should use the same public key. > >> - If the ID asserted by a peer does not match any PAD entry, > >> then a BTNS-enabled IPsec implementation replaces the ID with into > >> the new ID of type "PUBLICKEY" that is created by extracting the > >> public key from the IKE CERT (or ??) payload > >> > >> - the PAD is searched again, using this new ID type and value > >> > >> - if there is a match, the associated PAD entry (which will > >> be a BTNS entry) is used to control the SPD search > >> > >> - if there is no match, the IKE SA is rejected > > > >Good text. We'll use it. > >Q: does this relax the requirement for the PAD entry to be lowest priority? > >The two searches can be implemented with a single scan, with a priority > >based > >comparison (i.e. keep on the best match). > > I think you and Nico should agree on this point, and clarify the text > if needed. > Nico's message refers to the potential for additional PAD entries > that match PUBLICKEY, but if this ID type was created only to support > BTNS entries, then his message is saying that there can be multiple > such entries. Right now the text seems to indicate just one BTNS PAD > entry, and requires it to be in the last slot. The BTNS catch-all entry must be the last one in the PAD. There may be PAD entries that match specific public keys -- these must come before the BTNS catch-all PAD entry. From Nicolas.Williams at sun.com Mon Jul 30 09:00:10 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 30 Jul 2007 11:00:10 -0500 Subject: [anonsec] Fwd: [openikev2-announce] New versions released !!! In-Reply-To: References: <1185527796.7989.10.camel@localhost.localdomain> <2A4BFA8D-DCDD-4DE9-B898-F2503130FFC2@checkpoint.com> Message-ID: <20070730160010.GD1199@Sun.COM> On Mon, Jul 30, 2007 at 10:58:54AM -0400, Stephen Kent wrote: > At 4:55 PM -0500 7/27/07, Yoav Nir wrote: > >As long as it's running code... > > Windows is running code too, but it's not an IETF standard :-). Implementations aren't, though they might be standards compliant, but since the IETF doesn't have any sort of compliance testing, compliance is up to the vendors to test for and up to the customers to test for and insist on. > If CheckPoint wants to declare something it implemented as being > BTNS, despite the lack of an IESG-approved document, and in light of > the ongoing changes to the document, I guess it's a good marketing > ploy, if not good IETF behavior. It happens a lot in the IETF. For at least some Internet protocols vendors have shipped long before the RFCs issued. In any case, the latest release of the particular implementation that we're talking about is labelled as version 0.4, which might well be, for all we know, an acknowledgement of the potential for backwards incompatible changes as Internet-Drafts change backwards incompatibly. Nico -- From ddp at electric-loft.org Mon Jul 30 09:26:51 2007 From: ddp at electric-loft.org (Derrell Piper) Date: Mon, 30 Jul 2007 09:26:51 -0700 Subject: [anonsec] comments on the BTNS core I-D Message-ID: <1E2CD67A-DAC3-4981-A4AC-2BEAB31EDE1A@electric-loft.org> Overall: 'system' 'host' and 'node' are intermingled. 'node' in particular implies cluster to some of us and could easily be replaced with 'host' or 'system'. You need to specify exactly what happens for every failure mode and you ought to be sending IKE informational or Notify payloads for all error cases. Your bracketed notation is confusing. The brackets aren't adding anything. pg 3, third bullet "...replaces the ID with into the new ID..." -> "...replaces the ID with the new ID..." pg 3, last paragraph "These certificates need not to have been pre-shared with their peers (e.g., because ephermal, self-signed)." -> "These certificates do not need to be pre-shared with their peers and may be ephemeral self-signed certificates." I generally don't like the idea of sending self-signed certificates for ephemeral keys. If the point is solely to maintain IKEv2 semantics, you should say that. Otherwise, there's little reason to require the extra overhead of the certificate processing (and parsing) when all you're really doing is extracting the public key anyway. pg 6, Figure 1 "In this diagram, there are six end-nodes: A, B, C and D." That's four, not six. Do you mean "...nodes: A, B, C, D, Q and R."? "Node [D] has a non-fixed address." "non-fixed" meaning what exactly? Why is that relevant? pg 6, "The machine that we will care in this example is [SG-A]" Grammar. "Let's first examine [SG-A], a firewall..." pg 8, first bullet, maching PAD #3 but no Child SAs Is there an IKE informational generated in this case? I think maybe you should show exactly what you intend the IKE exchange to look like in this case. pg 8, second bullet "...a rogue BTNS nodes..." -> "...a rogue BTNS node..." I'm not sure I understand what you mean here. If you're authenticating on C's address with BTNS, you're C. In essence, aren't all BTNS nodes rogue nodes? I think your use of the term 'rogue node' is confusing throughout because using it at all sort of implies that there's some protection when there's not. Alternatively, perhaps this whole discussion belongs in the Security Considerations section. pg 8, "...and it's NFSv4 implementation is..." -> "...and its..." pg 8, "traffice" -> "traffic" pg 9, "As [Q] has no formal relationship with [SG-B], rogues can impersonate [B] (i.e., assert [B]'s addresses)." You need to specify what should happen if a second [B] or [SG-B] comes along. pg. 11, Section 4.2 "If so, records the server's name..." is a sentence fragment. pg. 11, "Leap of faith can work in a similar way for BTNS nodes, but it is currently still being designed and specified b y the IETF BNTS WG." This statement is close to useless. Either say something substantive or remove it. From kent at bbn.com Mon Jul 30 09:09:13 2007 From: kent at bbn.com (Stephen Kent) Date: Mon, 30 Jul 2007 12:09:13 -0400 Subject: [anonsec] Fwd: [openikev2-announce] New versions released !!! In-Reply-To: <20070730152449.GA1199@Sun.COM> References: <1185527796.7989.10.camel@localhost.localdomain> <2A4BFA8D-DCDD-4DE9-B898-F2503130FFC2@checkpoint.com> <20070730152449.GA1199@Sun.COM> Message-ID: At 10:24 AM -0500 7/30/07, Nicolas Williams wrote: >On Fri, Jul 27, 2007 at 02:18:49PM -0400, Stephen Kent wrote: >> At 6:50 AM -0500 7/27/07, Yoav Nir wrote: >> >Hi. >> > >> >Thought this would be of interest to the list. >> > >> >Apparently they have BTNS support. >> >> Since no BTNS documents are final yet, the above statement seems a >> bit premature :-). > >Maybe. There were SSHv2 implementations long before there were SSHv2 >RFCs. C'est la vie. SSH (v1?) was another example of a protocol developed outside the IETF, and later brought into the IETF. At least in this case, there were no directly competing IETF WGs. Steve From kent at bbn.com Mon Jul 30 09:30:02 2007 From: kent at bbn.com (Stephen Kent) Date: Mon, 30 Jul 2007 12:30:02 -0400 Subject: [anonsec] Fwd: [openikev2-announce] New versions released !!! In-Reply-To: <20070730160010.GD1199@Sun.COM> References: <1185527796.7989.10.camel@localhost.localdomain> <2A4BFA8D-DCDD-4DE9-B898-F2503130FFC2@checkpoint.com> <20070730160010.GD1199@Sun.COM> Message-ID: At 11:00 AM -0500 7/30/07, Nicolas Williams wrote: >On Mon, Jul 30, 2007 at 10:58:54AM -0400, Stephen Kent wrote: >> At 4:55 PM -0500 7/27/07, Yoav Nir wrote: >> >As long as it's running code... >> >> Windows is running code too, but it's not an IETF standard :-). > >Implementations aren't, though they might be standards compliant, but >since the IETF doesn't have any sort of compliance testing, compliance >is up to the vendors to test for and up to the customers to test for and >insist on. or to have third-party labs validate. > > If CheckPoint wants to declare something it implemented as being >> BTNS, despite the lack of an IESG-approved document, and in light of >> the ongoing changes to the document, I guess it's a good marketing >> ploy, if not good IETF behavior. > >It happens a lot in the IETF. For at least some Internet protocols >vendors have shipped long before the RFCs issued. note my distinction between RFC issuance vs. IESG approval. Once the IESG approves a document is may take many months (it used to be as long as a year) for the RFC to be issued, but the substance of the standard is fixed. Steve From kent at bbn.com Mon Jul 30 09:27:44 2007 From: kent at bbn.com (Stephen Kent) Date: Mon, 30 Jul 2007 12:27:44 -0400 Subject: [anonsec] comments on the BTNS core I-D In-Reply-To: <20070730154751.GC1199@Sun.COM> References: <20070730154751.GC1199@Sun.COM> Message-ID: At 10:47 AM -0500 7/30/07, Nicolas Williams wrote: >... > >It was misspelled, and no word is missing ("because " is a >legitimate English language idiom, as in "Joe was lazy because >spoiled"). It is an odd idiom, but one that I'm fond of. For standards documents we tend to look for somewhat more formal writing :-). > > Second, the text refers to bare RSA key payloads, plural, but I >> assume is it acceptable to send just one such payload, right? in > >It is plural because the nodes will be doing multiple IKE exchanges with >many peers thus there will be multiple bare RSA key payloads. This is another place where it's better to use singular instances as examples, rather than plural instances. The use of a plural instance as a subject creates ambiguity in the rest of the sentence, because one cannot know whether the later plural objects apply to each instance of the subject, or are due to the use of a plural subject. That's why I suggested re-writing text from "nodes" to "a node" in other parts of the document. >But in one IKE exchange there should be a single payload because there >can be only one AUTH payload so there can really only be one public key. That makes sense for this type of CERT payload; IKE does not provide guidance about specific CERT payload sub-types, just for the overall payload type, so it is helpful to provide that guidance here. > > fact, would it make sense to send more than one? also, the text > >Having multiple CERT payloads per-exchange all using the same public >key, as in different certs for the same key, seems OK, and even useful. agreed. > > allows additional cert payloads, but only of they contain the same >> key as the bare RSA payload, but the wording is confusing. I suggest >> the following rewording, if my assumptions about your intent are >> correct: >> >> A node that wishes to be treated as BTNS node by a peer MUST include >> at least one Raw RSA Key CERT payload. A node also MAY include one >> or more certificate payloads of types other than Raw RSA Key, but >> only if they contain the same public key as the Raw RSA Key CERT >> payload. These additional certificates need not have been pre-shared >> with the peer in (e.g., because they may be ephemeral, or >> self-signed). > >I like it, thanks. > >> A final question re this text: why allow sending additional certs? > >Because it would allow a node to do better than BTNS with some peer if >that peer could authenticate it; the node need not know a priori that >its peer can do so. RFC4306 doesn't seem to disallow multiple CERT >payloads, but the structure of the protocol is such that only one AUTH >payload makes sense, thus all CERT payloads should use the same public >key. yes, and it would be appropriate to not that here. >... >The BTNS catch-all entry must be the last one in the PAD. There may be >PAD entries that match specific public keys -- these must come before >the BTNS catch-all PAD entry. I agree that a BTNS "catch-all" entry must come last, but that entry is described with two adjectives: BTNS and "catch-all." So, can there be a BTNS's entry that matches a specific PUBLICKEY ID type and thus is not "catch-all?" I think that was Michael's question, and mine. If we say that a BTNS PAD entry is any PAD entry that uses the PUBLICKEY ID type, then syntactically this would allow other than catch-all BTNS entries. Steve From Nicolas.Williams at sun.com Mon Jul 30 10:00:42 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 30 Jul 2007 12:00:42 -0500 Subject: [anonsec] Fwd: [openikev2-announce] New versions released !!! In-Reply-To: References: <1185527796.7989.10.camel@localhost.localdomain> <2A4BFA8D-DCDD-4DE9-B898-F2503130FFC2@checkpoint.com> <20070730160010.GD1199@Sun.COM> Message-ID: <20070730170041.GG1199@Sun.COM> On Mon, Jul 30, 2007 at 12:30:02PM -0400, Stephen Kent wrote: > At 11:00 AM -0500 7/30/07, Nicolas Williams wrote: > >It happens a lot in the IETF. For at least some Internet protocols > >vendors have shipped long before the RFCs issued. > > note my distinction between RFC issuance vs. IESG approval. Once the > IESG approves a document is may take many months (it used to be as > long as a year) for the RFC to be issued, but the substance of the > standard is fixed. Yeah, but with SSHv2 the implementations existed and shipped long before the I-Ds even passed WGLC. From kent at bbn.com Mon Jul 30 10:06:41 2007 From: kent at bbn.com (Stephen Kent) Date: Mon, 30 Jul 2007 13:06:41 -0400 Subject: [anonsec] Fwd: [openikev2-announce] New versions released !!! In-Reply-To: <20070730170041.GG1199@Sun.COM> References: <1185527796.7989.10.camel@localhost.localdomain> <2A4BFA8D-DCDD-4DE9-B898-F2503130FFC2@checkpoint.com> <20070730160010.GD1199@Sun.COM> <20070730170041.GG1199@Sun.COM> Message-ID: At 12:00 PM -0500 7/30/07, Nicolas Williams wrote: >On Mon, Jul 30, 2007 at 12:30:02PM -0400, Stephen Kent wrote: >> At 11:00 AM -0500 7/30/07, Nicolas Williams wrote: >> >It happens a lot in the IETF. For at least some Internet protocols >> >vendors have shipped long before the RFCs issued. >> >> note my distinction between RFC issuance vs. IESG approval. Once the >> IESG approves a document is may take many months (it used to be as >> long as a year) for the RFC to be issued, but the substance of the >> standard is fixed. > >Yeah, but with SSHv2 the implementations existed and shipped long before >the I-Ds even passed WGLC. Then the vendors jumped the gun. Steve From Nicolas.Williams at sun.com Mon Jul 30 10:15:51 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 30 Jul 2007 12:15:51 -0500 Subject: [anonsec] comments on the BTNS core I-D In-Reply-To: References: <20070730154751.GC1199@Sun.COM> Message-ID: <20070730171551.GI1199@Sun.COM> On Mon, Jul 30, 2007 at 12:27:44PM -0400, Stephen Kent wrote: > At 10:47 AM -0500 7/30/07, Nicolas Williams wrote: > >... > > > >It was misspelled, and no word is missing ("because " is a > >legitimate English language idiom, as in "Joe was lazy because > >spoiled"). It is an odd idiom, but one that I'm fond of. > > For standards documents we tend to look for somewhat more formal writing > :-). Sure, but show me that this is not formal (it's harder than you think). Or did you mean that we want to use a subset of English likely to be understood by most readers, including those for whom English is not a first language? :) Such an argument wins me over more easily :) I'll put a note to the RFC-Editor about this. > > > Second, the text refers to bare RSA key payloads, plural, but I > >> assume is it acceptable to send just one such payload, right? in > > > >It is plural because the nodes will be doing multiple IKE exchanges with > >many peers thus there will be multiple bare RSA key payloads. > > This is another place where it's better to use singular instances as > examples, rather than plural instances. The use of a plural instance > as a subject creates ambiguity in the rest of the sentence, because > one cannot know whether the later plural objects apply to each > instance of the subject, or are due to the use of a plural subject. > That's why I suggested re-writing text from "nodes" to "a node" in > other parts of the document. OK, we can change that to a singular ("A node wishing to be treated as a BTNS node MUST include a bare RSA key CERT payload. ..."). > >> A final question re this text: why allow sending additional certs? > > > >Because it would allow a node to do better than BTNS with some peer if > >that peer could authenticate it; the node need not know a priori that > >its peer can do so. RFC4306 doesn't seem to disallow multiple CERT > >payloads, but the structure of the protocol is such that only one AUTH > >payload makes sense, thus all CERT payloads should use the same public > >key. > > yes, and it would be appropriate to not that here. Er, "to not that here"? Did you mean "to do that here"? > >... > >The BTNS catch-all entry must be the last one in the PAD. There may be > >PAD entries that match specific public keys -- these must come before > >the BTNS catch-all PAD entry. > > I agree that a BTNS "catch-all" entry must come last, but that entry > is described with two adjectives: BTNS and "catch-all." So, can there > be a BTNS's entry that matches a specific PUBLICKEY ID type and thus > is not "catch-all?" I think that was Michael's question, and mine. If Yes, there can be. Such an entry could be made as a result of connection latching (using the automatic IPsec policy editing scheme) or some leap of faith-ish schemes (not yet defined). > we say that a BTNS PAD entry is any PAD entry that uses the PUBLICKEY > ID type, then syntactically this would allow other than catch-all > BTNS entries. I'll make sure that we distinguish between the BTNS wildcard PAD entry and others. For example, the second bullet in section 2 needs a "wildcard" qualifier to be sprinkled here and there, and another bullet item needs to be added describing non-wildcard BTNS PAD entries (each such entry must match a single public key, either by value or by fingerprint). Thanks for catching this. From Nicolas.Williams at sun.com Mon Jul 30 10:31:39 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 30 Jul 2007 12:31:39 -0500 Subject: [anonsec] comments on the BTNS core I-D In-Reply-To: <1E2CD67A-DAC3-4981-A4AC-2BEAB31EDE1A@electric-loft.org> References: <1E2CD67A-DAC3-4981-A4AC-2BEAB31EDE1A@electric-loft.org> Message-ID: <20070730173138.GJ1199@Sun.COM> On Mon, Jul 30, 2007 at 09:26:51AM -0700, Derrell Piper wrote: > Overall: > > 'system' 'host' and 'node' are intermingled. 'node' in particular > implies > cluster to some of us and could easily be replaced with 'host' or > 'system'. I'm not sure we want to do that. For one, nothing says that you can't cluster BTNS hosts. It is about as difficult to cluster BTNS hosts as it is to cluster hosts using IPsec in general (a little worse once you add connection latching if you use the dynamic IPsec policy editing implementation approach). > You need to specify exactly what happens for every failure mode and > you ought to be sending IKE informational or Notify payloads for all > error cases. Failure is handled as specified in RFC4301 and RFC4306. There is a separate I-D adding an IKE notify payload to indicate to the peer that it has matched a BTNS PAD entry. > Your bracketed notation is confusing. The brackets aren't adding > anything. In the examples? > I generally don't like the idea of sending self-signed certificates for > ephemeral keys. If the point is solely to maintain IKEv2 semantics, you > should say that. Otherwise, there's little reason to require the extra > overhead of the certificate processing (and parsing) when all you're > really doing is extracting the public key anyway. Sending such certs is an option, not a requirement. > pg 6, Figure 1 > > "In this diagram, there are six end-nodes: A, B, C and D." > > That's four, not six. Do you mean "...nodes: A, B, C, D, Q and R."? Yes. > "Node [D] has a non-fixed address." "non-fixed" meaning what > exactly? Why is that relevant? That it uses DHCP. Michael? > pg 6, "The machine that we will care in this example is [SG-A]" > > Grammar. "Let's first examine [SG-A], a firewall..." A word was missing ("about"). > pg 8, first bullet, maching PAD #3 but no Child SAs > > Is there an IKE informational generated in this case? I think maybe you There can be (it's an option specified in a separate I-D). > should show exactly what you intend the IKE exchange to look like in > this case. Why? > pg 8, second bullet > > "...a rogue BTNS nodes..." -> "...a rogue BTNS node..." > > I'm not sure I understand what you mean here. If you're > authenticating on C's address with BTNS, you're C. In essence, aren't > all BTNS nodes rogue nodes? Yes, they are. The point is to illustrate that [C] gets no protection from other BTNS nodes (unless PAD entries are added to its regular peers' PADs that match on [C]'s public key). > I think your use of the term 'rogue node' is confusing throughout > because using it at all sort of implies that there's some protection > when there's not. I don't see the implication, particularly when the text is explicit about [C] not being protected from other BTNS nodes. > Alternatively, perhaps this whole discussion belongs in the Security > Considerations section. They are examples. The security considerations section already has text about the weaknesses of BTNS. > pg 9, "As [Q] has no formal relationship with [SG-B], rogues can > impersonate [B] (i.e., assert [B]'s addresses)." > > You need to specify what should happen if a second [B] or [SG-B] > comes along. I'm not sure what you mean here. > pg. 11, "Leap of faith can work in a similar way for BTNS nodes, but > it is currently still being designed and specified b y the IETF BNTS > WG." > > This statement is close to useless. Either say something substantive > or remove it. There are RFCs with similar statements (e.g., RFC2743, in relation to "channel binding"). These kinds of statements are informative, not normative, and inform the reader about concurrent efforts at the time that the document was being progressed. Such information can become stale, and therefore useless, but this is generally true for all RFCs. Nico -- From kent at bbn.com Mon Jul 30 10:50:57 2007 From: kent at bbn.com (Stephen Kent) Date: Mon, 30 Jul 2007 13:50:57 -0400 Subject: [anonsec] comments on the BTNS core I-D In-Reply-To: <20070730171551.GI1199@Sun.COM> References: <20070730154751.GC1199@Sun.COM> <20070730171551.GI1199@Sun.COM> Message-ID: At 12:15 PM -0500 7/30/07, Nicolas Williams wrote: >On Mon, Jul 30, 2007 at 12:27:44PM -0400, Stephen Kent wrote: >> At 10:47 AM -0500 7/30/07, Nicolas Williams wrote: >> >... >> > >> >It was misspelled, and no word is missing ("because " is a >> >legitimate English language idiom, as in "Joe was lazy because >> >spoiled"). It is an odd idiom, but one that I'm fond of. >> >> For standards documents we tend to look for somewhat more formal writing >> :-). > >Sure, but show me that this is not formal (it's harder than you think). Do you even have a copy of "Strunk and White" on your bookshelf? >Or did you mean that we want to use a subset of English likely to be >understood by most readers, including those for whom English is not a >first language? :) Such an argument wins me over more easily :) That's a good argument too, and if that's the one that will cause this text to be changed, I'll buy into it :-). >OK, we can change that to a singular ("A node wishing to be treated as a >BTNS node MUST include a bare RSA key CERT payload. ..."). great. > > >> A final question re this text: why allow sending additional certs? >> > >> >Because it would allow a node to do better than BTNS with some peer if >> >that peer could authenticate it; the node need not know a priori that >> >its peer can do so. RFC4306 doesn't seem to disallow multiple CERT >> >payloads, but the structure of the protocol is such that only one AUTH >> >payload makes sense, thus all CERT payloads should use the same public >> >key. >> >> yes, and it would be appropriate to not that here. > >Er, "to not that here"? Did you mean "to do that here"? no, I meant to "note that here." Just a single letter typo :-). >... > >Yes, there can be. Such an entry could be made as a result of >connection latching (using the automatic IPsec policy editing scheme) or >some leap of faith-ish schemes (not yet defined). Then perhaps the text should define a BTNS entry more clearly, near the beginning, and discuss the "catch-all" BTNS entry as a special case. > > we say that a BTNS PAD entry is any PAD entry that uses the PUBLICKEY >> ID type, then syntactically this would allow other than catch-all >> BTNS entries. > >I'll make sure that we distinguish between the BTNS wildcard PAD entry >and others. great. >For example, the second bullet in section 2 needs a "wildcard" qualifier >to be sprinkled here and there, and another bullet item needs to be >added describing non-wildcard BTNS PAD entries (each such entry must >match a single public key, either by value or by fingerprint). > >Thanks for catching this. You're welcome. Steve From Nicolas.Williams at sun.com Mon Jul 30 11:11:58 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 30 Jul 2007 13:11:58 -0500 Subject: [anonsec] comments on the BTNS core I-D In-Reply-To: References: <20070730154751.GC1199@Sun.COM> <20070730171551.GI1199@Sun.COM> Message-ID: <20070730181158.GN1199@Sun.COM> On Mon, Jul 30, 2007 at 01:50:57PM -0400, Stephen Kent wrote: > At 12:15 PM -0500 7/30/07, Nicolas Williams wrote: > >On Mon, Jul 30, 2007 at 12:27:44PM -0400, Stephen Kent wrote: > >> At 10:47 AM -0500 7/30/07, Nicolas Williams wrote: > >> >... > >> > > >> >It was misspelled, and no word is missing ("because " is a > >> >legitimate English language idiom, as in "Joe was lazy because > >> >spoiled"). It is an odd idiom, but one that I'm fond of. > >> > >> For standards documents we tend to look for somewhat more formal writing > >> :-). > > > >Sure, but show me that this is not formal (it's harder than you think). > > Do you even have a copy of "Strunk and White" on your bookshelf? I have a couple such books in my bookshelf, but I'm not at home at the moment. I've seen recent debates on prescriptivism that have caused me to doubt some of my own dislikes about other people's use of English. (I've been noticing that use of 'because' in several novels lately too, including Quicksilver, by Neal Stephenson.) > >Or did you mean that we want to use a subset of English likely to be > >understood by most readers, including those for whom English is not a > >first language? :) Such an argument wins me over more easily :) > > That's a good argument too, and if that's the one that will cause > this text to be changed, I'll buy into it :-). OK :) > >> yes, and it would be appropriate to not that here. > > > >Er, "to not that here"? Did you mean "to do that here"? > > no, I meant to "note that here." Just a single letter typo :-). OK. From ddp at electric-loft.org Mon Jul 30 11:53:25 2007 From: ddp at electric-loft.org (Derrell Piper) Date: Mon, 30 Jul 2007 11:53:25 -0700 Subject: [anonsec] comments on the BTNS core I-D In-Reply-To: <20070730173138.GJ1199@Sun.COM> References: <1E2CD67A-DAC3-4981-A4AC-2BEAB31EDE1A@electric-loft.org> <20070730173138.GJ1199@Sun.COM> Message-ID: On Jul 30, 2007, at 10:31 AM, Nicolas Williams wrote: > On Mon, Jul 30, 2007 at 09:26:51AM -0700, Derrell Piper wrote: >> Overall: >> >> 'system' 'host' and 'node' are intermingled. 'node' in particular >> implies >> cluster to some of us and could easily be replaced with 'host' or >> 'system'. > > I'm not sure we want to do that. For one, nothing says that you can't > cluster BTNS hosts. It is about as difficult to cluster BTNS hosts as > it is to cluster hosts using IPsec in general (a little worse once you > add connection latching if you use the dynamic IPsec policy editing > implementation approach). If you just replace 'node' with either 'system' or 'host' throughout, you'll address my point. >> You need to specify exactly what happens for every failure mode and >> you ought to be sending IKE informational or Notify payloads for all >> error cases. > > Failure is handled as specified in RFC4301 and RFC4306. There is a > separate I-D adding an IKE notify payload to indicate to the peer that > it has matched a BTNS PAD entry. Are there no new BNTS specific errors? Are they described somewhere else? >> Your bracketed notation is confusing. The brackets aren't adding >> anything. > > In the examples? Yes, but whatever. It's just notation. >> I generally don't like the idea of sending self-signed >> certificates for >> ephemeral keys. If the point is solely to maintain IKEv2 >> semantics, you >> should say that. Otherwise, there's little reason to require the >> extra >> overhead of the certificate processing (and parsing) when all you're >> really doing is extracting the public key anyway. > > Sending such certs is an option, not a requirement. I dislike the reference to self-signed certificates here because I believe the mere reference to them will encourage their use with BTNS and I don't think that's goodness. It's adding complexity for no additional value. >> pg 6, Figure 1 >> >> "In this diagram, there are six end-nodes: A, B, C and D." >> >> That's four, not six. Do you mean "...nodes: A, B, C, D, Q and R."? > > Yes. > >> "Node [D] has a non-fixed address." "non-fixed" meaning what >> exactly? Why is that relevant? > > That it uses DHCP. Michael? I assumed as much but I don't see how that's relevant in your examples. >> pg 6, "The machine that we will care in this example is [SG-A]" >> >> Grammar. "Let's first examine [SG-A], a firewall..." > > A word was missing ("about"). > >> pg 8, first bullet, maching PAD #3 but no Child SAs >> >> Is there an IKE informational generated in this case? I think >> maybe you > > There can be (it's an option specified in a separate I-D). > >> should show exactly what you intend the IKE exchange to look like in >> this case. > > Why? Because the failure mode is bad for the other side if you don't generate an informational/notify. >> pg 8, second bullet >> >> "...a rogue BTNS nodes..." -> "...a rogue BTNS node..." >> >> I'm not sure I understand what you mean here. If you're >> authenticating on C's address with BTNS, you're C. In essence, >> aren't >> all BTNS nodes rogue nodes? > > Yes, they are. The point is to illustrate that [C] gets no protection > from other BTNS nodes (unless PAD entries are added to its regular > peers' PADs that match on [C]'s public key). > >> I think your use of the term 'rogue node' is confusing throughout >> because using it at all sort of implies that there's some protection >> when there's not. > > I don't see the implication, particularly when the text is explicit > about [C] not being protected from other BTNS nodes. We agree there's no protection. I still think the fact that you mention 'rogue nodes' tends to make people question whether or not BTNS is providing protection from this when in fact it does not (by design). (FWIW, I do understand what you saying about C and the PAD.) >> Alternatively, perhaps this whole discussion belongs in the Security >> Considerations section. > > They are examples. The security considerations section already has > text > about the weaknesses of BTNS. > >> pg 9, "As [Q] has no formal relationship with [SG-B], rogues can >> impersonate [B] (i.e., assert [B]'s addresses)." >> >> You need to specify what should happen if a second [B] or [SG-B] >> comes along. > > I'm not sure what you mean here. Well, do you want to say anything about what you're going to do if you encounter a second BTNS host that's asserting a conflict network block (i.e., what are you going to do if you have a BTNS SA with SG-B and then a second SG-B comes along)? >> pg. 11, "Leap of faith can work in a similar way for BTNS nodes, but >> it is currently still being designed and specified b y the IETF BNTS >> WG." >> >> This statement is close to useless. Either say something substantive >> or remove it. > > There are RFCs with similar statements (e.g., RFC2743, in relation to > "channel binding"). These kinds of statements are informative, not > normative, and inform the reader about concurrent efforts at the time > that the document was being progressed. Such information can become > stale, and therefore useless, but this is generally true for all RFCs. > > Nico > -- From Nicolas.Williams at sun.com Mon Jul 30 13:29:12 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 30 Jul 2007 15:29:12 -0500 Subject: [anonsec] comments on the BTNS core I-D In-Reply-To: References: <1E2CD67A-DAC3-4981-A4AC-2BEAB31EDE1A@electric-loft.org> <20070730173138.GJ1199@Sun.COM> Message-ID: <20070730202911.GP1199@Sun.COM> On Mon, Jul 30, 2007 at 11:53:25AM -0700, Derrell Piper wrote: > On Jul 30, 2007, at 10:31 AM, Nicolas Williams wrote: > >On Mon, Jul 30, 2007 at 09:26:51AM -0700, Derrell Piper wrote: > >>Overall: > >> > >>'system' 'host' and 'node' are intermingled. 'node' in particular Actually, this is not the case. Looking at the usage in -04 I see - "system" is used as a synonym for "node" in one place; the other uses of it could be in reference to the implementation (as in "operating system") - "node" is mostly, but not always used when referring to a system operating with IPsec support - "host" is used only in reference to systems running behind a security gateway None of these uses seems to be inconsistent with the various glossaries of the IETF. For example, RFC1983 says this about "node": "An addressable device attached to a computer network. See also: host, router." And it says this about "host": "A computer that allows users to communicate with other host computers on a network. Individual users communicate by using application programs, such as electronic mail, Telnet and FTP. [Source: NNSC]." Whereas RFC2828 says this about "host": "(I) Specific Internet Protocol Suite usage: A networked computer that does not forward Internet Protocol packets that are not addressed to the computer itself. (See: router.)" Only RFC2828 defines "system": "(C) In this Glossary, the term is mainly used as an abbreviation for "automated information system"." From the usage of "system" elsewhere in RFC2828 I gather that "automated information system" means something like "computer." RFC4301 seems to use "system" to mean "networked computer" and includes, in some cases, intermediate systems ("A security gateway is an intermediate system..."). RFC4301 mostly does not refer to nodes, but it does not use "system" as having a single meaning ("system" usually appears in RFC4301 with or as a modifier). I see nothing about "node" denoting "possibly a cluster," only that it is a networked, addressable computer, including middle boxes (e.g., routers). OTOH, if a "node" can be replaced by a cluster of other nodes then presumably the cluster should behave as if it were a monolythic node to the best of the implementor's ability. And *this* leads me to conclude that "node" is a perfectly good word to be using in the BTNS core I-D, and in the way that we have used it. > >>implies > >>cluster to some of us and could easily be replaced with 'host' or > >>'system'. I simply fail to see where this implication comes from, although I do not reject the proposition that "every node could be a cluster [i.e., multiple systems behaving as though they were one]." And here I think "system" has a much broader meaning than "node," which leads me to conclude that... > >I'm not sure we want to do that. For one, nothing says that you can't > >cluster BTNS hosts. It is about as difficult to cluster BTNS hosts as > >it is to cluster hosts using IPsec in general (a little worse once you > >add connection latching if you use the dynamic IPsec policy editing > >implementation approach). > > If you just replace 'node' with either 'system' or 'host' throughout, > you'll address my point. ...to replace "node" with "system" would be inappropriate, and to replace "node" with "host" when some nodes in our examples are security gateways (and, therefore, a kind of router), is even more inappropriate still (since "host" is a "node" that does not forward packets, according to at least one glossary). I'd be happy to entertain an argument that "system" or some phrase including that word should replace "node" because RFC4301 does just that, but I've not seen such an argument. I'd also be happy to add a glossary, and to make sure that the I-D is consistent in its use of these three words, but this is a damned short I-D (particularly if you strip off the informative examples). Just how long must we make it?! And I'll note that RFC4301 does not define "system," nor "host," nor "node" in its glossary -- I think it doesn't even use "host" in the sense of "node that doesn't forward packets," which might make it a sloppily written RFC... But I think I'd rather conclude that English is not the formal language that ASN.1, XML, UML, etcetera are, and that this is actually a good thing. > >>You need to specify exactly what happens for every failure mode and > >>you ought to be sending IKE informational or Notify payloads for all > >>error cases. > > > >Failure is handled as specified in RFC4301 and RFC4306. There is a > >separate I-D adding an IKE notify payload to indicate to the peer that > >it has matched a BTNS PAD entry. > > Are there no new BNTS specific errors? Are they described somewhere > else? > > >>Your bracketed notation is confusing. The brackets aren't adding > >>anything. > > > >In the examples? > > Yes, but whatever. It's just notation. Agreed, it's just notation and we'll stick to it. > >>I generally don't like the idea of sending self-signed certificates > >>for ephemeral keys. If the point is solely to maintain IKEv2 > >>semantics, you should say that. Otherwise, there's little reason to > >>require the extra overhead of the certificate processing (and > >>parsing) when all you're really doing is extracting the public key > >>anyway. > > > >Sending such certs is an option, not a requirement. > > I dislike the reference to self-signed certificates here because I > believe the mere reference to them will encourage their use with BTNS > and I don't think that's goodness. It's adding complexity for no > additional value. Sorry, we're allowed to have MAYs, and we'll keep this one. Implementors are free to ignore this "MAY," as usual. > >>pg 6, Figure 1 > >> > >>"In this diagram, there are six end-nodes: A, B, C and D." > >> > >>That's four, not six. Do you mean "...nodes: A, B, C, D, Q and R."? > > > >Yes. > > > >>"Node [D] has a non-fixed address." "non-fixed" meaning what > >>exactly? Why is that relevant? > > > >That it uses DHCP. Michael? > > I assumed as much but I don't see how that's relevant in your examples. It's relevant because dynamically addressed systems can take over each other's addresses with a modicum of active attack effort. Perhaps this needs to be explained in more detail. In -04 we removed text that referred to the problems that may arise from having PAD entries with large address constraints. We presented on these problems at earlier meetings; from Stephen's input we concluded that describing these problems was not important in this document, and that the consequent need to be rigorous in describing them would be a waste of our time. So perhaps it is, indeed, irrelevant now. But I'm not convinced that it's completely irrelevant: because such a system's address can be one of so many it becomes undesirable to write PAD entries for them that say to search the SPD by IP address; of course, we don't have example PAD/SPD entries for \[D\]. Perhaps the examples have served their purpose (help reviewers) and now it's time to remove them? Michael? > >I don't see the implication, particularly when the text is explicit > >about [C] not being protected from other BTNS nodes. > > We agree there's no protection. I still think the fact that you > mention 'rogue nodes' tends to make people question whether or not > BTNS is providing protection from this when in fact it does not (by > design). (FWIW, I do understand what you saying about C and the > PAD.) For now we'll leave this as is. > >>pg 9, "As [Q] has no formal relationship with [SG-B], rogues can > >>impersonate [B] (i.e., assert [B]'s addresses)." > >> > >>You need to specify what should happen if a second [B] or [SG-B] > >>comes along. > > > >I'm not sure what you mean here. > > Well, do you want to say anything about what you're going to do if > you encounter a second BTNS host that's asserting a conflict network > block (i.e., what are you going to do if you have a BTNS SA with SG-B > and then a second SG-B comes along)? The PAD says how to authenticate SG-B, and the text of the I-D tells you that a BTNS node cannot assert SG-B's addresses because child SA requests by BTNS peers MUST be rejected if they assert addresses that are referenced by other non-BTNS PAD entries. The next to last bullet in example #1 covers this too. Nico --