From lha at kth.se Tue Dec 5 03:15:30 2006 From: lha at kth.se (=?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?=) Date: Tue, 5 Dec 2006 12:15:30 +0100 Subject: [anonsec] WG-LC: draft-ietf-btns-prob-and-applic-04 In-Reply-To: <03E70066-F9F6-492D-A58D-3CD5971CDDF1@it.su.se> References: <03E70066-F9F6-492D-A58D-3CD5971CDDF1@it.su.se> Message-ID: <43B0AACD-E6AE-4270-8424-F9EB198129D8@kth.se> 20 nov 2006 kl. 17.12 skrev Love H?rnquist ?strand: > To verify the consensus of the wg and catch the the last errors before > sending of the document to IESG I'm issuing a WG last call of > > Problem and Applicability Statement > for Better Than Nothing Security (BTNS) > > http://www.ietf.org/internet-drafts/draft-ietf-btns-prob-and- > applic-04.txt I've so far not seen one comment on the document, neither positive nor negative. Love From Nicolas.Williams at sun.com Sun Dec 3 20:30:59 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Sun, 3 Dec 2006 22:30:59 -0600 Subject: [anonsec] WG-LC: draft-ietf-btns-prob-and-applic-04 In-Reply-To: <43B0AACD-E6AE-4270-8424-F9EB198129D8@kth.se> Message-ID: <20061204043059.GH5938@binky.Central.Sun.COM> I think this document is mostly quite fine and almost ready. Besides some minor editing I think that some text on authentication assymetry in CBB could be removed. Comments below. > Abstract > > The Internet network security protocol suite, IPsec, consisting of > IKE, ESP, and AH, currently requires authentication via IKE of ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Does it? > network layer entities to bootstrap security. This authentication can > be based on mechanisms such as pre-shared symmetric keys, > certificates and associated asymmetric keys, or the use of Kerberos. > The need for authentication information and its associated identities > between network layer entities can be a significant obstacle to > deploying network security. This document explains the rationale for > extending the Internet network security suite to enable use of IPsec > security mechanisms without full IKE authentication. These ^^^^^^^^^^^^^^^^^^^^^^^ Can we find a better way to say this? "without actually authenticating IKE peers"? > extensions are intended to protect communication "better than ^ with > nothing" (BTNS) on their own (Stand Alone BTNS, or SAB), and may be ^ security > useful in providing network layer security that can be authenticated > by higher layers in the protocol stack, called Channel Bound BTNS > (CBB). This document also explains situations in which use of SAB and > CBB extensions are appropriate and can achieve their intended > benefit. Also, s/on their own//. > Consider the case of transport protocols. Increases in network > performance and the use of long-lived connections have resulted in > increased vulnerability of connection-oriented transport protocols to > attacks. Such attacks can be resisted to some extent within the > transport layer by performing additional validity checks, requiring > additional mechanisms added to each transport protocol. More direct ^ ^ ^^^^^^ that be s/direct/comprehensive/ > security can be provided, either at the transport or network layer. > This security currently requires a predetermined way to authenticate s/This security/Obtaining comprehensive security/ > the endpoints with a pre-shared secret, a public key infrastructure > (PKI) with shared trusted anchors, or an external key coordination ^^^^^^^^^^^ s/an external/other/ > system such as Kerberos. In all cases, secure communication can be > established only after endpoints mutually assert authenticated s/assert authenticated/authenticate each other's/ > identities as specified in their access control policies. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ and pass their access control policies > There is weaker notion of identity, one which is bootstrapped from > the session association itself. The identity doesn't mean "Bill > Smith" or "owner of shared secret X2YQ", but means something more > like "the entity with whom I have been communicating on connection > #23". Such identity is not invariant across associations, but because > it is invariant within an association it can still be used to provide > protection for that association. - I would add that it is possible, in some schemes (specifically the scheme in draft-btns-core), to refer to such an identity by a repeatable, non-spoofable handle. In draft-btns-core this would be a public key, and it is non-spoofable because it is bound into the "connection" by IKE. This is useful because it allows one to ask "is my peer on connection #32 the same as I had on connection #23 three days ago?" I believe this is mentioned later in the I-D, but it could stand being mentioned here where the topic of identity is broached. - Section 2.2 mentions the need, in CBB, for defining IPsec channels, but section 2.1 does not mention the need, in SAB, for either defining IPsec channels or LoF binding of BTNS peers to their addresses. A minor inconsistentcy since the topic is handled subsequently. - Section 2.2, s/where similar relates to/where similarity relates to/. - Section 2.4, > BTNS is not intended to protect the key exchange itself, so this > presents an opportunity for a man-in-the-middle attack or a well- > timed attack from other sources. Stand-alone BTNS is further not > intended to protect the endpoint from nodes masquerading as > legitimate clients but rather to raise the level of effort of an > attack to that of emulating a client. BTNS together with > authentication from higher layers in the stack can protect from such > masquerading, depending on how the authentication is coupled with the > BTNS associations, and at a later point in the protocol exchange. - Note that in CBB the key exchange is protected a posteriori, thus _detecting_ MITMs. This is quite similar to what happens in IKEv2. - Section 3.1: I would prefer most references to authentication a/symmetry in the application layer, in the CBB cases, be removed. Such as in the table that follows the first paragraph and the second part of bullet item 5 in the list that follows: > 5. Asymmetric CBB (A-CBB): one side lacks network layer > authentication information and possesses authentication at a > higher layer in the protocol stack; there are two variants, ^ stop here and delete the remainder. > Asymmetric IKE CBB(AI-CBB) where the other side possesses > conventional IKE-supported authentication, and asymmetric stand- > alone CBB (AS-CBB), where the other side lacks network layer > authentication information and lacks authentication at higher > layers - Section 3.1.3, remove this paragraph: > S-CCB could utilize application layer authentication, including ^^^ CBB > challenge/response PINs, such as used by S/Key in software or copy > protection dongles, or login passwords. I'm not sure where this came from, but it's neither quite right nor does it belong in this document. - Section 3.1.4. I'm rather confused by this one and I think that by and larger we can completely get rid of the distinction between S-CBB and A-CBB. What the application does for authentication and whether that is symmetric or not is really none of BTNS' business. We're trying to enable channel binding to BTNS -- that is, we're trying to say that BTNS is applicable to channel binding applications. Beyond that this I-D is simply not the right place to discuss the particulars of what happens at the application layer beyond saying that authentication at the app layer is to be bound to a BTNS channel. Nor is this I-D the right place to discuss the applicability of channel binding generally. So I think this section should be removed and the distinction of S-CBB vs. A-CBB should be removed as well. - Section 3.4: > SAB CBB > ------------------------------------------------------------- > Uses Open services Password/PIN services > Peer-to-peer > Zero-config. infrastructure Where did "Password/PIN services" come from? What does that mean? Nico -- From touch at ISI.EDU Tue Dec 5 20:04:50 2006 From: touch at ISI.EDU (Joe Touch) Date: Tue, 05 Dec 2006 20:04:50 -0800 Subject: [anonsec] WG-LC: draft-ietf-btns-prob-and-applic-04 In-Reply-To: <43B0AACD-E6AE-4270-8424-F9EB198129D8@kth.se> References: <03E70066-F9F6-492D-A58D-3CD5971CDDF1@it.su.se> <43B0AACD-E6AE-4270-8424-F9EB198129D8@kth.se> Message-ID: <45764162.8030602@isi.edu> I like it, but I'm biased ;-) Can others please post? Joe Love H?rnquist ?strand wrote: > 20 nov 2006 kl. 17.12 skrev Love H?rnquist ?strand: > >> To verify the consensus of the wg and catch the the last errors before >> sending of the document to IESG I'm issuing a WG last call of >> >> Problem and Applicability Statement >> for Better Than Nothing Security (BTNS) >> >> http://www.ietf.org/internet-drafts/draft-ietf-btns-prob-and- >> applic-04.txt > > I've so far not seen one comment on the document, neither positive > nor negative. > > Love > > > > _______________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/anonsec/attachments/20061205/32266cab/signature.bin From julien.IETF at laposte.net Wed Dec 6 09:05:04 2006 From: julien.IETF at laposte.net (Julien Laganier) Date: Wed, 6 Dec 2006 18:05:04 +0100 Subject: [anonsec] WG-LC: draft-ietf-btns-prob-and-applic-04 In-Reply-To: <43B0AACD-E6AE-4270-8424-F9EB198129D8@kth.se> References: <03E70066-F9F6-492D-A58D-3CD5971CDDF1@it.su.se> <43B0AACD-E6AE-4270-8424-F9EB198129D8@kth.se> Message-ID: <200612061805.05197.julien.IETF@laposte.net> On Tuesday 05 December 2006 12:15, Love H?rnquist ?strand wrote: > 20 nov 2006 kl. 17.12 skrev Love H?rnquist ?strand: > > To verify the consensus of the wg and catch the > > the last errors before sending of the document to > > IESG I'm issuing a WG last call of > > > > Problem and Applicability > > Statement for Better Than Nothing Security (BTNS) > > > > http://www.ietf.org/internet-drafts/draft-ietf-btn > >s-prob-and- applic-04.txt > > I've so far not seen one comment on the document, > neither positive nor negative. I finally managed to read the document, and I thought it well written and ready to be sent to IESG. --julien From miika at iki.fi Fri Dec 8 02:41:08 2006 From: miika at iki.fi (Miika Komu) Date: Fri, 8 Dec 2006 12:41:08 +0200 (EET) Subject: [anonsec] WG-LC: draft-ietf-btns-prob-and-applic-04 In-Reply-To: <200612061805.05197.julien.IETF@laposte.net> References: <03E70066-F9F6-492D-A58D-3CD5971CDDF1@it.su.se> <43B0AACD-E6AE-4270-8424-F9EB198129D8@kth.se> <200612061805.05197.julien.IETF@laposte.net> Message-ID: On Wed, 6 Dec 2006, Julien Laganier wrote: > On Tuesday 05 December 2006 12:15, Love H?rnquist > ?strand wrote: >> 20 nov 2006 kl. 17.12 skrev Love H?rnquist ?strand: >>> To verify the consensus of the wg and catch the >>> the last errors before sending of the document to >>> IESG I'm issuing a WG last call of >>> >>> Problem and Applicability >>> Statement for Better Than Nothing Security (BTNS) >>> >>> http://www.ietf.org/internet-drafts/draft-ietf-btn >>> s-prob-and- applic-04.txt >> >> I've so far not seen one comment on the document, >> neither positive nor negative. > > I finally managed to read the document, and I thought > it well written and ready to be sent to IESG. Agree. Some editorial nits below. I had some troubles in understanding initially the loosely defined term "authentication" in the context of the draft but I think it is now more clear. Particularly, the term "PKI" is mentioned quite late in the draft, which is IMHO connected to the authentication term and to the motivation of the whole draft. HIP is mentioned in section 2.2.1 briefly. Perhaps you could also mention that HIP has implicit channel binding mechanisms and reference RFC4423, HIP base draft or draft-ietf-hip-applications-00. In addition, the claim "such modifications are, at best, temporary patches to the ubiquitous vulnerability to spoofing attacks" requires some further explanation at least in the context of HIP. -- Miika Komu http://www.iki.fi/miika/ From yushunwa at ISI.EDU Thu Dec 14 11:48:29 2006 From: yushunwa at ISI.EDU (Yu-Shun Wang) Date: Thu, 14 Dec 2006 11:48:29 -0800 Subject: [anonsec] WG-LC: draft-ietf-btns-prob-and-applic-04 In-Reply-To: <20061204043059.GH5938@binky.Central.Sun.COM> References: <20061204043059.GH5938@binky.Central.Sun.COM> Message-ID: <4581AA8D.1050101@isi.edu> Nicolas Williams wrote: > I think this document is mostly quite fine and almost ready. > > Besides some minor editing I think that some text on authentication > assymetry in CBB could be removed. > > Comments below. Thanks, Nico. I looked over the comments, but half way through, I realized these are for the -01 version. It has changed a lot since then :-). Most of the comments don't apply anymore or are referring to the wrong section numbers. Could you take a look at -04 and see if any of these problems still exists? Thanks, yushun >> Abstract >> >> The Internet network security protocol suite, IPsec, consisting of >> IKE, ESP, and AH, currently requires authentication via IKE of > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Does it? Hmm, that doesn't include the non-IKE cases with pre-shared secrets. I'll remove IKE from that sentence: "The Internet network security protocol suite, IPsec, consisting of IKE, ESP, and AH, currently requires authentication of network layer entities to bootstrap security. (...) " Preshared secrets are covered in the next sentence. >> network layer entities to bootstrap security. This authentication can >> be based on mechanisms such as pre-shared symmetric keys, >> certificates and associated asymmetric keys, or the use of Kerberos. > >> The need for authentication information and its associated identities >> between network layer entities can be a significant obstacle to >> deploying network security. This document explains the rationale for >> extending the Internet network security suite to enable use of IPsec >> security mechanisms without full IKE authentication. These > ^^^^^^^^^^^^^^^^^^^^^^^ > > Can we find a better way to say this? > > "without actually authenticating IKE peers"? I think we can just say "without authentication." Is that ok? >> extensions are intended to protect communication "better than > ^ > with >> nothing" (BTNS) on their own (Stand Alone BTNS, or SAB), and may be > ^ > security >> useful in providing network layer security that can be authenticated >> by higher layers in the protocol stack, called Channel Bound BTNS >> (CBB). This document also explains situations in which use of SAB and >> CBB extensions are appropriate and can achieve their intended >> benefit. > > Also, s/on their own//. I think these comments are for -01. It has changed since then. :-) >> Consider the case of transport protocols. Increases in network >> performance and the use of long-lived connections have resulted in >> increased vulnerability of connection-oriented transport protocols to >> attacks. Such attacks can be resisted to some extent within the >> transport layer by performing additional validity checks, requiring >> additional mechanisms added to each transport protocol. More direct > ^ ^ ^^^^^^ > that be > > s/direct/comprehensive/ >> security can be provided, either at the transport or network layer. >> This security currently requires a predetermined way to authenticate > > s/This security/Obtaining comprehensive security/ >> the endpoints with a pre-shared secret, a public key infrastructure >> (PKI) with shared trusted anchors, or an external key coordination > ^^^^^^^^^^^ > s/an external/other/ >> system such as Kerberos. In all cases, secure communication can be >> established only after endpoints mutually assert authenticated > > s/assert authenticated/authenticate each other's/ > >> identities as specified in their access control policies. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > and pass their access control policies > > >> There is weaker notion of identity, one which is bootstrapped from >> the session association itself. The identity doesn't mean "Bill >> Smith" or "owner of shared secret X2YQ", but means something more >> like "the entity with whom I have been communicating on connection >> #23". Such identity is not invariant across associations, but because >> it is invariant within an association it can still be used to provide >> protection for that association. > > - I would add that it is possible, in some schemes (specifically the > scheme in draft-btns-core), to refer to such an identity by a > repeatable, non-spoofable handle. In draft-btns-core this would be a > public key, and it is non-spoofable because it is bound into the > "connection" by IKE. > > This is useful because it allows one to ask "is my peer on connection > #32 the same as I had on connection #23 three days ago?" > > I believe this is mentioned later in the I-D, but it could stand > being mentioned here where the topic of identity is broached. > > > - Section 2.2 mentions the need, in CBB, for defining IPsec channels, > but section 2.1 does not mention the need, in SAB, for either defining > IPsec channels or LoF binding of BTNS peers to their addresses. A > minor inconsistentcy since the topic is handled subsequently. > > > - Section 2.2, s/where similar relates to/where similarity relates to/. > > > - Section 2.4, > >> BTNS is not intended to protect the key exchange itself, so this >> presents an opportunity for a man-in-the-middle attack or a well- >> timed attack from other sources. Stand-alone BTNS is further not >> intended to protect the endpoint from nodes masquerading as >> legitimate clients but rather to raise the level of effort of an >> attack to that of emulating a client. BTNS together with >> authentication from higher layers in the stack can protect from such >> masquerading, depending on how the authentication is coupled with the >> BTNS associations, and at a later point in the protocol exchange. > > - Note that in CBB the key exchange is protected a posteriori, thus > _detecting_ MITMs. This is quite similar to what happens in IKEv2. > > > - Section 3.1: I would prefer most references to authentication > a/symmetry in the application layer, in the CBB cases, be removed. > > Such as in the table that follows the first paragraph and the > second part of bullet item 5 in the list that follows: > >> 5. Asymmetric CBB (A-CBB): one side lacks network layer >> authentication information and possesses authentication at a >> higher layer in the protocol stack; there are two variants, > ^ > stop here and delete the > remainder. >> Asymmetric IKE CBB(AI-CBB) where the other side possesses >> conventional IKE-supported authentication, and asymmetric stand- >> alone CBB (AS-CBB), where the other side lacks network layer >> authentication information and lacks authentication at higher >> layers > > > > - Section 3.1.3, remove this paragraph: > >> S-CCB could utilize application layer authentication, including > ^^^ > CBB >> challenge/response PINs, such as used by S/Key in software or copy >> protection dongles, or login passwords. > > I'm not sure where this came from, but it's neither quite right nor > does it belong in this document. > > > - Section 3.1.4. I'm rather confused by this one and I think that by > and larger we can completely get rid of the distinction between S-CBB > and A-CBB. > > What the application does for authentication and whether that is > symmetric or not is really none of BTNS' business. We're trying to > enable channel binding to BTNS -- that is, we're trying to say that > BTNS is applicable to channel binding applications. > > Beyond that this I-D is simply not the right place to discuss the > particulars of what happens at the application layer beyond saying > that authentication at the app layer is to be bound to a BTNS > channel. > > Nor is this I-D the right place to discuss the applicability of > channel binding generally. > > So I think this section should be removed and the distinction of > S-CBB vs. A-CBB should be removed as well. > > > - Section 3.4: > >> SAB CBB >> ------------------------------------------------------------- >> Uses Open services Password/PIN services >> Peer-to-peer >> Zero-config. infrastructure > > Where did "Password/PIN services" come from? What does that mean? > > Nico From Nicolas.Williams at sun.com Thu Dec 14 12:26:17 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 14 Dec 2006 14:26:17 -0600 Subject: [anonsec] WG-LC: draft-ietf-btns-prob-and-applic-04 In-Reply-To: <4581AA8D.1050101@isi.edu> References: <20061204043059.GH5938@binky.Central.Sun.COM> <4581AA8D.1050101@isi.edu> Message-ID: <20061214202616.GY26175@binky.Central.Sun.COM> On Thu, Dec 14, 2006 at 11:48:29AM -0800, Yu-Shun Wang wrote: > Nicolas Williams wrote: > >I think this document is mostly quite fine and almost ready. > > > >Besides some minor editing I think that some text on authentication > >assymetry in CBB could be removed. > > > >Comments below. > > Thanks, Nico. I looked over the comments, but half way through, > I realized these are for the -01 version. It has changed a lot > since then :-). Most of the comments don't apply anymore or are > referring to the wrong section numbers. Could you take a look at > -04 and see if any of these problems still exists? Oh crap. From yushunwa at ISI.EDU Thu Dec 14 12:26:03 2006 From: yushunwa at ISI.EDU (Yu-Shun Wang) Date: Thu, 14 Dec 2006 12:26:03 -0800 Subject: [anonsec] WG-LC: draft-ietf-btns-prob-and-applic-04 In-Reply-To: References: <03E70066-F9F6-492D-A58D-3CD5971CDDF1@it.su.se> <43B0AACD-E6AE-4270-8424-F9EB198129D8@kth.se> <200612061805.05197.julien.IETF@laposte.net> Message-ID: <4581B35B.3080802@isi.edu> Hi, Miika, Thanks for the comments. Some answers inline... Miika Komu wrote: > On Wed, 6 Dec 2006, Julien Laganier wrote: >> I finally managed to read the document, and I thought >> it well written and ready to be sent to IESG. > > Agree. Some editorial nits below. > > I had some troubles in understanding initially the loosely defined term > "authentication" in the context of the draft but I think it is now more > clear. Particularly, the term "PKI" is mentioned quite late in the > draft, which is IMHO connected to the authentication term and to the > motivation of the whole draft. Yes, these terms are used in the context of IPsec, which I hope should be quite clear from the intro. But please let me know if any of the specific usage in the text is confusing. As for PKI, I think this is the relevant text (bottom of page 2): " Furthermore, authenticated credentials such as certificates signed by certification authorities (CA) can be cumbersome and expensive to obtain. " I hope we can get away with it without explaining what PKI is and the problems with PKI. But also feel free to comment and suggest text. :-) > HIP is mentioned in section 2.2.1 briefly. Perhaps you could also > mention that HIP has implicit channel binding mechanisms and reference > RFC4423, HIP base draft or draft-ietf-hip-applications-00. In addition, > the claim "such modifications are, at best, temporary patches to the > ubiquitous vulnerability to spoofing attacks" requires some further > explanation at least in the context of HIP. Agreed with HIP and channel binding part. But IMHO, these are more subtle (you said "implicit" :-)) points that probably should be covered in the CB doc for more details and comparison. Also noted the second point on "temporary patches" re. HIP: s/Such modifications/The TCP-specific modifications/ Would this work? Thanks, yushun