From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Mon Feb 3 04:56:55 2003 Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) id EAA19463 for ipseckey-outgoing; Mon, 3 Feb 2003 04:56:55 -0500 (EST) Received: from ms1.nttdata.co.jp (ms1.nttdata.co.jp [163.135.193.232]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id EAA19435 for ; Mon, 3 Feb 2003 04:56:53 -0500 (EST) Received: from mail1.nttdata.co.jp ([163.135.10.21]) by ms1.nttdata.co.jp (8.9.3/3.7W-NTTDATA-TOP-01/14/03) with ESMTP id WAA07253; Mon, 3 Feb 2003 22:00:08 +0900 (JST) Received: from noanetmx0.noanet.nttdata.co.jp (localhost [127.0.0.1]) by mail1.nttdata.co.jp (8.9.3/3.7W-NTTDATA-TOP-11/07/02) with ESMTP id VAA05601; Mon, 3 Feb 2003 21:57:40 +0900 (JST) Received: from noanet01.noanet.nttdata.co.jp (noanet01.noanet.nttdata.co.jp [10.1.49.11]) by noanetmx0.noanet.nttdata.co.jp (8.9.3/3.7W) with ESMTP id VAA16359; Mon, 3 Feb 2003 21:59:07 +0900 (JST) Received: from nttdata.co.jp (10.8.131.50 [10.8.131.50]) by noanet01.noanet.nttdata.co.jp with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DVMQ05RF; Mon, 3 Feb 2003 22:00:07 +0900 Message-ID: <3E3E6803.60305@nttdata.co.jp> Date: Mon, 03 Feb 2003 22:00:51 +0900 From: Tatsuya Baba User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; ja-JP; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: ja MIME-Version: 1.0 To: Michael Richardson CC: ipseckey@lox.sandelman.ottawa.on.ca Subject: Re: [IPSECKEY] Re: I-D ACTION:draft-richardson-ipsec-rr-01.txt References: <200301311613.h0VGDurs003846@marajade.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca Michael Richardson wrote: > Tatsuya> In case both public key and gateway field in IPSECKEY RR exist, > Tatsuya> how should I interpret it? > > The public key that is provided is the public key of the gateway. OK, I mistook that the "public key" is the key of the RR owner, not the gateway's key. > They appear in the same resource record to avoid a second round trip. If it > does not appear, then a second round trip is necessary. This scenario may be > useful when the public key has to change very frequently and updating all of > the "client" records is too difficult. > (to put it another way, this is intentionally not 3rd-normal form) I think the second round trip is necessary only for first time, because the gateway's IPSECKEY RR retrieved by the second round trip is cached on the initiating IPsec node, and the cached gateway's IPSECKEY RR is used if accessing the different host behind the same gateway. > Tatsuya> If the gateway field is the same as the owner name of RR, > Tatsuya> it should be considered as a security gateway. > > Yes, in this case, the host is acting as its own gateway. Do the following two RRs both have the same meaning? 1) owner-name: "Host 1" gateway: "Host 1" public-key: Host-1-key 2) owner-name: "Host 1" gateway: "none" public-key: Host-1-key If (1) is a security gateway which implements tunnel mode only and (2) is an IPsec host which implements both tunnel and transport mode, the initiator can propose appropriate SA parameters (tunnel or transport mode) according to the presence of gateway field of the IPSECKEY RR. > Tatsuya> Host 1 -------- Internet ----------- Security --- Host 2 > Tatsuya> | | Gateway1 | > Tatsuya> | | | | > Tatsuya> | -------Security Association 1---------- | > Tatsuya> | | > Tatsuya> ----------------Security Association 2--------------- > > There is no clear way for host-1 to set this up on its own. > It would occur under this circumstance, assuming that the IPSECKEY RR is > deployed in the reverse map as specified in OE. (It may get deployed > elsewhere with different rules) I understand well that IPSECKEY RRs can establish netsted SAs. Thanks. -- Tatsuya BABA babatt@nttdata.co.jp R&D Headquarters, NTT DATA CORPORATION - 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 Feb 3 10:03:47 2003 Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) id KAA08768 for ipseckey-outgoing; Mon, 3 Feb 2003 10:03:47 -0500 (EST) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id KAA08755 for ; Mon, 3 Feb 2003 10:03:42 -0500 (EST) Received: from sandelman.ottawa.on.ca ([2002:c08b:2e21:2:204:76ff:fe2d:8c]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h13I6mL10601 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Mon, 3 Feb 2003 13:06:49 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h13I6krg004643 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 3 Feb 2003 13:06:48 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h13I6dwb004640; Mon, 3 Feb 2003 13:06:46 -0500 Message-Id: <200302031806.h13I6dwb004640@marajade.sandelman.ottawa.on.ca> To: Tatsuya Baba cc: ipseckey@lox.sandelman.ottawa.on.ca Subject: Re: [IPSECKEY] Re: I-D ACTION:draft-richardson-ipsec-rr-01.txt In-reply-to: Your message of "Mon, 03 Feb 2003 22:00:51 +0900." <3E3E6803.60305@nttdata.co.jp> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 03 Feb 2003 13:06:39 -0500 From: Michael Richardson Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Tatsuya" == Tatsuya Baba writes: Tatsuya> Michael Richardson wrote: Tatsuya> In case both public key and gateway field in IPSECKEY RR exist, Tatsuya> how should I interpret it? >> >> The public key that is provided is the public key of the gateway. Tatsuya> OK, I mistook that the "public key" is the key of the RR owner, not the Tatsuya> gateway's key. If gateway == RR owner, or if gateway is absent, then this is the case. >> They appear in the same resource record to avoid a second round trip. If it >> does not appear, then a second round trip is necessary. This scenario may be >> useful when the public key has to change very frequently and updating all of >> the "client" records is too difficult. >> (to put it another way, this is intentionally not 3rd-normal form) Tatsuya> I think the second round trip is necessary only for first time, Tatsuya> because the gateway's IPSECKEY RR retrieved by the second round trip Tatsuya> is cached on the initiating IPsec node, and the cached gateway's Tatsuya> IPSECKEY RR is used if accessing the different host behind the same Tatsuya> gateway. This can be true, and if you want this behaviour, this is an option. The issue is that when looking opportunistically, every round trip with the DNS is time that the user sits waiting for the web page to load... Tatsuya> Do the following two RRs both have the same meaning? Tatsuya> 1) Tatsuya> owner-name: "Host 1" Tatsuya> gateway: "Host 1" Tatsuya> public-key: Host-1-key Tatsuya> 2) Tatsuya> owner-name: "Host 1" Tatsuya> gateway: "none" Tatsuya> public-key: Host-1-key It depends upon where the key is found. They may be different - I am hoping to avoid deep discussion about semantics and focus on the format as a container. The IPsec sub-type of KEY contained no semantics. The only difference is the addition of the gateway field. Does it carry enough information for whatever it is that you want to do? ] 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 iQCVAwUBPj6vrYqHRg3pndX9AQHzhwQA6WIpuDqbwO/VN/4GTNKIuVBdWL/mDULU nCCBpLV2utzMkyU6uSc6xDM+8RmNZgGaw12m/Y420Up+wzZl9EHZcIDSbqHoq0XB zrJswxxV6t61uuXPlGxbW/uwznGaS5FqvoGjSL9ExAtVfX76y49jV0SkFw7v1OZk TqG9nnKcQgw= =0y+/ -----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 Feb 26 15:20:43 2003 Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) id PAA10713 for ipseckey-outgoing; Wed, 26 Feb 2003 15:20:43 -0500 (EST) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id PAA10708 for ; Wed, 26 Feb 2003 15:20:42 -0500 (EST) Received: from sandelman.ottawa.on.ca ([2002:c08b:2e21:2:204:76ff:fe2d:8c]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h1QKKQv10300 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Wed, 26 Feb 2003 15:20:28 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h1QKKPFp026535 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Wed, 26 Feb 2003 15:20:26 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h1QKKP9V026532 for ; Wed, 26 Feb 2003 15:20:25 -0500 Date: Wed, 26 Feb 2003 15:20:25 -0500 From: Michael Richardson Message-Id: <200302262020.h1QKKP9V026532@marajade.sandelman.ottawa.on.ca> Prev-Resent: Wed, 26 Feb 2003 15:20:24 -0500 Prev-Resent: "ipseckey " 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 Wed Feb 26 14: 51:42 2003 Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id OAA08799 for ; Wed, 26 Feb 2003 14:51:37 -0500 (EST) Received: by sentry.gw.tislabs.com; id OAA27711; Wed, 26 Feb 2003 14:52:07 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma027707; Wed, 26 Feb 03 14:51:34 -0500 Received: from localhost (weiler@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) with ESMTP id h1QJonP07896 for ; Wed, 26 Feb 2003 14:50:49 -0500 (EST) Date: Wed, 26 Feb 2003 14:50:49 -0500 (EST) From: Sam Weiler X-X-Sender: To: ipseckey@sandelman.ca Subject: WG Action: IPSEC KEYing information resource record Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-To: ipseckey Resent-Date: Wed, 26 Feb 2003 15:20:24 -0500 Resent-From: Michael Richardson ---------- Forwarded message ---------- Date: Wed, 26 Feb 2003 13:48:10 -0500 From: The IESG To: IETF-Announce: ; Subject: WG Action: IPSEC KEYing information resource record A new working group has been formed in the Security Area of the IETF. For additional information, contact the Area Directors or the Working Group Chairs. IPSEC KEYing information resource record (ipseckey) ----------------------------------------------------- Current Status: Active Working Group Chair(s): Sam Weiler Rob Austein Security Area Director(s): Jeffrey Schiller Steven Bellovin Security Area Advisor: Steven Bellovin Mailing Lists: General Discussion:ipseckey@sandelman.ca To Subscribe: ipseckey-request@sandelman.ca Archive: http://www.sandelman.ca/lists/html/ipseckey/ Description of Working Group: This effort has the goal of designing a IPSEC-specific resource record for the domain name system (DNS) to replace the functionality of the IPSEC sub-type of the KEY resource record. The original DNSSEC specification explicitly specified flags on the KEY resource records for use by IPSEC. Experience has shown that this has operational problems. The DNSEXT working group is restricting the use of the KEY record to DNS uses only. Thus, IPSEC keying via DNS needs a new resource record. The scope of work is to identify what information is needed in an IPSEC-specific keying resource record, and to design such a record in co-operation with the dnsext working group. The contents of the resource record are not limited to only the information that is in the DNS KEY record but may also contain other useful IPSEC information, such as that which is required for Opportunistic Encryption. Other possible uses are out of scope for this working group, since any reuse will require a careful analysis of the trust model and possible security interactions with IPsec. It is anticipated that such analysis will be documented in some future standards-track RFCs. 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. This effort is specific to providing IPSEC information in DNS. All other distribution channels are out of scope. Goals and Milestones: MAR 03 Solicit various proposals on what information is needed in IPSEC specific KEYing record APR 03 Publish first Internet-Draft of consensus DNS Resource Record MAY 03 Complete WG Last Call on consensus DNS RR proposal document and pass document to IESG for consideration as a Proposed Standard - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed.