From hartmans-ietf at mit.edu Sun Dec 4 07:47:59 2005 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Sun, 04 Dec 2005 10:47:59 -0500 Subject: [anonsec] SAB without connection latching Message-ID: Nico has partially described a feature called connection latching that allows a native mode IPsec implementation to guarantee that the same peer ID is used for every packet sent over a particular connection. It seems fairly clear that BTNS benefits significantly from this technology. The applicability statement makes the claim that BTNS protects against on-path attacks after the connection is established. In order to do that we need to have some form of something like connection latching even in non-native implementations. If we do nothing then the SA from one BTNS peer could be replaced by a SA from another BTNS peer and the traffic on the connection would be funneled over that SA. It seems like we're going to need something like mini-leap-of-faith in which we require that the identity of a peer remain constant for traffic protected by a btns SA. The obvious implementation to me seems to be something like: 1) Establish some sort of timer for packets going over the SA. If the connection appears to still be alive, then require that we maintain the same peer identity. 2) If for some reason we have to drop such an SA, install a temporary discard rule for some period of time to make sure that we kill off the connection. Note that I'm talking in very general terms about what behavior we want. I'm not talking about specific changes to the processing model, to the PAD or SPD. I realize that in order to be useful we eventually need to get to that level of detial. I also realize that when we close the loop and get to that level of detail we may find we change our requirements in order to be more consistent with the IPsec architecture. At this point though I'd like to hear what people think about the required behavior in non-native implementations. --Sam From Nicolas.Williams at sun.com Sun Dec 4 12:41:28 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Sun, 4 Dec 2005 14:41:28 -0600 Subject: [anonsec] SAB without connection latching In-Reply-To: References: Message-ID: <20051204204127.GG21090@binky.Central.Sun.COM> On Sun, Dec 04, 2005 at 10:47:59AM -0500, Sam Hartman wrote: > The applicability statement makes the claim that BTNS protects against > on-path attacks after the connection is established. In order to do ^^ off-path, not on-path. If the applicability statement says "on-path" then that's got to be a mistake. And passive attacks. To protect against more active attacks requires additional features, such as connection latching and channel binding, or, where workable, leap-of-faith. Nico -- From hartmans-ietf at mit.edu Sun Dec 4 12:50:51 2005 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Sun, 04 Dec 2005 15:50:51 -0500 Subject: [anonsec] 2401bis vs 2401 In-Reply-To: <4344B8E1.7090807@isi.edu> (Joe Touch's message of "Wed, 05 Oct 2005 22:40:49 -0700") References: <4344B8E1.7090807@isi.edu> Message-ID: >>>>> "Joe" == Joe Touch writes: Joe> If 2401bis is strictly required (vs. 2401), it might be Joe> useful to adjust the title (not sure, though). I'd prefer if Joe> there were a way to refer to 2401 processing, even if in an Joe> appendix, though I don't know if that's feasible. Hi. I've been working with Nico on trying to understand the implications of his draft for 2401bis. I've also been following the Kink working group's efforts to work with both 2401bis and 2401. My reasonably strong belief is that we have to do more than twice the work if we want to support both 2401bis and 2401. we need to do the analysis separately for each model (they are that different) and we then need to make sure the results are consistent. We must support 2401bis. I argue that we should not spend effort on 2401. I understand David's concerns WRT iscsi and IKE V1. I don't think only thinking about the 2401bis architecture precludes IKE V1 from being considered. --Sam From Nicolas.Williams at sun.com Sun Dec 4 12:59:47 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Sun, 4 Dec 2005 14:59:47 -0600 Subject: [anonsec] 2401bis vs 2401 In-Reply-To: References: <4344B8E1.7090807@isi.edu> Message-ID: <20051204205947.GI21090@binky.Central.Sun.COM> On Sun, Dec 04, 2005 at 03:50:51PM -0500, Sam Hartman wrote: > Hi. I've been working with Nico on trying to understand the > implications of his draft for 2401bis. I've also been following the > Kink working group's efforts to work with both 2401bis and 2401. BTW, I'll write up our discussion and send notes to the list tomorrow. Nico -- From hartmans-ietf at mit.edu Sun Dec 4 13:42:38 2005 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Sun, 04 Dec 2005 16:42:38 -0500 Subject: [anonsec] SAB without connection latching In-Reply-To: <20051204204127.GG21090@binky.Central.Sun.COM> (Nicolas Williams's message of "Sun, 4 Dec 2005 14:41:28 -0600") References: <20051204204127.GG21090@binky.Central.Sun.COM> Message-ID: >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Sun, Dec 04, 2005 at 10:47:59AM -0500, Sam Hartman Nicolas> wrote: >> The applicability statement makes the claim that BTNS protects >> against on-path attacks after the connection is established. >> In order to do Nicolas> ^^ off-path, not on-path. If the applicability Nicolas> statement says "on-path" then that's got to be a mistake. no, I'm fairly sure that protecting against on-path attacks after the connection is established is a goal of SAB. The entire point of my message is that in order to do that we need to do something more complicated than the most trivial possible vision of SAB. From Nicolas.Williams at sun.com Sun Dec 4 16:11:08 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Sun, 4 Dec 2005 18:11:08 -0600 Subject: [anonsec] SAB without connection latching In-Reply-To: References: <20051204204127.GG21090@binky.Central.Sun.COM> Message-ID: <20051205001108.GJ21090@binky.Central.Sun.COM> On Sun, Dec 04, 2005 at 04:42:38PM -0500, Sam Hartman wrote: > >>>>> "Nicolas" == Nicolas Williams writes: > > Nicolas> On Sun, Dec 04, 2005 at 10:47:59AM -0500, Sam Hartman > Nicolas> wrote: > >> The applicability statement makes the claim that BTNS protects > >> against on-path attacks after the connection is established. > >> In order to do > Nicolas> ^^ off-path, not on-path. If the applicability > Nicolas> statement says "on-path" then that's got to be a mistake. > > no, I'm fairly sure that protecting against on-path attacks after the > connection is established is a goal of SAB. > > The entire point of my message is that in order to do that we need to > do something more complicated than the most trivial possible vision of > SAB. Oh, right, "other on-path attacks after key exchange." Yes, I don't see how that can work w/o connection latching and/or leap-of-faith. Nico -- From lha at it.su.se Mon Dec 5 04:40:40 2005 From: lha at it.su.se (=?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?=) Date: Mon, 5 Dec 2005 13:40:40 +0100 Subject: [anonsec] minutes from ietf64 Message-ID: <0CC47F4A-A849-4CE4-8910-FE5C28B2AF19@it.su.se> Hello, I've uploaded the minutes for BTNS to the meeting materials website please send any comments on them before 18 Dec, thanks. Love http://www3.ietf.org/proceedings/05nov/minutes/btns.txt -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://www.postel.org/pipermail/anonsec/attachments/20051205/0b609d6e/PGP.bin From pekka.nikander at nomadiclab.com Mon Dec 5 05:23:05 2005 From: pekka.nikander at nomadiclab.com (Pekka Nikander) Date: Mon, 5 Dec 2005 14:23:05 +0100 Subject: [anonsec] SAB without connection latching In-Reply-To: References: Message-ID: <4C48F2A6-FDBA-43B7-915E-B92AE7D0BE33@nomadiclab.com> > It seems like we're going to need something like mini-leap-of-faith in > which we require that the identity of a peer remain constant for > traffic protected by a btns SA. I agree that such a feature would be very useful. > The obvious implementation to me seems to be something like: > > 1) Establish some sort of timer for packets going over the SA. If the > connection appears to still be alive, then require that we maintain > the same peer identity. > > 2) If for some reason we have to drop such an SA, install a temporary > discard rule for some period of time to make sure that we kill off > the connection. > > .... At this point though I'd like to hear what people think > about the required behavior in non-native implementations. What you describe above, with suitable administrative interfaces, sounds fine to me. But then, personally, I am not that interested in non-native implementations. Hence, I would also be happy to see the threats just documented, without requiring that non-native BTNS provide the equivalent of connection latching. --Pekka From kent at bbn.com Mon Dec 5 08:36:27 2005 From: kent at bbn.com (Stephen Kent) Date: Mon, 5 Dec 2005 11:36:27 -0500 Subject: [anonsec] SAB without connection latching In-Reply-To: <4C48F2A6-FDBA-43B7-915E-B92AE7D0BE33@nomadiclab.com> References: <4C48F2A6-FDBA-43B7-915E-B92AE7D0BE33@nomadiclab.com> Message-ID: I'll just note that 2401bis (soon to be issued as 4301, yeah!) adopts a processing model that relies on decorrelation to simplify and speed up processing in SG and BITW implementations. Making frequent changes to the SPD, as suggested in your message, may be computationally costly. Steve From hartmans-ietf at mit.edu Mon Dec 5 09:13:16 2005 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Mon, 05 Dec 2005 12:13:16 -0500 Subject: [anonsec] SAB without connection latching In-Reply-To: (Stephen Kent's message of "Mon, 5 Dec 2005 11:36:27 -0500") References: <4C48F2A6-FDBA-43B7-915E-B92AE7D0BE33@nomadiclab.com> Message-ID: >>>>> "Stephen" == Stephen Kent writes: Stephen> I'll just note that 2401bis (soon to be issued as 4301, Stephen> yeah!) adopts a processing model that relies on Stephen> decorrelation to simplify and speed up processing in SG Stephen> and BITW implementations. Making frequent changes to the Stephen> SPD, as suggested in your message, may be computationally Stephen> costly. noted. do you have any other approaches you think we should look at? --Sam From Black_David at emc.com Mon Dec 5 09:28:15 2005 From: Black_David at emc.com (Black_David@emc.com) Date: Mon, 5 Dec 2005 12:28:15 -0500 Subject: [anonsec] SAB without connection latching Message-ID: Steve, > I'll just note that 2401bis (soon to be issued as 4301, yeah!) > adopts a processing model that relies on decorrelation to simplify > and speed up processing in SG and BITW implementations. Making > frequent changes to the SPD, as suggested in your message, may be > computationally costly. Perhaps this ought to be done via the SAD rather than the SPD? Using an SAD entry for a "might be dead, but not 100% sure" SA has some resemblances to what's already necessary to deal with dead peers, and inflicting temporary discard rules on the SPD is going to make it significantly harder to check whether the decorrelated SPD that is being used actually implements the intended policy. 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 kent at bbn.com Mon Dec 5 10:07:04 2005 From: kent at bbn.com (Stephen Kent) Date: Mon, 5 Dec 2005 13:07:04 -0500 Subject: [anonsec] SAB without connection latching In-Reply-To: References: Message-ID: At 12:28 PM -0500 12/5/05, Black_David at emc.com wrote: >Steve, > >> I'll just note that 2401bis (soon to be issued as 4301, yeah!) >> adopts a processing model that relies on decorrelation to simplify >> and speed up processing in SG and BITW implementations. Making >> frequent changes to the SPD, as suggested in your message, may be >> computationally costly. > >Perhaps this ought to be done via the SAD rather than the SPD? >Using an SAD entry for a "might be dead, but not 100% sure" SA has >some resemblances to what's already necessary to deal with dead peers, >and inflicting temporary discard rules on the SPD is going to make >it significantly harder to check whether the decorrelated SPD that >is being used actually implements the intended policy. > >Thanks, >--David Good suggestion. Steve From Nicolas.Williams at sun.com Mon Dec 5 10:36:24 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 5 Dec 2005 12:36:24 -0600 Subject: [anonsec] SAB without connection latching In-Reply-To: References: <4C48F2A6-FDBA-43B7-915E-B92AE7D0BE33@nomadiclab.com> Message-ID: <20051205183624.GQ21090@binky.Central.Sun.COM> On Mon, Dec 05, 2005 at 11:36:27AM -0500, Stephen Kent wrote: > I'll just note that 2401bis (soon to be issued as 4301, yeah!) > adopts a processing model that relies on decorrelation to simplify > and speed up processing in SG and BITW implementations. Making > frequent changes to the SPD, as suggested in your message, may be > computationally costly. Even when done only on BITS or native implementations? From hartmans-ietf at mit.edu Mon Dec 5 11:29:42 2005 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Mon, 05 Dec 2005 14:29:42 -0500 Subject: [anonsec] SAB without connection latching In-Reply-To: <20051205183624.GQ21090@binky.Central.Sun.COM> (Nicolas Williams's message of "Mon, 5 Dec 2005 12:36:24 -0600") References: <4C48F2A6-FDBA-43B7-915E-B92AE7D0BE33@nomadiclab.com> <20051205183624.GQ21090@binky.Central.Sun.COM> Message-ID: >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Mon, Dec 05, 2005 at 11:36:27AM -0500, Stephen Kent Nicolas> wrote: >> I'll just note that 2401bis (soon to be issued as 4301, yeah!) >> adopts a processing model that relies on decorrelation to >> simplify and speed up processing in SG and BITW >> implementations. Making frequent changes to the SPD, as >> suggested in your message, may be computationally costly. Nicolas> Even when done only on BITS or native implementations? As I understand it, it is an optimization any IPsec implementation may choose to use. As best I can tell the text is constructed so that it is purely a performance issue. So, you can choose to do it in your implementation; lookups get faster and changes get slower. You could presumably choose to do anything else provided that it was externally the same. From kent at bbn.com Mon Dec 5 10:42:22 2005 From: kent at bbn.com (Stephen Kent) Date: Mon, 5 Dec 2005 13:42:22 -0500 Subject: [anonsec] SAB without connection latching In-Reply-To: References: <4C48F2A6-FDBA-43B7-915E-B92AE7D0BE33@nomadiclab.com> Message-ID: At 12:13 PM -0500 12/5/05, Sam Hartman wrote: > >>>>> "Stephen" == Stephen Kent writes: > > Stephen> I'll just note that 2401bis (soon to be issued as 4301, > Stephen> yeah!) adopts a processing model that relies on > Stephen> decorrelation to simplify and speed up processing in SG > Stephen> and BITW implementations. Making frequent changes to the > Stephen> SPD, as suggested in your message, may be computationally > Stephen> costly. > > >noted. do you have any other approaches you think we should look at? > >--Sam I think David's suggestion, to manage the inactivity timeout via the SAD, vs. the SPD, might be good. Steve From kent at bbn.com Mon Dec 5 12:13:04 2005 From: kent at bbn.com (Stephen Kent) Date: Mon, 5 Dec 2005 15:13:04 -0500 Subject: [anonsec] SAB without connection latching In-Reply-To: <20051205183624.GQ21090@binky.Central.Sun.COM> References: <4C48F2A6-FDBA-43B7-915E-B92AE7D0BE33@nomadiclab.com> <20051205183624.GQ21090@binky.Central.Sun.COM> Message-ID: At 12:36 PM -0600 12/5/05, Nicolas Williams wrote: >On Mon, Dec 05, 2005 at 11:36:27AM -0500, Stephen Kent wrote: >> I'll just note that 2401bis (soon to be issued as 4301, yeah!) >> adopts a processing model that relies on decorrelation to simplify >> and speed up processing in SG and BITW implementations. Making >> frequent changes to the SPD, as suggested in your message, may be >> computationally costly. > >Even when done only on BITS or native implementations? I said SGs and BITW. BITS is also an issue. Native, end-system implementations, because they can take advantage of the socket interface info, don't benefit as much from de-correlations, so I don't see this as an issue in that context. Steve From kent at bbn.com Mon Dec 5 12:14:09 2005 From: kent at bbn.com (Stephen Kent) Date: Mon, 5 Dec 2005 15:14:09 -0500 Subject: [anonsec] SAB without connection latching In-Reply-To: References: <4C48F2A6-FDBA-43B7-915E-B92AE7D0BE33@nomadiclab.com> <20051205183624.GQ21090@binky.Central.Sun.COM> Message-ID: At 2:29 PM -0500 12/5/05, Sam Hartman wrote: > >>>>> "Nicolas" == Nicolas Williams writes: > > Nicolas> On Mon, Dec 05, 2005 at 11:36:27AM -0500, Stephen Kent > Nicolas> wrote: > >> I'll just note that 2401bis (soon to be issued as 4301, yeah!) > >> adopts a processing model that relies on decorrelation to > >> simplify and speed up processing in SG and BITW > >> implementations. Making frequent changes to the SPD, as > >> suggested in your message, may be computationally costly. > > Nicolas> Even when done only on BITS or native implementations? > >As I understand it, it is an optimization any IPsec implementation may >choose to use. As best I can tell the text is constructed so that it >is purely a performance issue. So, you can choose to do it in your >implementation; lookups get faster and changes get slower. > > > >You could presumably choose to do anything else provided that it was >externally the same. You are correct. Steve From hartmans-ietf at mit.edu Mon Dec 5 13:32:59 2005 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Mon, 05 Dec 2005 16:32:59 -0500 Subject: [anonsec] SAB without connection latching In-Reply-To: (Stephen Kent's message of "Mon, 5 Dec 2005 13:42:22 -0500") References: <4C48F2A6-FDBA-43B7-915E-B92AE7D0BE33@nomadiclab.com> Message-ID: >>>>> "Stephen" == Stephen Kent writes: Stephen> At 12:13 PM -0500 12/5/05, Sam Hartman wrote: >> >>>>> "Stephen" == Stephen Kent writes: >> Stephen> I'll just note that 2401bis (soon to be issued as 4301, Stephen> yeah!) adopts a processing model that relies on Stephen> decorrelation to simplify and speed up processing in SG Stephen> and BITW implementations. Making frequent changes to the Stephen> SPD, as suggested in your message, may be computationally Stephen> costly. >> >> >> noted. do you have any other approaches you think we should >> look at? >> >> --Sam Stephen> I think David's suggestion, to manage the inactivity Stephen> timeout via the SAD, vs. the SPD, might be good. Ok. I thought I tried to be clear I was talking about what I wanted to accomplish not about how we actually accomplish. it. I'd rather not get stuck on details of where the inactivity timer goes at this point and I'm sorry I included details that were not required in my talking peace. --Sam From touch at ISI.EDU Mon Dec 5 15:00:02 2005 From: touch at ISI.EDU (Joe Touch) Date: Mon, 05 Dec 2005 15:00:02 -0800 Subject: [anonsec] 2401bis vs 2401 In-Reply-To: References: <4344B8E1.7090807@isi.edu> Message-ID: <4394C672.1040802@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sam Hartman wrote: >>>>>>"Joe" == Joe Touch writes: > > > Joe> If 2401bis is strictly required (vs. 2401), it might be > Joe> useful to adjust the title (not sure, though). I'd prefer if > Joe> there were a way to refer to 2401 processing, even if in an > Joe> appendix, though I don't know if that's feasible. > > Hi. I've been working with Nico on trying to understand the > implications of his draft for 2401bis. I've also been following the > Kink working group's efforts to work with both 2401bis and 2401. > > My reasonably strong belief is that we have to do more than twice the > work if we want to support both 2401bis and 2401. we need to do the > analysis separately for each model (they are that different) and we > then need to make sure the results are consistent. > > We must support 2401bis. I argue that we should not spend effort on > 2401. BTNS affects the SPD in 2401/2401bis in similar ways (and not much else); it's not clear that there will be double the effort required to address both (as is the case with KINK). It'd be useful to understand that before abandoning 2401. > I understand David's concerns WRT iscsi and IKE V1. I don't think > only thinking about the 2401bis architecture precludes IKE V1 from > being considered. It seems like 2401bis refers only to IKEv2 (end sec 3.2 of 2401bis). Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDlMZyE5f5cImnZrsRAqyrAKCuOzSL5ba71iB5W+br5/+Zk8u8QwCg9NHD Pvw3F5onD9GcTFBtPQ0vMPw= =BtfC -----END PGP SIGNATURE----- From touch at ISI.EDU Mon Dec 5 15:09:01 2005 From: touch at ISI.EDU (Joe Touch) Date: Mon, 05 Dec 2005 15:09:01 -0800 Subject: [anonsec] SAB without connection latching In-Reply-To: References: Message-ID: <4394C88D.10209@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sam Hartman wrote: > > Nico has partially described a feature called connection latching that > allows a native mode IPsec implementation to guarantee that the same > peer ID is used for every packet sent over a particular connection. > It seems fairly clear that BTNS benefits significantly from this > technology. > > The applicability statement makes the claim that BTNS protects against > on-path attacks after the connection is established. In order to do > that we need to have some form of something like connection latching > even in non-native implementations. > > If we do nothing then the SA from one BTNS peer could be replaced by a > SA from another BTNS peer and the traffic on the connection would be > funneled over that SA. Can't that happen with existing IPsec already? i.e., to replace one SA with another, signed in different ways? (different CAs, etc.) > It seems like we're going to need something like mini-leap-of-faith in > which we require that the identity of a peer remain constant for > traffic protected by a btns SA. Isn't that a requirement of existing IPsec implementations already, as per above? Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDlMiNE5f5cImnZrsRAqpsAJwNwluSOXovyEFFTPPJrc+jI7kttQCglZAi 4x2TXp+2XQzj6FoTA+0JfgM= =3mvd -----END PGP SIGNATURE----- From hartmans-ietf at mit.edu Mon Dec 5 15:35:27 2005 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Mon, 05 Dec 2005 18:35:27 -0500 Subject: [anonsec] SAB without connection latching In-Reply-To: <4394C88D.10209@isi.edu> (Joe Touch's message of "Mon, 05 Dec 2005 15:09:01 -0800") References: <4394C88D.10209@isi.edu> Message-ID: >>>>> "Joe" == Joe Touch writes: Joe> Sam Hartman wrote: >> Nico has partially described a feature called connection >> latching that allows a native mode IPsec implementation to >> guarantee that the same peer ID is used for every packet sent >> over a particular connection. It seems fairly clear that BTNS >> benefits significantly from this technology. >> >> The applicability statement makes the claim that BTNS protects >> against on-path attacks after the connection is established. >> In order to do that we need to have some form of something like >> connection latching even in non-native implementations. >> >> If we do nothing then the SA from one BTNS peer could be >> replaced by a SA from another BTNS peer and the traffic on the >> connection would be funneled over that SA. Joe> Can't that happen with existing IPsec already? i.e., to Joe> replace one SA with another, signed in different ways? Joe> (different CAs, etc.) Yes, but only when such a replacement is consistent with the PAD. I.E. in general it needs to be the same peer within the definitions of same based on trust anchors etc. >> It seems like we're going to need something like >> mini-leap-of-faith in which we require that the identity of a >> peer remain constant for traffic protected by a btns SA. Joe> Isn't that a requirement of existing IPsec implementations Joe> already, as per above? No. basically it can happen with existing IPsec implementations but is not actually a security problem for anything besides BTNS. From touch at ISI.EDU Mon Dec 5 15:59:11 2005 From: touch at ISI.EDU (Joe Touch) Date: Mon, 05 Dec 2005 15:59:11 -0800 Subject: [anonsec] SAB without connection latching In-Reply-To: References: <4394C88D.10209@isi.edu> Message-ID: <4394D44F.8030304@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sam Hartman wrote: >>>>>>"Joe" == Joe Touch writes: > > > Joe> Sam Hartman wrote: > >> Nico has partially described a feature called connection > >> latching that allows a native mode IPsec implementation to > >> guarantee that the same peer ID is used for every packet sent > >> over a particular connection. It seems fairly clear that BTNS > >> benefits significantly from this technology. > >> > >> The applicability statement makes the claim that BTNS protects > >> against on-path attacks after the connection is established. > >> In order to do that we need to have some form of something like > >> connection latching even in non-native implementations. > >> > >> If we do nothing then the SA from one BTNS peer could be > >> replaced by a SA from another BTNS peer and the traffic on the > >> connection would be funneled over that SA. > > Joe> Can't that happen with existing IPsec already? i.e., to > Joe> replace one SA with another, signed in different ways? > Joe> (different CAs, etc.) > > Yes, but only when such a replacement is consistent with the PAD. > I.E. in general it needs to be the same peer within the definitions of > same based on trust anchors etc. The PAD should be established when you connect (i.e., as a result of the IKE, rather than to verify the IKE), and leave it in place until the association is explicitly torn down. That entry would then prevent hijacking as per above the same way as any other PAD entry, right? > >> It seems like we're going to need something like > >> mini-leap-of-faith in which we require that the identity of a > >> peer remain constant for traffic protected by a btns SA. > > Joe> Isn't that a requirement of existing IPsec implementations > Joe> already, as per above? > > No. > > > basically it can happen with existing IPsec implementations but is not > actually a security problem for anything besides BTNS. The security issue seems to be whether the PAD should be modified while there are SAs open that are governed by that PAD. I didn't see whether 2401bis addressed that issue, but it seems independent of BTNS at that point. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDlNRPE5f5cImnZrsRApx1AJ48/ejW5DKuM30YDRBb0bUZz748PgCePs+K Tn9Fvx1/fQ+mWbUHqVzLO8Y= =AKMy -----END PGP SIGNATURE----- From Nicolas.Williams at sun.com Mon Dec 5 16:03:03 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 5 Dec 2005 18:03:03 -0600 Subject: [anonsec] BTNS updates Message-ID: <20051206000303.GM17884@binky.Central.Sun.COM> Sam and I met over the weekend and discussed how to spec BTNS. We read through the RFC2401bis sections on the PAD and worked this out: - We need a an SPD "BTNS OK" flag, not an "UNKNOWN" value for the name selector. - The PAD needs to allow a last entry for BTNS that matches peer IDs not matched by any other previous entry - Nodes that wish to be treated as BTNS nodes by their peers should generate a self-signed cert with a randomized DN. - Processing then works like so: - search the PAD as per-RFC2401bis, sections 4.4.3.* - if a match is found, use that PAD entry as per-RFC2401bis; failure to authenticate leads to failure[1] - if no matching entry is found and the last entry in the PAD is a BTNS entry, then authenticate the peer by verifying that the AUTH payload (in the IKEv2 case) is made with a private key corresponding to the peer's CERT CHILD SAs creation is constrained as with any other PAD entry, except that a BTNS peer ID is coerced to a "public key" ID type if the PAD entry says to search the SPD by ID. - if the peer matched the BTNS PAD entry then only SPD protect entries that have the "BTNS OK" flag will be matched We did not discuss leap-of-faith in much detail. Similarly, we did not discuss connection latching in too much detail. We did discuss channel bindings, however. Channel bindings do presume connection latching, which we did not work out in detail, but nonetheless we think that for SAs authenticated with public key signatures the channel bindings for latched connections will be the public key values of the two peers. Connection latching requires more thought. Specifically, we need to find a way to describe connection latching in RFC2401bis terms, or, if need be, specify extensions to RFC2401bis to permit the specification of connection latching. [1] Note that not allowing a fallback from a matching non-BTNS PAD entry to a BTNS PAD entry is important, particularly if the SPD would be searched by "peer IP addresses asserted in traffic selector payloads," but I think it might be OK if the BTNS PAD entry were to specify that the SPD should be searched for entries matching the special Name selector "UNKNOWN." Nico -- From Nicolas.Williams at sun.com Mon Dec 5 16:10:47 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 5 Dec 2005 18:10:47 -0600 Subject: [anonsec] SAB without connection latching In-Reply-To: <4394D44F.8030304@isi.edu> References: <4394C88D.10209@isi.edu> <4394D44F.8030304@isi.edu> Message-ID: <20051206001047.GC21090@binky.Central.Sun.COM> On Mon, Dec 05, 2005 at 03:59:11PM -0800, Joe Touch wrote: > Sam> Yes, but only when such a replacement is consistent with the PAD. > Sam> I.E. in general it needs to be the same peer within the > Sam> definitions of same based on trust anchors etc. > > The PAD should be established when you connect (i.e., as a result of the > IKE, rather than to verify the IKE), and leave it in place until the > association is explicitly torn down. That entry would then prevent > hijacking as per above the same way as any other PAD entry, right? The problem lies in "until the association is explicitly torn down." If that effectively means "forever" or "until someone complains" then that's not good. That's what would happen if the peer making the leap-of-faith PAD entry allows leap-of-faith PAD entries to be made for dynamically addressed nodes . > The security issue seems to be whether the PAD should be modified while > there are SAs open that are governed by that PAD. I didn't see whether > 2401bis addressed that issue, but it seems independent of BTNS at that > point. No, the SAs might expire due to lack of traffic, but the traffic flows might continue to exist, logically. Thus allowing the PAD entry to be removed as a result of SA expiration would be bad. Problem: How can non-native IPsec implementations know whether the associated traffic flows continue to exist? Problem: Given applications that use multiple connections between the same two peers, how can even native IPsec implementations know whether the associated traffic flows continue to exist? Nico -- From touch at ISI.EDU Mon Dec 5 16:15:47 2005 From: touch at ISI.EDU (Joe Touch) Date: Mon, 05 Dec 2005 16:15:47 -0800 Subject: [anonsec] BTNS updates In-Reply-To: <20051206000303.GM17884@binky.Central.Sun.COM> References: <20051206000303.GM17884@binky.Central.Sun.COM> Message-ID: <4394D833.1070505@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nicolas Williams wrote: > Sam and I met over the weekend and discussed how to spec BTNS. > > We read through the RFC2401bis sections on the PAD and worked this out: > > - We need a an SPD "BTNS OK" flag, not an "UNKNOWN" value for the name > selector. > > - The PAD needs to allow a last entry for BTNS that matches peer IDs > not matched by any other previous entry > > - Nodes that wish to be treated as BTNS nodes by their peers should > generate a self-signed cert with a randomized DN. > > - Processing then works like so: > > - search the PAD as per-RFC2401bis, sections 4.4.3.* > > - if a match is found, use that PAD entry as per-RFC2401bis; failure > to authenticate leads to failure[1] > > - if no matching entry is found and the last entry in the PAD is a > BTNS entry, then authenticate the peer by verifying that the AUTH > payload (in the IKEv2 case) is made with a private key > corresponding to the peer's CERT > > CHILD SAs creation is constrained as with any other PAD entry, > except that a BTNS peer ID is coerced to a "public key" ID type if > the PAD entry says to search the SPD by ID. > > - if the peer matched the BTNS PAD entry then only SPD protect > entries that have the "BTNS OK" flag will be matched > > > We did not discuss leap-of-faith in much detail. Similarly, we did not > discuss connection latching in too much detail. As per my other post, wouldn't both end up adding an entry to the PAD (call that a latching PAD entry)? That entry ought to supercede the BTNS entry. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDlNgzE5f5cImnZrsRAj27AKDpz4wXa0N+2CbNA/ryUkgwCi5T6wCgtHR0 kAgNeg4V31deBe5jXdd+840= =ZoJM -----END PGP SIGNATURE----- From touch at ISI.EDU Mon Dec 5 16:16:59 2005 From: touch at ISI.EDU (Joe Touch) Date: Mon, 05 Dec 2005 16:16:59 -0800 Subject: [anonsec] SAB without connection latching In-Reply-To: <20051206001047.GC21090@binky.Central.Sun.COM> References: <4394C88D.10209@isi.edu> <4394D44F.8030304@isi.edu> <20051206001047.GC21090@binky.Central.Sun.COM> Message-ID: <4394D87B.40507@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nicolas Williams wrote: > On Mon, Dec 05, 2005 at 03:59:11PM -0800, Joe Touch wrote: > >>Sam> Yes, but only when such a replacement is consistent with the PAD. >>Sam> I.E. in general it needs to be the same peer within the >>Sam> definitions of same based on trust anchors etc. >> >>The PAD should be established when you connect (i.e., as a result of the >>IKE, rather than to verify the IKE), and leave it in place until the >>association is explicitly torn down. That entry would then prevent >>hijacking as per above the same way as any other PAD entry, right? > > > The problem lies in "until the association is explicitly torn down." > > If that effectively means "forever" or "until someone complains" then > that's not good. > > That's what would happen if the peer making the leap-of-faith PAD entry > allows leap-of-faith PAD entries to be made for dynamically addressed > nodes . > > >>The security issue seems to be whether the PAD should be modified while >>there are SAs open that are governed by that PAD. I didn't see whether >>2401bis addressed that issue, but it seems independent of BTNS at that >>point. > > > No, the SAs might expire due to lack of traffic, but the traffic flows > might continue to exist, logically. Thus allowing the PAD entry to be > removed as a result of SA expiration would be bad. > > Problem: How can non-native IPsec implementations know whether the > associated traffic flows continue to exist? > > Problem: Given applications that use multiple connections between the > same two peers, how can even native IPsec implementations know > whether the associated traffic flows continue to exist? > > Nico Don't all these problems exist for existing PAD entries? Or is the PAD assumed static for all time? Any changes to the PAD can cause similar problems... Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDlNh7E5f5cImnZrsRAtO0AJ9gamg4PpVT4OtbiZzhzOYnf5KFCwCg5Xku +duw/4ydF4dJUF02HJqVmnw= =HXpR -----END PGP SIGNATURE----- From Nicolas.Williams at sun.com Mon Dec 5 16:21:28 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 5 Dec 2005 18:21:28 -0600 Subject: [anonsec] SAB without connection latching In-Reply-To: <4394D87B.40507@isi.edu> References: <4394C88D.10209@isi.edu> <4394D44F.8030304@isi.edu> <20051206001047.GC21090@binky.Central.Sun.COM> <4394D87B.40507@isi.edu> Message-ID: <20051206002128.GD21090@binky.Central.Sun.COM> On Mon, Dec 05, 2005 at 04:16:59PM -0800, Joe Touch wrote: > Don't all these problems exist for existing PAD entries? Maybe for some of them, but certainly not all. If you have peers asserting IP address type IDs and they have certs with iPAddress subject alternative names and you can validate said certs to some trust anchor specified in the PAD entry, then you can have a PAD entry that matches any peer asserting an IP address ID that won't have this problem. > Or is the PAD assumed static for all time? Any changes to the PAD can > cause similar problems... Yes, changes to the PAD can cause problems. Connection latching mitigates this, to some extent (i.e., not necessarily for applications that use many connections between two peers). Nico -- From touch at ISI.EDU Mon Dec 5 16:36:05 2005 From: touch at ISI.EDU (Joe Touch) Date: Mon, 05 Dec 2005 16:36:05 -0800 Subject: [anonsec] Comments on applicability statement In-Reply-To: <20050810013028.CB318E0049@carter-zimmerman.mit.edu> References: <20050810013028.CB318E0049@carter-zimmerman.mit.edu> Message-ID: <4394DCF5.2040107@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sam (et al.), Below is a summary of how we addressed your feedback from 8/9/2005 on the draft-ietf-btns-prob-and-applic-00.txt. Let us know if any of these issues should remain open. This refers to feedback on 00 as applied to 01. Pending updates (open issues) are noted as [PENDING UPDATE #...] FYI, updates 1-7 address private feedback from the first round by others. Joe - ---- Summary of pending updates from this email: #8 replicate applicability statement for SAB and CBB #9 address IKE vs. CBB comparative strength (number of vulnerabilities, level of protection provided) #10 clarify S-CBB self-signed SSL example (host in URL matches host in certificate) #11 clarify HTTPS and channel binding example #12 Sec 4 (now 5 in v01) replicates disussion; is there a better way to handle this? #13 Sec 5.3 (now 4.2 in v01) should use ssh rather than SSL as leap of faith (examine and address) #14 Sec 5.2 (now 4.2 in v01) discusses leap-of-faith need to discuss this on the list further (as per discussions in Vancouver) - ---- Sam Hartman wrote: > Overall I think the document is fairly good. I do have a few comments > I am submitting as an individual. > > Large concerns: > > Section 3. Please sjeparate the applicability statement for SAB and > CBB even if you need to duplicate text. I think this will make it > much cleaner to evaluate when considering whether protocols meet the > applicability statement. We had debated whether we agreed this was useful to do, but now concur it probably is, esp. regarding applicability to upper layer protocols. [PENDING UPDATE #8] > I don't tend to agree with the assertion that IKE is stronger than > CBB. That depends entirely on what's going on; I can think of > situations where CBB is stronger and situations where IKE is stronger. I believe we had addressed this in -01. The term "strong" was removed because the table was not intended as a comparison of "strength" which as I understood was mostly used in comparing cryptographic algorithms. The subsequent paragraph we attempted to qualify the comparison: (from -01, right before 3.1.1) "The following is a discussion of each of these use cases. Vulnerabilities and benefits are discussed in later subsections of this section separately. The labels in the table are organized by the least authenticated side, where SAB is the least secure because it uses no authentication, CBB is more secure because it uses authentication external to IPsec, and IKE is the most secure because it relies on integrated authentication. Note that the measure of least/most secure is based solely on the integration of authentication in these labels, and does not consider the comparative strength of various authentication algorithms." We're currently deveoping a further revision to address exactly how IPsec and CBB would differ in terms of the protections provided. [PENDING UPDATE #9] > I don't understand how s-cbb has anything to do with self-signed certs > and websites. There are two ways to interpret how self-signed certificates work in websites. In one case, they're self-signed and unchecked. However, most implementations require that the application allow the override to accept the self-signed certificate. There's no difference between the application 'deciding to allow all unsigned certs' (as a webserver typically does) and the application asking the user to check the contents of the certificiate manually. In both cases, the lower layer is asking the upper layer to accept the certificate; the lower layer has no way of knowing how deep the upper layer inspection was. This is NOT the same as just accepting the unsigned certificate at the lower layer. I.e., the host in the URL is required to match the domain in the certificate. (this should be made more clear than the 00-01 update provided) [PENDING UPDATE #10] > I actually don't understand how https is similar to cbb at all in that > there is no channel binding. The binding occurs at the socket layer; even though there is no official API, one has been implemented that allows the verification exchange. [Part of PENDING UPDATE #10] > I'm not sure that section 3.1 makes a good applicability statement. > In particular, it does not easily answer the two questions I would > expect from an applicability statement. As an operator considering > deploying BTNS, is BTNS appropriate for my use case. As a protocol > designer considering relying on BTNS, is BTNS appropriate for my > needs? I wonder whether we really need to break out all the > asymmetric cases. Instead I think it might be useful to focus on the > capabilities of a peer. That way you would need to describe when it > is acceptable to set up an association with an anonymous peer (SAB > applicability statement) and when it is acceptable to set up an > association to a peer you will bind at a higher layer (CBB > applicability statement). Added sec 3.4 to address this point - perhaps that should be the 'applicability statement' section? We also probably need to change the title of section 3.3 to something like "modes of BTNS" rather than 'uses'. [PENDING UPDATE #11] > Section 4 seems to duplicate a lot of the content I would expect to see in section 3. (note - section 4 is now section 5 in 01) It is intended to provide a summary, rather than a duplication. Is there a better way to address this? [PENDING UPDATE #12] > Section 5.3 . (note - section 5.3 is now 4.2 in 01) > I think ssh is a better example for leap of faith than > ssl. Agreed - this mod fell off the list with the section renumbering; it will be fixed in 01. [PENDING ISSUE #13] > Section 5.3 should either rule this extension in scope or out of > scope. Currently it just mentions the extension but takes no > position. Good question - we'll take that to the list, and leave it as a pending issue for now. [PENDING ISSUE #14] > A bunch of small things: > > TLS not SSL in description of https. Done. > In section 1.1 it seems odd to say that we use IPsec both because it is widely deployed and is facing deployment challenges. Done. > I don't understand why the definition of CBB and SAB belongs in 1.1; > it seems like we want a section break between the assumptions and the > description of the two modes of operation. It's not intended as a definition, but to foreshadow. We don't describe or define the terms, just the acronyms. > Please cite a definition for DOS, DDOS and flash crowd. We're not sure these are needed; they seem to be ubiquitous terms in the both the security community and elsewhere, and this is not intended to be an introduction to network security issues. - ----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDlNz0E5f5cImnZrsRArJtAJ4gT6dnabIRMUaIsYcJNLqYnuCTWgCgpded op29xhid3zvLYpOidfOWNek= =Dj2K -----END PGP SIGNATURE----- From Nicolas.Williams at sun.com Mon Dec 5 18:49:43 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 5 Dec 2005 20:49:43 -0600 Subject: [anonsec] BTNS updates In-Reply-To: <4394D833.1070505@isi.edu> References: <20051206000303.GM17884@binky.Central.Sun.COM> <4394D833.1070505@isi.edu> Message-ID: <20051206024942.GE21090@binky.Central.Sun.COM> On Mon, Dec 05, 2005 at 04:15:47PM -0800, Joe Touch wrote: > Nicolas Williams wrote: > > We did not discuss leap-of-faith in much detail. Similarly, we did not > > discuss connection latching in too much detail. > > As per my other post, wouldn't both end up adding an entry to the PAD > (call that a latching PAD entry)? That entry ought to supercede the BTNS > entry. We did discuss this for leap-of-faith at IETF64. I had not considered this approach for connection latching. But it sounds plausible, with a reference count on the PAD entry, so each latched connection holds a reference and the PAD entry is removed when the reference count falls to zero. Matching SPD entries would be added/removed dynamically as well as connections are latched/closed. Yes, seems workable. Nico -- From touch at ISI.EDU Tue Dec 6 09:05:46 2005 From: touch at ISI.EDU (Joe Touch) Date: Tue, 06 Dec 2005 09:05:46 -0800 Subject: [anonsec] SAB without connection latching In-Reply-To: <20051204204127.GG21090@binky.Central.Sun.COM> References: <20051204204127.GG21090@binky.Central.Sun.COM> Message-ID: <4395C4EA.3040800@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nicolas Williams wrote: > On Sun, Dec 04, 2005 at 10:47:59AM -0500, Sam Hartman wrote: > >>The applicability statement makes the claim that BTNS protects against >>on-path attacks after the connection is established. In order to do > ^^ > off-path, not on-path. If the applicability statement says "on-path" > then that's got to be a mistake. It's not a mistake. > And passive attacks. > > To protect against more active attacks requires additional features, > such as connection latching and channel binding, or, where workable, > leap-of-faith. > > Nico That seems true for any IPsec connection, e.g., in 2401bis when the PAD changes during a connection. I have been presuming 'connection latching' - - where the PAD cannot change during a connection and where BTNS would update the PAD once the connection is established. Leap-of-faith addresses something different - where the PAD entries persist between a series of connections, or are shared among connections to the same endpoint. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDlcTqE5f5cImnZrsRAqrpAJ9CA5RefblvDd5OWBod3mvNdep7ogCcDCN0 jnFR2J2fmhewU7Xa/AT3e1s= =SYRp -----END PGP SIGNATURE----- From hartmans-ietf at mit.edu Tue Dec 6 09:15:47 2005 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Tue, 06 Dec 2005 12:15:47 -0500 Subject: [anonsec] SAB without connection latching In-Reply-To: <4395C4EA.3040800@isi.edu> (Joe Touch's message of "Tue, 06 Dec 2005 09:05:46 -0800") References: <20051204204127.GG21090@binky.Central.Sun.COM> <4395C4EA.3040800@isi.edu> Message-ID: >>>>> "Joe" == Joe Touch writes: Joe> presuming 'connection latching' - where the PAD cannot change Joe> during a connection and where BTNS would update the PAD once Joe> the connection is established. Joe, it's not quite that simple. Please take a look at the definition of the PAD; it is quite complicated. Also, propose a mechanism for determining how long a connection exists. Then propose updates to Nico's mechanism to support this once he posts our notes. I do believe there is a solution in there somewhere but I also believe you are glossing over critical details necessary to make it actually work. From touch at ISI.EDU Tue Dec 6 09:24:01 2005 From: touch at ISI.EDU (Joe Touch) Date: Tue, 06 Dec 2005 09:24:01 -0800 Subject: [anonsec] SAB without connection latching In-Reply-To: References: <20051204204127.GG21090@binky.Central.Sun.COM> <4395C4EA.3040800@isi.edu> Message-ID: <4395C931.6060702@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sam Hartman wrote: >>>>>>"Joe" == Joe Touch writes: > > > Joe> presuming 'connection latching' - where the PAD cannot change > Joe> during a connection and where BTNS would update the PAD once > Joe> the connection is established. > > Joe, it's not quite that simple. Please take a look at the definition > of the PAD; it is quite complicated. Also, propose a mechanism for > determining how long a connection exists. > > Then propose updates to Nico's mechanism to support this once he posts > our notes. > > I do believe there is a solution in there somewhere but I also believe > you are glossing over critical details necessary to make it actually > work. The details I'm glossing over are the ones I'm presuming exist for conventional IPsec use. Otherwise, what prevents the PAD from changing during a connection, and the resulting authentication for an endpoint from being in flux? If these details aren't already there, then there is certainly a large amount of work to be done - but it is not BTNS-specific. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDlckxE5f5cImnZrsRAoZLAKCtFJA7hey+LvqBePc5rEY3vv8D+gCgthak B+mDsCiKRZ6mvJI8jNSN2eQ= =u0sy -----END PGP SIGNATURE----- From hartmans-ietf at mit.edu Tue Dec 6 09:30:50 2005 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Tue, 06 Dec 2005 12:30:50 -0500 Subject: [anonsec] SAB without connection latching In-Reply-To: <4395C931.6060702@isi.edu> (Joe Touch's message of "Tue, 06 Dec 2005 09:24:01 -0800") References: <20051204204127.GG21090@binky.Central.Sun.COM> <4395C4EA.3040800@isi.edu> <4395C931.6060702@isi.edu> Message-ID: >>>>> "Joe" == Joe Touch writes: Joe> Otherwise, what prevents the PAD from changing during a Joe> connection, and the resulting authentication for an endpoint Joe> from being in flux? 1) The PAD is assumed to be more or less static except under the control of the admin. 2) It *can* change and the authentication can be in flux. This isn't really a problem for traditionnal IPsec. --Sam From Nicolas.Williams at sun.com Tue Dec 6 09:32:04 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 6 Dec 2005 11:32:04 -0600 Subject: [anonsec] SAB without connection latching In-Reply-To: <4395C931.6060702@isi.edu> References: <20051204204127.GG21090@binky.Central.Sun.COM> <4395C4EA.3040800@isi.edu> <4395C931.6060702@isi.edu> Message-ID: <20051206173204.GH21090@binky.Central.Sun.COM> On Tue, Dec 06, 2005 at 09:24:01AM -0800, Joe Touch wrote: > Sam Hartman wrote: > >>>>>>"Joe" == Joe Touch writes: > > > > > > Joe> presuming 'connection latching' - where the PAD cannot change > > Joe> during a connection and where BTNS would update the PAD once > > Joe> the connection is established. > > > > Joe, it's not quite that simple. Please take a look at the definition > > of the PAD; it is quite complicated. Also, propose a mechanism for > > determining how long a connection exists. > > > > Then propose updates to Nico's mechanism to support this once he posts > > our notes. > > > > I do believe there is a solution in there somewhere but I also believe > > you are glossing over critical details necessary to make it actually > > work. > > The details I'm glossing over are the ones I'm presuming exist for > conventional IPsec use. > > Otherwise, what prevents the PAD from changing during a connection, and > the resulting authentication for an endpoint from being in flux? > > If these details aren't already there, then there is certainly a large > amount of work to be done - but it is not BTNS-specific. The PAD isn't enough to perform a binding, I think, because it isn't a requirement that PAD entries not overlap w.r.t. CHILD SA selector constraints. From touch at ISI.EDU Tue Dec 6 09:48:14 2005 From: touch at ISI.EDU (Joe Touch) Date: Tue, 06 Dec 2005 09:48:14 -0800 Subject: [anonsec] SAB without connection latching In-Reply-To: References: <20051204204127.GG21090@binky.Central.Sun.COM> <4395C4EA.3040800@isi.edu> <4395C931.6060702@isi.edu> Message-ID: <4395CEDE.6080707@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sam Hartman wrote: >>>>>>"Joe" == Joe Touch writes: > > > > Joe> Otherwise, what prevents the PAD from changing during a > Joe> connection, and the resulting authentication for an endpoint > Joe> from being in flux? > > 1) The PAD is assumed to be more or less static except under the > control of the admin. I didn't find any discussion of that in 2401bis. That seems like a substantial security issue (as per below). > 2) It *can* change and the authentication can be in flux. This isn't > really a problem for traditionnal IPsec. That would allow hijacking, just as with BTNS. An existing SA could could be torn down or modified by an IKE authenticated in a different way than the original SA. That would then permit hijacking. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDlc7eE5f5cImnZrsRAkoEAKCXO7y1mgXx8F2oB8CrQ31LpjqZdwCfcW1W Gna+4CGhtSVf3scDdO4aXDI= =GY7h -----END PGP SIGNATURE----- From kent at bbn.com Tue Dec 6 09:51:55 2005 From: kent at bbn.com (Stephen Kent) Date: Tue, 6 Dec 2005 12:51:55 -0500 Subject: [anonsec] SAB without connection latching In-Reply-To: <4395C931.6060702@isi.edu> References: <20051204204127.GG21090@binky.Central.Sun.COM> <4395C4EA.3040800@isi.edu> <4395C931.6060702@isi.edu> Message-ID: >... > >The details I'm glossing over are the ones I'm presuming exist for >conventional IPsec use. > >Otherwise, what prevents the PAD from changing during a connection, and >the resulting authentication for an endpoint from being in flux? > >If these details aren't already there, then there is certainly a large >amount of work to be done - but it is not BTNS-specific. > >Joe > Joe, The PAD was designed to fill a gap between the authorization data that IKE deals with, and the SPD, and to fill in gaps in the standards dealing with management of IKE authorization data. When I developed the PAD, in response to discussions in the pki4ipsec WG, nobody suggested that the PAD would be other than slowly changing. SA don't last forever, so if we assume a slowly changing PAD (very static in many contexts), then there was no need to worry about these issues. Hence no provisions were made to accommodate the implications of such changes on extant SAs. Steve From touch at ISI.EDU Tue Dec 6 09:55:11 2005 From: touch at ISI.EDU (Joe Touch) Date: Tue, 06 Dec 2005 09:55:11 -0800 Subject: [anonsec] BTNS updates In-Reply-To: <20051206024942.GE21090@binky.Central.Sun.COM> References: <20051206000303.GM17884@binky.Central.Sun.COM> <4394D833.1070505@isi.edu> <20051206024942.GE21090@binky.Central.Sun.COM> Message-ID: <4395D07F.70400@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nicolas Williams wrote: > On Mon, Dec 05, 2005 at 04:15:47PM -0800, Joe Touch wrote: > >>Nicolas Williams wrote: >> >>>We did not discuss leap-of-faith in much detail. Similarly, we did not >>>discuss connection latching in too much detail. >> >>As per my other post, wouldn't both end up adding an entry to the PAD >>(call that a latching PAD entry)? That entry ought to supercede the BTNS >>entry. > > > We did discuss this for leap-of-faith at IETF64. > > I had not considered this approach for connection latching. But it > sounds plausible, with a reference count on the PAD entry, so each > latched connection holds a reference and the PAD entry is removed when > the reference count falls to zero. Matching SPD entries would be > added/removed dynamically as well as connections are latched/closed. > > Yes, seems workable. > > Nico FWIW, the same approach SHOULD be used for conventional PAD entries - no modification while the reference count is non-zero. Actually, given the problems with the reference count, as well as the potential for entries above (ealier in the PAD) to be added which could override, it seems like the PAD information MUST be copied into the SAD when the connection is established, and only _that_ entry verified when incoming packets warrant (e.g., before taking actions that change the SA). Again, this would apply to both conventional and BTNS IPsec. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDldB/E5f5cImnZrsRAr3YAJ4qK6e9Wm8mMlDYsjcap/Iuw4wrtwCgv52c PYvx+8T/ExuQlSaZc0Gp2m8= =jH3C -----END PGP SIGNATURE----- From Nicolas.Williams at sun.com Tue Dec 6 10:07:52 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 6 Dec 2005 12:07:52 -0600 Subject: [anonsec] BTNS updates In-Reply-To: <4395D07F.70400@isi.edu> References: <20051206000303.GM17884@binky.Central.Sun.COM> <4394D833.1070505@isi.edu> <20051206024942.GE21090@binky.Central.Sun.COM> <4395D07F.70400@isi.edu> Message-ID: <20051206180752.GJ21090@binky.Central.Sun.COM> On Tue, Dec 06, 2005 at 09:55:11AM -0800, Joe Touch wrote: > FWIW, the same approach SHOULD be used for conventional PAD entries - no > modification while the reference count is non-zero. > > Actually, given the problems with the reference count, as well as the > potential for entries above (ealier in the PAD) to be added which could > override, it seems like the PAD information MUST be copied into the SAD > when the connection is established, and only _that_ entry verified when > incoming packets warrant (e.g., before taking actions that change the SA). I'm not sure, but I think a proper connection latch or leap-of-faith binding may have to be effected through all the databases -- PAD, SAD and SPD. For connection latching, in particular, I don't see how the SPD can be avoided. Note too that connection latching requires native IPsec -- it involves cooperation of the ULPs. > Again, this would apply to both conventional and BTNS IPsec. Agreed. Connection latching pre-dates BTNS for a reason, I'm sure :) From touch at ISI.EDU Tue Dec 6 10:10:55 2005 From: touch at ISI.EDU (Joe Touch) Date: Tue, 06 Dec 2005 10:10:55 -0800 Subject: [anonsec] SAB without connection latching In-Reply-To: References: <20051204204127.GG21090@binky.Central.Sun.COM> <4395C4EA.3040800@isi.edu> <4395C931.6060702@isi.edu> Message-ID: <4395D42F.1080102@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen Kent wrote: > >> ... >> >> The details I'm glossing over are the ones I'm presuming exist for >> conventional IPsec use. >> >> Otherwise, what prevents the PAD from changing during a connection, and >> the resulting authentication for an endpoint from being in flux? >> >> If these details aren't already there, then there is certainly a large >> amount of work to be done - but it is not BTNS-specific. >> >> Joe >> > Joe, > > The PAD was designed to fill a gap between the authorization data that > IKE deals with, and the SPD, and to fill in gaps in the standards > dealing with management of IKE authorization data. When I developed the > PAD, in response to discussions in the pki4ipsec WG, nobody suggested > that the PAD would be other than slowly changing. SA don't last forever, > so if we assume a slowly changing PAD (very static in many contexts), > then there was no need to worry about these issues. Hence no provisions > were made to accommodate the implications of such changes on extant SAs. > > Steve Hi, Steve, While I understand an appreciate this, even 'slowly changing' allows for change, and change allows a new entity with different authoriziation credentials to affect active SAs. Is it possible to copy the relevent PAD info used to authorize establishment of the SA into the SA itself, so that such changes could not be used maliciously? Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDldQvE5f5cImnZrsRAnr+AKC33e3KqOuD4FO4qFcc8ZqYfFa5UACfWQpo NI7RoEe0h4UD6/cVHlFpygo= =QBtf -----END PGP SIGNATURE----- From kent at bbn.com Wed Dec 7 06:50:06 2005 From: kent at bbn.com (Stephen Kent) Date: Wed, 7 Dec 2005 09:50:06 -0500 Subject: [anonsec] SAB without connection latching In-Reply-To: <20051206173204.GH21090@binky.Central.Sun.COM> References: <20051204204127.GG21090@binky.Central.Sun.COM> <4395C4EA.3040800@isi.edu> <4395C931.6060702@isi.edu> <20051206173204.GH21090@binky.Central.Sun.COM> Message-ID: At 11:32 AM -0600 12/6/05, Nicolas Williams wrote: >On Tue, Dec 06, 2005 at 09:24:01AM -0800, Joe Touch wrote: >> Sam Hartman wrote: >> >>>>>>"Joe" == Joe Touch writes: >> > >> > >> > Joe> presuming 'connection latching' - where the PAD cannot change >> > Joe> during a connection and where BTNS would update the PAD once >> > Joe> the connection is established. >> > >> > Joe, it's not quite that simple. Please take a look at the definition >> > of the PAD; it is quite complicated. Also, propose a mechanism for >> > determining how long a connection exists. >> > >> > Then propose updates to Nico's mechanism to support this once he posts >> > our notes. >> > >> > I do believe there is a solution in there somewhere but I also believe >> > you are glossing over critical details necessary to make it actually >> > work. >> >> The details I'm glossing over are the ones I'm presuming exist for >> conventional IPsec use. >> >> Otherwise, what prevents the PAD from changing during a connection, and >> the resulting authentication for an endpoint from being in flux? >> >> If these details aren't already there, then there is certainly a large >> amount of work to be done - but it is not BTNS-specific. > >The PAD isn't enough to perform a binding, I think, because it isn't a >requirement that PAD entries not overlap w.r.t. CHILD SA selector >constraints. Yes, that is a valid concern relative to the current spec. When I suggested text (a few months ago) for a simple modification to the PAD to accommodate BTNS-style functionality, I believe I noted the requirement that PAD entries for BTNS peers must be checked to avoid overlap with both BTNS and non-BTNS peers. I may be able to find that text again, if needed. Steve From kent at bbn.com Wed Dec 7 06:49:47 2005 From: kent at bbn.com (Stephen Kent) Date: Wed, 7 Dec 2005 09:49:47 -0500 Subject: [anonsec] SAB without connection latching In-Reply-To: <4395D42F.1080102@isi.edu> References: <20051204204127.GG21090@binky.Central.Sun.COM> <4395C4EA.3040800@isi.edu> <4395C931.6060702@isi.edu> <4395D42F.1080102@isi.edu> Message-ID: Joe, >... > > Joe, >> >> The PAD was designed to fill a gap between the authorization data that >> IKE deals with, and the SPD, and to fill in gaps in the standards >> dealing with management of IKE authorization data. When I developed the >> PAD, in response to discussions in the pki4ipsec WG, nobody suggested >> that the PAD would be other than slowly changing. SA don't last forever, >> so if we assume a slowly changing PAD (very static in many contexts), >> then there was no need to worry about these issues. Hence no provisions >> were made to accommodate the implications of such changes on extant SAs. >> >> Steve > >Hi, Steve, > >While I understand an appreciate this, even 'slowly changing' allows for >change, and change allows a new entity with different authoriziation >credentials to affect active SAs. The 4301 (nee 2401bis) text does not say that the SAD or SPD-S cache should be searched and affected entries reverified when a PAD entry changes. This is in contrast to the SPD, where 4.4.1 notes that SPD changes SHOULD cause a recheck of active SAs and allow an admin to specify whether affected SAs should persist or be deleted. In part the different is a result of the fact that changes to PAD entries can affect attributes of an IKE peer that need not have any effect on extant SAs. For example, if I change the IKE ID or the authentication credentials for a peer, or the gateway location info, that need not imply a need to recheck child SAs created relative to that peer. Only if the change is to the child SA ID/address constraints (relative to SPD matching) might it make sense to consider revalidation of extant SAs. What if a new PAD entry is created? Because the PAD is ordered, it could be very complex to determine if a newly created entry affects extant SAs, or if it were even the intent of the change to affect them. These considerations, plus the notion that the PAD is fairly static, caused us to not include text analogous to the SPD text in 4.4.1. Section 4.4.3.4 describes when the PAD is consulted. It is consulted during the initial IKE exchange, in support of IKE peer authentication and child SA constraints checking. It is also consulted during subsequent CREATE_CHILD_SA exchanges, for child SA constraints checking. If an extant SA needs to be rekeyed, IKE is invoked to effect the rekey. The PAD should be checked as a side effect of creating a child SA, and because a rekey creates a new child SA, the (current) PAD should be checked at that time. So in that sense, a change to the PAD, in terms of a modification to a PAD entry, has an opportunity to affect an extant SA (when it is rekeyed). There is some ambiguity here, in that the text does not say how to recheck the PAD for subsequent CREATE_CHILD_SA exchanges. If an implementation maintains a back pointer to the PAD from each IKE SA, and a back pointer to the IKE SA from each child SA, then rechecking the PAD for a rekey is easy. But what if the IKE SA has been deleted? The PAD is not designed to be searched based on traffic selectors for child SAs, but rather on IKE IDs. I assume this is the sort of complexity that Sam had in mind when he said that use of a dynamic PAD requires a lot of thought. >Is it possible to copy the relevent PAD info used to authorize >establishment of the SA into the SA itself, so that such changes could >not be used maliciously? Changes to the PAD are made by an authorized admin, just like changes to the SPD. So I don't think the term "malicious" applies here. Steve From Nicolas.Williams at sun.com Wed Dec 7 06:54:08 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 7 Dec 2005 08:54:08 -0600 Subject: [anonsec] SAB without connection latching In-Reply-To: References: <20051204204127.GG21090@binky.Central.Sun.COM> <4395C4EA.3040800@isi.edu> <4395C931.6060702@isi.edu> <20051206173204.GH21090@binky.Central.Sun.COM> Message-ID: <20051207145408.GE21090@binky.Central.Sun.COM> On Wed, Dec 07, 2005 at 09:50:06AM -0500, Stephen Kent wrote: > At 11:32 AM -0600 12/6/05, Nicolas Williams wrote: > >The PAD isn't enough to perform a binding, I think, because it isn't a > >requirement that PAD entries not overlap w.r.t. CHILD SA selector > >constraints. > > Yes, that is a valid concern relative to the current spec. > > When I suggested text (a few months ago) for a simple modification to > the PAD to accommodate BTNS-style functionality, I believe I noted > the requirement that PAD entries for BTNS peers must be checked to > avoid overlap with both BTNS and non-BTNS peers. I may be able to > find that text again, if needed. Keep in mind Joe's point that this is a problem for IPsec even without BTNS in the picture. A PAD entry that allows road warriors access to dynamically allocated addresses will allow road warriors to steal each other's traffic in the same way as we've discussed could happen with BTNS. Nico -- From Nicolas.Williams at sun.com Wed Dec 7 08:37:36 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 7 Dec 2005 10:37:36 -0600 Subject: [anonsec] SAB without connection latching In-Reply-To: <20051207145408.GE21090@binky.Central.Sun.COM> References: <20051204204127.GG21090@binky.Central.Sun.COM> <4395C4EA.3040800@isi.edu> <4395C931.6060702@isi.edu> <20051206173204.GH21090@binky.Central.Sun.COM> <20051207145408.GE21090@binky.Central.Sun.COM> Message-ID: <20051207163736.GH21090@binky.Central.Sun.COM> On Wed, Dec 07, 2005 at 08:54:08AM -0600, Nicolas Williams wrote: > On Wed, Dec 07, 2005 at 09:50:06AM -0500, Stephen Kent wrote: > > At 11:32 AM -0600 12/6/05, Nicolas Williams wrote: > > >The PAD isn't enough to perform a binding, I think, because it isn't a > > >requirement that PAD entries not overlap w.r.t. CHILD SA selector > > >constraints. > > > > Yes, that is a valid concern relative to the current spec. > > > > When I suggested text (a few months ago) for a simple modification to > > the PAD to accommodate BTNS-style functionality, I believe I noted > > the requirement that PAD entries for BTNS peers must be checked to > > avoid overlap with both BTNS and non-BTNS peers. I may be able to > > find that text again, if needed. > > Keep in mind Joe's point that this is a problem for IPsec even without > BTNS in the picture. A PAD entry that allows road warriors access to > dynamically allocated addresses will allow road warriors to steal each > other's traffic in the same way as we've discussed could happen with > BTNS. Also, creating {IP, ID} bindings through a dynamic PAD is a DoS attack vector and key rollover issues, as discussed at IETF64. Addressing the DoS problem requires cooperation from other infrastructure (e.g., DHCP servers) or idle timeouts (as discussed at IETF64, but also through reference counts on binding PAD entries representing references from outstanding connection-latched packet flows, as discussed on the list recently). Addressing the key rollover issues requires KE extensions. The Solaris connection latching approach seems like a trade-off by creating such bindings only per-connection 5-tuples -- thus, essentially, 7-tuples: {src IP, dst IP, src ID, dst ID, protocol, src port, dst port} -- at the cost of possibly exposing applications that use multiple connections between two peers. (Bill surely will correct me if I'm wrong.) Nico -- From kent at bbn.com Wed Dec 7 14:05:51 2005 From: kent at bbn.com (Stephen Kent) Date: Wed, 7 Dec 2005 17:05:51 -0500 Subject: [anonsec] SAB without connection latching In-Reply-To: <20051207145408.GE21090@binky.Central.Sun.COM> References: <20051204204127.GG21090@binky.Central.Sun.COM> <4395C4EA.3040800@isi.edu> <4395C931.6060702@isi.edu> <20051206173204.GH21090@binky.Central.Sun.COM> <20051207145408.GE21090@binky.Central.Sun.COM> Message-ID: At 8:54 AM -0600 12/7/05, Nicolas Williams wrote: >On Wed, Dec 07, 2005 at 09:50:06AM -0500, Stephen Kent wrote: >> At 11:32 AM -0600 12/6/05, Nicolas Williams wrote: >> >The PAD isn't enough to perform a binding, I think, because it isn't a >> >requirement that PAD entries not overlap w.r.t. CHILD SA selector >> >constraints. >> >> Yes, that is a valid concern relative to the current spec. >> >> When I suggested text (a few months ago) for a simple modification to >> the PAD to accommodate BTNS-style functionality, I believe I noted >> the requirement that PAD entries for BTNS peers must be checked to >> avoid overlap with both BTNS and non-BTNS peers. I may be able to >> find that text again, if needed. > >Keep in mind Joe's point that this is a problem for IPsec even without >BTNS in the picture. A PAD entry that allows road warriors access to >dynamically allocated addresses will allow road warriors to steal each >other's traffic in the same way as we've discussed could happen with >BTNS. I don't think this discussion has provided a good example to illustrate the problem in question. I'm guessing that the concern begins with the notion that one needs to dynamically update or create a PAD entry to accommodate road warriors. However, there has been no discussion in IPsec to suggest that dynamic PAD entries are needed to support road warriors. A PAD entry might identify the set of all road warriors for a company by a wild card name, e.g., *@bbn.com. The authorization data for the entry might say that these individuals have certs that can be validated using the CA cert for BBN. The entry would also specify that the IKE ID (not the road warrior's source address) be used for SPD matching. The SPD entry for these folks would be tagged with the name. Section 4.4.1.1 specifically gives the road warrior case as a motivation for the use of names to specify SPD entries, and says how to take the IP address of the road warrior (as the initiator) and use it as the remote address for the SPD entry (in a sort of PFP fashion). This should avoid the hijacking concern alluded to above. Mike Richardson discussed how 2401 implementations (the PAD concept was not part of the old standard) supported road warriors, in the BTNS meeting at IETF64. Mike, how do you envision using a PAD-equipped IPsec to accommodate road warriors? Do you see a need for dynamic PAD entries? Steve From hartmans-ietf at mit.edu Wed Dec 7 15:20:51 2005 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Wed, 07 Dec 2005 18:20:51 -0500 Subject: [anonsec] 3401 and highjacking In-Reply-To: (Stephen Kent's message of "Wed, 7 Dec 2005 17:05:51 -0500") References: <20051204204127.GG21090@binky.Central.Sun.COM> <4395C4EA.3040800@isi.edu> <4395C931.6060702@isi.edu> <20051206173204.GH21090@binky.Central.Sun.COM> <20051207145408.GE21090@binky.Central.Sun.COM> Message-ID: >>>>> "Stephen" == Stephen Kent writes: Stephen> A PAD entry might identify the set of all road warriors Stephen> for a company by a wild card name, e.g., *@bbn.com. The Stephen> authorization data for the entry might say that these Stephen> individuals have certs that can be validated using the CA Stephen> cert for BBN. The entry would also specify that the IKE Stephen> ID (not the road warrior's source address) be used for Stephen> SPD matching. The SPD entry for these folks would be Stephen> tagged with the name. Section 4.4.1.1 specifically gives Stephen> the road warrior case as a motivation for the use of Stephen> names to specify SPD entries, and says how to take the IP Stephen> address of the road warrior (as the initiator) and use it Stephen> as the remote address for the SPD entry (in a sort of PFP Stephen> fashion). This should avoid the hijacking concern alluded Stephen> to above. It's exactly this situation that gives rise to the concern. Think about what happens when two peers both identified by the same PAD entry and both using the same name to select SPD entries (name matching not IP matching) claim the same IP address. What happens when just as an SA expires a different peer claims the same remote IP address? From kent at bbn.com Thu Dec 8 08:22:52 2005 From: kent at bbn.com (Stephen Kent) Date: Thu, 8 Dec 2005 11:22:52 -0500 Subject: [anonsec] 3401 and highjacking In-Reply-To: References: <20051204204127.GG21090@binky.Central.Sun.COM> <4395C4EA.3040800@isi.edu> <4395C931.6060702@isi.edu> <20051206173204.GH21090@binky.Central.Sun.COM> <20051207145408.GE21090@binky.Central.Sun.COM> Message-ID: At 6:20 PM -0500 12/7/05, Sam Hartman wrote: > >>>>> "Stephen" == Stephen Kent writes: > > Stephen> A PAD entry might identify the set of all road warriors > Stephen> for a company by a wild card name, e.g., *@bbn.com. The > Stephen> authorization data for the entry might say that these > Stephen> individuals have certs that can be validated using the CA > Stephen> cert for BBN. The entry would also specify that the IKE > Stephen> ID (not the road warrior's source address) be used for > Stephen> SPD matching. The SPD entry for these folks would be > Stephen> tagged with the name. Section 4.4.1.1 specifically gives > Stephen> the road warrior case as a motivation for the use of > Stephen> names to specify SPD entries, and says how to take the IP > Stephen> address of the road warrior (as the initiator) and use it > Stephen> as the remote address for the SPD entry (in a sort of PFP > Stephen> fashion). This should avoid the hijacking concern alluded > Stephen> to above. > > >It's exactly this situation that gives rise to the concern. > >Think about what happens when two peers both identified by the same >PAD entry and both using the same name to select SPD entries (name >matching not IP matching) claim the same IP address. What happens >when just as an SA expires a different peer claims the same remote IP >address? Sam, You ask what happens if an SA (for a road warrior) expires and different peer claims the same remote IP address. It is not clear that there is any point in the re-key process that makes this a problem, per se. I think the real question is whether we check to ensure that we don't create two SAs with different peers but the same selector sets, when a child SA is created, in general. (Assume that the SAs in question have the remote ID address asserted by a road warrior, but the local IP address, protocol, and port fields are all ANY, a not-unreasonable SPD entry for such users.) If we allowed such parallel, identical SAs (from a selector perspective) we have a serious problem in general, at least for SG/BITW implementations. This is because outbound traffic to either remote user from any host at the enterprise net would not be able to be mapped unambiguously to the right SA. So, I assume that a second user cannot have caused a new SA to be created with the same remote address as the first user, so long as an SA exists for the first remote user who asserted the address in question. Note that 4301 (section 4.1) mandates support for multiple SAs with the same selectors between the SAME pair of IKE peers. The motivation for allowing multiple SAs between the same set of IKE peers is to allow use of different SAs for QoS, without making QoS an explicit selector value. This requirement was added because implementations often did not allow duplicate SAs to be created under any circumstances, and this was an explicit exception. So I think it is reasonable to assume that an IPsec implementation will not, in general, allow a second SA to be created with he same selector values, if the peer for the second SA is different from that of the extant SA. To the best of my recollection, nobody ever raised the issue of allowing multiple SAs with the same set of selector values but terminating at different peers. One might imagine this would be a way to support load sharing or fast fail-over between one SG at one site and two of more SGs at a different site. If each peer is individually identified in the PAD, and thus presumed to be authorized for the same address space, then this would seem to be safe. However, if we create a PAD entry for a class of users, as in my road warrior example, and we don't want them to be able to assert overlapping ownership for the same address space (for obvious reasons), then we would want to prohibit creation of concurrent SAs with identical selector values, terminating at different peers. I think this behavior has been the default in most implementations, based on the discussions that led to the text in 4.1 (re support of multiple SAs for QoS support), although I admit that it is not clearly noted in the RFC. Steve From Nicolas.Williams at sun.com Thu Dec 8 09:48:20 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 8 Dec 2005 11:48:20 -0600 Subject: [anonsec] 3401 and highjacking In-Reply-To: References: <20051204204127.GG21090@binky.Central.Sun.COM> <4395C4EA.3040800@isi.edu> <4395C931.6060702@isi.edu> <20051206173204.GH21090@binky.Central.Sun.COM> <20051207145408.GE21090@binky.Central.Sun.COM> Message-ID: <20051208174819.GW21090@binky.Central.Sun.COM> On Thu, Dec 08, 2005 at 11:22:52AM -0500, Stephen Kent wrote: > You ask what happens if an SA (for a road warrior) expires and > different peer claims the same remote IP address. It is not clear > that there is any point in the re-key process that makes this a > problem, per se. I think the real question is whether we check to > ensure that we don't create two SAs with different peers but the same > selector sets, when a child SA is created, in general. (Assume that > the SAs in question have the remote ID address asserted by a road > warrior, but the local IP address, protocol, and port fields are all > ANY, a not-unreasonable SPD entry for such users.) Now the real question is what happens at SA expiration time. The same mechanism that you describe for protecting road warriors can be used to protect BTNS nodes... ...but like BTNS the issue that comes up is: can an attacker sneak in by preventing SA re-keying and then establishing a new SA with the attacker instead of the victim as one end-point and with the same selectors as the previous SAs. If so, then IPsec has a problem. Solutions based on persisting an {IP, ID} binding post-SA expiration create problems of their own, as discussed at Vancouver and on the list (how to know when to remove such a binding, dynamic address pool exhaustion DoS attacks, key rollover in the BTNS case). Solutions based on persisting a "7-tuple" (5-tuple + IDs) binding for open connections (incuding BSD socket UDP "connections") create problems for applications that use multiple connections between two peers. Nico -- From touch at ISI.EDU Thu Dec 8 08:59:53 2005 From: touch at ISI.EDU (Joe Touch) Date: Thu, 08 Dec 2005 08:59:53 -0800 Subject: [anonsec] 3401 and highjacking In-Reply-To: References: <20051204204127.GG21090@binky.Central.Sun.COM> <4395C4EA.3040800@isi.edu> <4395C931.6060702@isi.edu> <20051206173204.GH21090@binky.Central.Sun.COM> <20051207145408.GE21090@binky.Central.Sun.COM> Message-ID: <43986689.8080109@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen Kent wrote: > At 6:20 PM -0500 12/7/05, Sam Hartman wrote: > >> >>>>> "Stephen" == Stephen Kent writes: >> >> Stephen> A PAD entry might identify the set of all road warriors >> Stephen> for a company by a wild card name, e.g., *@bbn.com. The >> Stephen> authorization data for the entry might say that these >> Stephen> individuals have certs that can be validated using the CA >> Stephen> cert for BBN. The entry would also specify that the IKE >> Stephen> ID (not the road warrior's source address) be used for >> Stephen> SPD matching. The SPD entry for these folks would be >> Stephen> tagged with the name. Section 4.4.1.1 specifically gives >> Stephen> the road warrior case as a motivation for the use of >> Stephen> names to specify SPD entries, and says how to take the IP >> Stephen> address of the road warrior (as the initiator) and use it >> Stephen> as the remote address for the SPD entry (in a sort of PFP >> Stephen> fashion). This should avoid the hijacking concern alluded >> Stephen> to above. >> >> >> It's exactly this situation that gives rise to the concern. >> >> Think about what happens when two peers both identified by the same >> PAD entry and both using the same name to select SPD entries (name >> matching not IP matching) claim the same IP address. What happens >> when just as an SA expires a different peer claims the same remote IP >> address? > > > Sam, > > You ask what happens if an SA (for a road warrior) expires and different > peer claims the same remote IP address. It is not clear that there is > any point in the re-key process that makes this a problem, per se. I > think the real question is whether we check to ensure that we don't > create two SAs with different peers but the same selector sets, when a > child SA is created, in general. (Assume that the SAs in question have > the remote ID address asserted by a road warrior, but the local IP > address, protocol, and port fields are all ANY, a not-unreasonable SPD > entry for such users.) How do you know they're different peers if they claim to be the same peer and are authenticated differently? That seems to be what allows the new peer to pose as the old one and affect even a persistent connection to the old one (e.g., by rekeying). Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDmGaJE5f5cImnZrsRAv5JAKD8KC5m1gdq9kYf5a8JuOVHsjgJSgCfTm5d xGiNJIb9zqUWZdW+fS38uQ0= =im6w -----END PGP SIGNATURE----- From kent at bbn.com Thu Dec 8 10:24:25 2005 From: kent at bbn.com (Stephen Kent) Date: Thu, 8 Dec 2005 13:24:25 -0500 Subject: [anonsec] 3401 and highjacking In-Reply-To: <20051208174819.GW21090@binky.Central.Sun.COM> References: <20051204204127.GG21090@binky.Central.Sun.COM> <4395C4EA.3040800@isi.edu> <4395C931.6060702@isi.edu> <20051206173204.GH21090@binky.Central.Sun.COM> <20051207145408.GE21090@binky.Central.Sun.COM> <20051208174819.GW21090@binky.Central.Sun.COM> Message-ID: At 11:48 AM -0600 12/8/05, Nicolas Williams wrote: >On Thu, Dec 08, 2005 at 11:22:52AM -0500, Stephen Kent wrote: >> You ask what happens if an SA (for a road warrior) expires and >> different peer claims the same remote IP address. It is not clear >> that there is any point in the re-key process that makes this a >> problem, per se. I think the real question is whether we check to >> ensure that we don't create two SAs with different peers but the same >> selector sets, when a child SA is created, in general. (Assume that >> the SAs in question have the remote ID address asserted by a road >> warrior, but the local IP address, protocol, and port fields are all >> ANY, a not-unreasonable SPD entry for such users.) > >Now the real question is what happens at SA expiration time. > >The same mechanism that you describe for protecting road warriors >can be used to protect BTNS nodes... > >...but like BTNS the issue that comes up is: can an attacker sneak in by >preventing SA re-keying and then establishing a new SA with the attacker >instead of the victim as one end-point and with the same selectors as >the previous SAs. If so, then IPsec has a problem. If re-keying makes use of the IKE SA from which the child was created, then I don't think anyone else can "sneak in." if the IKE SA has been deleted, then we have an ambiguous case, because 4301, like 2401, does not say how to locate an IKE peer when an outbound SA needs to be created. >Solutions based on persisting an {IP, ID} binding post-SA expiration >create problems of their own, as discussed at Vancouver and on the list >(how to know when to remove such a binding, dynamic address pool >exhaustion DoS attacks, key rollover in the BTNS case). I'd rather if we not transform "persist" into a transitive verb :-). >Solutions based on persisting a "7-tuple" (5-tuple + IDs) binding for >open connections (incuding BSD socket UDP "connections") create problems >for applications that use multiple connections between two peers. Note that if the pair of peers (gee, that has a nice ring to it) is the same, multiple SAs are OK, and MUST be supported as per 4301, so this case ought not be a problem. Steve From Nicolas.Williams at sun.com Thu Dec 8 12:08:30 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 8 Dec 2005 14:08:30 -0600 Subject: [anonsec] 3401 and highjacking In-Reply-To: References: <4395C931.6060702@isi.edu> <20051206173204.GH21090@binky.Central.Sun.COM> <20051207145408.GE21090@binky.Central.Sun.COM> <20051208174819.GW21090@binky.Central.Sun.COM> Message-ID: <20051208200830.GY21090@binky.Central.Sun.COM> On Thu, Dec 08, 2005 at 01:24:25PM -0500, Stephen Kent wrote: > At 11:48 AM -0600 12/8/05, Nicolas Williams wrote: > >Now the real question is what happens at SA expiration time. > > > >The same mechanism that you describe for protecting road warriors > >can be used to protect BTNS nodes... > > > >...but like BTNS the issue that comes up is: can an attacker sneak in by > >preventing SA re-keying and then establishing a new SA with the attacker > >instead of the victim as one end-point and with the same selectors as > >the previous SAs. If so, then IPsec has a problem. > > If re-keying makes use of the IKE SA from which the child was > created, then I don't think anyone else can "sneak in." if the IKE SA > has been deleted, then we have an ambiguous case, because 4301, like > 2401, does not say how to locate an IKE peer when an outbound SA > needs to be created. This does not address DoS attacks aimed at preventing re-keying. > >Solutions based on persisting an {IP, ID} binding post-SA expiration > >create problems of their own, as discussed at Vancouver and on the list > >(how to know when to remove such a binding, dynamic address pool > >exhaustion DoS attacks, key rollover in the BTNS case). > > I'd rather if we not transform "persist" into a transitive verb :-). Sigh. Nico -- From hartmans-ietf at mit.edu Thu Dec 8 14:48:17 2005 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Thu, 08 Dec 2005 17:48:17 -0500 Subject: [anonsec] 3401 and highjacking In-Reply-To: (Stephen Kent's message of "Thu, 8 Dec 2005 15:59:08 -0500") References: <4395C931.6060702@isi.edu> <20051206173204.GH21090@binky.Central.Sun.COM> <20051207145408.GE21090@binky.Central.Sun.COM> <20051208174819.GW21090@binky.Central.Sun.COM> <20051208200830.GY21090@binky.Central.Sun.COM> Message-ID: >>>>> "Stephen" == Stephen Kent writes: Stephen> The rest of the paragraph just said that we don't specify Stephen> how to locate an IKE peer when creating an IKE SA in Stephen> general. It seems hard to characterize the DoS Stephen> vulnerability of an unspecified mechanism. I don't think outbound SAs are where we should be focusing our thoughts. If I'm going to try and attack this mechanism I'm going to try and cause dead peer detection to delete the SA or prevent rekey of the IKE SA. Then I'm going to try and initiate an IKE SA of my own and create child SAs that are interesting. I don't see how the outbound peer selection matters. Once child SAs are created, IKE is no longer involved. From kent at bbn.com Thu Dec 8 12:59:08 2005 From: kent at bbn.com (Stephen Kent) Date: Thu, 8 Dec 2005 15:59:08 -0500 Subject: [anonsec] 3401 and highjacking In-Reply-To: <20051208200830.GY21090@binky.Central.Sun.COM> References: <4395C931.6060702@isi.edu> <20051206173204.GH21090@binky.Central.Sun.COM> <20051207145408.GE21090@binky.Central.Sun.COM> <20051208174819.GW21090@binky.Central.Sun.COM> <20051208200830.GY21090@binky.Central.Sun.COM> Message-ID: At 2:08 PM -0600 12/8/05, Nicolas Williams wrote: >On Thu, Dec 08, 2005 at 01:24:25PM -0500, Stephen Kent wrote: >> At 11:48 AM -0600 12/8/05, Nicolas Williams wrote: >> >Now the real question is what happens at SA expiration time. >> > >> >The same mechanism that you describe for protecting road warriors >> >can be used to protect BTNS nodes... >> > >> >...but like BTNS the issue that comes up is: can an attacker sneak in by >> >preventing SA re-keying and then establishing a new SA with the attacker >> >instead of the victim as one end-point and with the same selectors as >> >the previous SAs. If so, then IPsec has a problem. >> >> If re-keying makes use of the IKE SA from which the child was >> created, then I don't think anyone else can "sneak in." if the IKE SA >> has been deleted, then we have an ambiguous case, because 4301, like >> 2401, does not say how to locate an IKE peer when an outbound SA >> needs to be created. > >This does not address DoS attacks aimed at preventing re-keying. To what part of the paragraph you cited does this observation apply? It would seem that use of an existing IKE SA for re-key is as resistant to a DoS attack as any IKE SA after it is established. The rest of the paragraph just said that we don't specify how to locate an IKE peer when creating an IKE SA in general. It seems hard to characterize the DoS vulnerability of an unspecified mechanism. Steve From Nicolas.Williams at sun.com Thu Dec 8 14:50:24 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 8 Dec 2005 16:50:24 -0600 Subject: [anonsec] 3401 and highjacking In-Reply-To: References: <20051206173204.GH21090@binky.Central.Sun.COM> <20051207145408.GE21090@binky.Central.Sun.COM> <20051208174819.GW21090@binky.Central.Sun.COM> <20051208200830.GY21090@binky.Central.Sun.COM> Message-ID: <20051208225024.GD21090@binky.Central.Sun.COM> On Thu, Dec 08, 2005 at 03:59:08PM -0500, Stephen Kent wrote: > At 2:08 PM -0600 12/8/05, Nicolas Williams wrote: > >On Thu, Dec 08, 2005 at 01:24:25PM -0500, Stephen Kent wrote: > >> If re-keying makes use of the IKE SA from which the child was > >> created, then I don't think anyone else can "sneak in." if the IKE SA > >> has been deleted, then we have an ambiguous case, because 4301, like > >> 2401, does not say how to locate an IKE peer when an outbound SA > >> needs to be created. > > > >This does not address DoS attacks aimed at preventing re-keying. > > To what part of the paragraph you cited does this observation apply? The first sentence. > It would seem that use of an existing IKE SA for re-key is as > resistant to a DoS attack as any IKE SA after it is established. But if IKE traffic can't get through the SA will eventually expire... > The rest of the paragraph just said that we don't specify how to > locate an IKE peer when creating an IKE SA in general. It seems hard > to characterize the DoS vulnerability of an unspecified mechanism. Right, I was referring to the first part. I thought that would be clear. Nico -- From kent at bbn.com Thu Dec 8 15:28:55 2005 From: kent at bbn.com (Stephen Kent) Date: Thu, 8 Dec 2005 18:28:55 -0500 Subject: [anonsec] 3401 and highjacking In-Reply-To: References: <4395C931.6060702@isi.edu> <20051206173204.GH21090@binky.Central.Sun.COM> <20051207145408.GE21090@binky.Central.Sun.COM> <20051208174819.GW21090@binky.Central.Sun.COM> <20051208200830.GY21090@binky.Central.Sun.COM> Message-ID: At 5:48 PM -0500 12/8/05, Sam Hartman wrote: > >>>>> "Stephen" == Stephen Kent writes: > > Stephen> The rest of the paragraph just said that we don't specify > Stephen> how to locate an IKE peer when creating an IKE SA in > Stephen> general. It seems hard to characterize the DoS > Stephen> vulnerability of an unspecified mechanism. > > >I don't think outbound SAs are where we should be focusing our >thoughts. If I'm going to try and attack this mechanism I'm going to >try and cause dead peer detection to delete the SA or prevent rekey of >the IKE SA. Then I'm going to try and initiate an IKE SA of my own >and create child SAs that are interesting. I don't see how the >outbound peer selection matters. Once child SAs are created, IKE is >no longer involved. I noted outbound SA creation because the SG might be the peer that would try to initiate the re-key, if the timer or traffic volume triggers fire there first. If the re-key trigger occurs at the road warrior, it can use the (parent) IKE SA for re-key and we are just as secure as what I noted. it is not true that the IKE SA is not relevant after a child SA is created. Additional CREATE_CHILD_SA payloads are sent over the IKE SA, and thus that SA can be used for re-key, without the overhead of a a new IKE SA being created. Steve From kent at bbn.com Thu Dec 8 14:22:20 2005 From: kent at bbn.com (Stephen Kent) Date: Thu, 8 Dec 2005 17:22:20 -0500 Subject: [anonsec] 3401 and highjacking In-Reply-To: <43986689.8080109@isi.edu> References: <20051204204127.GG21090@binky.Central.Sun.COM> <4395C4EA.3040800@isi.edu> <4395C931.6060702@isi.edu> <20051206173204.GH21090@binky.Central.Sun.COM> <20051207145408.GE21090@binky.Central.Sun.COM> <43986689.8080109@isi.edu> Message-ID: At 8:59 AM -0800 12/8/05, Joe Touch wrote: >... > > >> You ask what happens if an SA (for a road warrior) expires and different >> peer claims the same remote IP address. It is not clear that there is >> any point in the re-key process that makes this a problem, per se. I >> think the real question is whether we check to ensure that we don't >> create two SAs with different peers but the same selector sets, when a >> child SA is created, in general. (Assume that the SAs in question have >> the remote ID address asserted by a road warrior, but the local IP >> address, protocol, and port fields are all ANY, a not-unreasonable SPD >> entry for such users.) > >How do you know they're different peers if they claim to be the same >peer and are authenticated differently? That seems to be what allows the >new peer to pose as the old one and affect even a persistent connection >to the old one (e.g., by rekeying). > >Joe In this example the peers assert different IDs and these IDs are verified based on use of different credentials, even though they are authenticated under a single PAD entry. So, they are not claiming to be the same entity at the peer authentication stage of the process. Both the original peer and the new peer map to the same SPD entry, if we use a wild card name there (not because of use of the wild card name in the PAD entry). Thus the new peer is free to assert the same remote IP address as the previous peer, based only on the SPD check. If we retain the peer ID from the previous entity (as part of the SPD-S cache entry), that could be used to reject attempts to assert the same remote address by a new entity, and still allow a remote entity to initiate a re-key while retaining an existing, remote address. But, let's look first at why this has not been an issue to date. If the (parent) IKE SA is still present, then by using that SA to protect the re-key we ensure that the peer for the re-key is unchanged. So, persistence of that SA is a simple, secure solution to this problem. It's also preferable from a performance perspective, as we avoid the need to perform a new DH operation or re-authenticate the peer. Although Mike has not yet responded to this thread,I believe many IPsec SG implementations assign an address to the road warrior, from a pool reserved for road warriors, rather than allowing the RW to assert its address. The notion is that outbound traffic to RWs has to be routed to the SG, and thus a pool of addresses is reserved for this purpose. This prevents a new IKE exchange from resulting in a remote address that is already in use, although it also would pull the address put from under a RW who was re-keying a long-lived SA, and thus kill extant connections using the old SA. My guess is that the problem we have been discussing is not a problem in practice. Use of the (parent) IKE SA, if it exists, avoids the problem. If that SA is not available, use of the DHCP-style address assignment by an SG avoids the hijacking concern, although at the expense of connection continuity. Given likely SA durations based on crypto security criteria, it seems unlikely that re-keying will be needed for most RWs. My experience as a RW is that my hotel usually time out my DHCP lease and cause me to reconnect if I linger too long reading e-mail. We could add the peer IKE ID to the SPD-S cache part of the 4301 processing model in a future document if folks agree that it is needed, and if it helps address the concerns raised by proposed BTNS use of PAD. Steve From kent at bbn.com Thu Dec 8 15:40:18 2005 From: kent at bbn.com (Stephen Kent) Date: Thu, 8 Dec 2005 18:40:18 -0500 Subject: [anonsec] 3401 and highjacking In-Reply-To: <20051208225024.GD21090@binky.Central.Sun.COM> References: <20051206173204.GH21090@binky.Central.Sun.COM> <20051207145408.GE21090@binky.Central.Sun.COM> <20051208174819.GW21090@binky.Central.Sun.COM> <20051208200830.GY21090@binky.Central.Sun.COM> <20051208225024.GD21090@binky.Central.Sun.COM> Message-ID: At 4:50 PM -0600 12/8/05, Nicolas Williams wrote: >On Thu, Dec 08, 2005 at 03:59:08PM -0500, Stephen Kent wrote: >> At 2:08 PM -0600 12/8/05, Nicolas Williams wrote: >> >On Thu, Dec 08, 2005 at 01:24:25PM -0500, Stephen Kent wrote: >> >> If re-keying makes use of the IKE SA from which the child was >> >> created, then I don't think anyone else can "sneak in." if the IKE SA >> >> has been deleted, then we have an ambiguous case, because 4301, like >> >> 2401, does not say how to locate an IKE peer when an outbound SA >> >> needs to be created. >> > >> >This does not address DoS attacks aimed at preventing re-keying. >> >> To what part of the paragraph you cited does this observation apply? > >The first sentence. > >> It would seem that use of an existing IKE SA for re-key is as >> resistant to a DoS attack as any IKE SA after it is established. > >But if IKE traffic can't get through the SA will eventually expire... > >> The rest of the paragraph just said that we don't specify how to >> locate an IKE peer when creating an IKE SA in general. It seems hard >> to characterize the DoS vulnerability of an unspecified mechanism. > >Right, I was referring to the first part. I thought that would be clear. Thanks for the clarification, but I'm still not certain I understand your point. Are you suggesting that an attacker will - wait for a child SA to timeout (or come close to timeout) - suppress traffic between the road warrior and the SG, on the IKE SA to prevent its use for rekey - wait for that SA to time out - and then try to initiate a new IKE SA so that the attacker (who has the credentials of another valid RW user) can pose as the road warrior whose IKE SA and child SAs both timed out? The goal of this attack is to take over connections to hosts behind the SG, where these connections belong to the first RW (assuming that these connections have not themselves timed out by now)? Sorry, but I think your comment was way too brief for me to reliably infer all of that context. I would not say that this attack can't be carried out, but it requires enough timeouts and active wiretapping events as to be pretty far down on the list of things to worry about, in my opinion. Steve From Nicolas.Williams at sun.com Thu Dec 8 16:25:14 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 8 Dec 2005 18:25:14 -0600 Subject: [anonsec] 3401 and highjacking In-Reply-To: References: <20051207145408.GE21090@binky.Central.Sun.COM> <20051208174819.GW21090@binky.Central.Sun.COM> <20051208200830.GY21090@binky.Central.Sun.COM> <20051208225024.GD21090@binky.Central.Sun.COM> Message-ID: <20051209002514.GI21090@binky.Central.Sun.COM> On Thu, Dec 08, 2005 at 06:40:18PM -0500, Stephen Kent wrote: > At 4:50 PM -0600 12/8/05, Nicolas Williams wrote: > >Right, I was referring to the first part. I thought that would be clear. > > Thanks for the clarification, but I'm still not certain I understand > your point. Are you suggesting that an attacker will > - wait for a child SA to timeout (or come close to timeout) > - suppress traffic between the road warrior and the SG, on > the IKE SA to prevent its use for rekey > - wait for that SA to time out > - and then try to initiate a new IKE SA so that the attacker > (who has the credentials of another valid RW user) can pose as the > road warrior whose IKE SA and child SAs both timed out? Yes. > The goal of this attack is to take over connections to hosts behind > the SG, where these connections belong to the first RW (assuming that > these connections have not themselves timed out by now)? (Not just tunnels...) Relying on connection timeouts being significantly smaller than SA timeouts seems unlikely to work (particularly if said timeouts have to be enforced by nodes behind an SG that have no idea that they have to do this). > Sorry, but I think your comment was way too brief for me to reliably > infer all of that context. I would not say that this attack can't be > carried out, but it requires enough timeouts and active wiretapping > events as to be pretty far down on the list of things to worry about, > in my opinion. I'm not so sure. I'm thinking of wifi scenarios and social engineering. For example, suppressing traffic between a road warrior and its peers may seem difficult, but if the attacker can get the victim to move out of range of its AP(s) then the attacker has effectively suppressed traffic between the victim and its peers. No active wire tapping is needed in such a scenario. Come on, get with the program: it's all about wireless nowadays, especially for road warriors! :) In any case, something concrete does result from this discussion: if we can specify BTNS such that BTNS nodes get the same level of protection that road warriors get in 4301 then we can declare concerns about attacks like the above out of scope for the base BTNS spec. Nico -- From hartmans-ietf at mit.edu Thu Dec 8 18:37:46 2005 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Thu, 08 Dec 2005 21:37:46 -0500 Subject: [anonsec] 3401 and highjacking In-Reply-To: (Stephen Kent's message of "Thu, 8 Dec 2005 18:28:55 -0500") References: <4395C931.6060702@isi.edu> <20051206173204.GH21090@binky.Central.Sun.COM> <20051207145408.GE21090@binky.Central.Sun.COM> <20051208174819.GW21090@binky.Central.Sun.COM> <20051208200830.GY21090@binky.Central.Sun.COM> Message-ID: >>>>> "Stephen" == Stephen Kent writes: Stephen> At 5:48 PM -0500 12/8/05, Sam Hartman wrote: >> >>>>> "Stephen" == Stephen Kent writes: >> Stephen> The rest of the paragraph just said that we don't specify Stephen> how to locate an IKE peer when creating an IKE SA in Stephen> general. It seems hard to characterize the DoS Stephen> vulnerability of an unspecified mechanism. >> >> >> I don't think outbound SAs are where we should be focusing our >> thoughts. If I'm going to try and attack this mechanism I'm >> going to try and cause dead peer detection to delete the SA or >> prevent rekey of the IKE SA. Then I'm going to try and >> initiate an IKE SA of my own and create child SAs that are >> interesting. I don't see how the outbound peer selection >> matters. Once child SAs are created, IKE is no longer >> involved. Stephen> I noted outbound SA creation because the SG might be the Stephen> peer that would try to initiate the re-key, if the timer Stephen> or traffic volume triggers fire there first. Stephen> If the re-key trigger occurs at the road warrior, it can Stephen> use the (parent) IKE SA for re-key and we are just as Stephen> secure as what I noted. Again, we are talking about rekey of the IKE SA, not rekey of the child SAs. I agree with you that if the IKE SA is still alive that there is an obvious secure behavior to implement: do not let child SAs from one peer replace child SAs from another peer. Stephen> it is not true that the IKE SA is not relevant after a Sorry, what I meant hear is that IKE and thus the peer selection algorithm are not important for the lifetime of a particular child SA once that child SA is created. The IKE process is only invoked to create new SAs; traffic will flow over existing SAs without involvement of IKE. If an attacker can create a situation where only the attackers' child SAs exist, then for the life of those SAs, traffic selected by the SPD will flow over those SAs. --Sam From Nicolas.Williams at sun.com Thu Dec 8 20:35:36 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 8 Dec 2005 22:35:36 -0600 Subject: [anonsec] 3401 and highjacking In-Reply-To: <20051209002514.GI21090@binky.Central.Sun.COM> References: <20051208174819.GW21090@binky.Central.Sun.COM> <20051208200830.GY21090@binky.Central.Sun.COM> <20051208225024.GD21090@binky.Central.Sun.COM> <20051209002514.GI21090@binky.Central.Sun.COM> Message-ID: <20051209043536.GY17884@binky.Central.Sun.COM> On Thu, Dec 08, 2005 at 06:25:14PM -0600, Nicolas Williams wrote: > In any case, something concrete does result from this discussion: if we > can specify BTNS such that BTNS nodes get the same level of protection > that road warriors get in 4301 then we can declare concerns about > attacks like the above out of scope for the base BTNS spec. Or maybe not. The threat models for road warriors talking to SGs and for BTNS nodes doing end-to-end IPsec need not be the same. From kent at bbn.com Fri Dec 9 06:17:11 2005 From: kent at bbn.com (Stephen Kent) Date: Fri, 9 Dec 2005 09:17:11 -0500 Subject: [anonsec] 3401 and highjacking In-Reply-To: <20051209002514.GI21090@binky.Central.Sun.COM> References: <20051207145408.GE21090@binky.Central.Sun.COM> <20051208174819.GW21090@binky.Central.Sun.COM> <20051208200830.GY21090@binky.Central.Sun.COM> <20051208225024.GD21090@binky.Central.Sun.COM> <20051209002514.GI21090@binky.Central.Sun.COM> Message-ID: Nico, I too think this has been a useful discussion, although it would be easier (at least for me) if we had articulated the precise description of the potential problem from the beginning :-). I agree that we ought not rely on the relative timeout durations for user connections vs. SAs. However, I do believe that the former are generally much shorter than the latter. From a crypto perspective, at typical RW access speeds, it would take many hours to send enough traffic to warrant a re-key of a child SA, even using 32-bit sequence numbers. Now that we have mandated support for 64-bit sequence numbers for these SAs, basic crypto concerns are not likely to ever trigger a re-key. The peer node is likely to crash before it triggers a re-key based on traffic volume. Thus we have to ask what time-based re-key interval is appropriate, for other than crypto reasons. The same question applies to IKE SAs. They carry so little traffic that basic crypto concerns are also not likely to ever trigger a re-key. Since retaining these SAs offers great benefits with regard to creating new child SAs, and for SA maintenance in general, I would guess the primary reason to delete them is if an implementation runs out of space for the SA state. Your wireless access example is a valid one, although I would argue that the list of attacker actions that needs to be exercised to execute the attack is getting pretty long ;-). Your closing comment seems a little bit ambiguous. We have identified residual vulnerabilities for RW use of (vanilla) IPsec, given a specific set of assumptions about how one choose to define PAD and SPD entries. There are other options for PAD and SPD configuration ton accommodate RWs, which would be more secure but more onerous from a management perspective. It seems fair to say that if BTNS is used in a context where RWs are supported as I described, then it need not be more secure than vanilla IPsec, to meet the criterion established by Sam when the WG was chartered. But, an IPsec context that does not support RWs, or that uses a different PAD & SPD configuration approach to accommodate them ought not be made more vulnerable by BTNS use, right? Steve From kent at bbn.com Fri Dec 9 06:40:12 2005 From: kent at bbn.com (Stephen Kent) Date: Fri, 9 Dec 2005 09:40:12 -0500 Subject: [anonsec] 3401 and highjacking In-Reply-To: <20051209043536.GY17884@binky.Central.Sun.COM> References: <20051208174819.GW21090@binky.Central.Sun.COM> <20051208200830.GY21090@binky.Central.Sun.COM> <20051208225024.GD21090@binky.Central.Sun.COM> <20051209002514.GI21090@binky.Central.Sun.COM> <20051209043536.GY17884@binky.Central.Sun.COM> Message-ID: At 10:35 PM -0600 12/8/05, Nicolas Williams wrote: >On Thu, Dec 08, 2005 at 06:25:14PM -0600, Nicolas Williams wrote: >> In any case, something concrete does result from this discussion: if we >> can specify BTNS such that BTNS nodes get the same level of protection >> that road warriors get in 4301 then we can declare concerns about >> attacks like the above out of scope for the base BTNS spec. > >Or maybe not. The threat models for road warriors talking to SGs and >for BTNS nodes doing end-to-end IPsec need not be the same. Agreed. Steve From kent at bbn.com Fri Dec 9 06:39:41 2005 From: kent at bbn.com (Stephen Kent) Date: Fri, 9 Dec 2005 09:39:41 -0500 Subject: [anonsec] 3401 and highjacking In-Reply-To: References: <4395C931.6060702@isi.edu> <20051206173204.GH21090@binky.Central.Sun.COM> <20051207145408.GE21090@binky.Central.Sun.COM> <20051208174819.GW21090@binky.Central.Sun.COM> <20051208200830.GY21090@binky.Central.Sun.COM> Message-ID: At 9:37 PM -0500 12/8/05, Sam Hartman wrote: >... > >Again, we are talking about rekey of the IKE SA, not rekey of the >child SAs. I agree with you that if the IKE SA is still alive that >there is an obvious secure behavior to implement: do not let child SAs >from one peer replace child SAs from another peer. Agreed. > Stephen> it is not true that the IKE SA is not relevant after a > > >Sorry, what I meant hear is that IKE and thus the peer selection >algorithm are not important for the lifetime of a particular child SA >once that child SA is created. The IKE process is only invoked to >create new SAs; traffic will flow over existing SAs without >involvement of IKE. If an attacker can create a situation where only >the attackers' child SAs exist, then for the life of those SAs, >traffic selected by the SPD will flow over those SAs. Agreed, but in order for the attacker to cause his SA to replace the SA in question, the attacker has to go through the SA creation process. I was just exploring both sides of that process, for completeness. I also was noting that, in practice, there are a number of parameters in the system that have to align just right to allow peer-B to create an SA that replaces the SA of peer-A, in the example context we are discussing. Note that this problem could, in principle, arise in other cases, not just for road warriors. Thne heart of the vulnerability is that we allow wild card PAD and SPD entries, an essential feature to make access control manageable. If two (or more) peers identified in the PAD have child SA constraints that overlap in name spaces or address space, then it is always possible for different peers to establish SAs that, at least serially in time, employ the same selector sets. A vendor could offer a PAD/SPD checker utility to alert admins to this potential problem, to help avoid configuration errors that create this situation unintentionally (as opposed to as a side effect of what the admin considers to be a reasonable way to configure the databases). The inclusion of the peer ID in the SPD-S would prevent the hijacking concern in the case of a re-key when the corresponding IKE SA is not available, but it would not address the time serial problem noted above, since in that case the old SA might have been deleted. In that case we are again left with the possibility, noted by Nico, that the user's connection timeout is long enough to allow the connection to persist beyond the SA lifetime. In a native host implementation this problem might be more addressed in other ways, but for an SG or BITW implementation ... Steve From Nicolas.Williams at sun.com Fri Dec 9 07:49:55 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 9 Dec 2005 09:49:55 -0600 Subject: [anonsec] 3401 and highjacking In-Reply-To: References: <20051208174819.GW21090@binky.Central.Sun.COM> <20051208200830.GY21090@binky.Central.Sun.COM> <20051208225024.GD21090@binky.Central.Sun.COM> <20051209002514.GI21090@binky.Central.Sun.COM> <20051209043536.GY17884@binky.Central.Sun.COM> Message-ID: <20051209154954.GO21090@binky.Central.Sun.COM> On Fri, Dec 09, 2005 at 09:40:12AM -0500, Stephen Kent wrote: > At 10:35 PM -0600 12/8/05, Nicolas Williams wrote: > >On Thu, Dec 08, 2005 at 06:25:14PM -0600, Nicolas Williams wrote: > >> In any case, something concrete does result from this discussion: if we > >> can specify BTNS such that BTNS nodes get the same level of protection > >> that road warriors get in 4301 then we can declare concerns about > >> attacks like the above out of scope for the base BTNS spec. > > > >Or maybe not. The threat models for road warriors talking to SGs and > >for BTNS nodes doing end-to-end IPsec need not be the same. > > Agreed. In particular, I suspect that road warriors doing VPN aren't too concerned about their peer road warriors for in all likelihood the network behing the SG is not very secure to begin with and it would be easier for an authorized user to go to a physical office, jack in to the LAN and attack from there. I think this attack is much more worrisome on end-to-end situations, where IPsec may be the only session protection available to some applications. What saves 4301 in this case may simply be [speculation ahead] that noone uses end-to-end IPsec in very dynamic environments. BTNS is not intended (by most of us here, I think) to be used for talking to SGs, but for end-to-end IPsec -- BITS and native modes. The same attack that may not bother road warriors talking to SGs seems definitely more worrisome to me for BTNS. So perhaps we do have a duty to address the problem. Nico -- From Nicolas.Williams at sun.com Fri Dec 9 08:00:07 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 9 Dec 2005 10:00:07 -0600 Subject: [anonsec] 3401 and highjacking In-Reply-To: References: <20051208174819.GW21090@binky.Central.Sun.COM> <20051208200830.GY21090@binky.Central.Sun.COM> <20051208225024.GD21090@binky.Central.Sun.COM> <20051209002514.GI21090@binky.Central.Sun.COM> Message-ID: <20051209160007.GP21090@binky.Central.Sun.COM> On Fri, Dec 09, 2005 at 09:17:11AM -0500, Stephen Kent wrote: > I too think this has been a useful discussion, although it would be > easier (at least for me) if we had articulated the precise > description of the potential problem from the beginning :-). There you go again :) > I agree that we ought not rely on the relative timeout durations for > user connections vs. SAs. However, I do believe that the former are > generally much shorter than the latter. From a crypto perspective, at > typical RW access speeds, it would take many hours to send enough > traffic to warrant a re-key of a child SA, even using 32-bit sequence > numbers. Now that we have mandated support for 64-bit sequence > numbers for these SAs, basic crypto concerns are not likely to ever > trigger a re-key. Well, it's not just the 64-bit sequence numbers, but the use of 128-bit block ciphers. At any rate, why should mobile nodes negotiate very long-lived SAs? Or, more importantly, why should their peers allow them to negotiate very long-lived SAs? (And how can a node, not an SG, know that a peer is mobile?) > Your wireless access example is a valid one, although I would argue > that the list of attacker actions that needs to be exercised to > execute the attack is getting pretty long ;-). Nah, just get the victim out of range with some good excuse and keep them out for as long as it takes for the victim's SAs to expire, then take over the victim's IP address and slide in. The attacker has to have credentials that match the same PAD entry or a similar one to that matched by the victim on the target SG -- a pretty strong requirement, but one that is easy to meet if the victim was a BTNS node! > Your closing comment seems a little bit ambiguous. We have identified > residual vulnerabilities for RW use of (vanilla) IPsec, given a > specific set of assumptions about how one choose to define PAD and > SPD entries. There are other options for PAD and SPD configuration > ton accommodate RWs, which would be more secure but more onerous from > a management perspective. It seems fair to say that if BTNS is used > in a context where RWs are supported as I described, then it need not > be more secure than vanilla IPsec, to meet the criterion established > by Sam when the WG was chartered. But, an IPsec context that does not > support RWs, or that uses a different PAD & SPD configuration > approach to accommodate them ought not be made more vulnerable by > BTNS use, right? Right, I corrected myself subsequently -- the same attack can be of different value in different contexts because we'll have different threat models. OTOH, a solution to this attack should be general, even if specifically needed by BTNS. But note that the RW issue is not just for RWs -- RW may be the primary example for the use of wildcards in 4301, but certainly I could see folks using those in contexts other than RWs talking to SGs. Nico -- From Nicolas.Williams at sun.com Fri Dec 9 08:05:44 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 9 Dec 2005 10:05:44 -0600 Subject: [anonsec] 3401 and highjacking In-Reply-To: References: <20051208174819.GW21090@binky.Central.Sun.COM> <20051208200830.GY21090@binky.Central.Sun.COM> Message-ID: <20051209160543.GQ21090@binky.Central.Sun.COM> On Fri, Dec 09, 2005 at 09:39:41AM -0500, Stephen Kent wrote: > The inclusion of the peer ID in the SPD-S would prevent the hijacking > concern in the case of a re-key when the corresponding IKE SA is not > available, but it would not address the time serial problem noted > above, since in that case the old SA might have been deleted. In that > case we are again left with the possibility, noted by Nico, that the > user's connection timeout is long enough to allow the connection to > persist beyond the SA lifetime. In a native host implementation this > problem might be more addressed in other ways, but for an SG or BITW > implementation ... Yes, it's difficult to see a solution for SGs or BITW -- they're too far removed from the actual applications to know whethere packet flows are outstanding. Of course, they could watch TCP (and SCTP) traffic and apply the kinds of heuristics that NAT boxes do, with the same degree of satisfaction, no doubt. Native mode can do much better -- by cooperating with the ULPs (which in turn cooperate with the applications), native IPsec can know exactly when said flows are active or gone. Connection latching takes advantage of this. Nico -- From kent at bbn.com Fri Dec 9 08:39:08 2005 From: kent at bbn.com (Stephen Kent) Date: Fri, 9 Dec 2005 11:39:08 -0500 Subject: [anonsec] 3401 and highjacking In-Reply-To: <20051209154954.GO21090@binky.Central.Sun.COM> References: <20051208174819.GW21090@binky.Central.Sun.COM> <20051208200830.GY21090@binky.Central.Sun.COM> <20051208225024.GD21090@binky.Central.Sun.COM> <20051209002514.GI21090@binky.Central.Sun.COM> <20051209043536.GY17884@binky.Central.Sun.COM> <20051209154954.GO21090@binky.Central.Sun.COM> Message-ID: At 9:49 AM -0600 12/9/05, Nicolas Williams wrote: >On Fri, Dec 09, 2005 at 09:40:12AM -0500, Stephen Kent wrote: >> At 10:35 PM -0600 12/8/05, Nicolas Williams wrote: >> >On Thu, Dec 08, 2005 at 06:25:14PM -0600, Nicolas Williams wrote: >> >> In any case, something concrete does result from this discussion: if we >> >> can specify BTNS such that BTNS nodes get the same level of protection >> >> that road warriors get in 4301 then we can declare concerns about >> >> attacks like the above out of scope for the base BTNS spec. >> > >> >Or maybe not. The threat models for road warriors talking to SGs and >> >for BTNS nodes doing end-to-end IPsec need not be the same. >> >> Agreed. > >In particular, I suspect that road warriors doing VPN aren't too >concerned about their peer road warriors for in all likelihood the >network behing the SG is not very secure to begin with and it would be >easier for an authorized user to go to a physical office, jack in to the >LAN and attack from there. > >I think this attack is much more worrisome on end-to-end situations, >where IPsec may be the only session protection available to some >applications. What saves 4301 in this case may simply be [speculation >ahead] that noone uses end-to-end IPsec in very dynamic environments. > >BTNS is not intended (by most of us here, I think) to be used for >talking to SGs, but for end-to-end IPsec -- BITS and native modes. > >The same attack that may not bother road warriors talking to SGs seems >definitely more worrisome to me for BTNS. > >So perhaps we do have a duty to address the problem. > >Nico >-- Nico, I agree that IPsec probably is not used very often for end-to-end security, because most enterprise nets don't like to allow network-layer encrypted traffic through firewalls. (This problem will not go away because of BTNS.) For end systems it makes sense to see if there are was to take advantage of the additional connection state knowledge available to help address these concerns. Steve From kent at bbn.com Fri Dec 9 08:50:52 2005 From: kent at bbn.com (Stephen Kent) Date: Fri, 9 Dec 2005 11:50:52 -0500 Subject: [anonsec] 3401 and highjacking In-Reply-To: <20051209160007.GP21090@binky.Central.Sun.COM> References: <20051208174819.GW21090@binky.Central.Sun.COM> <20051208200830.GY21090@binky.Central.Sun.COM> <20051208225024.GD21090@binky.Central.Sun.COM> <20051209002514.GI21090@binky.Central.Sun.COM> <20051209160007.GP21090@binky.Central.Sun.COM> Message-ID: At 10:00 AM -0600 12/9/05, Nicolas Williams wrote: >... > >Well, it's not just the 64-bit sequence numbers, but the use of 128-bit >block ciphers. 128-bit block ciphers are good for VERY large traffic volumes, about 2**64 blocks, and 16 bytes per block) is a lot of data. It was use of DES, a 64-bit block cipher, that made this more of a concern, but even then most SAs were not in place long enough for this to be an issue. >At any rate, why should mobile nodes negotiate very long-lived SAs? Or, >more importantly, why should their peers allow them to negotiate very >long-lived SAs? (And how can a node, not an SG, know that a peer is >mobile?) Two answers: - first, this is not so much a mobile vs. stationary user matter. with AES-128 and 64-bit sequence numbers, it should be very rare for an SA to persist long enough to need to be re-keyed for crypto reasons. - second, why negotiate a short lived SA, and incur the cost and complexity of re-keying if you don't have to? > > Your wireless access example is a valid one, although I would argue >> that the list of attacker actions that needs to be exercised to >> execute the attack is getting pretty long ;-). > >Nah, just get the victim out of range with some good excuse and keep >them out for as long as it takes for the victim's SAs to expire, then >take over the victim's IP address and slide in. The attacker has to >have credentials that match the same PAD entry or a similar one to that >matched by the victim on the target SG -- a pretty strong requirement, >but one that is easy to meet if the victim was a BTNS node! For the last few days we were having a discussion about whether BTNS might create new security problems as we modified the PAD to accommodate BTNS functionality, or whether we already had serious security problems in the vanilla IPsec context. Your example illustrates how support for BTNS might cause what was a low risk residual vulnerability in vanilla IPsec into a more serious concerns in a BTNS context. >... > >Right, I corrected myself subsequently -- the same attack can be of >different value in different contexts because we'll have different >threat models. OTOH, a solution to this attack should be general, even >if specifically needed by BTNS. > >But note that the RW issue is not just for RWs -- RW may be the primary >example for the use of wildcards in 4301, but certainly I could see >folks using those in contexts other than RWs talking to SGs. Yes, wild cards are not restricted to RW scenarios. Steve From Nicolas.Williams at sun.com Fri Dec 9 11:32:36 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 9 Dec 2005 13:32:36 -0600 Subject: [anonsec] 3401 and highjacking In-Reply-To: References: <20051208174819.GW21090@binky.Central.Sun.COM> <20051208200830.GY21090@binky.Central.Sun.COM> <20051208225024.GD21090@binky.Central.Sun.COM> <20051209002514.GI21090@binky.Central.Sun.COM> <20051209160007.GP21090@binky.Central.Sun.COM> Message-ID: <20051209193235.GT21090@binky.Central.Sun.COM> On Fri, Dec 09, 2005 at 11:50:52AM -0500, Stephen Kent wrote: > At 10:00 AM -0600 12/9/05, Nicolas Williams wrote: > >... > > > >Well, it's not just the 64-bit sequence numbers, but the use of 128-bit > >block ciphers. > > 128-bit block ciphers are good for VERY large traffic volumes, about > 2**64 blocks, and 16 bytes per block) is a lot of data. It was use of > DES, a 64-bit block cipher, that made this more of a concern, but > even then most SAs were not in place long enough for this to be an > issue. That's what I said -- you say that because of 64-bit sequence numbers SA expiration is not driven by traffic volume, and I added that 128-bit cipher block sizes are necessary also for traffic volume to be a non-issue. Nico -- From Nicolas.Williams at sun.com Fri Dec 9 11:35:19 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 9 Dec 2005 13:35:19 -0600 Subject: [anonsec] 3401 and highjacking In-Reply-To: References: <20051208174819.GW21090@binky.Central.Sun.COM> <20051208200830.GY21090@binky.Central.Sun.COM> <20051208225024.GD21090@binky.Central.Sun.COM> <20051209002514.GI21090@binky.Central.Sun.COM> <20051209160007.GP21090@binky.Central.Sun.COM> Message-ID: <20051209193519.GU21090@binky.Central.Sun.COM> On Fri, Dec 09, 2005 at 11:50:52AM -0500, Stephen Kent wrote: > At 10:00 AM -0600 12/9/05, Nicolas Williams wrote: > >At any rate, why should mobile nodes negotiate very long-lived SAs? Or, > >more importantly, why should their peers allow them to negotiate very > >long-lived SAs? (And how can a node, not an SG, know that a peer is > >mobile?) > > Two answers: > - first, this is not so much a mobile vs. stationary user > matter. with AES-128 and 64-bit sequence numbers, it should be very > rare for an SA to persist long enough to need to be re-keyed for > crypto reasons. > - second, why negotiate a short lived SA, and incur the cost > and complexity of re-keying if you don't have to? But then you have to do dead peer detection when IP addresses are re-assigned. Look, a road warrior with a 30 minute DHCP lease ought not be negotiating SAs that live longer than the DHCP lease. Else the next road warrior to take that address (and talk to the same peers as the first) will be unhappy. From Nicolas.Williams at sun.com Fri Dec 9 11:49:43 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 9 Dec 2005 13:49:43 -0600 Subject: [anonsec] 3401 and highjacking In-Reply-To: References: <20051208200830.GY21090@binky.Central.Sun.COM> <20051208225024.GD21090@binky.Central.Sun.COM> <20051209002514.GI21090@binky.Central.Sun.COM> <20051209043536.GY17884@binky.Central.Sun.COM> <20051209154954.GO21090@binky.Central.Sun.COM> Message-ID: <20051209194943.GW21090@binky.Central.Sun.COM> On Fri, Dec 09, 2005 at 11:39:08AM -0500, Stephen Kent wrote: > I agree that IPsec probably is not used very often for end-to-end > security, because most enterprise nets don't like to allow > network-layer encrypted traffic through firewalls. (This problem will > not go away because of BTNS.) But even inside intranets I suspect end-to-end use of IPsec is not widespread. I think the problem we've been discussing is more serious for end-to-end uses of IPsec than for VPN uses of it, and that since BTNS is intended to be used in end-to-end fashion this problem is more serious for BTNS specifically than for VPN. > For end systems it makes sense to see if there are was to take > advantage of the additional connection state knowledge available to > help address these concerns. Right. Connection latching does exactly that. We need to think about how to describe connection latching in RFC4301 terms and what extensions RFC4301 might need for connection latching. Similarly for leap-of-faith, if anyone still thinks we need it. From kent at bbn.com Fri Dec 9 11:59:10 2005 From: kent at bbn.com (Stephen Kent) Date: Fri, 9 Dec 2005 14:59:10 -0500 Subject: [anonsec] 3401 and highjacking In-Reply-To: <20051209193235.GT21090@binky.Central.Sun.COM> References: <20051208174819.GW21090@binky.Central.Sun.COM> <20051208200830.GY21090@binky.Central.Sun.COM> <20051208225024.GD21090@binky.Central.Sun.COM> <20051209002514.GI21090@binky.Central.Sun.COM> <20051209160007.GP21090@binky.Central.Sun.COM> <20051209193235.GT21090@binky.Central.Sun.COM> Message-ID: At 1:32 PM -0600 12/9/05, Nicolas Williams wrote: >On Fri, Dec 09, 2005 at 11:50:52AM -0500, Stephen Kent wrote: >> At 10:00 AM -0600 12/9/05, Nicolas Williams wrote: >> >... >> > >> >Well, it's not just the 64-bit sequence numbers, but the use of 128-bit >> >block ciphers. >> >> 128-bit block ciphers are good for VERY large traffic volumes, about >> 2**64 blocks, and 16 bytes per block) is a lot of data. It was use of >> DES, a 64-bit block cipher, that made this more of a concern, but >> even then most SAs were not in place long enough for this to be an >> issue. > >That's what I said -- you say that because of 64-bit sequence numbers >SA expiration is not driven by traffic volume, and I added that 128-bit >cipher block sizes are necessary also for traffic volume to be a >non-issue. > >Nico >-- Sorry, I misunderstood your comment. Steve From kent at bbn.com Fri Dec 9 12:02:30 2005 From: kent at bbn.com (Stephen Kent) Date: Fri, 9 Dec 2005 15:02:30 -0500 Subject: [anonsec] 3401 and highjacking In-Reply-To: <20051209193519.GU21090@binky.Central.Sun.COM> References: <20051208174819.GW21090@binky.Central.Sun.COM> <20051208200830.GY21090@binky.Central.Sun.COM> <20051208225024.GD21090@binky.Central.Sun.COM> <20051209002514.GI21090@binky.Central.Sun.COM> <20051209160007.GP21090@binky.Central.Sun.COM> <20051209193519.GU21090@binky.Central.Sun.COM> Message-ID: At 1:35 PM -0600 12/9/05, Nicolas Williams wrote: >On Fri, Dec 09, 2005 at 11:50:52AM -0500, Stephen Kent wrote: >> At 10:00 AM -0600 12/9/05, Nicolas Williams wrote: >> >At any rate, why should mobile nodes negotiate very long-lived SAs? Or, >> >more importantly, why should their peers allow them to negotiate very >> >long-lived SAs? (And how can a node, not an SG, know that a peer is >> >mobile?) >> >> Two answers: >> - first, this is not so much a mobile vs. stationary user >> matter. with AES-128 and 64-bit sequence numbers, it should be very >> rare for an SA to persist long enough to need to be re-keyed for >> crypto reasons. >> - second, why negotiate a short lived SA, and incur the cost >> and complexity of re-keying if you don't have to? > >But then you have to do dead peer detection when IP addresses are >re-assigned. yes, but DPD is a function that most vendors consider important, for a variety of reasons. >Look, a road warrior with a 30 minute DHCP lease ought not be >negotiating SAs that live longer than the DHCP lease. Else the next >road warrior to take that address (and talk to the same peers as the >first) will be unhappy. I see your point. I was thinking about tunnel mode, since that is what one uses to contact an SG, and it the change in the outer IP address need not affect the SA, as the MOBIKE folks have described in detail in their documents. Maybe that's (another) good reason to use tunnel mode in contexts like this. Steve From kent at bbn.com Fri Dec 9 12:04:33 2005 From: kent at bbn.com (Stephen Kent) Date: Fri, 9 Dec 2005 15:04:33 -0500 Subject: [anonsec] 3401 and highjacking In-Reply-To: <20051209194943.GW21090@binky.Central.Sun.COM> References: <20051208200830.GY21090@binky.Central.Sun.COM> <20051208225024.GD21090@binky.Central.Sun.COM> <20051209002514.GI21090@binky.Central.Sun.COM> <20051209043536.GY17884@binky.Central.Sun.COM> <20051209154954.GO21090@binky.Central.Sun.COM> <20051209194943.GW21090@binky.Central.Sun.COM> Message-ID: At 1:49 PM -0600 12/9/05, Nicolas Williams wrote: >On Fri, Dec 09, 2005 at 11:39:08AM -0500, Stephen Kent wrote: >> I agree that IPsec probably is not used very often for end-to-end >> security, because most enterprise nets don't like to allow >> network-layer encrypted traffic through firewalls. (This problem will >> not go away because of BTNS.) > >But even inside intranets I suspect end-to-end use of IPsec is not >widespread. I think the problem we've been discussing is more serious >for end-to-end uses of IPsec than for VPN uses of it, and that since >BTNS is intended to be used in end-to-end fashion this problem is more >serious for BTNS specifically than for VPN. Yes, it's probably fair to say that the configuration management required for access control and for authentication deter intra-net use of IPsec. > >> For end systems it makes sense to see if there are was to take >> advantage of the additional connection state knowledge available to >> help address these concerns. > >Right. Connection latching does exactly that. > >We need to think about how to describe connection latching in RFC4301 >terms and what extensions RFC4301 might need for connection latching. > >Similarly for leap-of-faith, if anyone still thinks we need it. OK. Steve From Nicolas.Williams at sun.com Fri Dec 9 12:08:58 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 9 Dec 2005 14:08:58 -0600 Subject: [anonsec] 3401 and highjacking In-Reply-To: References: <20051208225024.GD21090@binky.Central.Sun.COM> <20051209002514.GI21090@binky.Central.Sun.COM> <20051209043536.GY17884@binky.Central.Sun.COM> <20051209154954.GO21090@binky.Central.Sun.COM> <20051209194943.GW21090@binky.Central.Sun.COM> Message-ID: <20051209200858.GY21090@binky.Central.Sun.COM> On Fri, Dec 09, 2005 at 03:04:33PM -0500, Stephen Kent wrote: > At 1:49 PM -0600 12/9/05, Nicolas Williams wrote: > >But even inside intranets I suspect end-to-end use of IPsec is not > >widespread. I think the problem we've been discussing is more serious > >for end-to-end uses of IPsec than for VPN uses of it, and that since > >BTNS is intended to be used in end-to-end fashion this problem is more > >serious for BTNS specifically than for VPN. > > Yes, it's probably fair to say that the configuration management > required for access control and for authentication deter intra-net > use of IPsec. On the other hand, adding features such as connection latching that provide protection against hijacking would make configuration of end-to-end IPsec simpler by allowing the safe use of PAD entries with wildcards for ID matching and large IP address ranges for selector constraints. Nico -- From Nicolas.Williams at sun.com Fri Dec 9 12:13:10 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 9 Dec 2005 14:13:10 -0600 Subject: [anonsec] 3401 and highjacking In-Reply-To: References: <20051208200830.GY21090@binky.Central.Sun.COM> <20051208225024.GD21090@binky.Central.Sun.COM> <20051209002514.GI21090@binky.Central.Sun.COM> <20051209160007.GP21090@binky.Central.Sun.COM> <20051209193519.GU21090@binky.Central.Sun.COM> Message-ID: <20051209201310.GZ21090@binky.Central.Sun.COM> On Fri, Dec 09, 2005 at 03:02:30PM -0500, Stephen Kent wrote: > At 1:35 PM -0600 12/9/05, Nicolas Williams wrote: > >But then you have to do dead peer detection when IP addresses are > >re-assigned. > > yes, but DPD is a function that most vendors consider important, for > a variety of reasons. You once again misunderstood my point, which was not to cast aspertions on DPD. See below. > >Look, a road warrior with a 30 minute DHCP lease ought not be > >negotiating SAs that live longer than the DHCP lease. Else the next > >road warrior to take that address (and talk to the same peers as the > >first) will be unhappy. > > I see your point. I was thinking about tunnel mode, since that is > what one uses to contact an SG, and it the change in the outer IP > address need not affect the SA, as the MOBIKE folks have described in > detail in their documents. Maybe that's (another) good reason to use > tunnel mode in contexts like this. The point is that relying on SA expiration to add protection against the highjacking problem doesn't help if DPD is used and, OTOH, if DPD is not used then long SA expiration can lead to dynamic address exhaustion (a DoS). Nico -- From kent at bbn.com Fri Dec 9 12:49:57 2005 From: kent at bbn.com (Stephen Kent) Date: Fri, 9 Dec 2005 15:49:57 -0500 Subject: [anonsec] 3401 and highjacking In-Reply-To: <20051209201310.GZ21090@binky.Central.Sun.COM> References: <20051208200830.GY21090@binky.Central.Sun.COM> <20051208225024.GD21090@binky.Central.Sun.COM> <20051209002514.GI21090@binky.Central.Sun.COM> <20051209160007.GP21090@binky.Central.Sun.COM> <20051209193519.GU21090@binky.Central.Sun.COM> <20051209201310.GZ21090@binky.Central.Sun.COM> Message-ID: At 2:13 PM -0600 12/9/05, Nicolas Williams wrote: >On Fri, Dec 09, 2005 at 03:02:30PM -0500, Stephen Kent wrote: >> At 1:35 PM -0600 12/9/05, Nicolas Williams wrote: >> >But then you have to do dead peer detection when IP addresses are >> >re-assigned. >> >> yes, but DPD is a function that most vendors consider important, for >> a variety of reasons. > >You once again misunderstood my point, which was not to cast aspertions >on DPD. See below. > >> >Look, a road warrior with a 30 minute DHCP lease ought not be >> >negotiating SAs that live longer than the DHCP lease. Else the next >> >road warrior to take that address (and talk to the same peers as the >> >first) will be unhappy. >> >> I see your point. I was thinking about tunnel mode, since that is >> what one uses to contact an SG, and it the change in the outer IP >> address need not affect the SA, as the MOBIKE folks have described in >> detail in their documents. Maybe that's (another) good reason to use >> tunnel mode in contexts like this. > >The point is that relying on SA expiration to add protection against the >highjacking problem doesn't help if DPD is used and, OTOH, if DPD is not >used then long SA expiration can lead to dynamic address exhaustion (a >DoS). When I misread your comment on 128-bit block ciphers the error was all mine. I read the sentence too quickly. However, the text above is not as clear as it could be. You refer to "relying on SA expiration" without indicating whether you are referring to long duration SAs or short duration SAs. Do you mean that we can have shorter duration SAs and re-key them safely IF we keep around the IKE SAs, via which we perform DPD? Yes, longer duration SAs, without DPD, create a DoS potential, but this seems to be mostly a BTNS issue, since otherwise the ability to create an SA is strictly limited to (pre-) authorized peers. Steve Steve From kent at bbn.com Fri Dec 9 12:59:49 2005 From: kent at bbn.com (Stephen Kent) Date: Fri, 9 Dec 2005 15:59:49 -0500 Subject: [anonsec] 3401 and highjacking In-Reply-To: <20051209200858.GY21090@binky.Central.Sun.COM> References: <20051208225024.GD21090@binky.Central.Sun.COM> <20051209002514.GI21090@binky.Central.Sun.COM> <20051209043536.GY17884@binky.Central.Sun.COM> <20051209154954.GO21090@binky.Central.Sun.COM> <20051209194943.GW21090@binky.Central.Sun.COM> <20051209200858.GY21090@binky.Central.Sun.COM> Message-ID: At 2:08 PM -0600 12/9/05, Nicolas Williams wrote: >... > > Yes, it's probably fair to say that the configuration management >> required for access control and for authentication deter intra-net >> use of IPsec. > >On the other hand, adding features such as connection latching that >provide protection against hijacking would make configuration of >end-to-end IPsec simpler by allowing the safe use of PAD entries with >wildcards for ID matching and large IP address ranges for selector >constraints. > >Nico >-- maybe. it really depending on how one is using IPsec, the user population (RWs vs. satellite offices vs. inter-enterprise VPNs, ...), etc. your actual configuration savings may vary ... Steve From pekka.nikander at nomadiclab.com Thu Dec 15 02:15:58 2005 From: pekka.nikander at nomadiclab.com (Pekka Nikander) Date: Thu, 15 Dec 2005 11:15:58 +0100 Subject: [anonsec] About tunnel mode, id/loc split, and API issues (was Re: 3401 and highjacking) In-Reply-To: References: <20051208174819.GW21090@binky.Central.Sun.COM> <20051208200830.GY21090@binky.Central.Sun.COM> <20051208225024.GD21090@binky.Central.Sun.COM> <20051209002514.GI21090@binky.Central.Sun.COM> <20051209160007.GP21090@binky.Central.Sun.COM> <20051209193519.GU21090@binky.Central.Sun.COM> Message-ID: Steve, >> Look, a road warrior with a 30 minute DHCP lease ought not be >> negotiating SAs that live longer than the DHCP lease. Else the next >> road warrior to take that address (and talk to the same peers as the >> first) will be unhappy. > > I see your point. I was thinking about tunnel mode, since that is > what one uses to contact an SG, and it the change in the outer IP > address need not affect the SA, as the MOBIKE folks have described in > detail in their documents. Maybe that's (another) good reason to use > tunnel mode in contexts like this. FWIW, I think there is a deeper architectural issue lurking in here. Using tunnel mode (especially with rfc 1918 addresses) implements a kind of identifier/locator split. The inner addresses are no more used as locators (at least in the Internet) but more as identifier proxies, to tie security semantics to something that exists at the IP layer. The outer addresses act as locators, at least at the Internet side. Of course, the distinction is not clear, as the inner addresses are likely to be used as both identifier proxies and locators in the intranet side. From this point of view, I fully agree with you: using tunnel mode have good reasons here. However, I also think that in the long run we should go forward, and try to get rid of tunnel mode overhead by implementing the required id/loc split directly at the host level. Given the direction BTNS seems to be taking, i.e., using public keys a identifiers, this mostly becomes an API issue. That is, how do we represent the public keys to the applications. Do we use inner IP addresses as proxies for them, as we do today? If so, should we perhaps recommend use CGA or KHI addresses and only IPv6 API, to provide some intrinsic security to the binding between the inner addresses and the identifiers? Or should we have a completely new API, allowing applications to learn the IP addresses the public key through the new API? Finally, if we use this kind of id/loc-split- like tunnel mode in end-to-end BTNS, should we perhaps go for tunnel overhead reduction? (I think MOBIKE is considering doing that.) [KHIs are defined in draft-laganier-ipv6-khi-00.txt] From my very personal point of view, I would like to see the whole stack architecture to evolve to a direction where we use KHI addresses as "inner addresses" or identifiers, tunnel them to outer addresses or locators locally at the end-node, and reduce the tunnelling overhead to minimum. The problem with this approach, of course, is the initial resolution from KHI addresses to the locators. From my point of view, that would provide fairly good backwards compatibility with applications using IPv6 addresses. The transport efficiency (header overhead) would be minimal. And it would provide applications with IP addresses that have security semantics similar to what IPsec expects today but independent of the usage, lifetime, and selection of the outer addresses. --Pekka From kent at bbn.com Thu Dec 15 06:47:14 2005 From: kent at bbn.com (Stephen Kent) Date: Thu, 15 Dec 2005 09:47:14 -0500 Subject: [anonsec] About tunnel mode, id/loc split, and API issues (was Re: 3401 and highjacking) In-Reply-To: References: <20051208174819.GW21090@binky.Central.Sun.COM> <20051208200830.GY21090@binky.Central.Sun.COM> <20051208225024.GD21090@binky.Central.Sun.COM> <20051209002514.GI21090@binky.Central.Sun.COM> <20051209160007.GP21090@binky.Central.Sun.COM> <20051209193519.GU21090@binky.Central.Sun.COM> Message-ID: Pekka, Gee, are we getting cross talk from the HIP WG list :-)? Seriously, the inner/outer header address processing differences in tunnel mode are not motivated by the features you described. The inner address is used as the locator and ID by both the sender and the (ultimate) receiver. The outer header is applied to direct the packet to a specific SG, to address problems that could arise if there are multiple SGs, if fragmentation occurs, etc. By convention we require use of tunnel mode for both SAs in a pair,to make life simpler. >Given the direction BTNS seems to be taking, i.e., using public keys >a identifiers, this mostly becomes an API issue. That is, how do >we represent the public keys to the applications. Do we use inner >IP addresses as proxies for them, as we do today? If so, should we >perhaps recommend use CGA or KHI addresses and only IPv6 API, to >provide some intrinsic security to the binding between the inner >addresses and the identifiers? Or should we have a completely new >API, allowing applications to learn the IP addresses the public key >through the new API? Finally, if we use this kind of >id/loc-split-like tunnel mode in end-to-end BTNS, should we perhaps >go for tunnel overhead reduction? (I think MOBIKE is considering >doing that.) This argument seems to be very host-implementation centric. IPsec is used in host, BITW and SG contexts. Maybe BTNS needs to decide explicitly whether it is targeted only at hosts, or also at BITW and SG contexts, before we consider arguments that are host-centric. Steve From pekka.nikander at nomadiclab.com Thu Dec 15 21:59:42 2005 From: pekka.nikander at nomadiclab.com (Pekka Nikander) Date: Fri, 16 Dec 2005 06:59:42 +0100 Subject: [anonsec] About tunnel mode, id/loc split, and API issues (was Re: 3401 and highjacking) In-Reply-To: References: <20051208174819.GW21090@binky.Central.Sun.COM> <20051208200830.GY21090@binky.Central.Sun.COM> <20051208225024.GD21090@binky.Central.Sun.COM> <20051209002514.GI21090@binky.Central.Sun.COM> <20051209160007.GP21090@binky.Central.Sun.COM> <20051209193519.GU21090@binky.Central.Sun.COM> Message-ID: <3B34711D-EBF0-4D2D-A56D-6B4C4C9AFE93@nomadiclab.com> Steve, On Dec 15, 2005, at 15:47, Stephen Kent wrote: > Gee, are we getting cross talk from the HIP WG list :-)? You know, from the very beginning one of the reasons why I agreed to co-chair this WG was due to my personal believe that BTNS would be a step to the "right" direction. Whether HIP is the right direction or not, not even the jury is out yet but we are still collecting evidence. However, personally, I believe that there are multiple reasons why we will need a new layer of indirection in the stack. Given that, I've been quite convinced for a number of years now that the "right" place to add such indirection is at the boundary between the end-to-end and hop-by-hop functions at the IP layer. IPsec happens to be just there, for good reasons. > Seriously, the inner/outer header address processing differences in > tunnel mode are not motivated by the features you described. The > inner address is used as the locator and ID by both the sender and > the (ultimate) receiver. The outer header is applied to direct the > packet to a specific SG, to address problems that could arise if > there are multiple SGs, if fragmentation occurs, etc. By convention > we require use of tunnel mode for both SAs in a pair,to make life > simpler. I am not arguing about the conventional use of tunnelling. Like you are (rightly) labelling my argumentation as host centric, I'd be tempted to label your argumentation as VPN centric. FWIW, I find it still quite sad that the IPsec WG took the VPN oriented direction for so many years and almost ignored host-centric possibilities. But I think I do understand many of the reasons for that, though not necessarily all. Given that, I'd allude that you are above, intentionally or not, ignoring the sore reality that SGs are often (but not always) placed at the boundary between RFC 1918 addressed and publicly addressed network segments. When used in such a way, SGs and tunnelling as used for what some people call "IP virtualisation". I don't know if you have followed the recent discussions at the INT area and architecture-discuss mailing lists, but I've been questioning there whether such "IP virtualisation" is a sound long-term practise or more an indication of something missing from the networking service that we provide. (As a shorter-term practice IP virtualisation or VPNs are a fine too, no problem with that.) Hence, while you are certainly right stating that when the tunnel processing model was designed people did not necessarily consider the processing differences in terms of id/loc split, I still find it interesting that there are so many parallels between the current operational reality and the requirements that are leading to me to believe that there is a need of a new indirection layer. >> Given the direction BTNS seems to be taking, i.e., using public >> keys a identifiers, this mostly becomes an API issue. That is, >> how do we represent the public keys to the applications. Do we >> use inner IP addresses as proxies for them, as we do today? If >> so, should we perhaps recommend use CGA or KHI addresses and only >> IPv6 API, to provide some intrinsic security to the binding >> between the inner addresses and the identifiers? Or should we >> have a completely new API, allowing applications to learn the IP >> addresses the public key through the new API? Finally, if we use >> this kind of id/loc-split-like tunnel mode in end-to-end BTNS, >> should we perhaps go for tunnel overhead reduction? (I think >> MOBIKE is considering doing that.) > > This argument seems to be very host-implementation centric. Indeed. > IPsec is used in host, BITW and SG contexts. Maybe BTNS needs to > decide explicitly whether it is targeted only at hosts, or also at > BITW and SG contexts, before we consider arguments that are host- > centric. Personally, I don't believe that all solutions BTNS produces must work equally in the host, BITW and SG contexts. That is, I'm fine if the use of BTNS is more limited if used in BITW and/or SG contexts than when used in a pure host-to-host implementation context. But that is up to the WG to decide. But there seems to be a quite few issues here: - Quite a lot of the current discussion (connection latching, SPD/SA hijacking etc) seems to be intrinsically related to the underlying provisioning model. Indeed, the main difference between BTNS and "traditional" IPsec is in the provisioning models. In traditional IPsec, explicit configuration is a cornerstone for security while BTNS aims for a weaker security model where little or no configuration and no explicit credentials provisioning are needed. - The harder part in any tunnelling (IPsec or not) is provisioning or configuration. - From an end-point / stack architecture point of view, the difference between tunnelling and address-preserving double address translation is a very fine one. Almost non-existing. Tunnelling changes the IP addresses the network sees by wrapping an existing packet within a new header. As a packet emerges from the tunnel, it has the same IP addresses as before entering. Double address translation changes the IP addresses the network sees by replacing the IP addresses in the packet. After the "unwrapping" translation at the receiver end, the packet has the same IP addresses as before getting translated. The biggest practical or provisional difference is that double translation requires that there is one-to-one mapping between and pairs while tunnelling doesn't. So, trying to put the argumentation above together, my tentative conclusions are the following: 1. I see there definitive architectural value in solutions that advance the stack architecture into a direction where we implement a new layer of indirection (roughly) at the same place where IPsec is. 2. We need to be very careful when we think about the BTNS provisioning model and its consequences to security. 3. One potential way to solve/avoid problems related to connection latching and leap-of-faith is to make changes at the API level. One possible way to change the API is to provide applications with identifiers that fulfil their current semantic assumptions but that are not used as locators in the network. Such usage is, the provisioning model disregarding, fairly close to some current uses of IPsec tunnelling. I admit that this is a complex issue and requires, at least for me, some mind-boggling shifts in viewpoints while thinking through. --Pekka From touch at ISI.EDU Fri Dec 16 11:02:34 2005 From: touch at ISI.EDU (Joe Touch) Date: Fri, 16 Dec 2005 11:02:34 -0800 Subject: [anonsec] About tunnel mode, id/loc split, and API issues (was Re: 3401 and highjacking) In-Reply-To: References: <20051208174819.GW21090@binky.Central.Sun.COM> <20051208200830.GY21090@binky.Central.Sun.COM> <20051208225024.GD21090@binky.Central.Sun.COM> <20051209002514.GI21090@binky.Central.Sun.COM> <20051209160007.GP21090@binky.Central.Sun.COM> <20051209193519.GU21090@binky.Central.Sun.COM> Message-ID: <43A30F4A.2060905@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Pekka Nikander wrote: > Steve, > > >>>Look, a road warrior with a 30 minute DHCP lease ought not be >>>negotiating SAs that live longer than the DHCP lease. Else the next >>>road warrior to take that address (and talk to the same peers as the >>>first) will be unhappy. >> >>I see your point. I was thinking about tunnel mode, since that is >>what one uses to contact an SG, and it the change in the outer IP >>address need not affect the SA, as the MOBIKE folks have described in >>detail in their documents. Maybe that's (another) good reason to use >>tunnel mode in contexts like this. > > > FWIW, I think there is a deeper architectural issue lurking in here. > > Using tunnel mode (especially with rfc 1918 addresses) implements a > kind of identifier/locator split. The inner addresses are no more > used as locators (at least in the Internet) but more as identifier > proxies, to tie security semantics to something that exists at the IP > layer. The outer addresses act as locators, at least at the Internet > side. I disagree; the outer addresses locate the decapsulating security device, but the inner addresses still just locate the endpoint from that point on. They're not global address/locators, but local to the SG-host path, and they still combine name and location, as you note below. > Of course, the distinction is not clear, as the inner addresses are > likely to be used as both identifier proxies and locators in the > intranet side. > > From this point of view, I fully agree with you: using tunnel mode > have good reasons here. Tunnels can be used several ways: 1- keep the SA but allow outer addresses to change 2- keep the SA but allow inner addresses to change 3- make the SA inner + outer specific All three modes have their uses; 3 is certainly more conservative, but 1 is needed for mobility without rekeying and 2 is needed (and typically used) for aggregation (e.g., VPN for a subnet). There are a lot of subtle issues that evolve out of that, as you note with respect to efficiency, but also with respect to dynamic routing, etc. BTNS may provide an opportunity for some of this as follow-on, but seems out of scope at this time, IMO. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDow9KE5f5cImnZrsRAo43AJ9HFqCbWnt+0ofGMRfBDkaArhoHLgCdGDHU uO4rDNQsKg/u3hLRWxX+i18= =0kmv -----END PGP SIGNATURE----- From touch at ISI.EDU Fri Dec 16 11:10:46 2005 From: touch at ISI.EDU (Joe Touch) Date: Fri, 16 Dec 2005 11:10:46 -0800 Subject: [anonsec] About tunnel mode, id/loc split, and API issues (was Re: 3401 and highjacking) In-Reply-To: <3B34711D-EBF0-4D2D-A56D-6B4C4C9AFE93@nomadiclab.com> References: <20051208174819.GW21090@binky.Central.Sun.COM> <20051208200830.GY21090@binky.Central.Sun.COM> <20051208225024.GD21090@binky.Central.Sun.COM> <20051209002514.GI21090@binky.Central.Sun.COM> <20051209160007.GP21090@binky.Central.Sun.COM> <20051209193519.GU21090@binky.Central.Sun.COM> <3B34711D-EBF0-4D2D-A56D-6B4C4C9AFE93@nomadiclab.com> Message-ID: <43A31136.4080906@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Pekka Nikander wrote: > 2. We need to be very careful when we think about the BTNS > provisioning model and its consequences to security. I'm wondering if we can address the persistent concerns about BTNS creating new holes by saying simply and directly: "BTNS is intended to protect BYPASS'd traffic from off-path attacks." (i.e., SPD entries that the administrator would be just as comfortable setting as BYPASS). ?? (I appreciate this may be too direct or too simplistic, but I wonder if it helps)... Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDoxE2E5f5cImnZrsRAtsnAKCJ+Hx57pn2tN1fT/wFj4+uAf3leACdEmFc CVdwaMLuSJ4eOju+O9Yia8g= =2hwI -----END PGP SIGNATURE----- From Nicolas.Williams at sun.com Fri Dec 16 11:28:50 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 16 Dec 2005 13:28:50 -0600 Subject: [anonsec] About tunnel mode, id/loc split, and API issues (was Re: 3401 and highjacking) In-Reply-To: <43A31136.4080906@isi.edu> References: <20051209002514.GI21090@binky.Central.Sun.COM> <20051209160007.GP21090@binky.Central.Sun.COM> <20051209193519.GU21090@binky.Central.Sun.COM> <3B34711D-EBF0-4D2D-A56D-6B4C4C9AFE93@nomadiclab.com> <43A31136.4080906@isi.edu> Message-ID: <20051216192850.GR18698@binky.Central.Sun.COM> On Fri, Dec 16, 2005 at 11:10:46AM -0800, Joe Touch wrote: > Pekka Nikander wrote: > > 2. We need to be very careful when we think about the BTNS > > provisioning model and its consequences to security. > > I'm wondering if we can address the persistent concerns about BTNS > creating new holes by saying simply and directly: > > "BTNS is intended to protect BYPASS'd traffic from off-path attacks." No, because as we discussed a week or so ago the applicability statement says that BTNS protects against on-path MITM attacks subsequent to initial exchanges. What you may want to propose is that we drop that requirement. From touch at ISI.EDU Fri Dec 16 11:47:08 2005 From: touch at ISI.EDU (Joe Touch) Date: Fri, 16 Dec 2005 11:47:08 -0800 Subject: [anonsec] About tunnel mode, id/loc split, and API issues (was Re: 3401 and highjacking) In-Reply-To: <20051216192850.GR18698@binky.Central.Sun.COM> References: <20051209002514.GI21090@binky.Central.Sun.COM> <20051209160007.GP21090@binky.Central.Sun.COM> <20051209193519.GU21090@binky.Central.Sun.COM> <3B34711D-EBF0-4D2D-A56D-6B4C4C9AFE93@nomadiclab.com> <43A31136.4080906@isi.edu> <20051216192850.GR18698@binky.Central.Sun.COM> Message-ID: <43A319BC.3040109@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nicolas Williams wrote: > On Fri, Dec 16, 2005 at 11:10:46AM -0800, Joe Touch wrote: > >>Pekka Nikander wrote: >> >>>2. We need to be very careful when we think about the BTNS >>>provisioning model and its consequences to security. >> >>I'm wondering if we can address the persistent concerns about BTNS >>creating new holes by saying simply and directly: >> >>"BTNS is intended to protect BYPASS'd traffic from off-path attacks." > > > No, because as we discussed a week or so ago the applicability statement > says that BTNS protects against on-path MITM attacks subsequent to > initial exchanges. > > What you may want to propose is that we drop that requirement. I'm proposing that you don't use BTNS unless you would have been comfortable using BYPASS on that traffic; I'm not proposing that it's identical. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDoxm8E5f5cImnZrsRAro3AKC1WdgGy4cmgwJ1c081UUTRM1kLMwCeJMRG jrF1OgQ4PTxgFAY7dd4G9tM= =AK1K -----END PGP SIGNATURE----- From Nicolas.Williams at sun.com Fri Dec 16 11:50:35 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 16 Dec 2005 13:50:35 -0600 Subject: [anonsec] About tunnel mode, id/loc split, and API issues (was Re: 3401 and highjacking) In-Reply-To: <43A319BC.3040109@isi.edu> References: <20051209160007.GP21090@binky.Central.Sun.COM> <20051209193519.GU21090@binky.Central.Sun.COM> <3B34711D-EBF0-4D2D-A56D-6B4C4C9AFE93@nomadiclab.com> <43A31136.4080906@isi.edu> <20051216192850.GR18698@binky.Central.Sun.COM> <43A319BC.3040109@isi.edu> Message-ID: <20051216195035.GT18698@binky.Central.Sun.COM> On Fri, Dec 16, 2005 at 11:47:08AM -0800, Joe Touch wrote: > Nicolas Williams wrote: > > On Fri, Dec 16, 2005 at 11:10:46AM -0800, Joe Touch wrote: > >>I'm wondering if we can address the persistent concerns about BTNS > >>creating new holes by saying simply and directly: > >> > >>"BTNS is intended to protect BYPASS'd traffic from off-path attacks." > > > > > > No, because as we discussed a week or so ago the applicability statement > > says that BTNS protects against on-path MITM attacks subsequent to > > initial exchanges. > > > > What you may want to propose is that we drop that requirement. > > I'm proposing that you don't use BTNS unless you would have been > comfortable using BYPASS on that traffic; I'm not proposing that it's > identical. I don't understand -- what is not identical to what? Please address the on-path MITM issue. From touch at ISI.EDU Fri Dec 16 13:14:27 2005 From: touch at ISI.EDU (Joe Touch) Date: Fri, 16 Dec 2005 13:14:27 -0800 Subject: [anonsec] About tunnel mode, id/loc split, and API issues (was Re: 3401 and highjacking) In-Reply-To: <20051216195035.GT18698@binky.Central.Sun.COM> References: <20051209160007.GP21090@binky.Central.Sun.COM> <20051209193519.GU21090@binky.Central.Sun.COM> <3B34711D-EBF0-4D2D-A56D-6B4C4C9AFE93@nomadiclab.com> <43A31136.4080906@isi.edu> <20051216192850.GR18698@binky.Central.Sun.COM> <43A319BC.3040109@isi.edu> <20051216195035.GT18698@binky.Central.Sun.COM> Message-ID: <43A32E33.20406@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nicolas Williams wrote: > On Fri, Dec 16, 2005 at 11:47:08AM -0800, Joe Touch wrote: > >>Nicolas Williams wrote: >> >>>On Fri, Dec 16, 2005 at 11:10:46AM -0800, Joe Touch wrote: >>> >>>>I'm wondering if we can address the persistent concerns about BTNS >>>>creating new holes by saying simply and directly: >>>> >>>>"BTNS is intended to protect BYPASS'd traffic from off-path attacks." >>> >>> >>>No, because as we discussed a week or so ago the applicability statement >>>says that BTNS protects against on-path MITM attacks subsequent to >>>initial exchanges. >>> >>>What you may want to propose is that we drop that requirement. >> >>I'm proposing that you don't use BTNS unless you would have been >>comfortable using BYPASS on that traffic; I'm not proposing that it's >>identical. > > I don't understand -- what is not identical to what? BTNS != BYPASS > Please address the on-path MITM issue. If you restrict the use of BTNS to traffic that you could have been comfortable BYPASSing, MITM is moot. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDoy4zE5f5cImnZrsRAg4mAJwLUdYCz9KhUV8600tU6R07st4McQCdH5qN 3paB6biI65TGOUW5IEoeTBM= =7Fyb -----END PGP SIGNATURE----- From Nicolas.Williams at sun.com Fri Dec 16 13:47:19 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 16 Dec 2005 15:47:19 -0600 Subject: [anonsec] About tunnel mode, id/loc split, and API issues (was Re: 3401 and highjacking) In-Reply-To: <43A32E33.20406@isi.edu> References: <20051209193519.GU21090@binky.Central.Sun.COM> <3B34711D-EBF0-4D2D-A56D-6B4C4C9AFE93@nomadiclab.com> <43A31136.4080906@isi.edu> <20051216192850.GR18698@binky.Central.Sun.COM> <43A319BC.3040109@isi.edu> <20051216195035.GT18698@binky.Central.Sun.COM> <43A32E33.20406@isi.edu> Message-ID: <20051216214719.GB18698@binky.Central.Sun.COM> On Fri, Dec 16, 2005 at 01:14:27PM -0800, Joe Touch wrote: > Nicolas Williams wrote: > > Please address the on-path MITM issue. > > If you restrict the use of BTNS to traffic that you could have been > comfortable BYPASSing, MITM is moot. So are we then to understand that you do want to drop protection- against-MITM-attacks-after-initial-key-exchange from the requirements for BTNS? From touch at ISI.EDU Fri Dec 16 14:51:11 2005 From: touch at ISI.EDU (Joe Touch) Date: Fri, 16 Dec 2005 14:51:11 -0800 Subject: [anonsec] About tunnel mode, id/loc split, and API issues (was Re: 3401 and highjacking) In-Reply-To: <20051216214719.GB18698@binky.Central.Sun.COM> References: <20051209193519.GU21090@binky.Central.Sun.COM> <3B34711D-EBF0-4D2D-A56D-6B4C4C9AFE93@nomadiclab.com> <43A31136.4080906@isi.edu> <20051216192850.GR18698@binky.Central.Sun.COM> <43A319BC.3040109@isi.edu> <20051216195035.GT18698@binky.Central.Sun.COM> <43A32E33.20406@isi.edu> <20051216214719.GB18698@binky.Central.Sun.COM> Message-ID: <43A344DF.9040207@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nicolas Williams wrote: > On Fri, Dec 16, 2005 at 01:14:27PM -0800, Joe Touch wrote: > >>Nicolas Williams wrote: >> >>>Please address the on-path MITM issue. >> >>If you restrict the use of BTNS to traffic that you could have been >>comfortable BYPASSing, MITM is moot. > > > So are we then to understand that you do want to drop protection- > against-MITM-attacks-after-initial-key-exchange from the requirements > for BTNS? No - but since you don't know who you're doing the initial key exchange with, you shouldn't do such exchanges with any party you wouldn't basically be willing to do BYPASS with. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDo0TfE5f5cImnZrsRAkleAJ42e4PKT2x4uB5inBvY7c0QMYz8oACdGA71 AnDKkM6CHfTBdkOJ3kk6gJs= =xFa/ -----END PGP SIGNATURE----- From kent at bbn.com Fri Dec 16 15:48:55 2005 From: kent at bbn.com (Stephen Kent) Date: Fri, 16 Dec 2005 18:48:55 -0500 Subject: [anonsec] About tunnel mode, id/loc split, and API issues (was Re: 3401 and highjacking) In-Reply-To: <3B34711D-EBF0-4D2D-A56D-6B4C4C9AFE93@nomadiclab.com> References: <20051208174819.GW21090@binky.Central.Sun.COM> <20051208200830.GY21090@binky.Central.Sun.COM> <20051208225024.GD21090@binky.Central.Sun.COM> <20051209002514.GI21090@binky.Central.Sun.COM> <20051209160007.GP21090@binky.Central.Sun.COM> <20051209193519.GU21090@binky.Central.Sun.COM> <3B34711D-EBF0-4D2D-A56D-6B4C4C9AFE93@nomadiclab.com> Message-ID: At 6:59 AM +0100 12/16/05, Pekka Nikander wrote: >... >You know, from the very beginning one of the reasons why I agreed to >co-chair this WG was due to my personal believe that BTNS would be a >step to the "right" direction. The charter of BTNS focuses on contexts in which not authenticating a peer at the IP layer is a useful feature. It does not discuss the locator/ID separation that is the gist of your previous message. > Whether HIP is the right direction or not, not even the jury is >out yet but we are still collecting evidence. However, personally, >I believe that there are multiple reasons why we will need a new >layer of indirection in the stack. >Given that, I've been quite convinced for a number of years now that >the "right" place to add such indirection is at the boundary between >the end-to-end and hop-by-hop functions at the IP layer. IPsec >happens to be just there, for good reasons. As noted above, I think this WG is not an appropriate place to have this discussion, given its charter. >>... > >I am not arguing about the conventional use of tunnelling. Like you >are (rightly) labelling my argumentation as host centric, I'd be >tempted to label your argumentation as VPN centric. FWIW, I find it >still quite sad that the IPsec WG took the VPN oriented direction >for so many years and almost ignored host-centric possibilities. >But I think I do understand many of the reasons for that, though not >necessarily all. I disagree with your characterization. I think IPsec adopted a perspective that encompassed host, BITW, and SG approaches to providing the set of securty services we aim to provide. >Given that, I'd allude that you are above, intentionally or not, >ignoring the sore reality that SGs are often (but not always) placed >at the boundary between RFC 1918 addressed and publicly addressed >network segments. When used in such a way, SGs and tunnelling as >used for what some people call "IP virtualisation". I don't know if >you have followed the recent discussions at the INT area and >architecture-discuss mailing lists, but I've been questioning there >whether such "IP virtualisation" is a sound long-term practise or >more an indication of something missing from the networking service >that we provide. (As a shorter-term practice IP virtualisation or >VPNs are a fine too, no problem with that.) I have not followed those discussions. But I don't think this WG is an appropriate place to pursue them, given the charter. >Hence, while you are certainly right stating that when the tunnel >processing model was designed people did not necessarily consider >the processing differences in terms of id/loc split, I still find it >interesting that there are so many parallels between the current >operational reality and the requirements that are leading to me to >believe that there is a need of a new indirection layer. You may be right, but again, I would argue that the creation of the indirection layer option is a HIP WG matter, not a BTNS matter. >>IPsec is used in host, BITW and SG contexts. Maybe BTNS needs to >>decide explicitly whether it is targeted only at hosts, or also at >>BITW and SG contexts, before we consider arguments that are >>host-centric. > >Personally, I don't believe that all solutions BTNS produces must >work equally in the host, BITW and SG contexts. That is, I'm fine >if the use of BTNS is more limited if used in BITW and/or SG >contexts than when used in a pure host-to-host implementation >context. But that is up to the WG to decide. agreed. >But there seems to be a quite few issues here: > >- Quite a lot of the current discussion (connection latching, SPD/SA >hijacking etc) seems to be intrinsically related to the underlying >provisioning model. Indeed, the main difference between BTNS and >"traditional" IPsec is in the provisioning models. In traditional >IPsec, explicit configuration is a cornerstone for security while >BTNS aims for a weaker security model where little or no >configuration and no explicit credentials provisioning are needed. I would say that BTNS is motivated by the perception that provisioning for authentication is a burden in many contexts and that there are situations where it makes sense to avoid this burden. >- The harder part in any tunnelling (IPsec or not) is provisioning >or configuration. oh? >- From an end-point / stack architecture point of view, the >difference between tunnelling and address-preserving double address >translation is a very fine one. Almost non-existing. Tunnelling >changes the IP addresses the network sees by wrapping an existing >packet within a new header. As a packet emerges from the tunnel, it >has the same IP addresses as before entering. Double address >translation changes the IP addresses the network sees by replacing >the IP addresses in the packet. After the "unwrapping" translation >at the receiver end, the packet has the same IP addresses as before >getting translated. The biggest practical or provisional difference >is that double translation requires that there is one-to-one mapping >between and pairs >while tunnelling doesn't. One can perform tunneling for different reasons, some (many?) of which are distinct from the reasons for address translation. As I noted previously, tunneling for IPsec is motivated (in large part) by the need to direct the traffic to a specific SG, to ensure that the traffic arrives at a point where the SA state is present. if one reads more into tunneling than that, one is going outside the intent of the IPsec WG efforts. >So, trying to put the argumentation above together, my tentative >conclusions are the following: > >1. I see there definitive architectural value in solutions that >advance the stack architecture into a direction where we implement a >new layer of indirection (roughly) at the same place where IPsec is. Which is what HIP is doing, right? So why should this be part of the discussion here? >2. We need to be very careful when we think about the BTNS >provisioning model and its consequences to security. no argument there. >3. One potential way to solve/avoid problems related to connection >latching and leap-of-faith is to make changes at the API level. One >possible way to change the API is to provide applications with >identifiers that fulfil their current semantic assumptions but that >are not used as locators in the network. Such usage is, the >provisioning model disregarding, fairly close to some current uses >of IPsec tunnelling. Just because the two look similar, that does not mean they are equivalent. Since BTNS focuses on creating SAs that are not authenticated via network layer mechanisms, the notion of the IDs used at this layer seems irrelevant to the BTNS focus. Steve From Nicolas.Williams at Sun.COM Fri Dec 16 12:05:23 2005 From: Nicolas.Williams at Sun.COM (Nicolas Williams) Date: Fri, 16 Dec 2005 14:05:23 -0600 Subject: [anonsec] About tunnel mode, id/loc split, and API issues (was Re: 3401 and highjacking) In-Reply-To: References: <20051208225024.GD21090@binky.Central.Sun.COM> <20051209002514.GI21090@binky.Central.Sun.COM> <20051209160007.GP21090@binky.Central.Sun.COM> <20051209193519.GU21090@binky.Central.Sun.COM> Message-ID: <20051216200523.GU18698@binky.Central.Sun.COM> On Thu, Dec 15, 2005 at 11:15:58AM +0100, Pekka Nikander wrote: > FWIW, I think there is a deeper architectural issue lurking in here. Yes. > Using tunnel mode (especially with rfc 1918 addresses) implements a > kind of identifier/locator split. The inner addresses are no more > used as locators (at least in the Internet) but more as identifier > proxies, to tie security semantics to something that exists at the IP > layer. The outer addresses act as locators, at least at the Internet > side. But this deeper architectural issue is NOT specific to tunnels. So, let's leave tunnels behind for a second and consider this formulation of said architectural problem: IPsec, in its current form, requires a trade-off between dynamic addressing (the reality of today's IPv4 networks) and cryptographic binding of authenticated IDs and packet _flows_. A slightly longer version: IPsec provides ID<->packet cryptographic binding and cryptographic protection for individual packets. IPsec does not provide cryptographic binding of IDs to packet _flows_ associated with ULPs beyond that which is embodied in the IPsec configuration. This is so because IPsec is not integrated with the ULPs. To provide such cryptographic binding of IDs to packet _flows_ requires IPsec configuration to bind IDs to IP addresses, which makes IPsec configuration unmanageable where node renumbering events are common (as they often are, if nothing else because of DHCP/mobile nodes). There is a way to add such cryptographic binding of IDs<->flows, but it requires interfaces between IPsec and ULPs to manage such bindings and between applications and ULPs to allow applications access to channel bindings (not only for channel binding, but also so that applications can determine if two channels have equal bindings, for example). Other ways to achieve some degree of cryptographic binding of IDs<->flows involve IPsec guessing ULP state from packet inspection (much like NATs do). Are there still other ways to solve this problem? I can't think of any. Nico --