From owner-ipsec-policy@mail.vpnc.org Fri Jun 20 08:08:18 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00943 for ; Fri, 20 Jun 2003 08:08:14 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5KBZTrb066906 for ; Fri, 20 Jun 2003 04:35:29 -0700 (PDT) (envelope-from owner-ipsec-policy@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5KBZT28066905 for ipsec-policy-bks; Fri, 20 Jun 2003 04:35:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5KBZSrb066899 for ; Fri, 20 Jun 2003 04:35:29 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26378; Fri, 20 Jun 2003 07:35:27 -0400 (EDT) Message-Id: <200306201135.HAA26378@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec-policy@vpnc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsp-ipsec-apireq-00.txt Date: Fri, 20 Jun 2003 07:35:27 -0400 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Policy Working Group of the IETF. Title : Requirements for an IPsec API Author(s) : B. Sommerfeld Filename : draft-ietf-ipsp-ipsec-apireq-00.txt Pages : 8 Date : 2003-6-19 Given the open nature of the Internet today, application protocols require strong security. IPsec's wire protocols appear to meet the requirements of many protocols. The lack of a common model for application-layer interfaces has complicated use of IPsec by upper- layer protocols. This document provides an overview of facilities which a host IPsec implementation should provide to applications to allow them to both observe and influence how IPsec protects their communications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsp-ipsec-apireq-00.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-ipsp-ipsec-apireq-00.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-ipsp-ipsec-apireq-00.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-6-19154410.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsp-ipsec-apireq-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsp-ipsec-apireq-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-19154410.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec-policy@mail.vpnc.org Fri Jun 20 15:50:33 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04869 for ; Fri, 20 Jun 2003 15:50:32 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5KJIxrb096283 for ; Fri, 20 Jun 2003 12:18:59 -0700 (PDT) (envelope-from owner-ipsec-policy@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5KJIxFe096282 for ipsec-policy-bks; Fri, 20 Jun 2003 12:18:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from xanthine.gratuitous.org (xanthine.gratuitous.org [199.232.39.35]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5KJIvrb096266 for ; Fri, 20 Jun 2003 12:18:57 -0700 (PDT) (envelope-from ietf-ipsp@joelweber.com) Received: by xanthine.gratuitous.org with local; Fri, 20 Jun 2003 15:18:58 -0400 From: "Joel N. Weber II" To: ipsec-policy@vpnc.org Subject: draft-ietf-ipsp-ipsec-apireq-00 comments Message-Id: Date: Fri, 20 Jun 2003 15:18:58 -0400 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It would be useful if the introduction, after saying ``Many protocols under development are considering the use of IPsec for security.'' there were examples given of a few such protocols; without such examples, it is difficult to understand what problem this document is really trying to solve. For example, is the goal to provide an integrity protection and confidentiality layer underneath SASL user authentication methods? To address an issue with protocols such as TLS and Secure Shell discussed in draft-iab-sec-cons-03.txt: ``Second, TLS is susceptible to IP layer attacks that IPsec is not. Typically, these attacks take some form of denial of service or connection assassination.''? To provide security for some protocol whose properties are something else entirely? All of the above? (Are there any protocols that are explicitly excluded from this for any reason?) For making Secure Shell less vulnerable to denial of service attacks, it seems that it might be useful to define a new diffie-hellman-group1-sha1-ah method that would be identical to diffie-hellman-group1-sha1, except that it also would generate a shared secret to feed to IPsec AH by doing HASH(K || H || "G" || session_id); this implies that there may be value to having an IPsec API provide a mechanism by which an application can supply key material. Under ``Non-Goals and Bad Ideas'', it's unclear whether the ``Exposure of Keys'' section is trying to prohibit applications contributing key material in this fashion, or not. From owner-ipsec-policy@mail.vpnc.org Fri Jun 20 20:31:48 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15398 for ; Fri, 20 Jun 2003 20:31:48 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5L00Lrb009276 for ; Fri, 20 Jun 2003 17:00:21 -0700 (PDT) (envelope-from owner-ipsec-policy@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5L00Ljq009275 for ipsec-policy-bks; Fri, 20 Jun 2003 17:00:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5L00Krb009269 for ; Fri, 20 Jun 2003 17:00:20 -0700 (PDT) (envelope-from sommerfeld@east.sun.com) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5L00GmF013223; Fri, 20 Jun 2003 17:00:16 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5L00F27025870; Fri, 20 Jun 2003 20:00:15 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h5L00Fq3012319; Fri, 20 Jun 2003 20:00:15 -0400 (EDT) Message-Id: <200306210000.h5L00Fq3012319@thunk.east.sun.com> From: Bill Sommerfeld To: "Joel N. Weber II" cc: ipsec-policy@vpnc.org Subject: Re: draft-ietf-ipsp-ipsec-apireq-00 comments In-Reply-To: Your message of "Fri, 20 Jun 2003 15:18:58 EDT." Reply-to: sommerfeld@East.Sun.COM Date: Fri, 20 Jun 2003 20:00:15 -0400 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I've made the following changes, which I hope will clarify my intent. - Bill *** draft-ietf-ipsp-ipsec-apireq-00.xml 2003/06/20 22:52:06 1.4 --- draft-ietf-ipsp-ipsec-apireq-00.xml 2003/06/20 23:59:29 1.5 *************** *** 66,71 **** --- 66,92 ---- +
+ Most protocols for application security, such as TLS and SSH operate + at or above the transport layer. This renders the underlying + transport connections vulnerable to denial of service attacks, + including connection + assassination. + IPsec offers the promise of protecting against many of these denial of + service attacks. + + + There are other potential benefits. Conventional software-based + IPsec implementations isolate applications from the cryptographic + keys, improving security by making inadvertant or malicious key + exposure more difficult. In addition, specialized hardware may allow + encryption keys protected from disclosure within trusted cryptographic + units. Also, custom hardware units may well allow for higher performance. + + +
+
Separate policy and mechanism *************** *** 309,315 ****
There is absolutely no reason for applications to see the underlying ! encryption keys.
--- 330,338 ----
There is absolutely no reason for applications to see the underlying ! encryption keys, or influence the choice of keys. This is to allow an ! IPsec implementation to have a clear boundary around its cryptographic ! components.
*************** *** 399,405 **** ! None --- 422,430 ---- ! ! ! From owner-ipsec-policy@mail.vpnc.org Fri Jun 20 20:32:31 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15415 for ; Fri, 20 Jun 2003 20:32:31 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5L09Arb009419 for ; Fri, 20 Jun 2003 17:09:10 -0700 (PDT) (envelope-from owner-ipsec-policy@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5L099n2009418 for ipsec-policy-bks; Fri, 20 Jun 2003 17:09:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5L098rb009413 for ; Fri, 20 Jun 2003 17:09:08 -0700 (PDT) (envelope-from sommerfeld@east.sun.com) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5L093g5022549; Fri, 20 Jun 2003 17:09:04 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5L093tK022603; Fri, 20 Jun 2003 20:09:03 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h5L093q3012369; Fri, 20 Jun 2003 20:09:03 -0400 (EDT) Message-Id: <200306210009.h5L093q3012369@thunk.east.sun.com> From: Bill Sommerfeld To: "Joel N. Weber II" cc: ipsec-policy@vpnc.org Subject: Re: draft-ietf-ipsp-ipsec-apireq-00 comments In-Reply-To: Your message of "Fri, 20 Jun 2003 15:18:58 EDT." Reply-to: sommerfeld@East.Sun.COM Date: Fri, 20 Jun 2003 20:09:03 -0400 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: one more edit, to add references to related documents: *** draft-ietf-ipsp-ipsec-apireq-00.xml 2003/06/20 23:59:29 1.5 --- draft-ietf-ipsp-ipsec-apireq-00.xml 2003/06/21 00:08:09 1.6 *************** *** 85,90 **** --- 85,96 ---- units. Also, custom hardware units may well allow for higher performance. + + Areas where this is currently under active discussion include the + set of block storage protocols being + developed by the IP Storage working group and NFS version 4. +
*************** *** 424,429 **** --- 430,437 ---- + + From owner-ipsec-policy@mail.vpnc.org Sat Jun 21 11:46:13 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10218 for ; Sat, 21 Jun 2003 11:46:13 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5LFAfrb080523 for ; Sat, 21 Jun 2003 08:10:41 -0700 (PDT) (envelope-from owner-ipsec-policy@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5LFAfA7080522 for ipsec-policy-bks; Sat, 21 Jun 2003 08:10:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5LFAZrb080511 for ; Sat, 21 Jun 2003 08:10:40 -0700 (PDT) (envelope-from mcr@sandelman.ottawa.on.ca) 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 h5LFASq07111 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Sat, 21 Jun 2003 11:10:30 -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 h5LFC7i13386; Sat, 21 Jun 2003 11:12:08 -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 h5LFADde013383; Sat, 21 Jun 2003 11:10:14 -0400 Message-Id: <200306211510.h5LFADde013383@sandelman.ottawa.on.ca> To: "Joel N. Weber II" cc: ipsec-policy@vpnc.org Subject: Re: draft-ietf-ipsp-ipsec-apireq-00 comments In-reply-to: Your message of "Fri, 20 Jun 2003 15:18:58 EDT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Sat, 21 Jun 2003 11:10:12 -0400 From: Michael Richardson Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Joel" == Joel N Weber writes: Joel> session_id); this implies that there may be value to having an IPsec Joel> API provide a mechanism by which an application can supply key Joel> material. Under ``Non-Goals and Bad Ideas'', it's unclear whether Joel> the Joel> ``Exposure of Keys'' section is trying to prohibit applications Joel> contributing key material in this fashion, or not. PF_KEY already permits an application to do that. That's why it is a non-goal. The problem is already solved. ] 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"); [ From owner-ipsec-policy@mail.vpnc.org Thu Jun 26 11:22:24 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01950 for ; Thu, 26 Jun 2003 11:22:08 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5QEcBrb051906 for ; Thu, 26 Jun 2003 07:38:11 -0700 (PDT) (envelope-from owner-ipsec-policy@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5QEcB8m051905 for ipsec-policy-bks; Thu, 26 Jun 2003 07:38:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from wolfe.bbn.com (wolfe.bbn.com [128.89.80.22]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5QEcArb051885 for ; Thu, 26 Jun 2003 07:38:11 -0700 (PDT) (envelope-from clynn@bbn.com) Received: by wolfe.bbn.com (Postfix, from userid 13538) id 880D316484; Thu, 26 Jun 2003 10:38:06 -0400 (EDT) From: Charles Lynn To: ipsec@lists.tislabs.com Cc: ipsec-policy@vpnc.org Subject: IKEv2 selectors for IPsec? Message-Id: <20030626143806.880D316484@wolfe.bbn.com> Date: Thu, 26 Jun 2003 10:38:06 -0400 (EDT) Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Folks, What do folks think of making the IPsec (AH/ESP) protocol and SPI an IKEv2 selector? Its use gets into the area of dynamically created policy, e.g., when an end-to-end SA has to traverse intermediate security gateways. The question might be more appropriate for the IP Security Policy WG (is there any progress there or have folks lost interest?). A catch-22 might be that AH is not currently treated as an "upper layer protocol", so the processing model might need to be extended a bit. That in turn leads to the question of whether folks see any advantage to having IPv6 extension headers -- fragmentation header, routing header, jumbogram, destination options (and maybe Option Type), be selectors. One might argue that they are useful for filtering (access control) but not not useful as items that would select a policy action -- i.e., IPsec should use them but there is no need for IKEv2 negotiation. Charlie From owner-ipsec-policy@mail.vpnc.org Thu Jun 26 13:06:08 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09479 for ; Thu, 26 Jun 2003 13:05:53 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5QGXJrb059231 for ; Thu, 26 Jun 2003 09:33:19 -0700 (PDT) (envelope-from owner-ipsec-policy@mail.vpnc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5QGXJvl059230 for ipsec-policy-bks; Thu, 26 Jun 2003 09:33:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ipsec-policy@mail.vpnc.org using -f Received: from bsn-mail-01.bstormnetworks.com (mail.bstormnetworks.com [209.11.156.50]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5QGXIrb059220 for ; Thu, 26 Jun 2003 09:33:18 -0700 (PDT) (envelope-from skelly@airespace.com) Received: from airespace.com ([172.16.8.113]) by bsn-mail-01.bstormnetworks.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 26 Jun 2003 09:33:14 -0700 Message-ID: <3EFB20EB.3080005@airespace.com> Date: Thu, 26 Jun 2003 09:35:55 -0700 From: "Scott G. Kelly" Organization: Airespace User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Charles Lynn CC: ipsec@lists.tislabs.com, ipsec-policy@vpnc.org Subject: Re: IKEv2 selectors for IPsec? References: <20030626143806.880D316484@wolfe.bbn.com> X-Enigmail-Version: 0.75.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jun 2003 16:33:14.0286 (UTC) FILETIME=[A3D5A4E0:01C33C00] Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Charles Lynn wrote: | Folks, | | What do folks think of making the IPsec (AH/ESP) protocol and SPI an | IKEv2 selector? Agree - this has its uses. We need a more general model for protocol selectors. Scott -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQE++yDrMtIdhO0pgN4RArXxAJ463XU3vTfDkoXRqoKF95hnHdLDiACg45G/ F/Mss9G0g+ggnuQcLIUtUVU= =G+64 -----END PGP SIGNATURE-----