From touch at ISI.EDU Thu Aug 4 00:04:46 2005 From: touch at ISI.EDU (Joe Touch) Date: Thu, 04 Aug 2005 00:04:46 -0700 Subject: [anonsec] my slides for today's talk Message-ID: <42F1BE0E.2070309@isi.edu> at http://www.postel.org/anonsec/touch-ietf63.ppt Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/anonsec/attachments/20050804/b4c1c593/signature.bin From lha at kth.se Thu Aug 4 03:31:53 2005 From: lha at kth.se (=?iso-8859-1?q?Love_H=F6rnquist_=C5strand?=) Date: Thu, 04 Aug 2005 12:31:53 +0200 Subject: [anonsec] BTNS WG meeting summary Message-ID: A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 477 bytes Desc: not available Url : http://www.postel.org/pipermail/anonsec/attachments/20050804/8281f81c/attachment.bin From rajiv_das at msn.com Thu Aug 4 21:18:50 2005 From: rajiv_das at msn.com (rajiv Das) Date: Fri, 5 Aug 2005 09:48:50 +0530 Subject: [anonsec] Contributing to BTNS In-Reply-To: Message-ID: Hi, I read your slides and will read the draft over the weekend. I am interested to know more about the problem you people are investigating, and possibly would like to contribute in whatever way possible. Let me know how to go about it. Thanks, Rajiv Das http://thothzone.blogspot.com -----Original Message----- From: anonsec-bounces at postel.org [mailto:anonsec-bounces at postel.org] On Behalf Of anonsec-request at postel.org Sent: Friday, August 05, 2005 12:30 AM To: anonsec at postel.org Subject: ANONSEC Digest, Vol 12, Issue 1 Send ANONSEC mailing list submissions to anonsec at postel.org To subscribe or unsubscribe via the World Wide Web, visit http://www.postel.org/mailman/listinfo/anonsec or, via email, send a message with subject or body 'help' to anonsec-request at postel.org You can reach the person managing the list at anonsec-owner at postel.org When replying, please edit your Subject line so it is more specific than "Re: Contents of ANONSEC digest..." From Nicolas.Williams at sun.com Sun Aug 7 13:14:22 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Sun, 7 Aug 2005 15:14:22 -0500 Subject: [anonsec] IKE, PAD, SPD extensions, take 2 Message-ID: <20050807201421.GA18081@binky.Central.Sun.COM> So, Charlie Kaufman and I chatted after the meeting, and he convinced me that we need no IKE extensions. Basically, whether a peer takes one to be authenticated as one's asserted ID or not doesn't seem to be very important (except of course for authorization decisions made by that peer). This means that for BTNS hosts should use whatever credentials, or ephemeral self-signed tickets that they wish. Not having BTNS-specific bits on the wire in IKE makes analyzing the protocol simpler, particularly with regard to assymetric cases. That leaves us with the PAD/SPD extensions. We talked about it and concluded that all we really need is, almost anyways, the ANY wildcard value for ID selectors. I say "almost" because ANY in existing deployments could be taken to mean "any peer with certs I can validate with my configured trust anchors" so that chaning ANY to mean "any peer, BTNS or otherwise" would be rather, er, rude. So we need a new ID selector wildcard value corresponding to 'truly ANY'. What to name that value? Nico -- From lha at kth.se Sun Aug 7 14:48:53 2005 From: lha at kth.se (=?iso-8859-1?q?Love_H=F6rnquist_=C5strand?=) Date: Sun, 07 Aug 2005 23:48:53 +0200 Subject: [anonsec] Contributing to BTNS In-Reply-To: (rajiv Das's message of "Fri, 5 Aug 2005 09:48:50 +0530") References: Message-ID: A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 477 bytes Desc: not available Url : http://www.postel.org/pipermail/anonsec/attachments/20050807/885d4a49/attachment.bin From Nicolas.Williams at sun.com Sun Aug 7 15:02:20 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Sun, 7 Aug 2005 17:02:20 -0500 Subject: [anonsec] IKE, PAD, SPD extensions, take 2 In-Reply-To: <20050807201421.GA18081@binky.Central.Sun.COM> References: <20050807201421.GA18081@binky.Central.Sun.COM> Message-ID: <20050807220220.GB18081@binky.Central.Sun.COM> I'll re-write my -00 thusly and resubmit. Nico -- From pekka.nikander at nomadiclab.com Mon Aug 8 00:51:15 2005 From: pekka.nikander at nomadiclab.com (Pekka Nikander) Date: Mon, 8 Aug 2005 09:51:15 +0200 Subject: [anonsec] IKE, PAD, SPD extensions, take 2 In-Reply-To: <20050807201421.GA18081@binky.Central.Sun.COM> References: <20050807201421.GA18081@binky.Central.Sun.COM> Message-ID: <56CBC062-AC17-46C4-A4AA-E86E05C3D9D1@nomadiclab.com> > [...] > > That leaves us with the PAD/SPD extensions. > > We talked about it and concluded that all we really need is, almost > anyways, the ANY wildcard value for ID selectors. I say "almost" > because ANY in existing deployments could be taken to mean "any peer > with certs I can validate with my configured trust anchors" so that > chaning ANY to mean "any peer, BTNS or otherwise" would be rather, er, > rude. > > So we need a new ID selector wildcard value corresponding to 'truly > ANY'. > > What to name that value? > UNKNOWN? If the current semantics of ANY is basically "any whose identity I can assert w.r.t. to some trust anchor", won't this new "ANY" be "any whose identity I can't assert", i.e., unknown? --Pekka From paul at xelerance.com Mon Aug 8 03:27:21 2005 From: paul at xelerance.com (Paul Wouters) Date: Mon, 8 Aug 2005 12:27:21 +0200 (CEST) Subject: [anonsec] Contributing to BTNS In-Reply-To: References: Message-ID: On Sun, 7 Aug 2005, Love H?rnquist ?strand wrote: >> I read your slides and will read the draft over the weekend. I am interested >> to know more about the problem you people are investigating, and possibly >> would like to contribute in whatever way possible. Let me know how to go >> about it. > > A good starting point for what the group is going to do it the charter for > the group [1] and the Problem and Applicability Statement draft. The draft > needs some more revision and Joe Touch have recived some comments and have > ideas on how to improve the document. > > I'm sure Joe will appreciate any comments you have on the draft. I personally find the draft focuses far too much on TCP-RST issues. Really, if that is the main reason for BTNS, then a completely different solution to that specific problem should be designed. The current BTNS is rather overkill to fix the TCP-RST problem. Ofcourse, the real use of BTNS is to provide a better then nothing privacy between two parties, but it seems that people are too afraid to mention this political goal, and use the RST issue as a technical excuse for the unmentioned political goal. I have not read the draft carefully enough to give more specific technical comments, but I do find anonymous IPsec connections with only inbound public key exchange without any kind of third party verification too dangerous to give to people and tell them it adds security. I know it adds prootection against passive attacks, but I think it is far too easy to play man in the middle if there is only inbound (ISAKMP/IKE) information exchange happening. I'm also worried that transferring inbound X.509 certificates will hit many UDP fragmentation issues as we see now in IKE v1. Ofcourse I am somewhat biased to FreeS/WANs and Openswan's Opportunistic Encryption draft that uses DNS (and preferably DNSSEC) as a trusted third party. Furthermore, one could think of a Rendezvous extension where two parties meeting over Bluetooth (or any other non-internet connected connection) could send DNSSEC signed keys from their machine upwards the hierarchy until it meets a domain of which the other party has a signed trusted key as well. I hope BTNS and/or IKE v2 would allow such an exchange. Paul Paul From Nicolas.Williams at sun.com Mon Aug 8 08:07:33 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 8 Aug 2005 10:07:33 -0500 Subject: [anonsec] IKE, PAD, SPD extensions, take 2 In-Reply-To: <56CBC062-AC17-46C4-A4AA-E86E05C3D9D1@nomadiclab.com> References: <20050807201421.GA18081@binky.Central.Sun.COM> <56CBC062-AC17-46C4-A4AA-E86E05C3D9D1@nomadiclab.com> Message-ID: <20050808150733.GE18081@binky.Central.Sun.COM> On Mon, Aug 08, 2005 at 09:51:15AM +0200, Pekka Nikander wrote: > >[...] > > > >That leaves us with the PAD/SPD extensions. > > > >We talked about it and concluded that all we really need is, almost > >anyways, the ANY wildcard value for ID selectors. I say "almost" > >because ANY in existing deployments could be taken to mean "any peer > >with certs I can validate with my configured trust anchors" so that > >chaning ANY to mean "any peer, BTNS or otherwise" would be rather, er, > >rude. > > > >So we need a new ID selector wildcard value corresponding to 'truly > >ANY'. > > > >What to name that value? > > > > UNKNOWN? If the current semantics of ANY is basically "any whose > identity I can assert w.r.t. to some trust anchor", won't this new > "ANY" be "any whose identity I can't assert", i.e., unknown? Perfect. Thanks. Look for an I-D in a few days. Nico -- From Nicolas.Williams at sun.com Mon Aug 8 14:08:27 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 8 Aug 2005 16:08:27 -0500 Subject: [anonsec] IKE, PAD, SPD extensions, take 2 In-Reply-To: <20050808150733.GE18081@binky.Central.Sun.COM> References: <20050807201421.GA18081@binky.Central.Sun.COM> <56CBC062-AC17-46C4-A4AA-E86E05C3D9D1@nomadiclab.com> <20050808150733.GE18081@binky.Central.Sun.COM> Message-ID: <20050808210827.GB18082@binky.Central.Sun.COM> On Mon, Aug 08, 2005 at 10:07:33AM -0500, Nicolas Williams wrote: > On Mon, Aug 08, 2005 at 09:51:15AM +0200, Pekka Nikander wrote: > > >So we need a new ID selector wildcard value corresponding to 'truly > > >ANY'. > > > > > >What to name that value? > > > > > > > UNKNOWN? If the current semantics of ANY is basically "any whose > > identity I can assert w.r.t. to some trust anchor", won't this new > > "ANY" be "any whose identity I can't assert", i.e., unknown? > > Perfect. Thanks. We still have to consider how to represent opportunistic BTNS, that is "if the peer can do IKE, use BTNS, else don't use IPsec at all." I haven't given this any thought beyond noting that there's a downgrade attack through denying IKE service. Nico -- From touch at ISI.EDU Tue Aug 9 13:20:21 2005 From: touch at ISI.EDU (Joe Touch) Date: Tue, 09 Aug 2005 13:20:21 -0700 Subject: [anonsec] Contributing to BTNS In-Reply-To: References: Message-ID: <42F91005.1010401@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Wouters wrote: > On Sun, 7 Aug 2005, Love H?rnquist ?strand wrote: > >>> I read your slides and will read the draft over the weekend. I am >>> interested >>> to know more about the problem you people are investigating, and >>> possibly >>> would like to contribute in whatever way possible. Let me know how to go >>> about it. >> >> >> A good starting point for what the group is going to do it the charter >> for >> the group [1] and the Problem and Applicability Statement draft. The >> draft >> needs some more revision and Joe Touch have recived some comments and >> have >> ideas on how to improve the document. >> >> I'm sure Joe will appreciate any comments you have on the draft. > > > I personally find the draft focuses far too much on TCP-RST issues. Really, > if that is the main reason for BTNS, then a completely different > solution to > that specific problem should be designed. The current BTNS is rather > overkill > to fix the TCP-RST problem. That is historical, i.e., providing an example case that happened to also be the motivator in reality. It's intended as an example, not the only example. I had thought the doc gave that sense; can others speak up if that isn't the case? > Ofcourse, the real use of BTNS is to provide a better then nothing privacy > between two parties, but it seems that people are too afraid to mention > this > political goal, and use the RST issue as a technical excuse for the > unmentioned > political goal. > > I have not read the draft carefully enough to give more specific technical > comments, but I do find anonymous IPsec connections with only inbound > public > key exchange without any kind of third party verification too dangerous to > give to people and tell them it adds security. I know it adds prootection > against passive attacks, but I think it is far too easy to play man in the > middle if there is only inbound (ISAKMP/IKE) information exchange > happening. In a sense. BTNS doesn't care about man-in-the-middle (MITM). MITM substitutes one party for another, and BTNS doesn't care which party it's talking with. > I'm also worried that transferring inbound X.509 certificates will hit many > UDP fragmentation issues as we see now in IKE v1. > > Ofcourse I am somewhat biased to FreeS/WANs and Openswan's Opportunistic > Encryption draft that uses DNS (and preferably DNSSEC) as a trusted third > party. Yes - but that just replaces one infrastructure (CAs) with another (DNS). It doesn't solve the problem of how to secure communications with a party that hasn't already got (or doesn't want to get) a third-party to authenticate who it is. > Furthermore, one could think of a Rendezvous extension where two parties > meeting over Bluetooth (or any other non-internet connected connection) > could > send DNSSEC signed keys from their machine upwards the hierarchy until it > meets a domain of which the other party has a signed trusted key as well. > I hope BTNS and/or IKE v2 would allow such an exchange. > > Paul > Paul Perhaps, but that seems like yet another key distribution infrastructure alnternative, rather than one that avoids the need for such keys in the first place. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC+RAFE5f5cImnZrsRAr6NAJ942qRtQex0fLCPoaKSRvVUswSY6wCaAgAJ 3t36jEl77qGoSeT0I1eaPrg= =J8zj -----END PGP SIGNATURE----- From touch at ISI.EDU Tue Aug 9 13:21:50 2005 From: touch at ISI.EDU (Joe Touch) Date: Tue, 09 Aug 2005 13:21:50 -0700 Subject: [anonsec] IKE, PAD, SPD extensions, take 2 In-Reply-To: <56CBC062-AC17-46C4-A4AA-E86E05C3D9D1@nomadiclab.com> References: <20050807201421.GA18081@binky.Central.Sun.COM> <56CBC062-AC17-46C4-A4AA-E86E05C3D9D1@nomadiclab.com> Message-ID: <42F9105E.3090404@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Pekka Nikander wrote: >>[...] >> >>That leaves us with the PAD/SPD extensions. >> >>We talked about it and concluded that all we really need is, almost >>anyways, the ANY wildcard value for ID selectors. I say "almost" >>because ANY in existing deployments could be taken to mean "any peer >>with certs I can validate with my configured trust anchors" so that >>chaning ANY to mean "any peer, BTNS or otherwise" would be rather, er, >>rude. >> >>So we need a new ID selector wildcard value corresponding to 'truly >>ANY'. >> >>What to name that value? > > UNKNOWN? If the current semantics of ANY is basically "any whose > identity I can assert w.r.t. to some trust anchor", won't this new > "ANY" be "any whose identity I can't assert", i.e., unknown? > > --Pekka I'd have gone with "NONE", in the sense that it isn't even relevant. UNKNOWN sounds more like something that should generate an error somewhere (i.e., it implies erroneous operation). Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC+RBeE5f5cImnZrsRAuEmAKD2f4RMDfcLqhZYHyOVY+tP0AleMACfV971 79pBQnuQQBBbJj1SNzQ/ymA= =leR6 -----END PGP SIGNATURE----- From hartmans-ietf at mit.edu Tue Aug 9 18:30:28 2005 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Tue, 9 Aug 2005 21:30:28 -0400 (EDT) Subject: [anonsec] Comments on applicability statement Message-ID: <20050810013028.CB318E0049@carter-zimmerman.mit.edu> 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 don't understand how s-cbb has anything to do with self-signed certs and websites. 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 seems to duplicate a lot of the content I would expect to see in section 3. Section 5.3 . I think ssh is a better example for leap of faith than ssl. Section 5.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: TLS not SSL in description of https. 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. From hartmans-ietf at mit.edu Sat Aug 13 15:52:45 2005 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Sat, 13 Aug 2005 18:52:45 -0400 Subject: [anonsec] Contributing to BTNS In-Reply-To: (Paul Wouters's message of "Mon, 8 Aug 2005 12:27:21 +0200 (CEST)") References: Message-ID: >>>>> "Paul" == Paul Wouters writes: Paul> Ofcourse, the real use of BTNS is to provide a better then Paul> nothing privacy between two parties, but it seems that Paul> people are too afraid to mention this political goal, and Paul> use the RST issue as a technical excuse for the unmentioned Paul> political goal. There were three camps that wanted BTNS in the BOF. I think the document actually represents all three mindsets. Paul> specific technical comments, but I do find anonymous IPsec Paul> connections with only inbound public key exchange without Paul> any kind of third party verification too dangerous to give Paul> to people and tell them it adds security. I know it adds Paul> prootection against passive attacks, but I think it is far Paul> too easy to play man in the middle if there is only inbound Paul> (ISAKMP/IKE) information exchange happening. so, that would have been a valuable comment to make before the BTNS working group was charetered. However I don't think that there is any way of meeting the goals of the charter without providing IPsec SAs that are vulnerable to man-in-the-middle attacks. If you don't want to work on the problems described in the charter then this is not the working group for you. If you do, then we'd be happy to have your input. From jari.arkko at piuha.net Sun Aug 14 00:30:27 2005 From: jari.arkko at piuha.net (Jari Arkko) Date: Sun, 14 Aug 2005 10:30:27 +0300 Subject: [anonsec] Contributing to BTNS In-Reply-To: References: Message-ID: <42FEF313.7020303@piuha.net> Sam Hartman wrote: >However I don't think that there is any >way of meeting the goals of the charter without providing IPsec SAs >that are vulnerable to man-in-the-middle attacks > > Agreed. --Jari From jari.arkko at piuha.net Mon Aug 15 03:11:15 2005 From: jari.arkko at piuha.net (Jari Arkko) Date: Mon, 15 Aug 2005 13:11:15 +0300 Subject: [anonsec] review of draft-williams-btns-unauthenticated-bits-00.txt Message-ID: <43006A43.7050509@piuha.net> Hi Nicolas, I finally found some time to read this draft. (Disclaimer: Due to a conflict I could not stay the whole BTNS meeting in IETF-63, and I also have not followed list discussion. So I may be bringing up issues that you already discussed.) Overall, I like the approach. I have some smaller issues and one bigger technical issue. First the big issue: > This, then, is a crucial feature of BTNS mode IPsec: that it is most > useful (and least harmful) when used between systems with statically > allocated addresses and whose BTNS keys change infrequently. This worries me quite a bit. In today's network situation this is quite limiting, particularly if you consider that most server-to-server connections probably would use managed security rather than anonymous security. It may be that the combination of BTNS and MOBIKE might help here (probably will), or that we should start asking ourselves whether the binding to the IP address is really useful basis for BTNS. One approach would be to scope BTNS as an anonymous encryption scheme rather than leap-of-faith. That is, you could use it as a means to opportunistically protect all your communications, but you would not get any guarantees that you are talking to the same node beyond the life of the IKE SA. But this would possibly preclude the use of BTNS for the BGP application (or would it? i don't know). One way to deal with this would be to add not one, but two additional authentication modes to the PAD: Leap-of-faith: If you successfully execute an unauthenticated IKEv2 run with the peer, then latch on to the key communicated during that run, and require that key in all subsequent IKEv2 runs to or from that same address. This would most likely be used only with PAD entries that have been limited to a given peer address or a range of addresses, and a limited application. Anonymous encryption: Set up IKEv2 runs with peers in an opportunistic manner, without keeping any state from old connections to this address. Allow another IKEv2 run to clear the state (as in INITIAL_CONTACT). This is useful for protecting against non-path attackers and for on-path attackers that do not wish to execute a D-H MITM attack on every connection passing through. > Another crucial feature of BTNS mode IPsec: it MUST be possible to > manually edit a PAD on a BITS (or BITW) implementation to remove > stale BTNS entries. This is a related problem. Such manual edits are a non-starter for general population usage, though of course possible in limited applications. I would suggest making anonymous encryption the mandatory-to-implement feature and then requiring the above MUST only if Leap-of-Faith mode is supported. Then to the smaller issues: > This document specifies how to use the Internet Key Exchange (IKE) > protocols, such as IKEv1 and IKEv2, to setup "unauthenticated" For simplicity, I'd prefer doing this for IKEv2 only. > IKE peers, both v1 and v2, when receiving a peer's ID_PUBLICKEY MAY, > of course, reject the exchange according to local policy (i.e., if > the peer is not authorized to assert the given public key as its ID). What is the process of rejection, and will it consist of informing the client that the problem was lack of authorization for anonauth? This may be important, if we have a large number of IKE capable nodes in the Internet but not all of them supporting BTNS. Other issues: I don't see anything about the symmetric or asymmetric nature of this extension. Can you do anonsec one way or two way or both? Is this only for transport mode? Presumably yes, I'm not sure we want to deal with issues relating to authorizing specific inner addresses. Also, I don't see any discussion about the role of user confirmation in the leap-of-faith scheme, or the security implications for the lack of such confirmation. SSH and SIP leap of faith schemes employ such confirmations, and for those application it appears rather essential for the security. Mobike integration: in the leap-of-faith case, it seems that one could easily allow the address associated with the public key to change (or even have multiple concurrent addresses). What we still want to ensure that you can't override someone else's PAD entry. Arranging this seems problematic, because in a DHCP v4 environment you could easily get someone else's old address, and at IP layer the other end does not know if its still using that other address or not. --Jari From Nicolas.Williams at sun.com Mon Aug 15 08:30:51 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 15 Aug 2005 10:30:51 -0500 Subject: [anonsec] review of draft-williams-btns-unauthenticated-bits-00.txt In-Reply-To: <43006A43.7050509@piuha.net> References: <43006A43.7050509@piuha.net> Message-ID: <20050815153050.GX18081@binky.Central.Sun.COM> On Mon, Aug 15, 2005 at 01:11:15PM +0300, Jari Arkko wrote: > Hi Nicolas, > > I finally found some time to read this draft. > > (Disclaimer: Due to a conflict I could not stay the whole > BTNS meeting in IETF-63, and I also have not followed > list discussion. So I may be bringing up issues that you > already discussed.) What you missed is that I said to ignore the -00. My goal with that -00 had been to show how useless BTNS is without APIs, but partly this was based on a misunderstanding that led me to think that leap-of-faith creation of PAD entries would be needed. I now realize my error and am dropping the leap-of-faith stuff. Further, Charlie Kaufman argued that we needed no extensions to IKE or IKEv2, not on the wire anyways. In a subsequent hallway meeting he convinced me and then we discussed just what PAD/SPD extensions we might need, and we came up with this: we need a new ID selector wildcard value, just like "ANY" but meaning "any peer, BTNS or otherwise." (And we need this new selector only so that configurations using the old selector don't suddenly allow BTNS where it was never intended when the implementations are upgraded to ones that support BTNS.) So, to sum up, the current state of thinking on BTNS is that we need no IKE extensions, just a new ID selector wildcard for PAD and SPD entries, which we may be calling 'UNKNOWN'; IKE/IKEv2 implementations have to understand 'UNKNOWN', of course, and we may still need a new ID type just so we can internally represent the "identities" of BTNS peers. I'll answer any of your points that aren't answered by this later. Thanks! Nico -- From lha at kth.se Tue Aug 16 04:27:08 2005 From: lha at kth.se (=?iso-8859-1?q?Love_H=F6rnquist_=C5strand?=) Date: Tue, 16 Aug 2005 13:27:08 +0200 Subject: [anonsec] draft BTNS minutes for IETF 63 Message-ID: Please check for accuracy and completeness. Love --- BTNS meeting notes These are the minutes for the Better then nothing security (BTNS) working group meeting, held at IETF-63 on Thursday, August 4, 2005, in Paris. Thanks to Tero Kivinen and Jeffrey Altman for the notes on which these minutes are based. Note that these minutes do not follow the typical IETF minutes format, transcribing the discussion, but are on a more condensed format. Chairs: Love H?rnquist ?strand and Pekka Nikander * Working group background Three different groups/interests: * protection against off-path attackers * working towards channel binding * SSH-like leap-of-faith use of IPsec The working group was chartered to: * specify extensions to IPsec so that IPsec will support creation of unauthenticated SAs. * enable and encourage simpler and more rapid deployment of IPsec. * Goals for the meeting * get WG feeling for problem and applicability statement. * Initiate work on SPD/PAD/IKE extensions. * Need to update the milestones to more realistic goals. * Other technical discussion. * Decisions made 1. Need to support tunnel mode where inner address is the same as outer address. This is because of requirements of other protocols, such as iSCSI. 2. Start to Work on IKE v2, and got back and see what changes is needed for IKE v1. * Current outstanding issues Some of these question where asked during the meeting (by group and chairs): - what details for the SPD/PAD extensions? - how do you detect BTNS? - should self-signed certificates or raw keys be used? - Is it OK to allow clear text traffic and then later kick in BTNS ? * Current work - SPD/PAD extensions For the next item the WG will work on is the SPD/PAD extensions draft, target is to have it out well before Vancouver meeting. The people volunteering to be on the design team, if one is formed, are: Nico Williams, Bill Sommerfeld, Stephen Kent, Charlie Kaufmann, Soichi Sakane, Tero Kivinen, Joe (Touch ?). Sam Hartman is willing to participate but cannot be part of a design team due to conflict of role. To avoid that conflict the discussion need to be on the list. The WG will attempt to proceed without a formal design team, but if that fails, the chairs will form and announce a design team as it becomes necessary. * Points to pay attention to Charlie Kaufmann: Its not should I send authentication but does the other care what the authentication info is? Sam Hartman (AD) considers it breaking IPsec if the users doesn't upgrade to full IKE to keep BTNS. Its in the group charter to not break IPsec. * Updating milestones These are the proposed dates by the chairs based on the discussing in the meeting, the dates are pushed forward 3 months. Sep 05 First version of SPD and/or PAD extensions draft (if needed) Oct 05 WG LC on problem and applicability statement (a+b) Oct 05 First version of IKE extensions draft (if needed) Nov 05 First version of IPsec interfaces draft (e) Nov 05 Submit problem and applicability statement to IESG (a+b) Jan 05 WG LC on IKE extensions (c) Jan 05 WG LC on SPD and/or PAD extensions (d) Feb 05 Submit IKE extensions to the IESG Feb 05 Submit SPD and/or PAD extensions to the IESG Mar 06 WG LC on IPsec interfaces draft Mar 06 Submit IPsec interfaces draft to the IESG May 06 Re-charter or close the WG * Discussion on Applicability and Problem statement Joe Touch made a presentation on the Applicability and Problem statement. The initial draft was issued the first of July. Joe requested more feedback on the document, questions asked was: Style feedback: - Are there issues missing? - Are there issues that should be dropped? Items to be addressed: - auto detect - auto upgrade to security as needed - Any aspect of solution requirements Issues needed to be clarified: * why application security is not good enough * the costs of redundancy * why are we starting with IPsec Current feedback Style: -repetitions, acronyms Content: - more info on why application layer isn't sufficient - add redundancy of cost, as well as configuration - explain why IKE was chosen. There was agreement in the room that Joe should use the right terminology following the WG that created the terminology. It might be good to add a glossary. Joe asks contributors to mark what kind of comment they are making style, structure, or clarifications. Joe will put off changes until we know what we are keeping. He plans to integrate current comments and issue a new draft in 3-4 weeks. The PS/AS statement will need 1-3 cycles before we can send it to WGLC. The target for WGLC is late sept/early October. Sam Hartman (AD) considers it breaking IPsec if the users doesn't upgrade to full IKE to keep BTNS. It would violate the charter of the group. Russ Housley: The question of asymmetric case was up during charter discussion in the BOF, needs to be supported. Pekka proposes that we should start with no authentication case and work of the other parts later. Provide guidance in the document as to witch problems should be dealt with first. * Nico Williams' presentation - Thinking about BTNS Slides: * Basics - Forget what I have in my -00 individual submission ID on BTNS. - Just do IKE with base public key as CERT and with ID type to assert the base public key as the ID. - Add a bit of the PAD to allow for rules that say "any BTNS peer can use the IP addresses from these ranges". - If anyone care, a "this bare public key , use this address". Properties - No real authentication - Protects against passive attackers - Protects against off-path injection attacks - Active attackers that can take over a victim's DIP can negotiate new SAs and go from there - But it can't take over existing connections - This is only slightly worse than plain IPsec in that at least in plain IPsec one can tie non-mobile devices' IDs to their static IP address; not so easy for BTNS Nico also presented ideas for an API/connection latching, this is for a slight out of charter/later work item, but was allowed to continue because there was still time left and this was the last issue. * IPsec APIs: Connection Latching - Latch all packets send/received by a transport (e.g., TCP) for a given connection to all SAs with some algs/IDs/etc... - record algs/IDs of SA negotiated and used for the first packet sent or received for a connection - Subsequently send or accept only packets protected with similar SAs - In KAME, Solaris, a socket option - Add more protection against active attacks * IPsec APIs: Connection Latching - Even UDP data-grams can be latches, through without a UDP "connection" you probably only want to bind each datagram (and its fragments) to a single SA. * IPsec APIs: Retrieve IDs/CERTs for latched connection - if applications can latch connections then applications could ask the transports for information about the ends of the connections - Latched IDs, CERTs and certificates chain used in certificate validation for initial connection packet. - Then ... * IPsec Channels and Channel Bindings - Much more protection against active attackers. As strong as upper layer authentication, against early active attacks ... * Other issues Joe Touch: If you are going to turn on IPsec, it is possible to produce a DoS by sending junk. There is a new mailing list "triage" to address this issue. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 477 bytes Desc: not available Url : http://www.postel.org/pipermail/anonsec/attachments/20050816/a3729bbb/attachment.bin From hartmans-ietf at mit.edu Wed Aug 17 14:04:25 2005 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Wed, 17 Aug 2005 17:04:25 -0400 Subject: [anonsec] AD input to SPD/PAD draft In-Reply-To: (Love =?iso-8859-1?q?H=F6rnquist_=C5strand's?= message of "Tue, 16 Aug 2005 13:27:08 +0200") References: Message-ID: >>>>> "Love" == Love H?rnquist ?strand writes: Love> Sam Hartman is willing to participate but cannot be Love> part of a design team due to conflict of role. To avoid that Love> conflict the discussion need to be on the list. To clarify. The conflict comes with significant involvement in the document, not with what mailing list it takes place on or any specific label. It seems clear to me that being part of a design team and making useful contributions to that team would be crossing the line where I would need to recuse myself from the document for IESG processing. I believe it is reasonable to comment on technical issues and offer opinions on the list and to review the document. If I get too heavily involved, I'll still need to recuse myself but I believe I can avoid that. I was not meaning to imply that a design team should not form or have a list. It's just that if such a team forms, I won't be part of it. But if I had the same level of involvement on a public list I'd still probably have a conflict. From kivinen at iki.fi Sun Aug 14 06:02:00 2005 From: kivinen at iki.fi (Tero Kivinen) Date: Sun, 14 Aug 2005 16:02:00 +0300 Subject: [anonsec] Contributing to BTNS In-Reply-To: References: Message-ID: <17151.16584.10677.719389@fireball.kivinen.iki.fi> Paul Wouters writes: > I personally find the draft focuses far too much on TCP-RST issues. Really, > if that is the main reason for BTNS, then a completely different solution to > that specific problem should be designed. The current BTNS is rather overkill > to fix the TCP-RST problem. BTW, one idea I had earlier is that if we are really concerned about TCP-RST issues, and we do not have enough CPU power to encrypt/authenticate all traffic, we would need new traffic selectors for the IPsec that would allow us to encrypt/authenticate only TCP control traffic packets (i.e. packets having SYN, FIN, RST etc bits on). That could also be used on the protocols having internal authentication inside, but which cannot protect against TCP-RSTs (ssl, ssh). This would be tradeoff between security and CPU power needed (yes, there would be still lots of different attack which can be used to break connections, but this could protect against SYN-flooding, blind TCP-RSTs etc). -- kivinen at safenet-inc.com From touch at ISI.EDU Tue Aug 23 08:48:38 2005 From: touch at ISI.EDU (Joe Touch) Date: Tue, 23 Aug 2005 08:48:38 -0700 Subject: [anonsec] Contributing to BTNS In-Reply-To: <17151.16584.10677.719389@fireball.kivinen.iki.fi> References: <17151.16584.10677.719389@fireball.kivinen.iki.fi> Message-ID: <430B4556.5080603@isi.edu> Tero Kivinen wrote: > Paul Wouters writes: > >>I personally find the draft focuses far too much on TCP-RST issues. Really, >>if that is the main reason for BTNS, then a completely different solution to >>that specific problem should be designed. The current BTNS is rather overkill >>to fix the TCP-RST problem. > > BTW, one idea I had earlier is that if we are really concerned about > TCP-RST issues, and we do not have enough CPU power to > encrypt/authenticate all traffic, we would need new traffic selectors > for the IPsec that would allow us to encrypt/authenticate only TCP > control traffic packets (i.e. packets having SYN, FIN, RST etc bits > on). That is one of many possible solutions, including using multiple levels of algorithms with varying computational loads. It would be useful to take this discussion over to the triage at postel.org mailing list (www.postel.org/triage), since it is orthogonal to the solutions being developed here (IMO). Joe > That could also be used on the protocols having internal > authentication inside, but which cannot protect against TCP-RSTs (ssl, > ssh). > > This would be tradeoff between security and CPU power needed (yes, > there would be still lots of different attack which can be used to > break connections, but this could protect against SYN-flooding, blind > TCP-RSTs etc). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/anonsec/attachments/20050823/1c485f9b/signature.bin From sharipriya at novell.com Fri Aug 26 03:40:50 2005 From: sharipriya at novell.com (Haripriya S) Date: Fri, 26 Aug 2005 04:40:50 -0600 Subject: [anonsec] Question on applicability statement Message-ID: <430F3F0A020000B600001770@lucius.provo.novell.com> Hi, I have gone through the applicability statement of BTNS and I am not very clear about the implications of CCB. For example, section 4.1 states BTNS is intended to protect the network and transport layer between two parties after an association is established. SAB is not intended to protect to whom associations are established based on authenticated identity. CBB does not protect with whom associations are established initially, but allows higher layer protocols that provide authentication to couple to network layer security after the association is established, at which time the association can be adjusted accordingly. Since higher layer protocols could authenticate multiple identities (think of two ftp client sessions from the same machine), does it mean that CCB will allow the higher layer protocols to couple 'the same network level SA to each of these higer level identities'? How does that work? Thanks, Haripriya S. From Nicolas.Williams at sun.com Fri Aug 26 08:38:28 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 26 Aug 2005 10:38:28 -0500 Subject: [anonsec] Question on applicability statement In-Reply-To: <430F3F0A020000B600001770@lucius.provo.novell.com> References: <430F3F0A020000B600001770@lucius.provo.novell.com> Message-ID: <20050826153828.GN15718@binky.Central.Sun.COM> On Fri, Aug 26, 2005 at 04:40:50AM -0600, Haripriya S wrote: > Hi, > > I have gone through the applicability statement of BTNS and I am not > very clear about the implications of CCB. For example, section 4.1 > states > > BTNS is intended to protect the network and transport layer between > two parties after an association is established. SAB is not intended > > to protect to whom associations are established based on > authenticated identity. CBB does not protect with whom associations > > are established initially, but allows higher layer protocols that > provide authentication to couple to network layer security after the > > association is established, at which time the association can be > adjusted accordingly. > > Since higher layer protocols could authenticate multiple identities > (think of two ftp client sessions from the same machine), does it mean > that CCB will allow the higher layer protocols to couple 'the same > network level SA to each of these higer level identities'? How does that > work? So, when using channel bindings to bind authentication at higher layers to secure channels at lower layers one must first have such a channel to bind to. IPsec does not define such channels, not as such anyways, but it is possible to construct them. My presentation dwelt on this briefly; there are at least two IPsec implementations that provide such channels through cooperation between the application and transport layer and the latter's dynamic manipulation of the SPD, in a way. Nico -- From touch at ISI.EDU Fri Aug 26 11:09:14 2005 From: touch at ISI.EDU (Joe Touch) Date: Fri, 26 Aug 2005 11:09:14 -0700 Subject: [anonsec] Question on applicability statement In-Reply-To: <20050826153828.GN15718@binky.Central.Sun.COM> References: <430F3F0A020000B600001770@lucius.provo.novell.com> <20050826153828.GN15718@binky.Central.Sun.COM> Message-ID: <430F5ACA.6090309@isi.edu> Nicolas Williams wrote: > On Fri, Aug 26, 2005 at 04:40:50AM -0600, Haripriya S wrote: > >>Hi, >> >>I have gone through the applicability statement of BTNS and I am not >>very clear about the implications of CCB. For example, section 4.1 >>states >> >>BTNS is intended to protect the network and transport layer between >> two parties after an association is established. SAB is not intended >> >> to protect to whom associations are established based on >> authenticated identity. CBB does not protect with whom associations >> >> are established initially, but allows higher layer protocols that >> provide authentication to couple to network layer security after the >> >> association is established, at which time the association can be >> adjusted accordingly. >> >>Since higher layer protocols could authenticate multiple identities >>(think of two ftp client sessions from the same machine), does it mean >>that CCB will allow the higher layer protocols to couple 'the same >>network level SA to each of these higer level identities'? How does that >>work? > > > So, when using channel bindings to bind authentication at higher layers > to secure channels at lower layers one must first have such a channel to > bind to. > > IPsec does not define such channels, not as such anyways, but it is > possible to construct them. My presentation dwelt on this briefly; > there are at least two IPsec implementations that provide such channels > through cooperation between the application and transport layer and the > latter's dynamic manipulation of the SPD, in a way. > > Nico It might be useful to tap this statement, or some more specific text you might offer, to address this in the PS/AS. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/anonsec/attachments/20050826/1fb8bf3f/signature.bin From Nicolas.Williams at sun.com Fri Aug 26 16:23:49 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 26 Aug 2005 18:23:49 -0500 Subject: [anonsec] Question on applicability statement In-Reply-To: <430F5ACA.6090309@isi.edu> References: <430F3F0A020000B600001770@lucius.provo.novell.com> <20050826153828.GN15718@binky.Central.Sun.COM> <430F5ACA.6090309@isi.edu> Message-ID: <20050826232349.GD15718@binky.Central.Sun.COM> On Fri, Aug 26, 2005 at 11:09:14AM -0700, Joe Touch wrote: > Nicolas Williams wrote: > > So, when using channel bindings to bind authentication at higher layers > > to secure channels at lower layers one must first have such a channel to > > bind to. > > > > IPsec does not define such channels, not as such anyways, but it is > > possible to construct them. My presentation dwelt on this briefly; > > there are at least two IPsec implementations that provide such channels > > through cooperation between the application and transport layer and the > > latter's dynamic manipulation of the SPD, in a way. > > It might be useful to tap this statement, or some more specific text you > might offer, to address this in the PS/AS. Indeed! How about adding this to section 2.2? Of course, in order to perform channel binding there must be a channel to bind to; IPsec defines no such channels, though such channels can be constructed by transports layered above IP through cooperation between the transports and IPsec to ensure that all packets for a given channel are protected by similar SAs, where similar relates to, among other things, the IDs of the peers. Interfaces between applications and the transports are also needed for communicating channel binding data to applications, and may be needed as well as for applications to construct their own IPsec channels over connection-less, datagram-oriented transports. Nico -- From touch at ISI.EDU Sat Aug 27 15:51:08 2005 From: touch at ISI.EDU (Joe Touch) Date: Sat, 27 Aug 2005 15:51:08 -0700 Subject: [anonsec] Question on applicability statement In-Reply-To: <20050826232349.GD15718@binky.Central.Sun.COM> References: <430F3F0A020000B600001770@lucius.provo.novell.com> <20050826153828.GN15718@binky.Central.Sun.COM> <430F5ACA.6090309@isi.edu> <20050826232349.GD15718@binky.Central.Sun.COM> Message-ID: <4310EE5C.1010203@isi.edu> We'll insert the following as per Nico's suggestion in this version, unless there are editing suggestions or objections on this list shortly. Joe Nicolas Williams wrote: > On Fri, Aug 26, 2005 at 11:09:14AM -0700, Joe Touch wrote: > >>Nicolas Williams wrote: >> >>>So, when using channel bindings to bind authentication at higher layers >>>to secure channels at lower layers one must first have such a channel to >>>bind to. >>> >>>IPsec does not define such channels, not as such anyways, but it is >>>possible to construct them. My presentation dwelt on this briefly; >>>there are at least two IPsec implementations that provide such channels >>>through cooperation between the application and transport layer and the >>>latter's dynamic manipulation of the SPD, in a way. >> >>It might be useful to tap this statement, or some more specific text you >>might offer, to address this in the PS/AS. > > > Indeed! > > How about adding this to section 2.2? > > Of course, in order to perform channel binding there must be a > channel to bind to; IPsec defines no such channels, though such > channels can be constructed by transports layered above IP through > cooperation between the transports and IPsec to ensure that all > packets for a given channel are protected by similar SAs, where > similar relates to, among other things, the IDs of the peers. > > Interfaces between applications and the transports are also needed > for communicating channel binding data to applications, and may be > needed as well as for applications to construct their own IPsec > channels over connection-less, datagram-oriented transports. > > Nico -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/anonsec/attachments/20050827/0a4ccc57/signature.bin From lha at kth.se Tue Aug 30 06:45:00 2005 From: lha at kth.se (=?iso-8859-1?q?Love_H=F6rnquist_=C5strand?=) Date: Tue, 30 Aug 2005 15:45:00 +0200 Subject: [anonsec] minutes for IETF63 submitted Message-ID: A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 477 bytes Desc: not available Url : http://www.postel.org/pipermail/anonsec/attachments/20050830/9eed1652/attachment.bin