From lha at it.su.se Fri May 5 07:25:38 2006 From: lha at it.su.se (=?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?=) Date: Fri, 5 May 2006 16:25:38 +0200 Subject: [anonsec] ietf 65 meeting minutes Message-ID: Last day for corrections is on monday next week. So if you have any comments, this is the weekend to send the mail. Love http://www3.ietf.org/proceedings/06mar/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/20060505/2dc9803e/PGP.bin From yushunwa at ISI.EDU Fri May 5 11:28:06 2006 From: yushunwa at ISI.EDU (Yu-Shun Wang) Date: Fri, 05 May 2006 11:28:06 -0700 Subject: [anonsec] BTNS mailing list auto-rejection from non-subscribers In-Reply-To: References: Message-ID: <445B9936.5010107@isi.edu> Hi, (Not sure if Pekka's mail gets to the list yet, but his comments were all quoted below.) >> From: Pekka Savola >> Subject: BTNS prob/applic -02 review >> Date: Wed, 3 May 2006 13:10:24 +0300 (EEST) >> I had a flight, so I ended reading a couple of drafts in the interest >> of providing early out-of-WG review. Thanks. >> The doc was mostly in OK shape, though it wasn't clear whether the >> scenarios were the ones thought about by BTNS proponents rather than >> having been proposed by folks actually designing applications.. No direct answers, but I think the work on APIs (both channel binding and the general IPsec API) will definitely address that. >> substantial >> ----------- >> >> BTNS reduces vulnerability after associations have been established >> to attacks from parties not participating in the association. This >> helps protect systems from low-effort attacks on sessions or >> connections involving higher levels of resources. >> >> ==>the doc mostly discusses TCP RST attacks, maybe it should discuss ICMP >> attacks a bit too as those are in most cases much easier to launch than >> TCP-RST attacks. It is not clear to me whether IPsec includes sufficient >> mandatory-to-implement, enabled-by-default protections to this. Joe is also working on some ICMP-related drafts, he is better suited to address this suggestion. >> 4.6. Benefits >> >> BTNS raises the level of effort for many types of network or >> transport layer attacks. Casual, simple packet attacks need to be >> augmented to full associations and connection establishment for SAB, >> so that an attacker must perform as much work as regular host. SAB >> thus raises the effort for a DDOS attack to that of emulating a flash >> crowd. For open services, there may be no way to distinguish such a >> DDOS attack from a legitimate flash crowd anyway. >> >> ==> AFAICS, this text is too simplistic. It seems to assume that non-BTNS >> mode of connecting to the service is not supported, i.e., BTNS is deployed >> and enabled everywhere. What is the transition strategy to using BTNS? The benefits section is of course addressing the benefit of using BTNS, hence the assumption. I personally don't think it is the goal of this doc to also address the transition strategy, though it is imo not very complex. BTNS uses IKE (or added a mode in IKE, not sure how to accurately describe it), and is enabled through PAD and/or SPD. So if the other end doesn't support it, IKE exchange would fail. The "strategy" may boiled down to whether or not we revert back to non-protected mode, as the original intention is "better than nothing." So the question may be: do we go back to nothing if the other end doesn't do BTNS? That said, I still don't think it is the goal of this doc to address the transition strategy. It should be addressed at some point once we know the details of the mechanisms involved. >> The use of BTNS means that more traffic will require cryptographic >> operations. Receivers will observe increased processing load in >> decrypting and/or verifying incoming traffic as a result. Although >> this may itself present a substantial impediment to deployment, it is >> a challenge to all cryptographically protected communication systems. >> The use of crypto increases the load on those receiving protected >> traffic; this document does not address the impact BTNS has on such >> load. >> >> ==> you don't seem to discuss the fact that the set-up of BTNS >> requires significant number of round-trips, which may or may not be an >> issue for ome kinds of applications, especially for links with high >> latency. It uses IKE, so it adds whatever number of round-trips IKE requires. So yes, in the environments that IKE is not suitable due to latency issues, neither is BTNS. We will make a note in the doc. >> A man-in-the-middle attack on IPsec with CBB is discovered later than >> if IKE authentication were used. A man in the middle cannot subvert >> IKE authentication, and hence an attempt to attack it via use of two >> separate security associations will cause an IKE authentication >> failure. With CBB, the BTNS-IKE step will succeed because it is >> unauthenticated, and the security association will be set up. The >> man in the middle will not be discovered until the higher layer >> authentication fail after more resources have been invested in this >> session. Nonetheless, this is an improvement over the alternative of >> minimizing the configuration of IPsec by using a group pre-shared >> key, which provides no defense against man-in-the-middle attacks >> among the nodes sharing the key. >> >> ==> Did I understand correctly that MITM is discovered and session is >> taken down after the MITM attacker has been able to obtain passwords >> (or whatever) from higher-layer authentication? This sounds a bit >> bleak. It's of course better than nothing, but when designing or >> using higher-layer protocols, in the future the choice might be >> between using (say) TLS or using CBB-BTNS at lower layer -- and >> depending on whether the higher layer authentication leaks any >> secrets, NOT using BTNS might be a better choice (again, depending on >> the authentication type). >> >> In any case, the higher layer authentication information leaking (or >> lack thereof) and implications on BTNS applicability should be >> discussed explicitly. No. Nico or David specifically corrected me that channel binding should (or must) not reveal passwords in the upper layer authentication. So we should make that clear, but the details will be in Nico's doc. >> 6.1. Issues Not Addressed >> BTNS does not consider the impact of NAT or NAPT on the capabilities >> it intends to provide, except as are already addressed by the current >> Internet network security suite. >> >> ==> IMHO, BTNS *must* consider NAT or NAPT implications. Folks want this >> protocol to be useful across NATs.. Maybe that should say BTNS will work over whatever IPsec/NAPT that's being proposed. I really don't see why that wouldn't work, but I've never investigated that claim. (Maybe losing tunnel mode?) >> PKI4IPsec is an IETF WG focused on providing an automatic >> infrastructure for the configuration of Internet security services, >> e.g., to assist in deploying signed certificates and CA information >> [7]. >> >> ==> I reviewed pki4ipsec's profile doc, and according to doc author, >> this would be a mischaracterization of their target audience. The intended >> recipient of that spec, at least, was pki4ipsec implementors, not protocol >> users, deployers or application level users. Maybe reword (this isn't >> optimal but couldn't think of anything better): >> >> PKI4IPsec is an IETF WG focused on specifying a profile for pki4ipsec >> implementers on ways to bind PKI information to IPsec [7]. I'll replace it with your text. Thanks! >> semi-editorial >> -------------- >> >> For higher layer protocols with full, symmetric authentication at the >> application layer, e.g., TLS, pre-shared keys, etc., S-CBB allows >> those protocols to use those credentials and exchanges to bind to >> BTNS-IPsec, protecting the transport and network layer protocols in >> addition to the application data. >> >> ==> umm.. in most cases (e.g., web or IMAP access), the use of TLS >> rarely implies symmetric authentication, but rather that's obtained >> only when the clients also use certificates (not that often). Or >> maybe you include password or similar rather weak form of >> authentication under "symmetric" as well... Yes, but that doesn't mean one cannot use TLS in a symmetric manner. :-) >> 9.1. Normative References >> >> (none) >> >> ==> as per definitions of >> http://www.ietf.org/IESG/STATEMENTS/iesg-statement-normative-informative-references.txt >> there should probably be some normative references. Maybe 4301 & 4306. I'll check with Joe and David. >> [14] Richardson, M., "Opportunistic Encryption using The Internet >> Key Exchange (IKE)," (expired, was work in progress), >> draft-richardson-ipsec-opportunistic-17, Jan. 2005. >> >> ==> this is now RFC 4322. Noted. yushun From touch at ISI.EDU Mon May 8 10:03:36 2006 From: touch at ISI.EDU (Joe Touch) Date: Mon, 08 May 2006 10:03:36 -0700 Subject: [anonsec] forwarded from Pekka Savola Message-ID: <445F79E8.5070902@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Forwarded on behalf of Pekka Savola: - ------------------------------------------- Hi, (Not subscribed, hopefully this gets through..) I had a flight, so I ended reading a couple of drafts in the interest of providing early out-of-WG review. The doc was mostly in OK shape, though it wasn't clear whether the scenarios were the ones thought about by BTNS proponents rather than having been proposed by folks actually designing applications.. substantial - ----------- BTNS reduces vulnerability after associations have been established to attacks from parties not participating in the association. This helps protect systems from low-effort attacks on sessions or connections involving higher levels of resources. ==>the doc mostly discusses TCP RST attacks, maybe it should discuss ICMP attacks a bit too as those are in most cases much easier to launch than TCP-RST attacks. It is not clear to me whether IPsec includes sufficient mandatory-to-implement, enabled-by-default protections to this. 4.6. Benefits BTNS raises the level of effort for many types of network or transport layer attacks. Casual, simple packet attacks need to be augmented to full associations and connection establishment for SAB, so that an attacker must perform as much work as regular host. SAB thus raises the effort for a DDOS attack to that of emulating a flash crowd. For open services, there may be no way to distinguish such a DDOS attack from a legitimate flash crowd anyway. ==> AFAICS, this text is too simplistic. It seems to assume that non-BTNS mode of connecting to the service is not supported, i.e., BTNS is deployed and enabled everywhere. What is the transition strategy to using BTNS? The use of BTNS means that more traffic will require cryptographic operations. Receivers will observe increased processing load in decrypting and/or verifying incoming traffic as a result. Although this may itself present a substantial impediment to deployment, it is a challenge to all cryptographically protected communication systems. The use of crypto increases the load on those receiving protected traffic; this document does not address the impact BTNS has on such load. ==> you don't seem to discuss the fact that the set-up of BTNS requires significant number of round-trips, which may or may not be an issue for ome kinds of applications, especially for links with high latency. A man-in-the-middle attack on IPsec with CBB is discovered later than if IKE authentication were used. A man in the middle cannot subvert IKE authentication, and hence an attempt to attack it via use of two separate security associations will cause an IKE authentication failure. With CBB, the BTNS-IKE step will succeed because it is unauthenticated, and the security association will be set up. The man in the middle will not be discovered until the higher layer authentication fail after more resources have been invested in this session. Nonetheless, this is an improvement over the alternative of minimizing the configuration of IPsec by using a group pre-shared key, which provides no defense against man-in-the-middle attacks among the nodes sharing the key. ==> Did I understand correctly that MITM is discovered and session is taken down after the MITM attacker has been able to obtain passwords (or whatever) from higher-layer authentication? This sounds a bit bleak. It's of course better than nothing, but when designing or using higher-layer protocols, in the future the choice might be between using (say) TLS or using CBB-BTNS at lower layer -- and depending on whether the higher layer authentication leaks any secrets, NOT using BTNS might be a better choice (again, depending on the authentication type). In any case, the higher layer authentication information leaking (or lack thereof) and implications on BTNS applicability should be discussed explicitly. 6.1. Issues Not Addressed BTNS does not consider the impact of NAT or NAPT on the capabilities it intends to provide, except as are already addressed by the current Internet network security suite. ==> IMHO, BTNS *must* consider NAT or NAPT implications. Folks want this protocol to be useful across NATs. PKI4IPsec is an IETF WG focused on providing an automatic infrastructure for the configuration of Internet security services, e.g., to assist in deploying signed certificates and CA information [7]. ==> I reviewed pki4ipsec's profile doc, and according to doc author, this would be a mischaracterization of their target audience. The intended recipient of that spec, at least, was pki4ipsec implementors, not protocol users, deployers or application level users. Maybe reword (this isn't optimal but couldn't think of anything better): PKI4IPsec is an IETF WG focused on specifying a profile for pki4ipsec implementers on ways to bind PKI information to IPsec [7]. semi-editorial - -------------- For higher layer protocols with full, symmetric authentication at the application layer, e.g., TLS, pre-shared keys, etc., S-CBB allows those protocols to use those credentials and exchanges to bind to BTNS-IPsec, protecting the transport and network layer protocols in addition to the application data. ==> umm.. in most cases (e.g., web or IMAP access), the use of TLS rarely implies symmetric authentication, but rather that's obtained only when the clients also use certificates (not that often). Or maybe you include password or similar rather weak form of authentication under "symmetric" as well... 9.1. Normative References (none) ==> as per definitions of http://www.ietf.org/IESG/STATEMENTS/iesg-statement-normative-informative-references.txt there should probably be some normative references. [14] Richardson, M., "Opportunistic Encryption using The Internet Key Exchange (IKE)," (expired, was work in progress), draft-richardson-ipsec-opportunistic-17, Jan. 2005. ==> this is now RFC 4322. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEX3noE5f5cImnZrsRAuI4AKCrWNdlge9PeGEFyvgo9AeI0kopTACg4qwI LdY8SMdzAxPOt0AJQD0uKUs= =dUJi -----END PGP SIGNATURE----- From touch at ISI.EDU Mon May 8 10:26:31 2006 From: touch at ISI.EDU (Joe Touch) Date: Mon, 08 May 2006 10:26:31 -0700 Subject: [anonsec] forwarded from Pekka Savola In-Reply-To: <445F79E8.5070902@isi.edu> References: <445F79E8.5070902@isi.edu> Message-ID: <445F7F47.2010709@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Some comments: Most of the feedback below will be addressed in an upcoming revision, with exceptions as noted below. Feedback from the group is solicited on those. Joe Joe Touch wrote: > Forwarded on behalf of Pekka Savola: ... > substantial > ----------- > > BTNS reduces vulnerability after associations have been established > to attacks from parties not participating in the association. This > helps protect systems from low-effort attacks on sessions or > connections involving higher levels of resources. > > ==>the doc mostly discusses TCP RST attacks, maybe it should discuss > ICMP attacks a bit too as those are in most cases much easier to launch > than TCP-RST attacks. It is not clear to me whether IPsec includes > sufficient mandatory-to-implement, enabled-by-default protections to this. We should be more specific about protecting the packets of the transport protocol; ICMP issues should be addressed a bit, but are likely out of scope even for IPsec. > 6.1. Issues Not Addressed > BTNS does not consider the impact of NAT or NAPT on the capabilities > it intends to provide, except as are already addressed by the current > Internet network security suite. > > ==> IMHO, BTNS *must* consider NAT or NAPT implications. Folks want > this protocol to be useful across NATs. The interaction between IPsec and NAT/NAPT is already discussed in other documents. As others have stated, though, NAT is exactly the kind of attack that IPsec was designed to detect. > PKI4IPsec is an IETF WG focused on providing an automatic > infrastructure for the configuration of Internet security services, > e.g., to assist in deploying signed certificates and CA information > [7]. > > ==> I reviewed pki4ipsec's profile doc, and according to doc author, > this would be a mischaracterization of their target audience. The > intended recipient of that spec, at least, was pki4ipsec implementors, > not protocol users, deployers or application level users. Maybe reword > (this isn't optimal but couldn't think of anything better): > > PKI4IPsec is an IETF WG focused on specifying a profile for pki4ipsec > implementers on ways to bind PKI information to IPsec [7]. That's self-referential, which is unfortunate for a definition. What are pki4ipsec implementers trying to do? isn't "bind PKI information to IPsec" similar enough to the explanation offered? (if not, a rewording of that explanation would be more useful, esp one that could avoid using pki4ipsec and/or PKI in the definition). > 9.1. Normative References > > (none) > > ==> as per definitions of > http://www.ietf.org/IESG/STATEMENTS/iesg-statement-normative-informative-references.txt That's an IESG statement; the current RFC-Editor procedures are in 2222bis. Sec 2.7 of that indicates: Within an RFC, references to other documents fall into two general categories: "normative" and "informative". Normative references specify documents that must be read to understand or implement the technology in the new RFC, or whose technology must be present for the technology in the new RFC to work. ... even the IESG statement states: Note 3: The normative/informative distinction is relevant in any document that amounts to a technical specification, even if its intended status is Experimental or Informational. This isn't a tech specification; that's the reason all references are informative. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEX39HE5f5cImnZrsRAsaoAKC04kHrEPgnjwVpdjxWj+xqJstDOQCgthhn ahfow7k5e/yIV4SsYbgN9jQ= =pbc+ -----END PGP SIGNATURE----- From Nicolas.Williams at sun.com Mon May 8 10:49:05 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 8 May 2006 12:49:05 -0500 Subject: [anonsec] BTNS prob/applic -02 review (Re: BTNS mailing list auto-rejection from non-subscribers) In-Reply-To: <445B9936.5010107@isi.edu> References: <445B9936.5010107@isi.edu> Message-ID: <20060508174905.GA23410@binky.Central.Sun.COM> On Fri, May 05, 2006 at 11:28:06AM -0700, Yu-Shun Wang wrote: > (Not sure if Pekka's mail gets to the list yet, but his > comments were all quoted below.) Joe forwarded it today. > >> From: Pekka Savola > >> Subject: BTNS prob/applic -02 review > >> Date: Wed, 3 May 2006 13:10:24 +0300 (EEST) > > >> A man-in-the-middle attack on IPsec with CBB is discovered later than > >> if IKE authentication were used. A man in the middle cannot subvert > >> IKE authentication, and hence an attempt to attack it via use of two > >> separate security associations will cause an IKE authentication > >> failure. With CBB, the BTNS-IKE step will succeed because it is > >> unauthenticated, and the security association will be set up. The > >> man in the middle will not be discovered until the higher layer > >> authentication fail after more resources have been invested in this > >> session. Nonetheless, this is an improvement over the alternative of > >> minimizing the configuration of IPsec by using a group pre-shared > >> key, which provides no defense against man-in-the-middle attacks > >> among the nodes sharing the key. > >> > >> ==> Did I understand correctly that MITM is discovered and session is > >> taken down after the MITM attacker has been able to obtain passwords > >> (or whatever) from higher-layer authentication? This sounds a bit > >> bleak. It's of course better than nothing, but when designing or > >> using higher-layer protocols, in the future the choice might be > >> between using (say) TLS or using CBB-BTNS at lower layer -- and > >> depending on whether the higher layer authentication leaks any > >> secrets, NOT using BTNS might be a better choice (again, depending on > >> the authentication type). > >> > >> In any case, the higher layer authentication information leaking (or > >> lack thereof) and implications on BTNS applicability should be > >> discussed explicitly. > > No. Nico or David specifically corrected me that channel > binding should (or must) not reveal passwords in the upper > layer authentication. So we should make that clear, but the > details will be in Nico's doc. The application-layer authentication protocol is whatever it is. If it's something that provides attackers with password-derived material that can be attacked offline then an MITM, though detectable[*], will make out with something useful. OTOH, if it's a protocol that does not have such a weakness then MITMs can be detected and they cause little or no harm that they couldn't by trying to be MITMs at the application layer in a world with no IPsec. [*] If the application-layer authentication protocol is sufficiently weak then MITMs may be difficult to distinguish from loss of connectivity or peer reboot. E.g., Kerberos V AP exchanges would leak little other than the target's krb5 principal name, while Kerberos V AS exchanges using PA-ENC- TIMESTAMP pre-authentication would leak material that can then be attacked offline. So, yes, this needs to be called out in security considerations text, that what an active attacker can get away with in the channel-binding BTNS use cases depends on the application layer authentication protocol. > >> 6.1. Issues Not Addressed > >> BTNS does not consider the impact of NAT or NAPT on the capabilities > >> it intends to provide, except as are already addressed by the current > >> Internet network security suite. > >> > >> ==> IMHO, BTNS *must* consider NAT or NAPT implications. Folks want this > >> protocol to be useful across NATs.. > > Maybe that should say BTNS will work over whatever > IPsec/NAPT that's being proposed. I really don't > see why that wouldn't work, but I've never investigated > that claim. (Maybe losing tunnel mode?) BTNS is mostly orthogonal to NAT issues here because BTNS is primarily about peer authentication in IKE and IPsec policy. Applications using the new APIs may, by tying IDs to addresses [at the app layer], cause problems with NAT, but this too is not specific to BTNS (though it should be noted!). Michael may want to comment here as well. > >> semi-editorial > >> -------------- > >> > >> For higher layer protocols with full, symmetric authentication at the > >> application layer, e.g., TLS, pre-shared keys, etc., S-CBB allows > >> those protocols to use those credentials and exchanges to bind to > >> BTNS-IPsec, protecting the transport and network layer protocols in > >> addition to the application data. > >> > >> ==> umm.. in most cases (e.g., web or IMAP access), the use of TLS > >> rarely implies symmetric authentication, but rather that's obtained > >> only when the clients also use certificates (not that often). Or > >> maybe you include password or similar rather weak form of > >> authentication under "symmetric" as well... > > Yes, but that doesn't mean one cannot use TLS in a symmetric > manner. :-) Er, I think the thing about "full, symmetric authentication at the application layer" bit is wrong -- channel binding can be useful even if the application layer authentication protocol does not provide mutual authentication, as long as it authenticates one peer and can be bound to IPsec channels. Nico -- From kent at bbn.com Mon May 8 15:02:35 2006 From: kent at bbn.com (Stephen Kent) Date: Mon, 8 May 2006 18:02:35 -0400 Subject: [anonsec] forwarded from Pekka Savola In-Reply-To: <445F7F47.2010709@isi.edu> References: <445F79E8.5070902@isi.edu> <445F7F47.2010709@isi.edu> Message-ID: At 10:26 AM -0700 5/8/06, Joe Touch wrote: >... > > ==>the doc mostly discusses TCP RST attacks, maybe it should discuss >> ICMP attacks a bit too as those are in most cases much easier to launch >> than TCP-RST attacks. It is not clear to me whether IPsec includes >> sufficient mandatory-to-implement, enabled-by-default protections to this. > >We should be more specific about protecting the packets of the transport >protocol; ICMP issues should be addressed a bit, but are likely out of >scope even for IPsec. RFC 4301 discusses dealing with ICMP traffic in a fair amount of detail. Steve From touch at ISI.EDU Mon May 8 15:36:08 2006 From: touch at ISI.EDU (Joe Touch) Date: Mon, 08 May 2006 15:36:08 -0700 Subject: [anonsec] forwarded from Pekka Savola In-Reply-To: References: <445F79E8.5070902@isi.edu> <445F7F47.2010709@isi.edu> Message-ID: <445FC7D8.2010505@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen Kent wrote: > At 10:26 AM -0700 5/8/06, Joe Touch wrote: >> ... >> > ==>the doc mostly discusses TCP RST attacks, maybe it should discuss >>> ICMP attacks a bit too as those are in most cases much easier to launch >>> than TCP-RST attacks. It is not clear to me whether IPsec includes >>> sufficient mandatory-to-implement, enabled-by-default protections to >>> this. >> >> We should be more specific about protecting the packets of the transport >> protocol; ICMP issues should be addressed a bit, but are likely out of >> scope even for IPsec. > > RFC 4301 discusses dealing with ICMP traffic in a fair amount of detail. > > Steve Yes; that would be the thing to cite and/or summarize. In general, it seems like 4301: - indicates when to send (or not send) ICMPs which is not as relevant to this discussion - indicates that it is important to ignore incoming ICMPs (or at least some types thereof) if security is paramount (e.g., in Sec. 6) The latter seems more relevant; I was hinting above more that IPsec doesn't try to authenticate ICMPs from routers, so use of IPsec doesn't itself provide protection from ICMP attacks. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEX8fYE5f5cImnZrsRAhRLAKC3tHDvSgpboiPUgZtCBIzvqUclLgCdH/Jn lMXejNAQhmlL2q5ujNyJtqc= =Sk7W -----END PGP SIGNATURE----- From Nicolas.Williams at sun.com Mon May 8 15:57:54 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 8 May 2006 17:57:54 -0500 Subject: [anonsec] forwarded from Pekka Savola In-Reply-To: <445FC7D8.2010505@isi.edu> References: <445F79E8.5070902@isi.edu> <445F7F47.2010709@isi.edu> <445FC7D8.2010505@isi.edu> Message-ID: <20060508225754.GK28062@binky.Central.Sun.COM> On Mon, May 08, 2006 at 03:36:08PM -0700, Joe Touch wrote: > In general, it seems like 4301: > > - indicates when to send (or not send) ICMPs > which is not as relevant to this discussion > > - indicates that it is important to ignore incoming ICMPs > (or at least some types thereof) if security is paramount > (e.g., in Sec. 6) > > The latter seems more relevant; I was hinting above more that IPsec > doesn't try to authenticate ICMPs from routers, so use of IPsec doesn't > itself provide protection from ICMP attacks. Really? If you could negotiate an SA pair between two nodes you would accept unprotected port unreachable messages? I don't think I would. Nico -- From Nicolas.Williams at sun.com Mon May 8 16:38:56 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 8 May 2006 18:38:56 -0500 Subject: [anonsec] BTNS prob/applic -02 review (Re: BTNS mailing list auto-rejection from non-subscribers) In-Reply-To: <20060508174905.GA23410@binky.Central.Sun.COM> References: <445B9936.5010107@isi.edu> <20060508174905.GA23410@binky.Central.Sun.COM> Message-ID: <20060508233856.GL28062@binky.Central.Sun.COM> On Mon, May 08, 2006 at 12:49:05PM -0500, Nicolas Williams wrote: Pekka> ==> Did I understand correctly that MITM is discovered and session is Pekka> taken down after the MITM attacker has been able to obtain passwords Pekka> (or whatever) from higher-layer authentication? This sounds a bit Pekka> bleak. It's of course better than nothing, but when designing or Pekka> using higher-layer protocols, in the future the choice might be Pekka> between using (say) TLS or using CBB-BTNS at lower layer -- and Pekka> depending on whether the higher layer authentication leaks any Pekka> secrets, NOT using BTNS might be a better choice (again, depending on Pekka> the authentication type). Pekka> Pekka> In any case, the higher layer authentication information leaking (or Pekka> lack thereof) and implications on BTNS applicability should be Pekka> discussed explicitly. I addressed some of this earlier, but I didn't address the part about TLS being better than CBB-BTNS w.r.t. to application layer authentication protocol leaks. I'll make several points w.r.t. to that: - As I mentioned, there will be situations where the app-layer authen protocol leaks nothing much (e.g., Kerberos AP exchanges), and in these case the appeal of BTNS over TLS is that ESP/AH are much closer to the wire, and, more importantly, below RDDP, thus more processing can be offloaded to NICs. - Also, applications could do enrolment/leap-of-faith, where a peer's BTNS public key is learned and used to provide peer authentication via BTNS in subsequent exchanges. - When you say TLS you seem to mean "TLS with server certs." BTNS can support assymetric authentication as well. What's difficult about assymetric authentication is that you have to pre-exchange something by which the client can authenticate the server, such as CA root certs; of course, TLS too has cipher suites with no user or server authentication. So does TLS have anything on BTNS? But I agree that we have to carefully document security considerations for CBB-BTNS applications. From touch at ISI.EDU Mon May 8 16:56:44 2006 From: touch at ISI.EDU (Joe Touch) Date: Mon, 08 May 2006 16:56:44 -0700 Subject: [anonsec] forwarded from Pekka Savola In-Reply-To: <20060508225754.GK28062@binky.Central.Sun.COM> References: <445F79E8.5070902@isi.edu> <445F7F47.2010709@isi.edu> <445FC7D8.2010505@isi.edu> <20060508225754.GK28062@binky.Central.Sun.COM> Message-ID: <445FDABC.3070407@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nicolas Williams wrote: > On Mon, May 08, 2006 at 03:36:08PM -0700, Joe Touch wrote: >> In general, it seems like 4301: >> >> - indicates when to send (or not send) ICMPs >> which is not as relevant to this discussion >> >> - indicates that it is important to ignore incoming ICMPs >> (or at least some types thereof) if security is paramount >> (e.g., in Sec. 6) >> >> The latter seems more relevant; I was hinting above more that IPsec >> doesn't try to authenticate ICMPs from routers, so use of IPsec doesn't >> itself provide protection from ICMP attacks. > > Really? If you could negotiate an SA pair between two nodes you would > accept unprotected port unreachable messages? I don't think I would. > > Nico ICMPs from the destination are one thing; ICMPs from the middle of the network are different. IPsec doesn't say how to protect those, only that those probably need to be dropped. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEX9q8E5f5cImnZrsRAgj6AKDqbpTXAc/68zkj7M1O6Kr8oyVCAQCfSPLA vEohRGi+sX1zMh34wXA/cnY= =AL6S -----END PGP SIGNATURE----- From pekkas at netcore.fi Mon May 8 22:46:01 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 9 May 2006 08:46:01 +0300 (EEST) Subject: [anonsec] forwarded from Pekka Savola In-Reply-To: <445FDABC.3070407@isi.edu> References: <445F79E8.5070902@isi.edu> <445F7F47.2010709@isi.edu> <445FC7D8.2010505@isi.edu> <20060508225754.GK28062@binky.Central.Sun.COM> <445FDABC.3070407@isi.edu> Message-ID: On Mon, 8 May 2006, Joe Touch wrote: >>> - indicates that it is important to ignore incoming ICMPs >>> (or at least some types thereof) if security is paramount >>> (e.g., in Sec. 6) >>> >>> The latter seems more relevant; I was hinting above more that IPsec >>> doesn't try to authenticate ICMPs from routers, so use of IPsec doesn't >>> itself provide protection from ICMP attacks. >> >> Really? If you could negotiate an SA pair between two nodes you would >> accept unprotected port unreachable messages? I don't think I would. > > ICMPs from the destination are one thing; ICMPs from the middle of the > network are different. IPsec doesn't say how to protect those, only that > those probably need to be dropped. In other words, there is no mandatory-to-implement, enabled-by-default IPsec protection which would not break legitimate uses such as traceroute, ICMP soft-errors for TCP failover adjustment, etc. There was actually a debate between me and Stephen about this on RPSEC list this January [*]. I acknowledge the IPsec spec gives a couple of mostly un- or under-specified knobs for the administrators to play with when setting IPsec policies, but no good mechanism which wouldn't throw out the baby with the bathwater. [*] if interested, you may take a look at the thread around: http://www1.ietf.org/mail-archive/web/rpsec/current/msg01562.html -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From touch at ISI.EDU Tue May 9 10:06:40 2006 From: touch at ISI.EDU (Joe Touch) Date: Tue, 09 May 2006 10:06:40 -0700 Subject: [anonsec] forwarded from Pekka Savola In-Reply-To: References: <445F79E8.5070902@isi.edu> <445F7F47.2010709@isi.edu> <445FC7D8.2010505@isi.edu> <20060508225754.GK28062@binky.Central.Sun.COM> <445FDABC.3070407@isi.edu> Message-ID: <4460CC20.1030306@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Pekka Savola wrote: > On Mon, 8 May 2006, Joe Touch wrote: >>>> - indicates that it is important to ignore incoming ICMPs >>>> (or at least some types thereof) if security is paramount >>>> (e.g., in Sec. 6) >>>> >>>> The latter seems more relevant; I was hinting above more that IPsec >>>> doesn't try to authenticate ICMPs from routers, so use of IPsec doesn't >>>> itself provide protection from ICMP attacks. >>> >>> Really? If you could negotiate an SA pair between two nodes you would >>> accept unprotected port unreachable messages? I don't think I would. >> >> ICMPs from the destination are one thing; ICMPs from the middle of the >> network are different. IPsec doesn't say how to protect those, only that >> those probably need to be dropped. > > In other words, there is no mandatory-to-implement, enabled-by-default > IPsec protection which would not break legitimate uses such as > traceroute, ICMP soft-errors for TCP failover adjustment, etc. IPsec protects communication between two endpoints. It doesn't protect messages received from any arbitrary router in a network. Yes, since these systems depend on such messages, they would break - but, FWIW, they are often filtered for other reasons as well. > There was actually a debate between me and Stephen about this on RPSEC > list this January [*]. I acknowledge the IPsec spec gives a couple of > mostly un- or under-specified knobs for the administrators to play with > when setting IPsec policies, but no good mechanism which wouldn't throw > out the baby with the bathwater. If you want to configure an entire network's routers with keys and have them sign their ICMPs, this would work fine. The issue is one of deployment, not capability. This isn't - as I noted before - an IPsec issue, IMO. > [*] if interested, you may take a look at the thread around: > http://www1.ietf.org/mail-archive/web/rpsec/current/msg01562.html > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEYMwgE5f5cImnZrsRApOsAJ4nc6ouY0Kf1ncQRYgzYdxzoLQYEwCfc4+P euFA2qh8xpcF1MbohOYRVeA= =LpOW -----END PGP SIGNATURE----- From kent at bbn.com Fri May 12 15:21:33 2006 From: kent at bbn.com (Stephen Kent) Date: Fri, 12 May 2006 18:21:33 -0400 Subject: [anonsec] forwarded from Pekka Savola In-Reply-To: <445FC7D8.2010505@isi.edu> References: <445F79E8.5070902@isi.edu> <445F7F47.2010709@isi.edu> <445FC7D8.2010505@isi.edu> Message-ID: >.. >Yes; that would be the thing to cite and/or summarize. > >In general, it seems like 4301: > > - indicates when to send (or not send) ICMPs > which is not as relevant to this discussion > > - indicates that it is important to ignore incoming ICMPs > (or at least some types thereof) if security is paramount > (e.g., in Sec. 6) > >The latter seems more relevant; I was hinting above more that IPsec >doesn't try to authenticate ICMPs from routers, so use of IPsec doesn't >itself provide protection from ICMP attacks. > >Joe You're right that one would not expect an end system to have SAs with routers along the path. Thus the details provided about how to deal with ICMP traffic emitted over or received via such SAs are not so relevant. However, we do provide explicit advice about screening unauthenticated ICMPs to avoid some types of attacks, e.g., to not allow a PMTU to be set below some defined threshold. Steve From touch at ISI.EDU Fri May 12 15:59:08 2006 From: touch at ISI.EDU (Joe Touch) Date: Fri, 12 May 2006 15:59:08 -0700 Subject: [anonsec] forwarded from Pekka Savola In-Reply-To: References: <445F79E8.5070902@isi.edu> <445F7F47.2010709@isi.edu> <445FC7D8.2010505@isi.edu> Message-ID: <4465133C.3030406@isi.edu> Stephen Kent wrote: >> .. >> Yes; that would be the thing to cite and/or summarize. >> >> In general, it seems like 4301: >> >> - indicates when to send (or not send) ICMPs >> which is not as relevant to this discussion >> >> - indicates that it is important to ignore incoming ICMPs >> (or at least some types thereof) if security is paramount >> (e.g., in Sec. 6) >> >> The latter seems more relevant; I was hinting above more that IPsec >> doesn't try to authenticate ICMPs from routers, so use of IPsec doesn't >> itself provide protection from ICMP attacks. >> >> Joe > > You're right that one would not expect an end system to have SAs with > routers along the path. Thus the details provided about how to deal with > ICMP traffic emitted over or received via such SAs are not so relevant. > However, we do provide explicit advice about screening unauthenticated > ICMPs to avoid some types of attacks, e.g., to not allow a PMTU to be > set below some defined threshold. > > Steve Yes - Fernando and I reviewed that issue; he's updating his ICMP attacks doc to discuss this, and I'm cite 4301 as well as his doc in this regard in the update. Joe