From hartmans-ietf at mit.edu Thu Mar 3 10:24:32 2005 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Thu, 03 Mar 2005 13:24:32 -0500 Subject: [anonsec] BTNS approved for IETF-wide review Message-ID: The IESG discussed the BTNS working group charter today and has decided to send the charter out for external review. This is the first formal step in working group creation. We will hold the BOF next week. From my standpoint the goals include: * Finding people to do work * Finding chairs * Confirming the charter is OK If we can do that and if we have community consensus to create the working group, then I think we are in good shape. --Sam From weiler at tislabs.com Thu Mar 10 12:26:33 2005 From: weiler at tislabs.com (Samuel Weiler) Date: Thu, 10 Mar 2005 15:26:33 -0500 (EST) Subject: [anonsec] BTNS BOF summary Message-ID: First, I would like to thank our scribe, Yushun Wang, for taking wonderful minutes both at this BOF an the previous one in DC -- he has already provided me with a "draft" copy of Monday's minutes that far exceeds most WG's final minutes. I'd also like to thank our ADs for providing well-defined questions for the BOF to answer -- I think those really helped us to stay focused. The BTNS BOF uncovered no signifigant issues in the proposed charter. There were sufficient volunteers for each of the work items to provide some assurance that the work could get done. Those present raised no objection to an aggressive set of milestones that included initial drafts of all documents in two months and advancing all docs to the IESG within nine months (implying that the last of the docs will be in WG last call during the Vancouver meeting). An announcement of the proposed WG was sent to the ietf-announce list on Tuesday, with comments due to the IESG by March 16. -- Sam From weiler at tislabs.com Thu Mar 10 12:28:31 2005 From: weiler at tislabs.com (Samuel Weiler) Date: Thu, 10 Mar 2005 15:28:31 -0500 (EST) Subject: [anonsec] BTNS BOF follow-up items Message-ID: Following up on Monday's BOF, I have a few requests: -- I'd appreciate it if those who volunteered to edit doucments would send a note to me (and the list, if you like) reminding me of what portions of the work items you're interested in. Please provide as much detail as you like, including how interested you are in the different pieces (e.g. you'd do it if no one else wanted to) and about who you'd like to work with (or don't want to work with) as a co-editor. This will all get passed along to the chairs, when they're appointed. -- Would anyone with good notes from the meeting please send them to me, to be used by our designated scribe (Yushun Wang) to fill in gaps in his minutes? -- Those with comments on the charter text, particularly the work items, are encouraged to send them to the ADs. -- The ADs also solicited nominations for WG chair (with self-nomination allowed). Send those privately to the ADs. -- And... if there's a piece of work you think needs to be added to the charter, now's the moment to speak up. From hartmans-ietf at mit.edu Thu Mar 10 13:03:14 2005 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Thu, 10 Mar 2005 16:03:14 -0500 Subject: [anonsec] BTNS BOF summary In-Reply-To: (Samuel Weiler's message of "Thu, 10 Mar 2005 15:26:33 -0500 (EST)") References: Message-ID: Your summary seems inaccurate. It sounded to me like there was a strong consensus behind a new charter requirement that traditional IPsec work along side BTNS. From weiler at tislabs.com Thu Mar 10 13:20:35 2005 From: weiler at tislabs.com (Samuel Weiler) Date: Thu, 10 Mar 2005 16:20:35 -0500 (EST) Subject: [anonsec] BTNS BOF summary In-Reply-To: References: Message-ID: > Your summary seems inaccurate. It sounded to me like there was a > strong consensus behind a new charter requirement that traditional > IPsec work along side BTNS. That's what I get for trying to do that summary in too little time. You're entirely correct, Sam. I'd phrase it more as "there was a strong preference for a new requirement that it be possible to build an implementation that can simultaneouly do BTNS and traditional IPsec". There were, however, a signifigant number (maybe seven hands?) that expressed no interest that requirement -- that would be happy with a BTNS that could not peacefully coexist with traditional IPsec. I'd be a little hesitant to call that _strong_ consensus. -- Sam From pekka.nikander at nomadiclab.com Thu Mar 10 14:06:26 2005 From: pekka.nikander at nomadiclab.com (Pekka Nikander) Date: Thu, 10 Mar 2005 16:06:26 -0600 Subject: [anonsec] BTNS BOF follow-up items In-Reply-To: References: Message-ID: <6f3e334a9cacabeca52580cdebb11f97@nomadiclab.com> > -- I'd appreciate it if those who volunteered to edit doucments would > send a note to me (and the list, if you like) reminding me of what > portions of the work items you're interested in. Please provide as > much detail as you like, including how interested you are in the > different pieces (e.g. you'd do it if no one else wanted to) and > about who you'd like to work with (or don't want to work with) as a > co-editor. This will all get passed along to the chairs, when > they're appointed. I am interested in contributing to the last two items in the charter proposal, mostly from an architectural channel bindings point of view. As I expressed in the meeting, I find the work as an small but important step from the identifier/locator split point of view. If it indeed becomes possible to manage secured connections between hosts using an identifier that has clear security semantics instead of just using IP addresses, I would applaud that as an important step for this community. As I indicated, my primary interest here is architectural, and I am willing to produce text from that point of view. With that in mind, I'm willing to contribute some initial text for the e) document, i.e. explain the situation for higher-level protocol designers from the architectural, identifier/locator split point of view. > -- And... if there's a piece of work you think needs to be added to > the charter, now's the moment to speak up. I would like the situation wrt. channel bindings to be clarified. I find the current charter proposal somewhat ambiguous. --Pekka Nikander From touch at ISI.EDU Thu Mar 10 19:22:02 2005 From: touch at ISI.EDU (Joe Touch) Date: Thu, 10 Mar 2005 19:22:02 -0800 Subject: [anonsec] BTNS BOF follow-up items In-Reply-To: References: Message-ID: <42310EDA.6090303@isi.edu> Samuel Weiler wrote: > Following up on Monday's BOF, I have a few requests: > > -- I'd appreciate it if those who volunteered to edit doucments would > send a note to me (and the list, if you like) reminding me of what > portions of the work items you're interested in. Please provide as > much detail as you like, including how interested you are in the > different pieces (e.g. you'd do it if no one else wanted to) and > about who you'd like to work with (or don't want to work with) as a > co-editor. This will all get passed along to the chairs, when > they're appointed. I'm interested in the "Problem statement" (which I prefer to call item #1, rather than "Framework" as it was listed), and the "Applicability Statement" (item #2), merging the two as a single doc, as was suggested. As to the other docs, I would be glad to provide feedback primarily. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 263 bytes Desc: not available Url : http://www.postel.org/pipermail/anonsec/attachments/20050310/f8e08489/signature.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/anonsec/attachments/20050310/f8e08489/signature-0001.bin From Nicolas.Williams at sun.com Sat Mar 12 23:28:33 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Sun, 13 Mar 2005 01:28:33 -0600 Subject: [anonsec] BTNS BOF follow-up items In-Reply-To: References: Message-ID: <20050313072833.GA1007@binky.Central.Sun.COM> On Thu, Mar 10, 2005 at 03:28:31PM -0500, Samuel Weiler wrote: > Following up on Monday's BOF, I have a few requests: > > -- I'd appreciate it if those who volunteered to edit doucments would > send a note to me (and the list, if you like) reminding me of what > portions of the work items you're interested in. Please provide as > much detail as you like, including how interested you are in the > different pieces (e.g. you'd do it if no one else wanted to) and > about who you'd like to work with (or don't want to work with) as a > co-editor. This will all get passed along to the chairs, when > they're appointed. I'll be writing a document on: - BTNS use of IKEv1/2 and 2401/2401bis in *BITS* (and BITW) mode - BTNS use of IKEv1/2 and 2401/2401bis in *native* mode - which includes specification of how to construct IPsec "channels" and references to API requirements and related matters, which will cover, IIRC, parts of items (c) through (d) or even (e). This will be an individual submission I-D. > -- Those with comments on the charter text, particularly the work > items, are encouraged to send them to the ADs. I think we should review the charter after we get some comments to the I-D I promise above. > -- And... if there's a piece of work you think needs to be added to > the charter, now's the moment to speak up. See above. Nico -- From ekr at rtfm.com Mon Mar 14 08:12:41 2005 From: ekr at rtfm.com (Eric Rescorla) Date: Mon, 14 Mar 2005 08:12:41 -0800 Subject: [anonsec] Automatic detection of BTNS capability Message-ID: <20050314163135.BB59C28507@sierra.rtfm.com> Post the BOF in MSP, I've been thinking about how BTNS works in practice. In particular, do you want to be able to use it with hosts that you don't already know support IPsec in some flavor (either traditional or BTNS), but fall back to plaintext if it's not available. If the answer is yes, then you're faced with the question of how you detect whether the peer implements IPsec. [0] The obvious approach is simply to do the traditional IPsec thing and hold the initial packets until the IKE handshake has completed. However, if the peer doesn't do IKE and has firewalled off that port, then you're stuck waiting for the timeout. This really delays the initiation of the connection. The other option is to start sending traffic right away and do the IKE handshake in parallel. Then if the IKE handshake completes you switch over. Obviously, this makes sense in the face of the "no active attacks" assumption, but it seems like a fairly substantial change to the IPsec model... -Ekr [0] This isn't a problem with traditional IPsec because if your policy requires protection, you won't be able to communicate with non-IPsec hosts anyway. From Nicolas.Williams at sun.com Mon Mar 14 09:32:08 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 14 Mar 2005 11:32:08 -0600 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: <20050314163135.BB59C28507@sierra.rtfm.com> References: <20050314163135.BB59C28507@sierra.rtfm.com> Message-ID: <20050314173208.GD1007@binky.Central.Sun.COM> On Mon, Mar 14, 2005 at 08:12:41AM -0800, Eric Rescorla wrote: > Post the BOF in MSP, I've been thinking about how BTNS works in > practice. In particular, do you want to be able to use it with hosts > that you don't already know support IPsec in some flavor (either > traditional or BTNS), but fall back to plaintext if it's not > available. If the answer is yes, then you're faced with the question of > how you detect whether the peer implements IPsec. [0] We want this to be an option. Note that Joe's requirements are that active attacks are only possible at first, that after a successful initial exchange MITMs no longer work. A downgrade attack is an active attack that BTNS can't defend against except through policy, or interfaces, which disallow fallback onto unauthenticated plaintext. > The obvious approach is simply to do the traditional IPsec thing and > hold the initial packets until the IKE handshake has completed. However, > if the peer doesn't do IKE and has firewalled off that port, then you're > stuck waiting for the timeout. This really delays the initiation of the > connection. If you're willing to fallback on unauthenticated plaintext, which should not be a default. Otherwise this is no worse than IPsec is today. > The other option is to start sending traffic right away and do the > IKE handshake in parallel. Then if the IKE handshake completes you > switch over. Obviously, this makes sense in the face of the > "no active attacks" assumption, but it seems like a fairly substantial > change to the IPsec model... No, I don't think we want this -- I don't, anyways. Joe? But note that BTNS has other implications as well. Assuming BITS implementations the only way to avoid MITM attacks subsequent to the initial exchange is to make a persistent {IP addr, pubkey} association -- like secsh leap-of-faith -- and that may have implications for mobile networking. > -Ekr > > [0] This isn't a problem with traditional IPsec because if your policy > requires protection, you won't be able to communicate with non-IPsec > hosts anyway. Right. Nico -- From sommerfeld at sun.com Mon Mar 14 10:17:49 2005 From: sommerfeld at sun.com (Bill Sommerfeld) Date: Mon, 14 Mar 2005 13:17:49 -0500 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: <20050314163135.BB59C28507@sierra.rtfm.com> References: <20050314163135.BB59C28507@sierra.rtfm.com> Message-ID: <1110824268.27077.155.camel@thunk> On Mon, 2005-03-14 at 11:12, Eric Rescorla wrote: > The other option is to start sending traffic right away and do the > IKE handshake in parallel. Then if the IKE handshake completes you > switch over. Obviously, this makes sense in the face of the > "no active attacks" assumption, but it seems like a fairly substantial > change to the IPsec model... yes, though I believe the some of the opportunistic IPsec folk may already have running code for the latter model. There are clearly possible hybrid models: - give IKE a short time to claim the traffic; after that, send cleartext until an SA arrives (which may never happen). - if others to initiate BTNS to us, use it in reply -- but we always initiate in the clear/never initiate any connection (pure server). - if we know a BTNS key for the peer, try harder. - have history via ssh-style initial-leap-of-faith - ipseckey or equivalent in DNS - ??? - "allow BTNS" and "require BTNS" modes can be made compatible. the above is intended as food for thought. pruning will be needed to keep our scope manageable. From touch at ISI.EDU Mon Mar 14 10:53:40 2005 From: touch at ISI.EDU (Joe Touch) Date: Mon, 14 Mar 2005 10:53:40 -0800 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: <20050314173208.GD1007@binky.Central.Sun.COM> References: <20050314163135.BB59C28507@sierra.rtfm.com> <20050314173208.GD1007@binky.Central.Sun.COM> Message-ID: <4235DDB4.5020205@isi.edu> Nicolas Williams wrote: > On Mon, Mar 14, 2005 at 08:12:41AM -0800, Eric Rescorla wrote: ... >>The other option is to start sending traffic right away and do the >>IKE handshake in parallel. Then if the IKE handshake completes you >>switch over. Obviously, this makes sense in the face of the >>"no active attacks" assumption, but it seems like a fairly substantial >>change to the IPsec model... > > No, I don't think we want this -- I don't, anyways. Joe? IMO, that doesn't make sense (I agree with Nico). It'd be like using IKE but passing traffic until you do IKE - you don't do that now, you wouldn't with BTNS. > But note that BTNS has other implications as well. > > Assuming BITS implementations the only way to avoid MITM attacks > subsequent to the initial exchange is to make a persistent {IP addr, > pubkey} association -- like secsh leap-of-faith -- and that may have > implications for mobile networking. Yes - if you change your IP address, and don't do something to hide that from IPsec (e.g., use a tunnel over the parts that change), then you'd have to reassociate with the new addresses. Mobility already breaks lots of things when renumbering; BTNS is not new in this regard. BTNS doesn't add anything to that discussion, so IMO it is sufficient to ignore that issue as BTNS-specific. >>-Ekr >> >>[0] This isn't a problem with traditional IPsec because if your policy >>requires protection, you won't be able to communicate with non-IPsec >>hosts anyway. > > Right. > > Nico You decide if you want to require BTNS or use it where it's available. In the first case, you drop all attempts that don't handshake in IKE. In the second, you drop packets until IKE succeeds or fails, and notify the app (a flag that it would be able to check). Apps that care can put up a "locked padlock" icon, use the connection with an "unlocked padlock", or drop the connection themselves then. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/anonsec/attachments/20050314/aad51ffb/signature.bin From ekr at rtfm.com Mon Mar 14 11:08:26 2005 From: ekr at rtfm.com (Eric Rescorla) Date: Mon, 14 Mar 2005 11:08:26 -0800 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: Your message of "Mon, 14 Mar 2005 10:53:40 PST." <4235DDB4.5020205@isi.edu> Message-ID: <20050314192721.0772D28529@sierra.rtfm.com> Joe Touch wrote: > You decide if you want to require BTNS or use it where it's > available. In the first case, you drop all attempts that don't > handshake in IKE. > > In the second, you drop packets until IKE succeeds or fails, and > notify the app (a flag that it would be able to check). Apps that care > can put up a "locked padlock" icon, use the connection with an > "unlocked padlock", or drop the connection themselves then. This seems to have pretty undesirable performance consequences. I don't think I'd be willing to use the "use if available" setting if it implies this kind of delay when I connect to large fractions of the Internet. -Ekr From Nicolas.Williams at sun.com Mon Mar 14 11:14:20 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 14 Mar 2005 13:14:20 -0600 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: <4235DDB4.5020205@isi.edu> References: <20050314163135.BB59C28507@sierra.rtfm.com> <20050314173208.GD1007@binky.Central.Sun.COM> <4235DDB4.5020205@isi.edu> Message-ID: <20050314191419.GL1007@binky.Central.Sun.COM> On Mon, Mar 14, 2005 at 10:53:40AM -0800, Joe Touch wrote: > Nicolas Williams wrote: > >On Mon, Mar 14, 2005 at 08:12:41AM -0800, Eric Rescorla wrote: > ... > >>The other option is to start sending traffic right away and do the > >>IKE handshake in parallel. Then if the IKE handshake completes you > >>switch over. Obviously, this makes sense in the face of the > >>"no active attacks" assumption, but it seems like a fairly substantial > >>change to the IPsec model... > > > >No, I don't think we want this -- I don't, anyways. Joe? > > IMO, that doesn't make sense (I agree with Nico). It'd be like using IKE > but passing traffic until you do IKE - you don't do that now, you > wouldn't with BTNS. > > >But note that BTNS has other implications as well. > > > >Assuming BITS implementations the only way to avoid MITM attacks > >subsequent to the initial exchange is to make a persistent {IP addr, > >pubkey} association -- like secsh leap-of-faith -- and that may have > >implications for mobile networking. > > Yes - if you change your IP address, and don't do something to hide that > from IPsec (e.g., use a tunnel over the parts that change), then you'd > have to reassociate with the new addresses. It's worse than that -- the mobile client's peers might be running BTNS too, so now they'll have a persistent {IP address, pubkey} mapping that prevents re-use of that IP address with BTNS by other clients. I've been thinking about this and related issues a lot lately. When I said, at the BoF, that BTNS really needs APIs to be really useful, I meant it :) -- w/o APIs we run into such problems as this one, which, while not fatal, do make BTNS less useful than we might have hoped for. > Mobility already breaks lots of things when renumbering; BTNS is not new > in this regard. BTNS doesn't add anything to that discussion, so IMO it > is sufficient to ignore that issue as BTNS-specific. Yes, but BTNS + APIs + channel bindings do add a lot in this regard. And opportunistic IPsec + APIs too add a lot. Pekka was right -- HIP encompasses a lot of functionality that we're seeking piecemeal and elsewhere in the IETF. OTOH, it may be that the only way to reach HIP deployment is piecemeal. A holistic view of the problem should include APIs to IPsec, key distribution by PKI, through DNSSEC, and unauthenticated key distribution (as in BTNS), the last one being particularly useful for those interested in channel bindings to IPsec. > You decide if you want to require BTNS or use it where it's available. > In the first case, you drop all attempts that don't handshake in IKE. Yup. > In the second, you drop packets until IKE succeeds or fails, and notify > the app (a flag that it would be able to check). Please expand on this. What do you mean by "flag?" Existing error codes in existing APIs? Or new APIs? > Apps that care can put > up a "locked padlock" icon, use the connection with an "unlocked > padlock", or drop the connection themselves then. Well, this implies APIs. Nico -- From Nicolas.Williams at sun.com Mon Mar 14 11:19:00 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 14 Mar 2005 13:19:00 -0600 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: <20050314192721.0772D28529@sierra.rtfm.com> References: <4235DDB4.5020205@isi.edu> <20050314192721.0772D28529@sierra.rtfm.com> Message-ID: <20050314191900.GN1007@binky.Central.Sun.COM> On Mon, Mar 14, 2005 at 11:08:26AM -0800, Eric Rescorla wrote: > Joe Touch wrote: > > You decide if you want to require BTNS or use it where it's > > available. In the first case, you drop all attempts that don't > > handshake in IKE. > > > > In the second, you drop packets until IKE succeeds or fails, and > > notify the app (a flag that it would be able to check). Apps that care > > can put up a "locked padlock" icon, use the connection with an > > "unlocked padlock", or drop the connection themselves then. > > This seems to have pretty undesirable performance consequences. > I don't think I'd be willing to use the "use if available" > setting if it implies this kind of delay when I connect > to large fractions of the Internet. Hopefully all peers send port unreachable ICMPs if IKE is not running; that should help. Opportunistic IPsec, HIP, involve doing additional DNS[SEC] lookups too. Those will slow you down also... I'm not sure that BTNS w/ BITS (i.e., w/o APIs) will be useful in the open Internet, particularly for mobile users, though it will be useful in Joe's intended scenario (i.e., between routers). Nico -- From ekr at rtfm.com Mon Mar 14 11:36:20 2005 From: ekr at rtfm.com (Eric Rescorla) Date: Mon, 14 Mar 2005 11:36:20 -0800 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: Your message of "Mon, 14 Mar 2005 13:19:00 CST." <20050314191900.GN1007@binky.Central.Sun.COM> Message-ID: <20050314195515.01126284F1@sierra.rtfm.com> Nicolas Williams wrote: > On Mon, Mar 14, 2005 at 11:08:26AM -0800, Eric Rescorla wrote: > > Joe Touch wrote: > > > You decide if you want to require BTNS or use it where it's > > > available. In the first case, you drop all attempts that don't > > > handshake in IKE. > > > > > > In the second, you drop packets until IKE succeeds or fails, and > > > notify the app (a flag that it would be able to check). Apps that care > > > can put up a "locked padlock" icon, use the connection with an > > > "unlocked padlock", or drop the connection themselves then. > > > > This seems to have pretty undesirable performance consequences. > > I don't think I'd be willing to use the "use if available" > > setting if it implies this kind of delay when I connect > > to large fractions of the Internet. > > Hopefully all peers send port unreachable ICMPs if IKE is not running; > that should help. Well, my machines blackhole all forbidden UDP traffic. I imagine this is a fairly common firewall config. > Opportunistic IPsec, HIP, involve doing additional DNS[SEC] lookups too. > Those will slow you down also... Yes, but they're just normal success or failure things, not reliant on timeouts. We're potentially talking 30-120 seconds here... -Ekr From touch at ISI.EDU Mon Mar 14 11:52:29 2005 From: touch at ISI.EDU (Joe Touch) Date: Mon, 14 Mar 2005 11:52:29 -0800 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: <20050314192721.0772D28529@sierra.rtfm.com> References: <20050314192721.0772D28529@sierra.rtfm.com> Message-ID: <4235EB7D.3050705@isi.edu> Eric Rescorla wrote: > Joe Touch wrote: > >>You decide if you want to require BTNS or use it where it's >>available. In the first case, you drop all attempts that don't >>handshake in IKE. >> >>In the second, you drop packets until IKE succeeds or fails, and >>notify the app (a flag that it would be able to check). Apps that care >>can put up a "locked padlock" icon, use the connection with an >>"unlocked padlock", or drop the connection themselves then. > > This seems to have pretty undesirable performance consequences. > I don't think I'd be willing to use the "use if available" > setting if it implies this kind of delay when I connect > to large fractions of the Internet. You use things like that now when you go to some web pages. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/anonsec/attachments/20050314/473035e0/signature-0001.bin From ekr at rtfm.com Mon Mar 14 12:09:22 2005 From: ekr at rtfm.com (Eric Rescorla) Date: Mon, 14 Mar 2005 12:09:22 -0800 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: Your message of "Mon, 14 Mar 2005 11:52:29 PST." <4235EB7D.3050705@isi.edu> Message-ID: <20050314202816.E96A828507@sierra.rtfm.com> Joe Touch wrote: > Eric Rescorla wrote: > > Joe Touch wrote: > > > >>You decide if you want to require BTNS or use it where it's > >>available. In the first case, you drop all attempts that don't > >>handshake in IKE. > >> > >>In the second, you drop packets until IKE succeeds or fails, and > >>notify the app (a flag that it would be able to check). Apps that care > >>can put up a "locked padlock" icon, use the connection with an > >>"unlocked padlock", or drop the connection themselves then. > > This seems to have pretty undesirable performance consequences. > > I don't think I'd be willing to use the "use if available" > > setting if it implies this kind of delay when I connect > > to large fractions of the Internet. > > You use things like that now when you go to some web pages. How's that? If I have a URL in hand, there's a reasonable expectation that I can make a TCP connection to that host/port pair immediately, within the characteristics of the network. I certainly don't expect to wait a minute for the initial connection. -Ekr From touch at ISI.EDU Mon Mar 14 15:16:26 2005 From: touch at ISI.EDU (Joe Touch) Date: Mon, 14 Mar 2005 15:16:26 -0800 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: <20050314202816.E96A828507@sierra.rtfm.com> References: <20050314202816.E96A828507@sierra.rtfm.com> Message-ID: <42361B4A.7060902@isi.edu> Eric Rescorla wrote: > Joe Touch wrote: > >>Eric Rescorla wrote: >> >>>Joe Touch wrote: >>> >>> >>>>You decide if you want to require BTNS or use it where it's >>>>available. In the first case, you drop all attempts that don't >>>>handshake in IKE. >>>> >>>>In the second, you drop packets until IKE succeeds or fails, and >>>>notify the app (a flag that it would be able to check). Apps that care >>>>can put up a "locked padlock" icon, use the connection with an >>>>"unlocked padlock", or drop the connection themselves then. >>> >>>This seems to have pretty undesirable performance consequences. >>>I don't think I'd be willing to use the "use if available" >>>setting if it implies this kind of delay when I connect >>>to large fractions of the Internet. >> >>You use things like that now when you go to some web pages. > > How's that? If I have a URL in hand, there's a reasonable > expectation that I can make a TCP connection to that > host/port pair immediately, within the characteristics of > the network. I certainly don't expect to wait a minute > for the initial connection. > > -Ekr It's not a minute, but it is a few different handshakes. It happens all the time - IPv4 vs. IPv6, http vs. https, etc. Some apps do implement this 'try if available, and if not try the other'. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/anonsec/attachments/20050314/4d774dc0/signature.bin From touch at ISI.EDU Mon Mar 14 15:21:14 2005 From: touch at ISI.EDU (Joe Touch) Date: Mon, 14 Mar 2005 15:21:14 -0800 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: <20050314191419.GL1007@binky.Central.Sun.COM> References: <20050314163135.BB59C28507@sierra.rtfm.com> <20050314173208.GD1007@binky.Central.Sun.COM> <4235DDB4.5020205@isi.edu> <20050314191419.GL1007@binky.Central.Sun.COM> Message-ID: <42361C6A.5030808@isi.edu> Nicolas Williams wrote: > On Mon, Mar 14, 2005 at 10:53:40AM -0800, Joe Touch wrote: > >>Nicolas Williams wrote: ... >>Yes - if you change your IP address, and don't do something to hide that >>from IPsec (e.g., use a tunnel over the parts that change), then you'd >>have to reassociate with the new addresses. > > It's worse than that -- the mobile client's peers might be running BTNS > too, so now they'll have a persistent {IP address, pubkey} mapping that > prevents re-use of that IP address with BTNS by other clients. > > I've been thinking about this and related issues a lot lately. > > When I said, at the BoF, that BTNS really needs APIs to be really > useful, I meant it :) -- w/o APIs we run into such problems as this > one, which, while not fatal, do make BTNS less useful than we might have > hoped for. Dealing with mobility might be something we discuss later; let's get the non-mobile case working first. If we spend too much time worrying about "making BTNS less useful than it might be" we defeat the purpose- 'better than nothing'. 'As useful as it might be' is the enemy of 'good enough'. >>Mobility already breaks lots of things when renumbering; BTNS is not new >>in this regard. BTNS doesn't add anything to that discussion, so IMO it >>is sufficient to ignore that issue as BTNS-specific. > > > Yes, but BTNS + APIs + channel bindings do add a lot in this regard. > > And opportunistic IPsec + APIs too add a lot. > > Pekka was right -- HIP encompasses a lot of functionality that we're > seeking piecemeal and elsewhere in the IETF. OTOH, it may be that the > only way to reach HIP deployment is piecemeal. > > A holistic view of the problem should include APIs to IPsec, key > distribution by PKI, through DNSSEC, and unauthenticated key > distribution (as in BTNS), the last one being particularly useful for > those interested in channel bindings to IPsec. BTNS is a specific solution; the holistic view can be discussed elswhere, IMO. >>You decide if you want to require BTNS or use it where it's available. >>In the first case, you drop all attempts that don't handshake in IKE. > > > Yup. > > >>In the second, you drop packets until IKE succeeds or fails, and notify >>the app (a flag that it would be able to check). > > > Please expand on this. What do you mean by "flag?" Existing error > codes in existing APIs? Or new APIs? Error codes in existing APIs if at all possible. >> Apps that care can put >>up a "locked padlock" icon, use the connection with an "unlocked >>padlock", or drop the connection themselves then. > > > Well, this implies APIs. > > Nico See above. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/anonsec/attachments/20050314/fc760d4b/signature.bin From touch at ISI.EDU Mon Mar 14 15:26:48 2005 From: touch at ISI.EDU (Joe Touch) Date: Mon, 14 Mar 2005 15:26:48 -0800 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: <1110824268.27077.155.camel@thunk> References: <20050314163135.BB59C28507@sierra.rtfm.com> <1110824268.27077.155.camel@thunk> Message-ID: <42361DB8.8030806@isi.edu> Bill Sommerfeld wrote: > On Mon, 2005-03-14 at 11:12, Eric Rescorla wrote: > >>The other option is to start sending traffic right away and do the >>IKE handshake in parallel. Then if the IKE handshake completes you >>switch over. Obviously, this makes sense in the face of the >>"no active attacks" assumption, but it seems like a fairly substantial >>change to the IPsec model... > > > yes, though I believe the some of the opportunistic IPsec folk may already > have running code for the latter model. > > There are clearly possible hybrid models: > - give IKE a short time to claim the traffic; after that, send cleartext > until an SA arrives (which may never happen). I don't understand this. Once you send cleartext, you're compromised, and you can't trust that subsequent communication is in the secure context alone. > - if others to initiate BTNS to us, use it in reply -- but we always > initiate in the clear/never initiate any connection (pure server). There are variants of whether to require it for all incoming or outgoing. That seems like SPD configuration more than something we need to address by mechanism, though. > - if we know a BTNS key for the peer, try harder. > - have history via ssh-style initial-leap-of-faith > - ipseckey or equivalent in DNS > - ??? Initial leap-of-faith is how I think of BTNS working. Use of the DNS for keying is a non-starter here - that's just moving the infrastructure; BTNS is about avoiding infrastructure, not moving it. > - "allow BTNS" and "require BTNS" modes can be made compatible. Compatible with each other? They are - they'd use BTNS. Or did you mean something else? > the above is intended as food for thought. pruning will be needed to > keep our scope manageable. Definitely! (IMO) Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/anonsec/attachments/20050314/3948cb96/signature.bin From touch at ISI.EDU Mon Mar 14 15:30:36 2005 From: touch at ISI.EDU (Joe Touch) Date: Mon, 14 Mar 2005 15:30:36 -0800 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: <20050314191900.GN1007@binky.Central.Sun.COM> References: <4235DDB4.5020205@isi.edu> <20050314192721.0772D28529@sierra.rtfm.com> <20050314191900.GN1007@binky.Central.Sun.COM> Message-ID: <42361E9C.1000902@isi.edu> Nicolas Williams wrote: > On Mon, Mar 14, 2005 at 11:08:26AM -0800, Eric Rescorla wrote: > >>Joe Touch wrote: >> >>>You decide if you want to require BTNS or use it where it's >>>available. In the first case, you drop all attempts that don't >>>handshake in IKE. >>> >>>In the second, you drop packets until IKE succeeds or fails, and >>>notify the app (a flag that it would be able to check). Apps that care >>>can put up a "locked padlock" icon, use the connection with an >>>"unlocked padlock", or drop the connection themselves then. >> >>This seems to have pretty undesirable performance consequences. >>I don't think I'd be willing to use the "use if available" >>setting if it implies this kind of delay when I connect >>to large fractions of the Internet. > > > Hopefully all peers send port unreachable ICMPs if IKE is not running; > that should help. > > Opportunistic IPsec, HIP, involve doing additional DNS[SEC] lookups too. > Those will slow you down also... Not if I don't use them ;-) It's not "IKE w/CA or key, IKE via DNS key, BTNS, then cleartext", IMO. BTNS is appropriate only where you don't care about out-of-band identity. If you do, use CAs or shared keys (preshared or DNS-distributed). You'd only use BTNS where you don't. If you don't care about out-of-band identity, then you MIGHT allow cleartext, though. I can see the BTNS then cleartext variant being useful, e.g., for a webserver (which could throttle non-BTNS connections if under heavy load, to avoid potential attackers). > I'm not sure that BTNS w/ BITS (i.e., w/o APIs) will be useful in the > open Internet, particularly for mobile users, though it will be useful > in Joe's intended scenario (i.e., between routers). > > Nico IMO, BTNS w/o APIs will be very useful. I don't see many mobile users now, and I do see many web users. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/anonsec/attachments/20050314/48f26278/signature.bin From ekr at rtfm.com Mon Mar 14 16:03:53 2005 From: ekr at rtfm.com (Eric Rescorla) Date: Mon, 14 Mar 2005 16:03:53 -0800 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: Your message of "Mon, 14 Mar 2005 15:16:26 PST." <42361B4A.7060902@isi.edu> Message-ID: <20050315002247.5FD2F284D1@sierra.rtfm.com> Joe Touch wrote: > It's not a minute, but it is a few different handshakes. It happens > all the time - IPv4 vs. IPv6, http vs. https, etc. Some apps do > implement this 'try if available, and if not try the other'. Well, I don't even have an IPv6 address, so I'd be pretty surprised if my apps attempted IPv6 before IPv4. And if turning on IPv6 created this behavior, I would most certainly immediately turn it back off again. As for HTTPS, browsers are guided by the protocol in the URL. They don't fall back to HTTP if HTTPS fails. They just throw an error. They also don't try HTTPS before HTTP if provided with an HTTP URL. -Ekr From ekr at rtfm.com Mon Mar 14 16:05:24 2005 From: ekr at rtfm.com (Eric Rescorla) Date: Mon, 14 Mar 2005 16:05:24 -0800 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: Your message of "Mon, 14 Mar 2005 15:30:36 PST." <42361E9C.1000902@isi.edu> Message-ID: <20050315002418.DAA19284D1@sierra.rtfm.com> Joe Touch wrote: > If you don't care about out-of-band identity, then you MIGHT allow > cleartext, though. I can see the BTNS then cleartext variant being > useful, e.g., for a webserver (which could throttle non-BTNS > connections if under heavy load, to avoid potential attackers). I would think more importantly for clients.... However, I don't see how that can work if it creates an enormous performance hit. -Ekr From Nicolas.Williams at sun.com Mon Mar 14 18:40:10 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 14 Mar 2005 20:40:10 -0600 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: <42361C6A.5030808@isi.edu> References: <20050314163135.BB59C28507@sierra.rtfm.com> <20050314173208.GD1007@binky.Central.Sun.COM> <4235DDB4.5020205@isi.edu> <20050314191419.GL1007@binky.Central.Sun.COM> <42361C6A.5030808@isi.edu> Message-ID: <20050315024010.GV1007@binky.Central.Sun.COM> On Mon, Mar 14, 2005 at 03:21:14PM -0800, Joe Touch wrote: > Nicolas Williams wrote: > >On Mon, Mar 14, 2005 at 10:53:40AM -0800, Joe Touch wrote: > > > >>Nicolas Williams wrote: > ... > >>Yes - if you change your IP address, and don't do something to hide that > >>from IPsec (e.g., use a tunnel over the parts that change), then you'd > >>have to reassociate with the new addresses. > > > >It's worse than that -- the mobile client's peers might be running BTNS > >too, so now they'll have a persistent {IP address, pubkey} mapping that > >prevents re-use of that IP address with BTNS by other clients. > > > >I've been thinking about this and related issues a lot lately. > > > >When I said, at the BoF, that BTNS really needs APIs to be really > >useful, I meant it :) -- w/o APIs we run into such problems as this > >one, which, while not fatal, do make BTNS less useful than we might have > >hoped for. > > Dealing with mobility might be something we discuss later; let's get the > non-mobile case working first. Of course. We must, though, understand why a BITS BTNS host might or might not work well as a mobile peer or with mobile BTNS peers. > If we spend too much time worrying about "making BTNS less useful than > it might be" we defeat the purpose- 'better than nothing'. 'As useful as > it might be' is the enemy of 'good enough'. Who said anything about limiting BTNS' usefulness? As to making it more useful, I do seem to recall some charter items at Monday's meeting that did just that. I do believe we should and will specify something that works with fairly naive IPsec implementations (e.g., BITS types). But remember, we do need to look at channels too, so those of us interested in channel bindings have channels to bind to. And realize that without native IPsec / IPsec APIs or IPsec channels BTNS will be of limited usefulness, whether you like that or not. My I-D will explain why; for the time being I'd rather work on the I-D than debate these matters. [...] > >Yes, but BTNS + APIs + channel bindings do add a lot in this regard. > > > >And opportunistic IPsec + APIs too add a lot. > > > >Pekka was right -- HIP encompasses a lot of functionality that we're > >seeking piecemeal and elsewhere in the IETF. OTOH, it may be that the > >only way to reach HIP deployment is piecemeal. > > > >A holistic view of the problem should include APIs to IPsec, key > >distribution by PKI, through DNSSEC, and unauthenticated key > >distribution (as in BTNS), the last one being particularly useful for > >those interested in channel bindings to IPsec. > > BTNS is a specific solution; the holistic view can be discussed > elswhere, IMO. It is being discussed elsewhere now. I'm not trying to enlarge this putative WG's scope, but we must consider BTNS in the context of other goings on at the IETF -- we ought not work in a vaccuum. > >>You decide if you want to require BTNS or use it where it's available. > >>In the first case, you drop all attempts that don't handshake in IKE. > > > > > >Yup. > > > > > >>In the second, you drop packets until IKE succeeds or fails, and notify > >>the app (a flag that it would be able to check). > > > > > >Please expand on this. What do you mean by "flag?" Existing error > >codes in existing APIs? Or new APIs? > > Error codes in existing APIs if at all possible. 'K. From Nicolas.Williams at sun.com Mon Mar 14 18:48:27 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 14 Mar 2005 20:48:27 -0600 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: <42361E9C.1000902@isi.edu> References: <4235DDB4.5020205@isi.edu> <20050314192721.0772D28529@sierra.rtfm.com> <20050314191900.GN1007@binky.Central.Sun.COM> <42361E9C.1000902@isi.edu> Message-ID: <20050315024827.GW1007@binky.Central.Sun.COM> On Mon, Mar 14, 2005 at 03:30:36PM -0800, Joe Touch wrote: > Nicolas Williams wrote: > >Opportunistic IPsec, HIP, involve doing additional DNS[SEC] lookups too. > >Those will slow you down also... > > Not if I don't use them ;-) :) > It's not "IKE w/CA or key, IKE via DNS key, BTNS, then cleartext", IMO. But that could be a reasonable configuration. > BTNS is appropriate only where you don't care about out-of-band > identity. If you do, use CAs or shared keys (preshared or > DNS-distributed). You'd only use BTNS where you don't. We decided, one week ago, that BTNS and normal IPsec should be able to co-exist on the same host, and concurrently. That means that it must be possible to care about using PKI, PSK, keys in DNS[SEC], for some peers and unauthenticated public keys (BTNS) for others; that does not mean that one needs a fallback-type policy for IKE though, but such policies may yet be desirable. > >I'm not sure that BTNS w/ BITS (i.e., w/o APIs) will be useful in the > >open Internet, particularly for mobile users, though it will be useful > >in Joe's intended scenario (i.e., between routers). > > > >Nico > > IMO, BTNS w/o APIs will be very useful. I don't see many mobile users > now, and I do see many web users. It will be useful for the cases you care about, not for the ones I care about. We can deal with both by first addressing the simple BTNS case (the one that is useful to your use cases) and then, possibly separately, specifying what else is needed to make it useful in other use cases. Nico -- From touch at ISI.EDU Mon Mar 14 22:07:05 2005 From: touch at ISI.EDU (Joe Touch) Date: Mon, 14 Mar 2005 22:07:05 -0800 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: <20050315024827.GW1007@binky.Central.Sun.COM> References: <4235DDB4.5020205@isi.edu> <20050314192721.0772D28529@sierra.rtfm.com> <20050314191900.GN1007@binky.Central.Sun.COM> <42361E9C.1000902@isi.edu> <20050315024827.GW1007@binky.Central.Sun.COM> Message-ID: <42367B89.3020601@isi.edu> Nicolas Williams wrote: > On Mon, Mar 14, 2005 at 03:30:36PM -0800, Joe Touch wrote: ... >>It's not "IKE w/CA or key, IKE via DNS key, BTNS, then cleartext", IMO. > > > But that could be a reasonable configuration. Can you show an example? Why would I try to identify the endpoint, but if I can't then accept non-identified? >>BTNS is appropriate only where you don't care about out-of-band >>identity. If you do, use CAs or shared keys (preshared or >>DNS-distributed). You'd only use BTNS where you don't. > > We decided, one week ago, that BTNS and normal IPsec should be able to > co-exist on the same host, and concurrently. > > That means that it must be possible to care about using PKI, PSK, keys > in DNS[SEC], for some peers and unauthenticated public keys (BTNS) for > others; that does not mean that one needs a fallback-type policy for > IKE though, but such policies may yet be desirable. Why is having different policies for different endpoints relevant to having fallbacks? BTNS isn't a variant of IPsec that's exclusive IMO. It's a flag on an SPD, or at least that's how I think of it. Once you set the flag, you're saying "out-of-band identity doesn't matter" - so why are you bothering with checking SAs at that point? >>>I'm not sure that BTNS w/ BITS (i.e., w/o APIs) will be useful in the >>>open Internet, particularly for mobile users, though it will be useful >>>in Joe's intended scenario (i.e., between routers). >>> >>>Nico >> >>IMO, BTNS w/o APIs will be very useful. I don't see many mobile users >>now, and I do see many web users. > > It will be useful for the cases you care about, not for the ones I care > about. We can deal with both by first addressing the simple BTNS case > (the one that is useful to your use cases) and then, possibly > separately, specifying what else is needed to make it useful in other > use cases. Definitely. What I hope we can do is figure out how to do BTNS as a mode of an IPsec SPD, then elaborate on it as we go. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/anonsec/attachments/20050314/b15a9fea/signature.bin From touch at ISI.EDU Mon Mar 14 22:08:00 2005 From: touch at ISI.EDU (Joe Touch) Date: Mon, 14 Mar 2005 22:08:00 -0800 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: <20050315002418.DAA19284D1@sierra.rtfm.com> References: <20050315002418.DAA19284D1@sierra.rtfm.com> Message-ID: <42367BC0.3020704@isi.edu> Eric Rescorla wrote: > Joe Touch wrote: > >>If you don't care about out-of-band identity, then you MIGHT allow >>cleartext, though. I can see the BTNS then cleartext variant being >>useful, e.g., for a webserver (which could throttle non-BTNS >>connections if under heavy load, to avoid potential attackers). > > > I would think more importantly for clients.... However, I don't > see how that can work if it creates an enormous performance hit. > > -Ekr The 'heavy load' referred to would be from a perceived attack, not a performance hit. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/anonsec/attachments/20050314/d6cd8f97/signature.bin From touch at ISI.EDU Mon Mar 14 22:09:12 2005 From: touch at ISI.EDU (Joe Touch) Date: Mon, 14 Mar 2005 22:09:12 -0800 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: <20050315002247.5FD2F284D1@sierra.rtfm.com> References: <20050315002247.5FD2F284D1@sierra.rtfm.com> Message-ID: <42367C08.3070904@isi.edu> Eric Rescorla wrote: > Joe Touch wrote: > >>It's not a minute, but it is a few different handshakes. It happens >>all the time - IPv4 vs. IPv6, http vs. https, etc. Some apps do >>implement this 'try if available, and if not try the other'. > > Well, I don't even have an IPv6 address, so I'd be pretty > surprised if my apps attempted IPv6 before IPv4. And if > turning on IPv6 created this behavior, I would most > certainly immediately turn it back off again. If you use DNS, it's entirely possible that the app is checking v6 then v4, in that order, or in parallel. This issue was discussed in DC in TCPM. > As for HTTPS, browsers are guided by the protocol in the URL. > They don't fall back to HTTP if HTTPS fails. They just throw an > error. They also don't try HTTPS before HTTP if provided with an > HTTP URL. Redirection is how the app is guided into switching or falling back on protocols. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/anonsec/attachments/20050314/29f2b0a1/signature.bin From ekr at rtfm.com Mon Mar 14 22:27:26 2005 From: ekr at rtfm.com (Eric Rescorla) Date: Mon, 14 Mar 2005 22:27:26 -0800 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: Your message of "Mon, 14 Mar 2005 22:09:12 PST." <42367C08.3070904@isi.edu> Message-ID: <20050315064621.363AA284BE@sierra.rtfm.com> Joe Touch wrote: > Eric Rescorla wrote: > > Joe Touch wrote: > > > >>It's not a minute, but it is a few different handshakes. It happens > >>all the time - IPv4 vs. IPv6, http vs. https, etc. Some apps do > >>implement this 'try if available, and if not try the other'. > > Well, I don't even have an IPv6 address, so I'd be pretty > > surprised if my apps attempted IPv6 before IPv4. And if > > turning on IPv6 created this behavior, I would most > > certainly immediately turn it back off again. > > If you use DNS, it's entirely possible that the app is checking v6 > then v4, in that order, or in parallel. This issue was discussed in DC > in TCPM. Checking DNS in parallel isn't the same as trying to connect to a host which may be blocking your packets. DNS gives results (or a NXDOMAIN) in a semi-deterministic time frame. You don't have to wait for some timeout on v6 to try v4--at least not if things are configured correctly. > > As for HTTPS, browsers are guided by the protocol in the URL. > > They don't fall back to HTTP if HTTPS fails. They just throw an > > error. They also don't try HTTPS before HTTP if provided with an > > HTTP URL. > > Redirection is how the app is guided into switching or falling back on > protocols. Once again, redirection is semi-deterministic. You don't end up just waiting for 30-120 seconds because you tried HTTPS and the server doesn't support it. -Ekr From ekr at rtfm.com Mon Mar 14 22:29:12 2005 From: ekr at rtfm.com (Eric Rescorla) Date: Mon, 14 Mar 2005 22:29:12 -0800 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: Your message of "Mon, 14 Mar 2005 22:08:00 PST." <42367BC0.3020704@isi.edu> Message-ID: <20050315064806.EC3F6284BE@sierra.rtfm.com> Joe Touch wrote: > Eric Rescorla wrote: > > Joe Touch wrote: > > > >>If you don't care about out-of-band identity, then you MIGHT allow > >>cleartext, though. I can see the BTNS then cleartext variant being > >>useful, e.g., for a webserver (which could throttle non-BTNS > >>connections if under heavy load, to avoid potential attackers). > > I would think more importantly for clients.... However, I don't > > see how that can work if it creates an enormous performance hit. > > -Ekr > > The 'heavy load' referred to would be from a perceived attack, not a > performance hit. Yes, I appreciate that. My point is that I don't believe that clients (or servers) will implement it if with high probability it results in very high communications latency. -Ekr From kivinen at iki.fi Tue Mar 15 00:25:56 2005 From: kivinen at iki.fi (Tero Kivinen) Date: Tue, 15 Mar 2005 10:25:56 +0200 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: <20050314163135.BB59C28507@sierra.rtfm.com> References: <20050314163135.BB59C28507@sierra.rtfm.com> Message-ID: <16950.39956.904362.809895@fireball.kivinen.iki.fi> Eric Rescorla writes: > The obvious approach is simply to do the traditional IPsec thing and > hold the initial packets until the IKE handshake has completed. However, > if the peer doesn't do IKE and has firewalled off that port, then you're > stuck waiting for the timeout. This really delays the initiation of the > connection. Other opportunustic etc encryption schemes have also acted upon ICMP port unreachables etc, i.e. we could hold packets until we get first packet back from the other end, if it is ICMP port etc unreachable then allow traffic in plain, but continue trying IKE connection until it times out (i.e. if this was faked ICMP packet we will notice it when the real IKE server responds, and we can then move back to using IPsec). If the first packet is IKE packet then we hold the traffic packets until the exchange is finished (succeeded, or timed out). In case the port is silently firewalled off, then user will wait for the (perhaps much shorter than normally) timeout, and then start sending packets in plain. Hopefully users then complain to the adminstrator that they are silently discarding the IKE packets so that adminstrator can fix their setup to send ICMPs which will make future connections failing faster. Of course we can also remember from the past connections if the other host talks IPsec, and adjust the timeouts accordingly (i.e. if it talked IPsec last time wait for full timeout, if it we timed out last time, use shorter timeouts etc). That will help if btns is used between same parties. -- kivinen at safenet-inc.com From touch at ISI.EDU Tue Mar 15 06:44:02 2005 From: touch at ISI.EDU (Joe Touch) Date: Tue, 15 Mar 2005 06:44:02 -0800 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: <20050315064621.363AA284BE@sierra.rtfm.com> References: <20050315064621.363AA284BE@sierra.rtfm.com> Message-ID: <4236F4B2.2030807@isi.edu> Overall, I see this whole issue of how to handle alternatives distracting and unnecessary. IMO, the primary utility of BTNS will be to enable it and require it for a set of addresses - via an SPD with a 'use BTNS' flag. I don't think IPsec needs to handle BTNS-flagged SPDs differently from other SPDs, nor do I think there is any new concern about security that doing this raises - notably, because the SPD could have said "pass", which is less secure than BTNS, and IPsec already needs to keep those streams separate. IPsec doesn't (AFAIK) have a "please key, but if you timeout, that's OK so just 'pass' traffic" mode; I don't see that as being uniquely useful to BTNS or requiring discussion at this point. Joe Eric Rescorla wrote: > Joe Touch wrote: > >>Eric Rescorla wrote: >> >>>Joe Touch wrote: >>> >>> >>>>It's not a minute, but it is a few different handshakes. It happens >>>>all the time - IPv4 vs. IPv6, http vs. https, etc. Some apps do >>>>implement this 'try if available, and if not try the other'. >>> >>>Well, I don't even have an IPv6 address, so I'd be pretty >>>surprised if my apps attempted IPv6 before IPv4. And if >>>turning on IPv6 created this behavior, I would most >>>certainly immediately turn it back off again. >> >>If you use DNS, it's entirely possible that the app is checking v6 >>then v4, in that order, or in parallel. This issue was discussed in DC >>in TCPM. > > > Checking DNS in parallel isn't the same as trying to connect to > a host which may be blocking your packets. DNS gives results > (or a NXDOMAIN) in a semi-deterministic time frame. You don't > have to wait for some timeout on v6 to try v4--at least not if > things are configured correctly. > > > >>>As for HTTPS, browsers are guided by the protocol in the URL. >>>They don't fall back to HTTP if HTTPS fails. They just throw an >>>error. They also don't try HTTPS before HTTP if provided with an >>>HTTP URL. >> >>Redirection is how the app is guided into switching or falling back on >>protocols. > > > Once again, redirection is semi-deterministic. You don't end up > just waiting for 30-120 seconds because you tried HTTPS and the > server doesn't support it. > > -Ekr > > _______________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/anonsec/attachments/20050315/01f0a57b/signature.bin From ekr at rtfm.com Tue Mar 15 07:14:22 2005 From: ekr at rtfm.com (Eric Rescorla) Date: Tue, 15 Mar 2005 07:14:22 -0800 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: Your message of "Tue, 15 Mar 2005 06:44:02 PST." <4236F4B2.2030807@isi.edu> Message-ID: <20050315153305.3EAFF2860F@sierra.rtfm.com> Joe Touch wrote: > Overall, I see this whole issue of how to handle alternatives > distracting and unnecessary. Obviously, I disagree. > IMO, the primary utility of BTNS will be to enable it and require it > for a set of addresses - via an SPD with a 'use BTNS' flag. I don't > think IPsec needs to handle BTNS-flagged SPDs differently from other > SPDs, nor do I think there is any new concern about security that > doing this raises - notably, because the SPD could have said "pass", > which is less secure than BTNS, and IPsec already needs to keep those > streams separate. > > IPsec doesn't (AFAIK) have a "please key, but if you timeout, that's > OK so just 'pass' traffic" mode; I don't see that as being uniquely > useful to BTNS or requiring discussion at this point. It's not a security concern, it's a performance and deployment concern. Let's talk big picture for a second. There are (at least) two ways that BTNS can be used: 1. Use BTNS or nothing. 2. Use BTNS or fall back to cleartext. Now, in case (1), you definitely can't turn on BTNS unless you absolutely know that the peer does BTNS, because otherwise you can't communicate. This means that you need to have a prior arrangement with the peer, at which point they could easily have provided a public key fingerprint, at which point you could do more or less standard IKE (replacing the cert check with a comparison to the fingerprint, which is easy to add and not really a wire protocol issue) and call it a day. So, I think BTNS mostly makes sense with a fallback to plaintext. But then what you want is for people to turn it on globally for all possible peers. This isn't going to work if people have to take a big performance hit for doing so. Do you have some different usage model where this makes sense? -Ekr From touch at ISI.EDU Tue Mar 15 07:33:00 2005 From: touch at ISI.EDU (Joe Touch) Date: Tue, 15 Mar 2005 07:33:00 -0800 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: <20050315153305.3EAFF2860F@sierra.rtfm.com> References: <20050315153305.3EAFF2860F@sierra.rtfm.com> Message-ID: <4237002C.3020409@isi.edu> Eric Rescorla wrote: > Joe Touch wrote: > >>Overall, I see this whole issue of how to handle alternatives >>distracting and unnecessary. > > > Obviously, I disagree. > > > >>IMO, the primary utility of BTNS will be to enable it and require it >>for a set of addresses - via an SPD with a 'use BTNS' flag. I don't >>think IPsec needs to handle BTNS-flagged SPDs differently from other >>SPDs, nor do I think there is any new concern about security that >>doing this raises - notably, because the SPD could have said "pass", >>which is less secure than BTNS, and IPsec already needs to keep those >>streams separate. >> >>IPsec doesn't (AFAIK) have a "please key, but if you timeout, that's >>OK so just 'pass' traffic" mode; I don't see that as being uniquely >>useful to BTNS or requiring discussion at this point. > > > It's not a security concern, it's a performance and deployment > concern. > > Let's talk big picture for a second. There are (at least) two ways > that BTNS can be used: > > 1. Use BTNS or nothing. > 2. Use BTNS or fall back to cleartext. > > Now, in case (1), you definitely can't turn on BTNS unless you > absolutely know that the peer does BTNS, because otherwise you > can't communicate. This means that you need to have a prior > arrangement with the peer, at which point they could easily > have provided a public key fingerprint, at which point you > could do more or less standard IKE (replacing the cert check > with a comparison to the fingerprint, which is easy to add > and not really a wire protocol issue) and call it a day. Consider the following: - give people two different URLs - one that triggers BTNS, one that does not (e.g., two different IP addresses) - let users pick, but give preferential treatment under heavy load to the BTNS address, because it is more protected from attack As to key distribution, the assertion that if I have BTNS then you and I have a key isn't true; many systems already have IPsec, but lack the key. That's the whole point of BTNS - to avoid needing per-pair prearrangement. If backoff is really required, we can try IKE with a new option; the option should be immediately declined as not supported, and this should not require a timeout. Timeout would occur only if the other end didn't even have IKE; that's no different from today. Fix that with IKE first, then let me know how BTNS is different. ;-) BTNS does not solve the "I don't even speak IKE" stuff; it solves the "I speak IKE, but don't have a preshared secret (key or pre-agreed CA).". > So, I think BTNS mostly makes sense with a fallback to plaintext. Fallback to plaintext != fallback to non-IPsec. That may indeed be useful, but can't be done without timeouts as you mention. BTNS doesn't solve the non-IPsec case, again. > But then what you want is for people to turn it on globally > for all possible peers. This isn't going to work if people > have to take a big performance hit for doing so. > > Do you have some different usage model where this makes sense? > > -Ekr > > > > > > > > > > > > _______________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/anonsec/attachments/20050315/ec192478/signature-0001.bin From ekr at rtfm.com Tue Mar 15 08:03:48 2005 From: ekr at rtfm.com (Eric Rescorla) Date: Tue, 15 Mar 2005 08:03:48 -0800 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: Your message of "Tue, 15 Mar 2005 07:33:00 PST." <4237002C.3020409@isi.edu> Message-ID: <20050315162230.B4C8A284C1@sierra.rtfm.com> Joe Touch wrote: > Eric Rescorla wrote: > > Joe Touch wrote: > > > >>Overall, I see this whole issue of how to handle alternatives > >>distracting and unnecessary. > > Obviously, I disagree. > > > >>IMO, the primary utility of BTNS will be to enable it and require it > >>for a set of addresses - via an SPD with a 'use BTNS' flag. I don't > >>think IPsec needs to handle BTNS-flagged SPDs differently from other > >>SPDs, nor do I think there is any new concern about security that > >>doing this raises - notably, because the SPD could have said "pass", > >>which is less secure than BTNS, and IPsec already needs to keep those > >>streams separate. > >> > >>IPsec doesn't (AFAIK) have a "please key, but if you timeout, that's > >>OK so just 'pass' traffic" mode; I don't see that as being uniquely > >>useful to BTNS or requiring discussion at this point. > > It's not a security concern, it's a performance and deployment > > concern. Let's talk big picture for a second. There are (at least) > > two ways > > that BTNS can be used: > > 1. Use BTNS or nothing. > > 2. Use BTNS or fall back to cleartext. > > Now, in case (1), you definitely can't turn on BTNS unless you > > absolutely know that the peer does BTNS, because otherwise you > > can't communicate. This means that you need to have a prior > > arrangement with the peer, at which point they could easily > > have provided a public key fingerprint, at which point you > > could do more or less standard IKE (replacing the cert check > > with a comparison to the fingerprint, which is easy to add > > and not really a wire protocol issue) and call it a day. > > Consider the following: > > - give people two different URLs - one that triggers BTNS, one that > does not (e.g., two different IP addresses) This is basically manual backoff. I don't really believe that people will do this. > - let users pick, but give preferential treatment under heavy load to > the BTNS address, because it is more protected from attack I hear this kind of proposal for preferential network load handling a lot, but I'm skeptical of its value. Modern DDoS attacks tend to be of the lots of packets variety. And since it's easy for an attacker to do BTNS anyway... > As to key distribution, the assertion that if I have BTNS then you and > I have a key isn't true; many systems already have IPsec, but lack the > key. That's the whole point of BTNS - to avoid needing per-pair > prearrangement. What I said was if I *knew* you had BTNS then we can arrange a fingerprint through the same channel through which I learned you had BTNS. > If backoff is really required, we can try IKE with a new option; the > option should be immediately declined as not supported, and this > should not require a timeout. Timeout would occur only if the other > end didn't even have IKE; that's no different from today. Fix that > with IKE first, then let me know how BTNS is different. ;-) The situations aren't the same, because with IKE now you never want to fallback to non-IPsec. However, with BTNS, you might want to and that's how the problem arises. > BTNS does not solve the "I don't even speak IKE" stuff; it solves the > "I speak IKE, but don't have a preshared secret (key or pre-agreed > CA).". > > > So, I think BTNS mostly makes sense with a fallback to plaintext. > > Fallback to plaintext != fallback to non-IPsec. That may indeed be > useful, but can't be done without timeouts as you mention. BTNS > doesn't solve the non-IPsec case, again. Hmm.... I'd imagined it was intended to. If it doesn't, it strikes me as far less useful. -Ekr From ekr at rtfm.com Tue Mar 15 08:17:11 2005 From: ekr at rtfm.com (Eric Rescorla) Date: Tue, 15 Mar 2005 08:17:11 -0800 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: Your message of "Tue, 15 Mar 2005 08:03:48 PST." <20050315162230.B4C8A284C1@sierra.rtfm.com> Message-ID: <20050315163553.78DA3284C1@sierra.rtfm.com> Eric Rescorla wrote: > > As to key distribution, the assertion that if I have BTNS then you and > > I have a key isn't true; many systems already have IPsec, but lack the > > key. That's the whole point of BTNS - to avoid needing per-pair > > prearrangement. > > What I said was if I *knew* you had BTNS then we can arrange a > fingerprint through the same channel through which I learned you > had BTNS. To be specific, what I meant was that whatever tool you use to set the new SPD entry can easily fetch the peer's certificate and write a digest to the SPD, thus removing the need for modifications to IPsec. -Ekr From touch at ISI.EDU Tue Mar 15 08:21:07 2005 From: touch at ISI.EDU (Joe Touch) Date: Tue, 15 Mar 2005 08:21:07 -0800 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: <20050315163553.78DA3284C1@sierra.rtfm.com> References: <20050315163553.78DA3284C1@sierra.rtfm.com> Message-ID: <42370B73.8010305@isi.edu> Eric Rescorla wrote: > Eric Rescorla wrote: > >>>As to key distribution, the assertion that if I have BTNS then you and >>>I have a key isn't true; many systems already have IPsec, but lack the >>>key. That's the whole point of BTNS - to avoid needing per-pair >>>prearrangement. >> >>What I said was if I *knew* you had BTNS then we can arrange a >>fingerprint through the same channel through which I learned you >>had BTNS. > > > To be specific, what I meant was that whatever tool you use > to set the new SPD entry can easily fetch the peer's certificate > and write a digest to the SPD, thus removing the need for > modifications to IPsec. > > -Ekr How do you fetch the certificate for the SPD 10.*.*.* ? Besides, even if it were for a single address, why fetch a certificate you don't care to check? (again, that misses the point of BTNS). Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/anonsec/attachments/20050315/c836839b/signature.bin From touch at ISI.EDU Tue Mar 15 08:32:49 2005 From: touch at ISI.EDU (Joe Touch) Date: Tue, 15 Mar 2005 08:32:49 -0800 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: <20050315162230.B4C8A284C1@sierra.rtfm.com> References: <20050315162230.B4C8A284C1@sierra.rtfm.com> Message-ID: <42370E31.2070508@isi.edu> Eric Rescorla wrote: > Joe Touch wrote: > >>Eric Rescorla wrote: ... >>Consider the following: >> >>- give people two different URLs - one that triggers BTNS, one that >>does not (e.g., two different IP addresses) > > This is basically manual backoff. I don't really believe that > people will do this. Beliefs about what people will or will not do got us here - with forced keys, whether preshared, the shared CA, or shared in a database (e.g. DNS). Let's try this as a different path, and find out what people really do rather than speculating again. ;-) >>- let users pick, but give preferential treatment under heavy load to >>the BTNS address, because it is more protected from attack > > I hear this kind of proposal for preferential network load > handling a lot, but I'm skeptical of its value. Modern DDoS > attacks tend to be of the lots of packets variety. And since > it's easy for an attacker to do BTNS anyway... Again, this misses the point of BTNS. Anybody who does enough work to setup an association is indistinguishable from a legitimate user, and deserves to be treated as such. There is a lot of work throughout the IETF aimed at dealing with modern DDOS attacks that attack specific connections, not just flooding the whole net with packets. We saw this with TCP SYN attacks, we see it with RST attacks, etc. This is not conjecture. The 'lots of packets' attack needs to be vetted somehow anyway - IPsec is supposed to handle those too, and if it doesn't, there's little hope of any alternative handling it better. >>As to key distribution, the assertion that if I have BTNS then you and >>I have a key isn't true; many systems already have IPsec, but lack the >>key. That's the whole point of BTNS - to avoid needing per-pair >>prearrangement. > > What I said was if I *knew* you had BTNS then we can arrange a > fingerprint through the same channel through which I learned you > had BTNS. What makes you think you a) know I have BTNS? by the time you do, we should already be knee-deep in DH exchange, IMO b) should bother with an exchange whose result shouldn't be relevant? if you start to talk with an endpoint that early, why not proactively setup the SA, rather than getting CAs you are going to ignore? >>If backoff is really required, we can try IKE with a new option; the >>option should be immediately declined as not supported, and this >>should not require a timeout. Timeout would occur only if the other >>end didn't even have IKE; that's no different from today. Fix that >>with IKE first, then let me know how BTNS is different. ;-) > > The situations aren't the same, because with IKE now you never > want to fallback to non-IPsec. Not necessarily; you could want to lock things down where you can but still provide open access to less detailed info where you can't. > However, with BTNS, you might want > to and that's how the problem arises. As above, I don't agree that it arises here. First, there's sufficient (IMO primary) utility in the non-backoff case. Second, the backoff case is no different from IPsec backoff to cleartext. There's nothing BTNS-specific about this. >>BTNS does not solve the "I don't even speak IKE" stuff; it solves the >>"I speak IKE, but don't have a preshared secret (key or pre-agreed >>CA).". >> >> >>>So, I think BTNS mostly makes sense with a fallback to plaintext. >> >>Fallback to plaintext != fallback to non-IPsec. That may indeed be >>useful, but can't be done without timeouts as you mention. BTNS >>doesn't solve the non-IPsec case, again. > > Hmm.... I'd imagined it was intended to. If it doesn't, it strikes > me as far less useful. Not me. BTNS isn't a replacement for IPsec; it's a replacement for needing preshared keys or CAs in IPsec (as well as the correlary need in other protocols, eventually, but that's my overall vision, not this WG). The problem of fallback on systems that lack any pre-deployed protocol to explicitly negotiate security is one of telepathy. Timeouts are the only solution, and have known problems. If you solve that problem, let us know, but otherwise I think it's out of scope because it's not remotely new. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/anonsec/attachments/20050315/703a0a1d/signature.bin From ekr at rtfm.com Tue Mar 15 08:40:41 2005 From: ekr at rtfm.com (Eric Rescorla) Date: Tue, 15 Mar 2005 08:40:41 -0800 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: Your message of "Tue, 15 Mar 2005 08:21:07 PST." <42370B73.8010305@isi.edu> Message-ID: <20050315165923.3B2F828579@sierra.rtfm.com> Joe Touch wrote: > Eric Rescorla wrote: > > Eric Rescorla wrote: > > > >>>As to key distribution, the assertion that if I have BTNS then you and > >>>I have a key isn't true; many systems already have IPsec, but lack the > >>>key. That's the whole point of BTNS - to avoid needing per-pair > >>>prearrangement. > >> > >> What I said was if I *knew* you had BTNS then we can arrange a > >> fingerprint through the same channel through which I learned you > >>had BTNS. > > To be specific, what I meant was that whatever tool you use > > to set the new SPD entry can easily fetch the peer's certificate > > and write a digest to the SPD, thus removing the need for > > modifications to IPsec. > > -Ekr > > How do you fetch the certificate for the SPD 10.*.*.* ? > > Besides, even if it were for a single address, why fetch a certificate > you don't care to check? (again, that misses the point of BTNS). Because I'm trying to figure out how to do this without writing new RFCs, of course? -Ekr From ekr at rtfm.com Tue Mar 15 08:50:10 2005 From: ekr at rtfm.com (Eric Rescorla) Date: Tue, 15 Mar 2005 08:50:10 -0800 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: Your message of "Tue, 15 Mar 2005 08:32:49 PST." <42370E31.2070508@isi.edu> Message-ID: <20050315170852.D578028572@sierra.rtfm.com> Joe Touch wrote: > Eric Rescorla wrote: > >>- let users pick, but give preferential treatment under heavy load to > >>the BTNS address, because it is more protected from attack > > I hear this kind of proposal for preferential network load handling > > a lot, but I'm skeptical of its value. Modern DDoS attacks tend to > > be of the lots of packets variety. And since > > it's easy for an attacker to do BTNS anyway... > > Again, this misses the point of BTNS. Anybody who does enough work to > setup an association is indistinguishable from a legitimate user, and > deserves to be treated as such. This basically buys you zilch aainst zombies, which are the current major threeat. > There is a lot of work throughout the IETF aimed at dealing with > modern DDOS attacks that attack specific connections, not just > flooding the whole net with packets. We saw this with TCP SYN attacks, > we see it with RST attacks, etc. This is not conjecture. Actually, the data suggests that modern attacks are lots of packets attacks, NOT targeted clever TCP-based stuff. See http://www.monkey.org/~jose/presentations/ddos.d/ > >>As to key distribution, the assertion that if I have BTNS then you and > >>I have a key isn't true; many systems already have IPsec, but lack the > >>key. That's the whole point of BTNS - to avoid needing per-pair > >>prearrangement. > > What I said was if I *knew* you had BTNS then we can arrange a > > fingerprint through the same channel through which I learned you > > had BTNS. > > What makes you think you > a) know I have BTNS? > > by the time you do, we should already be knee-deep > in DH exchange, IMO Sorry, I should have said "know you have IKE". Once again, the concern is waiting for a connction to someone who ahs no IKE capability. > The problem of fallback on systems that lack any pre-deployed protocol > to explicitly negotiate security is one of telepathy. Timeouts are the > only solution, and have known problems. If you solve that problem, let > us know, but otherwise I think it's out of scope because it's not > remotely new. Well, the question at hand is whether BTNS is actually useful if it requires people to time out constantly. The fact that I don't have a useful solution to the problem doesn't make it go away. That said, it seems to me that you've dismissed the "start transmitting in the clear and then switch over if/when you get an association" strategy rather too quickly. -Ekr From Nicolas.Williams at sun.com Tue Mar 15 08:53:50 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 15 Mar 2005 10:53:50 -0600 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: <20050315170852.D578028572@sierra.rtfm.com> References: <42370E31.2070508@isi.edu> <20050315170852.D578028572@sierra.rtfm.com> Message-ID: <20050315165350.GB1007@binky.Central.Sun.COM> On Tue, Mar 15, 2005 at 08:50:10AM -0800, Eric Rescorla wrote: > Well, the question at hand is whether BTNS is actually useful > if it requires people to time out constantly. The fact that I > don't have a useful solution to the problem doesn't make it > go away. For the use case that Joe cares about (protecting routers against RST attacks on their BGP TCP connections) BTNS is useful and timeouts won't be an issue. > That said, it seems to me that you've dismissed the "start > transmitting in the clear and then switch over if/when you get > an association" strategy rather too quickly. In the router case it should be easy enough to get BTNS to just work that you might not ever care about fallback modes. More generally you might care about fallbacks, but then you get into the mobility issues I pointed out before -- as a result BTNS w/ BITS mode IPsec is limited, pretty much, to use cases like Joe's. Nico -- From Julien.Laganier at Sun.COM Tue Mar 15 09:48:15 2005 From: Julien.Laganier at Sun.COM (Julien Laganier) Date: Tue, 15 Mar 2005 18:48:15 +0100 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: <20050315170852.D578028572@sierra.rtfm.com> References: <20050315170852.D578028572@sierra.rtfm.com> Message-ID: <200503151848.15803.julien.laganier@sun.com> On Tuesday 15 March 2005 17:50, Eric Rescorla wrote: > Well, the question at hand is whether BTNS is actually useful > if it requires people to time out constantly. The fact that I > don't have a useful solution to the problem doesn't make it > go away. This looks similar to me to the experience of an user using remote login: One might first try to use SSH, and if it gets an ICMP port unreachable, would switch to Telnet, for example. Now if the remote box doesn't send such ICMPs, the user will have to Timeout. This has happened quite a lot to me. I don't see how BTNS is different w.r.t to this behavior. If the remote box is correctly configured it should send ICMP port btns unreachable, so no timeouts. If it's not properly configured, then... what can we do better? > That said, it seems to me that you've dismissed the "start > transmitting in the clear and then switch over if/when you get > an association" strategy rather too quickly. An SPD entry in KAME IPsec might have this feature enabled (via the 'use' flag instead of 'require' flag). The traffic pass in clear until an IPsec association is possibly established. --julien From touch at ISI.EDU Tue Mar 15 10:58:33 2005 From: touch at ISI.EDU (Joe Touch) Date: Tue, 15 Mar 2005 10:58:33 -0800 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: <20050315165923.3B2F828579@sierra.rtfm.com> References: <20050315165923.3B2F828579@sierra.rtfm.com> Message-ID: <42373059.5030309@isi.edu> Eric Rescorla wrote: > Joe Touch wrote: > >>Eric Rescorla wrote: >> >>>Eric Rescorla wrote: >>> >>> >>>>>As to key distribution, the assertion that if I have BTNS then you and >>>>>I have a key isn't true; many systems already have IPsec, but lack the >>>>>key. That's the whole point of BTNS - to avoid needing per-pair >>>>>prearrangement. >>>> >>>>What I said was if I *knew* you had BTNS then we can arrange a >>>>fingerprint through the same channel through which I learned you >>>>had BTNS. >>> >>>To be specific, what I meant was that whatever tool you use >>>to set the new SPD entry can easily fetch the peer's certificate >>>and write a digest to the SPD, thus removing the need for >>>modifications to IPsec. >>>-Ekr >> >>How do you fetch the certificate for the SPD 10.*.*.* ? >> >>Besides, even if it were for a single address, why fetch a certificate >>you don't care to check? (again, that misses the point of BTNS). > > > Because I'm trying to figure out how to do this without writing > new RFCs, of course? You haven't said why you want to fetch certificates you don't want to check. If you want to check certificates, that may indeed require new RFCs, but that's not BTNS. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/anonsec/attachments/20050315/f539d27e/signature-0001.bin From touch at ISI.EDU Tue Mar 15 11:04:30 2005 From: touch at ISI.EDU (Joe Touch) Date: Tue, 15 Mar 2005 11:04:30 -0800 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: <20050315170852.D578028572@sierra.rtfm.com> References: <20050315170852.D578028572@sierra.rtfm.com> Message-ID: <423731BE.70708@isi.edu> Eric Rescorla wrote: > Joe Touch wrote: > >>Eric Rescorla wrote: >> >>>>- let users pick, but give preferential treatment under heavy load to >>>>the BTNS address, because it is more protected from attack >>> >>>I hear this kind of proposal for preferential network load handling >>>a lot, but I'm skeptical of its value. Modern DDoS attacks tend to >>>be of the lots of packets variety. And since >>>it's easy for an attacker to do BTNS anyway... >> >>Again, this misses the point of BTNS. Anybody who does enough work to >>setup an association is indistinguishable from a legitimate user, and >>deserves to be treated as such. > > > This basically buys you zilch aainst zombies, which are the current > major threeat. Zombies that do full connections, agreed. That's NOT the threat people are discussing throughout the IETF right now, the one that gave rise to _this_ BOF/WG. Note that zombies might even have signed certificates - just that they've been compromised. So no defense is valid against them, since they are isomorphic to legitimate users. If you come up with a way to fix that, let us all know. In another WG, because that's outside the scope of this WG. >>There is a lot of work throughout the IETF aimed at dealing with >>modern DDOS attacks that attack specific connections, not just >>flooding the whole net with packets. We saw this with TCP SYN attacks, >>we see it with RST attacks, etc. This is not conjecture. > > Actually, the data suggests that modern attacks are lots of packets > attacks, NOT targeted clever TCP-based stuff. See > > http://www.monkey.org/~jose/presentations/ddos.d/ If you want to argue that there are other solutions needed, please do so in another WG/BOF. Lots-of-packets attacks hit IPsec, BTNS-IPsec, SSH, and everything else. Again, if you come up with a way to fix that, please let us all know - in another WG. >>>>As to key distribution, the assertion that if I have BTNS then you and >>>>I have a key isn't true; many systems already have IPsec, but lack the >>>>key. That's the whole point of BTNS - to avoid needing per-pair >>>>prearrangement. >>> >>>What I said was if I *knew* you had BTNS then we can arrange a >>>fingerprint through the same channel through which I learned you >>>had BTNS. >> >>What makes you think you >> a) know I have BTNS? >> >> by the time you do, we should already be knee-deep >> in DH exchange, IMO > > Sorry, I should have said "know you have IKE". Once again, > the concern is waiting for a connction to someone who ahs > no IKE capability. Again (arrgh), if you come up with a way to solve avoiding a timeout for IKE vs. non-IKE, let us know (in another WG). That's outside the scope of BTNS, and has nothing to do with BTNS. >>The problem of fallback on systems that lack any pre-deployed protocol >>to explicitly negotiate security is one of telepathy. Timeouts are the >>only solution, and have known problems. If you solve that problem, let >>us know, but otherwise I think it's out of scope because it's not >>remotely new. > > Well, the question at hand is whether BTNS is actually useful > if it requires people to time out constantly. You're still assuming that it's not useful unless there's a fallback to cleartext; I am not. > The fact that I > don't have a useful solution to the problem doesn't make it > go away. It also doesn't make it a problem for this WG ;-) > That said, it seems to me that you've dismissed the "start > transmitting in the clear and then switch over if/when you get > an association" strategy rather too quickly. > > -Ekr Too quickly for you, but not too quickly for me. I don't consider that a viable alternative at all. If anhyone else does, we can talk about it, but I haven't heard a groundswell in favor, nor have I heard a convincing argument as to why it's critical to getting BTNS out the door or used. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/anonsec/attachments/20050315/0bc3bd47/signature.bin From ekr at rtfm.com Tue Mar 15 13:28:22 2005 From: ekr at rtfm.com (Eric Rescorla) Date: Tue, 15 Mar 2005 13:28:22 -0800 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: Your message of "Tue, 15 Mar 2005 11:04:30 PST." <423731BE.70708@isi.edu> Message-ID: <20050315214704.98BD628493@sierra.rtfm.com> Joe Touch wrote: > Eric Rescorla wrote: > > Joe Touch wrote: > >>Eric Rescorla wrote: > >>Again, this misses the point of BTNS. Anybody who does enough work to > >>setup an association is indistinguishable from a legitimate user, and > >>deserves to be treated as such. > > This basically buys you zilch aainst zombies, which are the current > > major threeat. > > Zombies that do full connections, agreed. That's NOT the threat people > are discussing throughout the IETF right now, the one that gave rise > to _this_ BOF/WG. > > Note that zombies might even have signed certificates - just that > they've been compromised. So no defense is valid against them, since > they are isomorphic to legitimate users. > > If you come up with a way to fix that, let us all know. In another WG, > because that's outside the scope of this WG. Is this even a WG at all yet? I thought the question on the table was whether the piece of work you propose to do was worth actually doing, a context in which the issues I'm raising are quite relevant. > for IKE vs. non-IKE, let us know (in another WG). That's outside the > scope of BTNS, and has nothing to do with BTNS. Once again, the fact that BTNS brings up the issue of falling back to cleartext is what makes this an issue here. > > That said, it seems to me that you've dismissed the "start > > transmitting in the clear and then switch over if/when you get > > an association" strategy rather too quickly. > > Too quickly for you, but not too quickly for me. I don't consider that > a viable alternative at all. Oh, well than that totally settles it, I guess... Do you have an actual argument to make here? -Ekr From touch at ISI.EDU Tue Mar 15 13:44:49 2005 From: touch at ISI.EDU (Joe Touch) Date: Tue, 15 Mar 2005 13:44:49 -0800 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: <20050315214704.98BD628493@sierra.rtfm.com> References: <20050315214704.98BD628493@sierra.rtfm.com> Message-ID: <42375751.4000601@isi.edu> Eric Rescorla wrote: ... >>Note that zombies might even have signed certificates - just that >>they've been compromised. So no defense is valid against them, since >>they are isomorphic to legitimate users. >> >>If you come up with a way to fix that, let us all know. In another WG, >>because that's outside the scope of this WG. > > Is this even a WG at all yet? I thought the question on the table > was whether the piece of work you propose to do was worth actually > doing, a context in which the issues I'm raising are quite relevant. That vote was decided last IETF, and the rest is in the hands of the IESG; the question is one of scope so far, and I believe this issue is outside of scope. Others can voice their position. >>for IKE vs. non-IKE, let us know (in another WG). That's outside the >>scope of BTNS, and has nothing to do with BTNS. > > Once again, the fact that BTNS brings up the issue of falling back > to cleartext is what makes this an issue here. I disagree; I don't think BTNS brings up the issue of cleartext fallback per se. >>>That said, it seems to me that you've dismissed the "start >>>transmitting in the clear and then switch over if/when you get >>>an association" strategy rather too quickly. >> >>Too quickly for you, but not too quickly for me. I don't consider that >>a viable alternative at all. > > Oh, well than that totally settles it, I guess... > > Do you have an actual argument to make here? I've made it multiple times in more detail; you disagree. We know where we both stand; let's hear from others. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/anonsec/attachments/20050315/da28bf3f/signature.bin From ekr at rtfm.com Tue Mar 15 13:58:00 2005 From: ekr at rtfm.com (Eric Rescorla) Date: Tue, 15 Mar 2005 13:58:00 -0800 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: Your message of "Tue, 15 Mar 2005 13:44:49 PST." <42375751.4000601@isi.edu> Message-ID: <20050315221643.493572851F@sierra.rtfm.com> Joe Touch wrote: > Eric Rescorla wrote: > ... > >>Note that zombies might even have signed certificates - just that > >>they've been compromised. So no defense is valid against them, since > >>they are isomorphic to legitimate users. > >> > >>If you come up with a way to fix that, let us all know. In another WG, > >>because that's outside the scope of this WG. > > Is this even a WG at all yet? I thought the question on the table > > was whether the piece of work you propose to do was worth actually > > doing, a context in which the issues I'm raising are quite relevant. > > That vote was decided last IETF, and the rest is in the hands of the > IESG; the question is one of scope so far, and I believe this issue is > outside of scope. Others can voice their position. Which is what I'm doing... > I've made it multiple times in more detail; you disagree. We know > where we both stand; let's hear from others. Works for me. -Ekr From paul.hoffman at vpnc.org Tue Mar 15 14:00:12 2005 From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Tue, 15 Mar 2005 14:00:12 -0800 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: <20050315170852.D578028572@sierra.rtfm.com> References: <20050315170852.D578028572@sierra.rtfm.com> Message-ID: At 8:50 AM -0800 3/15/05, Eric Rescorla wrote: >This basically buys you zilch aainst zombies, which are the current >major threeat. Are you suggesting that prevention of attack by zombies be put in the charter? If so, why should that be in BTNS' charter but no one else's? >Sorry, I should have said "know you have IKE". Once again, >the concern is waiting for a connction to someone who ahs >no IKE capability. This line of argument is quite similar to the "foo-over-SSL on a different port vs. SSL upgrade such as STARTTLS". The result is quite similar: if the initiator has a policy to try BTNS, they need to have a fallback if IKE fails to give them what they want, and another policy if IKE doesn't even start up in a reasonable time. >Well, the question at hand is whether BTNS is actually useful >if it requires people to time out constantly. Nothing said so far "requires people to time out constantly". BTNS is an optional service. It would be reasonable of an implementer to put something in their code that says "if I timed out the last time I tried to get security with BTNS, don't try this time". It would be even smarter to retry BTNS at other times to see if there is now a working BTNS service. >That said, it seems to me that you've dismissed the "start >transmitting in the clear and then switch over if/when you get >an association" strategy rather too quickly. Agree. This option could be discussed in the protocol document. --Paul Hoffman, Director --VPN Consortium From Nicolas.Williams at sun.com Tue Mar 15 14:05:35 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 15 Mar 2005 16:05:35 -0600 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: References: <20050315170852.D578028572@sierra.rtfm.com> Message-ID: <20050315220535.GT1007@binky.Central.Sun.COM> On Tue, Mar 15, 2005 at 02:00:12PM -0800, Paul Hoffman wrote: > At 8:50 AM -0800 3/15/05, Eric Rescorla wrote: > >That said, it seems to me that you've dismissed the "start > >transmitting in the clear and then switch over if/when you get > >an association" strategy rather too quickly. > > Agree. This option could be discussed in the protocol document. Emphasis on "optional." From sommerfeld at sun.com Tue Mar 15 14:16:10 2005 From: sommerfeld at sun.com (Bill Sommerfeld) Date: Tue, 15 Mar 2005 17:16:10 -0500 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: <42375751.4000601@isi.edu> References: <20050315214704.98BD628493@sierra.rtfm.com> <42375751.4000601@isi.edu> Message-ID: <1110924969.6760.218.camel@thunk> On Tue, 2005-03-15 at 16:44, Joe Touch wrote: > I've made it multiple times in more detail; you disagree. We know where > we both stand; let's hear from others. As an implementor I can do things either way. Joe's approach is slightly easier. What Joe asks for could be done via a per-socket bit, either from the SPD or from the application saying (via a socket option or moral equivalent) that BTNS was requested/required. A "this is for BTNS" vs "this requires conventional IKE authentication" bit could be reflected to key management via a new PF_KEY extension. The existence of SPD/PAD entries calling for conventional IPsec/IKE authentication would, of course, trump/subsume this application request. From Nicolas.Williams at sun.com Tue Mar 15 14:20:28 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 15 Mar 2005 16:20:28 -0600 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: <1110924969.6760.218.camel@thunk> References: <20050315214704.98BD628493@sierra.rtfm.com> <42375751.4000601@isi.edu> <1110924969.6760.218.camel@thunk> Message-ID: <20050315222028.GX1007@binky.Central.Sun.COM> On Tue, Mar 15, 2005 at 05:16:10PM -0500, Bill Sommerfeld wrote: > On Tue, 2005-03-15 at 16:44, Joe Touch wrote: > > I've made it multiple times in more detail; you disagree. We know where > > we both stand; let's hear from others. > > As an implementor I can do things either way. Joe's approach is > slightly > easier. > > What Joe asks for could be done via a per-socket bit, either from the > SPD > or from the application saying (via a socket option or moral equivalent) > that BTNS was requested/required. > > A "this is for BTNS" vs "this requires conventional IKE authentication" > bit could be reflected to key management via a new PF_KEY extension. > > The existence of SPD/PAD entries calling for conventional IPsec/IKE > authentication would, of course, trump/subsume this application request. What Bill said. Note that Bill mentions APIs... :) Nico -- From Black_David at emc.com Tue Mar 15 17:14:08 2005 From: Black_David at emc.com (Black_David@emc.com) Date: Tue, 15 Mar 2005 20:14:08 -0500 Subject: [anonsec] BTNS and fetching fingerprints/certs Message-ID: Subject change to focus on the core of Ekr's argument: > Let's talk big picture for a second. There are (at least) two > ways that BTNS can be used: > > 1. Use BTNS or nothing. > 2. Use BTNS or fall back to cleartext. > > Now, in case (1), you definitely can't turn on BTNS unless you > absolutely know that the peer does BTNS, because otherwise you > can't communicate. This means that you need to have a prior > arrangement with the peer, at which point they could easily > have provided a public key fingerprint, at which point you > could do more or less standard IKE (replacing the cert check > with a comparison to the fingerprint, which is easy to add > and not really a wire protocol issue) and call it a day. I believe this was later clarified that "know the peer does BTNS" specifically meant "know the peer supports IKE". I'm definitely interested in case (1) and have a counterexample to Ekr's "could easily" assertion ... ... Suppose that the "prior arrangement with the peer" is "sneaker-net", so any fingerprint, shared secret, etc. gets transported by hand (don't laugh, it's not that unrealistic). By the time one gets up to adding the 20th host with full n x n connectivity, there are 38 items that have to be transported - 19 to the new host, and one to each of the host's 19 peers - and this has exceeded any reasonable scope of "easily" ... The reason this matters is administrative/management overhead. I'm interested in BTNS for channel binding use cases where there are already good sets of identities and authentication credentials in a higher layer protocol. Any notion of identity at the IPsec level that requires any management/administrative attention just gets in the way in this case, even if something better than "sneaker-net" is available. The security policy will be simple/compact - Joe's 10.*.*.* is far more likely than an SPD entry per peer because the former requires no changes to add or remove a host. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david at emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From yogesh.swami at acm.org Wed Mar 16 08:56:50 2005 From: yogesh.swami at acm.org (Yogesh Prem Swami) Date: Wed, 16 Mar 2005 08:56:50 -0800 (PST) Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: 6667 Message-ID: <20050316165650.41575.qmail@web81210.mail.yahoo.com> --- Paul Hoffman wrote: > At 8:50 AM -0800 3/15/05, Eric Rescorla wrote: > >This basically buys you zilch aainst zombies, which are the current > >major threeat. > > Are you suggesting that prevention of attack by zombies be put in the > charter? If so, why should that be in BTNS' charter but no one else's? > While I don't think the charter should contain solution for Zombies, I do think that BTNS should provide what it promises: "Better than no security." If having BTNS means easier ways to do zombie DoS attacks (and I guess Joe and I have discussed this before on the TCPM mailing list), then, in my opinion BTNS is not better than no security, (it's only trading one form of DoS attacks with another form, like moving back door lock to front door). And yes, you can do zombie attacks using 3rd party certs too, but the degree and ease of attacks are different. DoS ultimately is about degree, isn't it? If BTNS becomes a wg, It would be nice to at least produce an informational document/conference-paper which does a through analysis of different trade-offs involved. Yogesh -- http://people.nokia.net/~yogesh From Nicolas.Williams at sun.com Wed Mar 16 09:03:55 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 16 Mar 2005 11:03:55 -0600 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: <20050316165650.41575.qmail@web81210.mail.yahoo.com> References: <20050316165650.41575.qmail@web81210.mail.yahoo.com> Message-ID: <20050316170355.GQ1007@binky.Central.Sun.COM> On Wed, Mar 16, 2005 at 08:56:50AM -0800, Yogesh Prem Swami wrote: > --- Paul Hoffman wrote: > > At 8:50 AM -0800 3/15/05, Eric Rescorla wrote: > > >This basically buys you zilch aainst zombies, which are the current > > >major threeat. > > > > Are you suggesting that prevention of attack by zombies be put in the > > charter? If so, why should that be in BTNS' charter but no one else's? > > > > While I don't think the charter should contain solution for Zombies, I do think > that BTNS should provide what it promises: "Better than no security." If having > BTNS means easier ways to do zombie DoS attacks (and I guess Joe and I have > discussed this before on the TCPM mailing list), then, in my opinion BTNS is > not better than no security, (it's only trading one form of DoS attacks with > another form, like moving back door lock to front door). And yes, you can do > zombie attacks using 3rd party certs too, but the degree and ease of attacks > are different. DoS ultimately is about degree, isn't it? Noone has argued that BTNS makes zombie DoS/DDoS attacks easier, nor do I see how it would. As to what is meant by "better than no security:" better than just sending and accepting unauthenticated plaintext. So should BTNS' charter say anything about zombie DoS protection? I don't think so, at least not until we figure out that BTNS has something to offer there. Nico -- From yogesh.swami at acm.org Wed Mar 16 09:29:02 2005 From: yogesh.swami at acm.org (Yogesh Prem Swami) Date: Wed, 16 Mar 2005 09:29:02 -0800 (PST) Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: 6667 Message-ID: <20050316172902.85019.qmail@web81203.mail.yahoo.com> Oops! sent too quickly by mistake. >> Noone has argued that BTNS makes zombie DoS/DDoS attacks easier, nor do >> I see how it would. >> > Consider this: A security gagateway accepts self signed certs. Let's say A and > B > are communicating with each other normally. Now a rogue node Malice wants to > disrupt this connection. To do this Malice established a secure channel using > self signed cert, and A accepts it. After the secure channel is established, > malice puts a couple of IPIPn IPIPackets inside the IPIPsecacket and > ultimately > a TCP RSRSTackets with the right atattributesf B. This is shown in figure > below: > A<--------------------------->B | | IPIPn-IPIPn-IPIPn-IPIPnd TCP of B +---------------------------> Malice You can solve this by looking inside the IP in IP headers (but that could lead to other kind of DoS attacks where you keep parsing IPeaders for no reason). I don't recall if RFC2401 and 2402 bis, mention checking inner tunnels for inbound processing. Of course, all this could be solved if you change IPsec that is not an option, right? Yogesh >> As to what is meant by "better than no security:" better than just >> sending and accepting unauthenticated plaintext. >> >> So should BTNS' charter say anything about zombie DoS protection? I >> don't think so, at least not until we figure out that BTNS has something >> to offer there. >> >> Nico >> -- From yogesh.swami at acm.org Wed Mar 16 09:45:18 2005 From: yogesh.swami at acm.org (Yogesh Prem Swami) Date: Wed, 16 Mar 2005 09:45:18 -0800 (PST) Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: 6667 Message-ID: <20050316174518.2721.qmail@web81201.mail.yahoo.com> > > While I don't think the charter should contain solution for Zombies, I do > think > that BTNS should provide what it promises: "Better than no security." If > having > BTNS means easier ways to do zombie DoS attacks (and I guess Joe and I have > discussed this before on the TCPM mailing list), then, in my opinion BTNS is > not better than no security, (it's only trading one form of DoS attacks with > another form, like moving back door lock to front door). And yes, you can do Just to be clear, I am not opposed to the idea of BTNS, but I would prefer to have a treaoffs document also so that people can decide for themselves. Yogesh From touch at ISI.EDU Wed Mar 16 11:45:12 2005 From: touch at ISI.EDU (Joe Touch) Date: Wed, 16 Mar 2005 11:45:12 -0800 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: <20050316165650.41575.qmail@web81210.mail.yahoo.com> References: <20050316165650.41575.qmail@web81210.mail.yahoo.com> Message-ID: <42388CC8.8030908@isi.edu> Yogesh Prem Swami wrote: > --- Paul Hoffman wrote: > >>At 8:50 AM -0800 3/15/05, Eric Rescorla wrote: >> >>>This basically buys you zilch aainst zombies, which are the current >>>major threeat. >> >>Are you suggesting that prevention of attack by zombies be put in the >>charter? If so, why should that be in BTNS' charter but no one else's? > > While I don't think the charter should contain solution for Zombies, I do think > that BTNS should provide what it promises: "Better than no security." If having > BTNS means easier ways to do zombie DoS attacks (and I guess Joe and I have > discussed this before on the TCPM mailing list), then, in my opinion BTNS is > not better than no security, (it's only trading one form of DoS attacks with > another form, like moving back door lock to front door). And yes, you can do > zombie attacks using 3rd party certs too, but the degree and ease of attacks > are different. DoS ultimately is about degree, isn't it? The issue is degree of work required for an attack. BTNS raises the bar -- better then nothing, but not better than endpoint authentication via CA or shared secret. > If BTNS becomes a wg, It would be nice to at least produce an informational > document/conference-paper which does a through analysis of different trade-offs > involved. > > Yogesh This would be in the applicability statement. I.e., it makes it harder for zombies to attack via shooting out stray packets, but allows them to continue to attack by making full connections. Note that this doesn't make things worse than 'nothing' - it's still better, or in the worst case, 'no worse than nothing.' Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/anonsec/attachments/20050316/16f9dc61/signature.bin From touch at ISI.EDU Wed Mar 16 11:47:01 2005 From: touch at ISI.EDU (Joe Touch) Date: Wed, 16 Mar 2005 11:47:01 -0800 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: <20050316172902.85019.qmail@web81203.mail.yahoo.com> References: <20050316172902.85019.qmail@web81203.mail.yahoo.com> Message-ID: <42388D35.4080002@isi.edu> Yogesh Prem Swami wrote: > Oops! sent too quickly by mistake. > > >>>Noone has argued that BTNS makes zombie DoS/DDoS attacks easier, nor do >>>I see how it would. >>> >> >>Consider this: A security gagateway accepts self signed certs. Let's say A > > and > >>B >>are communicating with each other normally. Now a rogue node Malice wants to >>disrupt this connection. To do this Malice established a secure channel using >>self signed cert, and A accepts it. After the secure channel is established, >>malice puts a couple of IPIPn IPIPackets inside the IPIPsecacket and >>ultimately >>a TCP RSRSTackets with the right atattributesf B. This is shown in figure >>below: >> > > A<--------------------------->B > | > | IPIPn-IPIPn-IPIPn-IPIPnd TCP of B > +---------------------------> Malice > > > You can solve this by looking inside the IP in IP headers (but that could lead > to other kind of DoS attacks where you keep parsing IPeaders for no reason). I > don't recall if RFC2401 and 2402 bis, mention checking inner tunnels for > inbound processing. Tunnel mode does; transport mode does not when the inner header is IPIP (see RFC3884). > Of course, all this could be solved if you change IPsec > that is not an option, right? > > > Yogesh > > > >>>As to what is meant by "better than no security:" better than just >>>sending and accepting unauthenticated plaintext. >>> >>>So should BTNS' charter say anything about zombie DoS protection? I >>>don't think so, at least not until we figure out that BTNS has something >>>to offer there. >>> >>>Nico >>>-- > > > > _______________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/anonsec/attachments/20050316/87329517/signature.bin From touch at ISI.EDU Wed Mar 16 11:49:21 2005 From: touch at ISI.EDU (Joe Touch) Date: Wed, 16 Mar 2005 11:49:21 -0800 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: <20050316174518.2721.qmail@web81201.mail.yahoo.com> References: <20050316174518.2721.qmail@web81201.mail.yahoo.com> Message-ID: <42388DC1.904@isi.edu> Yogesh Prem Swami wrote: >>While I don't think the charter should contain solution for Zombies, I do >>think >>that BTNS should provide what it promises: "Better than no security." If >>having >>BTNS means easier ways to do zombie DoS attacks (and I guess Joe and I have >>discussed this before on the TCPM mailing list), then, in my opinion BTNS is >>not better than no security, (it's only trading one form of DoS attacks with >>another form, like moving back door lock to front door). And yes, you can do > > Just to be clear, I am not opposed to the idea of BTNS, but I would prefer to > have a treaoffs document also so that people can decide for themselves. > > Yogesh That would be appropriate for the applicability statement, and certainly zombies are worth mentioning - i.e., that BTNS is still better than nothing when the zombies attack by simple packets, but is at least no worse than nothing when zombies do full requests. Note that even CA checks aren't going to solve attacks by full requests; the only solution there are SPDs that limit access to known non-attackers. That requires CAs or preshared keys, since access is based on out-of-band identity. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/anonsec/attachments/20050316/2a8518bd/signature.bin From yogesh.swami at acm.org Wed Mar 16 11:57:36 2005 From: yogesh.swami at acm.org (Yogesh Prem Swami) Date: Wed, 16 Mar 2005 11:57:36 -0800 (PST) Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: 6667 Message-ID: <20050316195736.40723.qmail@web81201.mail.yahoo.com> > > > > You can solve this by looking inside the IP in IP headers (but that could > lead > > to other kind of DoS attacks where you keep parsing IPeaders for no > reason). I > > don't recall if RFC2401 and 2402 bis, mention checking inner tunnels for > > inbound processing. > > Tunnel mode does; transport mode does not when the inner header is IPIP > (see RFC3884). > Right. Probably food for charter scope. Yogesh From touch at ISI.EDU Wed Mar 16 12:00:52 2005 From: touch at ISI.EDU (Joe Touch) Date: Wed, 16 Mar 2005 12:00:52 -0800 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: <20050316195736.40723.qmail@web81201.mail.yahoo.com> References: <20050316195736.40723.qmail@web81201.mail.yahoo.com> Message-ID: <42389074.7070706@isi.edu> Yogesh Prem Swami wrote: >>>You can solve this by looking inside the IP in IP headers (but that could >> >>lead >> >>>to other kind of DoS attacks where you keep parsing IPeaders for no >> >>reason). I >> >>>don't recall if RFC2401 and 2402 bis, mention checking inner tunnels for >>>inbound processing. >> >>Tunnel mode does; transport mode does not when the inner header is IPIP >>(see RFC3884). >> > > > Right. Probably food for charter scope. How so? This is no different from in-tunnel attacks on other IPsec SAs; it's already checked, so should not be an issue. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/anonsec/attachments/20050316/1fef19f2/signature.bin From yogesh.swami at acm.org Wed Mar 16 12:07:49 2005 From: yogesh.swami at acm.org (Yogesh Prem Swami) Date: Wed, 16 Mar 2005 12:07:49 -0800 (PST) Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: 6667 Message-ID: <20050316200749.68105.qmail@web81204.mail.yahoo.com> --- Joe Touch wrote: > > > Yogesh Prem Swami wrote: > >>>You can solve this by looking inside the IP in IP headers (but that could > >> > >>lead > >> > >>>to other kind of DoS attacks where you keep parsing IPeaders for no > >> > >>reason). I > >> > >>>don't recall if RFC2401 and 2402 bis, mention checking inner tunnels for > >>>inbound processing. > >> > >>Tunnel mode does; transport mode does not when the inner header is IPIP > >>(see RFC3884). > >> > > > > > > Right. Probably food for charter scope. > > How so? This is no different from in-tunnel attacks on other IPsec SAs; > it's already checked, so should not be an issue. > Ah! Misread tunnel for transport. I haven't read 3884 so can't really comment on what's there. Yogesh From kent at bbn.com Wed Mar 16 15:13:58 2005 From: kent at bbn.com (Stephen Kent) Date: Wed, 16 Mar 2005 18:13:58 -0500 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: <20050316172902.85019.qmail@web81203.mail.yahoo.com> References: <20050316172902.85019.qmail@web81203.mail.yahoo.com> Message-ID: At 9:29 AM -0800 3/16/05, Yogesh Prem Swami wrote: >Oops! sent too quickly by mistake. > >>> Noone has argued that BTNS makes zombie DoS/DDoS attacks easier, nor do >>> I see how it would. >>> >> Consider this: A security gagateway accepts self signed certs. Let's say A >and >> B >> are communicating with each other normally. Now a rogue node Malice wants to >> disrupt this connection. To do this Malice established a secure >>channel using >> self signed cert, and A accepts it. After the secure channel is established, >> malice puts a couple of IPIPn IPIPackets inside the IPIPsecacket and >> ultimately >> a TCP RSRSTackets with the right atattributesf B. This is shown in figure >> below: >> > A<--------------------------->B > | > | IPIPn-IPIPn-IPIPn-IPIPnd TCP of B > +---------------------------> Malice > > >You can solve this by looking inside the IP in IP headers (but that could lead >to other kind of DoS attacks where you keep parsing IPeaders for no reason). I >don't recall if RFC2401 and 2402 bis, mention checking inner tunnels for >inbound processing. Of course, all this could be solved if you change IPsec >that is not an option, right? > >Yogesh IPsec bounds the depth of header inspection, intentionally. 2401bis is pretty clear on that. Changing this is not an option, in my opinion. Steve From yogesh.swami at acm.org Wed Mar 16 16:51:57 2005 From: yogesh.swami at acm.org (Yogesh Swami) Date: Wed, 16 Mar 2005 18:51:57 -0600 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: References: <20050316172902.85019.qmail@web81203.mail.yahoo.com> Message-ID: <4238D4AD.6060202@acm.org> >> >> You can solve this by looking inside the IP in IP headers (but that >> could lead >> to other kind of DoS attacks where you keep parsing IPeaders for no >> reason). I >> don't recall if RFC2401 and 2402 bis, mention checking inner tunnels for >> inbound processing. Of course, all this could be solved if you change >> IPsec >> that is not an option, right? >> >> Yogesh > > > IPsec bounds the depth of header inspection, intentionally. 2401bis is > pretty clear on that. Changing this is not an option, in my opinion. > I wasn't suggesting to change. Far from it. My point was that accepting self-signed certs require a through analysis to make sure that there are no unintended consequences. My example was motivated by con artist in a social setting, who start as strangers and diligently build trust over a period of time but then dupe the victims anyway (similar to going through IKE, and then attacking). Probably it was a bad example, but in my opinion BTNS must produce a document that addresses such issues. This will also help set the right policies on BTNS enabled hosts. Yogesh From kent at bbn.com Thu Mar 17 10:57:54 2005 From: kent at bbn.com (Stephen Kent) Date: Thu, 17 Mar 2005 13:57:54 -0500 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: <4238D4AD.6060202@acm.org> References: <20050316172902.85019.qmail@web81203.mail.yahoo.com> <4238D4AD.6060202@acm.org> Message-ID: At 6:51 PM -0600 3/16/05, Yogesh Swami wrote: >>>You can solve this by looking inside the IP in IP headers (but >>>that could lead >>>to other kind of DoS attacks where you keep parsing IPeaders for >>>no reason). I >>>don't recall if RFC2401 and 2402 bis, mention checking inner tunnels for >>>inbound processing. Of course, all this could be solved if you change IPsec >>>that is not an option, right? >>> >>>Yogesh >> >> >>IPsec bounds the depth of header inspection, intentionally. 2401bis >>is pretty clear on that. Changing this is not an option, in my >>opinion. >> > >I wasn't suggesting to change. Far from it. > >My point was that accepting self-signed certs require a through >analysis to make sure that there are no unintended consequences. My >example was motivated by con artist in a social setting, who start >as strangers and diligently build trust over a period of time but >then dupe the victims anyway (similar to going through IKE, and then >attacking). Probably it was a bad example, but in my opinion BTNS >must produce a document that addresses such issues. This will also >help set the right policies on BTNS enabled hosts. > >Yogesh I agree that use of self-signed certs or other non-authenticated keys is not trivial. The extensions that will be needed to the PAD and/or SPD have to be considered carefully, to avoid undermining the access control features that are central to IPsec. Steve From touch at ISI.EDU Thu Mar 17 12:06:49 2005 From: touch at ISI.EDU (Joe Touch) Date: Thu, 17 Mar 2005 12:06:49 -0800 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: References: <20050316172902.85019.qmail@web81203.mail.yahoo.com> <4238D4AD.6060202@acm.org> Message-ID: <4239E359.9000304@isi.edu> Stephen Kent wrote: > At 6:51 PM -0600 3/16/05, Yogesh Swami wrote: > >>>>You can solve this by looking inside the IP in IP headers (but >>>>that could lead >>>>to other kind of DoS attacks where you keep parsing IPeaders for >>>>no reason). I >>>>don't recall if RFC2401 and 2402 bis, mention checking inner tunnels for >>>>inbound processing. Of course, all this could be solved if you change IPsec >>>>that is not an option, right? >>>> >>>>Yogesh >>> >>> >>>IPsec bounds the depth of header inspection, intentionally. 2401bis >>>is pretty clear on that. Changing this is not an option, in my >>>opinion. >>> >> >>I wasn't suggesting to change. Far from it. >> >>My point was that accepting self-signed certs require a through >>analysis to make sure that there are no unintended consequences. My >>example was motivated by con artist in a social setting, who start >>as strangers and diligently build trust over a period of time but >>then dupe the victims anyway (similar to going through IKE, and then >>attacking). Probably it was a bad example, but in my opinion BTNS >>must produce a document that addresses such issues. This will also >>help set the right policies on BTNS enabled hosts. >> >>Yogesh > > > I agree that use of self-signed certs or other non-authenticated keys > is not trivial. The extensions that will be needed to the PAD and/or > SPD have to be considered carefully, to avoid undermining the access > control features that are central to IPsec. > > Steve Such potential undermining can occur already with the use of 'pass' mode SPD entries, or with keys and CAs that have varying levels of trust. Although this issue has been raised before, there doesn't seem to be a new issue that BTNS exposes regarding "keeping the streams from crossing", i.e., that doesn't already existing in current IPsec/IKE use. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/anonsec/attachments/20050317/785821b5/signature.bin From kent at bbn.com Thu Mar 17 12:32:10 2005 From: kent at bbn.com (Stephen Kent) Date: Thu, 17 Mar 2005 15:32:10 -0500 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: <4239E359.9000304@isi.edu> References: <20050316172902.85019.qmail@web81203.mail.yahoo.com> <4238D4AD.6060202@acm.org> <4239E359.9000304@isi.edu> Message-ID: At 12:06 PM -0800 3/17/05, Joe Touch wrote: >Content-Type: multipart/signed; micalg=pgp-sha1; > protocol="application/pgp-signature"; > boundary="------------enig9B6CBEE8C0216EAB39AE23B8" > > > >Stephen Kent wrote: >>At 6:51 PM -0600 3/16/05, Yogesh Swami wrote: >> >>>>>You can solve this by looking inside the IP in IP headers (but >>>>>that could lead >>>>>to other kind of DoS attacks where you keep parsing IPeaders for >>>>>no reason). I >>>>>don't recall if RFC2401 and 2402 bis, mention checking inner tunnels for >>>>>inbound processing. Of course, all this could be solved if you >>>>>change IPsec >>>>>that is not an option, right? >>>>> >>>>>Yogesh >>>> >>>> >>>>IPsec bounds the depth of header inspection, intentionally. >>>>2401bis is pretty clear on that. Changing this is not an option, >>>>in my opinion. >>>> >>> >>>I wasn't suggesting to change. Far from it. >>> >>>My point was that accepting self-signed certs require a through >>>analysis to make sure that there are no unintended consequences. >>>My example was motivated by con artist in a social setting, who >>>start as strangers and diligently build trust over a period of >>>time but then dupe the victims anyway (similar to going through >>>IKE, and then attacking). Probably it was a bad example, but in my >>>opinion BTNS must produce a document that addresses such issues. >>>This will also help set the right policies on BTNS enabled hosts. >>> >>>Yogesh >> >> >>I agree that use of self-signed certs or other non-authenticated >>keys is not trivial. The extensions that will be needed to the PAD >>and/or SPD have to be considered carefully, to avoid undermining >>the access control features that are central to IPsec. >> >>Steve > >Such potential undermining can occur already with the use of 'pass' >mode SPD entries, or with keys and CAs that have varying levels of >trust. First, I assume you mean BYPASS. Second, the PAD constrains the scope of authorization for each peer re the SPD, and thus provides a clear way to address variability in CA trustworthiness. One obvious danger here is adding controls that make it hard to understand the implications of BTNS peers re authenticated peers, and thus undermine extant security capabilities. >Although this issue has been raised before, there doesn't seem to be >a new issue that BTNS exposes regarding "keeping the streams from >crossing", i.e., that doesn't already existing in current IPsec/IKE >use. That remains to be seen, as people propose specific mechanisms to support BTNS target functionality. Steve From touch at ISI.EDU Thu Mar 17 13:27:13 2005 From: touch at ISI.EDU (Joe Touch) Date: Thu, 17 Mar 2005 13:27:13 -0800 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: References: <20050316172902.85019.qmail@web81203.mail.yahoo.com> <4238D4AD.6060202@acm.org> <4239E359.9000304@isi.edu> Message-ID: <4239F631.2050605@isi.edu> Stephen Kent wrote: > At 12:06 PM -0800 3/17/05, Joe Touch wrote: > >>Content-Type: multipart/signed; micalg=pgp-sha1; >> protocol="application/pgp-signature"; >> boundary="------------enig9B6CBEE8C0216EAB39AE23B8" >> >> >> >>Stephen Kent wrote: >> >>>At 6:51 PM -0600 3/16/05, Yogesh Swami wrote: >>> >>> >>>>>>You can solve this by looking inside the IP in IP headers (but >>>>>>that could lead >>>>>>to other kind of DoS attacks where you keep parsing IPeaders for >>>>>>no reason). I >>>>>>don't recall if RFC2401 and 2402 bis, mention checking inner tunnels for >>>>>>inbound processing. Of course, all this could be solved if you >>>>>>change IPsec >>>>>>that is not an option, right? >>>>>> >>>>>>Yogesh >>>>> >>>>> >>>>>IPsec bounds the depth of header inspection, intentionally. >>>>>2401bis is pretty clear on that. Changing this is not an option, >>>>>in my opinion. >>>>> >>>> >>>>I wasn't suggesting to change. Far from it. >>>> >>>>My point was that accepting self-signed certs require a through >>>>analysis to make sure that there are no unintended consequences. >>>>My example was motivated by con artist in a social setting, who >>>>start as strangers and diligently build trust over a period of >>>>time but then dupe the victims anyway (similar to going through >>>>IKE, and then attacking). Probably it was a bad example, but in my >>>>opinion BTNS must produce a document that addresses such issues. >>>>This will also help set the right policies on BTNS enabled hosts. >>>> >>>>Yogesh >>> >>> >>>I agree that use of self-signed certs or other non-authenticated >>>keys is not trivial. The extensions that will be needed to the PAD >>>and/or SPD have to be considered carefully, to avoid undermining >>>the access control features that are central to IPsec. >>> >>>Steve >> >>Such potential undermining can occur already with the use of 'pass' >>mode SPD entries, or with keys and CAs that have varying levels of >>trust. > > > First, I assume you mean BYPASS. Yup. > Second, the PAD constrains the scope of authorization for each peer > re the SPD, and thus provides a clear way to address variability in > CA trustworthiness. > > One obvious danger here is adding controls that make it hard to > understand the implications of BTNS peers re authenticated peers, and > thus undermine extant security capabilities. Agreed. But BYPASS vs. authenticated has similar issues, IMO. >>Although this issue has been raised before, there doesn't seem to be >>a new issue that BTNS exposes regarding "keeping the streams from >>crossing", i.e., that doesn't already existing in current IPsec/IKE >>use. > > That remains to be seen, as people propose specific mechanisms to > support BTNS target functionality. > > Steve That would require a good argument that BTNS somehow could cross streams with authenticated in ways that BYPASS can't, or that two different authenticated streams can't. Which, again, would be an issue in IPsec/IKE, not with BTNS per se. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/anonsec/attachments/20050317/6e0d21a7/signature.bin From kent at bbn.com Thu Mar 17 14:21:34 2005 From: kent at bbn.com (Stephen Kent) Date: Thu, 17 Mar 2005 17:21:34 -0500 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: <4239F631.2050605@isi.edu> References: <20050316172902.85019.qmail@web81203.mail.yahoo.com> <4238D4AD.6060202@acm.org> <4239E359.9000304@isi.edu> <4239F631.2050605@isi.edu> Message-ID: > > >>Second, the PAD constrains the scope of authorization for each peer >>re the SPD, and thus provides a clear way to address variability in >>CA trustworthiness. >> >>One obvious danger here is adding controls that make it hard to >>understand the implications of BTNS peers re authenticated peers, >>and thus undermine extant security capabilities. > >Agreed. But BYPASS vs. authenticated has similar issues, IMO. > >>>Although this issue has been raised before, there doesn't seem to >>>be a new issue that BTNS exposes regarding "keeping the streams >>>from crossing", i.e., that doesn't already existing in current >>>IPsec/IKE use. >> >>That remains to be seen, as people propose specific mechanisms to >>support BTNS target functionality. >> >>Steve > >That would require a good argument that BTNS somehow could cross >streams with authenticated in ways that BYPASS can't, or that two >different authenticated streams can't. Which, again, would be an >issue in IPsec/IKE, not with BTNS per se. > >Joe > or it requires an argument that the additional management features that have to be introduced to accommodate BTNS create systemic, management-induced vulnerabilities that otherwise would not have existed. Steve From touch at ISI.EDU Fri Mar 18 07:58:54 2005 From: touch at ISI.EDU (Joe Touch) Date: Fri, 18 Mar 2005 07:58:54 -0800 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: References: <20050316172902.85019.qmail@web81203.mail.yahoo.com> <4238D4AD.6060202@acm.org> <4239E359.9000304@isi.edu> <4239F631.2050605@isi.edu> Message-ID: <423AFABE.4040206@isi.edu> Stephen Kent wrote: .... >>>>Although this issue has been raised before, there doesn't seem to >>>>be a new issue that BTNS exposes regarding "keeping the streams >>>>from crossing", i.e., that doesn't already existing in current >>>>IPsec/IKE use. >>> >>>That remains to be seen, as people propose specific mechanisms to >>>support BTNS target functionality. >>> >>>Steve >> >>That would require a good argument that BTNS somehow could cross >>streams with authenticated in ways that BYPASS can't, or that two >>different authenticated streams can't. Which, again, would be an >>issue in IPsec/IKE, not with BTNS per se. >> >>Joe > > or it requires an argument that the additional management features > that have to be introduced to accommodate BTNS create systemic, > management-induced vulnerabilities that otherwise would not have > existed. > > Steve An argument that makes such case would indeed be useful. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/anonsec/attachments/20050318/289e59a5/signature.bin From kent at bbn.com Fri Mar 18 08:15:34 2005 From: kent at bbn.com (Stephen Kent) Date: Fri, 18 Mar 2005 11:15:34 -0500 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: <423AFABE.4040206@isi.edu> References: <20050316172902.85019.qmail@web81203.mail.yahoo.com> <4238D4AD.6060202@acm.org> <4239E359.9000304@isi.edu> <4239F631.2050605@isi.edu> <423AFABE.4040206@isi.edu> Message-ID: At 7:58 AM -0800 3/18/05, Joe Touch wrote: >Content-Type: multipart/signed; micalg=pgp-sha1; > protocol="application/pgp-signature"; > boundary="------------enigC9DEAD8BC58B0B85D7956B22" > > > >Stephen Kent wrote: >.... >>>>>Although this issue has been raised before, there doesn't seem >>>>>to be a new issue that BTNS exposes regarding "keeping the >>>>>streams from crossing", i.e., that doesn't already existing in >>>>>current IPsec/IKE use. >>>> >>>>That remains to be seen, as people propose specific mechanisms to >>>>support BTNS target functionality. >>>> >>>>Steve >>> >>>That would require a good argument that BTNS somehow could cross >>>streams with authenticated in ways that BYPASS can't, or that two >>>different authenticated streams can't. Which, again, would be an >>>issue in IPsec/IKE, not with BTNS per se. >>> >>>Joe >> >>or it requires an argument that the additional management features >>that have to be introduced to accommodate BTNS create systemic, >>management-induced vulnerabilities that otherwise would not have >>existed. >> >>Steve > >An argument that makes such case would indeed be useful. > >Joe Glad we agree :-). Of course, such an argument can be made only once we have concrete proposals in front of the WG. So we have to first develop the proposals, then analyze them before we know whether they are OK or potentially dangerous. Steve From touch at ISI.EDU Fri Mar 18 08:21:37 2005 From: touch at ISI.EDU (Joe Touch) Date: Fri, 18 Mar 2005 08:21:37 -0800 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: References: <20050316172902.85019.qmail@web81203.mail.yahoo.com> <4238D4AD.6060202@acm.org> <4239E359.9000304@isi.edu> <4239F631.2050605@isi.edu> <423AFABE.4040206@isi.edu> Message-ID: <423B0011.6060807@isi.edu> Stephen Kent wrote: > At 7:58 AM -0800 3/18/05, Joe Touch wrote: > >>Content-Type: multipart/signed; micalg=pgp-sha1; >> protocol="application/pgp-signature"; >> boundary="------------enigC9DEAD8BC58B0B85D7956B22" >> >> >> >>Stephen Kent wrote: >>.... >> >>>>>>Although this issue has been raised before, there doesn't seem >>>>>>to be a new issue that BTNS exposes regarding "keeping the >>>>>>streams from crossing", i.e., that doesn't already existing in >>>>>>current IPsec/IKE use. >>>>> >>>>>That remains to be seen, as people propose specific mechanisms to >>>>>support BTNS target functionality. >>>>> >>>>>Steve >>>> >>>>That would require a good argument that BTNS somehow could cross >>>>streams with authenticated in ways that BYPASS can't, or that two >>>>different authenticated streams can't. Which, again, would be an >>>>issue in IPsec/IKE, not with BTNS per se. >>>> >>>>Joe >>> >>>or it requires an argument that the additional management features >>>that have to be introduced to accommodate BTNS create systemic, >>>management-induced vulnerabilities that otherwise would not have >>>existed. >>> >>>Steve >> >>An argument that makes such case would indeed be useful. >> >>Joe > > > Glad we agree :-). > > Of course, such an argument can be made only once we have concrete > proposals in front of the WG. So we have to first develop the > proposals, then analyze them before we know whether they are OK or > potentially dangerous. > > Steve We're agreeing again. We should stop now while we're ahead ;-) Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/anonsec/attachments/20050318/d004540a/signature.bin From hartmans-ietf at mit.edu Wed Mar 23 20:08:38 2005 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Wed, 23 Mar 2005 23:08:38 -0500 Subject: [anonsec] Revised BTNS charter Message-ID: <87d5tpd6t5.fsf@luminous.mit.edu> Hi. Steve Kent graciously revised the BTNS charter to take into account things that happened at the BOF and sent his revised charter to the IESG. I've taken his rewording as a starting point and propose the following new charter. I believe it accomplishes the following things: * Adds the requirement that BTNS play well with traditional IPsec * Addresses some concerns about the word anonymous * Adds text about IPsec's access control architecture * Clarify goal e is the interface recommendations between IPsec and higher-layer protocols. Note that this is expected to compliment draft-bellovin-use-appsec. * Remove the requirement that we finish in three IETF meetings. Timing should be handled through milestones not charters. Better-Than-Nothing Security (btns) =================================== Current Status: Proposed Working Group DESCRIPTION: The IPsec architecture (as described in RFC 2401 and its successor, soon to be issued) provides a comprehensive approach to IP layer security. The architecture and associated protocols (ESP, AH, and IKE) provide protection from a wide array of attacks ,based on a set of security services anchored by access control. It has been suggested that IPsec sometimes may not be deployed because of the requirement to generate and distribute authentication credentials, e.g., certificates or pre-shared secrets. There is significant interest in enabling IPsec to create security associations (SAs) with peers who do not possess authentication credentials that can be validated a priori. Examples of such credentials include self-signed certificates or "bare" public keys. This mode of IPsec operation would enable use of ESP to protect against purely passive attacks, but it would yield SAs that might be vulnerable to various forms of active attacks. The primary purpose of this working group is to specify extensions to the IPsec architecture, and possibly extensions or profiles of IKE, so that IPsec will support creation of unauthenticated SAs. The goal of the resulting RFCs is to enable and encourage simpler and more rapid deployment of IPsec in contexts where use of unauthenticated SAs is deemed appropriate. Any IKE and IPsec extensions/profiles developed in this WG MUST NOT undermine the security facilities already defined for IPsec. Specifically, the access control facilities that are central to IPsec must not be degraded when unauthenticated SAs are employed concurrently with authenticated SAs in the same IPsec implementation. Two related problems emerged during the discussion of this problem. First, there is a desire in the KITTEN, RDDP, NFSv4 and potentially other working groups to make use of unauthenticated IPsec SAs, and later cryptographically bind these SAs to applications, which perform their own authentication. The specification of how this binding is performed for IPsec and the specification of how the binding interacts with application authentication protocols are out of scope for this working group. However, interactions between this cryptographic channel binding and IPsec (e.g., the PAD, SPD, SAD, etc.) are expected to be similar to those for the unauthenticated mode with no binding. This working group needs to consider how to support channel bindings when developing extensions to IPsec, specifically the PAD and SPD elements. Secondly, BTNS and the channel bindings work both encourage IPsec to be used to secure higher layer protocols. As such we need to determine what information these higher layer protocols need from IPsec. Two proposals are under discussion for providing unauthenticated SA support for IPsec: bare RSA keys transported by IKE and self-signed certificates transported by IKE. The WG has the following specific goals: a) Develop an informational framework document to describe the motivation and goals for having security protocols that support unauthenticated security associations in general, and IPsec and IKE in particular b) Develop an informational applicability statement, describing a set of threat models with relaxed adversary capability assumptions, to characterize the contexts in which use of unauthenticated SAs is appropriate c) If necessary, specify standards-track IKE extensions or profiles that support one or both of the bare RSA keys or self-signed certificates d) Specify standards-track extensions to the SPD and PAD to support unauthenticated SAs for IPsec and cryptographic channel bindings for IPsec e) Develop an informational document describing the interfaces that IPsec implementations should provide to allow IPsec SAs to be used to secure higher layer protocols The final goal is expected to compliment work going on elsewhere in establishing best current practice for higher layer protocols secured by IPsec. From hartmans-ietf at mit.edu Wed Mar 23 20:11:23 2005 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Wed, 23 Mar 2005 23:11:23 -0500 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: <20050314192721.0772D28529@sierra.rtfm.com> (Eric Rescorla's message of "Mon, 14 Mar 2005 11:08:26 -0800") References: <20050314192721.0772D28529@sierra.rtfm.com> Message-ID: <878y4dd6ok.fsf@luminous.mit.edu> >>>>> "Eric" == Eric Rescorla writes: Eric> Joe Touch wrote: >> You decide if you want to require BTNS or use it where it's >> available. In the first case, you drop all attempts that don't >> handshake in IKE. >> >> In the second, you drop packets until IKE succeeds or fails, >> and notify the app (a flag that it would be able to >> check). Apps that care can put up a "locked padlock" icon, use >> the connection with an "unlocked padlock", or drop the >> connection themselves then. Eric> This seems to have pretty undesirable performance Eric> consequences. I don't think I'd be willing to use the "use Eric> if available" setting if it implies this kind of delay when Eric> I connect to large fractions of the Internet. Today, I certainly would not want it to be the default. I might well decide I want it as a default for some protocols though. It seems like a reasonable option to support if it doesn't get in the way too much. From ekr at rtfm.com Wed Mar 23 20:27:04 2005 From: ekr at rtfm.com (Eric Rescorla) Date: Wed, 23 Mar 2005 20:27:04 -0800 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: Your message of "Wed, 23 Mar 2005 23:11:23 EST." <878y4dd6ok.fsf@luminous.mit.edu> Message-ID: <20050324044552.1869B284E9@sierra.rtfm.com> Sam Hartman wrote: > >>>>> "Eric" == Eric Rescorla writes: > > Eric> Joe Touch wrote: > >> You decide if you want to require BTNS or use it where it's > >> available. In the first case, you drop all attempts that don't > >> handshake in IKE. > >> > >> In the second, you drop packets until IKE succeeds or fails, > >> and notify the app (a flag that it would be able to > >> check). Apps that care can put up a "locked padlock" icon, use > >> the connection with an "unlocked padlock", or drop the > >> connection themselves then. > > Eric> This seems to have pretty undesirable performance > Eric> consequences. I don't think I'd be willing to use the "use > Eric> if available" setting if it implies this kind of delay when > Eric> I connect to large fractions of the Internet. > > Today, I certainly would not want it to be the default. I might well > decide I want it as a default for some protocols though. It seems > like a reasonable option to support if it doesn't get in the way too > much. OK... I think the key question here is whether we should standardize a protocol that provides *only* this option. -Ekr From hartmans-ietf at mit.edu Wed Mar 23 20:44:04 2005 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Wed, 23 Mar 2005 23:44:04 -0500 Subject: [anonsec] My thoughts on the how to detect BTNS thread Message-ID: <874qf1d563.fsf@luminous.mit.edu> Some thoughts mostly as an individual not as an AD. * Ekr has convinced me that the start with cleartext and end up with BTNS mode was dismissed too quickly. I think we should seriously consider the implications of that mode. * Leap of faith concerns me greatly. I'm concerned that we need to consider how key rollover works. Briefly we need to make sure that keys are not assumed to last too long and that bindings to identifiers (like IP addresses) are not longer than those identifiers are actually valid for the peer. On the other hand leap of faith is useful. * Joe's tendency to decide far-reaching architectural issues are out of scope bothers me a lot. Solving them is almost certainly out of scope. However we always have a duty to understand the architectural implications of the work we do. We should constantly evaluate whether one approach will make other broader issues easier to deal with in the future. Similarly when we find an unexpected architectural issue we should re-evaluate whether our efforts still make sense. The challenge is to make sure that we do not get lost in the big picture and fail to deliver our small part. We do not need to be all things to all people, but we should at least roughly know what we are to most people. General hint for trying to move things out of scope: if having a discussion will take less effort than convincing people a discussion is out of scope, sit back and have the discussion. From hartmans-ietf at mit.edu Wed Mar 23 20:50:59 2005 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Wed, 23 Mar 2005 23:50:59 -0500 Subject: [anonsec] Automatic detection of BTNS capability In-Reply-To: <20050315163553.78DA3284C1@sierra.rtfm.com> (Eric Rescorla's message of "Tue, 15 Mar 2005 08:17:11 -0800") References: <20050315163553.78DA3284C1@sierra.rtfm.com> Message-ID: <87zmwtbqa4.fsf@luminous.mit.edu> >>>>> "Eric" == Eric Rescorla writes: Eric> Eric Rescorla wrote: >> > As to key distribution, the assertion that if I have BTNS >> then you and > I have a key isn't true; many systems already >> have IPsec, but lack the > key. That's the whole point of BTNS >> - to avoid needing per-pair > prearrangement. >> >> What I said was if I *knew* you had BTNS then we can arrange a >> fingerprint through the same channel through which I learned >> you had BTNS. Eric> To be specific, what I meant was that whatever tool you use Eric> to set the new SPD entry can easily fetch the peer's Eric> certificate and write a digest to the SPD, thus removing the Eric> need for modifications to IPsec. It has been my experience that saying "mandate security" requires less of a channel than "mandate security; my public key hash is deadbeeffacebad" Reasons you might not be able to retrieve certificates: * Applying "mandate security" to a large number of destinations * Some destinations (or you) are offline when you make the policy assertion * The lifetime of the "mandate security" policy assertion is longer than the lifetime of the certs Note that we may not need any IKE modifications. The charter anticipates this possibility. Personally I think we'll need some normative text that lets you say "self signed certs OK" as I expect the output of PKI4IPSEC will probably mandate that you do cert path validation and other things we do not want to do. Even so, you're going to need PAD/SPD changes. It's clear to me there are RFCs to be written even if there are not IKEs to be modified. From paul.hoffman at vpnc.org Wed Mar 23 20:58:09 2005 From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Wed, 23 Mar 2005 20:58:09 -0800 Subject: [anonsec] Cleartext into BTNS In-Reply-To: <874qf1d563.fsf@luminous.mit.edu> References: <874qf1d563.fsf@luminous.mit.edu> Message-ID: At 11:44 PM -0500 3/23/05, Sam Hartman wrote: >* Ekr has convinced me that the start with cleartext and end up with > BTNS mode was dismissed too quickly. I think we should seriously > consider the implications of that mode. This has been discussed before in what many people say is the first serious attempt to do this in the IETF: upgrading an active SMTP to SSL mid-conversation. That discussion turned religious fairly quickly, but it might not this time. The archives at are a good starting point. --Paul Hoffman, Director --VPN Consortium From touch at ISI.EDU Wed Mar 23 21:57:01 2005 From: touch at ISI.EDU (Joe Touch) Date: Wed, 23 Mar 2005 21:57:01 -0800 Subject: [anonsec] Revised BTNS charter In-Reply-To: <87d5tpd6t5.fsf@luminous.mit.edu> References: <87d5tpd6t5.fsf@luminous.mit.edu> Message-ID: <424256AD.7020604@isi.edu> Sam Hartman wrote: > Hi. Steve Kent graciously revised the BTNS charter to take into > account things that happened at the BOF and sent his revised charter > to the IESG. It was my impression that we - as a group - had rough consensus on the bulk of the charter at least. And - correct me if this is incorrect - wouldn't the appropriate step have been to get rough consensus on this variant before considering it in the IESG? > I've taken his rewording as a starting point and propose the following > new charter. I believe it accomplishes the following things: > > * Adds the requirement that BTNS play well with traditional IPsec > > * Addresses some concerns about the word anonymous > > * Adds text about IPsec's access control architecture > > * Clarify goal e is the interface recommendations between IPsec and > higher-layer protocols. Note that this is expected to compliment > draft-bellovin-use-appsec. > > * Remove the requirement that we finish in three IETF meetings. > Timing should be handled through milestones not charters. While I agree with *some* of these goals, I do not feel that this is the only thing the revision accomplishes, and I don't feel it is a step forward. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/anonsec/attachments/20050323/d64e9e2f/signature.bin From touch at ISI.EDU Wed Mar 23 22:02:59 2005 From: touch at ISI.EDU (Joe Touch) Date: Wed, 23 Mar 2005 22:02:59 -0800 Subject: [anonsec] My thoughts on the how to detect BTNS thread In-Reply-To: <874qf1d563.fsf@luminous.mit.edu> References: <874qf1d563.fsf@luminous.mit.edu> Message-ID: <42425813.5080208@isi.edu> Sam Hartman wrote: > > Some thoughts mostly as an individual not as an AD. > > * Ekr has convinced me that the start with cleartext and end up with > BTNS mode was dismissed too quickly. I think we should seriously > consider the implications of that mode. That mode might have utility, but it has a number of dangers as well. More importantly, there is no reason that mode is particular to BTNS; it could potentially be applied to any SA. > * Leap of faith concerns me greatly. I'm concerned that we need to > consider how key rollover works. Briefly we need to make sure that > keys are not assumed to last too long and that bindings to > identifiers (like IP addresses) are not longer than those > identifiers are actually valid for the peer. On the other hand leap > of faith is useful. > > * Joe's tendency to decide far-reaching architectural issues are out > of scope bothers me a lot. Solving them is almost certainly out of > scope. However we always have a duty to understand the > architectural implications of the work we do. We should constantly > evaluate whether one approach will make other broader issues easier > to deal with in the future. Similarly when we find an unexpected > architectural issue we should re-evaluate whether our efforts still > make sense. The challenge is to make sure that we do not get lost > in the big picture and fail to deliver our small part. We do not > need to be all things to all people, but we should at least roughly > know what we are to most people. Agreed; however, there is a fine line between considering the implications of our work and considering all possible remotely related implications. The former is constructive; the latter, distracting. To the extent that I feel that some issues raised apply equally well to more conventional IPsec use, they are distracting. To ignore those distractions bothers me a lot ;-) > General hint for trying to move things out of scope: if having a > discussion will take less effort than convincing people a discussion > is out of scope, sit back and have the discussion. Sometimes it is the understanding of *why* things are out of scope that is more important than the amount of time we spend either way. We have a duty to understand that, IMO, as well ;-) Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/anonsec/attachments/20050323/35f4ac8f/signature.bin From touch at ISI.EDU Wed Mar 23 22:04:23 2005 From: touch at ISI.EDU (Joe Touch) Date: Wed, 23 Mar 2005 22:04:23 -0800 Subject: [anonsec] Cleartext into BTNS In-Reply-To: References: <874qf1d563.fsf@luminous.mit.edu> Message-ID: <42425867.6030406@isi.edu> Paul Hoffman wrote: > At 11:44 PM -0500 3/23/05, Sam Hartman wrote: > >>* Ekr has convinced me that the start with cleartext and end up with >> BTNS mode was dismissed too quickly. I think we should seriously >> consider the implications of that mode. > > > This has been discussed before in what many people say is the first > serious attempt to do this in the IETF: upgrading an active SMTP to > SSL mid-conversation. That discussion turned religious fairly > quickly, but it might not this time. The archives at > are a good starting point. > > --Paul Hoffman, Director > --VPN Consortium Is there a precis of that discussion? (or would you or anyone else be willing to provide one?) I.e., one email-long? Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/anonsec/attachments/20050323/c3c43b07/signature-0001.bin From hartmans-ietf at mit.edu Wed Mar 23 22:38:18 2005 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Thu, 24 Mar 2005 01:38:18 -0500 Subject: [anonsec] Revised BTNS charter In-Reply-To: <424256AD.7020604@isi.edu> (Joe Touch's message of "Wed, 23 Mar 2005 21:57:01 -0800") References: <87d5tpd6t5.fsf@luminous.mit.edu> <424256AD.7020604@isi.edu> Message-ID: <87mzstblb9.fsf@luminous.mit.edu> >>>>> "Joe" == Joe Touch writes: Joe> Sam Hartman wrote: >> Hi. Steve Kent graciously revised the BTNS charter to take >> into account things that happened at the BOF and sent his >> revised charter to the IESG. Joe> It was my impression that we - as a group - had rough Joe> consensus on the bulk of the charter at least. Yep. We did and do. Joe> And - correct me if this is incorrect - wouldn't the Joe> appropriate step have been to get rough consensus on this Joe> variant before considering it in the IESG? No. The IESG had sent the old charter out for external review and requested comments be sent to the IESG. That's how external WG review works. >> I've taken his rewording as a starting point and propose the >> following new charter. I believe it accomplishes the following >> things: * Adds the requirement that BTNS play well with >> traditional IPsec * Addresses some concerns about the word >> anonymous * Adds text about IPsec's access control architecture >> * Clarify goal e is the interface recommendations between IPsec >> and higher-layer protocols. Note that this is expected to >> compliment draft-bellovin-use-appsec. * Remove the requirement >> that we finish in three IETF meetings. Timing should be >> handled through milestones not charters. Joe> While I agree with *some* of these goals, I do not feel that Joe> this is the only thing the revision accomplishes, and I don't Joe> feel it is a step forward. OK, then feel free to provide an alternate revision that you like better. I'll note that we discussed a need for a charter change regarding working with traditional IPsec at the BOF and Steve is the only one who has proposed any text. I'm not particularly attached to Steve's text, but I do weigh existing text over no action. Take whatever path you believe is most efficient: provide comments on Steve's text or provide an alternative. I'd just like to actually reach closure. --Sam From hartmans-ietf at mit.edu Wed Mar 23 22:39:32 2005 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Thu, 24 Mar 2005 01:39:32 -0500 Subject: [anonsec] I need BTNS milestones Message-ID: <87is3hbl97.fsf@luminous.mit.edu> Hi. In order to put BTNS back on the IESG agenda I need the milestones agreed to at the BOF. Thanks, --Sam From touch at ISI.EDU Wed Mar 23 23:04:00 2005 From: touch at ISI.EDU (Joe Touch) Date: Wed, 23 Mar 2005 23:04:00 -0800 Subject: [anonsec] integration of Sam's version with the pre-BOF charter Message-ID: <42426660.6000501@isi.edu> Hi, all, The following attempts to incorporate some of the revisions Sam suggested, excepting in particular the use of the term "unauthenticated" to replace the original "anonymous" (which is the term used more commonly to refer to Diffie-Hellman in the absence of signatures), as well as retaining the context and motivation of the previous versions of the charter. Joe ---- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: btns-charter-03-23-05.txt Url: http://www.postel.org/pipermail/anonsec/attachments/20050323/c99fe15b/btns-charter-03-23-05.txt -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/anonsec/attachments/20050323/c99fe15b/signature.bin From Julien.Laganier at Sun.COM Thu Mar 24 02:25:14 2005 From: Julien.Laganier at Sun.COM (Julien Laganier) Date: Thu, 24 Mar 2005 11:25:14 +0100 Subject: [anonsec] integration of Sam's version with the pre-BOF charter In-Reply-To: <42426660.6000501@isi.edu> References: <42426660.6000501@isi.edu> Message-ID: <200503241125.14313.julien.laganier@sun.com> On Thursday 24 March 2005 08:04, Joe Touch wrote: > Hi, all, > > The following attempts to incorporate some of the revisions Sam > suggested, excepting in particular the use of the term > "unauthenticated" to replace the original "anonymous" (which is the > term used more commonly to refer to Diffie-Hellman in the absence > of signatures), as well as retaining the context and motivation of > the previous versions of the charter. The proposed charter is fine with me. --julien PS: There's a typo in item d) at the end of the text: s/anonymou/anonymous From sommerfeld at sun.com Thu Mar 24 07:18:15 2005 From: sommerfeld at sun.com (Bill Sommerfeld) Date: Thu, 24 Mar 2005 10:18:15 -0500 Subject: [anonsec] integration of Sam's version with the pre-BOF charter In-Reply-To: <42426660.6000501@isi.edu> References: <42426660.6000501@isi.edu> Message-ID: <1111677494.9762.50.camel@unknown.hamachi.org> On Thu, 2005-03-24 at 02:04, Joe Touch wrote: > The following attempts to incorporate some of the revisions Sam > suggested, excepting in particular the use of the term "unauthenticated" > to replace the original "anonymous" (which is the term used more > commonly to refer to Diffie-Hellman in the absence of signatures), as > well as retaining the context and motivation of the previous versions of > the charter. I support the removal of "anonymous". it has implications which either blow up the scope of our work or provide grounds for others not familiar with how we're using the term to claim we didn't deliver what we promised. The primary implication I'm referring to, of course, is the notion that "anonymous" services provide a way for a peer's identity to remain unknown to its peers. This is a very hard problem and is not at all related to the problems you seem to be interested in securing. Joe: Can you clarify your objection to "unauthenticated"? I get the impression that you're actually looking for integrity-protected but not authenticated communication.. - Bill From touch at ISI.EDU Thu Mar 24 08:07:07 2005 From: touch at ISI.EDU (Joe Touch) Date: Thu, 24 Mar 2005 08:07:07 -0800 Subject: [anonsec] integration of Sam's version with the pre-BOF charter In-Reply-To: <1111677494.9762.50.camel@unknown.hamachi.org> References: <42426660.6000501@isi.edu> <1111677494.9762.50.camel@unknown.hamachi.org> Message-ID: <4242E5AB.9040101@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bill Sommerfeld wrote: | On Thu, 2005-03-24 at 02:04, Joe Touch wrote: | | |>The following attempts to incorporate some of the revisions Sam |>suggested, excepting in particular the use of the term "unauthenticated" |>to replace the original "anonymous" (which is the term used more |>commonly to refer to Diffie-Hellman in the absence of signatures), as |>well as retaining the context and motivation of the previous versions of |>the charter. | | | I support the removal of "anonymous". it has implications which either | blow up the scope of our work or provide grounds for others not familiar | with how we're using the term to claim we didn't deliver what we | promised. | | The primary implication I'm referring to, of course, is the notion that | "anonymous" services provide a way for a peer's identity to remain | unknown to its peers. | | This is a very hard problem and is not at all related to the problems | you seem to be interested in securing. | | Joe: Can you clarify your objection to "unauthenticated"? I get the | impression that you're actually looking for integrity-protected but not | authenticated communication.. | | - Bill The term "anonymous" when applied to Diffie-Hellman is precisely what I mean, and is the more conventional term in the security literature. That term is also applied to things beyond keying, such as anonymous web surfing, email, etc. - which is certainly a different thing. Unauthenticated isn't appropriate - we may authenticate traffic between two parties whose identity is not validated by a third party or preshared secret. Unauthenticated thus implies that authentication (vs. encryption) is avoided. That's not the case; it is only the identity that is not authenticated. I.e., in both cases there is opportunity for overloaded interpretation, but anonymous - for this purpose - is more appropriate. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCQuWrE5f5cImnZrsRAh5eAJwN67kJWbpObenY/1vFKjvDBqA25ACgt+m1 i88jIErPsDYuFMzLapbRVJw= =M67H -----END PGP SIGNATURE----- From hartmans-ietf at mit.edu Thu Mar 24 08:28:00 2005 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Thu, 24 Mar 2005 11:28:00 -0500 Subject: [anonsec] integration of Sam's version with the pre-BOF charter In-Reply-To: <1111677494.9762.50.camel@unknown.hamachi.org> (Bill Sommerfeld's message of "Thu, 24 Mar 2005 10:18:15 -0500") References: <42426660.6000501@isi.edu> <1111677494.9762.50.camel@unknown.hamachi.org> Message-ID: <87vf7h9ffz.fsf@luminous.mit.edu> >>>>> "Bill" == Bill Sommerfeld writes: Bill> On Thu, 2005-03-24 at 02:04, Joe Touch wrote: >> The following attempts to incorporate some of the revisions Sam >> suggested, excepting in particular the use of the term >> "unauthenticated" to replace the original "anonymous" (which is >> the term used more commonly to refer to Diffie-Hellman in the >> absence of signatures), as well as retaining the context and >> motivation of the previous versions of the charter. Bill> I support the removal of "anonymous". it has implications Bill> which either blow up the scope of our work or provide Bill> grounds for others not familiar with how we're using the Bill> term to claim we didn't deliver what we promised. I understand Bill's concern. However I'm actually OK with a charter either with or without anonymous. The charter Joe sent to the list is fine with me provided that typos are fixed. The charter I sent last night is also fine with me. I've sent Joe's charter to the IESG and Russ noting that we're likely to choose something that very much looks like either Joe's charter or Steve's charter and that anyone with strong opinions should express them now. But mainly, I support efficient closure on this issue. :-) From touch at ISI.EDU Thu Mar 24 09:11:44 2005 From: touch at ISI.EDU (Joe Touch) Date: Thu, 24 Mar 2005 09:11:44 -0800 Subject: [anonsec] integration of Sam's version with the pre-BOF charter In-Reply-To: <42426660.6000501@isi.edu> References: <42426660.6000501@isi.edu> Message-ID: <4242F4D0.4000308@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Joe Touch wrote: | Hi, all, | | The following attempts to incorporate some of the revisions Sam | suggested, excepting in particular the use of the term "unauthenticated" | to replace the original "anonymous" (which is the term used more | commonly to refer to Diffie-Hellman in the absence of signatures), as | well as retaining the context and motivation of the previous versions of | the charter. Specific changes: a) changed unauthenticated back to anonymous reasons as noted in my reply to Bill b) changed the first paragraph mostly back to the pre-BOF version Sam's version weakens the motivation that I thought was fine - and useful - in the pre-BOF version. FYI, most of the differences are in the first half; the two versions are more similar after, "There is significant interest...". c) added motivation back to the end of the second paragraph "...to enable and encourage", again restoring the context beyond basicailly 'where deemed appropriate' The remainder is as Sam posted, including the milestones. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCQvTPE5f5cImnZrsRAkxKAJkBPX66zbaZ9l03gXzzTIK8UmmiyQCfX00R fZm5VZhvWRp08viJGTy1chw= =5smI -----END PGP SIGNATURE----- From kent at bbn.com Thu Mar 24 10:46:38 2005 From: kent at bbn.com (Stephen Kent) Date: Thu, 24 Mar 2005 13:46:38 -0500 Subject: [anonsec] integration of Sam's version with the pre-BOF charter In-Reply-To: <4242E5AB.9040101@isi.edu> References: <42426660.6000501@isi.edu> <1111677494.9762.50.camel@unknown.hamachi.org> <4242E5AB.9040101@isi.edu> Message-ID: Joe, In IPsec, there are two forms of identity that we make use of as an input to access control: the IP address of a peer or a symbolic identity for the peer. This is reflected in the forms of peer ID that are supported in the SPD and in the PAD. We authenticate peers, based on one of these two forms of identity, as a precursor to the access control decisions that determine what traffic is allowed to flow across the IPsec barrier. Authentication is generically defined as verification of an attribute, and more commonly verification of a claimed identity. Thus, in the IPsec context, we authenticate a peer's identity either as an IP address or as a symbolic name. Thus unauthenticated IPsec communication is communication in which IPsec does not verify a claimed either of the two forms of identity attributes which we otherwise would verify. This is precisely what we are proposing to explore when we say that we will consider accepting self-signed certs or raw keys. The identity in a self signed cert might be accurate, and thus provide no anonymity ion terms of a symbolic name, but it would be unauthenticated in the IPsec context. The IP address of a peer may be accurate, and thus provide no anonymity in terms of that identity form, yet if we fail to verify the peer's claim to the address, it is unauthenticated i the IPsec context. These are technically valid reasons for using the term "unauthenticated" in the charter, and for not using "anonymous." The fact that the term "anonymous" often is is used to refer to a D-H exchange that does not employ certs is not germane to this IPsec-centric discussion. After all, we use precisely this form of exchange on IKE today, and then we authenticate the peers. Since we are not suggesting a change the D-H part of IKE, only to the later, authentication phase, it makes sense to refer to the result as an unauthenticated exchange. The fact than an application may later verify a claimed identity for a peer with whom an SA has been created is not relevant to the characterization of the IPsec level communication. Moreover, if an application does authenticate the peer, then one would hardly refer to the overall communication as anonymous at that point! Finally, long ago we changed the terminology in ESP and AH to refer to the service that is provided by the ICV as integrity, not authentication. Thus your closing comment about what "unauthenticated" implies (vs. encryption) also is not consistent with IPsec terminology. Steve From Nicolas.Williams at sun.com Thu Mar 24 11:00:34 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 24 Mar 2005 13:00:34 -0600 Subject: [anonsec] integration of Sam's version with the pre-BOF charter In-Reply-To: <1111677494.9762.50.camel@unknown.hamachi.org> References: <42426660.6000501@isi.edu> <1111677494.9762.50.camel@unknown.hamachi.org> Message-ID: <20050324190033.GZ9676@binky.Central.Sun.COM> On Thu, Mar 24, 2005 at 10:18:15AM -0500, Bill Sommerfeld wrote: > On Thu, 2005-03-24 at 02:04, Joe Touch wrote: > > > The following attempts to incorporate some of the revisions Sam > > suggested, excepting in particular the use of the term "unauthenticated" > > to replace the original "anonymous" (which is the term used more > > commonly to refer to Diffie-Hellman in the absence of signatures), as > > well as retaining the context and motivation of the previous versions of > > the charter. > > I support the removal of "anonymous". it has implications which either > blow up the scope of our work or provide grounds for others not familiar > with how we're using the term to claim we didn't deliver what we > promised. Further, we've had this discussion before, and I saw the name change from "ANONSEC" to "BTNS" as agreement that "anon*" was too confusing or controversial. Why can't we just let it be and use "unauthenticated?" Sure, in some circles "anon*" in the context of Diffie-Hellman refers to an ephemeral-ephemeral DH exchange that is not authenticated. But in other circles "anonimity" refers to privacy protection. Normally such differences in terminology don't matter much because the relevant communities work separately, but here that is not the case. Oh well. Nico -- From Nicolas.Williams at sun.com Thu Mar 24 11:13:01 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 24 Mar 2005 13:13:01 -0600 Subject: [anonsec] Revised BTNS charter In-Reply-To: <87d5tpd6t5.fsf@luminous.mit.edu> References: <87d5tpd6t5.fsf@luminous.mit.edu> Message-ID: <20050324191301.GA9676@binky.Central.Sun.COM> On Wed, Mar 23, 2005 at 11:08:38PM -0500, Sam Hartman wrote: [...] > Two related problems emerged during the discussion of this problem. > First, there is a desire in the KITTEN, RDDP, NFSv4 and potentially > other working groups to make use of unauthenticated IPsec SAs, and > later cryptographically bind these SAs to applications, which perform > their own authentication. The specification of how this binding is > performed for IPsec and the specification of how the binding interacts > with application authentication protocols are out of scope for this > working group. However, interactions > between this cryptographic channel binding and IPsec (e.g., the PAD, > SPD, SAD, etc.) are expected to be similar to those for the > unauthenticated mode with no binding. This working group needs to > consider how to support channel bindings when developing extensions to > IPsec, specifically the PAD and SPD elements. [...] > The WG has the following specific goals: [...] > d) Specify standards-track extensions to the SPD and PAD to > support unauthenticated SAs for IPsec and cryptographic channel bindings > for IPsec > > e) Develop an informational document describing the interfaces that > IPsec implementations should provide to allow IPsec SAs to be used to > secure higher layer protocols I see (d) and (e) as being in conflict with the paragraph quoted above, specifically the third sentence -- items (d) and (e) clearly bring into scope that which is ruled to be out of scope above. Please clarify, Nico -- From touch at ISI.EDU Thu Mar 24 11:18:24 2005 From: touch at ISI.EDU (Joe Touch) Date: Thu, 24 Mar 2005 11:18:24 -0800 Subject: [anonsec] integration of Sam's version with the pre-BOF charter In-Reply-To: References: <42426660.6000501@isi.edu> <1111677494.9762.50.camel@unknown.hamachi.org> <4242E5AB.9040101@isi.edu> Message-ID: <42431280.40007@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen Kent wrote: | Joe, | | In IPsec, there are two forms of identity that we make use of as an | input to access control: the IP address of a peer or a symbolic | identity for the peer. This is reflected in the forms of peer ID that | are supported in the SPD and in the PAD. We authenticate peers, based | on one of these two forms of identity, as a precursor to the access | control decisions that determine what traffic is allowed to flow | across the IPsec barrier. | | Authentication is generically defined as verification of an | attribute, and more commonly verification of a claimed identity. | Thus, in the IPsec context, we authenticate a peer's identity either | as an IP address or as a symbolic name. Thus unauthenticated IPsec | communication is communication in which IPsec does not verify a | claimed either of the two forms of identity attributes which we | otherwise would verify. Authentication is used throughout the security community to refer both to the process of determining the validity of peer's identity as well as to the process applied to ensure the integrety of data; this terminology persists in 2401bis-05: (glossary): ~ Authentication ~ This term is used informally to refer to the combination of two ~ nominally distinct security services, data origin authentication ~ and connectionless integrity. See the definitions below for each ~ of these services. Redefining it to mean only one of these in the revised IPsec documentation is not going to change this ambiguity. | This is precisely what we are proposing to explore when we say that | we will consider accepting self-signed certs or raw keys. The | identity in a self signed cert might be accurate, and thus provide no | anonymity ion terms of a symbolic name, but it would be | unauthenticated in the IPsec context. The IP address of a peer may | be accurate, and thus provide no anonymity in terms of that identity | form, yet if we fail to verify the peer's claim to the address, it is | unauthenticated i the IPsec context. "might be accurate" is not a useful description of anonymity; it is the fact that the name is not *known* accurate that means it is, by definition, anonymous. | These are technically valid reasons for using the term | "unauthenticated" in the charter, and for not using "anonymous." | | The fact that the term "anonymous" often is is used to refer to a D-H | exchange that does not employ certs is not germane to this | IPsec-centric discussion. After all, we use precisely this form of | exchange on IKE today, and then we authenticate the peers. Since we | are not suggesting a change the D-H part of IKE, only to the later, | authentication phase, it makes sense to refer to the result as an | unauthenticated exchange. "Unauthenticated" DH, even as used in IKE, is called "anonymous DH" more commonly in the literature. DH as used in IKE is called "authenticated DH" in the literature (at least where it isn't called STS), but the converse is not the common term. | The fact than an application may later verify a claimed identity for | a peer with whom an SA has been created is not relevant to the | characterization of the IPsec level communication. Moreover, if an | application does authenticate the peer, then one would hardly refer | to the overall communication as anonymous at that point! | | Finally, long ago we changed the terminology in ESP and AH to refer | to the service that is provided by the ICV as integrity, not | authentication. Thus your closing comment about what | "unauthenticated" implies (vs. encryption) also is not consistent | with IPsec terminology. | | Steve It might be sufficient to clarify "anonymous SA" as omitting the authentication phase in IKE, referring to the SAs as unauthenticated to be consistent with IPsec terminology where it specifically applies. (s/anonymous SA/unauthenticated SA/ in the 2nd, 4th, & 6th paragraphs; it is already fixed in the 3rd). In other places, the term is not used in an IPsec-specific way, and is not inconsistent with IPsec terminology. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCQxKAE5f5cImnZrsRAnXkAJ0cw5y6MYh7Wi3nG+tYF73Eej7lEgCgtX0B rtPa5mDITxE+ibaU4ugALbA= =EStI -----END PGP SIGNATURE----- From touch at ISI.EDU Thu Mar 24 11:22:58 2005 From: touch at ISI.EDU (Joe Touch) Date: Thu, 24 Mar 2005 11:22:58 -0800 Subject: [anonsec] integration of Sam's version with the pre-BOF charter In-Reply-To: <20050324190033.GZ9676@binky.Central.Sun.COM> References: <42426660.6000501@isi.edu> <1111677494.9762.50.camel@unknown.hamachi.org> <20050324190033.GZ9676@binky.Central.Sun.COM> Message-ID: <42431392.6020406@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nicolas Williams wrote: | On Thu, Mar 24, 2005 at 10:18:15AM -0500, Bill Sommerfeld wrote: | |>On Thu, 2005-03-24 at 02:04, Joe Touch wrote: |> |> |>>The following attempts to incorporate some of the revisions Sam |>>suggested, excepting in particular the use of the term "unauthenticated" |>>to replace the original "anonymous" (which is the term used more |>>commonly to refer to Diffie-Hellman in the absence of signatures), as |>>well as retaining the context and motivation of the previous versions of |>>the charter. |> |>I support the removal of "anonymous". it has implications which either |>blow up the scope of our work or provide grounds for others not familiar |>with how we're using the term to claim we didn't deliver what we |>promised. | | | Further, we've had this discussion before, and I saw the name change | from "ANONSEC" to "BTNS" as agreement that "anon*" was too confusing or | controversial. When applied to the term "security", I agree. But not when applied to the key exchange itself, when it is the term of art. All these words are overloaded in other areas - as I've noted equally applies to the term 'unauthenticated'. IMO, if we're using an existing variant of anonymous DH key exchange, it is more clear and less confusing to call it what it is already called. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCQxOSE5f5cImnZrsRAs0RAKCwEgjPa2zn1iUnTAmqalgi3jGbPQCg50Dq jEgXYpUHWnHlGtd7TUua9Wo= =FXtS -----END PGP SIGNATURE----- From sommerfeld at sun.com Thu Mar 24 11:38:34 2005 From: sommerfeld at sun.com (Bill Sommerfeld) Date: Thu, 24 Mar 2005 14:38:34 -0500 Subject: [anonsec] integration of Sam's version with the pre-BOF charter In-Reply-To: <4242E5AB.9040101@isi.edu> References: <42426660.6000501@isi.edu> <1111677494.9762.50.camel@unknown.hamachi.org> <4242E5AB.9040101@isi.edu> Message-ID: <1111693113.21058.151.camel@thunk> On Thu, 2005-03-24 at 11:07, Joe Touch wrote: > The term "anonymous" when applied to Diffie-Hellman is precisely what I > mean, and is the more conventional term in the security literature. two comments: - I recently stumbled across rfc2828, "Internet Security Glossary". Admittedly it's an Informational document, but it's "one of ours". - Both "anonymous" and "unauthenticated" have ambiguity issues. - AH was misnamed. Folks who are being careful tend to use "integrity" and "confidentiality" to describe the services provided by AH/ESP. the service that btns seems to want to make optional is the "identification" part of "authentication"... - Bill From Nicolas.Williams at sun.com Thu Mar 24 11:47:19 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 24 Mar 2005 13:47:19 -0600 Subject: [anonsec] My thoughts on the how to detect BTNS thread In-Reply-To: <874qf1d563.fsf@luminous.mit.edu> References: <874qf1d563.fsf@luminous.mit.edu> Message-ID: <20050324194719.GC9676@binky.Central.Sun.COM> On Wed, Mar 23, 2005 at 11:44:04PM -0500, Sam Hartman wrote: > > > Some thoughts mostly as an individual not as an AD. > > * Ekr has convinced me that the start with cleartext and end up with > BTNS mode was dismissed too quickly. I think we should seriously > consider the implications of that mode. As long as that mode is not required I won't object :) > * Leap of faith concerns me greatly. I'm concerned that we need to > consider how key rollover works. Briefly we need to make sure that > keys are not assumed to last too long and that bindings to > identifiers (like IP addresses) are not longer than those > identifiers are actually valid for the peer. On the other hand leap > of faith is useful. As I've been pointing out to folks there is definitely such a problem with leap-of-faith here, though I've focused on the mobility angle. A BTNS implementation in a BITS[*] IPsec implementation would have to make a persistent PAD entry for a new peer's public key, which, combined with not authenticating the peer's key amounts to leap-of-faith "authentication." Peer mobility, like key rollover, causes problems then, as there's currently no way to communicate peer address or credential changes to the PAD in the BITS IPsec implementation. Consider mobility: a mobile node comes along and causes a persistent entry to be created at some peer's PAD, then it goes away and a new node re-uses the same dynamically assigned address as the previous node, but the new node now cannot communicate with thold node's peers as its public key will be different from the previous node's. Clearly key rollover is similar to peer mobility in this context, and has similar consequences: manual intervention or additional IKE extensions will be needed for BITS IPsec w/ BTNS to cope with key rollover / address changes. Perhaps this is a problem that the MOBIKE WG can help with. I note that its charter does not mention the PAD, though it mentions changing established SAs' endpoints (it speaks of "SA gateway addresses," which sounds unfortunately VPN-specfic), but it seems to me that, in a 2401bis world it ought to. [*] A BTNS implementation in a native IPsec implementation may not have this problem as the applications may effectively control the lifetime of the otherwise persistent PAD entries created by BTNS. Note that apps need APIs in order to effect such control; implicit control through, say, socket APIs, specifically connect() and shutdown() is insufficient as an application may need multiple connections to a peer, possibly separated in time. Cheers, Nico -- From touch at ISI.EDU Thu Mar 24 11:56:45 2005 From: touch at ISI.EDU (Joe Touch) Date: Thu, 24 Mar 2005 11:56:45 -0800 Subject: [anonsec] integration of Sam's version with the pre-BOF charter In-Reply-To: <1111693113.21058.151.camel@thunk> References: <42426660.6000501@isi.edu> <1111677494.9762.50.camel@unknown.hamachi.org> <4242E5AB.9040101@isi.edu> <1111693113.21058.151.camel@thunk> Message-ID: <42431B7D.40001@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bill Sommerfeld wrote: | On Thu, 2005-03-24 at 11:07, Joe Touch wrote: | | |>The term "anonymous" when applied to Diffie-Hellman is precisely what I |>mean, and is the more conventional term in the security literature. | | | two comments: | | - I recently stumbled across rfc2828, "Internet Security Glossary". | Admittedly it's an Informational document, but it's "one of ours". | | - Both "anonymous" and "unauthenticated" have ambiguity issues. | | - AH was misnamed. Folks who are being careful tend to use "integrity" | and "confidentiality" to describe the services provided by AH/ESP. FWIW, the term integrity is misused as well. Integrity = unmodified E.g., CRCs protect against accidental integrity compromise but don't tell you WHO (endpoint address or endpoint identity) the data came from, which is why they are subject to modification en-route Authentication = attributable to a source (whether the source's true indentity is known or not) this implies that the content has integrity protection, but integrity alone != authentication (even of just data) | the service that btns seems to want to make optional is the | "identification" part of "authentication"... BTNS would use authenticated or encrypted data with unauthenticated keys. An unauthenticated key means that the true endpoint identity is not known, which makes it anonymous. BTNS *does* want to retain some part of identification - to ensure that an endpoint doesn't change, regardless of the 'identity' (in people-terms, "which person" is constant, but "who" is not checked). Granted that all these terms are being used ambiguously all over the place, but there has not yet been a successful rescoping of terminology that both avoids ambiguity and remains accurate. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCQxt9E5f5cImnZrsRArpjAKCHHh7xWxiK2JsKbyqlIUDbvjxgpgCfSsXA GN6UubS2YsGyIzBNKLciWyY= =vBZj -----END PGP SIGNATURE----- From kent at bbn.com Thu Mar 24 12:45:00 2005 From: kent at bbn.com (Stephen Kent) Date: Thu, 24 Mar 2005 15:45:00 -0500 Subject: [anonsec] integration of Sam's version with the pre-BOF charter In-Reply-To: <42431280.40007@isi.edu> References: <42426660.6000501@isi.edu> <1111677494.9762.50.camel@unknown.hamachi.org> <4242E5AB.9040101@isi.edu> <42431280.40007@isi.edu> Message-ID: At 11:18 AM -0800 3/24/05, Joe Touch wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > > >Stephen Kent wrote: >| Joe, >| >| In IPsec, there are two forms of identity that we make use of as an >| input to access control: the IP address of a peer or a symbolic >| identity for the peer. This is reflected in the forms of peer ID that >| are supported in the SPD and in the PAD. We authenticate peers, based >| on one of these two forms of identity, as a precursor to the access >| control decisions that determine what traffic is allowed to flow >| across the IPsec barrier. >| >| Authentication is generically defined as verification of an >| attribute, and more commonly verification of a claimed identity. >| Thus, in the IPsec context, we authenticate a peer's identity either >| as an IP address or as a symbolic name. Thus unauthenticated IPsec >| communication is communication in which IPsec does not verify a >| claimed either of the two forms of identity attributes which we >| otherwise would verify. > >Authentication is used throughout the security community to refer both >to the process of determining the validity of peer's identity as well as >to the process applied to ensure the integrety of data; this terminology >persists in 2401bis-05: > > >(glossary): >~ Authentication >~ This term is used informally to refer to the combination of two >~ nominally distinct security services, data origin authentication >~ and connectionless integrity. See the definitions below for each >~ of these services. note the term "informally in the definition. note that we explicitly moved away from using the term "authentication" to describe the service supported by the ICV in AH and ESP a few years ago. >Redefining it to mean only one of these in the revised IPsec >documentation is not going to change this ambiguity. I don't share you perception of the ambiguity, and neither do lots of other folks who argued with you about this on the list the last time, as Nico noted. >> This is precisely what we are proposing to explore when we say that >| we will consider accepting self-signed certs or raw keys. The >| identity in a self signed cert might be accurate, and thus provide no >| anonymity ion terms of a symbolic name, but it would be >| unauthenticated in the IPsec context. The IP address of a peer may >| be accurate, and thus provide no anonymity in terms of that identity >| form, yet if we fail to verify the peer's claim to the address, it is >| unauthenticated i the IPsec context. > >"might be accurate" is not a useful description of anonymity; it is the >fact that the name is not *known* accurate that means it is, by >definition, anonymous. my examples show that, in the general case, an unauthenticated SA does not provide anonymity. describing the goal of BTNS as anonymity makes no sense, given the reality of the forms of identity with which IPsec deals. > >| These are technically valid reasons for using the term >| "unauthenticated" in the charter, and for not using "anonymous." >| >| The fact that the term "anonymous" often is is used to refer to a D-H >| exchange that does not employ certs is not germane to this >| IPsec-centric discussion. After all, we use precisely this form of >| exchange on IKE today, and then we authenticate the peers. Since we >| are not suggesting a change the D-H part of IKE, only to the later, >| authentication phase, it makes sense to refer to the result as an >| unauthenticated exchange. > >"Unauthenticated" DH, even as used in IKE, is called "anonymous DH" more >commonly in the literature. DH as used in IKE is called "authenticated >DH" in the literature (at least where it isn't called STS), but the >converse is not the common term. the DH exchange, in isolation is anonymous because the public keys are not bound to identities by certs. but we are not addressing the DH exchange in BTNS. we are talking about what IKE does and IPsec relies upon that provides authentication, and how we plan to remove the need for the authentication. > >| The fact than an application may later verify a claimed identity for >| a peer with whom an SA has been created is not relevant to the >| characterization of the IPsec level communication. Moreover, if an >| application does authenticate the peer, then one would hardly refer >| to the overall communication as anonymous at that point! >| >| Finally, long ago we changed the terminology in ESP and AH to refer >| to the service that is provided by the ICV as integrity, not >| authentication. Thus your closing comment about what >| "unauthenticated" implies (vs. encryption) also is not consistent >| with IPsec terminology. >| >| Steve > >It might be sufficient to clarify "anonymous SA" as omitting the >authentication phase in IKE, referring to the SAs as unauthenticated to >be consistent with IPsec terminology where it specifically applies. >(s/anonymous SA/unauthenticated SA/ in the 2nd, 4th, & 6th paragraphs; >it is already fixed in the 3rd). > >In other places, the term is not used in an IPsec-specific way, and is >not inconsistent with IPsec terminology. BTNS may aspire to be more general than IPsec, but since the milestones and deliverables are all IPsec-specific, it makes sense to use terminology that is appropriate in the IPsec context. Steve From hartmans-ietf at mit.edu Thu Mar 24 13:32:05 2005 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Thu, 24 Mar 2005 16:32:05 -0500 Subject: [anonsec] Revised BTNS charter In-Reply-To: <20050324191301.GA9676@binky.Central.Sun.COM> (Nicolas Williams's message of "Thu, 24 Mar 2005 13:13:01 -0600") References: <87d5tpd6t5.fsf@luminous.mit.edu> <20050324191301.GA9676@binky.Central.Sun.COM> Message-ID: >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Wed, Mar 23, 2005 at 11:08:38PM -0500, Sam Hartman Nicolas> wrote: [...] >> Two related problems emerged during the discussion of this >> problem. First, there is a desire in the KITTEN, RDDP, NFSv4 >> and potentially other working groups to make use of >> unauthenticated IPsec SAs, and later cryptographically bind >> these SAs to applications, which perform their own >> authentication. The specification of how this binding is >> performed for IPsec and the specification of how the binding >> interacts with application authentication protocols are out of >> scope for this working group. However, interactions between >> this cryptographic channel binding and IPsec (e.g., the PAD, >> SPD, SAD, etc.) are expected to be similar to those for the >> unauthenticated mode with no binding. This working group needs >> to consider how to support channel bindings when developing >> extensions to IPsec, specifically the PAD and SPD elements. Nicolas> [...] >> The WG has the following specific goals: Nicolas> [...] >> d) Specify standards-track extensions to the SPD and PAD to >> support unauthenticated SAs for IPsec and cryptographic channel >> bindings for IPsec >> >> e) Develop an informational document describing the interfaces >> that IPsec implementations should provide to allow IPsec SAs to >> be used to secure higher layer protocols Nicolas> I see (d) and (e) as being in conflict with the paragraph Nicolas> quoted above, specifically the third sentence -- items Nicolas> (d) and (e) clearly bring into scope that which is ruled Nicolas> to be out of scope above. The intent is that channel bindings is in scope only when there is a likelihood of conflicts if the channel bindings and non-channel-bindings solutions are pursued separately. I believe the SPD/PAD interactions and the interface requirements are both examples where you want only one solution--a solution that works with BTNS and channel bindings. So that solution will be developed here. From hartmans-ietf at mit.edu Fri Mar 25 10:31:16 2005 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Fri, 25 Mar 2005 13:31:16 -0500 Subject: [anonsec] anonymous unauthenticated Message-ID: <87eke3a87f.fsf@luminous.mit.edu> So, my current plan is to submit a charter to the IESG that uses unauthenticated rather than anonymous. I think that Joe would rather I minimize the number of changes to do this. So, I plan to start with Joe's charter and make the minmimum number of changes to useunauthenticated instead of anonymous. My reasons for using unauthenticated are as follows: * Anonymous created sufficient confusion early on that a lot of people stopped using the term; I was half-heartedly alternating between anonymous keying and unauthenticated, liking neither. Others were using different phrases. * I had intended to avoid the word anonymous when I made the revisions that ended up at the BOF charter, but failed to find a way of doing so that I liked. * It came up again and with the exception of Joe there seems to be general support for avoiding the term anonymous. If people can think of alternate phrasing that is neither anonymous nor unauthenticated but that is reasonably clear, that would be preferable to any of the alternatives. --Sam From touch at ISI.EDU Mon Mar 28 14:43:13 2005 From: touch at ISI.EDU (Joe Touch) Date: Mon, 28 Mar 2005 14:43:13 -0800 Subject: [anonsec] anonymous unauthenticated In-Reply-To: <87eke3a87f.fsf@luminous.mit.edu> References: <87eke3a87f.fsf@luminous.mit.edu> Message-ID: <42488881.5010207@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sam Hartman wrote: > > So, my current plan is to submit a charter to the IESG that uses > unauthenticated rather than anonymous. I think that Joe would rather > I minimize the number of changes to do this. So, I plan to start with > Joe's charter and make the minmimum number of changes to > useunauthenticated instead of anonymous. > > My reasons for using unauthenticated are as follows: > > * Anonymous created sufficient confusion early on that a lot of people > stopped using the term; I was half-heartedly alternating between > anonymous keying and unauthenticated, liking neither. Others were > using different phrases. > > * I had intended to avoid the word anonymous when I made the revisions > that ended up at the BOF charter, but failed to find a way of doing > so that I liked. > > * It came up again and with the exception of Joe there seems to be general support for avoiding the term anonymous. > > If people can think of alternate phrasing that is neither anonymous > nor unauthenticated but that is reasonably clear, that would be > preferable to any of the alternatives. > > --Sam How about "uncredentialed"? Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCSIiBE5f5cImnZrsRAja7AJwLDlt9k4p96A5fEHdIOFC9SKQLHgCfRB6r vd0orpyclv15XYAIuTrechE= =lTMM -----END PGP SIGNATURE----- From hartmans-ietf at mit.edu Tue Mar 29 14:21:42 2005 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Tue, 29 Mar 2005 17:21:42 -0500 Subject: [anonsec] [Sam Hartman] Revised: BTNS charter Message-ID: Hi. Here is the charter I've submitted to the IESG for consideration at Thursday's meeting. In the interests of making everyone unhappy, I've not quite followed the approach I said I was going to follow regarding unauthenticated vs anonymous. (Well, OK, actually it was in the interests of trying to make the charter flow better. Really I have no interest in making anyone unhappy and am still surprised that this has been such a big issue.) I think anonymous keying is a reasonable description of what we're doing here and is hopefully not confused with anonymous communication which has all sorts of privacy implications. In cases where we are discussing the key exchange I've used the term anonymous keying. It was already used once in the draft charter. In cases where we are discussing IPsec SAs I've used the term unauthenticated SA. This is still not perfect; it is still confusing and I'm sure people will disagree with it. Hopefully we will at least remember what it means well enough to be able to understand our charter. I've also inserted the phrase "to avoid duplication of effort," into the paragraph about channel binding. This was done to address a concern Russ brought up as we discussed the charter yesterday. Better-Than-Nothing Security (btns) Last Modified: 2005-03-29 Security Area Director(s): Russell Housley Sam Hartman Security Area Advisor: Sam Hartman Mailing Lists: General Discussion: anonsec at postel.org To subscribe: http://www.postel.org/anonsec Archive: http://www.postel.org/anonsec DESCRIPTION: Current Internet Protocol security protocol (IPsec) and Internet Key Exchange protocol (IKE) present somewhat of an all-or-nothing alternative; these protocols provide protection from a wide array of possible threats, but are sometimes not deployed because of the need for pre-existing credentials. There is significant interest in providing anonymous (unauthenticated) keying for IPsec to create security associations (SAs) with peers who do not possess authentication credentials that can be validated. Examples of such credentials include self-signed certificates or "bare" public keys. This mode would protect against passive attacks but would be vulnerable to active attacks. The primary purpose of this working group is to specify extensions to the IPsec architecture, and possibly extensions or profiles of IKE, so that IPsec will support creation of unauthenticated SAs. The goal of the resulting RFCs is to enable and encourage simpler and more rapid deployment of IPsec in contexts where use of unauthenticated SAs is deemed appropriate, to enable and encourage the use of network security where it has been difficult to deploy--notably, to enable simpler, more rapid deployment. Any IKE and IPsec extensions/profiles developed in this WG MUST NOT undermine the security facilities already defined for IPsec. Specifically, the access control facilities that are central to IPsec must not be degraded when unauthenticated SAs are employed concurrently with authenticated SAs in the same IPsec implementation. Two related problems emerged during the discussion of this problem. First, there is a desire in the KITTEN, RDDP, NFSv4 and potentially other working groups to make use of unauthenticated IPsec SAs, and later cryptographically bind these SAs to applications, which perform their own authentication. The specification of how this binding is performed for IPsec and the specification of how the binding interacts with application authentication protocols are out of scope for this working group. However, interactions between this cryptographic channel binding and IPsec (e.g., the PAD, SPD, SAD, etc.) are expected to be similar to those for the unauthenticated mode with no binding. To avoid duplication of effort, This working group needs to consider how to support channel bindings when developing extensions to IPsec, specifically the PAD and SPD elements. Secondly, BTNS and the channel bindings work both encourage IPsec to be used to secure higher layer protocols. As such we need to determine what information these higher layer protocols need from IPsec. Two proposals are under discussion for providing unauthenticated SA support for IPsec: bare RSA keys transported by IKE and self-signed certificates transported by IKE. The WG has the following specific goals: a) Develop an informational framework document to describe the motivation and goals for having security protocols that support anonymous keying of security associations in general, and IPsec and IKE in particular b) Develop an informational applicability statement, describing a set of threat models with relaxed adversary capability assumptions, to characterize the contexts in which use of unauthenticated SAs is appropriate c) If necessary, specify standards-track IKE extensions or profiles that support one or both of the bare RSA keys or self-signed certificates d) Specify standards-track extensions to the SPD and PAD to support unauthenticated SAs for IPsec and cryptographic channel bindings for IPsec e) Develop an informational document describing the interfaces that IPsec implementations should provide to allow IPsec SAs to be used to secure higher layer protocols The final goal is expected to complement work going on elsewhere in establishing best current practice for higher layer protocols secured by IPsec.