From rajiv_das at msn.com Thu Nov 3 04:53:09 2005 From: rajiv_das at msn.com (Rajiv Das) Date: Thu, 03 Nov 2005 18:23:09 +0530 Subject: [anonsec] Inputs Regarding BTNS P/A Document Message-ID: An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/anonsec/attachments/20051103/fce9950d/attachment.html From mcr at sandelman.ottawa.on.ca Sun Nov 6 06:15:41 2005 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Sun, 06 Nov 2005 06:15:41 -0800 Subject: [anonsec] opportunistic IPsec interoperability References: <20040909085202.GM1457@leitl.org> <20040909215027.GL1989@binky.central.sun.com> Message-ID: A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : http://www.postel.org/pipermail/anonsec/attachments/20051106/d5ef2052/attachment.bin From mcr at sandelman.ottawa.on.ca Sun Nov 6 06:57:56 2005 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Sun, 06 Nov 2005 06:57:56 -0800 Subject: [anonsec] my comments on the documents Message-ID: A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : http://www.postel.org/pipermail/anonsec/attachments/20051106/3d1f556b/attachment.bin From dbernard at ozonline.com.au Sun Nov 6 12:50:44 2005 From: dbernard at ozonline.com.au (Dan Bernardo) Date: Mon, 7 Nov 2005 07:50:44 +1100 Subject: [anonsec] my comments on the documents References: Message-ID: <002d01c5e313$c5d2fdb0$6401a8c0@IBM3600A6A6AC6> Hi, Can I get a copy of the doc or at least the link? It looks interesting to me. Thanks Dan ----- Original Message ----- From: "Michael Richardson" To: Sent: Monday, November 07, 2005 1:57 AM Subject: [anonsec] my comments on the documents > _______________________________________________ > > _____________________________________________________ > This mail has been virus scanned by Australia On Line > see http://www.australiaonline.net.au/mailscanning > From mcr at sandelman.ottawa.on.ca Sun Nov 6 13:09:45 2005 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Sun, 06 Nov 2005 13:09:45 -0800 Subject: [anonsec] what kind of phase 2 SAs are we negotiating? References: <20050408173500.GD5837@binky.Central.Sun.COM> <4256D2E5.1000603@isi.edu> Message-ID: A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : http://www.postel.org/pipermail/anonsec/attachments/20051106/4bc20c01/attachment.bin From mcr at sandelman.ottawa.on.ca Sun Nov 6 13:30:46 2005 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Sun, 06 Nov 2005 13:30:46 -0800 Subject: [anonsec] draft-williams-btns-00.txt References: <20050914055952.GF26789@binky.Central.Sun.COM> <4327F56A.6040102@piuha.net> <20050914144643.GB29692@binky.Central.Sun.COM> <1126714611.10426.49.camel@thunk> <4328ADD4.4070600@piuha.net> Message-ID: A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : http://www.postel.org/pipermail/anonsec/attachments/20051106/34943532/attachment.bin From mcr at sandelman.ottawa.on.ca Sun Nov 6 13:43:19 2005 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Sun, 06 Nov 2005 13:43:19 -0800 Subject: [anonsec] my comments on the documents References: Message-ID: A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : http://www.postel.org/pipermail/anonsec/attachments/20051106/c6b01253/attachment.bin From touch at ISI.EDU Sun Nov 6 14:15:37 2005 From: touch at ISI.EDU (Joe Touch) Date: Sun, 06 Nov 2005 14:15:37 -0800 Subject: [anonsec] my comments on the documents In-Reply-To: References: Message-ID: <436E8089.70502@isi.edu> Michael Richardson wrote: >>>>>> "Michael" == Michael Richardson writes: > Michael> Please change section 4.2: Opportunistic Encryption (OE) is a > Michael> system for automatic discovery of hosts willing to do a > Michael> BTNS-like encryption, with authentication being exchanged by > Michael> leveraging through existing use of the DNS. > > Please change section 4.2: Opportunistic Encryption (OE) is a > system for automatic discovery of hosts willing to do a BTNS-like encryption, > with authentication being exchanged by leveraging existing use of the DNS Sure, but the changes need to be a little more careful. In particular, most of BTNS focuses on what your own side does. Finding another side that is willing to do BTNS matters only if your own cert is not signed by a well-known CA; it has nothing to do with your decision to proceed with the cert of the other side without checking its CA. How does this 'automatic discovery' work, and how is it a variant of OE? (can you explain?) Finally, there's no need to use the DNS to exchange authentication in BTNS; that just inserts an extra intermediary to attack, and possibly a worse delay. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/anonsec/attachments/20051106/247dc175/signature.bin From touch at ISI.EDU Sun Nov 6 14:05:39 2005 From: touch at ISI.EDU (Joe Touch) Date: Sun, 06 Nov 2005 14:05:39 -0800 Subject: [anonsec] my comments on the documents In-Reply-To: <002d01c5e313$c5d2fdb0$6401a8c0@IBM3600A6A6AC6> References: <002d01c5e313$c5d2fdb0$6401a8c0@IBM3600A6A6AC6> Message-ID: <436E7E33.5070708@isi.edu> See: http://www.postel.org/rbridge Dan Bernardo wrote: > Hi, > > Can I get a copy of the doc or at least the link? > It looks interesting to me. > > Thanks > Dan > > ----- Original Message ----- > From: "Michael Richardson" > To: > Sent: Monday, November 07, 2005 1:57 AM > Subject: [anonsec] my comments on the documents > > >> _______________________________________________ >> >> _____________________________________________________ >> This mail has been virus scanned by Australia On Line >> see http://www.australiaonline.net.au/mailscanning >> > > _______________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/anonsec/attachments/20051106/028853e3/signature.bin From lha at it.su.se Sun Nov 6 17:02:03 2005 From: lha at it.su.se (=?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?=) Date: Sun, 6 Nov 2005 17:02:03 -0800 Subject: [anonsec] roberts comments on prob-and-applic-00 and -01 Message-ID: <2B4EB446-20F0-4AF8-AD24-3E5DAE706E0E@it.su.se> Hello Some time ago I asked some friends of mine to review the PS/AS documents. The night before leaving for IETF-64 I was over for dinner at Robert Burgess and he had some comments on the document, but since he haven't sent them to the list, I'm do it for him. The general comments was that -01 is a great improvement over -00. The amount of abbreviations are bad since they are so closed to each other (S-SAB vs SAB), we confused each other some some times because of that. Robert found the idea of removing authentication much clearer but the document was really lacking in the channel-binding case. He saw many more features that could be mentioned, like moving encryption to IPsec layer for performance reasons (this is indirectly mentioned in introduction, but not in the text itself), ability to change encryption to a stronger encryption for the application without modifying the transport itself. Love -------------- 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/20051106/3c7a4fee/PGP.bin From touch at ISI.EDU Sun Nov 6 23:21:40 2005 From: touch at ISI.EDU (Joe Touch) Date: Sun, 06 Nov 2005 23:21:40 -0800 Subject: [anonsec] my comments on the documents In-Reply-To: <17830.1131342562@marajade.sandelman.ca> References: <436E8089.70502@isi.edu> <17830.1131342562@marajade.sandelman.ca> Message-ID: <436F0084.3080004@isi.edu> Michael Richardson wrote: > >>>>>>> "Joe" == Joe Touch writes: > Joe> Sure, but the changes need to be a little more careful. In > Joe> particular, most of BTNS focuses on what your own side > Joe> does. Finding another side that is willing to do BTNS matters > Joe> only if your own cert is not signed by a well-known CA; it has > Joe> nothing to do with your decision to proceed with the cert of > Joe> the other side without checking its CA. > > Yes, I agree. > The section in question is relating to other work. I'm sending text, > because you have mis-stated what OE does. The original text: Opportunistic Encryption (OE) is a system for automating authentication infrastructure by leveraging the existing use of the DNS Your proposed text: Opportunistic Encryption (OE) is a system for automatic discovery of hosts willing to do a BTNS-like encryption, with authentication being exchanged by leveraging existing use of the DNS Agreed as to the text change. > The point is that BTNS doesn't do discovery, nor does it matter, > because of what you just said. > > Joe> How does this 'automatic discovery' work, and how is it a > Joe> variant of OE? (can you explain?) > > System about to send packet looks in reverse DNS for a specific kind > of RR (TXT RR in the current draft, to be changed to IPSECKEY soon in a > future revision of the specification). > If the key exists, it initiates. If the key doesn't exist, it fails, > and may fall-back to something else (pass or block). Why would we want to depend on a predeployed infrastructure to detect whether the other end was willing to do something? Wouldn't the success of an IKE exchange with an un-CA'd certificate be proof, and wouldn't that be more direct (and less dependent on infrastructure)? > This is described in draft-richardson-ipsec-opportunistic-17.txt > http://www.sandelman.ottawa.on.ca/SSW/freeswan/oeid/draft-richardson-ipsec-opportunistic.html > sections 2.3, 3.1, 3.2, 4.2, 4.4, 5.2, 10.1. > > Joe> Finally, there's no need to use the DNS to exchange > Joe> authentication in BTNS; that just inserts an extra intermediary > Joe> to attack, and possibly a worse delay. > > Nor was it suggested. Yes, but even checking to see whether it exists introduces a delay, doesn't it? Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/anonsec/attachments/20051106/0ab7ac0e/signature.bin From mcr at sandelman.ottawa.on.ca Mon Nov 7 18:58:55 2005 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Mon, 07 Nov 2005 18:58:55 -0800 Subject: [anonsec] my comments on the documents References: <436E8089.70502@isi.edu> <17830.1131342562@marajade.sandelman.ca> <436F0084.3080004@isi.edu> Message-ID: A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : http://www.postel.org/pipermail/anonsec/attachments/20051107/759f30cd/attachment.bin From touch at ISI.EDU Mon Nov 7 21:22:18 2005 From: touch at ISI.EDU (Joe Touch) Date: Mon, 07 Nov 2005 21:22:18 -0800 Subject: [anonsec] my comments on the documents In-Reply-To: References: <436E8089.70502@isi.edu> <17830.1131342562@marajade.sandelman.ca> <436F0084.3080004@isi.edu> Message-ID: <4370360A.1070304@isi.edu> Michael Richardson wrote: >>>>>> "Joe" == Joe Touch writes: > >> System about to send packet looks in reverse DNS for a specific kind > >> of RR (TXT RR in the current draft, to be changed to IPSECKEY soon in > >> a future revision of the specification). If the key exists, it > >> initiates. If the key doesn't exist, it fails, and may fall-back to > >> something else (pass or block). > > Joe> Why would we want to depend on a predeployed infrastructure to > Joe> detect whether the other end was willing to do something? Wouldn't > Joe> the success of an IKE exchange with an un-CA'd certificate be proof, > Joe> and wouldn't that be more direct (and less dependent on > Joe> infrastructure)? > > Okay, so consider the case where the IKE exchange is not successful. > - how can you tell that it failed? (it could take a long time) > - how can you tell that you aren't in a bid-down attack? > > Joe> Yes, but even checking to see whether it exists introduces a delay, > Joe> doesn't it? > > Yes, it does. But, a gratuitous DH, plus 3 IKE Main Mode messages is a > longer delay, assuming that it works. The primary difference is whether to start by contacting an infrastructure or to start with IKE and go to the infrastructure only if required. The gratuitous DH + IKE is a lot faster than a DNS timeout when no DNS is available (DNS timeouts are in the tens of seconds). Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/anonsec/attachments/20051107/d42a36e8/signature.bin From paul at xelerance.com Tue Nov 8 09:07:09 2005 From: paul at xelerance.com (Paul Wouters) Date: Tue, 8 Nov 2005 18:07:09 +0100 (CET) Subject: [anonsec] my comments on the documents In-Reply-To: <4370360A.1070304@isi.edu> References: <436E8089.70502@isi.edu> <17830.1131342562@marajade.sandelman.ca> <436F0084.3080004@isi.edu> <4370360A.1070304@isi.edu> Message-ID: On Mon, 7 Nov 2005, Joe Touch wrote: > The primary difference is whether to start by contacting an > infrastructure or to start with IKE and go to the infrastructure only if > required. Start with infrastructure might give you trusted third party data, protecting against all local active attacks. > The gratuitous DH + IKE is a lot faster than a DNS timeout when no DNS > is available (DNS timeouts are in the tens of seconds). If you have no DNS you will have those delays in browsing and emailing too. However, normally, you would get a NXDOMAIN, which only takes about 1 second. Paul -- "Happiness is never grand" --- Mustapha Mond, World Controller (Brave New World) From touch at ISI.EDU Tue Nov 8 10:07:58 2005 From: touch at ISI.EDU (Joe Touch) Date: Tue, 08 Nov 2005 10:07:58 -0800 Subject: [anonsec] my comments on the documents In-Reply-To: References: <436E8089.70502@isi.edu> <17830.1131342562@marajade.sandelman.ca> <436F0084.3080004@isi.edu> <4370360A.1070304@isi.edu> Message-ID: <4370E97E.4000309@isi.edu> Paul Wouters wrote: > On Mon, 7 Nov 2005, Joe Touch wrote: > >> The primary difference is whether to start by contacting an >> infrastructure or to start with IKE and go to the infrastructure only if >> required. > > Start with infrastructure might give you trusted third party data, protecting > against all local active attacks. Agreed. That is not the focus of this draft, however. >> The gratuitous DH + IKE is a lot faster than a DNS timeout when no DNS >> is available (DNS timeouts are in the tens of seconds). > > If you have no DNS you will have those delays in browsing and emailing too. > However, normally, you would get a NXDOMAIN, which only takes about 1 second. I won't have a delay if I don't use DNS names. NXDOMAIN is a DNS reply; I don't get that if there is _no_ DNS. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/anonsec/attachments/20051108/f5ad6015/signature.bin From Nicolas.Williams at sun.com Tue Nov 8 10:30:18 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 8 Nov 2005 12:30:18 -0600 Subject: [anonsec] my comments on the documents In-Reply-To: <436E8089.70502@isi.edu> References: <436E8089.70502@isi.edu> Message-ID: <20051108183018.GF29056@binky.Central.Sun.COM> On Sun, Nov 06, 2005 at 02:15:37PM -0800, Joe Touch wrote: > > > Michael Richardson wrote: > >>>>>> "Michael" == Michael Richardson writes: > > Michael> Please change section 4.2: Opportunistic Encryption (OE) is a > > Michael> system for automatic discovery of hosts willing to do a > > Michael> BTNS-like encryption, with authentication being exchanged by > > Michael> leveraging through existing use of the DNS. > > > > Please change section 4.2: Opportunistic Encryption (OE) is a > > system for automatic discovery of hosts willing to do a BTNS-like encryption, > > with authentication being exchanged by leveraging existing use of the DNS > > Sure, but the changes need to be a little more careful. In particular, > most of BTNS focuses on what your own side does. Finding another side > that is willing to do BTNS matters only if your own cert is not signed > by a well-known CA; it has nothing to do with your decision to proceed > with the cert of the other side without checking its CA. Er, even if you have a good cert your BTNS-capable peers may not or your cert may not be good enough to them -- you might still be happy to do BTNS. From sommerfeld at sun.com Tue Nov 8 11:17:30 2005 From: sommerfeld at sun.com (Bill Sommerfeld) Date: Tue, 08 Nov 2005 11:17:30 -0800 Subject: [anonsec] BTNS and Tunnels In-Reply-To: References: Message-ID: <1131477450.961.34.camel@localhost> On Mon, 2005-10-31 at 12:30, Black_David at emc.com wrote: > I support Tero's comments on NAT-T - getting that into IPsec took enough > work that we should avoid damaging or breaking it - it's entirely too > useful ;-). agreed. but, on the other hand, if there is existing unauthenticated communication between A and B, it should not be possible for "C" to make an unauthenticated BTNS connection to B, claim an inner tunnel address of A, and vacuum up traffic for "A"... Requiring that C = A (either directly, or indirectly by use of transport mode) makes the problem go away. There may be other ways as well. - Bill From paul at xelerance.com Tue Nov 8 11:33:21 2005 From: paul at xelerance.com (Paul Wouters) Date: Tue, 8 Nov 2005 20:33:21 +0100 (CET) Subject: [anonsec] BTNS and Tunnels In-Reply-To: <1131477450.961.34.camel@localhost> References: <1131477450.961.34.camel@localhost> Message-ID: On Tue, 8 Nov 2005, Bill Sommerfeld wrote: > > I support Tero's comments on NAT-T - getting that into IPsec took enough > > work that we should avoid damaging or breaking it - it's entirely too > > useful ;-). > Requiring that C = A (either directly, or indirectly by use of transport > mode) makes the problem go away. There may be other ways as well. Transport mode and NAT-T is not a happy combination though. Paul From hartmans-ietf at mit.edu Tue Nov 8 13:31:43 2005 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Tue, 08 Nov 2005 16:31:43 -0500 Subject: [anonsec] [Sam Hartman] Comments on applicability statement Message-ID: An embedded message was scrubbed... From: Sam Hartman Subject: [anonsec] Comments on applicability statement Date: Tue, 9 Aug 2005 21:30:28 -0400 (EDT) Size: 4270 Url: http://www.postel.org/pipermail/anonsec/attachments/20051108/fe935552/attachment.mht From hartmans-ietf at mit.edu Tue Nov 8 13:48:25 2005 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Tue, 08 Nov 2005 16:48:25 -0500 Subject: [anonsec] [Sam Hartman] Comments on applicability statement In-Reply-To: (Sam Hartman's message of "Tue, 08 Nov 2005 16:31:43 -0500") References: Message-ID: BTW, if the authors explained why they didn't address an issue or if they needed clarification I may have missed that. --Sam From touch at ISI.EDU Tue Nov 8 18:31:41 2005 From: touch at ISI.EDU (Joe Touch) Date: Tue, 08 Nov 2005 18:31:41 -0800 Subject: [anonsec] [Sam Hartman] Comments on applicability statement In-Reply-To: References: Message-ID: <43715F8D.8040108@isi.edu> We're preparing a post that summarizes all the open issues; we apologize for not doing that earlier. In some cases open issues were ones we didn't know how to address; in other cases, we wanted to see if there was any other input in how to address the issue raised, or whether there was consensus on the proposed change. That summary will be presented in rough form at the WG. Joe Sam Hartman wrote: > > So, many of these comments have not been addressed. > > I'm trimming my old message to include issues I still consider open. > > > > > > ------------------------------------------------------------------------ > > Subject: > [anonsec] Comments on applicability statement > From: > Sam Hartman > Date: > Tue, 9 Aug 2005 21:30:28 -0400 (EDT) > To: > anonsec at postel.org > > To: > anonsec at postel.org > > > 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. > > 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 actually don't understand how https is similar to cbb at all in that > there is no channel binding. > > > 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). > > Section 4.3 . I think ssh is a better example for leap of faith than > ssl. Section 4.3 should either rule this extension in scope or out of > scope. Currently it just mentions the extension but takes no > position. > > > > A bunch of small things: > > > In section 1.1 it seems odd to say that we use IPsec both because it is widely deployed and is facing deployment challenges. > > 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. > > > > Please cite a definition for DOS, DDOS and flash crowd. > _______________________________________________ > > > > ------------------------------------------------------------------------ > > _______________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/anonsec/attachments/20051108/4eb8495a/signature.bin From touch at ISI.EDU Tue Nov 8 18:32:49 2005 From: touch at ISI.EDU (Joe Touch) Date: Tue, 08 Nov 2005 18:32:49 -0800 Subject: [anonsec] [Sam Hartman] Comments on applicability statement In-Reply-To: References: Message-ID: <43715FD1.6020404@isi.edu> Sam Hartman wrote: > BTW, if the authors explained why they didn't address an issue or if > they needed clarification I may have missed that. > > --Sam Our apologies on that point; we have been preparing such a list internally, but hadn't prepared it for posting. That is exactly what we're doing right now, to correct that issue. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/anonsec/attachments/20051108/26f42fba/signature.bin From touch at ISI.EDU Wed Nov 9 09:43:27 2005 From: touch at ISI.EDU (Joe Touch) Date: Wed, 09 Nov 2005 09:43:27 -0800 Subject: [anonsec] my comments on the documents In-Reply-To: <22561.1131552994@marajade.sandelman.ca> References: <436E8089.70502@isi.edu> <17830.1131342562@marajade.sandelman.ca> <436F0084.3080004@isi.edu> <4370360A.1070304@isi.edu> <22561.1131552994@marajade.sandelman.ca> Message-ID: <4372353F.1070600@isi.edu> Michael Richardson wrote: > >>>>>>> "Joe" == Joe Touch writes: > Joe> Yes, but even checking to see whether it exists introduces a > Joe> delay, doesn't it? > > >> Yes, it does. But, a gratuitous DH, plus 3 IKE Main Mode messages > >> is a longer delay, assuming that it works. > > Joe> The primary difference is whether to start by contacting an > Joe> infrastructure or to start with IKE and go to the > Joe> infrastructure only if required. > > Joe> The gratuitous DH + IKE is a lot faster than a DNS timeout when > Joe> no DNS is available (DNS timeouts are in the tens of seconds). > > Yes, DNS timeouts can be a serious problem, but we know who to ask, > and we have some expectation of an NXdomain (or NSEC) to tell us that > there is no record. You're still assuming there's a DNS to ask. What if there is NONE? Alternately (different case), what if there IS a record but it's not available? NXdomain won't - and shouldn't - be generated by the delegating server. > But, what are the right IKE timeouts? What if there is an attacker? > How do you know if the recipient is not interested? IKE timeouts are always local to the two parties; DNS timeouts are harder to preempt on a per-connection basis (they can be buried in the net, and only the origin resolver can control the timeout). > ICMP port unreachable's may get filtered out. (They could also get forged!) > How do you think random firewall admin is going to respond when they > start getting unsolicited messages to port 500? > > So, the problem with trying IKE is that it may in fact take far longer > than "tens of seconds" to establish that the peer is not > interested. > Next, you need to build a cache as well, since you don't want to > repeat this for each web page. What is the TTL of the cache? > DNS already does all of that for us. DNS is infrastructure. What happens when it's _not_ there? Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/anonsec/attachments/20051109/3c4f38b3/signature.bin From paul at xelerance.com Wed Nov 9 12:40:35 2005 From: paul at xelerance.com (Paul Wouters) Date: Wed, 9 Nov 2005 21:40:35 +0100 (CET) Subject: [anonsec] my comments on the documents In-Reply-To: <4372353F.1070600@isi.edu> References: <436E8089.70502@isi.edu> <17830.1131342562@marajade.sandelman.ca> <436F0084.3080004@isi.edu> <4370360A.1070304@isi.edu> <22561.1131552994@marajade.sandelman.ca> <4372353F.1070600@isi.edu> Message-ID: On Wed, 9 Nov 2005, Joe Touch wrote: > > Yes, DNS timeouts can be a serious problem, but we know who to ask, > > and we have some expectation of an NXdomain (or NSEC) to tell us that > > there is no record. > > You're still assuming there's a DNS to ask. What if there is NONE? If there is none configured (eg through resolv.conf), then failure is instantly. If there are nameservers configured in resolv.conf (or on windows in the registry) that are not there, then the machine has a much more generic problem, and adding any kind of encryption is not going to help it. It won't be able to do anything that requires dns, and anything it attemps to do that requires dns, such as ftp or http, will fail in the same bad time range of your supposed 10 seconds. > Alternately (different case), what if there IS a record but it's not > available? I do not understand this case. The record IS available (in DNS?) but it is not available? I guess if it is broken it will return a ServFail. If the local resolver is working, but the remote DNS that is authorative is not, then yes there will be a delay, and again it is the fault of the administrator of the machine you are trying to connect to and should be fixed. If you would be trying to connect to that machine (by dns name?) and that is what triggered BTNS, then you've already spend 10 seconds waiting (and I guess failed to resolve it) > NXdomain won't - and shouldn't - be generated by the delegating server. Correct, a quick ServFail should be generated. > > But, what are the right IKE timeouts? What if there is an attacker? > > How do you know if the recipient is not interested? > > IKE timeouts are always local to the two parties; DNS timeouts are > harder to preempt on a per-connection basis (they can be buried in the > net, and only the origin resolver can control the timeout). A machine running a Windows Firewall and dropping IKE would also cause you to wait a number of seconds before you give up on BTNS IKE. > DNS is infrastructure. What happens when it's _not_ there? ServFails. And they get cacahed too if your resolver is still working. If your resolver is not working, you're spending most of your time drinking coffee anyway. Paul From touch at ISI.EDU Wed Nov 9 13:43:19 2005 From: touch at ISI.EDU (Joe Touch) Date: Wed, 09 Nov 2005 13:43:19 -0800 Subject: [anonsec] my comments on the documents In-Reply-To: References: <436E8089.70502@isi.edu> <17830.1131342562@marajade.sandelman.ca> <436F0084.3080004@isi.edu> <4370360A.1070304@isi.edu> <22561.1131552994@marajade.sandelman.ca> <4372353F.1070600@isi.edu> Message-ID: <43726D77.90706@isi.edu> Paul Wouters wrote: > On Wed, 9 Nov 2005, Joe Touch wrote: > >>> Yes, DNS timeouts can be a serious problem, but we know who to ask, >>> and we have some expectation of an NXdomain (or NSEC) to tell us that >>> there is no record. >> You're still assuming there's a DNS to ask. What if there is NONE? > > If there is none configured (eg through resolv.conf), then failure is instantly. > If there are nameservers configured in resolv.conf (or on windows in the > registry) that are not there, then the machine has a much more generic problem, FWIW - that's the case I was thinking of. > and adding any kind of encryption is not going to help it It won't be able to > do anything that requires dns, and anything it attemps to do that requires dns, > such as ftp or http, will fail in the same bad time range of your supposed 10 > seconds. > >> Alternately (different case), what if there IS a record but it's not >> available? > > I do not understand this case. The record IS available (in DNS?) but it is not > available? The parent knows a delegation exists, but the child is unavailable. Just trying to cover bases. > I guess if it is broken it will return a ServFail. If the local > resolver is working, but the remote DNS that is authorative is not, then yes > there will be a delay, and again it is the fault of the administrator of the > machine you are trying to connect to and should be fixed. Agreed; just pointing out the delays there. > If you would be > trying to connect to that machine (by dns name?) and that is what triggered > BTNS, then you've already spend 10 seconds waiting (and I guess failed to > resolve it) Yes; you might not use DNS to get to a BTNS peer, though - that's the case I'm considering where OE would induce delays. >> NXdomain won't - and shouldn't - be generated by the delegating server. > > Correct, a quick ServFail should be generated. > >>> But, what are the right IKE timeouts? What if there is an attacker? >>> How do you know if the recipient is not interested? >> IKE timeouts are always local to the two parties; DNS timeouts are >> harder to preempt on a per-connection basis (they can be buried in the >> net, and only the origin resolver can control the timeout). > > A machine running a Windows Firewall and dropping IKE would also cause you > to wait a number of seconds before you give up on BTNS IKE. Yes - but if you give up on BTNS IKE, you've done all you can in the most direct way. >> DNS is infrastructure. What happens when it's _not_ there? > > ServFails. And they get cacahed too if your resolver is still working. If > your resolver is not working, you're spending most of your time drinking > coffee anyway. Only if you use names ;-) Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/anonsec/attachments/20051109/e7f139ff/signature.bin From Nicolas.Williams at sun.com Thu Nov 10 08:46:29 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 10 Nov 2005 10:46:29 -0600 Subject: [anonsec] my comments on the documents In-Reply-To: References: <436E8089.70502@isi.edu> <17830.1131342562@marajade.sandelman.ca> <436F0084.3080004@isi.edu> <4370360A.1070304@isi.edu> <22561.1131552994@marajade.sandelman.ca> <4372353F.1070600@isi.edu> Message-ID: <20051110164629.GT29056@binky.Central.Sun.COM> On Wed, Nov 09, 2005 at 09:40:35PM +0100, Paul Wouters wrote: > On Wed, 9 Nov 2005, Joe Touch wrote: > > > > Yes, DNS timeouts can be a serious problem, but we know who to ask, > > > and we have some expectation of an NXdomain (or NSEC) to tell us that > > > there is no record. > > > > You're still assuming there's a DNS to ask. What if there is NONE? > > If there is none configured (eg through resolv.conf), then failure is instantly. > If there are nameservers configured in resolv.conf (or on windows in the > registry) that are not there, then the machine has a much more generic problem, > and adding any kind of encryption is not going to help it. It won't be able to > do anything that requires dns, and anything it attemps to do that requires dns, > such as ftp or http, will fail in the same bad time range of your supposed 10 > seconds. But other nameservers could be down too :( From sommerfeld at sun.com Thu Nov 10 14:40:49 2005 From: sommerfeld at sun.com (Bill Sommerfeld) Date: Thu, 10 Nov 2005 14:40:49 -0800 Subject: [anonsec] persistence of leap-of-faith-learned entries. Message-ID: <1131662449.929.21.camel@localhost> section 3 of your draft says: Implementors may provide a PAD entry attribute used to indicate that the given PAD entry is a template that should, when matched, cause new PAD and SPD entries to be created binding the matching peer's IP address and BTNS ID (i.e., public key) by using the PUBLICKEY ID selector to match on the peer's public key. Entries created this way have to be persistent, for some value of "persistent," though we RECOMMEND that "persistent" mean "until manually removed." much of current IPsec use involves portable systems which use dhcp-assigned addresses. ssh's leap-of-faith database only records the key of the server (which usually doesn't move much); it does not record client-side keys. your scheme might work on a node which is usually the ultimate initiator, but is likely to cause trouble on a usually-the-responder node. an IKE protocol extension to (for instance) include TTL or remaining lease lifetime might help.. - Bill From Nicolas.Williams at sun.com Thu Nov 10 15:23:43 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 10 Nov 2005 17:23:43 -0600 Subject: [anonsec] persistence of leap-of-faith-learned entries. In-Reply-To: <1131662449.929.21.camel@localhost> References: <1131662449.929.21.camel@localhost> Message-ID: <20051110232343.GB29056@binky.Central.Sun.COM> On Thu, Nov 10, 2005 at 02:40:49PM -0800, Bill Sommerfeld wrote: > section 3 of your draft says: > > Implementors may provide a PAD entry attribute used to indicate that > the given PAD entry is a template that should, when matched, cause > new PAD and SPD entries to be created binding the matching peer's IP > address and BTNS ID (i.e., public key) by using the PUBLICKEY ID > selector to match on the peer's public key. Entries created this way > have to be persistent, for some value of "persistent," though we > RECOMMEND that "persistent" mean "until manually removed." > > much of current IPsec use involves portable systems which use > dhcp-assigned addresses. > > ssh's leap-of-faith database only records the key of the server (which > usually doesn't move much); it does not record client-side keys. > > your scheme might work on a node which is usually the ultimate > initiator, but is likely to cause trouble on a usually-the-responder > node. The security considerations text call this out as a DoS. > an IKE protocol extension to (for instance) include TTL or remaining > lease lifetime might help.. Yeah, personally I'd rather rip LoF out. From paul at xelerance.com Thu Nov 10 17:08:07 2005 From: paul at xelerance.com (Paul Wouters) Date: Fri, 11 Nov 2005 02:08:07 +0100 (CET) Subject: [anonsec] persistence of leap-of-faith-learned entries. In-Reply-To: <20051110232343.GB29056@binky.Central.Sun.COM> References: <1131662449.929.21.camel@localhost> <20051110232343.GB29056@binky.Central.Sun.COM> Message-ID: On Thu, 10 Nov 2005, Nicolas Williams wrote: > > ssh's leap-of-faith database only records the key of the server (which > > usually doesn't move much); it does not record client-side keys. can it not record the used ID as well? Then it could send a FQDN as id, and we could store key+id. > > an IKE protocol extension to (for instance) include TTL or remaining > > lease lifetime might help.. > > Yeah, personally I'd rather rip LoF out. I'd rather keep LoF in. It's all we have in BTNS. Paul -- "Happiness is never grand" --- Mustapha Mond, World Controller (Brave New World) From Nicolas.Williams at sun.com Thu Nov 10 17:17:06 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 10 Nov 2005 19:17:06 -0600 Subject: [anonsec] persistence of leap-of-faith-learned entries. In-Reply-To: References: <1131662449.929.21.camel@localhost> <20051110232343.GB29056@binky.Central.Sun.COM> Message-ID: <20051111011706.GK29056@binky.Central.Sun.COM> On Fri, Nov 11, 2005 at 02:08:07AM +0100, Paul Wouters wrote: > On Thu, 10 Nov 2005, Nicolas Williams wrote: > > > > ssh's leap-of-faith database only records the key of the server (which > > > usually doesn't move much); it does not record client-side keys. > > can it not record the used ID as well? Then it could send a FQDN as id, > and we could store key+id. > > > > an IKE protocol extension to (for instance) include TTL or remaining > > > lease lifetime might help.. > > > > Yeah, personally I'd rather rip LoF out. > > I'd rather keep LoF in. It's all we have in BTNS. It's not. From Nicolas.Williams at sun.com Thu Nov 10 18:05:38 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 10 Nov 2005 20:05:38 -0600 Subject: [anonsec] persistence of leap-of-faith-learned entries. In-Reply-To: <20051111011706.GK29056@binky.Central.Sun.COM> References: <1131662449.929.21.camel@localhost> <20051110232343.GB29056@binky.Central.Sun.COM> <20051111011706.GK29056@binky.Central.Sun.COM> Message-ID: <20051111020537.GM29056@binky.Central.Sun.COM> On Thu, Nov 10, 2005 at 07:17:06PM -0600, Nicolas Williams wrote: > On Fri, Nov 11, 2005 at 02:08:07AM +0100, Paul Wouters wrote: > > On Thu, 10 Nov 2005, Nicolas Williams wrote: > > > > > > ssh's leap-of-faith database only records the key of the server (which > > > > usually doesn't move much); it does not record client-side keys. > > > > can it not record the used ID as well? Then it could send a FQDN as id, > > and we could store key+id. > > > > > > an IKE protocol extension to (for instance) include TTL or remaining > > > > lease lifetime might help.. > > > > > > Yeah, personally I'd rather rip LoF out. > > > > I'd rather keep LoF in. It's all we have in BTNS. > > It's not. > _______________________________________________ To clarify: there's channel bindings. From lha at it.su.se Thu Nov 10 19:27:00 2005 From: lha at it.su.se (=?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?=) Date: Thu, 10 Nov 2005 19:27:00 -0800 Subject: [anonsec] IETF64 BTNS meeting summary Message-ID: <266ABF94-4D94-4AD4-85B6-A1BA29082780@it.su.se> IETF-64 BTNS Session Summary November 10, 15.10 - 16.10 BTNS held it second meeting in Vancouver. Two documents where discussed during the meeting, the "Problem and Applicability Statement" and "An Unauthenticated Mode of IPsec". Joe Touch talked about the Problem and Applicability Statement document and how the document was updated to deal with the comments received on the document. More review of the document is needed. Nico Williams made a short presentation of his draft "An Unauthenticated Mode of IPsec". There was a good discussion on how to deal with SSH style leap of faith and how to describe BTNS within the IPsec framework with respect to PAD and SPD. Decisions ========= * Adopted Nico Williams draft draft-williams-btns-00 as a WG item. Action items ============ * Publish next version of the Problem and Applicability Statement hopefully in the beginning of December. Joe, Yu-Shun, David. * Get more review of the Problem and Applicability Statement, chairs * Publish next version of Nico draft as a working-group item, Nico. * Add text in Nico draft how to the use-cases in Problem and Applicability Statement is used, Nico. Update milestones ================= Done First version of SPD and/or PAD extensions draft Jan 06 WG LC on problem and applicability statement (a+b) Jan 06 First version of IKE extensions draft (if needed) Feb 06 First version of IPsec interfaces draft (e) Feb 06 Submit problem and applicability statement to IESG (a+b) Mar 06 WG LC on IKE extensions (c) Mar 06 WG LC on SPD and/or PAD extensions (d) Apr 06 Submit IKE extensions to the IESG Apr 06 Submit SPD and/or PAD extensions to the IESG Jun 06 WG LC on IPsec interfaces draft Jun 06 Submit IPsec interfaces draft to the IESG Jun 06 Recharter or close the WG -------------- 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/20051110/d77497f3/PGP.bin From hartmans-ietf at mit.edu Mon Nov 21 07:58:18 2005 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Mon, 21 Nov 2005 10:58:18 -0500 Subject: [anonsec] persistence of leap-of-faith-learned entries. In-Reply-To: (Paul Wouters's message of "Fri, 11 Nov 2005 02:08:07 +0100 (CET)") References: <1131662449.929.21.camel@localhost> <20051110232343.GB29056@binky.Central.Sun.COM> Message-ID: >>>>> "Paul" == Paul Wouters writes: Paul> On Thu, 10 Nov 2005, Nicolas Williams wrote: >> > ssh's leap-of-faith database only records the key of the >> server (which > usually doesn't move much); it does not record >> client-side keys. Paul> can it not record the used ID as well? Then it could send a Paul> FQDN as id, and we could store key+id. Then what do you do? How is it useful to kno the key and ID without knowing which traffic should go to that ID? --Sam From paul at xelerance.com Mon Nov 21 08:49:53 2005 From: paul at xelerance.com (Paul Wouters) Date: Mon, 21 Nov 2005 17:49:53 +0100 (CET) Subject: [anonsec] persistence of leap-of-faith-learned entries. In-Reply-To: References: <1131662449.929.21.camel@localhost> <20051110232343.GB29056@binky.Central.Sun.COM> Message-ID: On Mon, 21 Nov 2005, Sam Hartman wrote: > Paul> On Thu, 10 Nov 2005, Nicolas Williams wrote: > >> > ssh's leap-of-faith database only records the key of the > >> server (which > usually doesn't move much); it does not record > >> client-side keys. > > Paul> can it not record the used ID as well? Then it could send a > Paul> FQDN as id, and we could store key+id. > > Then what do you do? How is it useful to kno the key and ID without > knowing which traffic should go to that ID? If it is a host-host connection (a la Opportunistic Encryption) then it will just encrypt that traffic which otherwise would go plaintext. This would allow us to keep the ID and key fingerprint for subsequent connects. If there are multiple ways of connecting, eg towards a subnet behind the host, then I would want to allow some unknown incoming machine without having a confirmed (hardcoded) policy anyway. Though one middle case here is when an "OE gateway" is used, eg one IPsec server offering anonymous IPsec connections for an entire subnet behind it. But then the OE gateway has a specific policy loaded for that. Opportunistic Encryption, as curently implemented in freeswan/openswan is always bound to a policy. Authentication of a host (and using leap of faith) is a seperate process from applying policies for OE/anonsec type connections. Or in other words. we do ssh leap of faith without knowing whether the user can still login to the remote server as well. authentication is a different step from host/client verification. Paul -- "Happiness is never grand" --- Mustapha Mond, World Controller (Brave New World) From hartmans-ietf at mit.edu Mon Nov 21 09:19:55 2005 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Mon, 21 Nov 2005 12:19:55 -0500 Subject: [anonsec] persistence of leap-of-faith-learned entries. In-Reply-To: (Paul Wouters's message of "Mon, 21 Nov 2005 17:49:53 +0100 (CET)") References: <1131662449.929.21.camel@localhost> <20051110232343.GB29056@binky.Central.Sun.COM> Message-ID: >>>>> "Paul" == Paul Wouters writes: Paul> On Mon, 21 Nov 2005, Sam Hartman wrote: On Thu, 10 Nov 2005, Paul> Nicolas Williams wrote: >> >> > ssh's leap-of-faith database only records the key of the >> >> server (which > usually doesn't move much); it does not >> record >> client-side keys. >> Paul> can it not record the used ID as well? Then it could send a Paul> FQDN as id, and we could store key+id. >> Then what do you do? How is it useful to kno the key and ID >> without knowing which traffic should go to that ID? Paul> If it is a host-host connection (a la Opportunistic Paul> Encryption) then it will just encrypt that traffic which Paul> otherwise would go plaintext. This would allow us to keep Paul> the ID and key fingerprint for subsequent connects. I think you're missing the whole point. I'm going to suggest you do the same thing I told Nico: walk through an example in sufficient detail that you can explain when SPD entries get added and what they contain. I think you will find that you're missing information you need and/or what you describe is not within 2401bis. The nice thing about this suggestion is that if I'm wrong and what you describe is in fact simple it is fairly easy to demonstrate. --Sam From kivinen at iki.fi Tue Nov 22 02:29:03 2005 From: kivinen at iki.fi (Tero Kivinen) Date: Tue, 22 Nov 2005 12:29:03 +0200 Subject: [anonsec] persistence of leap-of-faith-learned entries. In-Reply-To: References: <1131662449.929.21.camel@localhost> <20051110232343.GB29056@binky.Central.Sun.COM> Message-ID: <17282.62191.833676.263418@fireball.kivinen.iki.fi> Sam Hartman writes: > I think you're missing the whole point. I'm going to suggest you do > the same thing I told Nico: walk through an example in sufficient > detail that you can explain when SPD entries get added and what they > contain. Here is a short example of the scenario where the ssh-style leap of faith would be useful: ---------------------------------------------------------------------- Environment =========== Staticly configured router network, where each router has a fixed IP-address, and fixed key that is used by that IP-address. The actual routing is done dynamically by routing protocol run between the routers. The IP-address <-> key mapping is static, and persistent, meaning, that even if the router needs to be changed because of hardware failure, the new router will be configured with the same private key. This can be done in multiple ways, but all of those are outside the scope of this example. Few examples of those ways to provide static, persistent mapping are: All keys and IP addresses are stored in the centralized database, and routers fetch them from there when they boot up; Key, and the identity (IP-number) of the router is stored on the smartcard which is attached to the router itself. Note, that each organization usually have their own way of doing this, meaning there is no single centralized database, but one organization might use one database, and another might use smartcards, and another might be using some other method. There is no fast key rollover, and there is no changes in the key <-> IP mapping. Each key is identified by the single IP-address used as a identity when it is used. We are trying to protect routing protocol running on UDP/TCP port 1234, and nothing else. The routers are owned and adminstrated by multiple different organizations, which do not have common adminstration, thus pre-distributing keys or centralized CA is out of question. The number of routers is huge, and and the number of organizations in the whole network is also very large, but each router usually talks to only few other routers (i.e. the ones they are directly connected to), and routers keep talking all the time with the same routers (unless there is real physical change in the network (i.e. new link / router added somewhere)). The parties each router talk to do not really change often, but the whole network having huge number of routers will in total have lots of changes each day (but affecting only those routers directly related to those changes). For example we could have 1 million routers, with 10,000 organizations (each organization having 100 routers), each router is connected to around 10 other routers via direct links, and there could be 1,000 new routers added and deleted every day, i.e. affecting 10,000 routers in the network. When new router is added to new or previously disconnected link, it will automatically detect the other ends ip-address and connect to it, and after that the routing protocol automatically takes care of updating the routes (i.e. adding new router or deleting old one does not require manual configuration changes in the neighbor routers). Policy ====== Initial SPD in each router could be something like: Any IP, UDP/TCP port 1234 <-> Any IP, UDP/TCP port 1234: PROTECT(BTNS-LEAP-OF-FAITH, expire = 14 days) Any IP <-> Any IP: BYPASS Initial connection ================== When the new IKE SA connection is created (either by us or by other end), and the PROTECT has BTNS-LEAP-OF-FAITH, we create new SPD rule with following values (2200:AF11::1 is remote ip, and 2200:AF22::2 is local ip): 2200:AF11::1, UDP/TCP port 1234 <-> 2200:AF22::2, UDP/TCP port 1234 PROTECT, expire time = 14 days and new PAD rule: IPV4_ID: 2200:AF11::1, key: , expire time = 14 days Connections after initial connection ==================================== As we now have SPD rule that will expilicty match the traffic 2200:AF11::1 port 1234 <-> 2200:AF22::2 port 1234, and PAD entry which ties 2200:AF11::1 to the given key, we will reject all connections which cannot authenticate using the same key coming from the same IP address. Thus after the initial connections, attackers cannot fake to be the router. Expiring entries ================ Each SPD and PAD rule has new information, i.e. the expire time. If no connections comes in using that PAD/SPD rule before that expires then the whole entry is removed from the database. Every time connection comes in, then the expire timeout is started from the beginning. This allows slow key roll-over, i.e. if we remove one router from the network, its keys are forgotten from the other nodes after expire time, and then we can add new router back to same IP with different key. The expire time should be taken long enough to be able to cope all temporary failures (link going down, someone accidently cutting the cable etc), but short enough that it can cope with the actual operational changes (i.e. customer leaving, and his router being disconnected, and then new customer arriving few weeks later to the same premisis, and new router installed there). This is something we cannot do on the secure shell as there is no guarantee that the other ends will connect frequently enough, as connections are depending on the users. If we are protecting automated network, where we can be sure that in normal case we do have connections up and running all the time, we can do this kind of expiring. Summary ======== This example above, does not try to be any exact protocol doing everything, but a simple example showing where the ssh-style leap of faith could be useful. There are other places where it could be used, and this example is very limited, and using strong limitations to limit the scope. This probably could be expanded to support more scenarios, but the basic idea of this example is to show one very limited scenario where it could be used. -- kivinen at safenet-inc.com From mcr at sandelman.ottawa.on.ca Sat Nov 26 19:04:55 2005 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Sat, 26 Nov 2005 22:04:55 -0500 Subject: [anonsec] persistence of leap-of-faith-learned entries. References: <1131662449.929.21.camel@localhost> <20051110232343.GB29056@binky.Central.Sun.COM> <17282.62191.833676.263418@fireball.kivinen.iki.fi> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Tero" == Tero Kivinen writes: Tero> Any IP, UDP/TCP port 1234 <-> Any IP, UDP/TCP port 1234: Tero> PROTECT(BTNS-LEAP-OF-FAITH, expire = 14 days) Probably the "expire=" is the key. Note that if some of routers come up with dynamic IPs and use FQDN IDs, it all still works --- if the other routers would always refuse to speak UDP/TCP port 1234 in the clear. There is no DOS by policy. All of this may or may not also have channel binding in the protocol. Want a real example of this? Hosts getting disks via iSCSI from an ISP. Another good example of this might be protecting 6to4 traffic. Tero> This is something we cannot do on the secure shell as there is no Tero> guarantee that the other ends will connect frequently enough, as Tero> connections are depending on the users. If we are protecting Good point. The expiry could be on the order of tens of hours. I think a key other point is that there is: a) BTNS and b) BTNS-LEAP-OF-FAITH We don't have to make LoF work for all scenarios. It may not be appropriate. Further, LoF is a *local* policy on the responder. It doesn't need to be negotiated, or known a-priori. - -- ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr at xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iQEVAwUBQ4kiWoCLcPvd0N1lAQLmAwgAuTBl/2SpoCEBFNEL08SeRAyH4YeM7faL 74qRXmizDAxu+qDA10VLEq8uuiwLvLpfPMnfhZBRFtx/Dvy/D0JaXdSy+FNlTb1+ nxk8phOoZAXZN/d65M8DQY/0pj2YE4EkxvM5PBLPAMYuWNVSbGtTv8idhGZQSVVn UietoyVpOq8ABDwWl5hXFMpsS+nT55i3qUuJmw0PzJ6RlULSB9fOUbxsxGaMBxtk NlvuLhNZQx77ga4gxVnqy2qy5xI6Q2Cfe2e8tf2WpCz3fdqMm/wBwvVQJugtBck8 W8CwsnMZVksrHkAi7F+XzDrwxzx9T9B9QAzySBW21Wpd0DVW51PnUw== =FXxC -----END PGP SIGNATURE-----