From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Tue May 6 14:12:58 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01753 for ; Tue, 6 May 2003 14:12:53 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h46IEoU10216 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Tue, 6 May 2003 14:14:53 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h46IFNm18482 for ipseckey-outgoing; Tue, 6 May 2003 14:15:23 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h46IFMO18473 for ; Tue, 6 May 2003 14:15:22 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h46IEKU10206 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO) for ; Tue, 6 May 2003 14:14:21 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h46IEJwe031940; Tue, 6 May 2003 14:14:19 -0400 Message-Id: <200305061814.h46IEJwe031940@sandelman.ottawa.on.ca> To: ipseckey@sandelman.ca CC: Erik Nordmark Subject: [IPSECKEY] Re: draft-ietf-ipseckey-rr-00.txt In-reply-to: Your message of "Tue, 06 May 2003 10:45:29 +0200." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 06 May 2003 14:14:18 -0400 From: Michael Richardson Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Erik" == Erik Nordmark writes: Erik> The draft should explicitly say that the domain name in the RDATA Erik> (the gatway) Erik> must not be compressed. See draft-ietf-dnsext-unknown-rrs- Yes, good point. Is there a canonical way to refer to the domain-name in the RDATA? The self-describing format specified in 1035? Erik> Does the preference field have utility when there is no gateway? Yes, because no gateway usually means "self". ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPrf7coqHRg3pndX9AQE2LQP8Dr30PhVe7nU+4wmFD+zjGS0xzr7QeiqO SKrjW8fZS0U3C7qZh8DqVYJZvYBw/OibhEno53wPl/oRmh4EPbj1OciwAIYSY+De zNZUfMU/sKJkQ1H2ikEoJ1X9lD/IzyRHYemEiyFkgpm5/OYj7VR0aw9El+XbJE5V YuhpE/oSdwk= =nVOc -----END PGP SIGNATURE----- - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Wed May 7 16:18:06 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16017 for ; Wed, 7 May 2003 16:18:05 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h47KK7U14322 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Wed, 7 May 2003 16:20:10 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h47KKkY07438 for ipseckey-outgoing; Wed, 7 May 2003 16:20:46 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h47KKim07433 for ; Wed, 7 May 2003 16:20:44 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h47KJfU14316 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO) for ; Wed, 7 May 2003 16:19:42 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h47KJegs032583 for ; Wed, 7 May 2003 16:19:40 -0400 Message-Id: <200305072019.h47KJegs032583@sandelman.ottawa.on.ca> To: ipseckey@sandelman.ca Subject: [IPSECKEY] the -01 draft Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 07 May 2003 16:19:40 -0400 From: Michael Richardson Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca -----BEGIN PGP SIGNED MESSAGE----- I'm going to repeat the Security Considerations section here: 4. Security Considerations | This entire memo pertains to the provision of public keying material | for use by key management protocols such as ISAKMP/IKE (RFC2407) [7]. | Implementations of DNS servers and resolvers SHOULD take care to make | sure that the keying material is delivered intact to the end | application. The use of DNSSEC to provide end-to-end integrity | protection is strongly encouraged. | The semantics of this record is outside of the scope of this | document, so no advice for users of this information is provided. | Any user of this resource record MUST carefully document their trust | model, and why the trust model of DNSSEC is appropriate. === Secondly, is there agreement that "DNSSEC" generally includes use of TSIG, or should this be explicitely stated? It seems like overspecification to me. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPrlqWoqHRg3pndX9AQFsFAP7BqElI9Nw4kzJOGRIl+nGkP9aZTHwQrI0 yu8q7BUZ95nhKGxTO0E592yvZbQ5aYkXmqMDyqu7bSqbZjXNlfdv9QFUyHyX8J6U N7IYIQ0MUtDZOVisGRTBsTfLibjxR8Rj5gH/vuKuKKrqeVXOxe/4mqZCDv1FNvt8 SfCg1s0PaN4= =87dZ -----END PGP SIGNATURE----- - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Wed May 7 17:44:58 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18909 for ; Wed, 7 May 2003 17:44:57 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h47LlXU14608 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Wed, 7 May 2003 17:47:35 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h47LmUq11618 for ipseckey-outgoing; Wed, 7 May 2003 17:48:30 -0400 (EDT) Received: from nic.crt.se (nic.crt.se [193.12.107.10]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h47LmSm11610 for ; Wed, 7 May 2003 17:48:28 -0400 (EDT) Received: from mail.crt.se (postiljon.crt.se [193.12.115.230]) by nic.crt.se (Postfix) with ESMTP id 280E661B2; Wed, 7 May 2003 23:47:24 +0200 (CEST) Received: from crt.se (stargate-i.crt.se [193.12.115.229]) by mail.crt.se (Postfix) with ESMTP id E8D531D99; Wed, 7 May 2003 23:47:23 +0200 (MEST) Date: Wed, 7 May 2003 23:47:23 +0200 (CEST) From: Jakob Schlyter To: Michael Richardson Cc: ipseckey@sandelman.ca Subject: Re: [IPSECKEY] the -01 draft In-Reply-To: <200305072019.h47KJegs032583@sandelman.ottawa.on.ca> Message-ID: References: <200305072019.h47KJegs032583@sandelman.ottawa.on.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca On Wed, 7 May 2003, Michael Richardson wrote: > Secondly, is there agreement that "DNSSEC" generally includes use of > TSIG, or should this be explicitely stated? It seems like overspecification > to me. I think the resolution process should be stated. in draft-ietf-secsh-dns we wrote: "Clients that do not validate the DNSSEC signatures themselves MUST use a secure transport, e.g. TSIG [8], SIG(0) [9] or IPsec [7], between themselves and the entity performing the signature validation." jakob - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Wed May 7 17:48:18 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19011 for ; Wed, 7 May 2003 17:48:17 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h47LowU14621 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Wed, 7 May 2003 17:51:00 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h47LpxD11782 for ipseckey-outgoing; Wed, 7 May 2003 17:51:59 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h47Lpwm11777 for ; Wed, 7 May 2003 17:51:58 -0400 (EDT) Received: from thrintun.hactrn.net ([2002:425c:4242:0:250:daff:fe82:1c39]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h47LotU14618 for ; Wed, 7 May 2003 17:50:55 -0400 (EDT) Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id EFBD118EE for ; Wed, 7 May 2003 17:50:43 -0400 (EDT) Date: Wed, 07 May 2003 17:50:43 -0400 From: Rob Austein To: ipseckey@sandelman.ca Subject: Re: [IPSECKEY] the -01 draft In-Reply-To: <200305072019.h47KJegs032583@sandelman.ottawa.on.ca> References: <200305072019.h47KJegs032583@sandelman.ottawa.on.ca> User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030507215043.EFBD118EE@thrintun.hactrn.net> Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca At Wed, 07 May 2003 16:19:40 -0400, Michael Richardson wrote: > > Secondly, is there agreement that "DNSSEC" generally includes use of > TSIG, or should this be explicitely stated? It seems like overspecification > to me. One could make a case either way, but the "DNS Threats" document[1] took the position that TSIG is not part of "DNSSEC" per se, and I think the DNSSECbis editorial team[2] came to the same conclusion. Of course, I'm a co-author of [1] and a member of [2], so I may just be reporting my own (internally consistant) confusion. - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Wed May 7 20:47:12 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25529 for ; Wed, 7 May 2003 20:47:11 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h480nVU15032 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Wed, 7 May 2003 20:49:33 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h480oSs20087 for ipseckey-outgoing; Wed, 7 May 2003 20:50:28 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h480oRm20078 for ; Wed, 7 May 2003 20:50:27 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h480nNU15026 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO) for ; Wed, 7 May 2003 20:49:24 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h480nMqo006049; Wed, 7 May 2003 20:49:23 -0400 Message-Id: <200305080049.h480nMqo006049@sandelman.ottawa.on.ca> To: Jakob Schlyter cc: ipseckey@sandelman.ca Subject: Re: [IPSECKEY] the -01 draft In-reply-to: Your message of "Wed, 07 May 2003 23:47:23 +0200." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 07 May 2003 20:49:22 -0400 From: Michael Richardson Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca >>>>> "Jakob" == Jakob Schlyter writes: Jakob> I think the resolution process should be stated. Jakob> in draft-ietf-secsh-dns we wrote: Jakob> "Clients that do not validate the DNSSEC signatures themselves Jakob> MUST Jakob> use a secure transport, e.g. TSIG [8], SIG(0) [9] or IPsec [7], Jakob> between themselves and the entity performing the signature Jakob> validation." I'd rather write: Clients that do not validate the DNSSEC signatures themselves MUST communicate with a recursive resolver that does DNSSEC resolution using either a secure channel: local to the host, or via a TSIG or SIG(0) with another host. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Thu May 8 06:41:54 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19274 for ; Thu, 8 May 2003 06:41:53 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h48AiMU16839 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Thu, 8 May 2003 06:44:24 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h48Aj1o19542 for ipseckey-outgoing; Thu, 8 May 2003 06:45:01 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h48Aisi19533 for ; Thu, 8 May 2003 06:44:58 -0400 (EDT) Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h48AhiU16836 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL) for ; Thu, 8 May 2003 06:43:49 -0400 (EDT) Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h48AhcB4018025 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 8 May 2003 12:43:40 +0200 To: Michael Richardson Cc: Jakob Schlyter , ipseckey@sandelman.ca Subject: Re: [IPSECKEY] the -01 draft References: <200305080049.h480nMqo006049@sandelman.ottawa.on.ca> From: Simon Josefsson X-Payment: hashcash 1.2 0:030508:mcr@sandelman.ottawa.on.ca:6fc00b64a6157fbe X-Hashcash: 0:030508:mcr@sandelman.ottawa.on.ca:6fc00b64a6157fbe X-Payment: hashcash 1.2 0:030508:jakob@crt.se:4c720019b73fd677 X-Hashcash: 0:030508:jakob@crt.se:4c720019b73fd677 X-Payment: hashcash 1.2 0:030508:ipseckey@sandelman.ca:675ce49ae62ea570 X-Hashcash: 0:030508:ipseckey@sandelman.ca:675ce49ae62ea570 Date: Thu, 08 May 2003 12:43:38 +0200 In-Reply-To: <200305080049.h480nMqo006049@sandelman.ottawa.on.ca> (Michael Richardson's message of "Wed, 07 May 2003 20:49:22 -0400") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-32.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca Michael Richardson writes: >>>>>> "Jakob" == Jakob Schlyter writes: > Jakob> I think the resolution process should be stated. > > Jakob> in draft-ietf-secsh-dns we wrote: > > Jakob> "Clients that do not validate the DNSSEC signatures themselves > Jakob> MUST > Jakob> use a secure transport, e.g. TSIG [8], SIG(0) [9] or IPsec [7], > Jakob> between themselves and the entity performing the signature > Jakob> validation." > > I'd rather write: > Clients that do not validate the DNSSEC signatures themselves > MUST communicate with a recursive resolver that does DNSSEC resolution > using either a secure channel: local to the host, or via a TSIG > or SIG(0) with another host. This text imply that DNSSEC is required for IPSECKEY to work, which I believe would be a mistake. I believe IPSECKEY is useful without DNSSEC, just as long as the data is properly secured. DNSSEC may have been a hidden assumption in the mind set of people related to this work, but I see no technical justification for it. Preventing IPSECKEY to work with secure DNS systems that aren't based on DNSSEC would be unfortunate. I think Jakob's proposed text is better. - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Thu May 8 14:31:01 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02702 for ; Thu, 8 May 2003 14:31:00 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h48IXMU17931 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Thu, 8 May 2003 14:33:24 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h48IY3S12973 for ipseckey-outgoing; Thu, 8 May 2003 14:34:03 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h48IY1012968 for ; Thu, 8 May 2003 14:34:01 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h48IWvU17927 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO) for ; Thu, 8 May 2003 14:32:58 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h48IWu11028198 for ; Thu, 8 May 2003 14:32:56 -0400 Message-Id: <200305081832.h48IWu11028198@sandelman.ottawa.on.ca> To: ipseckey@sandelman.ca Subject: Re: [IPSECKEY] the -01 draft In-reply-to: Your message of "Thu, 08 May 2003 12:43:38 +0200." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Thu, 08 May 2003 14:32:56 -0400 From: Michael Richardson Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca -----BEGIN PGP SIGNED MESSAGE----- Simon, I see your point in the text that I wrote. Not my intention to restrict it. Jakob's text still implies that the signatures must be checked, which is not the case if one knows one is pulling it from a local server which may have an authoritative on disk source. How about: The IPSECKEY resource record contains information that MUST be communicated to the end client in an integral fashion - i.e. free from modification. The form of this channel is up to the consumer of the data. It may be end-to-end DNSSEC validation, a TSIG or SIG(0) channel to another secure source, a secure local channel on the host, or some combination of the above. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPrqi1YqHRg3pndX9AQHNVAQAvNpms2fiOB7p48MOdNsN67UKn0J94CGW RhYNb9OBae5T9GZusjyR9U73sJBv9EHuvZqdcoTTaDcuGAlJjyW0wWZMSj6KEcK4 OLyjjDTEuQKydFHI5UG/r6dEgfrYIroB6ij3/mS03Lfou8ysRU81DB+0mgD2jFGR YBBeTiuSifo= =aykE -----END PGP SIGNATURE----- - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Thu May 8 14:53:41 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03475 for ; Thu, 8 May 2003 14:53:40 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h48IuPU18047 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Thu, 8 May 2003 14:56:27 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h48IvRe14594 for ipseckey-outgoing; Thu, 8 May 2003 14:57:27 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h48IvQn14588 for ; Thu, 8 May 2003 14:57:26 -0400 (EDT) Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h48IuJU18044 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL) for ; Thu, 8 May 2003 14:56:21 -0400 (EDT) Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h48IuFB4026152 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 8 May 2003 20:56:16 +0200 To: Michael Richardson Cc: ipseckey@sandelman.ca Subject: Re: [IPSECKEY] the -01 draft References: <200305081832.h48IWu11028198@sandelman.ottawa.on.ca> From: Simon Josefsson X-Payment: hashcash 1.2 0:030508:mcr@sandelman.ottawa.on.ca:1efbd204d4f9701c X-Hashcash: 0:030508:mcr@sandelman.ottawa.on.ca:1efbd204d4f9701c X-Payment: hashcash 1.2 0:030508:ipseckey@sandelman.ca:01da593ef700bbbe X-Hashcash: 0:030508:ipseckey@sandelman.ca:01da593ef700bbbe Date: Thu, 08 May 2003 20:56:15 +0200 In-Reply-To: <200305081832.h48IWu11028198@sandelman.ottawa.on.ca> (Michael Richardson's message of "Thu, 08 May 2003 14:32:56 -0400") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-32.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca Michael Richardson writes: > Simon, I see your point in the text that I wrote. Not my intention to > restrict it. Jakob's text still implies that the signatures must be checked, > which is not the case if one knows one is pulling it from a local server > which may have an authoritative on disk source. > > How about: > The IPSECKEY resource record contains information that MUST be > communicated to the end client in an integral fashion - i.e. free > from modification. The form of this channel is up to the consumer > of the data. It may be end-to-end DNSSEC validation, a TSIG or SIG(0) > channel to another secure source, a secure local channel on the > host, or some combination of the above. Sounds good. There must be a trust relationship between the client and the server, so the client is able to trust that the data it is using really was unmodified. Perhaps this is obvious, though. Thanks! - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Thu May 8 15:07:42 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04451 for ; Thu, 8 May 2003 15:07:41 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h48JAMU18118 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Thu, 8 May 2003 15:10:25 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h48JBNq15302 for ipseckey-outgoing; Thu, 8 May 2003 15:11:23 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h48JBLn15291 for ; Thu, 8 May 2003 15:11:21 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h48JAHU18111 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO) for ; Thu, 8 May 2003 15:10:18 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h48JAGKd029254 for ; Thu, 8 May 2003 15:10:16 -0400 Message-Id: <200305081910.h48JAGKd029254@sandelman.ottawa.on.ca> To: ipseckey@sandelman.ca Subject: Re: [IPSECKEY] the -01 draft In-reply-to: Your message of "Thu, 08 May 2003 20:56:15 +0200." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Thu, 08 May 2003 15:10:15 -0400 From: Michael Richardson Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Simon" == Simon Josefsson writes: Simon> There must be a trust relationship between the client and the Simon> server, so the client is able to trust that the data it is using Simon> really was unmodified. Perhaps this is obvious, though. My impression is that "Security Considerations" sections are really there to make sure that the obvious is clearly stated for all. The text is now: 4. Security Considerations This entire memo pertains to the provision of public keying material for use by key management protocols such as ISAKMP/IKE (RFC2407) [7]. The IPSECKEY resource record contains information that MUST be communicated to the end client in an integral fashion - i.e. free from modification. The form of this channel is up to the consumer of the data - there must be a trust relationship between the end consumer of this resource record and the server. This relationship may be end-to-end DNSSEC validation, a TSIG or SIG(0) channel to another secure source, a secure local channel on the host, or some combination of the above. The semantics of this record is outside of the scope of this document, so no advice for users of this information is provided. Any user of this resource record MUST carefully document their trust model, and why the trust model of DNSSEC is appropriate, if that is the secure channel used. Chairs, are there further issues with the -01 document? ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPrqrj4qHRg3pndX9AQHZ0QP/R9lXePKZp8tDSHAHZ/9xBxRUuqgffiM4 OI54ZfkP4HTgjORW1RuX+rvLW3ghHg/fOCc7uhMTnKNM/5sbTlCRiVn4r/jFbECe 7DDcxUTv3AcJ8wNcYduqNL5+xQP5KDQDTmmtmftTBIUs2GF1uDg5uH3zoRXYCgfs tc4ICwn32o8= =2oy5 -----END PGP SIGNATURE----- - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Mon May 12 18:29:09 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07006 for ; Mon, 12 May 2003 18:29:08 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4CMVSm05049; Mon, 12 May 2003 18:31:29 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h4CMVbL29008 for ipseckey-outgoing; Mon, 12 May 2003 18:31:37 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4CMVaR29003 for ; Mon, 12 May 2003 18:31:36 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h4CMUSTh024334 for ; Mon, 12 May 2003 18:30:29 -0400 Message-Id: <200305122230.h4CMUSTh024334@sandelman.ottawa.on.ca> To: ipseckey@sandelman.ca Subject: [IPSECKEY] meta-list info In-reply-to: Your message of "Thu, 08 May 2003 20:56:15 +0200." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 12 May 2003 18:30:28 -0400 From: Michael Richardson Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca I noticed that email out of my system was generally blocked. ipseckey has two subcribers at @nic.mx, for which TLS was attempted, and it was hanging - sendmail needed -9 to boot it. I have rebuilt my sendmail with the right option to have it consult on whether or not to do TLS, and disabled it for nic.mx. Email should get unblocked slowly. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Mon May 12 18:29:13 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07004 for ; Mon, 12 May 2003 18:29:07 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4CMVrm05067; Mon, 12 May 2003 18:31:53 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h4CMAkN28055 for ipseckey-outgoing; Mon, 12 May 2003 18:10:46 -0400 (EDT) Received: from karoshi.com (vacation.karoshi.com [198.32.6.68]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4CMAiR28050 for ; Mon, 12 May 2003 18:10:44 -0400 (EDT) Received: (from bmanning@localhost) by karoshi.com (8.11.6/8.11.6 - yeah right) id h4CMEvL11027; Mon, 12 May 2003 15:14:57 -0700 From: bmanning@karoshi.com Message-Id: <200305122214.h4CMEvL11027@karoshi.com> Subject: Re: [IPSECKEY] "example" IPv6 blocks To: mcr@sandelman.ottawa.on.ca (Michael Richardson) Date: Mon, 12 May 2003 15:14:57 -0700 (PDT) Cc: ipseckey@sandelman.ca In-Reply-To: <200304282340.h3SNedPJ014939@marajade.sandelman.ottawa.on.ca> from "Michael Richardson" at Apr 28, 2003 07:40:38 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca Content-Transfer-Encoding: 7bit > > > IANA/IETF has reserved 192.2.0.0 for examples. > Is there an equivalent IPv6 block? > off by one error 192.0.2.0/24 --bill - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Tue May 13 00:02:46 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13787 for ; Tue, 13 May 2003 00:02:46 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4D45Nl06678 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Tue, 13 May 2003 00:05:26 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h4D46L416017 for ipseckey-outgoing; Tue, 13 May 2003 00:06:21 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4D46JR16000; Tue, 13 May 2003 00:06:19 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4CMW3m05071; Mon, 12 May 2003 18:32:03 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h4CMW3wX024389; Mon, 12 May 2003 18:32:03 -0400 Message-Id: <200305122232.h4CMW3wX024389@sandelman.ottawa.on.ca> To: bmanning@karoshi.com cc: mcr@lox.sandelman.ottawa.on.ca (Michael Richardson), ipseckey@sandelman.ca Subject: Re: [IPSECKEY] "example" IPv6 blocks In-reply-to: Your message of "Mon, 12 May 2003 15:14:57 PDT." <200305122214.h4CMEvL11027@karoshi.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 12 May 2003 18:32:02 -0400 From: Michael Richardson Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca >>>>> "bmanning" == bmanning writes: >> IANA/IETF has reserved 192.2.0.0 for examples. >> Is there an equivalent IPv6 block? bmanning> off by one error bmanning> 192.0.2.0/24 Yes... the document is actually correct. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From mcr@lox.sandelman.ottawa.on.ca Thu May 15 11:43:08 2003 Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [192.139.46.73]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12693 for ; Thu, 15 May 2003 11:43:08 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4FFkAQ18769 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO) for ; Thu, 15 May 2003 11:46:11 -0400 (EDT) Received: (from mcr@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h4FFkLg01645; Thu, 15 May 2003 11:46:21 -0400 (EDT) Date: Thu, 15 May 2003 11:46:21 -0400 (EDT) Message-Id: <200305151546.h4FFkLg01645@lox.sandelman.ottawa.on.ca> From: mcr@sandelman.ottawa.on.ca Subject: [ipseckey] Monthly information file for ipseckey@sandelman.ottawa.on.ca To: ipseckey-archive@ietf.org BOF description IPSEC KEYing information resource record WG (ipseckey) Please see http://www.ietf.org/html.charters/ipseckey-charter.html for the official page. To unsubscribe, email to majordomo@sandelman.ca, body is: "unsubscribe ipseckey" You can always ask majordomo@sandelman.ottawa.on.ca to remove you from any list hosted by Sandelman Software This message sent to ipseckey-archive@lists.ietf.org From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Sun May 18 17:07:02 2003 Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [192.139.46.73]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17597 for ; Sun, 18 May 2003 17:06:58 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4IL8up06163 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Sun, 18 May 2003 17:08:59 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h4IL9b317080 for ipseckey-outgoing; Sun, 18 May 2003 17:09:37 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4IL9ZM17059 for ; Sun, 18 May 2003 17:09:35 -0400 (EDT) Received: from fledge.watson.org (ak82hjs7hex92j@fledge.watson.org [204.156.12.50]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4IL8Kp06151 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO) for ; Sun, 18 May 2003 17:08:24 -0400 (EDT) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.9/8.12.9) with ESMTP id h4IL7uOn053112; Sun, 18 May 2003 17:07:56 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.12.9/8.12.9/Submit) with SMTP id h4IL7u8H053109; Sun, 18 May 2003 17:07:56 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Sun, 18 May 2003 17:07:56 -0400 (EDT) From: Sam Weiler Reply-To: Sam Weiler To: Michael Richardson cc: ipseckey@sandelman.ca Subject: [IPSECKEY] draft 01 nits In-Reply-To: <200305170124.h4H1OKNl007996@sandelman.ottawa.on.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca The submitted version should not have change bars. Chalk it up to Natalia downloading the wrong one, but it should be corrected. Abstract should not have references (see ID-nits). Abstract s/proposed to be// 1.1 /be authenticated DNSSEC resource record/be authenticated with DNSSEC/ 1.1 terminal node? What's a terminal node? Do you mean in a terminal node in the DNS tree? Can't there be A records for example.com as well as host.example.com? Why not IPSECKEY records? Is class independent the right answer? 2. I'd strip this line, instead putting it the IANA section as I've done in my draft. Go ahead and put in the number so they don't get confused -- they can always change it. 2.1 strip the parenthetical, just put algorithm type in the comma-separated list 2.2 Can you summarize the precendence interpretation? 2.3 First paragraph. Commas both seem out of place, or lacking a mate. 2.4 Should client handling of unknown formats be defined? 2.6 s/then public key/then the public key/ s/RFC3110 to/RFC3110 extended that limit to/ "for the purposes of encoding and decoding" didn't make sense on a first reading. Can you clean it up? You say "no such limit", but a two byte octet count, while huge, is still a limit. Why not say so? The rest of the text could be clearer, but it's verbatim 3110, so may as well leave it. 3.1 s/There/The/ Should client handling of the root (.) gateway be specified? 3.2 "a node 192.2.0.38" is awkward and probably needs to be changed. Why not just drop the address from the prose entirely? Even in the third example, you could say "...to another node specified by IPv4 address". "with the identity" seems like a bizarre phrasing. The second example: again, what does the client do? What does . mean? - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Sun May 18 18:56:21 2003 Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [192.139.46.73]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20136 for ; Sun, 18 May 2003 18:56:20 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4IMwpp06520 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Sun, 18 May 2003 18:58:53 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h4IMxug21969 for ipseckey-outgoing; Sun, 18 May 2003 18:59:56 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4IMxtM21964 for ; Sun, 18 May 2003 18:59:55 -0400 (EDT) Received: from sandelman.ottawa.on.ca ([2002:c08b:2e2f::1]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4IMwbp06509 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Sun, 18 May 2003 18:58:43 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h4IMYsWQ013520; Sun, 18 May 2003 18:35:54 -0400 Message-Id: <200305182235.h4IMYsWQ013520@sandelman.ottawa.on.ca> To: Sam Weiler cc: ipseckey@sandelman.ca Subject: [IPSECKEY] Re: draft 01 nits In-reply-to: Your message of "Sun, 18 May 2003 17:07:56 EDT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Sun, 18 May 2003 18:34:53 -0400 From: Michael Richardson Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca >>>>> "Sam" == Sam Weiler writes: Sam> The submitted version should not have change bars. Chalk it up to Sam> Natalia Sam> downloading the wrong one, but it should be corrected. No, I pointed her at that one :-) Clearly, a revision without change bars is easy to do. Sam> Abstract should not have references (see ID-nits). Rest I will process in a few. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Mon May 19 14:26:33 2003 Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [192.139.46.73]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29592 for ; Mon, 19 May 2003 14:26:31 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4JIRqp10324 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Mon, 19 May 2003 14:27:54 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h4JISdY26777 for ipseckey-outgoing; Mon, 19 May 2003 14:28:40 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4JIScv26772 for ; Mon, 19 May 2003 14:28:39 -0400 (EDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4JIRKp10312 for ; Mon, 19 May 2003 14:27:27 -0400 (EDT) Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 1919518E3 for ; Mon, 19 May 2003 14:26:14 -0400 (EDT) Date: Mon, 19 May 2003 14:26:14 -0400 From: Rob Austein To: ipseckey Subject: [IPSECKEY] Security Considerations User-Agent: Wanderlust/2.10.0 (Venus) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030519182614.1919518E3@thrintun.hactrn.net> Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca I sent Michael a bunch of comments on the current draft yesterday. Most of them were dumb little editorial stuff. The one really substantial comment was about the Security Considerations section. I don't think that what we have there now will fly, it fails the hurdle as stated in ID-nits: "Must have meaningful exploration of security issues raised by proposal, should include both risks and description of solutions or workarounds." I agreed to help Michael on fixing this (other volunteers would of course be welcome, nay, beseeched), but there's one point we need to clarify with the WG first: Is it the intention of this WG that the IPSECKEY RR be useful in an environment which does not (somehow) provide data origin authentication and data integrity protection for the IPSECKEY RR? Please note that I am trying -not- to make this explictly dependent on DNSSEC, the issue here is what services we require from the environment, not what specific mechanism provides those services. If the answer is "no, the WG doesn't expect IPSECKEY to be useful without data origin authentication and data integrity protection for the IPSECKEY RR", then the security considerations stuff is just a matter of writing up some stuff we already understand. If, however, the answer is "yes", then somebody needs to explain how and why it makes sense to trust keys that one gets without these protections, because we need to put that explanation into the draft. My (personal, private) take is that the answer to the question is "no", but that's for the WG as a whole to decide. Please also note that fixing up the Security Considerations section will probably involve evaluating SHOULDs and MUSTs elsewhere in the draft to make sure that they're consistant with what we've written. - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Mon May 19 16:32:16 2003 Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [192.139.46.73]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04983 for ; Mon, 19 May 2003 16:32:15 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4JKYJp10725 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Mon, 19 May 2003 16:34:22 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h4JKZOr03577 for ipseckey-outgoing; Mon, 19 May 2003 16:35:24 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4JKZMv03572 for ; Mon, 19 May 2003 16:35:22 -0400 (EDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4JKYAp10722 for ; Mon, 19 May 2003 16:34:11 -0400 (EDT) Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id A26F418E3; Mon, 19 May 2003 16:33:01 -0400 (EDT) Date: Mon, 19 May 2003 16:33:01 -0400 From: Rob Austein To: hugh@xisp.net Cc: ipseckey@sandelman.ca, gnu@toad.com, design@lists.freeswan.org, Hugh Daniel Subject: [IPSECKEY] Re: Security Considerations for IPSECKEY In-Reply-To: <200305191954.h4JJsJHX008066@road.toad.com> References: <200305191954.h4JJsJHX008066@road.toad.com> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030519203301.A26F418E3@thrintun.hactrn.net> Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca Pretty good answer, Hugh. I think it contains most (perhaps all) of what was missing from the Security Considerations. Thanks. Any other comments? - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Tue May 20 03:48:12 2003 Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [192.139.46.73]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02274 for ; Tue, 20 May 2003 03:48:10 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4K7oHp13488 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Tue, 20 May 2003 03:50:20 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h4K7p6N08161 for ipseckey-outgoing; Tue, 20 May 2003 03:51:06 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4K7p3O08156 for ; Tue, 20 May 2003 03:51:03 -0400 (EDT) Received: from herculanum.int-evry.fr (herculanum.int-evry.fr [157.159.11.15]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4K7npp13482 for ; Tue, 20 May 2003 03:49:51 -0400 (EDT) Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id D051D33B5B; Tue, 20 May 2003 09:49:46 +0200 (CEST) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id 420E13F42F; Tue, 20 May 2003 09:56:53 +0200 (CEST) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003052009494408521 ; Tue, 20 May 2003 09:49:44 +0200 Received: from localhost (ivan.int-evry.fr [157.159.100.48]) by sparte.int-evry.fr (Postfix) with ESMTP id C0A0D3F42F; Tue, 20 May 2003 09:56:50 +0200 (CEST) Received: from jjp by localhost with local id 19I1sH-00048y-00; Tue, 20 May 2003 09:49:29 +0200 Date: Tue, 20 May 2003 09:49:29 +0200 From: Jean-Jacques Puig To: Rob Austein Cc: ipseckey Subject: Re: [IPSECKEY] Security Considerations Message-ID: <20030520074929.GA15583@ivan.int-evry.fr> References: <20030519182614.1919518E3@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030519182614.1919518E3@thrintun.hactrn.net> Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca On Mon, May 19, 2003 at 02:26:14PM -0400, Rob Austein wrote: > Is it the intention of this WG that the IPSECKEY RR be useful in an > environment which does not (somehow) provide data origin > authentication and data integrity protection for the IPSECKEY RR? My opinion is also "no" (well, I mean it is not 'my' intention "that the IPSECKEY RR etc."). But I would be interested in the explanations of someone who would say "yes" here (pure curiosity :). > Please note that I am trying -not- to make this explictly dependent on > DNSSEC, the issue here is what services we require from the > environment, not what specific mechanism provides those services. Agree. Obviously, DNSSEC is not the only solution available here (it may depend on the use of the RR, which is not covered by the draft). I made the cut and paste for the WG to discuss on the real thing: 4. Security Considerations | This entire memo pertains to the provision of public keying material | for use by key management protocols such as ISAKMP/IKE (RFC2407) [7]. | Implementations of DNS servers and resolvers SHOULD take care to make | sure that the keying material is delivered intact to the end | application. The use of DNSSEC to provide end-to-end integrity | protection is strongly encouraged. May be 'strongly encouraged' is a bit... strong :). Why not something like: % Implementations of DNS servers and resolvers SHOULD take care to make % sure that the keying material is delivered intact to the end % application. End to end integrity can be achieved, for instance, % through the use of DNSSEC [8]. | The semantics of this record is outside of the scope of this | document, so no advice for users of this information is provided. | Any user of this resource record MUST carefully document their trust | model, and why the trust model of DNSSEC is appropriate. Well, anyway, current SC section looks good. I don't think we have a big issue here unless WG globally disagree on the importance of integrity and data origin authentication. -- Jean-Jacques Puig - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Tue May 20 11:01:37 2003 Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [192.139.46.73]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16827 for ; Tue, 20 May 2003 11:01:36 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4KF40p14758 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Tue, 20 May 2003 11:04:02 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h4KF52i00541 for ipseckey-outgoing; Tue, 20 May 2003 11:05:02 -0400 (EDT) Received: from cyteen.hactrn.net (dsl092-066-068.bos1.dsl.speakeasy.net [66.92.66.68]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4KF50O00529 for ; Tue, 20 May 2003 11:05:00 -0400 (EDT) Received: from thangorodrim.hactrn.net (unknown [2002:425c:4242:1:260:1dff:fef2:221e]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "thangorodrim.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id 5F9EA1AB for ; Tue, 20 May 2003 11:02:41 -0400 (EDT) Received: from thangorodrim.hactrn.net (localhost [::1]) by thangorodrim.hactrn.net (Postfix) with ESMTP id 3BE4523B6 for ; Tue, 20 May 2003 15:02:37 +0000 (UTC) Date: Tue, 20 May 2003 11:02:36 -0400 From: Rob Austein To: ipseckey@sandelman.ca Subject: [IPSECKEY] Forward: Security Considerations for IPSECKEY References: <200305191954.h4JJsJHX008066@road.toad.com> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/21.2 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: multipart/mixed; boundary="Multipart_Tue_May_20_11:02:22_2003-1" Message-Id: <20030520150238.3BE4523B6@thangorodrim.hactrn.net> Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca --Multipart_Tue_May_20_11:02:22_2003-1 Content-Type: text/plain; charset=US-ASCII [Jakob pointed out that I'd thanked Hugh for a message that hadn't made it to the mailing list -- majordomo probably didn't like Hugh's posting address, since it wasn't his usual one. Anyway, in the interest of moving discussion along, here's Hugh's message. --sra] --Multipart_Tue_May_20_11:02:22_2003-1 Content-Type: message/rfc822 Message-Id: <200305191954.h4JJsJHX008066@road.toad.com> To: ipseckey@sandelman.ca Cc: gnu@toad.com, mcr@sandelman.ca, weiler@watson.org, sra+ipseckey@hactrn.net, design@lists.freeswan.org Subject: Security Considerations for IPSECKEY Reply-To: hugh@xisp.net Errors-To: hugh@xisp.net Date: Mon, 19 May 2003 12:54:19 -0700 From: Hugh Daniel MIME-Version: 1.0 -----BEGIN PGP SIGNED MESSAGE----- A debate has arisen over the IPSECKEY draft "Security Considerations" section that is blocking it's forward progress. Let me take a stab at clearing up the issues a bit. There are two things that I think need to be clarified, first the the user threat model vs. integrity/authentication and second is the reach of any such integrity/authentication. So to the first issue. In the case of the current (non DNSsec) DNS system the IPSECKEY RR is very useful to any Internet user who's security "threat model" does not need to protect against "active attacks" such as Man-in-the-Middle (MitM). To protect against such active attacks one needs both verify and authenticate the entirety of the IPSECKEY RR (and many other RR's with out with the IPSECKEY RR is useless). The choice between these two usage models must be left up to the users and system/network administrators, but that a choice is being made by _someone_ needs to be clearly defined, maybe here. I feel that the IPSECKEY RR is clearly useful even in a non-DNSsec world where it provides protection against all forms of "passive attack". To explain why an un-verified/un-authenticated IPSECKEY RR is useful think about the difference between what security geeks call a "passive attack" vs. an "active attack". In an "active attack" the attacker needs to be in a position to alter the data flow (in this case the IPSECKEY RR) which can be hard and prone to detection. In a "passive attack" no data or meta data is changed, just "snooped", but the user can still be harmed (identity theft is an example). Thus having even an un-verified/un-authenticated IPSECKEY RR can help provide critical network security. In our case with IPsec we have even better protection in that unless the malfeasant is in a position to also mount a MitM attack any altered IPSECKEY RR data will be detected by ISAKMP/IKE and be rejected with NO security threat (wrong key, no SA's get created, no user data is moved), just a standard DoS as one might get with any sort of DNS poisoning. The second issue of the 'reach' of the integrity/authentication is what I think Mr. Richardson was trying to address in the -01 draft and likely needs to be made more clear. If the users (or system/network admins) "threat model" policy causes the IPSECKEY RR (and other RR's) to be integrity/authentication checked then the check it's self has to be securely delivered to the end user/program. In the current Internet it is quite possible that network designers will try to create networks where DNSsec caching and/or validation will happen on hosts that are across un-secured local LAN's from the end user/program. Such networks are fundamentally only as secure as the first issue case (raw DNS that protects only against passive attacks). I read the current wording as a warning against such non End-to-End designs, yet it is clear that the wording needs to be improved. Lastly, with the IPSECKEY RR the WG is providing a critical tool to link DNS information with bulk TCP/IP data transit, yet such a linkage might have different meanings to different users depending on how their systems use IPSECKEY along with other protocols (DNSsec, IPsec etc.). Thus the current draft statement that "The semantics of this record is outside of the scope of this document,"... is very true, though possibly in need of word smithing. I would like to note that we are all "security geeks" here and will need to work hard at not making the "Security Considerations" section longer then the actual document...if not longer then the IPsec RFC's in total! ||ugh Daniel hugh@freeswan.org Systems Testing & Project mis-Management The Linux FreeS/WAN Project http://www.freeswan.org -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv Comment: For the matching public key, finger the Reply-To: address. iQCVAwUBPsk2ZVZpdJR7FBQRAQF3wgQAhUG9uItJXiBIzmz/HUeWPPHSAelm1amf QkxrQo4bBpFZ7kvHIGasPC+UDvxeuhsk/VMkRm804F4Kygthl2KgMg7zglYIb7Ow +Uoo7lwUdtykTUsa/dbCukKhLy2BDjy9gNOJqeDCCvRT+O4yarpMtBO6YCbDVM2j zFCJvrObSFI= =hSnG -----END PGP SIGNATURE----- --Multipart_Tue_May_20_11:02:22_2003-1-- - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Tue May 20 14:01:51 2003 Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [192.139.46.73]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23225 for ; Tue, 20 May 2003 14:01:50 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4KI0qp15535 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Tue, 20 May 2003 14:00:55 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h4KI1c809497 for ipseckey-outgoing; Tue, 20 May 2003 14:01:38 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4KI1ai09492 for ; Tue, 20 May 2003 14:01:36 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4KI0Mp15532 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Tue, 20 May 2003 14:00:23 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h4KI0MIk005018 for ; Tue, 20 May 2003 14:00:22 -0400 Message-Id: <200305201800.h4KI0MIk005018@sandelman.ottawa.on.ca> To: ipseckey@sandelman.ca Subject: [IPSECKEY] Hugh Daniel: [Design] Security Considerations for IPSECKEY Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 20 May 2003 14:00:21 -0400 From: Michael Richardson Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca From: Hugh Daniel Subject: [Design] Security Considerations for IPSECKEY -----BEGIN PGP SIGNED MESSAGE----- A debate has arisen over the IPSECKEY draft "Security Considerations" section that is blocking it's forward progress. Let me take a stab at clearing up the issues a bit. There are two things that I think need to be clarified, first the the user threat model vs. integrity/authentication and second is the reach of any such integrity/authentication. So to the first issue. In the case of the current (non DNSsec) DNS system the IPSECKEY RR is very useful to any Internet user who's security "threat model" does not need to protect against "active attacks" such as Man-in-the-Middle (MitM). To protect against such active attacks one needs both verify and authenticate the entirety of the IPSECKEY RR (and many other RR's with out with the IPSECKEY RR is useless). The choice between these two usage models must be left up to the users and system/network administrators, but that a choice is being made by _someone_ needs to be clearly defined, maybe here. I feel that the IPSECKEY RR is clearly useful even in a non-DNSsec world where it provides protection against all forms of "passive attack". To explain why an un-verified/un-authenticated IPSECKEY RR is useful think about the difference between what security geeks call a "passive attack" vs. an "active attack". In an "active attack" the attacker needs to be in a position to alter the data flow (in this case the IPSECKEY RR) which can be hard and prone to detection. In a "passive attack" no data or meta data is changed, just "snooped", but the user can still be harmed (identity theft is an example). Thus having even an un-verified/un-authenticated IPSECKEY RR can help provide critical network security. In our case with IPsec we have even better protection in that unless the malfeasant is in a position to also mount a MitM attack any altered IPSECKEY RR data will be detected by ISAKMP/IKE and be rejected with NO security threat (wrong key, no SA's get created, no user data is moved), just a standard DoS as one might get with any sort of DNS poisoning. The second issue of the 'reach' of the integrity/authentication is what I think Mr. Richardson was trying to address in the -01 draft and likely needs to be made more clear. If the users (or system/network admins) "threat model" policy causes the IPSECKEY RR (and other RR's) to be integrity/authentication checked then the check it's self has to be securely delivered to the end user/program. In the current Internet it is quite possible that network designers will try to create networks where DNSsec caching and/or validation will happen on hosts that are across un-secured local LAN's from the end user/program. Such networks are fundamentally only as secure as the first issue case (raw DNS that protects only against passive attacks). I read the current wording as a warning against such non End-to-End designs, yet it is clear that the wording needs to be improved. Lastly, with the IPSECKEY RR the WG is providing a critical tool to link DNS information with bulk TCP/IP data transit, yet such a linkage might have different meanings to different users depending on how their systems use IPSECKEY along with other protocols (DNSsec, IPsec etc.). Thus the current draft statement that "The semantics of this record is outside of the scope of this document,"... is very true, though possibly in need of word smithing. I would like to note that we are all "security geeks" here and will need to work hard at not making the "Security Considerations" section longer then the actual document...if not longer then the IPsec RFC's in total! ||ugh Daniel hugh@freeswan.org Systems Testing & Project mis-Management The Linux FreeS/WAN Project http://www.freeswan.org -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv Comment: For the matching public key, finger the Reply-To: address. iQCVAwUBPsk2ZVZpdJR7FBQRAQF3wgQAhUG9uItJXiBIzmz/HUeWPPHSAelm1amf QkxrQo4bBpFZ7kvHIGasPC+UDvxeuhsk/VMkRm804F4Kygthl2KgMg7zglYIb7Ow +Uoo7lwUdtykTUsa/dbCukKhLy2BDjy9gNOJqeDCCvRT+O4yarpMtBO6YCbDVM2j zFCJvrObSFI= =hSnG -----END PGP SIGNATURE----- _______________________________________________ Design mailing list Design@lists.freeswan.org http://lists.freeswan.org/mailman/listinfo/design - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Tue May 20 14:21:59 2003 Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [192.139.46.73]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23987 for ; Tue, 20 May 2003 14:21:58 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4KILap15617 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Tue, 20 May 2003 14:21:40 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h4KIMkm10581 for ipseckey-outgoing; Tue, 20 May 2003 14:22:46 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4KIMji10576 for ; Tue, 20 May 2003 14:22:45 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4KILVp15614 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Tue, 20 May 2003 14:21:33 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h4KILVML005473 for ; Tue, 20 May 2003 14:21:31 -0400 Message-Id: <200305201821.h4KILVML005473@sandelman.ottawa.on.ca> To: ipseckey@sandelman.ca Subject: [IPSECKEY] Re: comments and nits (not including SC) In-reply-to: Your message of "Sun, 18 May 2003 18:24:57 EDT." <20030518222457.EC50218E3@thrintun.hactrn.net> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 20 May 2003 14:21:31 -0400 From: Michael Richardson Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca -----BEGIN PGP SIGNED MESSAGE----- {Rob, I'm reordering so that things were discussion/conversation is needed is at the top} >>>>> "Rob" == Rob Austein writes: Rob> Nit: Rob> | 3 A wire-encoded domain-name is present. The wire-encoded format is Rob> | self-describing, so the length is implicit. Rob> Change: Rob> s/domain-name/domain name/ Rob> Rational: Rob> There's no such thing as a "domain-name". RFC1035:, section 3.3: is a domain name represented as a series of labels, and terminated by a label with zero length. is a single length octet followed by that number of characters. is treated as binary information, and can be up to 256 characters in length (including the length octet). Perhaps I should say ""? Rob> Minor content: Rob> This record replaces the functionality of the sub-type #1 of the Rob> KEY Resource Record, which has been proposed to be obsoleted by Rob> RFC3445 [11]. Rob> Change: Rob> s/proposed to be obsoleted/obsoleted/ Done. Original was written prior to publication. I've been told to get rid of the reference in the abstract. Do I do this by just deleting the [11], or the RFC3445. as well? Rob> s/name/name for use with the IPsec protocol suite/ Rob> Rationale: Rob> Our charter clearly limits us to the IPSEC-specific scope, so the Rob> document needs to be equally clear about that. I don't particularly Rob> care how this is phrased so long as the scope is stated clearly enough Rob> that nobody can claim it's ambiguous. What the abstract says is fine, Rob> but the introduction needs to say it too. Done. Rob> Minor content: Rob> An IPSECKEY resource record SHOULD be authenticated DNSSEC resource Rob> record. Rob> Change: Rob> s/SHOULD be authenticated DNSSEC resource record/MUST be used in Rob> combination with DNSSEC unless some other means of authenticating the Rob> IPSECKEY resource record is available/ Done. Rob> I think that this rephrasing of the SHOULD as a conditional MUST Rob> captures the intent of the WG (I could be wrong), and seems more Rob> likely to survive IETF last call and IESG review than the original. I think that I agree with your intent. But, I thought that this is where "SHOULD" was was useful. I was trying to write: An IPSECKEY resource record SHOULD be authenticated. DNSSEC is the recommended method. See next message dealing with SC section. Rob> Strunk & White, "The Elements of Style", section 1, rule 3 :). Rob> Summary: it's ok to omit both of the commas surrounding a brief Rob> parenthetical clause, but if you keep one, you have to keep the other. Did I mention English was my second language? :-) marajade-[~] mcr 1036 %echo $LANG C Rob> Change: Rob> s/format of the gateway/format of the information/ Done. Rob> ================================================================ Rob> Nit: Rob> | The gateway field indicates a gateway to which an IPsec tunnel may be Rob> | created in order to reach the entity holding this resource record. Rob> Change: Rob> s/holding/named by/ Rob> Rational: Rob> Not clear what it means for an entity to "hold" a DNS name. I'd say "naming" - Its the thing on the left that I want to refer to. Rob> s/, as defined/. The data portion is an IPv4 address as described/ Rob> s/name (section 3.3 of RFC1035 [2])/name, as described in section 3.3 of RFC1035 [2]/ Rob> Rational: Done. Rob> s/value 5/value 5,/ Done. Rob> Nit: Rob> RFC2065 limited the exponent and modulus to 2552 bits in length, and Rob> RFC3110 to 4096 bits. No such limit is specified here for the Rob> purposes of encoding and decoding. Rob> Change: Rob> s/RFC3110 to 4096/RFC3110 limits them to 4096/ Rob> Rational: Rob> I don't -think- that RFC2065 limits RFC3110 to 4096 bits :). Done. Rob> s/255 and by/255, and as/ Done. Rob> ================================================================ Rob> Minor content: Rob> IPSECKEY RRs may appear as lines in a zone data master file. The Rob> | precedence, gateway type and algorithm and gateway fields are Rob> | REQUIRED. There base64 encoded public key block is OPTIONAL. Rob> If no gateway is to be indicated, then the root (".") SHOULD be used. Rob> Change: Rob> s/appear as lines/appear/ Done. Rob> s/then the root (".") SHOULD be used/then the gateway type field MUST Rob> be zero, and the gateway type MUST be "."/ Rob> s/OPTIONAL; if not present, then the public key field of the resource Rob> record MUST be construed as being zero octets in length/ Done. Rob> Rational: Rob> The first change is because we're not defining the format of master Rob> files, just the format of the RDATA portion of this one RR. Rob> The rest of the changes are intended to remove potential ambiguities. Rob> Nit: Rob> | An example of a node, 3ffe:501:4819:2000:210:f3ff:fe03:4d0 that has Rob> | delegated authority to the node Rob> Change: Rob> s/to the node/to the node 2001:200:0:8002::2000:1./ Done. Rob> See ID-nits comments (below), though, the address itself will probably Rob> have to change. Switched to 2002: example. Bill Manning says that there is an example allocation in IPv6. Rob> ID-nits: Rob> You can't use non-US-ASCII, so you'll have to change the spelling of Rob> both occurances of Olafur's name in the acknowledgements section. okay. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCUAwUBPspyKYqHRg3pndX9AQFoNgP3TVZUU801wvN+dm1nPMtoPzi/GB5MWpFc fduS2IKGyMUB9SvBx8P/uasDmhzyzHC//TkvrWLTj9dhPMWPQaM6S54Anm+bQKx5 vNGZgLeu7QGtANGRx4tELvWZCEe32jikKO5qteQRxgPDXgmV6aAR0bW7+bvqvzU+ 9EmJf8adcQ== =R4O5 -----END PGP SIGNATURE----- - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Tue May 20 14:37:24 2003 Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [192.139.46.73]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24513 for ; Tue, 20 May 2003 14:37:23 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4KIaZp15689 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Tue, 20 May 2003 14:36:37 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h4KIbjw11303 for ipseckey-outgoing; Tue, 20 May 2003 14:37:45 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4KIbii11298 for ; Tue, 20 May 2003 14:37:44 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4KIaUp15686 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Tue, 20 May 2003 14:36:32 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h4KIaUoM005815 for ; Tue, 20 May 2003 14:36:30 -0400 Message-Id: <200305201836.h4KIaUoM005815@sandelman.ottawa.on.ca> To: ipseckey@sandelman.ca Subject: [IPSECKEY] Re: draft 01 nits In-reply-to: Your message of "Sun, 18 May 2003 17:07:56 EDT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 20 May 2003 14:36:29 -0400 From: Michael Richardson Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Sam" == Sam Weiler writes: Sam> 1.1 terminal node? What's a terminal node? Do you mean in a Sam> terminal node in the DNS tree? Can't there be A records for Sam> example.com as well as Sam> host.example.com? Why not IPSECKEY records? Well, in the *OE* use, for which we have an acceptable threat model description, there isn't. However, if RR may have use elsewhere, then you may be correct. I will remove the word "terminal" Sam> Is class independent the right answer? We decided this in SFO. Sam> 2. I'd strip this line, instead putting it the IANA section as I've Sam> done in my draft. Go ahead and put in the number so they don't get Sam> confused -- they can always change it. Did Jakob figure out what the recommendation was going to be? Sam> 2.1 strip the parenthetical, just put algorithm type in the Sam> comma-separated list Done. Sam> 2.2 Can you summarize the precendence interpretation? Gateways listed in IPSECKEY records records with lower precedence are to be attempted first. Where there is a tie in precedence, they order should be non-deterministic. Sam> 2.3 First paragraph. Commas both seem out of place, or lacking a Sam> mate. Fixed already. Sam> 2.4 Should client handling of unknown formats be defined? You mean, what should the client do if the value isn't 0, 1, 2 or 3? I'm open to suggestions. I'd say just pretend that the record didn't exist. Sam> 2.6 s/then public key/then the public key/ Sam> s/RFC3110 to/RFC3110 extended that limit to/ Sam> "for the purposes of encoding and decoding" didn't make sense on Sam> a first reading. Can you clean it up? Sam> You say "no such limit", but a two byte octet count, while huge, is Sam> still a limit. Why not say so? The rest of the text could be Sam> clearer, Sam> but it's verbatim 3110, so may as well leave it. so, it is cleaned up a bit already, the point of "encoding and decoding" is that DNS implementations MUST permit the entire size to be encoded and decoded. But, for practical purposes a document that uses this may set a lower limit on the size of the keys. Sam> 3.1 s/There/The/ Sam> Should client handling of the root (.) gateway be specified? That's already mentioned now. Sam> 3.2 "a node 192.2.0.38" is awkward and probably needs to be changed. Sam> Why Sam> not just drop the address from the prose entirely? Even in the third Sam> example, you could say "...to another node specified by IPv4 address". Sam> "with the identity" seems like a bizarre phrasing. okay. Sam> The second example: again, what does the client do? What does . mean? that would be a question as to semantics of this record, right? I was going to say that this is out of scope, but I just re-read the charter, which seems to be a bit broader than I had originally thought: The WG will define the semantics of the record only in terms of how the data in the record can be used for initializing an IPSEC session. Questions of when it is appropriate to do so are regarded as policy issues that are out of scope for this WG. I am reluctant to write very much here, because I feel that it will quickly become dozens of pages. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPsp1rIqHRg3pndX9AQGp9AQAto0xtsHVrBsSE8HrG4ITNc0rlCMPnZbC VGowgKpZ+BExIH/eTriWTVpnAtvA4X1o9vH5mVgEivUomq0jV19xAVZDuUsU1C3K nZfk7NRHVpWUDSbLCsfjbyuZR5UcYnIeEfMaTNE8RMCWC+ngKZh8A4xDsCDEhfJm FKdXPjYMhDQ= =ibmY -----END PGP SIGNATURE----- - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Tue May 20 15:08:49 2003 Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [192.139.46.73]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25980 for ; Tue, 20 May 2003 15:08:48 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4KJ8Qp15890 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Tue, 20 May 2003 15:08:28 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h4KJ9RK13131 for ipseckey-outgoing; Tue, 20 May 2003 15:09:27 -0400 (EDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4KJ9Pi13126 for ; Tue, 20 May 2003 15:09:26 -0400 (EDT) Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 99BE518C1 for ; Tue, 20 May 2003 15:07:04 -0400 (EDT) Date: Tue, 20 May 2003 15:07:04 -0400 From: Rob Austein To: ipseckey@sandelman.ca Subject: Re: [IPSECKEY] Re: comments and nits (not including SC) In-Reply-To: <200305201821.h4KILVML005473@sandelman.ottawa.on.ca> References: <20030518222457.EC50218E3@thrintun.hactrn.net> <200305201821.h4KILVML005473@sandelman.ottawa.on.ca> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030520190704.99BE518C1@thrintun.hactrn.net> Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca At Tue, 20 May 2003 14:21:31 -0400, Michael Richardson wrote: > > >>>>> "Rob" == Rob Austein writes: > Rob> Nit: > > Rob> | 3 A wire-encoded domain-name is present. The wire-encoded format is > Rob> | self-describing, so the length is implicit. > > Rob> Change: > > Rob> s/domain-name/domain name/ > > Rob> Rational: > > Rob> There's no such thing as a "domain-name". > > RFC1035:, section 3.3: > > is a domain name represented as a series of labels, and > terminated by a label with zero length. is a single > length octet followed by that number of characters. > is treated as binary information, and can be up to 256 characters in > length (including the length octet). > > Perhaps I should say ""? As I said, a nit, but anyway... The RFC 1035 context is a (partial) BNF grammer, which replaces interword whitespace in multi-word token names with hyphenation. In ordinary running text it's still "domain name" (or "DNS name"). > I've been told to get rid of the reference in the abstract. Do I do this > by just deleting the [11], or the RFC3445. as well? Deleting just [11] may suffice, deleting both is safest. > Rob> Minor content: > > Rob> An IPSECKEY resource record SHOULD be authenticated DNSSEC resource > Rob> record. > > Rob> Change: > > Rob> s/SHOULD be authenticated DNSSEC resource record/MUST be used in > Rob> combination with DNSSEC unless some other means of authenticating the > Rob> IPSECKEY resource record is available/ > > Done. > > Rob> I think that this rephrasing of the SHOULD as a conditional MUST > Rob> captures the intent of the WG (I could be wrong), and seems more > Rob> likely to survive IETF last call and IESG review than the original. > > I think that I agree with your intent. > But, I thought that this is where "SHOULD" was was useful. I was trying > to write: > > An IPSECKEY resource record SHOULD be authenticated. > DNSSEC is the recommended method. > > See next message dealing with SC section. Ack, let's revisit this one after the Security Considerations section. > Rob> | The gateway field indicates a gateway to which an IPsec tunnel may be > Rob> | created in order to reach the entity holding this resource record. > > Rob> Change: > > Rob> s/holding/named by/ > > Rob> Rational: > > Rob> Not clear what it means for an entity to "hold" a DNS name. > > I'd say "naming" - Its the thing on the left that I want to refer to. s/holding/named by the owner name of/ ("owner name" is the DNS weenie term for the thing on the left.) > Rob> | An example of a node, 3ffe:501:4819:2000:210:f3ff:fe03:4d0 that has > Rob> | delegated authority to the node > > Rob> Change: > > Rob> s/to the node/to the node 2001:200:0:8002::2000:1./ > > Done. > > Rob> See ID-nits comments (below), though, the address itself will probably > Rob> have to change. > > Switched to 2002: example. > Bill Manning says that there is an example allocation in IPv6. Cool, I must've missed it. Reference? - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Tue May 20 15:27:28 2003 Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [192.139.46.73]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27167 for ; Tue, 20 May 2003 15:27:27 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4KJR5p15954 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Tue, 20 May 2003 15:27:07 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h4KJSG113982 for ipseckey-outgoing; Tue, 20 May 2003 15:28:16 -0400 (EDT) Received: from herculanum.int-evry.fr (herculanum.int-evry.fr [157.159.11.15]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4KJSDi13977 for ; Tue, 20 May 2003 15:28:13 -0400 (EDT) Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id BDCC234569 for ; Tue, 20 May 2003 21:22:41 +0200 (CEST) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id A96B23F43F for ; Tue, 20 May 2003 21:29:58 +0200 (CEST) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003052021224014804 for ; Tue, 20 May 2003 21:22:40 +0200 Received: from localhost (ivan.int-evry.fr [157.159.100.48]) by sparte.int-evry.fr (Postfix) with ESMTP id 661933F43F for ; Tue, 20 May 2003 21:29:58 +0200 (CEST) Received: from jjp by localhost with local id 19ICgq-0000qH-00 for ; Tue, 20 May 2003 21:22:24 +0200 Date: Tue, 20 May 2003 21:22:24 +0200 From: Jean-Jacques Puig To: ipsec Subject: Re: [IPSECKEY] Security Considerations Message-ID: <20030520192224.GA21812@ivan.int-evry.fr> References: <20030519182614.1919518E3@thrintun.hactrn.net> <20030520074929.GA15583@ivan.int-evry.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030520074929.GA15583@ivan.int-evry.fr> Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca On Tue, May 20, 2003 at 09:49:29AM +0200, Jean-Jacques Puig wrote: > On Mon, May 19, 2003 at 02:26:14PM -0400, Rob Austein wrote: > > Is it the intention of this WG that the IPSECKEY RR be useful in an > > environment which does not (somehow) provide data origin > > authentication and data integrity protection for the IPSECKEY RR? > > My opinion is also "no" (well, I mean it is not 'my' intention "that the > IPSECKEY RR etc."). But I would be interested in the explanations of > someone who would say "yes" here (pure curiosity :). Sorry, I realized reading `comments and nits` from Mr Austein that I possibly misunderstood his words. IMHO, express an 'intent' is not the same as to 'order': the former expresses itself with SHOULD while the later expresses with MUST. Rephrasing my answer: "no, it is not my intention that the IPSECKEY RR ... which does not (somehow) ... for the IPSECKEY RR BUT I don't care if someone uses this RR in such an environment." > 4. Security Considerations > > | This entire memo pertains to the provision of public keying material > | for use by key management protocols such as ISAKMP/IKE (RFC2407) [7]. > > | Implementations of DNS servers and resolvers SHOULD take care to make > | sure that the keying material is delivered intact to the end > | application. The use of DNSSEC to provide end-to-end integrity > | protection is strongly encouraged. > > May be 'strongly encouraged' is a bit... strong :). Why not something > like: > > % Implementations of DNS servers and resolvers SHOULD take care to make > % sure that the keying material is delivered intact to the end > % application. End to end integrity can be achieved, for instance, > % through the use of DNSSEC [8]. This is where we disagree I think. SHOULD is perfectly suitable here (IMHO), and MUST would be more than expressing an intent: it would express a requirement. 2119: 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. I don't think it is a up to the wg to make DNSSEC or any other mecanism mandatory. We surely can provide advices though. > > | The semantics of this record is outside of the scope of this > | document, so no advice for users of this information is provided. > | Any user of this resource record MUST carefully document their trust > | model, and why the trust model of DNSSEC is appropriate. -- Jean-Jacques Puig - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Tue May 20 15:33:16 2003 Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [192.139.46.73]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27401 for ; Tue, 20 May 2003 15:33:15 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4KJWjp15993 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Tue, 20 May 2003 15:32:47 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h4KJXsa14264 for ipseckey-outgoing; Tue, 20 May 2003 15:33:55 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4KJXri14259 for ; Tue, 20 May 2003 15:33:54 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4KJWep15990 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Tue, 20 May 2003 15:32:41 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h4KJWeTu007335 for ; Tue, 20 May 2003 15:32:40 -0400 Message-Id: <200305201932.h4KJWeTu007335@sandelman.ottawa.on.ca> To: ipseckey@sandelman.ca Subject: [IPSECKEY] Security Considerations Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 20 May 2003 15:32:39 -0400 From: Michael Richardson Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca 4. Security Considerations This entire memo pertains to the provision of public keying material for use by key management protocols such as ISAKMP/IKE (RFC2407) [7]. The IPSECKEY resource record contains information that MUST be communicated to the end client in an integral fashion - i.e. free from modification. The form of this channel is up to the consumer of the data - there must be a trust relationship between the end consumer of this resource record and the server. This relationship may be end-to-end DNSSEC validation, a TSIG or SIG(0) channel to another secure source, a secure local channel on the host, or some combination of the above. The keying material provided by the IPSECKEY resource record is not sensitive to passive attacks - it may be freely disclosed to any party without any impact on the security properties of the resulting IPsec session: IPsec and IKE provide for defense against both active and passive attacks. An active attack against this record, were it not provided with end- to-end integrity, would provide an opportunity for an attacker to replace the keying material. If the attacker was not able to subsequently mount a second man-in- the-middle attack on the IKE negotiation, then this would result in a denial of service, as the authentication used by IKE would fail. If the attacker was also in a position to perform a man-in-the-middle attack on IKE and IPsec negotiations as well, then it would be a position to compromise the resulting IPsec channel. Note that an attack must be able to perform active DNS attacks on both sides of the IKE negotiation in order for this to succeed. The semantics of when to use this record is outside of the scope of this document. Any user of this resource record MUST carefully document their trust model, and why the trust model of DNSSEC is appropriate, if that is the secure channel used. - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Tue May 20 16:41:45 2003 Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [192.139.46.73]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29435 for ; Tue, 20 May 2003 16:41:43 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4KKfJp16260 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Tue, 20 May 2003 16:41:21 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h4KKgUd17639 for ipseckey-outgoing; Tue, 20 May 2003 16:42:30 -0400 (EDT) Received: from herculanum.int-evry.fr (herculanum.int-evry.fr [157.159.11.15]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4KKgTi17630 for ; Tue, 20 May 2003 16:42:29 -0400 (EDT) Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id D0CED3447F; Tue, 20 May 2003 22:41:10 +0200 (CEST) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id EAF1E3F43F; Tue, 20 May 2003 22:48:28 +0200 (CEST) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003052022410925281 ; Tue, 20 May 2003 22:41:09 +0200 Received: from localhost (ivan.int-evry.fr [157.159.100.48]) by sparte.int-evry.fr (Postfix) with ESMTP id 85D6E3F43F; Tue, 20 May 2003 22:48:28 +0200 (CEST) Received: from jjp by localhost with local id 19IDun-0004SP-00; Tue, 20 May 2003 22:40:53 +0200 Date: Tue, 20 May 2003 22:40:53 +0200 From: Jean-Jacques Puig To: Michael Richardson Cc: ipseckey@sandelman.ca Subject: Re: [IPSECKEY] Security Considerations Message-ID: <20030520204053.GA3345@ivan.int-evry.fr> References: <200305201932.h4KJWeTu007335@sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200305201932.h4KJWeTu007335@sandelman.ottawa.on.ca> Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca Wow, it got huge ! On Tue, May 20, 2003 at 03:32:39PM -0400, Michael Richardson wrote: > > 4. Security Considerations > > This entire memo pertains to the provision of public keying material > for use by key management protocols such as ISAKMP/IKE (RFC2407) [7]. > A question regarding the charter ipsec-specific scope: obviously, the IPSECKEY RR public key is for use with a key management protocol (KMP). But I came to wonder about what means 'ipsec-specific' ? Does this means that the KMP belongs to the ipsec protocols suite (this is how I understand it) or does this means that it is for use for a KMP that is able to set up ESP or AH SAs ? By the way, do we mean that the DOI of the key management protocol (KMP) in phase 2 (if applicable) is IPsec ? > > The IPSECKEY resource record contains information that MUST be > communicated to the end client in an integral fashion - i.e. free > from modification. The form of this channel is up to the consumer of > the data - there must be a trust relationship between the end > consumer of this resource record and the server. This relationship > may be end-to-end DNSSEC validation, a TSIG or SIG(0) channel to > another secure source, a secure local channel on the host, or some > combination of the above. > May be the first thing we should focus on now is to reach for a consensus about if end to end integrity is REQUIRED or RECOMMANDED. > > The keying material provided by the IPSECKEY resource record is not > sensitive to passive attacks - it may be freely disclosed to any > party without any impact on the security properties of the resulting > IPsec session: IPsec and IKE provide for defense against both active > and passive attacks. > Do we really need to speak about IPsec and IKE here ? The RR datas are expected to be public and as such are implicitly unsensitive to passive attacks. > > An active attack against this record, were it not provided with end- > to-end integrity, would provide an opportunity for an attacker to > replace the keying material. What about the gateway ? By providing his own gateway (with a suitable key or with an ipseckey rr for the gateway), wouldn't the attacker manage to reroute destination packets to him thanks to the tunnel ? Would this help to set up a MiM ? > > If the attacker was not able to subsequently mount a second man-in- > the-middle attack on the IKE negotiation, then this would result in a > denial of service, as the authentication used by IKE would fail. > > If the attacker was also in a position to perform a man-in-the-middle > attack on IKE and IPsec negotiations as well, then it would be a > position to compromise the resulting IPsec channel. Note that an > attack must be able to perform active DNS attacks on both sides of > the IKE negotiation in order for this to succeed. I see your point, but is it expected that IKE initiator and responder will both use IPSECKEY RR ? I think asymetric scenarios may happen (initiator using IPSECKEY and responder an other scheme). > > The semantics of when to use this record is outside of the scope of > this document. Any user of this resource record MUST carefully > document their trust model, and why the trust model of DNSSEC is > appropriate, if that is the secure channel used. > -- Jean-Jacques Puig - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Tue May 20 16:41:50 2003 Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [192.139.46.73]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29434 for ; Tue, 20 May 2003 16:41:43 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4KKetp16256 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Tue, 20 May 2003 16:40:57 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h4KKfx317605 for ipseckey-outgoing; Tue, 20 May 2003 16:41:59 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4KKfvi17597 for ; Tue, 20 May 2003 16:41:57 -0400 (EDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4KKeip16253 for ; Tue, 20 May 2003 16:40:44 -0400 (EDT) Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id D175D18C1 for ; Tue, 20 May 2003 16:39:37 -0400 (EDT) Date: Tue, 20 May 2003 16:39:37 -0400 From: Rob Austein To: ipseckey@sandelman.ca Subject: Re: [IPSECKEY] Security Considerations In-Reply-To: <200305201932.h4KJWeTu007335@sandelman.ottawa.on.ca> References: <200305201932.h4KJWeTu007335@sandelman.ottawa.on.ca> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030520203937.D175D18C1@thrintun.hactrn.net> Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca I'll defer to all the Real Security Geeks in the (virtual) room on whether the analysis is technically correct, but the revised Security Considerations look pretty good to me. Nits: At Tue, 20 May 2003 15:32:39 -0400, Michael Richardson wrote: > > If the attacker was not able to subsequently mount a second man-in- s/was/were/ > If the attacker was also in a position to perform a man-in-the-middle s/was/were/ > attack on IKE and IPsec negotiations as well, then it would be a s/it would be/the attacker would be in/ > position to compromise the resulting IPsec channel. Note that an > attack must be able to perform active DNS attacks on both sides of s/an attack/an attacker/ > The semantics of when to use this record is outside of the scope of > this document. Any user of this resource record MUST carefully > document their trust model, and why the trust model of DNSSEC is > appropriate, if that is the secure channel used. No objection to what I think is the intent of the text here, but "semantics" just doesn't sound right in this context. I'm page faulting on what the right word would be, it's somewhere in the neighborhood of "implementation and operational policy decision", but I haven't thought of the right word yet. Leave it as it stands if nobody can think of a better way of phrasing this, but I suspect that the current phrasing is going to confuse people. Thanks! - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Tue May 20 16:44:42 2003 Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [192.139.46.73]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29598 for ; Tue, 20 May 2003 16:44:41 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4KKiHp16269 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Tue, 20 May 2003 16:44:19 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h4KKjSa17799 for ipseckey-outgoing; Tue, 20 May 2003 16:45:28 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4KKjRi17783 for ; Tue, 20 May 2003 16:45:27 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4KKiEp16266 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Tue, 20 May 2003 16:44:15 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h4KKiDiZ008909 for ; Tue, 20 May 2003 16:44:13 -0400 Message-Id: <200305202044.h4KKiDiZ008909@sandelman.ottawa.on.ca> To: ipseckey@sandelman.ca Subject: Re: [IPSECKEY] Re: comments and nits (not including SC) In-reply-to: Your message of "Tue, 20 May 2003 15:07:04 EDT." <20030520190704.99BE518C1@thrintun.hactrn.net> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 20 May 2003 16:44:12 -0400 From: Michael Richardson Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Rob" == Rob Austein writes: Rob> There's no such thing as a "domain-name". >> >> RFC1035:, section 3.3: >> >> is a domain name represented as a series of labels, and >> terminated by a label with zero length. is a single >> length octet followed by that number of characters. >> is treated as binary information, and can be up to 256 characters in >> length (including the length octet). >> >> Perhaps I should say ""? Rob> As I said, a nit, but anyway... The RFC 1035 context is a (partial) Rob> BNF grammer, which replaces interword whitespace in multi-word token Rob> names with hyphenation. Rob> In ordinary running text it's still "domain name" (or "DNS name"). Done. Rob> See ID-nits comments (below), though, the address itself will probably Rob> have to change. >> >> Switched to 2002: example. >> Bill Manning says that there is an example allocation in IPv6. Rob> Cool, I must've missed it. Reference? I don't have one. he says one was allocated, but hasn't provided a reference. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPsqTm4qHRg3pndX9AQEhsQP/fkMdanJKc2mdJ6weMiKbkVQ4V4hncHi/ Ozg1HfObLgn1M+GF12f2UgsQmXFX76VE2oDgIbp8cTg4h4V7yzkiqFYFnFnLL2/I P6WMRg34lGXNPAgnxWXuraSHoKjM8TJQ9HbKmHAFnnrX+zuWMKnKjE4xnQ3oNukf ZodmbUdkRvM= =GCCh -----END PGP SIGNATURE----- - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Tue May 20 16:47:43 2003 Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [192.139.46.73]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29793 for ; Tue, 20 May 2003 16:47:40 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4KKlJp16302 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Tue, 20 May 2003 16:47:21 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h4KKmUF17982 for ipseckey-outgoing; Tue, 20 May 2003 16:48:30 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4KKmTi17977 for ; Tue, 20 May 2003 16:48:29 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4KKlFp16299 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Tue, 20 May 2003 16:47:17 -0400 (EDT) From: Michael Richardson Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h4KKlFQ3008993 for ; Tue, 20 May 2003 16:47:15 -0400 Date: Tue, 20 May 2003 16:47:15 -0400 Message-Id: <200305202047.h4KKlFQ3008993@sandelman.ottawa.on.ca> Prev-Resent: Tue, 20 May 2003 16:47:14 -0400 Prev-Resent: "ipseckey@sandelman.ca " To: undisclosed-recipients:; Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca From owner-ipseckey@lox.sandelman.ottawa.on.ca Tue May 20 15: 37:35 2003 Received: from expansionpack.xtdnet.nl (mail.xtdnet.nl [193.110.157.5]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4KJb9i14424; Tue, 20 May 2003 15:37:34 -0400 (EDT) Received: from mail.xtdnet.nl (mail.xtdnet.nl [193.110.157.5]) by expansionpack.xtdnet.nl (8.12.8/8.11.6) with ESMTP id h4KJYvDJ010178 (using TLSv1/SSLv3 with cipher EDH-DSS-DES-CBC3-SHA (168 bits) verified NO); Tue, 20 May 2003 21:34:57 +0200 Date: Tue, 20 May 2003 21:34:57 +0200 (MET DST) From: Paul Wouters To: hugh@xisp.net cc: ipseckey@sandelman.ca, gnu@toad.com, mcr@sandelman.ca, weiler@watson.org, sra+ipseckey@hactrn.net, design@lists.freeswan.org Subject: Re: [Design] Security Considerations for IPSECKEY In-Reply-To: <200305191954.h4JJsJHX008066@road.toad.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MailScanner: Found to be clean Resent-To: ipseckey@sandelman.ca Resent-Date: Tue, 20 May 2003 16:47:14 -0400 Resent-From: Michael Richardson On Mon, 19 May 2003, Hugh Daniel wrote: > If the users (or system/network admins) "threat model" policy > causes the IPSECKEY RR (and other RR's) to be integrity/authentication > checked then the check it's self has to be securely delivered to the > end user/program. > > In the current Internet it is quite possible that network designers > will try to create networks where DNSsec caching and/or validation > will happen on hosts that are across un-secured local LAN's from the > end user/program. Such networks are fundamentally only as secure as > the first issue case (raw DNS that protects only against passive > attacks). I would add to this that insecurely using a dnssec resolver does has one problem, it gives a false sense of security. Is the application relaying on the insecure "ad" bit? Is it relying on not getting a servfail? I seriously hope that running your own (caching) recursive resolver becomes best current practice or even a mandatory part of dnssec (MUST HAVE) Paul - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Tue May 20 17:09:39 2003 Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [192.139.46.73]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00490 for ; Tue, 20 May 2003 17:09:36 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4KL9Ep16372 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Tue, 20 May 2003 17:09:16 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h4KLAPY19178 for ipseckey-outgoing; Tue, 20 May 2003 17:10:25 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4KLAMi19169 for ; Tue, 20 May 2003 17:10:22 -0400 (EDT) Received: from karoshi.com (vacation.karoshi.com [198.32.6.68]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4KL99p16368 for ; Tue, 20 May 2003 17:09:09 -0400 (EDT) Received: (from bmanning@localhost) by karoshi.com (8.11.6/8.11.6 - yeah right) id h4KL8tj24065; Tue, 20 May 2003 14:08:55 -0700 From: bmanning@karoshi.com Message-Id: <200305202108.h4KL8tj24065@karoshi.com> Subject: Re: [IPSECKEY] Re: comments and nits (not including SC) To: mcr@sandelman.ottawa.on.ca (Michael Richardson) Date: Tue, 20 May 2003 14:08:55 -0700 (PDT) Cc: ipseckey@sandelman.ca In-Reply-To: <200305202044.h4KKiDiZ008909@sandelman.ottawa.on.ca> from "Michael Richardson" at May 20, 2003 04:44:12 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca Content-Transfer-Encoding: 7bit > >> Switched to 2002: example. > >> Bill Manning says that there is an example allocation in IPv6. > > Rob> Cool, I must've missed it. Reference? > > I don't have one. he says one was allocated, but hasn't provided a > reference. APNIC made the following delegation in late 2002: the IPv6 prefix 2001:0DB8::/32 has been set aside for use in documentation. ref: http://www.apnic.net/info/faq/ipv6-documentation-prefix-faq.html --bill - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Tue May 20 17:46:24 2003 Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [192.139.46.73]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01510 for ; Tue, 20 May 2003 17:46:23 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4KLjop16510 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Tue, 20 May 2003 17:45:52 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h4KLkmJ20813 for ipseckey-outgoing; Tue, 20 May 2003 17:46:48 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4KLkli20808 for ; Tue, 20 May 2003 17:46:47 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4KLjXp16502 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Tue, 20 May 2003 17:45:35 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h4KLjX45010417 for ; Tue, 20 May 2003 17:45:33 -0400 Message-Id: <200305202145.h4KLjX45010417@sandelman.ottawa.on.ca> To: ipseckey@sandelman.ca Subject: Re: [IPSECKEY] Security Considerations In-reply-to: Your message of "Tue, 20 May 2003 22:40:53 +0200." <20030520204053.GA3345@ivan.int-evry.fr> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 20 May 2003 17:45:32 -0400 From: Michael Richardson Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca >> The IPSECKEY resource record contains information that MUST be I meant to write "SHOULD" here. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Tue May 20 17:51:46 2003 Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [192.139.46.73]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01576 for ; Tue, 20 May 2003 17:51:45 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4KLpRp16539 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Tue, 20 May 2003 17:51:29 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h4KLqcr21079 for ipseckey-outgoing; Tue, 20 May 2003 17:52:38 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4KLqbi21074 for ; Tue, 20 May 2003 17:52:37 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4KLpNp16536 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Tue, 20 May 2003 17:51:25 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h4KLpMDn010537 for ; Tue, 20 May 2003 17:51:23 -0400 Message-Id: <200305202151.h4KLpMDn010537@sandelman.ottawa.on.ca> To: ipseckey@sandelman.ca Subject: Re: [IPSECKEY] Security Considerations In-reply-to: Your message of "Tue, 20 May 2003 22:40:53 +0200." <20030520204053.GA3345@ivan.int-evry.fr> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 20 May 2003 17:51:22 -0400 From: Michael Richardson Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Jean-Jacques" == Jean-Jacques Puig writes: Jean-Jacques> A question regarding the charter ipsec-specific scope: obviously, the Jean-Jacques> IPSECKEY RR public key is for use with a key management protocol (KMP). Yes. Jean-Jacques> But I came to wonder about what means 'ipsec-specific' ? Does this means Jean-Jacques> that the KMP belongs to the ipsec protocols suite (this is how I Jean-Jacques> understand it) or does this means that it is for use for a Yes. It would be IKE, IKEv2, and perhaps Photoris (if you can find any). KINK/IKE would not use public keys directly (the KDC might), so this doesn't matter. >> The keying material provided by the IPSECKEY resource record is not >> sensitive to passive attacks - it may be freely disclosed to any >> party without any impact on the security properties of the resulting >> IPsec session: IPsec and IKE provide for defense against both active >> and passive attacks. >> Jean-Jacques> Do we really need to speak about IPsec and IKE here ? The RR datas are Jean-Jacques> expected to be public and as such are implicitly unsensitive to passive Jean-Jacques> attacks. SC is mostly about stating what we think we already know :-) >> An active attack against this record, were it not provided with end- >> to-end integrity, would provide an opportunity for an attacker to >> replace the keying material. Jean-Jacques> What about the gateway ? By providing his own gateway (with a suitable Jean-Jacques> key or with an ipseckey rr for the gateway), wouldn't the attacker Jean-Jacques> manage to reroute destination packets to him thanks to the tunnel ? Jean-Jacques> Would this help to set up a MiM ? Yes, they could do that. Does this need to be stated. >> If the attacker was not able to subsequently mount a second man-in- >> the-middle attack on the IKE negotiation, then this would result in a >> denial of service, as the authentication used by IKE would fail. >> >> If the attacker was also in a position to perform a man-in-the-middle >> attack on IKE and IPsec negotiations as well, then it would be a >> position to compromise the resulting IPsec channel. Note that an >> attack must be able to perform active DNS attacks on both sides of >> the IKE negotiation in order for this to succeed. Jean-Jacques> I see your point, but is it expected that IKE initiator and responder Jean-Jacques> will both use IPSECKEY RR ? I think asymetric scenarios may happen Jean-Jacques> (initiator using IPSECKEY and responder an other scheme). That's true. I have certainly done this in the past! Both ends *do* need to have their public key's spoofed to get in the middle. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPsqjV4qHRg3pndX9AQHxfAQAqcc63afc+QFV6E773uYNMO3nwzL9kyFk hEVrfI6LDsrDMgkvltO4JF2E7jT5M1/t7wFFZkt5KlrGETvmHZqp4oMCVxIqe++m W8hcBnQPKp6kIlsTvrxzLLJty9DHhL7/fyfnC5EKmE9slocFaw594tDpHMSJtcQG g4sq/buxsGE= =ZGWF -----END PGP SIGNATURE----- - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Tue May 20 18:12:49 2003 Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [192.139.46.73]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03106 for ; Tue, 20 May 2003 18:12:48 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4KMCRp16599 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Tue, 20 May 2003 18:12:29 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h4KMDcc22156 for ipseckey-outgoing; Tue, 20 May 2003 18:13:38 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4KMDai22151 for ; Tue, 20 May 2003 18:13:36 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4KMCMp16596 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Tue, 20 May 2003 18:12:24 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h4KMCMjL010988 for ; Tue, 20 May 2003 18:12:22 -0400 Message-Id: <200305202212.h4KMCMjL010988@sandelman.ottawa.on.ca> To: ipseckey@sandelman.ca Subject: Re: [IPSECKEY] Re: comments and nits (not including SC) In-reply-to: Your message of "Tue, 20 May 2003 14:08:55 PDT." <200305202108.h4KL8tj24065@karoshi.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 20 May 2003 18:12:21 -0400 From: Michael Richardson Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca -----BEGIN PGP SIGNED MESSAGE----- >>>>> "bmanning" == bmanning writes: >> I don't have one. he says one was allocated, but hasn't provided a >> reference. bmanning> APNIC made the following delegation in late 2002: bmanning> the IPv6 prefix 2001:0DB8::/32 has been set aside for use in documentation. bmanning> ref: bmanning> http://www.apnic.net/info/faq/ipv6-documentation-prefix-faq.html Got it, thank you. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPsqoRIqHRg3pndX9AQHH3gP/Q4Cln1v8KroIfvJmDtNwNSpFFhCBFSx/ ho8Fy6GjoX9MynA8owxpwr4zHKhENJQOI7IFP4/QM5F9oOkdBgGf/tcsMEhxGO0R kAcML3Wup9ojv/x8b+8t/vI9McjCBZqi+w30zcuTXW1MFoPKZUo+OtHqeLEBDUR2 OYePBhj/FCo= =9fbo -----END PGP SIGNATURE----- - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Tue May 20 18:42:24 2003 Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [192.139.46.73]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04240 for ; Tue, 20 May 2003 18:42:20 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4KMg0p16698 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Tue, 20 May 2003 18:42:02 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h4KMhAH23516 for ipseckey-outgoing; Tue, 20 May 2003 18:43:10 -0400 (EDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4KMh8i23511 for ; Tue, 20 May 2003 18:43:08 -0400 (EDT) Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 4229618C5 for ; Tue, 20 May 2003 18:40:48 -0400 (EDT) Date: Tue, 20 May 2003 18:40:48 -0400 From: Rob Austein To: ipseckey@sandelman.ca Subject: Re: [IPSECKEY] Security Considerations User-Agent: Wanderlust/2.10.0 (Venus) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030520224048.4229618C5@thrintun.hactrn.net> Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca At Tue, 20 May 2003 17:51:22 -0400, Michael Richardson wrote: > >>>>> "Jean-Jacques" == Jean-Jacques Puig writes: > > >> An active attack against this record, were it not provided with end- > >> to-end integrity, would provide an opportunity for an attacker to > >> replace the keying material. > > Jean-Jacques> What about the gateway ? By providing his own gateway (with a suitable > Jean-Jacques> key or with an ipseckey rr for the gateway), wouldn't the attacker > Jean-Jacques> manage to reroute destination packets to him thanks to the tunnel ? > Jean-Jacques> Would this help to set up a MiM ? > > Yes, they could do that. > Does this need to be stated. Yes. - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Tue May 20 19:33:23 2003 Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [192.139.46.73]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05789 for ; Tue, 20 May 2003 19:33:22 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4KNWkp16862 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Tue, 20 May 2003 19:32:48 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h4KNXrg25938 for ipseckey-outgoing; Tue, 20 May 2003 19:33:53 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4KNXpi25933 for ; Tue, 20 May 2003 19:33:51 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4KNWcp16859 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Tue, 20 May 2003 19:32:39 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h4KNWbgJ012752 for ; Tue, 20 May 2003 19:32:38 -0400 Message-Id: <200305202332.h4KNWbgJ012752@sandelman.ottawa.on.ca> To: ipseckey@sandelman.ca Subject: Re: [IPSECKEY] Security Considerations (pass 2) In-reply-to: Your message of "Tue, 20 May 2003 18:40:48 EDT." <20030520224048.4229618C5@thrintun.hactrn.net> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 20 May 2003 19:32:37 -0400 From: Michael Richardson Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca -----BEGIN PGP SIGNED MESSAGE----- I've restructured it a bit. Comments welcome. 4. Security Considerations This entire memo pertains to the provision of public keying material for use by key management protocols such as ISAKMP/IKE (RFC2407) [7]. The IPSECKEY resource record contains information that SHOULD be communicated to the end client in an integral fashion - i.e. free from modification. The form of this channel is up to the consumer of the data - there must be a trust relationship between the end consumer of this resource record and the server. This relationship may be end-to-end DNSSEC validation, a TSIG or SIG(0) channel to another secure source, a secure local channel on the host, or some combination of the above. The keying material provided by the IPSECKEY resource record is not sensitive to passive attacks. The keying material may be freely disclosed to any party without any impact on the security properties of the resulting IPsec session: IPsec and IKE provide for defense against both active and passive attacks. Any use of this resource record MUST carefully document their trust model, and why the trust model of DNSSEC is appropriate, if that is the secure channel used. 4.1 Active attacks against unsecured IPSECKEY resource records This section deals with active attacks against the DNS. These attacks require that DNS requests and responses be intercepted and changed. DNSSEC is designed to defend against attacks of this kind. The first kind of active attack is when the attacker replaces the keying material with either a key under its control, or with garbage. If the attacker were not able to subsequently mount a second man-in- the-middle attack on the IKE negotiation after replacing the public key, then this would result in a denial of service, as the authenticator used by IKE would fail. If the attacker were able to mount both active attacks against DNS, and in a position to perform a man-in-the-middle attack on IKE and IPsec negotiations, then the attacker would be in a position to compromise the resulting IPsec channel. Note that an attacker must be able to perform active DNS attacks on both sides of the IKE negotiation in order for this to succeed. The second kind of active attack is when the attacker replaces the the gateway address to point to a node under the attacker's control. The attacker can either replace the public key as well, or remove it - providing an IPSECKEY record of its own to match the gateway address. This later form creates a simple man-in-the-middle. The attacker could create a second tunnel to the real destination. Note that as before, this requires that the attacker also mount an active attack against the responder. Note that the man-in-the-middle can not only forward cleartext packets to the original destination. While the destination may be willing to speak in the clear, replying to the original sender, the sender would have already created a policy expecting ciphertext. Thus, the need for attacker to intercept traffic from both sides. A protocol which permits the gateway field to delegate to a different host MAY want to restrict this feature when end-to-end integrity is not available. Richardson Expires September 30, 2003 [Page 10] Internet-Draft ipsecrr April 2003 5. IANA Considerations IANA is asked to assign a resource record type number from the normal resource record number space. The algorithm field does not require any IANA action, as it is inherited from DNS KEY algorithm values. Richardson Expires September 30, 2003 [Page 11] Internet-Draft ipsecrr April 2003 6. Acknowledgments My thanks to Paul Hoffman, Sam Weiler, Jean-Jacques Puig, and Olafur Gurmundsson who reviewed this document carefully. Additional thanks to Olafur Gurmundsson for a reference implementation. Richardson Expires September 30, 2003 [Page 12] Internet-Draft ipsecrr April 2003 Normative references [1] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [2] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [3] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [4] Eastlake, D. and C. Kaufman, "Domain Name System Security Extensions", RFC 2065, January 1997. Richardson Expires September 30, 2003 [Page 13] Internet-Draft ipsecrr April 2003 Non-normative references [5] Thomson, S. and C. Huitema, "DNS Extensions to support IP version 6", RFC 1886, December 1995. [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [7] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998. [8] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [9] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System (DNS)", RFC 2536, March 1999. [10] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)", RFC 3110, May 2001. [11] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource Record (RR)", RFC 3445, December 2002. Author's Address Michael C. Richardson Sandelman Software Works 470 Dawson Avenue Ottawa, ON K1Z 5V7 CA EMail: mcr@sandelman.ottawa.on.ca URI: http://www.sandelman.ottawa.on.ca/ Richardson Expires September 30, 2003 [Page 14] Internet-Draft ipsecrr April 2003 Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Richardson Expires September 30, 2003 [Page 15] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPsq7E4qHRg3pndX9AQF3rQQAoZvG5uu8sYunGmcok5tVGwd9lStEsOkM rHWI1g5hlWyGz3YVshbdPWeAd7WIC2YyQaWT0n1spx8bImBUl5AJNRCS4mUPXIvs j47bRM9i7sYl5R0SzZ6Bs204iLP8mgn0RPVSAKOYqt4NAnaJGEAGUC9sjM/C0nNq LDz5d53/TJU= =byPv -----END PGP SIGNATURE----- - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Tue May 20 22:24:36 2003 Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [192.139.46.73]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08893 for ; Tue, 20 May 2003 22:24:33 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4L2NMp17432 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Tue, 20 May 2003 22:23:24 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h4L2NxC04633 for ipseckey-outgoing; Tue, 20 May 2003 22:23:59 -0400 (EDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4L2NvT04616 for ; Tue, 20 May 2003 22:23:57 -0400 (EDT) Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 3915618C5 for ; Tue, 20 May 2003 22:21:37 -0400 (EDT) Date: Tue, 20 May 2003 22:21:37 -0400 From: Rob Austein To: ipseckey@sandelman.ca Subject: Re: [IPSECKEY] Security Considerations (pass 2) In-Reply-To: <200305202332.h4KNWbgJ012752@sandelman.ottawa.on.ca> References: <20030520224048.4229618C5@thrintun.hactrn.net> <200305202332.h4KNWbgJ012752@sandelman.ottawa.on.ca> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030521022137.3915618C5@thrintun.hactrn.net> Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca At Tue, 20 May 2003 19:32:37 -0400, Michael Richardson wrote: > > I've restructured it a bit. Comments welcome. Content looks good. Nits (many of which are really just a single tense agreement problem that appears in many places throughout the text), plus one point that's a bit unclear, at the very end. > 4. Security Considerations > > This entire memo pertains to the provision of public keying material > for use by key management protocols such as ISAKMP/IKE (RFC2407) [7]. > > The IPSECKEY resource record contains information that SHOULD be > communicated to the end client in an integral fashion - i.e. free > from modification. The form of this channel is up to the consumer of > the data - there must be a trust relationship between the end > consumer of this resource record and the server. This relationship > may be end-to-end DNSSEC validation, a TSIG or SIG(0) channel to > another secure source, a secure local channel on the host, or some > combination of the above. > > The keying material provided by the IPSECKEY resource record is not > sensitive to passive attacks. The keying material may be freely > disclosed to any party without any impact on the security properties > of the resulting IPsec session: IPsec and IKE provide for defense > against both active and passive attacks. > > Any use of this resource record MUST carefully document their trust > model, and why the trust model of DNSSEC is appropriate, if that is > the secure channel used. > > 4.1 Active attacks against unsecured IPSECKEY resource records > > This section deals with active attacks against the DNS. These > attacks require that DNS requests and responses be intercepted and > changed. DNSSEC is designed to defend against attacks of this kind. > > The first kind of active attack is when the attacker replaces the > keying material with either a key under its control, or with garbage. > > If the attacker were not able to subsequently mount a second man-in- s/were/is/ s/subsequently mount a second/mount a subsequent/ > the-middle attack on the IKE negotiation after replacing the public > key, then this would result in a denial of service, as the > authenticator used by IKE would fail. s/would/will/g > If the attacker were able to mount both active attacks against DNS, > and in a position to perform a man-in-the-middle attack on IKE and s/were able to mount both/is able both to mount/ s/DNS, and in/DNS and is also in/ > IPsec negotiations, then the attacker would be in a position to s/would/will/ > compromise the resulting IPsec channel. Note that an attacker must > be able to perform active DNS attacks on both sides of the IKE > negotiation in order for this to succeed. > > The second kind of active attack is when the attacker replaces the s/is when/is one in which/ > the gateway address to point to a node under the attacker's control. > The attacker can either replace the public key as well, or remove it > - providing an IPSECKEY record of its own to match the gateway s/can/can then/ s/as well, or remove it -/or remove it, thus/ > address. > > This later form creates a simple man-in-the-middle. The attacker s/man-in-the-middle. The/man-in-the-middle attack, since the/ > could create a second tunnel to the real destination. Note that as s/could/can then/ s/that/that,/ > before, this requires that the attacker also mount an active attack > against the responder. > > Note that the man-in-the-middle can not only forward cleartext s/only/just/ > packets to the original destination. While the destination may be > willing to speak in the clear, replying to the original sender, the > sender would have already created a policy expecting ciphertext. s/would/will/ > Thus, the need for attacker to intercept traffic from both sides. s/Thus, the need for attacker/Thus, the attacker will need/ > A protocol which permits the gateway field to delegate to a different > host MAY want to restrict this feature when end-to-end integrity is > not available. Er, from what is the gateway field different? The RR owner name? How should this test be applied when: a) the RR owner name is an encoded address (reverse tree) and the gateway field is a DNS name, or b) the RR owner name is a "normal" DNS name and the gateway field is one of the address forms? Bit of a slippery slope. - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Wed May 21 11:47:27 2003 Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [192.139.46.73]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25676 for ; Wed, 21 May 2003 11:47:26 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4LFk0p20749 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Wed, 21 May 2003 11:46:02 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h4LFkqE16306 for ipseckey-outgoing; Wed, 21 May 2003 11:46:52 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4LFkpx16301 for ; Wed, 21 May 2003 11:46:51 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4LFjbp20734 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Wed, 21 May 2003 11:45:38 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h4LFjbBB000478 for ; Wed, 21 May 2003 11:45:37 -0400 Message-Id: <200305211545.h4LFjbBB000478@sandelman.ottawa.on.ca> To: ipseckey@sandelman.ca Subject: Re: [IPSECKEY] Security Considerations (pass 2) In-reply-to: Your message of "Tue, 20 May 2003 22:21:37 EDT." <20030521022137.3915618C5@thrintun.hactrn.net> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 21 May 2003 11:45:36 -0400 From: Michael Richardson Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca -----BEGIN PGP SIGNED MESSAGE----- Rob> Content looks good. Rob> Nits (many of which are really just a single tense agreement problem Rob> that appears in many places throughout the text), plus one point Thanks for all of this. I certainly can fix it myself, but never on the same day as writing the original. >> A protocol which permits the gateway field to delegate to a different >> host MAY want to restrict this feature when end-to-end integrity is >> not available. Rob> Er, from what is the gateway field different? The RR owner name? How Rob> should this test be applied when: Rob> a) the RR owner name is an encoded address (reverse tree) and the Rob> gateway field is a DNS name, or Rob> b) the RR owner name is a "normal" DNS name and the gateway field is Rob> one of the address forms? Rob> Bit of a slippery slope. Without integrity protection, one *might* want to permit only the situation where "No gateway is present", or IP an IP address is present that it is == to the thing that one looked up originally. The first example is shows a node that has delegate to self. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPsufHoqHRg3pndX9AQGDVQQAmFjdBx872p/QPXIXb6vO13TFFzWm9bQP CeoypPRnQTF6RwJ1706/eqXPskjdDQWdevHxyTDsdpzDCVLffwe40prx3Rvx7dDc 102DIu0/2ibgtRULwSTsOKZmEJxb8qzEVFKEqofDDas04/5rwRBunsVztj+8p+51 vopcb/Ii6Ds= =CRbq -----END PGP SIGNATURE----- - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Thu May 22 04:08:37 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04221 for ; Thu, 22 May 2003 04:08:36 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4M87Os00762 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Thu, 22 May 2003 04:07:27 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h4M88Ij07795 for ipseckey-outgoing; Thu, 22 May 2003 04:08:18 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4M88GW07773 for ; Thu, 22 May 2003 04:08:16 -0400 (EDT) Received: from herculanum.int-evry.fr (herculanum.int-evry.fr [157.159.11.15]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4M871s00757 for ; Thu, 22 May 2003 04:07:02 -0400 (EDT) Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id 5F68234B95; Thu, 22 May 2003 10:06:53 +0200 (CEST) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id 7231F3F45A; Thu, 22 May 2003 10:14:43 +0200 (CEST) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003052210065225516 ; Thu, 22 May 2003 10:06:52 +0200 Received: from localhost (ivan.int-evry.fr [157.159.100.48]) by sparte.int-evry.fr (Postfix) with ESMTP id ACE053F47A; Thu, 22 May 2003 10:14:42 +0200 (CEST) Received: from jjp by localhost with local id 19Il5p-0007OZ-00; Thu, 22 May 2003 10:06:29 +0200 Date: Thu, 22 May 2003 10:06:29 +0200 From: Jean-Jacques Puig To: Michael Richardson Cc: ipseckey@sandelman.ca Subject: Re: [IPSECKEY] Security Considerations Message-ID: <20030522080629.GA28139@ivan.int-evry.fr> References: <20030520204053.GA3345@ivan.int-evry.fr> <200305202151.h4KLpMDn010537@sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200305202151.h4KLpMDn010537@sandelman.ottawa.on.ca> Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca On Tue, May 20, 2003 at 05:51:22PM -0400, Michael Richardson wrote: > >> If the attacker was not able to subsequently mount a second man-in- > >> the-middle attack on the IKE negotiation, then this would result in a > >> denial of service, as the authentication used by IKE would fail. > >> > >> If the attacker was also in a position to perform a man-in-the-middle > >> attack on IKE and IPsec negotiations as well, then it would be a > >> position to compromise the resulting IPsec channel. Note that an > >> attack must be able to perform active DNS attacks on both sides of > >> the IKE negotiation in order for this to succeed. > > Jean-Jacques> I see your point, but is it expected that IKE initiator and responder > Jean-Jacques> will both use IPSECKEY RR ? I think asymetric scenarios may happen > Jean-Jacques> (initiator using IPSECKEY and responder an other scheme). > > That's true. I have certainly done this in the past! > Both ends *do* need to have their public key's spoofed to get in the middle. > Sorry, I don't know if I was clear about why I was talking about that. In the (latests) SC sentence: > Note that an attacker must >be able to perform active DNS attacks on both sides of the IKE >negotiation in order for this to succeed. I think we should only state: > Note that an attacker must >be able to perform active attacks on both sides of the IKE >negotiation in order for this to succeed. An active DNS attack against at least one side is what this security consideration deals with. The active attack on the other side depends on the other channel elected to get public key. This may be also DNS (in which case, the other active attack is also against DNS), or PKI, relation to a crypto-based address, keys shared on a mounted filesystem, pieces of paper with hand-written keys, etc. Note also that in the present case, the attacker is in position to modify phase 1 payloads to force choice of identities, kind of authentication, etc. All of this may affect the choice of channels elected to get the public keys. Please, if I'm wrong, may someone explain why active DNS attacks MUST be performed against BOTH sides in this case. -- Jean-Jacques Puig - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Thu May 22 04:34:40 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04558 for ; Thu, 22 May 2003 04:34:40 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4M8XSs00823 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Thu, 22 May 2003 04:33:30 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h4M8YeQ14219 for ipseckey-outgoing; Thu, 22 May 2003 04:34:40 -0400 (EDT) Received: from herculanum.int-evry.fr (herculanum.int-evry.fr [157.159.11.15]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4M8YbW14200 for ; Thu, 22 May 2003 04:34:37 -0400 (EDT) Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id 84A2634C2E; Thu, 22 May 2003 10:33:18 +0200 (CEST) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id 056D13F455; Thu, 22 May 2003 10:41:09 +0200 (CEST) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003052210331801163 ; Thu, 22 May 2003 10:33:18 +0200 Received: from localhost (ivan.int-evry.fr [157.159.100.48]) by sparte.int-evry.fr (Postfix) with ESMTP id B43FB3F455; Thu, 22 May 2003 10:41:08 +0200 (CEST) Received: from jjp by localhost with local id 19IlVP-0002XN-00; Thu, 22 May 2003 10:32:55 +0200 Date: Thu, 22 May 2003 10:32:55 +0200 From: Jean-Jacques Puig To: Michael Richardson Cc: ipseckey@sandelman.ca Subject: Re: [IPSECKEY] Security Considerations (pass 2) Message-ID: <20030522083255.GB28139@ivan.int-evry.fr> References: <20030520224048.4229618C5@thrintun.hactrn.net> <200305202332.h4KNWbgJ012752@sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200305202332.h4KNWbgJ012752@sandelman.ottawa.on.ca> Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca On Tue, May 20, 2003 at 07:32:37PM -0400, Michael Richardson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > > I've restructured it a bit. Comments welcome. > > 4. Security Considerations > > This entire memo pertains to the provision of public keying material > for use by key management protocols such as ISAKMP/IKE (RFC2407) [7]. > > The IPSECKEY resource record contains information that SHOULD be > communicated to the end client in an integral fashion - i.e. free > from modification. The form of this channel is up to the consumer of > the data - there must be a trust relationship between the end > consumer of this resource record and the server. This relationship > may be end-to-end DNSSEC validation, a TSIG or SIG(0) channel to > another secure source, a secure local channel on the host, or some > combination of the above. > > The keying material provided by the IPSECKEY resource record is not > sensitive to passive attacks. The keying material may be freely > disclosed to any party without any impact on the security properties > of the resulting IPsec session: IPsec and IKE provide for defense > against both active and passive attacks. > > Any use of this resource record MUST carefully document their trust > model, and why the trust model of DNSSEC is appropriate, if that is > the secure channel used. > > 4.1 Active attacks against unsecured IPSECKEY resource records > > This section deals with active attacks against the DNS. These > attacks require that DNS requests and responses be intercepted and > changed. DNSSEC is designed to defend against attacks of this kind. > > The first kind of active attack is when the attacker replaces the > keying material with either a key under its control, or with garbage. > > If the attacker were not able to subsequently mount a second man-in- > the-middle attack on the IKE negotiation after replacing the public > key, then this would result in a denial of service, as the > authenticator used by IKE would fail. > > If the attacker were able to mount both active attacks against DNS, > and in a position to perform a man-in-the-middle attack on IKE and > IPsec negotiations, then the attacker would be in a position to > compromise the resulting IPsec channel. Note that an attacker must > be able to perform active DNS attacks on both sides of the IKE > negotiation in order for this to succeed. > > The second kind of active attack is when the attacker replaces the > the gateway address to point to a node under the attacker's control. > The attacker can either replace the public key as well, or remove it > - providing an IPSECKEY record of its own to match the gateway > address. > > This later form creates a simple man-in-the-middle. The attacker > could create a second tunnel to the real destination. Note that as > before, this requires that the attacker also mount an active attack > against the responder. > > Note that the man-in-the-middle can not only forward cleartext (I think both are corrects, but the second may be more 'academic':) s/can not/cannot/ > packets to the original destination. While the destination may be > willing to speak in the clear, replying to the original sender, the > sender would have already created a policy expecting ciphertext. > Thus, the need for attacker to intercept traffic from both sides. Though it is not usefull to mention it in the draft, I think the attacker may achieve easily this interception: 1) Attacker provides a wrong IPSECKEY RR with it's own gateway through DNS cache poisonning. 2) Initiator establishes tunnel with attacker's gateway. 3) Initiator sends packets to Destination through tunnel. 4) Attacker masquerades source address of packets coming through the tunnel, and forwards them to Destination. 5) Destination answers to the masqueraded address (the attacker) 6) Attacker masquerades destination address of packets coming from Destination, and forwards them through the tunnel, etc. Attackers main difficulty is then to deal with transport checksums and application datas containing endpoint addresses or names. > > A protocol which permits the gateway field to delegate to a different > host MAY want to restrict this feature when end-to-end integrity is > not available. > -- Jean-Jacques Puig - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Thu May 22 13:11:38 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21635 for ; Thu, 22 May 2003 13:11:37 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4MHAts02653 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Thu, 22 May 2003 13:10:57 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h4MHBff07135 for ipseckey-outgoing; Thu, 22 May 2003 13:11:41 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4MHBeU07130 for ; Thu, 22 May 2003 13:11:40 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4MHAPs02646 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Thu, 22 May 2003 13:10:26 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h4MHAOTF032410 for ; Thu, 22 May 2003 13:10:25 -0400 Message-Id: <200305221710.h4MHAOTF032410@sandelman.ottawa.on.ca> To: ipseckey@sandelman.ca Subject: Re: [IPSECKEY] Security Considerations In-reply-to: Your message of "Thu, 22 May 2003 10:06:29 +0200." <20030522080629.GA28139@ivan.int-evry.fr> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Thu, 22 May 2003 13:10:24 -0400 From: Michael Richardson Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Jean-Jacques" == Jean-Jacques Puig writes: Jean-Jacques> On Tue, May 20, 2003 at 05:51:22PM -0400, Michael Richardson wrote: >> >> If the attacker was not able to subsequently mount a second man-in- >> >> the-middle attack on the IKE negotiation, then this would result in a >> >> denial of service, as the authentication used by IKE would fail. >> >> >> >> If the attacker was also in a position to perform a man-in-the-middle >> >> attack on IKE and IPsec negotiations as well, then it would be a >> >> position to compromise the resulting IPsec channel. Note that an >> >> attack must be able to perform active DNS attacks on both sides of >> >> the IKE negotiation in order for this to succeed. >> Jean-Jacques> I see your point, but is it expected that IKE initiator and responder Jean-Jacques> will both use IPSECKEY RR ? I think asymetric scenarios may happen Jean-Jacques> (initiator using IPSECKEY and responder an other scheme). >> >> That's true. I have certainly done this in the past! >> Both ends *do* need to have their public key's spoofed to get in the middle. >> Jean-Jacques> Sorry, I don't know if I was clear about why I was talking about that. Jean-Jacques> In the (latests) SC sentence: >> Note that an attacker must >> be able to perform active DNS attacks on both sides of the IKE >> negotiation in order for this to succeed. Jean-Jacques> I think we should only state: >> Note that an attacker must >> be able to perform active attacks on both sides of the IKE >> negotiation in order for this to succeed. Jean-Jacques> An active DNS attack against at least one side is what this Jean-Jacques> security consideration deals with. The active attack on the other side Jean-Jacques> depends on the other channel elected to get public key. This may be Okay, let me setup my classic nomenclature to explain: [Q] [R] . . AS2 [A]---------[SG-A].......+.[M]..+.......[SG-B]-------[B] | ........ ..PI.... ..wild.. .+.......+......[SG-C] AS3 Assume that we have: A.in-addr.arpa. IN IPSECKEY ( 10 1 5 SG-A SG-A's-KEY ) B.in-addr.arpa. IN IPSECKEY ( 10 1 5 SG-B SG-B's-KEY ) Now, assume that SG-A's doesn't get this record, but instead gets: B.in-addr.arpa. IN IPSECKEY ( 10 1 5 SG-B SG-M's-KEY ) that's is, just the KEY is changed. We then see: [SG-A] <===IKE========>[M]<===IKE==>[SG-B] That is, M pretends to be SG-B to SG-A, and vica-versa. Since SG-A has M's key instead of SG-B's key, SG-A is easily fooled into thinking it is speaking to SG-B. However, if as you postulate, SG-B has SG-A's key in a secure fashion, then the second IKE transaction, where M pretends to be SG-A, fails. SG-B doesn't believe M, since it has SG-A's proper key. As such, it won't negotiate, and while SG-A may send traffic to M, M will be unable to forward it to SG-B. Jean-Jacques> Note also that in the present case, the attacker is in position to Jean-Jacques> modify phase 1 payloads to force choice of identities, kind of Jean-Jacques> authentication, etc. All of this may affect the choice of channels Jean-Jacques> elected to get the public keys. Yes/no. It certainly can do that. The phase 1 info is authenticated after the privacy is established, so the authentication will fail. Jean-Jacques> Please, if I'm wrong, may someone explain why active DNS attacks MUST Jean-Jacques> be performed against BOTH sides in this case. I hope that the above explains it. >>>>> "Jean-Jacques" == Jean-Jacques Puig writes: >> packets to the original destination. While the destination may be >> willing to speak in the clear, replying to the original sender, the >> sender would have already created a policy expecting ciphertext. >> Thus, the need for attacker to intercept traffic from both sides. Jean-Jacques> Though it is not usefull to mention it in the draft, I think Jean-Jacques> the attacker may achieve easily this interception: Jean-Jacques> 1) Attacker provides a wrong IPSECKEY RR with it's own gateway through Jean-Jacques> DNS cache poisonning. Jean-Jacques> 2) Initiator establishes tunnel with attacker's gateway. Yes. Let's call initiator "A". Jean-Jacques> 3) Initiator sends packets to Destination through tunnel. Yes. Let's call destination "B", and attacker "M" Jean-Jacques> 4) Attacker masquerades source address of packets coming through the Jean-Jacques> tunnel, and forwards them to Destination. Do you mean performs NAPT or NAT? Jean-Jacques> 5) Destination answers to the masqueraded address (the attacker) Jean-Jacques> 6) Attacker masquerades destination address of packets coming from Jean-Jacques> Destination, and forwards them through the tunnel, etc. Jean-Jacques> Attackers main difficulty is then to deal with transport checksums and Jean-Jacques> application datas containing endpoint addresses or names. Trivial, I think, since NAT technology is widely available, and there are few protocols which are in widespread use that do not have NAPT support. Note that the destination (B) logs a connection from the attacker (M). It also has no security, and knows it has none. Since it was willing to speak in the clear in this case, I would expect that it already thinks life is fine with being spoofed. M could also initiate to B, at which point B knows that it has a tunnel to M, not to A. It could even be the case that B knows M is M securely (DNSSEC). The concern is naturally that "A" thinks that it is speaking securely to "B". It may reveal passwords, etc. to M. It has been spoof'ed by M. Is this a new attack? Not really to me. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPs0EfYqHRg3pndX9AQFlVAP9EuNwVbZmDmYFSZuh5/DUIhEGfDUQ+6bx fABQkhNHQHwGr2Sha+DS16wuEVl+NQ9g54lfrKm1LbOmFX8xZ8rZd6s1PT6zgnHR PdbxXZEG/Fc2vksfSxiH1uUq/1FG+TaxZsQpwvB9v7OgPN3XgbC1xKdOVzDsJ/Lw ruSTSKiR18A= =Ybtm -----END PGP SIGNATURE----- - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Thu May 22 14:51:48 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24362 for ; Thu, 22 May 2003 14:51:46 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4MIpGs03016 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Thu, 22 May 2003 14:51:18 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h4MIq2w12479 for ipseckey-outgoing; Thu, 22 May 2003 14:52:02 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4MIq1U12474 for ; Thu, 22 May 2003 14:52:01 -0400 (EDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4MIoks03013 for ; Thu, 22 May 2003 14:50:46 -0400 (EDT) Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id D24A2190E for ; Thu, 22 May 2003 14:49:39 -0400 (EDT) Date: Thu, 22 May 2003 14:49:39 -0400 From: Rob Austein To: ipseckey@sandelman.ca Subject: Re: [IPSECKEY] Security Considerations (pass 2) In-Reply-To: <200305211545.h4LFjbBB000478@sandelman.ottawa.on.ca> References: <20030521022137.3915618C5@thrintun.hactrn.net> <200305211545.h4LFjbBB000478@sandelman.ottawa.on.ca> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030522184939.D24A2190E@thrintun.hactrn.net> Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca [Sorry for the delay, took yesterday off] At Wed, 21 May 2003 11:45:36 -0400, Michael Richardson wrote: > > >> A protocol which permits the gateway field to delegate to a different > >> host MAY want to restrict this feature when end-to-end integrity is > >> not available. > > Rob> Er, from what is the gateway field different? The RR owner name? How > Rob> should this test be applied when: > > Rob> a) the RR owner name is an encoded address (reverse tree) and the > Rob> gateway field is a DNS name, or > > Rob> b) the RR owner name is a "normal" DNS name and the gateway field is > Rob> one of the address forms? > > Rob> Bit of a slippery slope. > > Without integrity protection, one *might* want to permit only the situation > where "No gateway is present", or IP an IP address is present that it is == > to the thing that one looked up originally. The first example is shows a node > that has delegate to self. So perhaps something like the following would do (keyboarded, might need wordsmithing): Note that the danger here only applies to cases where the gateway field of the IPSECKEY RR indicates a different entity than the owner name of the IPSECKEY RR. In cases where the end-to-end integrity of the IPSECKEY RR is suspect, the end client MUST[*] restrict its use of the IPSECKEY RR to cases where the RR owner name matches the content of the gateway field. [*] Open MAY/SHOULD/MUST question here here. I've written it as MUST because that's my own preference, but others may disagree. Reasoning, such as it is: the context of this whole subsection assumes an environment in which we are worried about MitM attacks, so I think we've already handled Hugh's "passive attacks only" context elsewhere, and I suspect that anything weaker than a MUST in this context here is going to cause delays during IETF Last Call, etcetera. If anybone thinks that MUST is wrong here, please speak up. - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Thu May 22 15:43:58 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27303 for ; Thu, 22 May 2003 15:43:57 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4MJhMs03576 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Thu, 22 May 2003 15:43:25 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h4MJiXr15812 for ipseckey-outgoing; Thu, 22 May 2003 15:44:33 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4MJiWU15807 for ; Thu, 22 May 2003 15:44:32 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4MJhGs03573 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Thu, 22 May 2003 15:43:18 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h4MJhFxP003500 for ; Thu, 22 May 2003 15:43:15 -0400 Message-Id: <200305221943.h4MJhFxP003500@sandelman.ottawa.on.ca> To: ipseckey@sandelman.ca Subject: Re: [IPSECKEY] Security Considerations (pass 2) In-reply-to: Your message of "Thu, 22 May 2003 14:49:39 EDT." <20030522184939.D24A2190E@thrintun.hactrn.net> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Thu, 22 May 2003 15:43:15 -0400 From: Michael Richardson Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Rob" == Rob Austein writes: Rob> So perhaps something like the following would do (keyboarded, might Rob> need wordsmithing): Rob> Note that the danger here only applies to cases where the gateway Rob> field of the IPSECKEY RR indicates a different entity than the owner Rob> name of the IPSECKEY RR. In cases where the end-to-end integrity of Rob> the IPSECKEY RR is suspect, the end client MUST[*] restrict its use Rob> of the IPSECKEY RR to cases where the RR owner name matches the Rob> content of the gateway field. I don't find anything wrong with your text, and I agree about the MUST. The current OE document, already says, for instance: 3.2.4.1 Restriction on unauthenticated TXT delegation records An implementation SHOULD also provide an additional administrative control on delegation records and DNSSEC. This control would apply to delegation records (the TXT records in the reverse-map) that are not protected by DNSSEC. Records of this type are only permitted to delegate to their own address as a gateway. When this option is enabled, an active attack on DNS will be unable to redirect packets to other than the original destination. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPs0oUYqHRg3pndX9AQGTzAQAuFCWW0Zwh/7ebfJ6u2m9jf1IGnsuKzK0 iOpcDRnHoRqPFbiiUnFm1COQiSXyLoFUwLInNXBTCbLXr/KeWhJqOtRKSxFrd8dW d1y6k+E+NnIBr2Bg3VDaY4qgubA9I2/cK/OfFeei/LqJnlSyLdrXI6HoQzgbQPFa 1ehony7T/hA= =iF1w -----END PGP SIGNATURE----- - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Fri May 23 05:16:40 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29448 for ; Fri, 23 May 2003 05:16:39 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4N9Ffs06643 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Fri, 23 May 2003 05:15:43 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h4N9GRX11559 for ipseckey-outgoing; Fri, 23 May 2003 05:16:28 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4N9GQu11548 for ; Fri, 23 May 2003 05:16:26 -0400 (EDT) Received: from herculanum.int-evry.fr (herculanum.int-evry.fr [157.159.11.15]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4N9FAs06636 for ; Fri, 23 May 2003 05:15:11 -0400 (EDT) Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id 7598633FF7; Fri, 23 May 2003 11:15:03 +0200 (CEST) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id 7F0463F40C; Fri, 23 May 2003 11:15:03 +0200 (CEST) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003052311150200843 ; Fri, 23 May 2003 11:15:03 +0200 Received: from localhost (ivan.int-evry.fr [157.159.100.48]) by sparte.int-evry.fr (Postfix) with ESMTP id B0B0F3F49B; Fri, 23 May 2003 11:15:01 +0200 (CEST) Received: from jjp by localhost with local id 19J8dG-0004CR-00; Fri, 23 May 2003 11:14:34 +0200 Date: Fri, 23 May 2003 11:14:34 +0200 From: Jean-Jacques Puig To: Michael Richardson Cc: ipseckey@sandelman.ca Subject: Re: [IPSECKEY] Security Considerations Message-ID: <20030523091434.GA2037@ivan.int-evry.fr> References: <20030522080629.GA28139@ivan.int-evry.fr> <200305221710.h4MHAOTF032410@sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200305221710.h4MHAOTF032410@sandelman.ottawa.on.ca> Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca Sorry this go so big. Comments are inline. On Thu, May 22, 2003 at 01:10:24PM -0400, Michael Richardson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > > >>>>> "Jean-Jacques" == Jean-Jacques Puig writes: > Jean-Jacques> On Tue, May 20, 2003 at 05:51:22PM -0400, Michael Richardson wrote: > >> >> If the attacker was not able to subsequently mount a second man-in- > >> >> the-middle attack on the IKE negotiation, then this would result in a > >> >> denial of service, as the authentication used by IKE would fail. > >> >> > >> >> If the attacker was also in a position to perform a man-in-the-middle > >> >> attack on IKE and IPsec negotiations as well, then it would be a > >> >> position to compromise the resulting IPsec channel. Note that an > >> >> attack must be able to perform active DNS attacks on both sides of > >> >> the IKE negotiation in order for this to succeed. > >> > Jean-Jacques> I see your point, but is it expected that IKE initiator and responder > Jean-Jacques> will both use IPSECKEY RR ? I think asymetric scenarios may happen > Jean-Jacques> (initiator using IPSECKEY and responder an other scheme). > >> > >> That's true. I have certainly done this in the past! > >> Both ends *do* need to have their public key's spoofed to get in the middle. > >> > > Jean-Jacques> Sorry, I don't know if I was clear about why I was talking about that. > Jean-Jacques> In the (latests) SC sentence: > > >> Note that an attacker must > >> be able to perform active DNS attacks on both sides of the IKE > >> negotiation in order for this to succeed. > > Jean-Jacques> I think we should only state: > > >> Note that an attacker must > >> be able to perform active attacks on both sides of the IKE > >> negotiation in order for this to succeed. > > Jean-Jacques> An active DNS attack against at least one side is what this > Jean-Jacques> security consideration deals with. The active attack on the other side > Jean-Jacques> depends on the other channel elected to get public key. This may be > > Okay, let me setup my classic nomenclature to explain: > > [Q] [R] > . . AS2 > [A]---------[SG-A].......+.[M]..+.......[SG-B]-------[B] > | ........ > ..PI.... > ..wild.. > .+.......+......[SG-C] AS3 > > > Assume that we have: > > A.in-addr.arpa. IN IPSECKEY ( 10 1 5 SG-A SG-A's-KEY ) > B.in-addr.arpa. IN IPSECKEY ( 10 1 5 SG-B SG-B's-KEY ) Ok, I see where we failed to understand each others. The difference is I assume the *general case* we consider is where IPSECKEY information is available for one peer, while the other peer may use other unsecure ways to get public keys (let's say a floppy with raw unauthenticated datas). That is, I assume we may have something like: A.in-addr.arpa. IN IPSECKEY ( 10 1 5 SG-A SG-A's-KEY ) (a) SG-B's-KEY and delegation(B->SG-B) on a floppy (b) I surely agree that M must perform two active attacks. The first one is a *DNS* active attack against SG-B, in which M provides the kind of following info instead of (a): A.in-addr.arpa. IN IPSECKEY (10 1 5 SG-A SG-M's-KEY ). The second active attack if a... *FLOPPY* active attack against SG-A :). That is, M substitutes a floppy providing SG-M's-KEY and delegation(B->SG-M). The difference between our views on the subject (IMHO) is that you consider the general case is where SG-A and SG-B will both use IPSECKEY RR, while for me the general case relevant to IPSECKEY RR is where (at least) either SG-A or SG-B uses IPSECKEY RR. Therefore, for me, the two above mentionned active *DNS* attacks are -in my general case- merely two active attacks. > > > Now, assume that SG-A's doesn't get this record, but instead gets: > > B.in-addr.arpa. IN IPSECKEY ( 10 1 5 SG-B SG-M's-KEY ) > > that's is, just the KEY is changed. > We then see: > [SG-A] <===IKE========>[M]<===IKE==>[SG-B] > > That is, M pretends to be SG-B to SG-A, and vica-versa. > Since SG-A has M's key instead of SG-B's key, SG-A is easily fooled into > thinking it is speaking to SG-B. > > However, if as you postulate, SG-B has SG-A's key in a secure fashion, In fact, what I postulate is that SG-B gets SG-A's key in an unsecure fashion which may be something else than IPSECKEY RR, like the floppy disk above. Sorry about being unclear about that. I came to consider this asymetry because I think several scheme to retrieve public keys will appear in the wild, and given this plurality, chances that both initiator and responder use IPSECKEY RR may be low. > then the second IKE transaction, where M pretends to be SG-A, fails. SG-B > doesn't believe M, since it has SG-A's proper key. > As such, it won't negotiate, and while SG-A may send traffic to M, M > will be unable to forward it to SG-B. > > Jean-Jacques> Note also that in the present case, the attacker is in position to > Jean-Jacques> modify phase 1 payloads to force choice of identities, kind of > Jean-Jacques> authentication, etc. All of this may affect the choice of channels > Jean-Jacques> elected to get the public keys. > > Yes/no. > It certainly can do that. The phase 1 info is authenticated after the > privacy is established, so the authentication will fail. Because M provided wrong responder key to SG-A through un-(integrity protected) ipseckey rr, M is able to recompute the kind of message from IKE's phase1 with public key encryption: HDR, KE, [ HASH(1), ] PubKey_r,PubKey_r (mesg 3) Thus, M is able to annonce a different IDii. According to the type of IDii, the responder may try to get public key of SG-A, and get fooled by the false IDii provided by M. > > Jean-Jacques> Please, if I'm wrong, may someone explain why active DNS attacks MUST > Jean-Jacques> be performed against BOTH sides in this case. > > I hope that the above explains it. > > >>>>> "Jean-Jacques" == Jean-Jacques Puig writes: > >> packets to the original destination. While the destination may be > >> willing to speak in the clear, replying to the original sender, the > >> sender would have already created a policy expecting ciphertext. > >> Thus, the need for attacker to intercept traffic from both sides. > > Jean-Jacques> Though it is not usefull to mention it in the draft, I think > Jean-Jacques> the attacker may achieve easily this interception: > Jean-Jacques> 1) Attacker provides a wrong IPSECKEY RR with it's own gateway through > Jean-Jacques> DNS cache poisonning. > > Jean-Jacques> 2) Initiator establishes tunnel with attacker's gateway. > > Yes. Let's call initiator "A". > > Jean-Jacques> 3) Initiator sends packets to Destination through tunnel. > > Yes. Let's call destination "B", and attacker "M" > > Jean-Jacques> 4) Attacker masquerades source address of packets coming through the > Jean-Jacques> tunnel, and forwards them to Destination. > > Do you mean performs NAPT or NAT? basic-nat (NAT). > > Jean-Jacques> 5) Destination answers to the masqueraded address (the attacker) > > Jean-Jacques> 6) Attacker masquerades destination address of packets coming from > Jean-Jacques> Destination, and forwards them through the tunnel, etc. > Jean-Jacques> Attackers main difficulty is then to deal with transport checksums and > Jean-Jacques> application datas containing endpoint addresses or names. > > Trivial, I think, since NAT technology is widely available, and there are few > protocols which are in widespread use that do not have NAPT support. > > Note that the destination (B) logs a connection from the attacker (M). > It also has no security, and knows it has none. > Since it was willing to speak in the clear in this case, I would expect > that it already thinks life is fine with being spoofed. > > M could also initiate to B, at which point B knows that it has a tunnel > to M, not to A. It could even be the case that B knows M is M securely (DNSSEC). > > The concern is naturally that "A" thinks that it is speaking securely to > "B". It may reveal passwords, etc. to M. It has been spoof'ed by M. Is > this a new attack? Not really to me. No, of course it is not new, we all know that, and discussion about SC is mostly about stating what we think we already know ;-)). But: > While the destination may be > willing to speak in the clear, replying to the original sender, the > sender would have already created a policy expecting ciphertext. > THUS, THE NEED FOR ATTACKER TO INTERCEPT TRAFFIC FROM BOTH SIDES. According to this sentence, one may think that M MUST be on 'the' route a packet would 'naturally' follow to go from SG-A to SG-B. This is not required: By providing it's own security gateway through the RR to the initiator, M both get a way to be IKE's responder and to intercept the packets, even if he was not on the classical route between SG-A and SG-B initially. M must then make sure he will get answers destined to A. He may proceed according one of the following ways: - by establishing a tunnel with SG-B, with the hope that SG-B will accept the odd policy that M is the gateway for A (but how can SG-B tell if no delegation info exist for A ?). If it works, M only forwards packets from A to B through the tunnel. - by doing basic-nat, changing A address by an address on which he has full control. Classical routing will then help him to get the answers. Thus, I certainly agree with what this sentence says and with your comments, but what I want to underline is that this attack does not require M to be on a specific location (that is, on a specific route), and therefore is PARTICULARLY easy to perform because M can specify a wrong address for SG-B in the RR. Note that in the case SG-B does not accept the previous policies ('clear-text' or 'M is gateway for A'), it remains the case where M and A are remote warriors from SG-B's network. With a combination of both basic-nat and tunnel establishment with SG-B, M performs the attack. Well anyway, I was only questioning the accuracy of the above consideration, but I agree I do hairs splitting here :), and that it reaches the frontiers of the charter. -- Jean-Jacques Puig - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Fri May 23 06:39:50 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01250 for ; Fri, 23 May 2003 06:39:49 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4NAdDs06929 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Fri, 23 May 2003 06:39:16 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h4NAeMT28861 for ipseckey-outgoing; Fri, 23 May 2003 06:40:22 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4NAeFu28851 for ; Fri, 23 May 2003 06:40:15 -0400 (EDT) Received: from herculanum.int-evry.fr (herculanum.int-evry.fr [157.159.11.15]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4NAd0s06924 for ; Fri, 23 May 2003 06:39:00 -0400 (EDT) Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id 5F74434074; Fri, 23 May 2003 12:38:54 +0200 (CEST) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id AE3BB3F494; Fri, 23 May 2003 12:38:55 +0200 (CEST) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003052312385310047 ; Fri, 23 May 2003 12:38:53 +0200 Received: from localhost (ivan.int-evry.fr [157.159.100.48]) by sparte.int-evry.fr (Postfix) with ESMTP id 8F8163F494; Fri, 23 May 2003 12:38:55 +0200 (CEST) Received: from jjp by localhost with local id 19J9wR-0007r8-00; Fri, 23 May 2003 12:38:27 +0200 Date: Fri, 23 May 2003 12:38:27 +0200 From: Jean-Jacques Puig To: Michael Richardson Cc: ipseckey@sandelman.ca Subject: Re: [IPSECKEY] Security Considerations (pass 2) Message-ID: <20030523103827.GB2037@ivan.int-evry.fr> References: <20030522184939.D24A2190E@thrintun.hactrn.net> <200305221943.h4MJhFxP003500@sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200305221943.h4MJhFxP003500@sandelman.ottawa.on.ca> Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca On Thu, May 22, 2003 at 03:43:15PM -0400, Michael Richardson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > > >>>>> "Rob" == Rob Austein writes: > Rob> So perhaps something like the following would do (keyboarded, might > Rob> need wordsmithing): > > Rob> Note that the danger here only applies to cases where the gateway > Rob> field of the IPSECKEY RR indicates a different entity than the owner > Rob> name of the IPSECKEY RR. In cases where the end-to-end integrity of > Rob> the IPSECKEY RR is suspect, the end client MUST[*] restrict its use > Rob> of the IPSECKEY RR to cases where the RR owner name matches the > Rob> content of the gateway field. > > I don't find anything wrong with your text, and I agree about the MUST. Question: what do you mean by: "In cases where the end-to-end integrity of the IPSECKEY RR is suspect" ? Do you mean: a) Implementation detected (how ?) or expects with a reasonnable probability that an active attack is under way. Then I agree the end client MUST restrict the use of the record. or: b) When there is no end-to-end integrity, (or when a gateway cannot know surely about that), the end client MUST restrict the use of the record. In case b), the end client does not know whether he is the victim of an active attack or not. Therefore, our choice here will affect implementations behaviour in networks in which only passive attacks may happen. From Mr Austein: > [*] Open MAY/SHOULD/MUST question here here. I've written it as MUST > because that's my own preference, but others may disagree. Reasoning, > such as it is: the context of this whole subsection assumes an > environment in which we are worried about MitM attacks, so I think > we've already handled Hugh's "passive attacks only" context elsewhere, > and I suspect that anything weaker than a MUST in this context here is > going to cause delays during IETF Last Call, etcetera. I would like to be sure that Mr Daniel has no further arguments about the interest of the gateway field to be different from the RR owner in the "passive attacks only context". In the context of active attack, I agree on a MUST, but how the implementation would know in which context it is ? Is it a choice from the administrator ? I think we can state it this way: In an environment in which only passive attacks are likely to happen, both key information and gateway option are to be trusted, and no specific end-to-end integrity protection is required. In an environment in which active attacks are likely to happen, both key information and gateway option are extremely vulnerable without the use of end-to-end integrity protection. Thus, in such an environment, the dns client MUST refuse any gateway field different from the RR owner name. Note that this implies coherence of types between RR owner name and gateway field (both IPv4 or both FQDN or both IPv6 etc), thus the use of self "." is recommanded for ease of use. Clients using IPSECKEY RR MAY provide a way to choose that no protection against active attacks is required. In this latter case, the client MAY restrict its use of the IPSECKEY RR to cases where the RR owner name matches. I'm really sorry to mess around with these problems of MAY/SHOULD/MUST, but I fear current statements let opened too many questions or may lead to restrict too much. -- Jean-Jacques Puig - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Fri May 23 10:03:13 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05346 for ; Fri, 23 May 2003 10:03:10 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4NE2Ks07579 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Fri, 23 May 2003 10:02:22 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h4NE3Px08551 for ipseckey-outgoing; Fri, 23 May 2003 10:03:25 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4NE3Ou08546 for ; Fri, 23 May 2003 10:03:24 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4NE28s07566 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Fri, 23 May 2003 10:02:09 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h4NE28h8026209 for ; Fri, 23 May 2003 10:02:08 -0400 Message-Id: <200305231402.h4NE28h8026209@sandelman.ottawa.on.ca> To: ipseckey@sandelman.ca Subject: Re: [IPSECKEY] Security Considerations In-reply-to: Your message of "Fri, 23 May 2003 11:14:34 +0200." <20030523091434.GA2037@ivan.int-evry.fr> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 23 May 2003 10:02:07 -0400 From: Michael Richardson Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Jean-Jacques" == Jean-Jacques Puig writes: Jean-Jacques> Ok, I see where we failed to understand each others. The difference is I Jean-Jacques> assume the *general case* we consider is where IPSECKEY information is Jean-Jacques> available for one peer, while the other peer may use other unsecure ways Jean-Jacques> to get public keys (let's say a floppy with raw unauthenticated datas). I'm not sure I'd call a floppy unauthenticated, but I understand that you are saying that M can not mount an online attack against B. Jean-Jacques> Because M provided wrong responder key to SG-A through un-(integrity Jean-Jacques> protected) ipseckey rr, M is able to recompute the kind of message from Jean-Jacques> IKE's phase1 with public key encryption: Jean-Jacques> HDR, KE, [ HASH(1), ] PubKey_r,PubKey_r (mesg 3) Jean-Jacques> Thus, M is able to annonce a different IDii. According to the type of Jean-Jacques> IDii, the responder may try to get public key of SG-A, and get fooled by Jean-Jacques> the false IDii provided by M. This depends a lot upon how you use IPSECKEY, I guess. Are you assuming that M is also impersonating B's IP? I agree that this is a man-in-the-middle attack. It is what happens when you use unauthenticated data :-) >> The concern is naturally that "A" thinks that it is speaking securely to >> "B". It may reveal passwords, etc. to M. It has been spoof'ed by M. Is >> this a new attack? Not really to me. Jean-Jacques> No, of course it is not new, we all know that, and discussion about SC is Jean-Jacques> mostly about stating what we think we already know ;-)). But: >> While the destination may be >> willing to speak in the clear, replying to the original sender, the >> sender would have already created a policy expecting ciphertext. >> THUS, THE NEED FOR ATTACKER TO INTERCEPT TRAFFIC FROM BOTH SIDES. Jean-Jacques> According to this sentence, one may think that M MUST be on 'the' Jean-Jacques> route a packet would 'naturally' follow to go from SG-A to SG-B. Jean-Jacques> This is not required: By providing it's own security gateway through the Jean-Jacques> RR to the initiator, M both get a way to be IKE's responder and to Jean-Jacques> intercept the packets, even if he was not on the classical route between Jean-Jacques> SG-A and SG-B initially. M must then make sure he will get answers Jean-Jacques> destined to A. He may proceed according one of the following ways: okay, you've sold me. Can you suggest text to detail this? Are you suggesting that I simply remove the highlighted (upcase) sentence? Jean-Jacques> Well anyway, I was only questioning the accuracy of the above Jean-Jacques> consideration, but I agree I do hairs splitting here :), and that it Jean-Jacques> reaches the frontiers of the charter. So, tell me what you'd like to do here... ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPs4p3oqHRg3pndX9AQGLAQP/U7VdJvIpAr9SqTS5ke/pPVc504PD0fP2 7+Zdth60LMKMezaSO2t9wJ7zr4yE5DL4E7pN0RCHBttiaPQkarfTz2zpz4M4deJr xA58/6Ibx7bR6dc6iuwsURSdB25MYil33n0VTrojSsfWl9Syz3o/Xv197dxh4Oc5 H5FsbqAoZwY= =gyFR -----END PGP SIGNATURE----- - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Fri May 23 16:11:50 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23807 for ; Fri, 23 May 2003 16:11:45 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4NKAJs09003 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Fri, 23 May 2003 16:10:21 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h4NKB6v24379 for ipseckey-outgoing; Fri, 23 May 2003 16:11:06 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4NKB4q24373 for ; Fri, 23 May 2003 16:11:05 -0400 (EDT) Received: from mail2.flora.ca (madras3.flora.ca [192.139.46.245]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4NK9ls08990 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO) for ; Fri, 23 May 2003 16:09:49 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail2.flora.ca (8.12.8/8.12.8) with ESMTP id h4NK9dKs022134 for ; Fri, 23 May 2003 16:09:40 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23426; Fri, 23 May 2003 16:03:51 -0400 (EDT) Message-Id: <200305232003.QAA23426@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipseckey@sandelman.ca From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [IPSECKEY] I-D ACTION:draft-ietf-ipseckey-rr-02.txt Date: Fri, 23 May 2003 16:03:50 -0400 Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPSEC KEYing information resource record Working Group of the IETF. Title : A method for storing IPsec keying material in DNS Author(s) : M. Richardson Filename : draft-ietf-ipseckey-rr-02.txt Pages : 15 Date : 2003-5-23 This document describes a new resource record for DNS. This record may be used to store public keys for use in IPsec systems. This record replaces the functionality of the sub-type #1 of the KEY Resource Record, which has been obsoleted by RFC3445. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipseckey-rr-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipseckey-rr-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipseckey-rr-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-5-23115537.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipseckey-rr-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipseckey-rr-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-23115538.I-D@ietf.org> --OtherAccess-- --NextPart-- - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Sun May 25 15:51:40 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09959 for ; Sun, 25 May 2003 15:51:39 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4PJoFs17319 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Sun, 25 May 2003 15:50:17 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h4PJp8t21933 for ipseckey-outgoing; Sun, 25 May 2003 15:51:09 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4PJp4F21928 for ; Sun, 25 May 2003 15:51:06 -0400 (EDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4PJnks17313 for ; Sun, 25 May 2003 15:49:47 -0400 (EDT) Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id B629E18E7 for ; Sun, 25 May 2003 15:48:37 -0400 (EDT) Date: Sun, 25 May 2003 15:48:37 -0400 From: Rob Austein To: ipseckey@sandelman.ca Subject: Re: [IPSECKEY] Security Considerations (pass 2) In-Reply-To: <20030523103827.GB2037@ivan.int-evry.fr> References: <20030522184939.D24A2190E@thrintun.hactrn.net> <200305221943.h4MJhFxP003500@sandelman.ottawa.on.ca> <20030523103827.GB2037@ivan.int-evry.fr> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030525194837.B629E18E7@thrintun.hactrn.net> Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca At Fri, 23 May 2003 12:38:27 +0200, Jean-Jacques Puig wrote: > > In the context of active attack, I agree on a MUST, but how the > implementation would know in which context it is ? Is it a choice from > the administrator ? In my opinion, the answer to this is "yes" (that is, I think that the decision on whether to worry about active attacks is administrative, and takes place on the client side). It might be appropriate for us to say that the default (for clueless administrators) must be to worry about active attacks, but I think that Hugh has made a decent case for why an implementor might chose to provide a way for consenting adults to chose not to worry about active attacks. > In an environment in which active attacks are likely to happen, both key > information and gateway option are extremely vulnerable without the > use of end-to-end integrity protection. Thus, in such an environment, > the dns client MUST refuse any gateway field different from the RR owner > name. Note that this implies coherence of types between RR owner name > and gateway field (both IPv4 or both FQDN or both IPv6 etc), thus the > use of self "." is recommanded for ease of use. Yeah, I was wondering if I should have punted the stuff about the RR owner name matching the gateway field and just said that a client which has to worry about active attacks on the DNS data MUST NOT trust IPSECKEY records with a non-zero gateway type field. - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Mon May 26 11:25:12 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16176 for ; Mon, 26 May 2003 11:25:11 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4QFOAl02487 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Mon, 26 May 2003 11:24:12 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h4QFP2v19716 for ipseckey-outgoing; Mon, 26 May 2003 11:25:02 -0400 (EDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4QFP0J19709 for ; Mon, 26 May 2003 11:25:01 -0400 (EDT) Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 9F3CE18C5 for ; Mon, 26 May 2003 11:22:36 -0400 (EDT) Date: Mon, 26 May 2003 11:22:36 -0400 From: Rob Austein To: ipseckey@sandelman.ca Subject: Re: [IPSECKEY] Security Considerations (pass 2) In-Reply-To: <20030526082045.GE6805@ivan.int-evry.fr> References: <20030522184939.D24A2190E@thrintun.hactrn.net> <200305221943.h4MJhFxP003500@sandelman.ottawa.on.ca> <20030523103827.GB2037@ivan.int-evry.fr> <20030525194837.B629E18E7@thrintun.hactrn.net> <20030526082045.GE6805@ivan.int-evry.fr> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030526152236.9F3CE18C5@thrintun.hactrn.net> Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca At Mon, 26 May 2003 10:20:45 +0200, Jean-Jacques Puig wrote: > > That's good question. Besides, on the server side, section 3.1 mandates: > > If no gateway is to be indicated, then the gateway type field MUST be > zero, and the gateway type MUST be "." > > BTW, s/gateway type/gateway field/ ? The second one, yes ('the gateway type MUST be "."'), good catch. > > Is there a peticular difference between the following 2 cases ? > > - No gateway (type=0 gateway=".") > - The gateway is the same as the RR owner (ex: type=1 > gateway=192.0.2.38) > > I would take type=0 as a clue that the host will accept transport mode > SA, and (type != 0 && address == RR_owner) as a clue that the host will > take only tunnel mode proposals. Is it the original intent ? Michael will have to speak to intent, but I didn't read it that way. I read the two cases as semantically equivalent, and had assumed that the choice of tunnel vs transport mode was something to be negotiated by the parties involved. We probably need a sentence in the draft to clarify this, one way or the other. - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Mon May 26 13:34:49 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18980 for ; Mon, 26 May 2003 13:34:49 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4QHXtl03014 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Mon, 26 May 2003 13:33:57 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h4QHYlk26575 for ipseckey-outgoing; Mon, 26 May 2003 13:34:47 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4QHYkq26570 for ; Mon, 26 May 2003 13:34:46 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4QHXRl03011 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Mon, 26 May 2003 13:33:28 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h4QHXQk0022707 for ; Mon, 26 May 2003 13:33:26 -0400 Message-Id: <200305261733.h4QHXQk0022707@sandelman.ottawa.on.ca> To: ipseckey@sandelman.ca Subject: Re: [IPSECKEY] Security Considerations (pass 2) In-reply-to: Your message of "Mon, 26 May 2003 11:22:36 EDT." <20030526152236.9F3CE18C5@thrintun.hactrn.net> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 26 May 2003 13:33:25 -0400 From: Michael Richardson Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Rob" == Rob Austein writes: Rob> At Mon, 26 May 2003 10:20:45 +0200, Jean-Jacques Puig wrote: >> >> That's good question. Besides, on the server side, section 3.1 mandates: >> >> If no gateway is to be indicated, then the gateway type field MUST be >> zero, and the gateway type MUST be "." >> >> BTW, s/gateway type/gateway field/ ? Rob> The second one, yes ('the gateway type MUST be "."'), good catch. Thank you. >> Is there a peticular difference between the following 2 cases ? >> >> - No gateway (type=0 gateway=".") >> - The gateway is the same as the RR owner (ex: type=1 >> gateway=192.0.2.38) >> >> I would take type=0 as a clue that the host will accept transport mode >> SA, and (type != 0 && address == RR_owner) as a clue that the host will >> take only tunnel mode proposals. Is it the original intent ? Rob> Michael will have to speak to intent, but I didn't read it that way. Rob> I read the two cases as semantically equivalent, and had assumed that Rob> the choice of tunnel vs transport mode was something to be negotiated Rob> by the parties involved. No intent is implied by this document. My opinion is that you would need to write a use-case document that explains how to you are using the record. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPtJP5IqHRg3pndX9AQHXkQQAtjtTRS7+3gFSJ9nwY7K6HDYoWsEVgREw pgLPsHLr2FoFuTRH0qKeT7gQ2n6d3yesyupo0Hma3+Xo8xuc7AdB4WIrJYbk7Xm5 k0TjtIGMKlo/ji0+J5mw0j6CGN+pi7Bet3pozmyRpHGcFSfM6j3GYIM48mO4fMlg /67MiAA6nRM= =Nqeh -----END PGP SIGNATURE----- - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Tue May 27 01:03:29 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15013 for ; Tue, 27 May 2003 01:03:28 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4R52Ol06886 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Tue, 27 May 2003 01:02:27 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h4R53Jc05020 for ipseckey-outgoing; Tue, 27 May 2003 01:03:19 -0400 (EDT) Received: from herculanum.int-evry.fr (herculanum.int-evry.fr [157.159.11.15]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4R53Gd05009 for ; Tue, 27 May 2003 01:03:17 -0400 (EDT) Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id BEC3F34675 for ; Mon, 26 May 2003 09:25:13 +0200 (CEST) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id 1CB333F428 for ; Mon, 26 May 2003 09:26:15 +0200 (CEST) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003052609251330839 for ; Mon, 26 May 2003 09:25:13 +0200 Received: from localhost (ivan.int-evry.fr [157.159.100.48]) by sparte.int-evry.fr (Postfix) with ESMTP id BA24A3F428 for ; Mon, 26 May 2003 09:26:14 +0200 (CEST) Received: from jjp by localhost with local id 19KCLT-0005So-00 for ; Mon, 26 May 2003 09:24:35 +0200 Date: Mon, 26 May 2003 09:24:35 +0200 From: Jean-Jacques Puig To: ipseckey@sandelman.ca Subject: [IPSECKEY] ultimate nits ? Message-ID: <20030526072435.GD6805@ivan.int-evry.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca Hi, In latest submission: - 1.1 Overview An IPSECKEY resource record MUST be used in combination with DNSSEC unless some other means of authenticating the IPSECKEY resource record is available. Doesn't this contradict current choice of SHOULD in security considerations ? - 2.6 RDATA format - RSA public key If the algorithm type has the value 5, then public key portion contains an RSA public key, encoded as described in secion 2 of s/secion/section/ - 3.2 Examples An example of a node, 192.0.2.38 that has delegated authority to the node 192.0.2.3. 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 5 1 s/5 1/1 5/ ? -- Jean-Jacques Puig - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Tue May 27 01:31:41 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15498 for ; Tue, 27 May 2003 01:31:41 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4R5VGl07006 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Tue, 27 May 2003 01:31:18 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h4R5W7h06917 for ipseckey-outgoing; Tue, 27 May 2003 01:32:07 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4R5W3d06912 for ; Tue, 27 May 2003 01:32:04 -0400 (EDT) Received: from herculanum.int-evry.fr (herculanum.int-evry.fr [157.159.11.15]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4R5Ujl07003 for ; Tue, 27 May 2003 01:30:45 -0400 (EDT) Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id 0777D33AC7; Mon, 26 May 2003 10:21:23 +0200 (CEST) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id 337633F42C; Mon, 26 May 2003 10:22:25 +0200 (CEST) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003052610212217524 ; Mon, 26 May 2003 10:21:22 +0200 Received: from localhost (ivan.int-evry.fr [157.159.100.48]) by sparte.int-evry.fr (Postfix) with ESMTP id E91FF3F42C; Mon, 26 May 2003 10:22:24 +0200 (CEST) Received: from jjp by localhost with local id 19KDDp-0005Vv-00; Mon, 26 May 2003 10:20:45 +0200 Date: Mon, 26 May 2003 10:20:45 +0200 From: Jean-Jacques Puig To: Rob Austein Cc: ipseckey@sandelman.ca Subject: Re: [IPSECKEY] Security Considerations (pass 2) Message-ID: <20030526082045.GE6805@ivan.int-evry.fr> References: <20030522184939.D24A2190E@thrintun.hactrn.net> <200305221943.h4MJhFxP003500@sandelman.ottawa.on.ca> <20030523103827.GB2037@ivan.int-evry.fr> <20030525194837.B629E18E7@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030525194837.B629E18E7@thrintun.hactrn.net> Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca On Sun, May 25, 2003 at 03:48:37PM -0400, Rob Austein wrote: > > In an environment in which active attacks are likely to happen, both key > > information and gateway option are extremely vulnerable without the > > use of end-to-end integrity protection. Thus, in such an environment, > > the dns client MUST refuse any gateway field different from the RR owner > > name. Note that this implies coherence of types between RR owner name > > and gateway field (both IPv4 or both FQDN or both IPv6 etc), thus the > > use of self "." is recommanded for ease of use. > > Yeah, I was wondering if I should have punted the stuff about the RR > owner name matching the gateway field and just said that a client > which has to worry about active attacks on the DNS data MUST NOT trust > IPSECKEY records with a non-zero gateway type field. That's good question. Besides, on the server side, section 3.1 mandates: If no gateway is to be indicated, then the gateway type field MUST be zero, and the gateway type MUST be "." BTW, s/gateway type/gateway field/ ? Is there a peticular difference between the following 2 cases ? - No gateway (type=0 gateway=".") - The gateway is the same as the RR owner (ex: type=1 gateway=192.0.2.38) I would take type=0 as a clue that the host will accept transport mode SA, and (type != 0 && address == RR_owner) as a clue that the host will take only tunnel mode proposals. Is it the original intent ? -- Jean-Jacques Puig - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Tue May 27 03:18:24 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00897 for ; Tue, 27 May 2003 03:18:23 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4R7Hgl07358 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Tue, 27 May 2003 03:17:45 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h4R7Ipj14787 for ipseckey-outgoing; Tue, 27 May 2003 03:18:51 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4R7Ijd14762 for ; Tue, 27 May 2003 03:18:45 -0400 (EDT) Received: from herculanum.int-evry.fr (herculanum.int-evry.fr [157.159.11.15]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4R7HQl07352 for ; Tue, 27 May 2003 03:17:26 -0400 (EDT) Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id AB3F233EA3; Tue, 27 May 2003 09:15:37 +0200 (CEST) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id 893123F429; Tue, 27 May 2003 09:17:00 +0200 (CEST) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003052709153716982 ; Tue, 27 May 2003 09:15:37 +0200 Received: from localhost (ivan.int-evry.fr [157.159.100.48]) by sparte.int-evry.fr (Postfix) with ESMTP id CE67E3F429; Tue, 27 May 2003 09:16:59 +0200 (CEST) Received: from jjp by localhost with local id 19KYfe-0007IJ-00; Tue, 27 May 2003 09:14:54 +0200 Date: Tue, 27 May 2003 09:14:54 +0200 From: Jean-Jacques Puig To: Michael Richardson Cc: ipseckey@sandelman.ca Subject: Re: [IPSECKEY] Security Considerations (pass 2) Message-ID: <20030527071454.GB31841@ivan.int-evry.fr> References: <20030526152236.9F3CE18C5@thrintun.hactrn.net> <200305261733.h4QHXQk0022707@sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200305261733.h4QHXQk0022707@sandelman.ottawa.on.ca> Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca On Mon, May 26, 2003 at 01:33:25PM -0400, Michael Richardson wrote: > >> I would take type=0 as a clue that the host will accept transport mode > >> SA, and (type != 0 && address == RR_owner) as a clue that the host will > >> take only tunnel mode proposals. Is it the original intent ? > > Rob> Michael will have to speak to intent, but I didn't read it that way. > Rob> I read the two cases as semantically equivalent, and had assumed that > Rob> the choice of tunnel vs transport mode was something to be negotiated > Rob> by the parties involved. > > No intent is implied by this document. > My opinion is that you would need to write a use-case document that > explains how to you are using the record. Right. Then current consideration about RR owner name matching content of the gateway field sounds both precise enough and not too restrictive. Looks fine for me. -- Jean-Jacques - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Wed May 28 13:33:37 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12928 for ; Wed, 28 May 2003 13:33:37 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4SHWNN01203 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Wed, 28 May 2003 13:32:25 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h4SHXC507658 for ipseckey-outgoing; Wed, 28 May 2003 13:33:13 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4SHXB807653 for ; Wed, 28 May 2003 13:33:11 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4SHVoN01198 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Wed, 28 May 2003 13:31:51 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h4SHVoC2018691 for ; Wed, 28 May 2003 13:31:50 -0400 Message-Id: <200305281731.h4SHVoC2018691@sandelman.ottawa.on.ca> To: ipseckey@sandelman.ca Subject: Re: [IPSECKEY] ultimate nits ? In-reply-to: Your message of "Mon, 26 May 2003 09:24:35 +0200." <20030526072435.GD6805@ivan.int-evry.fr> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 28 May 2003 13:31:49 -0400 From: Michael Richardson Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Jean-Jacques" == Jean-Jacques Puig writes: Jean-Jacques> In latest submission: I assume you mean -02. draft> An IPSECKEY resource record MUST be used in combination with DNSSEC draft> unless some other means of authenticating the IPSECKEY resource record draft> is available. Jean-Jacques> Doesn't this contradict current choice of SHOULD in security Jean-Jacques> considerations ? I guess that it does. I will change this to a SHOULD. We moderated it with the rest of the sentence, but your point is well taken. Jean-Jacques> 2.6 RDATA format - RSA public key Thanks for the other nits. I stared at the numbers for each for awhile, and I guess I didn't get them all. Numbers without labels are hard for us humans :-) ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPtTyg4qHRg3pndX9AQHYtgQA7b7TCeOuc+KYMeVwpw811Oy5OlYgRBpO 8UmWA8hv9JpdS1ZcMCyLSuCp9o8MXh61lbD6s/gNR9INyACN3cZkly1FBR1am80j SrvfkVmIwkPOhl6GsFX8wfOeku5A7wYvd/YCVWijGTdjRq9qFqatkLAhP2XcublS pCYY4rbKbzI= =cNZs -----END PGP SIGNATURE----- - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Thu May 29 04:42:26 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23095 for ; Thu, 29 May 2003 04:42:25 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4T8fiN05728 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Thu, 29 May 2003 04:41:46 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h4T8giY07073 for ipseckey-outgoing; Thu, 29 May 2003 04:42:44 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4T8ggJ07061 for ; Thu, 29 May 2003 04:42:42 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4T8aIN05711 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Thu, 29 May 2003 04:36:19 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h4T8aISk007532; Thu, 29 May 2003 04:36:18 -0400 Message-Id: <200305290836.h4T8aISk007532@sandelman.ottawa.on.ca> To: itojun@iijlab.net, ipseckey@sandelman.ca cc: namedroppers@ops.ietf.org Subject: [IPSECKEY] Re: draft-ietf-ipseckey-rr-02.txt In-reply-to: Your message of "Thu, 29 May 2003 17:19:29 +0900." <20030529081929.E4BE892@coconut.itojun.org> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Thu, 29 May 2003 04:36:17 -0400 From: Michael Richardson Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca >>>>> "itojun" == itojun writes: itojun> not sure if it is for ipsec wg, or dnsext wg... Thank you for the comments... the answer is neither, new "IPSECKEY" WG. itojun> of a node, 192.0.2.38 that has published its key only." itojun> (gateway field itojun> being ".") confuses me. what does it mean? It might be used by the responder to verify the identity provided by the initiator, without expressing any desire to be contacted. itojun> what kind of value should i put into "gateway" field if i itojun> want to ask people to do transport mode IPsec? Please see thread from last week: http://www.sandelman.ottawa.on.ca/lists/html/ipseckey/msg00170.html :-) itojun> maybe, draft-ietf-ipseckey-rr-02.txt should refer some other itojun> document itojun> like draft-richardson-ipsec-opportunistic-11.txt for its actual itojun> usage/meaning? That document does not specify IPSECKEY, nor will it. Rather, a future document will explain usage. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Fri May 30 07:24:19 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29089 for ; Fri, 30 May 2003 07:24:18 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4UBN3H01243 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Fri, 30 May 2003 07:23:06 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h4UBNwh20532 for ipseckey-outgoing; Fri, 30 May 2003 07:23:58 -0400 (EDT) Received: from mail2.flora.ca (madras3.flora.ca [192.139.46.245]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4UBNqq20527 for ; Fri, 30 May 2003 07:23:52 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail2.flora.ca (8.12.8/8.12.8) with ESMTP id h4UBMSKs023967 for ; Fri, 30 May 2003 07:22:28 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28498; Fri, 30 May 2003 07:15:15 -0400 (EDT) Message-Id: <200305301115.HAA28498@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipseckey@sandelman.ca From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [IPSECKEY] I-D ACTION:draft-ietf-ipseckey-rr-03.txt Date: Fri, 30 May 2003 07:15:14 -0400 Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPSEC KEYing information resource record Working Group of the IETF. Title : A method for storing IPsec keying material in DNS Author(s) : M. Richardson Filename : draft-ietf-ipseckey-rr-03.txt Pages : 15 Date : 2003-5-29 This document describes a new resource record for DNS. This record may be used to store public keys for use in IPsec systems. This record replaces the functionality of the sub-type #1 of the KEY Resource Record, which has been obsoleted by RFC3445. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipseckey-rr-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipseckey-rr-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipseckey-rr-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-5-29161817.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipseckey-rr-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipseckey-rr-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-29161817.I-D@ietf.org> --OtherAccess-- --NextPart-- - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Fri May 30 15:49:26 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25016 for ; Fri, 30 May 2003 15:49:25 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4UJmZH03232 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Fri, 30 May 2003 15:48:37 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h4UJmIK17006 for ipseckey-outgoing; Fri, 30 May 2003 15:48:18 -0400 (EDT) Received: from fledge.watson.org (ak82hjs7hex92j@fledge.watson.org [204.156.12.50]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4UJmGU17001 for ; Fri, 30 May 2003 15:48:16 -0400 (EDT) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.9/8.12.9) with ESMTP id h4UJk0On073250 for ; Fri, 30 May 2003 15:46:00 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.12.9/8.12.9/Submit) with SMTP id h4UJjxOM073247 for ; Fri, 30 May 2003 15:45:59 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 30 May 2003 15:45:59 -0400 (EDT) From: Sam Weiler Reply-To: Sam Weiler To: ipseckey@sandelman.ca Subject: [IPSECKEY] Unknown format handling In-Reply-To: <200305301115.HAA28498@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca Does the document need to specify the handling of unknown gateway types/formats (section 2.4)? -- Sam - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Fri May 30 16:35:31 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26975 for ; Fri, 30 May 2003 16:35:30 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4UKUxH03424 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Fri, 30 May 2003 16:31:01 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h4UKWFv18818 for ipseckey-outgoing; Fri, 30 May 2003 16:32:15 -0400 (EDT) Received: from fledge.watson.org (ak82hjs7hex92j@fledge.watson.org [204.156.12.50]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4UKWCU18806 for ; Fri, 30 May 2003 16:32:12 -0400 (EDT) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.9/8.12.9) with ESMTP id h4UJjGOn073149; Fri, 30 May 2003 15:45:20 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.12.9/8.12.9/Submit) with SMTP id h4UJjGGr073146; Fri, 30 May 2003 15:45:16 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 30 May 2003 15:45:16 -0400 (EDT) From: Sam Weiler To: Michael Richardson cc: ipseckey Subject: Re: [IPSECKEY] new revision of draft In-Reply-To: <200303301650.h2UGomsY001842@marajade.sandelman.ottawa.on.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca On Sun, 30 Mar 2003, Michael Richardson wrote: > > Sam> Section 2.4: Needs to have generic text for any value, then the > Sam> expansion for RSA and maybe mention the DSA doc, but not in it's own > Sam> subsection. > > I don't understand how what is there is wrong. This is now 2.6/2.7. The new section 2.3 isn't clear on how (or if) IPSECKEY automatically incorporates newly defined public key formats. This needs to be clarified. 2.6 Should have generic text specifying how any key format is included, with RSA and DSA given as examples, assuming that we want this to be extensible. If we want to limit it to RSA/DSA, that should be made more explicit. -- Sam - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Fri May 30 17:25:54 2003 Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29049 for ; Fri, 30 May 2003 17:25:53 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4ULItH03869 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Fri, 30 May 2003 17:18:57 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h4ULK7x21971 for ipseckey-outgoing; Fri, 30 May 2003 17:20:07 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h4ULK6U21966 for ; Fri, 30 May 2003 17:20:06 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4ULIiH03866 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Fri, 30 May 2003 17:18:45 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h4ULIhRl021665 for ; Fri, 30 May 2003 17:18:43 -0400 Message-Id: <200305302118.h4ULIhRl021665@sandelman.ottawa.on.ca> To: ipseckey Subject: Re: [IPSECKEY] new revision of draft In-reply-to: Your message of "Fri, 30 May 2003 15:45:16 EDT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 30 May 2003 17:18:42 -0400 From: Michael Richardson Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca >>>>> "Sam" == Sam Weiler writes: Sam> Section 2.4: Needs to have generic text for any value, then the Sam> expansion for RSA and maybe mention the DSA doc, but not in it's own Sam> subsection. >> I don't understand how what is there is wrong. Sam> This is now 2.6/2.7. The new section 2.3 isn't clear on how (or if) Sam> IPSECKEY automatically incorporates newly defined public key formats. Sam> This needs to be clarified. okay. I'd say that if DNSEXT defines a new key format that it should be permissible to use it. Can you suggest text to this effect? ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed.