From mcr@lox.sandelman.ottawa.on.ca Thu Apr 15 11:42:40 2004 Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [205.150.200.166]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01224 for ; Thu, 15 Apr 2004 11:42:38 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i3FFgRg29922 for ; Thu, 15 Apr 2004 11:42:27 -0400 (EDT) Received: (from mcr@localhost) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) id i3FFkJw27825; Thu, 15 Apr 2004 11:46:19 -0400 (EDT) Date: Thu, 15 Apr 2004 11:46:19 -0400 (EDT) Message-Id: <200404151546.i3FFkJw27825@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 WG/mailing list 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 Wed Apr 28 14:35:39 2004 Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [205.150.200.166]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06214 for ; Wed, 28 Apr 2004 14:35:38 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i3SIP0P02716 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Wed, 28 Apr 2004 14:25:03 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) id i3SIN2x17135 for ipseckey-outgoing; Wed, 28 Apr 2004 14:23:02 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [205.150.200.181]) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i3SIIUM16963 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL) for ; Wed, 28 Apr 2004 14:18:31 -0400 (EDT) Received: from sandelman.ottawa.on.ca (wlan237.sandelman.ca [205.150.200.237]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i3SICqP02586 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Wed, 28 Apr 2004 14:12:52 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i3SICqsG026934 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 28 Apr 2004 14:12:52 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i3SICqsZ026931 for ; Wed, 28 Apr 2004 14:12:52 -0400 To: ipseckey@lox.sandelman.ottawa.on.ca Subject: [IPSECKEY] Security Considerations (take 10) X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Date: Wed, 28 Apr 2004 14:12:52 -0400 Message-ID: <26930.1083175972@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca -----BEGIN PGP SIGNED MESSAGE----- The following text is in the -10 document, which I've asked to have published. This is the result of many exchanges between Rob, Sam and I to get thing right. I have introduced two new headings (4.1.1 and 4.1.2) and moved some text upwards. 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) [8]. 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 derivative specification that makes 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. | An active attack on the DNS that caused the wrong IP address to be | retrieved (via forged address), and therefore the wrong QNAME to be | queried would also result in a man-in-the-middle attack. This | situation exists independantly of whether or not the IPSECKEY RR is | 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. This | section deals with the situation where DNSSEC is not available. This | is not the recommended deployment scenario. |4.1.1 Active attacks against IPSECKEY keying materials The first kind of active attack is when the attacker replaces the keying material with either a key under its control or with garbage. | The gateway field is either untouched, or is null. The IKE | negotiation will therefore occur with the original end-system. For | this attack to be successful, the attacker must be able to perform a | man-in-the-middle attack on the IKE negotiation. This attack requires | that the attacker be able to intercept and modify packets on the | forwarding path for the IKE and data packets. | If the attacker is not able to perform this man-in-the-middle attack | on the IKE negotiation, then this will result in a denial of service, | as the IKE negotiation will fail. If the attacker is able to both to mount active attacks against DNS and is also in a position to perform a man-in-the-middle attack on IKE and IPsec negotiations, then the attacker will 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. |4.1.2 Active attacks against IPSECKEY gateway material The second kind of active attack is one in which the attacker replaces the the gateway address to point to a node under the | attacker's control. The attacker then either replaces the public key | or removes it. If they were to remove the public key, then they | could provide an accurate public key of their own in a second record. | This second form creates a simple man-in-the-middle since the | attacker can then 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 just 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 will have already created a policy expecting ciphertext. Thus, | the attacker will need to intercept traffic in both directions. In | some cases, the attacker may be able to accomplish the full intercept | by use of Network Addresss/Port Translation (NAT/NAPT) technology. | This attack is easier than the first one because the attacker does | NOT need to be on the end-to-end forwarding path. The attacker need | only be able to modify DNS replies. This can be done by packet | modification, by various kinds of race attacks, or through methods | that pollute DNS caches. | 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. As the RR owner name is assumed when the gateway field is | null, a null gateway field is considered a match. | Thus, any records obtained under unverified conditions (e.g. no | DNSSEC, or trusted path to source) that have a non-null gateway field | MUST be ignored. | This restriction eliminates attacks against the gateway field, which | are considered much easier, as the attack does not need to be on the | forwarding path. | In the case of an IPSECKEY RR with a value of three in its gateway | type field, the gateway field contains a domain name. The subsequent | query required to translate that name into an IP address or IPSECKEY | RR will also be subject to man-in-the-middle attacks. If the | end-to-end integrity of this second query is suspect, then the | provisions above also apply. The IPSECKEY RR MUST be ignored whenever | the resulting gateway does not match the QNAME of the original | IPSECKEY RR query. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQI/0IoqHRg3pndX9AQHzIQP6AnlB/TT3QHkOcQrogAKgIrSbIcmAOiuv oioxl/yQtPqHcDzUjot0AVc1zPNdt6yMhZ2fid46s3rff5jQjj5AqeH25soEieZ3 f6R581l1q0btCdL1vaq3T8Ll3ru/g3lq2WGiLWAKq1kiFRfrAGlujhoEER2n10i+ Ht2j1cN9f6g= =IV/k -----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 Apr 28 15:43:18 2004 Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [205.150.200.166]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11879 for ; Wed, 28 Apr 2004 15:43:17 -0400 (EDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i3SJajZ03215 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Wed, 28 Apr 2004 15:41:10 -0400 (EDT) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) id i3SJcTs18951 for ipseckey-outgoing; Wed, 28 Apr 2004 15:38:29 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [205.150.200.181]) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i3SJb1M18921 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL) for ; Wed, 28 Apr 2004 15:37:02 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i3SJVMP03177 for ; Wed, 28 Apr 2004 15:31:23 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11233; Wed, 28 Apr 2004 15:31:19 -0400 (EDT) Message-Id: <200404281931.PAA11233@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ipseckey@sandelman.ca From: Internet-Drafts@ietf.org Subject: [IPSECKEY] I-D ACTION:draft-ietf-ipseckey-rr-10.txt Date: Wed, 28 Apr 2004 15:31:18 -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-10.txt Pages : 19 Date : 2004-4-28 This document describes a new resource record for Domain Name System (DNS). This record may be used to store public keys for use in IP security (IPsec) systems. The record also includes provisions for indicating what system should be contacted when establishing an IPsec tunnel with the entity in question. 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-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-10.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-10.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: <2004-4-28153221.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipseckey-rr-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipseckey-rr-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-28153221.I-D@ietf.org> --OtherAccess-- --NextPart-- - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed.