From owner-ietf-ipsra@mail.vpnc.org Mon Jul 2 12:12:45 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03560 for ; Mon, 2 Jul 2001 12:12:44 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f62FHf721146 for ietf-ipsra-bks; Mon, 2 Jul 2001 08:17:41 -0700 (PDT) Received: from smtp1.cluster.oleane.net (smtp1.cluster.oleane.net [195.25.12.16]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f62FHdm21142 for ; Mon, 2 Jul 2001 08:17:39 -0700 (PDT) Received: from oleane (upper-side.rain.fr [194.250.212.114]) by smtp1.cluster.oleane.net with SMTP id f62FHdo70868 for ; Mon, 2 Jul 2001 17:17:39 +0200 (CEST) Message-ID: <005501c1030a$01a60ba0$0601a8c0@oleane.com> From: "Peter Lewis" To: Subject: IPSec Global Summit Date: Mon, 2 Jul 2001 17:16:45 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0052_01C1031A.C4EBB820" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0052_01C1031A.C4EBB820 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The third annual IPSec Global Summit will take place in Paris October 23 = through 26, 2001.=20 http://www.upperside.fr/ipsec2001/ipsec01intro.htm ------=_NextPart_000_0052_01C1031A.C4EBB820 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
The third annual IPSec Global Summit will take place = in Paris=20 October 23 through 26, 2001.
http://www.up= perside.fr/ipsec2001/ipsec01intro.htm
------=_NextPart_000_0052_01C1031A.C4EBB820-- From owner-ietf-ipsra@mail.vpnc.org Tue Jul 3 07:44:31 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA24816 for ; Tue, 3 Jul 2001 07:44:28 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f63AvU909247 for ietf-ipsra-bks; Tue, 3 Jul 2001 03:57:30 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f63AvNm09239 for ; Tue, 3 Jul 2001 03:57:28 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23273; Tue, 3 Jul 2001 06:56:40 -0400 (EDT) Message-Id: <200107031056.GAA23273@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ipsra@vpnc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-dhcp-13.txt Date: Tue, 03 Jul 2001 06:56:39 -0400 Sender: owner-ietf-ipsra@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 Remote Access Working Group of the IETF. Title : DHCPv4 Configuration of IPSEC Tunnel Mode Author(s) : B. Patel, B. Aboba, S. Kelly, V. Gupta Filename : draft-ietf-ipsec-dhcp-13.txt Pages : 17 Date : 02-Jul-01 In many remote access scenarios, a mechanism for making the remote host appear to be present on the local corporate network is quite useful. This may be accomplished by assigning the host a 'virtual' address from the corporate network, and then tunneling traffic via IPSec from the host's ISP-assigned address to the corporate security gateway. In IPv4, Dynamic Host Configuration Protocol (DHCP) provides for such remote host configuration. This draft explores the requirements for host configuration in IPSec tunnel mode, and describes how DHCPv4 may be leveraged for configuration. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-dhcp-13.txt 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-ipsec-dhcp-13.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-ipsec-dhcp-13.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: <20010702161405.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-dhcp-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-dhcp-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010702161405.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ipsra@mail.vpnc.org Tue Jul 3 13:07:11 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12660 for ; Tue, 3 Jul 2001 13:07:10 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f63GSS621855 for ietf-ipsra-bks; Tue, 3 Jul 2001 09:28:28 -0700 (PDT) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f63GSQm21850 for ; Tue, 3 Jul 2001 09:28:26 -0700 (PDT) Received: by mail.redcreek.com with Internet Mail Service (5.5.2653.19) id <3GSKH9J1>; Tue, 3 Jul 2001 09:29:08 -0700 Received: from redcreek.com (host43.redcreek.com [209.218.26.43]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3GSKH9JD; Tue, 3 Jul 2001 09:29:03 -0700 From: "Scott G. Kelly" To: ietf-ipsra@vpnc.org Message-ID: <3B41F2CC.B22B7DF0@redcreek.com> Date: Tue, 03 Jul 2001 09:29:00 -0700 Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: requirements draft - suggested additions Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi All, I am (finally) performing the edits resulting from wg last call on the requirements draft, and it occurs to me that something is lacking. However, given that last call has occurred, I thought I should check with everyone before making any additions. In section 2 (General Solution Requirements), there is a list of 6 requirements: o should provide direct support for legacy user authentication systems such as RADIUS o should encourage migration from existing low-entropy password-based systems to more secure authentication systems o if legacy support cannot be provided without some sort of migration, the impact of such migration should be minimized o user authentication information must be protected against eavesdropping and replay (including the user identity) o single sign-on capability should be provided in configurations employing load-balancing and/or redundancy o n-factor authentication mechanisms should be supported I think we should add the following: o Security gateway vulnerability to DoS attacks should be minimized, and if possible, should not be greater than the vulnerability which exists in SGW systems not providing remote access o The chosen mechanism(s) should minimize any reduction in the baseline security of the underlying IPsec connection (when compared with the unselected mechanisms) Does anyone object to either of these? Scott From owner-ietf-ipsra@mail.vpnc.org Thu Jul 5 07:35:38 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07849 for ; Thu, 5 Jul 2001 07:35:37 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f65ArDM28646 for ietf-ipsra-bks; Thu, 5 Jul 2001 03:53:13 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f65ArCm28639 for ; Thu, 5 Jul 2001 03:53:12 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06348; Thu, 5 Jul 2001 06:52:28 -0400 (EDT) Message-Id: <200107051052.GAA06348@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ipsra@vpnc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsra-pic-02.txt Date: Thu, 05 Jul 2001 06:52:27 -0400 Sender: owner-ietf-ipsra@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 Remote Access Working Group of the IETF. Title : PIC, A Pre-IKE Credential Provisioning Protocol Author(s) : Y. Sheffer, H. Krawczyk, B. Aboba Filename : draft-ietf-ipsra-pic-02.txt Pages : 23 Date : 03-Jul-01 This document presents a method to bootstrap IPSec authentication via an 'Authentication Server' (AS) and legacy user authentication (e.g., RADIUS). The client machine communicates with the AS using a key exchange protocol where only the server is authenticated, and the derived keys are used to protect the legacy user authentication. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsra-pic-02.txt 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-ipsra-pic-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-ipsra-pic-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: <20010703124508.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsra-pic-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsra-pic-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010703124508.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ipsra@mail.vpnc.org Thu Jul 5 12:47:42 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19228 for ; Thu, 5 Jul 2001 12:47:42 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f65GD7h17346 for ietf-ipsra-bks; Thu, 5 Jul 2001 09:13:07 -0700 (PDT) Received: from [165.227.249.20] (ip20.proper.com [165.227.249.20]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f65GD5m17338 for ; Thu, 5 Jul 2001 09:13:05 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <200107051052.GAA06348@ietf.org> References: <200107051052.GAA06348@ietf.org> Date: Thu, 5 Jul 2001 09:11:20 -0700 To: ietf-ipsra@vpnc.org From: Paul Hoffman / VPNC Subject: Re: I-D ACTION:draft-ietf-ipsra-pic-02.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 6:52 AM -0400 7/5/01, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the IP Security Remote Access Working >Group of the IETF. > > Title : PIC, A Pre-IKE Credential Provisioning Protocol > Author(s) : Y. Sheffer, H. Krawczyk, B. Aboba > Filename : draft-ietf-ipsra-pic-02.txt > Pages : 23 > Date : 03-Jul-01 > >This document presents a method to bootstrap IPSec authentication via >an 'Authentication Server' (AS) and legacy user authentication (e.g., >RADIUS). The client machine communicates with the AS using a key >exchange protocol where only the server is authenticated, and the >derived keys are used to protect the legacy user authentication. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ipsra-pic-02.txt Thank you to the authors for turning this draft in! Could all folks in the WG take a good look at the draft soon and make comments here on the list? It would be nice to make progress at a slightly faster pace. --Paul Hoffman, Director --VPN Consortium From owner-ietf-ipsra@mail.vpnc.org Thu Jul 5 12:48:04 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19280 for ; Thu, 5 Jul 2001 12:48:03 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f65GD7m17347 for ietf-ipsra-bks; Thu, 5 Jul 2001 09:13:07 -0700 (PDT) Received: from [165.227.249.20] (ip20.proper.com [165.227.249.20]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f65GD6m17342 for ; Thu, 5 Jul 2001 09:13:06 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: Date: Thu, 5 Jul 2001 09:12:40 -0700 To: ietf-ipsra@vpnc.org From: Paul Hoffman / VPNC Subject: Fwd: Protocol Action: DHCPv4 Configuration of IPSEC Tunnel Mode to Proposed Standard Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Congratulations to the WG; we have our first standard out. >To: IETF-Announce: ; >Cc: RFC Editor >Cc: Internet Architecture Board >Cc: ipsec@lists.tislabs.com >From: The IESG >Subject: Protocol Action: DHCPv4 Configuration of IPSEC Tunnel Mode to > Proposed Standard >Date: Thu, 05 Jul 2001 10:23:59 -0400 >Sender: owner-ipsec@lists.tislabs.com > > > >The IESG has approved the Internet-Draft 'DHCPv4 Configuration of IPSEC >Tunnel Mode' as a Proposed Standard. >This document is the product of the IPSEC Remote Access (IPSRA) Working >Group. The IESG contact persons are Jeffrey Schiller and Marcus >Leech. > > >Technical Summary > > This protocol provides a mechanism for IPSEC tunnel configuration using > the existing DHCP, IKE and IPSEC protocols. It defines a new HTYPE > for IPSEC virtual interfaces, and describes the steps necessary to make > DHCP work correctly and securely for IPSEC tunnel configuration. > >Working Group Summary > > The competitor to this protocol, IKECFG, has been largely dismissed by > both the IPSEC and IPSRA working groups. There was no significant dissent > during the LAST CALL period. The document outlines why it is a more > appropriate solution than IKECFG. > >Protocol Quality > > This document was reviewed by Marcus Leech. At least two implementations > are known to exist. From owner-ietf-ipsra@mail.vpnc.org Thu Jul 5 20:46:33 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA01610 for ; Thu, 5 Jul 2001 20:46:31 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f660DZ628632 for ietf-ipsra-bks; Thu, 5 Jul 2001 17:13:35 -0700 (PDT) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f660DXm28628 for ; Thu, 5 Jul 2001 17:13:33 -0700 (PDT) Received: by mail.redcreek.com with Internet Mail Service (5.5.2653.19) id <3G8WXB8B>; Thu, 5 Jul 2001 17:14:17 -0700 Received: from redcreek.com (SKELLYLAPTOP [209.125.38.47]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3G8WXB70; Thu, 5 Jul 2001 17:13:36 -0700 From: "Scott G. Kelly" To: ietf-ipsra@vpnc.org Message-ID: <3B4502BE.3A7295CD@redcreek.com> Date: Thu, 05 Jul 2001 17:13:50 -0700 Organization: RedCreek Communications X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Subject: evaluation draft Content-Type: multipart/mixed; boundary="------------8E2D553262DA1FCF8FFD7DCA" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------8E2D553262DA1FCF8FFD7DCA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All, Attached is a copy of the draft which compares pic, getcert, crack, ula, hybrid, and xauth that I promised months ago. I've submitted it to the ID editor (as a personal submission), but also wanted to archive it here in the mailing list. I vastly underestimated the amount of work involved, and feel as though I'd like to work on it for another week or so even now. On the other hand, we need to move forward, so I'm putting it out now in order to solicit comments. Scott --------------8E2D553262DA1FCF8FFD7DCA Content-Type: text/plain; charset=us-ascii; name="draft-kelly-ipsra-eval-00.txt" Content-Disposition: inline; filename="draft-kelly-ipsra-eval-00.txt" Content-Transfer-Encoding: 7bit IPsec Remote Access Working Group Scott Kelly INTERNET-DRAFT RedCreek Communications draft-kelly-ipsra-eval-00.txt July, 2001 Comparing Proposed Solutions for IPsec Remote Access Legacy User Authentication Status of This Memo This document is an Internet Draft and is in full conformance with all provisions of Section 10 of [RFC2026]. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Comments on this document should be sent to the IETF IPsec remote access discussion list (ietf-ipsra@vpnc.org). Abstract A number of competing methods for integrating legacy remote access user authentication into IPsec have been proposed, resulting in confusion as to which method(s) might be best for solving the problems at hand. This document briefly compares these proposals in an effort to clarify the relative standing of each with respect to the problem space and requirements. Kelly Expires Jan 2002 [Page 1] Internet Draft July, 2001 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Basic Problem Space Description . . . . . . . . . . . . . . . . 3 1.3 Reader Prerequisites . . . . . . . . . . . . . . . . . . . . . . 4 1.4 Requirements Terminology . . . . . . . . . . . . . . . . . . . . 4 1.5 General Terminology . . . . . . . . . . . . . . . . . . . . . . 4 2. General Solution Requirements . . . . . . . . . . . . . . . . . . 5 3. Brief Enumeration of Proposed Solutions . . . . . . . . . . . . . 7 4. Common Features of Proposed Solutions . . . . . . . . . . . . . . 8 4.1 Common Issues for Proposals Supporting Preshared Keys . . . . . 8 4.1.1 General issues for configurations using preshared keys . . . . 9 4.1.2 Fixed Address (unique PSK) . . . . . . . . . . . . . . . . . . 10 4.1.2 Non-fixed Address, Global Preshared Key . . . . . . . . . . . 10 4.1.3 Non-fixed Address, Unique Preshared Key . . . . . . . . . . . 11 4.2 General Issues For Configurations Using Mutual Certificates . . 11 5. Comparing the Proposals . . . . . . . . . . . . . . . . . . . . . 12 5.1 XAUTH/MODECFG . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.2 Hybrid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.3 ULA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.4 CRACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.5 L2TP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.6 PIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.7 GetCert . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 6. Comparison of Proposals to Requirements . . . . . . . . . . . . . 17 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 7.1 DoS Susceptibility . . . . . . . . . . . . . . . . . . . . . . . 20 7.2 Code Complexity . . . . . . . . . . . . . . . . . . . . . . . . 21 7.3 Single Sign-on Support . . . . . . . . . . . . . . . . . . . . . 21 7.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . . . 21 9. Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 23 Kelly Expires Jan 2002 [Page 2] Internet Draft July, 2001 1. Introduction The IPsec remote access working group (ipsra) was formed in order to settle upon a solution set for providing secure remote access using IPsec components. Integral to the secure remote access problem is the desire to provide support for existing legacy authentication mechanisms, most notably RADIUS and SecureID. A number of competing methods for integrating such user authentication into IPsec have been proposed, resulting in confusion as to which method(s) might be best for solving the problems at hand. This document briefly compares these proposals in an effort to clarify the relative standing of each with respect to the problem space and requirements. 1.2 Basic Problem Space Description Customers want to provide secure remote access to their networks using IPsec along with authentication methods which leverage currently deployed user authentication mechanisms (primarily RADIUS and SecureID). This is difficult, as currently defined authentication mechanisms for IPsec are symmetric, e.g. either both sides (the user and the security gateway) authenticate using a shared secret, or both sides authenticate using identical public key mechanisms (encryption or signatures). These mechanisms provide no support for the passphrases which are typically required for legacy mechanisms. While at first glance one might conclude that passwords are similar to shared secrets, and that some adaptation of the shared secret mechanism currently supported by IPsec would resolve this problem, there are at least two issues with this approach (ignoring for the moment that preshared keys are susceptible to dictionary attacks, and that users would often make this simpler by choosing easily guessed passphrases). First, there is the problem of identifying the correct secret to apply at the gateway. IKE, as currently defined, may only identify shared secrets by IP address if main mode is used, and for most remote access scenarios, the IP address of the remote user simply is not known a priori. Even if it were, this would be no help if a one time passphrase mechanism were in use. This implies that use of aggressive mode is required for this approach, and this raises a number of security issues due to vulnerabilities associated with aggressive mode. Also, many of the same issues relating to one time passphrases exist for aggressive mode. The second issue raised by using passphrases as preshared keys pertains to scalability. If passphrases are to be in any way useful from a security perspective, they must be unique for each user. Since Kelly Expires Jan 2002 [Page 3] Internet Draft July, 2001 the gateway must also use this same passphrase (it is being used as a shared secret), this requires that the gateway be configured with each remote user's unique identifier and passphrase. This becomes problematic as the number of remote users grows large. Further complicating matters, legacy mechanisms typically provide one-sided authentication for the user, implicitly trusting that the challenger (the gateway) is who/what it claims to be. However, IPsec provides for no such one-sided authentication technique. Hence, in order to support legacy authentication mechanisms within IPsec, it must either be possible to authenticate the user and the gateway asymmetrically, or it must be possible to derive a user credential from the legacy authentication process which may then be used to secure an IPsec connection. 1.3 Reader Prerequisites Reader familiarity with RFCs 2401-2412 is a minimum prerequisite to understanding the concepts discussed here. Familiarity with concepts relating to Public Key Infrastructures (PKIs) is also necessary, as is familiarity with the various secure remote access proposals discussed below ([XAUTH/MODECFG], [HYBRID], [ULA], [CRACK], [PIC], [L2TPSEC], [GETCERT]). An understanding of various classes of attacks on cryptographic primitives and network connections will further facilitate understanding. 1.4 Requirements Terminology The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [KEYWORDS]. 1.5 General Terminology Following are definitions of terms as they are used in this document. o MiM: Man-in-the-Middle, as in the case where an adversary positions an intercepting system between two endpoints, and traffic in both directions must pass through this intercepting system, giving the adversary the opportunity to modify the data stream in either or both directions. o DoS: Denial of Service, as in the case where a system is prevented from delivering essential services due to outside interference. Kelly Expires Jan 2002 [Page 4] Internet Draft July, 2001 o User Identifier: this term refers to the value used to uniquely identify the remote user, typically a user name. o Passphrase: this term refers to the value the remote user presents in conjunction with the user identifier in order to verify the user's identity; it may be a value the user commits to memory (such as an ascii string), it may be retrieved from storage, or it may be generated by a device the user possesses or interacts with at the time of the access attempt. In the case of n-factor authentication mechanisms, a user may be required to present multiple passphrases in order to satisfy admission criteria. o SGW - Security GateWay, the IPsec termination point for the target network to which remote acess is to be provided. o PSK - PreShared Key, as in a shared secret value used for proof of identity and/or group membership. o IRAC - Ipsec Remote Access Client o IRAS - Ipsec Remote Access Server (or SGW) o DH exchange - Diffie-Hellman key exchange 2. General Solution Requirements In evaluating the various proposed solutions, the first order of business is to hold them up against the user authentication requirements for secure remote access to determine how completely satisfied the requirements are by each proposal. Basic requirements for user authentication as it applies to secure remote access using IPsec are presented in [KR01], and these requirements are not detailed here, except for a brief synopsis (taken from [KR01]). In general, proposed IPsec remote access mechanisms should meet the following goals: o should provide direct support for legacy user authentication systems such as RADIUS o should encourage migration from existing low-entropy password-based systems to more secure authentication systems o if legacy support cannot be provided without some sort of migration, the impact of such migration should be minimized o user authentication information must be protected against Kelly Expires Jan 2002 [Page 5] Internet Draft July, 2001 eavesdropping and replay (including the user identity) o single sign-on capability should be provided in configurations employing load-balancing and/or redundancy o n-factor authentication mechanisms should be supported Two additional goals not listed above are suggested in this document: o Security gateway vulnerability to DoS attacks should be minimized, and if possible, should not be greater than the vulnerability which exists in SGW systems not providing remote access o The chosen mechanism(s) should minimize any reduction in the baseline security of the underlying IPsec connection In most cases, the motivation for each of the security goals in the initial list above is obvious. However, the need for the two additional suggested goals may be less evident, so supporting discussion is provided below. Regarding vulnerability to DoS attacks, we should note that the SGW represents a shared access point for the target network, and as such, has the potential to adversely affect multiple users in case of failure, both inside and outside of the target network. Further, in cases where there is only one SGW for a given network, it represents a single point of failure. Hence, it seems reasonable to suggest that the chosen solution should not increase the DoS vulnerability of this critical system if this can be avoided. Regarding the security of the underlying connection, IPsec, as currently defined, provides for a baseline measure of security with certain assumptions. That is, if we may assume that the keying material generated by the DH exchange is effectively random (i.e. unguessable), and by implication that the keying material used for authenticating the key exchange is effectively random (as well as securely stored), then other assumptions regarding relative security of the resulting connection (i.e. the effort required to compromise the connection) are warranted. However, it is possible to choose methods of producing and/or storing authentication keying material which invalidate these assumptions. If such a method is chosen, then the baseline security of the underlying connection will be reduced when compared to a connection which uses more secure keying material production and storage methods. This implies that the overall security characteristics of the user Kelly Expires Jan 2002 [Page 6] Internet Draft July, 2001 authentication mechanism may directly influence the security of the underlying IPsec connection. This being the case, it seems reasonable to suggest that either the chosen mechanism should not reduce the baseline effectiveness of the underlying IPsec connection in comparison to non-remote-access connections, or (if this cannot be avoided) that the resulting security reduction should be minimized. A secondary area of concern pertains to the manner in which we might unwittingly reduce security by adding functionality which interacts with the base IPsec subsystem in unforseen ways. As systems grow in complexity, it becomes increasingly difficult to reasonably assert that such unforseen interactions are either not possible or not occurring. This is largely due to the increase in the number of system inputs and their corresponding outputs, and to our inability to accurately characterize these quantities. That is, increasing complexity makes the task of recognizing all of the possible system input/output combinations quite difficult (if not impossible) for a human mind. Hence, the probability of an oversight or error which impacts on critical system function is proportional to system complexity, and software development experience to date suggests that as systems grow increasingly complex, this probability nears unity. In response to this issue, computer-based analytical techniques have been developed to assist in the task of characterizing complex systems. These techniques seem effective in transcending the computational and organizational limitations of the human mind in many cases. However, while computer-based analytical engines might improve performance with respect to organizing and understanding complexity, these engines are ultimately designed and interpreted by the same sorts of agents as they are intended to aid, and hence may not be as accurate as hoped. Recognition of the implications of these observations is apparently difficult for some, perhaps due in part to the lack of clearcut quantifying measures for accuracy (or in this case, security) as a function of code complexity. The fact that one cannot insert the number of added lines of code into an equation to arrive at the conclusion that either a critical bug has or has not been introduced makes it difficult for some to accept the criticality of this issue when designing and implementing secure systems. Nonetheless, given the stakes in scenarios requiring high security, the implications of added complexity must not be ignored. Hence, we should strive to balance the added complexity of the chosen solution with other design goals. 3. Brief Enumeration of Proposed Solutions Kelly Expires Jan 2002 [Page 7] Internet Draft July, 2001 As noted, there are a number of proposed solutions to date. These are as follows: o XAUTH/MODECFG - XAUTH refers to eXtended AUTHentication (within IKE), and is detailed in [XAUTH]. It is tightly bound to another proposal, the ISAKMP configuration method [MODECFG]. o HYBRID - this proposal builds upon the XAUTH/MODECFG combination, adding one-sided server authentication. It is detailed in [HYBRID]. o ULA - ULA refers to User-Level Authentication; this proposal was withdrawn due to various shortcomings, but is included here for the sake of completeness. See [ULA] for additional detail. o CRACK - CRACK stands for Challenge/Response for Authenticated Cryptographic Keys, and is discussed in [CRACK]. o L2TP - L2TP (Layer 2 Tunneling Protocol) uses PPP-based authentication. Use of L2TP with IPsec is discussed in [L2TPSEC]. o PIC - PIC stands for Pre-Ike Credential provisioning protocol, and is discussed in [PIC] o GetCert - GetCert is a shorthand name for "Client Certificate and Key Retrieval for IKE", and is discussed in [GETCERT]. This document provides a (currently very) brief analysis of how each of these stacks up against the remote access user authentication requirements discussed above. 4. Common Features of Proposed Solutions Before looking at the individual proposals, it may be useful to examine some of the issues which multiple proposals have in common. A number of the proposals provide for the use of preshared keys to authenticate an IKE session prior to authenticating the user (XAUTH, ULA, L2TP), and an overlapping subset provides for the use of public key mechanisms for the same purpose. These are discussed below. 4.1 Common Issues for Proposals Supporting Preshared Keys A subset of the proposals (XAUTH/MODECFG, ULA, L2TP) provide the ability to use preshared keys as a part of the authentication process. All of these proposals, when used in this manner, share common issues, which are discussed in section 4.1.1 below. Kelly Expires Jan 2002 [Page 8] Internet Draft July, 2001 In addition, preshared keys may be used in a number of network configurations, including the following: o remote client uses fixed IP address with unique preshared key o remote client uses non-fixed IP address with global preshared key o remote client uses non-fixed IP address with unique preshared key (requires use of IKE aggressive mode) The individual issues associated with these are discussed in sections 4.1.2-4.1.4. 4.1.1 General issues for configurations using preshared keys Preshared keys, when compared to well-managed public/private key pairs, provide a significantly weaker form of authentication for IPsec. Brute force man-in-the-middle attacks on the preshared keys are possible. For example, an adversary might juxtapose himself between the remote user and the security gateway, and attempt to intercept the remote access user's connection attempt with the gateway. If the SGW can be impersonated in this manner by the attacker, the remote access client will provide the attacker with enough information so that the preshared key may be subjected to an offline dictionary attack. Once a preshared key is compromised, additional information regarding the user identity and legacy authentication passphrase is vulnerable, and if the authentication passphrase is compromised, the system has failed entirely: the attacker may impersonate the remote user. This risk may be mitigated by using one-time legacy authentication tokens, but it should be noted that the identity information will still not be protected. Further, if an attacker with MiM capability succeeds in determining the preshared key, he may then launch MiM attacks on subsequent remote access sessions in which he sits transparently in the connection path, impersonating the sgw to the remote user, and impersonating the remote user to the sgw. The implications of this are clear. These risks are not mitigated by using aggressive mode with preshared keys, which is a much more likely scenario for remote access given that the IP address of the remote access user will vary. Furthermore, the attacker need not interact with the data stream in this case, but only needs to observe the exchange. Aggressive mode proceeds as follows: Remote User Security Gateway Kelly Expires Jan 2002 [Page 9] Internet Draft July, 2001 ------------------ ---------------------- HDR, SA, KE, Ni, IDii --> <-- HDR, SA, KE, Nr, IDir, HASH_R HDR, HASH_I --> Note that in this case, the attacker has access to the HASH_R value, along with all relevant inputs, so that a dictionary attack may again be mounted on the preshared key. Also note that in this case the SGW is forced to compute HASH_R prior to verifying the remote user's identity, implying an increased vulnerability to DoS attacks, and if the user (attacker) sends a spurious third message, the SGW must complete the DH exponentiation to detect it. In fact, methods which rely on preshared keys and aggressive mode may be trivially susceptible to DoS attacks due to this vulnerability, in that an attacker has but to construct a valid IDii payload, and this may be used again and again in order to cause the SGW to repeatedly allocate context memory, compute HASH_R, and perhaps compute the DH value. Finally, support for use of preshared keys does scale well, and does not encourage migration to stronger authentication mechanisms, and in fact, may encourage the opposite. Hence, it may be prudent from a security perspective to disallow such support in any proposed solution. Issues specific to particular uses of preshared keys for the various network configurations enumerated in section 4.1 above are discussed in the following sections. 4.1.2 Fixed Address (unique PSK) In the case where the IP address is fixed, IKE main mode may be used with a preshared key. This is an unusual situation for remote access, but it does present the ability to use a unique preshared key for each user, meaning it may be at least as secure as typical site-to- site configurations employing preshared keys. However, preshared keys within main mode are susceptible to attack as noted above, so this may provide a false sense of security. Also, use of per-user preshared keys raises obvious scalability issues as the number of users grows. 4.1.2 Non-fixed Address, Global Preshared Key In some cases, a single preshared key may be used for all remote users. A global preshared key has obvious shortcomings, and must not Kelly Expires Jan 2002 [Page 10] Internet Draft July, 2001 be recommended. Such keys may be compromised in numerous ways without detection, and once this has occurred, eavesdropping and MiM attacks are greatly simplified. This is unacceptable from a security perspective. 4.1.3 Non-fixed Address, Unique Preshared Key Unique preshared keys may be used with non-fixed addresses if IKE aggressive mode is used. However, this method is vulnerable to DoS attacks on the sgw, as the user identity is not protected, and intercepted packets may be replayed, causing the sgw to needlessly engage in hash and exponentiation calculations. This method is also susceptible to dictionary attacks on the preshared key. In addition, per-user keys do not scale as the number of users grows. 4.2 General Issues For Configurations Using Mutual Certificates In general, public key authentication mechanisms are much stronger than shared secret mechanisms. However, there are a number of issues even with these. Due to the overhead associated with authentication operations, there is some unavoidable DoS susceptibility. For example, using IKE main mode, an attacker may cause the SGW to needlessly perform expensive public key and/or Diffie-Hellman operations just to prove that the attacker is not authorized to connect. If aggressive mode is used instead of main mode, the SGW may be forced to generate its own signature without first verifying the identity of the remote user. A sufficient number of such spurious computations will impinge upon the SGW's ability to deliver services to authorized users. Note that these issues exist for site to site installations as well as remote access scenarios, although in site-to-site connections the remote IP address may be used by the SGW as an additional filter, raising the bar somewhat for the attacker. In selecting such a mechanism for remote access, we should strive to not introduce any more vulnerability than already exists in site to site scenarios. A second area of consideration pertains to the storage mechanism for the private key used to authenticate the user. If this key is compromised, the entity it authenticates may be impersonated without detection. Hence, the integrity of the derived authentication is directly proportional to the security of the private key storage technique. If the private key is stored on the hard drive of the subject system, it is vulnerable to a number of attacks, and may be compromised Kelly Expires Jan 2002 [Page 11] Internet Draft July, 2001 without detection. Therefore, the integrity of the resulting authentication in this case is directly proportional to the security of the system in which the hard drive resides. If this system is hardened, physical access is strictly controlled, and system configuration is strictly controlled, the associated level of security may be relatively high. However, if the system is (for example) a laptop containing a commercial operating system, and the user has typical freedoms regarding system usage and configuration, the associated level of security is likely quite low. In such cases, the private key may be compromised without detection in numerous ways, and even if an additional factor of authentication is used (such as a username/passphrase pair) the SGW is subject to increased vulnerability to DoS attacks (the attacker can negotiate multiple phase 1 SAs using the private key). If a post-IKE legacy user authentication mechanism is used, the underlying user authentication mechanism is also subject to attack, which may ultimately expose the protected network(s) and data. These risks may be mitigated if the private key is securely contained (e.g. in a smartcard), and if key usage requires an additional factor of authentication in advance (i,.e. stealing the key container does not necessarily guarantee access). However, it should be recognized that a sufficiently secured private key may also obviate the need for a username-passphrase exchange, unless n-factor authentication is required. So, while public key methods may seem to remedy many of the issues raised by the use of preshared keys, we must be careful to evaluate the relative security of the private keys in such scenarios. Solutions relying on insufficiently secured private keys are correspondingly insecure. 5. Comparing the Proposals 5.1 XAUTH/MODECFG Xauth is a user authentication mechanism which functions by first forming a phase 1 IKE SA using one of the conventional IKE authentication techniques (preshared key or public key), and by then extending the IKE exchange to include additional user authentication exchanges. The xauth payloads ride atop an additional proposed IKE extension (referred to as "modecfg" or "ikecfg") which is essentially a DHCP-like mechanism meant to provide host configuration parameters to remote access clients. Xauth may be deployed in at least five different configurations: Kelly Expires Jan 2002 [Page 12] Internet Draft July, 2001 o main mode using unique preshared keys (fixed IRAC address) o main mode using global preshared key (non-fixed IRAC address) o aggressive mode using unique or global preshared key and keyid o main mode using certificates o aggressive mode using certificates When used with preshared keys, xauth suffers from all of the associated shortcomings discussed above in section 4.1. When used with certificates, either the associated private keys are adequately safeguarded, or they are not. If so, xauth is superfluous, unless n- factor authentication is required. If not, the associated shortcomings are present. Specific xauth issues (in addition to the general issues discussed above) include the following: o Xauth requires the SGW to participate in the user authentication process, which increases SGW vulnerability both in terms of complexity and denial of service. o Adding an open-ended number of challenge-rsp exchanges to a key exchange increases vulnerability to denial of service attack under some circumstances, and absolutely increases the complexity of the key exchange mechanism under all circumstances. While an open-ended exchange may not be entirely avoidable given the n-factor authentication requirement, xauth does not begin such exchanges until a phase 1 IKE SA has been instantiated, and this with either limited or no knowledge of the user identity in several of the supported configurations. The overhead associated with the DH exchange is significant, and the fact that an anonymous peer may force expenditure of this effort implies that a system supporting the associated configuration is trivially susceptible to denial of service. Further, once such phase 1 sessions are established, the SGW may be "led on" by a malicious peer for some (hopefully limited) period of time, guaranteeing that the associated system resources will remain unavailable during this period. o Xauth requires proxy support in the SGW for up to 16 different authentication methods, which greatly increases system complexity. o There may be some known ascii plaintext at fixed locations within packets due to support for user prompts. The amount of text will normally be small, but should not be ignored. If a reusable passphrase is contained within the xauth exchange, an attacker may have significant motivation for breaking the IKE session encryption, and known plaintext will simplify this task. Kelly Expires Jan 2002 [Page 13] Internet Draft July, 2001 o Xauth requires support for its companion, modecfg. This duplicates some of the functionality of DHCP, but lacks support for critical components, implying that it is redundant, and therefore adds unnecessary complexity. However, one has no choice but to implement modecfg if one wishes to implement xauth. 5.2 Hybrid The "Hybrid" authentication mechanism [HYBRID] attempts to address some of the shortcomings of xauth, most notably the need to support global preshared keys when remote access client certificates are not available. The hybrid mechanism modifies the xauth mechanism by requiring the IRAS to authenticate itself using public key techniques, and deferring user authentication until after the phase 1 IKE SA is in place. That is, hybrid requires the IRAS to authenticate to the IRAC, but not vice versa - it is a one-sided authentication. This mechanism is trivially susceptible to DoS attacks, as it requires the IRAS to engage in an unauthenticated Diffie-Hellman exchange which includes an expensive public key operation, and then to continue the conversation for some period of time beyond that, perhaps in error. In addition, all of the specific xauth shortcomings not relating specifically to preshared keys apply equally to hybrid. 5.3 ULA The previously proposed ULA method* [ULA] consists in forming an authenticated phase 1 SA in the same manner as xauth, followed by creation of a phase 2 SA whose sole purpose is to protect the authentication exchange. Following successful authentication, the phase 2 SA is either replaced, or the selectors are modified to permit access to appropriate resources. While this method improves somewhat on xauth by providing the ability to offload the user authentication to an outboard server (reachable through the tunnel), it suffers from many of the same problems as xauth. In particular, this method has the following shortcomings: o if preshared keys are used, this technique suffers from all of the general shortcoming associated with these which were identified above, e.g. vulnerability to MiM, offline dictionary attacks, undetected compromise, lack of scalability, etc. o requires IRAS to create phase 1 and phase 2 SAs without verifying user identity; this has obvious DoS implications, and is also susceptible to attacks on the underlying authentication Kelly Expires Jan 2002 [Page 14] Internet Draft July, 2001 infrastructure. These risks may be mitigated if mutual certificates are used, but as with xauth, either the user's private key is securely stored or not. If so, ULA is superfluous unless n-factor authentication is required, and if not, the associated shortcomings are present. *This proposal was withdrawn due to security issues 5.4 CRACK The CRACK technique [CRACK] integrates the user authentication process into the key exchange negotiation within IKE by defining a new exchange type. The IRAS authenticates using public key techniques, while the user authenticates using an identity and one or more passphrases. The exchange proceeds as follows: Client (I) Gateway (R) ----------- ----------- HDR, SAi, KEi, Ni [, CERTREQ] ---> <--- HDR, SAr, [CERT, ] KEr, SIG1, Nr HDR*, CHRE, PK ---> <--- HDR*, < SIG2 | CHRE > HDR*, < SIG3 | CHRE > ---> For payload definitions, see [CRACK]. This technique limits the denial of service implications for the IRAS when compared to xauth, hybrid, or ula, as the user must authenticate very early in the protocol. However, this method suffers from the following shortcomings: o IRAS must produce signature prior to authenticating user o IRAS must complete DH computation to detect spurious second message from attacker o IRAS must participate in the legacy user authentication process o requires support for an additional IKE exchange type 5.5 L2TP The L2TP user authentication mechanism is very similar to the ULA mechanism, and consists in forming both phase 1 and phase 2 SAs prior to authenticating the user. Hence, it suffers from precisely the same shortcomings as ULA (and by proxy, many of the shortcomings of xauth). However, the L2TP method also completely removes the user authentication from IPsec and moves it into PPP, so that per-user Kelly Expires Jan 2002 [Page 15] Internet Draft July, 2001 network access security must also be managed within the L2TP/PPP subsystem. This has significant implications in terms of increased system complexity. The current proposals for using L2TP with IPsec suggest using a "machine certificate" to authenticate the IKE SA. Note that as with xauth, either the user's private key is securely stored or not. If so, the L2TP user authentication may be superfluous (unless n-factor authentication is required), and if not, the associated shortcomings are present. 5.6 PIC The PIC mechanism provides a method for integrating legacy user authentication with existing IPsec deployments without the need for modifying the underlying IPsec implementations. This is accomplished by authenticating the user outside of the IPsec session proper, and providing the user with a short-lived certificate which may then be used within IKE using currently defined public key authentication mechanisms. The PIC method accomplishes user authentication using an ISAKMP exchange which supports legacy mechanisms, and then provides the user with a private/public keypair and certificate which are used for subsequent authentication operations with the security gateway. While PIC may be terminated by the target security gateway, it may also be terminated by a separate authentication server. The exchange is as follows: Client Authentication Server ------ --------------------------- (1) HDR, SA, KE, Ni --> (2) <-- HDR, SA, KE, Nr, IDir,[CERT,] SIG_R, HASH, [,...] (3) HDR*, HASH, EAP, [EAP...,] --> [CREDENTIAL-REQUEST] (4) <-- HDR*, HASH, EAP, [EAP...,] [CREDENTIAL] Security issues with this method include the following: o if PIC is run on the sgw, the sgw is subject to DoS attacks due the fact that it must generate a signature and compute a DH exponential prior to authenticating the remote access user. Kelly Expires Jan 2002 [Page 16] Internet Draft July, 2001 o separate connections are required for authentication and access; however, this implementation detail may be rendered transparent to the user 5.7 GetCert The GetCert method is a percursor to PIC, having provided the first example of the underlying model: as a result of a non-IPsec user authentication exchange, the user obtains a certificate which is used to authenticate a subsequent IKE session. The primary difference between GetCert and PIC is in the transport. While PIC runs over a new ISAKMP exchange, GetCert is completely independent of IPsec, and runs over a HTTPS/TCP connection. Security issues with this method include the following: o if GetCert is run on the IRAS, the IRAS is subject to DoS attacks due the fact that it must field incoming SSL connections from unauthenticated users o separate connections are required for authentication and access; however, this implementation detail may be rendered transparent to the user. 6. Comparison of Proposals to Requirements All of the proposed mechanisms solve the most basic problem, which is to authenticate remote access users by way of legacy authentication systems. However, they do so in several different ways. The techniques fall into 3 general categories, from a high level: o those which complete IPsec negotiation (phase 1 and/or phase 2 IKE) prior to authenticating the user (XAUTH, HYBRID, ULA, L2TP). o those which integrate the user authentication into IKE phase 1 negotiation (CRACK). o those which move the user interaction outside of IPsec entirely (PIC, GETCERT) Another way to group these is as follows: o those which require the IRAS to participate in the user authentication process (XAUTH, HYBRID, ULA, L2TP, CRACK) Kelly Expires Jan 2002 [Page 17] Internet Draft July, 2001 o those which do not require the IRAS to participate in the user authentication process (PIC, GETCERT) Recalling our goals from section 2, it is appropriate to compare the proposals against each of these at this time. 6.1 Provide direct support for legacy user authentication systems such as RADIUS All proposals meet this goal. 6.2 Encourages migration from existing low-entropy password-based systems to more secure authentication systems Proposals requiring use of public key mechanisms certainly meet this goal, while proposals supporting both preshared keys and public key mechanisms meet it to a lesser extent. PIC, GETCERT, CRACK, and HYBRID all require support for public key mechanisms. If XAUTH, ULA, and L2TP are used with preshared keys, they do not meet this goal. 6.3 If legacy support cannot be provided without some sort of migration, the impact of such migration should be minimized Since all proposals meet 6.1, this is moot. 6.4 User authentication information must be protected against eavesdropping and replay (including the user identity) Proposals requiring the use of aggressive mode do not meet this goal, meaning the preshared key modes of XAUTH, ULA, and L2TP. It might be argued that these mechanisms may use preshared keys with fixed IP addresses (and hence use main mode), but this raises obvious SGW scaling issues, and therefore these cases do not represent likely remote access scenarios. Hence, XAUTH, ULA, and L2TP only meet this goal when used with IKE main mode and public keys. All other proposals meet this goal unconditionally. 6.5 Single sign-on capability should be provided in configurations employing load-balancing and/or redundancy Only proposals which permit the user to instantiate a connection with a redundant IRAS without re-entering user authentication information Kelly Expires Jan 2002 [Page 18] Internet Draft July, 2001 (username, password, etc) meet this goal, i.e. PIC and GetCert. 6.6 N-factor authentication mechanisms should be supported All proposals meet this goal. 6.7 Security gateway vulnerability to DoS attacks should be minimized, and if possible, should not be greater than the vulnerability which exists in SGW systems not providing remote access. Proposals requiring no modification to the underlying IPsec implementation unconditionally meet this goal. The only proposals having this characteristic are PIC and GetCert, when they are run on outboard authentication servers. Proposals requiring modification to the underlying IPsec implementation must be examined more closely. All members of the class of proposals which defer user authentication until after a phase 1 SA has been negotiated (XAUTH, HYBRID, ULA, L2TP) are more vulnerable to DoS attacks than those not sharing this characteristic. CRACK, while not strictly in this class (it authenticates the user *during* phase one), must also be considered with this group due to other similarities. Of these proposals, HYBRID and CRACK are clearly the most vulnerable, since they require the SGW to perform Diffie-Hellman and public key computations for an unauthenticated peer. In the case of the other 3, the DoS implications might be minimized if main mode with (random) preshared key authentication were used for phase 1, but this is not feasible due to scaling issues. Hence, for XAUTH, ULA, and L2TP, main mode with signatures is the only realistic approach. This has a slightly higher DoS risk, but no more so than for other non-remote-access IKE exchanges using public key techniques. However, the validity of this assumption depends upon the security of the private keys used for authenticating the remote access client. As noted previously, if this key is not securely stored, DoS attacks become trivial for a determined adversary. 6.8 The chosen mechanism(s) should minimize any reduction in the baseline security of the underlying IPsec connection Proposals requiring no modification to the underlying IPsec implementation clearly meet this goal. The only proposals having this characteristic are PIC and GetCert (when implemented on outboard authentication servers). Proposals requiring modification to the Kelly Expires Jan 2002 [Page 19] Internet Draft July, 2001 underlying IPsec implementation must be examined more closely. All proposals other than PIC and GetCert modify the underlying IPsec implementation, and so introduce some probability that the security of the underlying implementation (and therefore, that of the connection) has been reduced. The XAUTH, HYBRID, and CRACK approaches all directly modify IKE by adding new states and protocol elements. This certainly increases code complexity, along with the probability of an implementation error. However, this effect is most difficult to quantify. In addition, all approaches other than PIC and GetCert (and perhaps L2TP) require the SGW to act as a proxy in the user authentication protocol. L2TP may avoid this by terminating the L2TP tunnel on a host behind the SGW rather than on the SGW itself, but if this is done, then there must also be some protocol between the L2TP termination point and the SGW which permits access revocation if the user fails to properly authenticate - otherwise, the L2TP server may terminate the connection, but the SGW won't know it - which again adds complexity to the SGW. 7. Summary The various proposals come out on fairly equal footing regarding several of the stated requirements, with differences emerging in the following 3 areas: o increased SGW susceptibility to DoS attacks o increased SGW complexity o single sign-on support These are discussed in more detail below. 7.1 DoS Susceptibility XAUTH, HYBRID, ULA, CRACK, and L2TP are all susceptible to DoS attacks under some circumstances. HYBRID and CRACK are trivially susceptible to DoS attacks. PIC and GetCert only increase the SGW's DoS susceptibility if they are implemented on the SGW. L2TP, ULA, and XAUTH are less susceptible than HYBRID and CRACK if the remote user's private key is securely contained, but only in this case. To the extent that the private key is susceptible to compromise, the DoS risk increases proportionally. As noted earlier, a private key stored on the hard drive of a typical user system would not stand up to a determined adversary. Kelly Expires Jan 2002 [Page 20] Internet Draft July, 2001 While it may be argued that using a smartcard (or other secure container) goes a long way toward resolving this problem, it must be noted that this imposes a significant increase in the cost of the solution, both economically and logistically. In this case, smartcards (or whatever security container is used) must be provided for each remote access user, and these must be managed. And if one is stolen, it may be used for DoS attacks (or worse, unfettered access) until it is discovered missing. An alternative to secure containers is to provide a short-lived key at the time access is desired which is good for a limited time only. The short lifetime of the key significantly narrows the window during which it might be compromised, and if such a key were somehow compromised, the damage potential would be bounded by its lifetime. That is, if the key lifetime is sufficiently short, the only realistic compromise scenario (for DoS purposes) entails gaining control of the system while the key is valid and passing it along to the attacker. However, an attacker with this capability can also gain control of a system relying on a smartcard, and by proxy, full access to the network beyond the SGW - so the smartcard is not much help in this case, and in such a case, DoS attacks should be the least of our concerns. 7.2 Code Complexity XAUTH, HYBRID, ULA, CRACK, and L2TP all significantly increase the complexity of the IRAS code base, while PIC and GetCert need not be implemented on the IRAS. 7.3 Single Sign-on Support XAUTH, HYBRID, ULA, CRACK, and L2TP do not provide for single sign-on support, while GetCert and PIC do (the short-lived certificate may be used to connect to a redundant IRAS). 7.4 Conclusion The only proposals which meet all criteria are GetCert and PIC (when implemented on an outboard authentication server). 8. Security Considerations The topic of this document is secure remote access. Security Kelly Expires Jan 2002 [Page 21] Internet Draft July, 2001 considerations are discussed throughout the document. 9. Editors' Addresses Scott Kelly RedCreek Communications 3900 Newpark Mall Road Newark, CA 94560 USA email: skelly@redcreek.com Telephone: +1 (510) 745-3969 10. References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [KEYWORDS] Bradner, S., "Key Words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [KR01] S. Kelly, S.Ramamoorthi, "Requirements for IPsec Remote Access Scenarios", draft-ietf-ipsra-reqmts-03.txt (work in progress). [XAUTH] Pereira and Beaulieu, "Extended Authentication within ISAKMP/Oakley XAUTH)", draft-ietf-ipsec-isakmp-xauth-06.txt (work in progress). [MODECFG] R Pereira, S. Anand, B. Patel, "The ISAKMP Configuration Method", draft-ietf-ipsec-isakmp-mode-cfg-05.txt (work in progress) [ULA] S. Kelly, J. Knowles, B. Aboba, "User-level Authentication Mechanisms for IPsec", draft-kelly-ipsra-userauth-00.txt, (work in progress) [CRACK] D Harkins, B Korver, D Piper, "IKE Challenge/Response for Authenticated Cryptographic Keys", draft-harkins-ipsec-ike- crack-00.txt (work in progress). [L2TPSEC] B. Patel, B. Aboba, W. Dixon, G. Zorn, S. Booth, "Securing L2TP using IPSEC", draft-ietf-l2tpext-security-02.txt" (work in progress) [PIC] Y. Sheffer, H. Krawczyk, "PIC, A Pre-IKE Credential Provisioning Protocol ", draft-ietf-ipsra-pic-01.txt, (work in progress) Kelly Expires Jan 2002 [Page 22] Internet Draft July, 2001 [GETCERT] Bellovin and Moskowitz, "Client Certificate and Key Retrieval for IKE", draft-bellovin-ipsra-getcert-00.txt (work in progress). 11. Full Copyright Statement Copyright (C) The Internet Society (1998). 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. Kelly Expires Jan 2002 [Page 23] --------------8E2D553262DA1FCF8FFD7DCA-- From owner-ietf-ipsra@mail.vpnc.org Sat Jul 7 04:41:55 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA16824 for ; Sat, 7 Jul 2001 04:41:54 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f67808J19991 for ietf-ipsra-bks; Sat, 7 Jul 2001 01:00:08 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [199.203.73.68]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f67804m19986 for ; Sat, 7 Jul 2001 01:00:04 -0700 (PDT) Received: from mypc (localhost [127.0.0.1]) by michael.checkpoint.com (8.9.3/8.9.1) with SMTP id KAA03746; Sat, 7 Jul 2001 10:59:48 +0300 (IDT) Message-ID: <00c001c106c3$d35cd3b0$255f003e@checkpoint.com> From: "Tamir Zegman" To: "Scott G. Kelly" , References: <3B4502BE.3A7295CD@redcreek.com> Subject: Re: evaluation draft Date: Sat, 7 Jul 2001 11:04:22 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I believe you have missed some important points in your DoS analysis. All proposals are suceptible to DoS as all of them either perform a DH key exchange or perform some kind of RSA operation. It is not important if the machine being DoS is running IKE (as is the case with most proposals) or another protocol (GetCert, PIC?) Your analysis is based on the assumption that RSA private operations (i.e. RSA signatures) are more expensive than RSA public operarions (i.e. RSA verifications). You must note the following: While in practice RSA verification is faster than RSA signature this is NOT the case when you have a DoS attack. While RSA private operations can be accelerated using CRT (as well as by using some precomputation techniques), RSA public operations cannot. An attacker can use a public key with a large exponent with or without a large modulus to mount a DoS attack. Note that in Hybrid the security gateway does not perform any RSA public operation and is therefore better protected even compared to regular IKE with certs! In order to mount a DoS attack in a PIC/GetCert environment: 1. One can mount an attack on the server running PIC/Get cert. 2. One can mount an attack on the server running IKE. Since these IKE servers use RSA signatures to authenticate the clients they are suceptible to a large RSA exponent (or modulus) DoS attack as well as the fact that they are required to perform DH. You have made some remraks that XAUTH has a weakness of known plaintext at fixed locations. I believe that you have raised this issue more than once and more than once have been proven wrong. First, because any crypographic protocol can be argued to have known plaintext in it. Second, because one assumes that the cipher used to protect the exchange is strong enough and if it is not, then all bets are off. I can't understand why you repeat this argument. Tamir. From owner-ietf-ipsra@mail.vpnc.org Sat Jul 7 15:54:00 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22203 for ; Sat, 7 Jul 2001 15:54:00 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f67J93H19817 for ietf-ipsra-bks; Sat, 7 Jul 2001 12:09:03 -0700 (PDT) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f67J92m19813 for ; Sat, 7 Jul 2001 12:09:02 -0700 (PDT) Received: by mail.redcreek.com with Internet Mail Service (5.5.2653.19) id <3G8WXD66>; Sat, 7 Jul 2001 12:09:46 -0700 Received: from redcreek.com (SKELLYLAPTOP [209.125.38.47]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3G8WXD65; Sat, 7 Jul 2001 12:09:35 -0700 From: "Scott G. Kelly" To: Tamir Zegman Cc: ietf-ipsra@vpnc.org Message-ID: <3B475E7D.BA229435@redcreek.com> Date: Sat, 07 Jul 2001 12:09:49 -0700 Organization: RedCreek Communications X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: evaluation draft References: <3B4502BE.3A7295CD@redcreek.com> <00c001c106c3$d35cd3b0$255f003e@checkpoint.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Tamir, Thanks for taking the time to review the draft. Comments interspersed below... Tamir Zegman wrote: > > I believe you have missed some important points in your DoS analysis. As noted in my email, I could easily have spent at least another week on the draft. This is very complex subject matter. My hope in releasing it in its current state is that others will contribute in filling out the draft content (as you are doing here). > All proposals are suceptible to DoS as all of them either perform a DH key > exchange or perform some kind of RSA operation. > It is not important if the machine being DoS is running IKE (as is the case > with most proposals) or another protocol (GetCert, PIC?) The primary point I was making was that in the case of GetCert and PIC, it is not necessarily the SGW which is vulnerable, since either one may be run on a standalone authentication server. I believe this is a significant consideration in comparing these mechanisms. Don't you? > Your analysis is based on the assumption that RSA private operations (i.e. > RSA signatures) are more expensive than RSA public operarions (i.e. RSA > verifications). I'm not sure what made you think I assumed this - please elaborate. > You must note the following: > While in practice RSA verification is faster than RSA signature this is NOT > the case when you have a DoS attack. > While RSA private operations can be accelerated using CRT (as well as by > using some precomputation techniques), RSA public operations cannot. > An attacker can use a public key with a large exponent with or without a > large modulus to mount a DoS attack. > Note that in Hybrid the security gateway does not perform any RSA public > operation and is therefore better protected even compared to regular IKE > with certs! Note that in hybrid the SGW forms (and then uses) an IKE SA with absolutely no assurance regarding the identity of the remote peer. This is *not* better protected from DoS than standard IKE with certs, and also opens other SGW code paths to an attacker which would not otherwise be accessible, assuming the attacker has the resources to easily complete the verification and DH (think DDoS). > In order to mount a DoS attack in a PIC/GetCert environment: > 1. One can mount an attack on the server running PIC/Get cert. Yes, but this need not affect the SGW, whereas with the any of the other proposed mechanisms, it will. > 2. One can mount an attack on the server running IKE. Since these IKE > servers use RSA signatures to authenticate the clients they are suceptible > to a large RSA exponent (or modulus) DoS attack as well as the fact that > they are required to perform DH. I think the baseline measure is this: if an outboard AS is used, is the SGW more vulnerable than it would be for SGW's supporting non-remote access? I don't think you are saying that it is, are you? > You have made some remraks that XAUTH has a weakness of known plaintext at > fixed locations. > I believe that you have raised this issue more than once and more than once > have been proven wrong. This was a very minor point, and it makes little sense to expend much energy on it. However, I raised it once in the past (in the ULA draft), and it has never been proven wrong. When I raised the issue in the ULA draft, I believed that there was more plaintext than there actually is (I thought the "USERNAME=" and "PASSWORD=" values in the draft were literal strings, rather than TLV tokens). When I discovered my error, I acknowledged this and backed down somewhat from my original statements, noting that the remaining plaintext was certainly less of a concern. In the current draft, I try to make the point that the amount of plaintext may be small, and so should be considered in that light. Nonetheless, it should not be ignored - especially when it could minimized (or eliminated) by simply standardizing prompts, using tokens instead, and mixing payload ordering. > First, because any crypographic protocol can be argued to have known > plaintext in it. Nonetheless, we generally strive to limit (or eliminate) known plaintext whenever possible, and this is good practice. > Second, because one assumes that the cipher used to protect the exchange is > strong enough and if it is not, then all bets are off. > I can't understand why you repeat this argument. I am not a cryptographer. However, I think that we should never assume that a cipher is unbreakable, and that known plaintext (and other things which may provide an adversary with an advantage, however slight) should be avoided whenever possible. I've never heard a cryptographer argue otherwise. The bottom line: this is a very minor issue which could be easily corrected by modifying xauth. I did not mean to detract from the larger issues by including this, but even if it is a small consideration, it should not be ignored. Scott From owner-ietf-ipsra@mail.vpnc.org Sun Jul 8 04:27:40 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA05425 for ; Sun, 8 Jul 2001 04:27:40 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f687oG017324 for ietf-ipsra-bks; Sun, 8 Jul 2001 00:50:16 -0700 (PDT) Received: from ns02.newbridge.com (ns02.newbridge.com [192.75.23.75]) by above.proper.com (8.11.3/8.11.3) with SMTP id f687oFm17311 for ; Sun, 8 Jul 2001 00:50:15 -0700 (PDT) Received: (qmail 4029 invoked from network); 8 Jul 2001 07:48:20 -0000 Received: from portal1.newbridge.com (HELO kanata-mh1.ca.newbridge.com) (192.75.23.76) by ns02.newbridge.com with SMTP; 8 Jul 2001 07:48:20 -0000 Received: from kanmail02.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for ietf-ipsra@vpnc.org; Sun, 8 Jul 2001 03:46:25 -0400 Received: from andrewk3 ([138.120.49.124]) by kanmail02.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA5C43 for ; Sun, 8 Jul 2001 03:46:23 -0400 Reply-To: From: "Andrew Krywaniuk" To: Subject: RE: Protocol Action: DHCPv4 Configuration of IPSEC Tunnel Mode toProposed Standard Date: Sun, 8 Jul 2001 01:19:50 -0400 Message-Id: <000701c10781$36efdef0$1e72788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 In-Reply-To: <200107051423.KAA14187@ietf.org> Importance: Normal Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Working Group Summary > > The competitor to this protocol, IKECFG, has been largely > dismissed by > both the IPSEC and IPSRA working groups. There was no > significant dissent > during the LAST CALL period. The document outlines why it > is a more > appropriate solution than IKECFG. You know, I'm not going to disagree with this draft going to proposed standard, but I find it kind of sad that the WG summary had to have quite this much spin on it. Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of The IESG > Sent: Thursday, July 05, 2001 10:24 AM > To: IETF-Announce:; > Cc: RFC Editor; Internet Architecture Board; ipsec@lists.tislabs.com > Subject: Protocol Action: DHCPv4 Configuration of IPSEC Tunnel Mode > toProposed Standard > > > > > The IESG has approved the Internet-Draft 'DHCPv4 > Configuration of IPSEC > Tunnel Mode' as a Proposed Standard. > This document is the product of the IPSEC Remote Access > (IPSRA) Working > Group. The IESG contact persons are Jeffrey Schiller and Marcus > Leech. > > > Technical Summary > > This protocol provides a mechanism for IPSEC tunnel > configuration using > the existing DHCP, IKE and IPSEC protocols. It defines a new HTYPE > for IPSEC virtual interfaces, and describes the steps > necessary to make > DHCP work correctly and securely for IPSEC tunnel configuration. > > Working Group Summary > > The competitor to this protocol, IKECFG, has been largely > dismissed by > both the IPSEC and IPSRA working groups. There was no > significant dissent > during the LAST CALL period. The document outlines why it > is a more > appropriate solution than IKECFG. > > Protocol Quality > > This document was reviewed by Marcus Leech. At least two > implementations > are known to exist. > > > From owner-ietf-ipsra@mail.vpnc.org Sun Jul 8 04:27:44 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA05444 for ; Sun, 8 Jul 2001 04:27:44 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f687oMA17348 for ietf-ipsra-bks; Sun, 8 Jul 2001 00:50:22 -0700 (PDT) Received: from ns02.newbridge.com (ns02.newbridge.com [192.75.23.75]) by above.proper.com (8.11.3/8.11.3) with SMTP id f687oFm17309 for ; Sun, 8 Jul 2001 00:50:15 -0700 (PDT) Received: (qmail 4034 invoked from network); 8 Jul 2001 07:48:20 -0000 Received: from portal1.newbridge.com (HELO kanata-mh1.ca.newbridge.com) (192.75.23.76) by ns02.newbridge.com with SMTP; 8 Jul 2001 07:48:20 -0000 Received: from kanmail02.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for ietf-ipsra@vpnc.org; Sun, 8 Jul 2001 03:46:31 -0400 Received: from andrewk3 ([138.120.49.124]) by kanmail02.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA5C47; Sun, 8 Jul 2001 03:46:29 -0400 Reply-To: From: "Andrew Krywaniuk" To: "'Scott G. Kelly'" , "'Tamir Zegman'" Cc: Subject: RE: evaluation draft Date: Sun, 8 Jul 2001 03:39:19 -0400 Message-Id: <000801c10781$39de2540$1e72788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 In-Reply-To: <3B475E7D.BA229435@redcreek.com> Importance: Normal Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Scott, 90% of your draft could be summarized down to the simple fact that IKE is vulnerable to some kinds of DoS. The draft acknowledges that DoS attacks are in fact possible with any of the proposed authentication methods, but it is organized in such a way as to sensationalize the DoS attacks against some modes while downplaying the attacks against others. I personally consider DoS protection to be a very important feature of an encryption protocol. However, I have noticed that DoS vulnerability tends to be trivialized during actual protocol design, but it is routinely trotted out whenever someone scrapes the bottom of the evidence barrel. The fact is that IKE is vulnerable to DoS, period. Main mode forces the initiator to at least be sending packets from a routeable address, but that's about the extent of the DoS protection. Unless you are using some kind of DoS avoidance strategy that is not mentioned in the RFCs, an attacker can sit there and make you compute Diffie-Hellman keys to his heart's content. Of course, the attacker could also make you do a signature verification in addition to computing the DH secret, but why would he do this? What makes the DH attack more devestating is the fact that the attacker doesn't even have to use real DH values. He can just send you a bunch of random data and let you try to decrypt it. If he wanted to make you verify a signature, he would have to generate a properly formed message, which involves doing the DH calculation himself; that gives the attacker a much less attractive work factor. So yes, user authentication might open up new vulnerabilities that weren't previously available (in the sense that an anonymous user can force the server to do DH, PK, *and* legacy operations before the intrusion is detected), but these attacks are far less severe than the attacks that already were previously available. You might also ask yourself which is more DoS resistant: 1 dedicated gateway doing only Main Mode + 1 dedicated server doing only user auth, or 2 load-sharing gateways doing both Main Mode & user auth... > > You have made some remraks that XAUTH has a weakness of > known plaintext at > > fixed locations. > > I believe that you have raised this issue more than once > and more than once > > have been proven wrong. > > This was a very minor point, and it makes little sense to expend much > energy on it. However, I raised it once in the past (in the > ULA draft), > and it has never been proven wrong. Or rather, you have consistently ignored the proof that you were wrong. Last I heard, it has also "never been proven" that the moon landing wasn't faked or that the earth is more than 5,000 years old. If it is such a minor point then why do you bring it up every time you go off on one of your tirades about ModeCfg/XAuth/Hybrid? You consistently repeat the opinion that Hybrid has "serious security issues" yet you are unwilling to make any clear statement of what these issues are. The few points you do bring up are easily refuted. Being vague and non-commital may seem to be a good arguing strategy, but I think you misjudge the ability of the people on this list to see through you. Your claim that IKE requires implementations to accept payloads in any order for the purpose of thwarting known plaintext attacks just doesn't hold water. Most IKE messages only contain 2-3 payloads and they are of predictable length, so the number of possible permutations is small. Someone already pointed out to you a couple of years ago that the certificate payload already contains a huge block of known plaintext. The fact is that IKE is not designed to be used with ciphers that are vulnerable to known plaintext attacks. If we wanted to use that kind of weak cipher, then we wouldn't be using CBC mode; instead, we would probably use a mode of operation with infinite error propagation. And BTW, even ignoring the fact that the whole premise of your argument is wrong, XAuth allows attributes to be sent in any order anyway, so your specious premise refutes your specious argument. Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. From owner-ietf-ipsra@mail.vpnc.org Mon Jul 9 00:51:50 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA20977 for ; Mon, 9 Jul 2001 00:51:49 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6947Zr12748 for ietf-ipsra-bks; Sun, 8 Jul 2001 21:07:35 -0700 (PDT) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6947Xm12742 for ; Sun, 8 Jul 2001 21:07:33 -0700 (PDT) Received: by mail.redcreek.com with Internet Mail Service (5.5.2653.19) id <3G8WX1WA>; Sun, 8 Jul 2001 21:08:19 -0700 Received: from redcreek.com (SKELLYLAPTOP [209.125.38.47]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3G8WX1V0; Sun, 8 Jul 2001 21:08:10 -0700 From: "Scott G. Kelly" To: andrew.krywaniuk@alcatel.com Cc: "'Tamir Zegman'" , ietf-ipsra@vpnc.org Message-ID: <3B492E38.49D8B48B@redcreek.com> Date: Sun, 08 Jul 2001 21:08:24 -0700 Organization: RedCreek Communications X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: evaluation draft References: <000801c10781$39de2540$1e72788a@andrewk3.ca.newbridge.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Andrew, Unfortunately, I've growing quite accustomed to your use of personal attacks as a substitute for well-reasoned discussion, and while it is very difficult, I will nonetheless refrain from responding in kind. I won't respond to everything in your post, but I will address a few things. If anyone else reading this needs more context, I suggest you read the draft which I posted earlier in this thread. First, I'll remove the known plaintext discussion from the draft, for the following reasons: - I have commented both in the draft and in emails that it is a very minor issue - it is clearly a lightning rod which is detracting from more substantive issues - if xauth (hybrid) were to become a serious contender in ipsra, it could be easily remedied at that time Other comments interspersed below. Andrew Krywaniuk wrote: > 90% of your draft could be summarized down to the simple fact that IKE is > vulnerable to some kinds of DoS. The draft acknowledges that DoS attacks are > in fact possible with any of the proposed authentication methods, but it is > organized in such a way as to sensationalize the DoS attacks against some > modes while downplaying the attacks against others. This is a very myopic summary, and you've clearly overlooked some significant points. I suggest that you give it a thorough, objective reading, and then spend some time really thinking this through. There is IKE, and then there is IKE + . What the draft attempts to discuss in detail are the additional vulnerabilities that result (over and above those found in plain vanilla IKE) when you add various things on. DoS vulnerabilities aren't the only things considered. > I personally consider DoS protection to be a very important feature of an > encryption protocol. However, I have noticed that DoS vulnerability tends to > be trivialized during actual protocol design, but it is routinely trotted > out whenever someone scrapes the bottom of the evidence barrel. In case you haven't noticed, I am not trivializing it during *this* actual protocol design, but apparently you are. Regarding the various vulnerabilities in IKE, perhaps some of them could be improved upon during the son of IKE work. However, son of IKE won't be able to undo whatever we do here, so we had better mind our own shop in the meantime. > So yes, user authentication might open up new vulnerabilities that weren't > previously available (in the sense that an anonymous user can force the > server to do DH, PK, *and* legacy operations before the intrusion is > detected), but these attacks are far less severe than the attacks that > already were previously available. Again, read the draft - and then think about it. I am certainly open to discussion on these points. I think Tamir made some good points in his email yesterday regarding relative DoS vulnerability of hybrid vs plain old ike, and I think we should review them. The whole point of the draft is to stimulate such discussion, and (until now) nobody has actually captured all of the issues in writing. On the other hand, I think that asserting that "these attacks are far less severe than the attacks that already were previously available" is naive. > If it is such a minor point then why do you bring it up every time you go > off on one of your tirades about ModeCfg/XAuth/Hybrid? You consistently > repeat the opinion that Hybrid has "serious security issues" yet you are > unwilling to make any clear statement of what these issues are. The few > points you do bring up are easily refuted. Being vague and non-commital may > seem to be a good arguing strategy, but I think you misjudge the ability of > the people on this list to see through you. Again, read the draft - it makes very clear statements about what the issues are. Personal attacks and mischaracterizations are poor substitutes for cogent, well-reasoned arguments. If you can present a persuasive, non-emotional argument as to why xauth or hybrid or xxx is a better solution than the other proposals, please do so immediately. We have already wasted far too much time here, and we need to get our work done. Scott From owner-ietf-ipsra@mail.vpnc.org Mon Jul 9 04:52:23 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07844 for ; Mon, 9 Jul 2001 04:52:22 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f698GIC06271 for ietf-ipsra-bks; Mon, 9 Jul 2001 01:16:18 -0700 (PDT) Received: from ns02.newbridge.com (ns02.newbridge.com [192.75.23.75]) by above.proper.com (8.11.3/8.11.3) with SMTP id f698GHm06267 for ; Mon, 9 Jul 2001 01:16:17 -0700 (PDT) Received: (qmail 5783 invoked from network); 9 Jul 2001 08:14:13 -0000 Received: from portal1.newbridge.com (HELO kanata-mh1.ca.newbridge.com) (192.75.23.76) by ns02.newbridge.com with SMTP; 9 Jul 2001 08:14:13 -0000 Received: from kanmail02.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for ietf-ipsra@vpnc.org; Mon, 9 Jul 2001 04:14:47 -0400 Received: from andrewk3 ([138.120.49.159]) by kanmail02.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAAC79; Mon, 9 Jul 2001 04:14:45 -0400 Reply-To: From: "Andrew Krywaniuk" To: "'Scott G. Kelly'" Cc: Subject: RE: evaluation draft Date: Mon, 9 Jul 2001 04:04:09 -0400 Message-Id: <000d01c1084e$56483a90$1e72788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 In-Reply-To: <3B492E38.49D8B48B@redcreek.com> Importance: Normal Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > First, I'll remove the known plaintext discussion from the draft, for > the following reasons: > > - I have commented both in the draft and in emails that it is a very > minor issue > - it is clearly a lightning rod which is detracting from more > substantive issues > - if xauth (hybrid) were to become a serious contender in ipsra, it > could be easily remedied at that time I would rather you removed it for the reason that the problem is not a problem. > > I personally consider DoS protection to be a very important > feature of an > > encryption protocol. However, I have noticed that DoS > vulnerability tends to > > be trivialized during actual protocol design, but it is > routinely trotted > > out whenever someone scrapes the bottom of the evidence barrel. > > In case you haven't noticed, I am not trivializing it during *this* > actual protocol design, but apparently you are. > > Regarding the various vulnerabilities in IKE, perhaps some of them > could be improved upon during the son of IKE work. However, son of IKE > won't be able to undo whatever we do here, so we had better > mind our own > shop in the meantime. Any of the possible amendments to IKE to deal with DoS, from base mode to client puzzles to stateless cookies, would have a direct impact on the IPSRA solution. If you fix the problem at the root, it will not exist at the branches. > > You > consistently > > repeat the opinion that Hybrid has "serious security > issues" yet you are > > unwilling to make any clear statement of what these issues > are. The few > > points you do bring up are easily refuted. > > Again, read the draft - it makes very clear statements about what the > issues are. Here is what it says in the draft: This mechanism is trivially susceptible to DoS attacks, as it requires the IRAS to engage in an unauthenticated Diffie-Hellman exchange which includes an expensive public key operation, a) I explained in the last e-mail how plain old IKE has the exact same vulnerability. and then to continue the conversation for some period of time beyond that, perhaps in error. b) This is not a serious vulnerability, and it is common to all such protocols. If you move the user authentication to a dedicated server then yes, this DoS attack is moved to the IRAS. I explain in (d) why that is not significant. In addition, all of the specific xauth shortcomings not relating specifically to preshared keys apply equally to hybrid. Copied from draft: Specific xauth issues (in addition to the general issues discussed above) include the following: o Xauth requires the SGW to participate in the user authentication process, which increases SGW vulnerability both in terms of complexity c) Arguments which state that X is complex are easy to make and impossible to disprove. and denial of service. d) If you discount the fact that moving the user authentication to a dedicated IRAS requires the purchase of new hardware... and this money could have alternately been spent on a load-sharing second gateway, which would have helped handle the DoS. o Adding an open-ended number of challenge-rsp exchanges to a key exchange increases vulnerability to denial of service attack under some circumstances, and absolutely increases the complexity of the key exchange mechanism under all circumstances. While an open-ended exchange may not be entirely avoidable given the n-factor authentication requirement, xauth does not begin such exchanges until a phase 1 IKE SA has been instantiated, and this with either limited or no knowledge of the user identity in several of the supported configurations. The overhead associated with the DH exchange is significant, and the fact that an anonymous peer may force expenditure of this effort implies that a system supporting the associated configuration is trivially susceptible to denial of service. Further, once such phase 1 sessions are established, the SGW may be "led on" by a malicious peer for some (hopefully limited) period of time, guaranteeing that the associated system resources will remain unavailable during this period. e) see all of a, b, c, and d. o Xauth requires proxy support in the SGW for up to 16 different authentication methods, which greatly increases system complexity. f) the key phrase here is "up to" o There may be some known ascii plaintext at fixed locations within packets due to support for user prompts. The amount of text will normally be small, but should not be ignored. g) Both IKE and ESP have significant amounts of known plaintext (think tunneled IP header). This is an assumption in the protocol design, as I explained yesterday. If a reusable passphrase is contained within the xauth exchange, an attacker may have significant motivation for breaking the IKE session encryption, h) the draft states that CHAP is preferable to PAP in general. and known plaintext will simplify this task. i) Try rekeying more often. Last I heard, known plaintext attacks required 2^(big number) of code blocks. o Xauth requires support for its companion, modecfg. This duplicates some of the functionality of DHCP, but lacks support for critical components, implying that it is redundant, and therefore adds unnecessary complexity. However, one has no choice but to implement modecfg if one wishes to implement xauth. j) XAuth only uses a small part of the modecfg draft. It is not "tightly bound" as you have stated previously. It would be easy to move that part out into a separate draft, as I in fact did in the Attribute Exchange draft. None of these are new arguments. I have pointed out all of the above many times over the course of the last 2 years. > If you can present a persuasive, > non-emotional argument as to why xauth or hybrid or xxx is a better > solution than the other proposals, please do so immediately. We have > already wasted far too much time here, and we need to get our > work done. I'm not trying to convince you that xauth or hybrid is a better solution than GetCert/PIC. I am merely asking that you stop publicly making incorrect claims about vulnerabilities in these protocols so I can stop having to refute them. You go ahead and write your little drafts about whatever you want, and as long as you stop writing about non-existant security flaws in other people's protocols, I won't give you any trouble. Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. From owner-ietf-ipsra@mail.vpnc.org Mon Jul 9 07:42:30 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09883 for ; Mon, 9 Jul 2001 07:42:29 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f69B7a212285 for ietf-ipsra-bks; Mon, 9 Jul 2001 04:07:36 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f69B7Xm12281 for ; Mon, 9 Jul 2001 04:07:34 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09045; Mon, 9 Jul 2001 07:06:45 -0400 (EDT) Message-Id: <200107091106.HAA09045@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ietf-ipsra@vpnc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-kelly-ipsra-eval-00.txt Date: Mon, 09 Jul 2001 07:06:45 -0400 Sender: owner-ietf-ipsra@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. Title : Comparing Proposed Solutions for IPsec Remote Access Legacy User Authentication Author(s) : S. Kelly Filename : draft-kelly-ipsra-eval-00.txt Pages : 23 Date : 06-Jul-01 A number of competing methods for integrating legacy remote access user authentication into IPsec have been proposed, resulting in confusion as to which method(s) might be best for solving the problems at hand. This document briefly compares these proposals in an effort to clarify the relative standing of each with respect to the problem space and requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kelly-ipsra-eval-00.txt 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-kelly-ipsra-eval-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-kelly-ipsra-eval-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: <20010706135111.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kelly-ipsra-eval-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-kelly-ipsra-eval-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010706135111.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ipsra@mail.vpnc.org Mon Jul 9 11:02:20 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17195 for ; Mon, 9 Jul 2001 11:02:18 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f69EHDc15601 for ietf-ipsra-bks; Mon, 9 Jul 2001 07:17:13 -0700 (PDT) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f69EHBm15597 for ; Mon, 9 Jul 2001 07:17:12 -0700 (PDT) Received: by mail.redcreek.com with Internet Mail Service (5.5.2653.19) id <3G8WXFGC>; Mon, 9 Jul 2001 07:17:55 -0700 Received: from redcreek.com (SKELLYLAPTOP [209.125.38.47]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3G8WXFGB; Mon, 9 Jul 2001 07:17:41 -0700 From: "Scott G. Kelly" To: andrew.krywaniuk@alcatel.com Cc: ietf-ipsra@vpnc.org Message-ID: <3B49BD0D.38C97136@redcreek.com> Date: Mon, 09 Jul 2001 07:17:49 -0700 Organization: RedCreek Communications X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: evaluation draft References: <000d01c1084e$56483a90$1e72788a@andrewk3.ca.newbridge.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Andrew Krywaniuk wrote: > > Regarding the various vulnerabilities in IKE, perhaps some of them > > could be improved upon during the son of IKE work. However, son of IKE > > won't be able to undo whatever we do here, so we had better > > mind our own > > shop in the meantime. > > Any of the possible amendments to IKE to deal with DoS, from base mode to > client puzzles to stateless cookies, would have a direct impact on the IPSRA > solution. If you fix the problem at the root, it will not exist at the > branches. Exactly how would any of these "ammendments" impact on the fact that hybrid requires the gateway to support *unauthenticated* incoming connections from anyone? And what effect would they have on any ipsra solution which uses some weak form of authentication to get through ike so that the "real" authtentication, consisting of username/pwd, can proceed? > > > You > > consistently > > > repeat the opinion that Hybrid has "serious security > > issues" yet you are > > > unwilling to make any clear statement of what these issues > > are. The few > > > points you do bring up are easily refuted. > > > > Again, read the draft - it makes very clear statements about what the > > issues are. > > Here is what it says in the draft: > > This mechanism is trivially susceptible to DoS attacks, as it > requires the IRAS to engage in an unauthenticated Diffie-Hellman > exchange which includes an expensive public key operation, > > a) I explained in the last e-mail how plain old IKE has the exact same > vulnerability. Er... you mean plain old IKE will form an unauthenticated session (actually, an indeterminate number of them) and then use it (them) for some undefined period of time while the anonymous entity at the other end feeds who knows what down the pipe? Care to elaborate? > and then > to continue the conversation for some period of time beyond that, > perhaps in error. > > b) This is not a serious vulnerability, and it is common to all such > protocols. If you move the user authentication to a dedicated server then > yes, this DoS attack is moved to the IRAS. I explain in (d) why that is not > significant. Your "explanation" in (d) is that I should put another gateway with the same problem next to the first one to resolve this. This ups the ante a bit, but does not change the fact that, for many of the proposed mechansims, an attack on the user authentication system is an attack on the security gateway (and all users with established sessions). This should not be ignored, especially given that some of the proposed mechanisms do not have this problem. Are you trying to argue that this is not an important distinction? > In addition, all of the specific xauth > shortcomings not relating specifically to preshared keys apply > equally to hybrid. I'll look at the draft text to see if this should be clarified somehow. > Copied from draft: > > Specific xauth issues (in addition to the general issues discussed > above) include the following: > > o Xauth requires the SGW to participate in the user authentication > process, which increases SGW vulnerability both in terms of > complexity > > c) Arguments which state that X is complex are easy to make and impossible > to disprove. The same could be said for arguments which state that you clearly don't understand this issue. You have added nothing to the discussion here. > and denial of service. > > d) If you discount the fact that moving the user authentication to a > dedicated IRAS requires the purchase of new hardware... and this money could > have alternately been spent on a load-sharing second gateway, which would > have helped handle the DoS. Not positive, but I think you said something like, if I discount the fact that ... requires purchase of new hardware, ... I could spend this money on some *other* new hardware instead. Huh? > > o Xauth requires proxy support in the SGW for up to 16 different > authentication methods, which greatly increases system > complexity. > > f) the key phrase here is "up to" The key phrase here is "why?" > o There may be some known ascii plaintext at fixed locations within > packets due to support for user prompts. The amount of text will > normally be small, but should not be ignored. > > g) Both IKE and ESP have significant amounts of known plaintext (think > tunneled IP header). This is an assumption in the protocol design, as I > explained yesterday. Use of PFS and identity protection make a significant difference here, greatly reducing the (probable) known plaintext. Using tokens instead of arbitrary text phrases in xauth would accomplish the same thing. Good cryptographic protocol design includes effort to minimize known plaintext. This is a very simple change. This is the last I'll say on this topic, given earlier comments. > If a reusable > passphrase is contained within the xauth exchange, an attacker > may have significant motivation for breaking the IKE session > encryption, > > h) the draft states that CHAP is preferable to PAP in general. While the draft *could* make this statement, that is a very liberal (inaccurate) interpretation of what it actually says. As an aside, aren't the MD5 hash of a passphrase and the corresponding challenge susceptible to a dictionary attack? > j) XAuth only uses a small part of the modecfg draft. It is not "tightly > bound" as you have stated previously. It would be easy to move that part out > into a separate draft, as I in fact did in the Attribute Exchange draft. As defined, it requires modecfg; hence, it is tightly bound to modecfg. Which draft the modecfg mechanism is defined in is not the issue. If you believe this is simply remedied, why waste words here? > None of these are new arguments. I have pointed out all of the above many > times over the course of the last 2 years. You haven't convincingly argued anything here. You seem to make this very personal. I am open to modifying my views when calmly reasoned (and substantial) arguments are presented, but your numerous personal attacks have not been persuasive. > > If you can present a persuasive, > > non-emotional argument as to why xauth or hybrid or xxx is a better > > solution than the other proposals, please do so immediately. We have > > already wasted far too much time here, and we need to get our > > work done. > > I'm not trying to convince you that xauth or hybrid is a better solution > than GetCert/PIC. I am merely asking that you stop publicly making incorrect > claims about vulnerabilities in these protocols so I can stop having to > refute them. You go ahead and write your little drafts about whatever you > want, and as long as you stop writing about non-existant security flaws in > other people's protocols, I won't give you any trouble. ...go ahead and write my little drafts? I guess that last paragraph wasn't clear. Trying again: If you can present a persuasive, non-emotional argument as to why xauth or hybrid or xxx is a better solution than the other proposals, please do so immediately. We have already wasted far too much time here, and we need to get our work done. Scott From owner-ietf-ipsra@mail.vpnc.org Mon Jul 9 16:25:55 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA27906 for ; Mon, 9 Jul 2001 16:25:54 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f69Jkhb26957 for ietf-ipsra-bks; Mon, 9 Jul 2001 12:46:43 -0700 (PDT) Received: from relay2.nai.com (relay2.nai.com [161.69.3.67]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f69Jkgm26953 for ; Mon, 9 Jul 2001 12:46:42 -0700 (PDT) Received: from scwsout1.nai.com (undef-3-73.nai.com [161.69.3.73] (may be forged)) by relay2.nai.com (8.9.3/8.9.3) with SMTP id OAA29921 for ; Mon, 9 Jul 2001 14:46:39 -0500 (CDT) Received: FROM ca-ex-bridge1.nai.com BY scwsout1.nai.com ; Mon Jul 09 12:44:13 2001 -0700 Received: by SNC-5-23.nai.com with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Jul 2001 12:46:12 -0700 Message-ID: <8894CA1F87A5D411BD24009027EE78381281AF@md-exchange1.nai.com> From: "Mason, David" To: ietf-ipsra@vpnc.org Subject: RE: evaluation draft Date: Mon, 9 Jul 2001 12:45:26 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Someone has already pointed out that PIC is basically the same as Hybrid (minus the ability to do a Quick Mode) so I think most of the arguments about which is better seems like a lot of hot air. Some of my hot air: The big advantage to PIC is that hopefully the PKI vendors will enable it to issue long term credentials in an automated fashion thereby alleviating the logistic headache of initial certificate deployment to a large user base. The use of EAP is a nice touch. Since two-factor requirements will exist even after a fully deployed PKI is available, security gateways will likely provide that support to avoid requiring the customer to have a separate AS. A security gateway that has to provide Legacy Auth support (act as the AS) will likely prefer Hybrid (not much reason to duplicate all that code, avoids public/private key pair generation the results of which will be thrown away shortly, avoids extra communication rounds). The users of palm devices will prefer Hybrid since the device will only have to do one public key verification (I'm afraid PIC followed by IKE Signature will be painfully slow on a palm device). -dave From owner-ietf-ipsra@mail.vpnc.org Mon Jul 9 18:14:07 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29787 for ; Mon, 9 Jul 2001 18:14:06 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f69LhdD00237 for ietf-ipsra-bks; Mon, 9 Jul 2001 14:43:39 -0700 (PDT) Received: from beach.sctc.com (beach.sctc.com [192.55.214.50]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f69Lhcm00232 for ; Mon, 9 Jul 2001 14:43:38 -0700 (PDT) Received: from beach.sctc.com (root@localhost) by beach.sctc.com with ESMTP id f69LNHp21668; Mon, 9 Jul 2001 16:23:17 -0500 (CDT) Received: from sphinx.sctc.com (sphinx.sctc.com [172.17.192.3]) by beach.sctc.com with ESMTP id f69LNGm21664; Mon, 9 Jul 2001 16:23:16 -0500 (CDT) Received: from gandalf.sctc.com (gandalf.sctc.com [172.17.192.103]) by sphinx.sctc.com (8.8.8+Sun/8.7.3) with ESMTP id QAA05194; Mon, 9 Jul 2001 16:43:34 -0500 (CDT) Received: from localhost (allison@localhost) by gandalf.sctc.com (8.9.3+Sun/) with ESMTP id QAA23332; Mon, 9 Jul 2001 16:43:36 -0500 (CDT) Date: Mon, 9 Jul 2001 16:43:35 -0500 (CDT) From: Tylor Allison X-X-Sender: To: "Scott G. Kelly" cc: , Subject: Re: evaluation draft In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Scott, I've read through the draft and have some comments. I'll try to be as objective as I can, but I'll state up front that I strongly believe that PIC/GetCert are the wrong solution to the Legacy Remote Access problem. To know where I am coming from... We have implemented/fielded XAUTH. Is this the best solution? Maybe not, but it was the best fit at the time. The biggest problem I have with PIC/GetCert is that they don't provide the most straight-forward solution to the Legacy Remote Access problem. To reiterate your definition of the problem: Customers want to use legacy authentication mechanisms with the IPSec deployments. Now how does IPSec currently handle remote peer authentication? IKE. But as you state, IKE currently only supports symmetric authentication mechanisms, and this does not fit wth the legacy authentication methods. The simplest most straight-forward solution then? Fix IKE to support the legacy authentication mechanisms, not try to work around the current IKE limitations by defining new protocols to bootstrap IKE. Yes this means modifying IKE and yes this means adding more complexity to IKE. I'll try to provide some more detailed arguments in response to your draft in my comments interspersed below... On Thu, 5 Jul 2001, Scott G. Kelly wrote: > 5.1 XAUTH/MODECFG [TA] Summarized other XAUTH concerns... o Xauth leverages existing IKE phase 1 exchange and is susceptable to current IKE phase 1 attacks. True, global pre-shared keys with XAUTH introduces some security concerns. > o Xauth requires the SGW to participate in the user authentication > process, which increases SGW vulnerability both in terms of > complexity and denial of service. [TA] I don't believe this matters... the complexity issue exists for all solutions (see below), and I don't believe the DoS attack is any worse than what currently exists (again, see reasoning below). > o Adding an open-ended number of challenge-rsp exchanges to a key > exchange increases vulnerability to denial of service attack > under some circumstances, and absolutely increases the complexity > of the key exchange mechanism under all circumstances. While an > open-ended exchange may not be entirely avoidable given the > n-factor authentication requirement, xauth does not begin such > exchanges until a phase 1 IKE SA has been instantiated, and this > with either limited or no knowledge of the user identity in > several of the supported configurations. The overhead associated > with the DH exchange is significant, and the fact that an > anonymous peer may force expenditure of this effort implies that > a system supporting the associated configuration is trivially > susceptible to denial of service. Further, once such phase 1 > sessions are established, the SGW may be "led on" by a malicious > peer for some (hopefully limited) period of time, guaranteeing > that the associated system resources will remain unavailable > during this period. [TA] Same argument which I'll defer to below. > o Xauth requires proxy support in the SGW for up to 16 different > authentication methods, which greatly increases system > complexity. > o There may be some known ascii plaintext at fixed locations within > packets due to support for user prompts. The amount of text will > normally be small, but should not be ignored. If a reusable > passphrase is contained within the xauth exchange, an attacker > may have significant motivation for breaking the IKE session > encryption, and known plaintext will simplify this task. [TA] - already discussed to death... > o Xauth requires support for its companion, modecfg. This > duplicates some of the functionality of DHCP, but lacks support > for critical components, implying that it is redundant, and > therefore adds unnecessary complexity. However, one has no choice > but to implement modecfg if one wishes to implement xauth. [TA] This is not true. XAUTH and Mode-Config are two exchanges which share the same payloads and exchange number. One does not have to implement mode-config functionality to implement XAUTH. > 5.2 Hybrid [TA] - summarized... o susceptable to DoS attacks because of one-way authentication of phase 1 SA (prior to legacy exchange). o phase 1 exchange is left in "limbo" until legacy exchange is completed. o other vulnerabilities similar to XAUTH exchange. [TA] - very similar to XAUTH... see below for my overal DoS arguments. > 5.4 CRACK > o IRAS must produce signature prior to authenticating user > o IRAS must complete DH computation to detect spurious second > message from attacker > o IRAS must participate in the legacy user authentication process > o requires support for an additional IKE exchange type > 5.6 PIC > o if PIC is run on the sgw, the sgw is subject to DoS attacks due > the fact that it must generate a signature and compute a DH > exponential prior to authenticating the remote access user. [TA] These are the same DoS concerns that you have for the above protocols. > o separate connections are required for authentication and access; > however, this implementation detail may be rendered transparent > to the user [TA] This will have to be configured somewhere, right? So someone will have to set it (whether it is the end-user or an administrator). Instead of having the possibility for a single authentication exchange failure, you now have to concerned with two separate auth exchange failures. From a customer support perspective, this added complexity sounds like a nightmare. [TA] o greater overall complexity The implementation of a separate protocol services by separate components on separate hardware, and the interaction between these new components and the existing IPsec architecture make this choice more complex. Added complexity leads to added security concerns. > 5.7 GetCert > > Security issues with this method include the following: > > o if GetCert is run on the IRAS, the IRAS is subject to DoS attacks > due the fact that it must field incoming SSL connections from > unauthenticated users > > o separate connections are required for authentication and access; > however, this implementation detail may be rendered transparent > to the user. [TA] o greater overall complexity The implementation of a separate protocol services by separate components on separate hardware, and the interaction between these new components and the existing IPsec architecture make this choice more complex. Added complexity leads to added security concerns. > 6.4 User authentication information must be protected against > eavesdropping and replay (including the user identity) > > Proposals requiring the use of aggressive mode do not meet this goal, > meaning the preshared key modes of XAUTH, ULA, and L2TP. It might be > argued that these mechanisms may use preshared keys with fixed IP > addresses (and hence use main mode), but this raises obvious SGW > scaling issues, and therefore these cases do not represent likely > remote access scenarios. Hence, XAUTH, ULA, and L2TP only meet this > goal when used with IKE main mode and public keys. All other > proposals meet this goal unconditionally. [TA] Even with a known preshared key, an attacker would still need to break the DH exponentiation to eavesdrop... correct? > 6.5 Single sign-on capability should be provided in configurations > employing load-balancing and/or redundancy > > Only proposals which permit the user to instantiate a connection with > a redundant IRAS without re-entering user authentication information > (username, password, etc) meet this goal, i.e. PIC and GetCert. [TA] I don't see how single-sign on works for the GetCert/PIC method. This is a difficult problem that I feel is not adequately addressed by any solution I've seen to date. > 6.7 Security gateway vulnerability to DoS attacks should be > minimized, and if possible, should not be greater than the > vulnerability which exists in SGW systems not providing remote > access. > > Proposals requiring no modification to the underlying IPsec > implementation unconditionally meet this goal. The only proposals > having this characteristic are PIC and GetCert, when they are run on > outboard authentication servers. Proposals requiring modification to > the underlying IPsec implementation must be examined more closely. [TA] I don't agree with this logic. You need to consider what it means to add a remote access capability to a base IPsec system, even if you don't change the code. Ultimately, with any solution, you are allowing an unknown entity to connect to your SGW instead of just individual hosts. The implications of this is that you have opened yourself up to DoS attacks inherit to IKE. To say that PIC and GetCert are immune, or better than the other approaches is a misrepresentation (atleast for some of the other protocols). More to come... > All members of the class of proposals which defer user authentication > until after a phase 1 SA has been negotiated (XAUTH, HYBRID, ULA, > L2TP) are more vulnerable to DoS attacks than those not sharing this > characteristic. CRACK, while not strictly in this class (it > authenticates the user *during* phase one), must also be considered > with this group due to other similarities. Of these proposals, HYBRID > and CRACK are clearly the most vulnerable, since they require the SGW > to perform Diffie-Hellman and public key computations for an > unauthenticated peer. [TA] DH exponentiation can be exploited for all methods. This is true of all methods because this vulnerability lies within IKE. > 6.8 The chosen mechanism(s) should minimize any reduction in the > baseline security of the underlying IPsec connection [TA] Shouldn't the goal be to minimize any reduction of the security of the system including the remote access solution? > Proposals requiring no modification to the underlying IPsec > implementation clearly meet this goal. The only proposals having this > characteristic are PIC and GetCert (when implemented on outboard > authentication servers). Proposals requiring modification to the > underlying IPsec implementation must be examined more closely. > > All proposals other than PIC and GetCert modify the underlying IPsec > implementation, and so introduce some probability that the security > of the underlying implementation (and therefore, that of the > connection) has been reduced. The XAUTH, HYBRID, and CRACK approaches > all directly modify IKE by adding new states and protocol elements. > This certainly increases code complexity, along with the probability > of an implementation error. However, this effect is most difficult to > quantify. > > In addition, all approaches other than PIC and GetCert (and perhaps > L2TP) require the SGW to act as a proxy in the user authentication > protocol. L2TP may avoid this by terminating the L2TP tunnel on a > host behind the SGW rather than on the SGW itself, but if this is > done, then there must also be some protocol between the L2TP > termination point and the SGW which permits access revocation if the > user fails to properly authenticate - otherwise, the L2TP server may > terminate the connection, but the SGW won't know it - which again > adds complexity to the SGW. [TA] PIC and GetCert may use a separate server, but the still need to proxy the same requests to a third-party authentication server, right? I'm not sure what offloading this to a separate server buys you, besides added complexity. > 7. Summary > > The various proposals come out on fairly equal footing regarding > several of the stated requirements, with differences emerging in the > following 3 areas: > > o increased SGW susceptibility to DoS attacks > > o increased SGW complexity > > o single sign-on support > > These are discussed in more detail below. > > 7.1 DoS Susceptibility > > XAUTH, HYBRID, ULA, CRACK, and L2TP are all susceptible to DoS > attacks under some circumstances. HYBRID and CRACK are trivially > susceptible to DoS attacks. PIC and GetCert only increase the SGW's > DoS susceptibility if they are implemented on the SGW. L2TP, ULA, and > XAUTH are less susceptible than HYBRID and CRACK if the remote user's > private key is securely contained, but only in this case. To the > extent that the private key is susceptible to compromise, the DoS > risk increases proportionally. As noted earlier, a private key stored > on the hard drive of a typical user system would not stand up to a > determined adversary. [TA] My DoS conclusions don't match with what you have stated... XAUTH The DoS attacks against XAUTH are similar to native IKE, since XAUTH is an extension of phase 1 exchange. I don't believe that the knowledge of a preshared key helps a DoS attacker to any great extent, as they would have to work harder (more cycles) at a DoS attack in order to use it. Hybrid Again similar to native IKE, you have to have an active DoS attacker sending and receiving packets. Making the SGW compute values for complete phase 1 exchange is not much different from just computing DH exponentiation and it comes at the expense of the DoS attacker having to perform the DH operations. CRACK As currently documented, CRACK is susceptable to non-active DoS attacks... meaning that a DoS attacker can forge bogus packets and force the SGW to perform DH exp. This could be remedied by modifying the protocol to perform two round trips before full exponentiation. This would force an active DoS attack to exploit the DH exp and then would be similar to current IKE. PIC/GetCert You have taken the stance that offloading the User Auth to a separate box will reduce DoS possibilities, and therefore PIC/GetCert is better. If you look only at the SGW, I'll grant that the DoS attack against PIC/GetCert is less than if PIC/GetCert are implemented on the SGW. I know that there is a strong reason why we want to reduce the risk of DoS attacks on the SGW. But we must also look at the DoS attacks that can be waged against the protocol that you are promoting. PIC/GetCert are no better and sometimes worse than many of the other proposals. You have all the DoS vulnerabilities of IKE, coupled with DoS vulnerabilities introduced by the new protocol. In this regard, PIC is as bad as you make out CRACK to be(I'm not sure where GetCert fits). Look at the protocols... they are almost the same! Plus, you have given the attacker two points to compromise... I'll get into this more in a bit. > While it may be argued that using a smartcard (or other secure > container) goes a long way toward resolving this problem, it must be > noted that this imposes a significant increase in the cost of the > solution, both economically and logistically. In this case, > smartcards (or whatever security container is used) must be provided > for each remote access user, and these must be managed. And if one is > stolen, it may be used for DoS attacks (or worse, unfettered access) > until it is discovered missing. > > An alternative to secure containers is to provide a short-lived key > at the time access is desired which is good for a limited time only. > The short lifetime of the key significantly narrows the window during > which it might be compromised, and if such a key were somehow > compromised, the damage potential would be bounded by its lifetime. > That is, if the key lifetime is sufficiently short, the only > realistic compromise scenario (for DoS purposes) entails gaining > control of the system while the key is valid and passing it along to > the attacker. However, an attacker with this capability can also gain > control of a system relying on a smartcard, and by proxy, full access > to the network beyond the SGW - so the smartcard is not much help in > this case, and in such a case, DoS attacks should be the least of our > concerns. [TA] I believe this is a separate issue than DoS. It is a security issue of the protocols in question. Private Key compromise, Man-in-the-Middle, and Replay vulnerabilities should be listed separately. > 7.2 Code Complexity > > XAUTH, HYBRID, ULA, CRACK, and L2TP all significantly increase the > complexity of the IRAS code base, while PIC and GetCert need not be > implemented on the IRAS. [TA] I believe that where the PIC/GetCert code is implemented is irrelevant. You have to look at the complexity as it applies to the entire Remote Access sub-system. To be fair, you must have an apples to apples comparison of the complexity of the entire Remote Access solution, not just how each solution impacts IKE. With this in mind, can you honestly say that you believe the GetCert/PIC solution is less complex then modifying IKE with one of XAUTH/CRACK/HYBRID? But what about modularity of design you might ask? Modularity can be achieved in many ways... the design however should fit with the problem you are trying to solve. Again, the problem is to use legacy authentication in the IPSec environment. I contend that a separate module in an IKE implementation to handle a legacy authentication exchange is much more inline with the problem, then a module which provides for certificate retrieval mechanism. > 7.3 Single Sign-on Support > > XAUTH, HYBRID, ULA, CRACK, and L2TP do not provide for single sign-on > support, while GetCert and PIC do (the short-lived certificate may be > used to connect to a redundant IRAS). [TA] You're assuming that the single sign-on environment is PKI based. If, however the single sign-on environment is legacy auth based (e.g. tokens), the PIC/GetCert methods would not meet this goal. A separate issue for all Remote Access solutions is how the user authentication info is shared in a single sign-on environment. > 7.4 Conclusion > > The only proposals which meet all criteria are GetCert and PIC (when > implemented on an outboard authentication server). > My conclusions? You contend that because PIC/GetCert can offload the Legacy Auth to a separate box, that this makes these proposals the better choice. The point I am trying to make, is that while this can offload some of the DoS and Security concerns from the SGW, you should still look at the entire Remote Access solution and perform the same analysis. What are my DoS concerns? What are my security concerns? From a DoS perspective, I would say it is a wash... each proposal has DoS concerns which need to fully evaluated. One concern with separate components... if IKE is fixed to address DoS concerns? Where does that leave a separate protocol? From a security perspective, I believe that the PIC/GetCert solution is not as secure. My reasoning? The complexity issue is definately on the forefront. As you have stated, complexity and how it affects security is very hard to quantify. Comparing a XAUTH/HYBRID/CRACK solution to the PIC/GetCert, I hope you can agree that PIC/GetCert is more complex. Also, having separate boxes increases the likelihood of other security issues: e.g. platform/os dependant bugs. Finally from a design perspective, I have to go back to the original question. How can we provide Legacy Authentication to IPsec applications in a remote access scenario? What is the simplest way? I have to believe this is through fixing the component currently responsible for IPsec remote party authentication. Fix IKE. I honestly believe that if the requirement to not modify IKE was not in the IPSRA charter, we would have agreed an a protocol similar to CRACK/XAUTH/HYBRID a long time ago. But, it's in the charter? Fix the charter. Do what makes the most sense. Way more than my $.02 I'm sure. --- Tylor Allison tylor_allison@securecomputing.com Secure Computing Corporation From owner-ietf-ipsra@mail.vpnc.org Mon Jul 9 18:44:37 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00303 for ; Mon, 9 Jul 2001 18:44:35 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f69LiXZ00269 for ietf-ipsra-bks; Mon, 9 Jul 2001 14:44:33 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f69LiAm00250 for ; Mon, 9 Jul 2001 14:44:11 -0700 (PDT) Received: from toque.cisco.com (toque.cisco.com [161.44.208.153]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f69LgKH08401 for ; Mon, 9 Jul 2001 14:42:21 -0700 (PDT) Received: from DDUKESW2K (ott-b1-dhcp-10-85-28-157.cisco.com [10.85.28.157]) by toque.cisco.com (Mirapoint) with SMTP id ABD08534; Mon, 9 Jul 2001 17:43:57 -0400 (EDT) Message-ID: <014b01c108c0$596fb280$9d1c550a@cisco.com> Reply-To: "Darren Dukes" From: "Darren Dukes" To: "ietf-ipsra" References: <3B4502BE.3A7295CD@redcreek.com> Subject: Re: evaluation draft Date: Mon, 9 Jul 2001 17:44:36 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Scott, here are some initial comments. 1 - You should add a section stating provisioning complexities. If a user wants to provision a remote access VPN but does not want to provision a PKI, why would they want to deploy an IRAS for PIC, which is just a CA using legacy authentication mechanisms for enrolment? 2 - You suggest a reduction in security with an increase in complexity "Hence, the probability of an oversight or error which impacts on critical system function is proportional to system complexity, and software development experience to date suggests that as systems grow increasingly complex, this probability nears unity." Is this your own idea or do you have some data or a published authority that can back this up? 4 - Does an increase in complexity causing a unity decrease in security also extend to provisioning of the security solution with multiple servers that must now be configured? If so are the "Two additional goals" you state in section 2 still valid? 5 - If a separate IRAS is not deployed for PIC but it exists on the SGW, PIC and Hybrid have the same DoS vulnerabilities. 6 - If Hybrid and PIC offer the same vulnerabilities to DoS on the SGW then both implementations must offer some "throttle" capability to avoid dieing from a DoS attack. This negates the problem of disrupting existing traffic with an IKE-based (or PIC-based) DoS attack does it not? 7 - Hybrid requires half of the DH computations that PIC does, especially important if they are on the same SGW. This is worth mentioning in your review of PIC 8 - I disagree with the Hybrid/Xauth issues: You write "Xauth requires the SGW to participate in the user authentication process, which increases SGW vulnerability both in terms of complexity and denial of service." If the complexity of writing and deploying an IRAS is anything close to the complexity of writing and testing Hybrid then this argument also applies to PIC. You write "Adding an open-ended number of challenge-rsp exchanges to a key exchange increases vulnerability to denial of service attack under some circumstances, and absolutely increases the complexity of the key exchange mechanism under all circumstances[... etc]" This is the same as the issue above, and all SGW implementations must deal with this by throttling the amount of processor time they will allow IKE (or PIC) to use You write "There may be some known ascii plaintext at fixed locations within packets due to support for user prompts. [...]" I believe others have commented on this too, but any protocol has known bytes in each packet. EAP has message text as well, so you should include this in PIC if you believe it is significant. You write "Xauth requires support for its companion, modecfg." Others have already provided valid comments here... You write "[HYBRID] is trivially susceptible to DoS attacks, as it requires the IRAS to engage in an unauthenticated Diffie-Hellman exchange which includes an expensive public key operation, and then to continue the conversation for some period of time beyond that, perhaps in error." Yes and this should be throttled by the implementation to prevent DoS attacks. PIC will also suffer from this if run on the SGW. Overall an interesting read but I still believe PIC has too much infrastructure and computational overhead as compared to Hybrid. Darren. ----- Original Message ----- From: "Scott G. Kelly" To: Sent: Thursday, July 05, 2001 8:13 PM Subject: evaluation draft > Hi All, > > Attached is a copy of the draft which compares pic, getcert, crack, ula, > hybrid, and xauth that I promised months ago. I've submitted it to the > ID editor (as a personal submission), but also wanted to archive it here > in the mailing list. I vastly underestimated the amount of work > involved, and feel as though I'd like to work on it for another week or > so even now. On the other hand, we need to move forward, so I'm putting > it out now in order to solicit comments. > > Scott > > > > > IPsec Remote Access Working Group Scott Kelly > INTERNET-DRAFT RedCreek Communications > draft-kelly-ipsra-eval-00.txt July, 2001 > > > > Comparing Proposed Solutions for > IPsec Remote Access Legacy User Authentication > > > > Status of This Memo > > This document is an Internet Draft and is in full conformance with > all provisions of Section 10 of [RFC2026]. Internet Drafts are > working documents of the Internet Engineering Task Force (IETF), its > areas, and working groups. Note that other groups may also distribute > working documents as Internet Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as ``work in progress.'' > > The list of current Internet-Drafts can be accessed at > > http://www.ietf.org/ietf/1id-abstracts.txt > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > Comments on this document should be sent to the IETF IPsec remote > access discussion list (ietf-ipsra@vpnc.org). > > > Abstract > > A number of competing methods for integrating legacy remote access > user authentication into IPsec have been proposed, resulting in > confusion as to which method(s) might be best for solving the > problems at hand. This document briefly compares these proposals in > an effort to clarify the relative standing of each with respect to > the problem space and requirements. > > > > > > > > > > > Kelly Expires Jan 2002 [Page 1] > > Internet Draft July, 2001 > > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 1.2 Basic Problem Space Description . . . . . . . . . . . . . . . . 3 > 1.3 Reader Prerequisites . . . . . . . . . . . . . . . . . . . . . . 4 > 1.4 Requirements Terminology . . . . . . . . . . . . . . . . . . . . 4 > 1.5 General Terminology . . . . . . . . . . . . . . . . . . . . . . 4 > 2. General Solution Requirements . . . . . . . . . . . . . . . . . . 5 > 3. Brief Enumeration of Proposed Solutions . . . . . . . . . . . . . 7 > 4. Common Features of Proposed Solutions . . . . . . . . . . . . . . 8 > 4.1 Common Issues for Proposals Supporting Preshared Keys . . . . . 8 > 4.1.1 General issues for configurations using preshared keys . . . . 9 > 4.1.2 Fixed Address (unique PSK) . . . . . . . . . . . . . . . . . . 10 > 4.1.2 Non-fixed Address, Global Preshared Key . . . . . . . . . . . 10 > 4.1.3 Non-fixed Address, Unique Preshared Key . . . . . . . . . . . 11 > 4.2 General Issues For Configurations Using Mutual Certificates . . 11 > 5. Comparing the Proposals . . . . . . . . . . . . . . . . . . . . . 12 > 5.1 XAUTH/MODECFG . . . . . . . . . . . . . . . . . . . . . . . . . 12 > 5.2 Hybrid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 > 5.3 ULA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 > 5.4 CRACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 > 5.5 L2TP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 > 5.6 PIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 > 5.7 GetCert . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 > 6. Comparison of Proposals to Requirements . . . . . . . . . . . . . 17 > 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 > 7.1 DoS Susceptibility . . . . . . . . . . . . . . . . . . . . . . . 20 > 7.2 Code Complexity . . . . . . . . . . . . . . . . . . . . . . . . 21 > 7.3 Single Sign-on Support . . . . . . . . . . . . . . . . . . . . . 21 > 7.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 > 8. Security Considerations . . . . . . . . . . . . . . . . . . . . . 21 > 9. Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 > 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 > 11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 23 > > > > > > > > Kelly Expires Jan 2002 [Page 2] > > Internet Draft July, 2001 > > > 1. Introduction > > > The IPsec remote access working group (ipsra) was formed in order to > settle upon a solution set for providing secure remote access using > IPsec components. Integral to the secure remote access problem is the > desire to provide support for existing legacy authentication > mechanisms, most notably RADIUS and SecureID. A number of competing > methods for integrating such user authentication into IPsec have been > proposed, resulting in confusion as to which method(s) might be best > for solving the problems at hand. This document briefly compares > these proposals in an effort to clarify the relative standing of each > with respect to the problem space and requirements. > > 1.2 Basic Problem Space Description > > Customers want to provide secure remote access to their networks > using IPsec along with authentication methods which leverage > currently deployed user authentication mechanisms (primarily RADIUS > and SecureID). This is difficult, as currently defined authentication > mechanisms for IPsec are symmetric, e.g. either both sides (the user > and the security gateway) authenticate using a shared secret, or both > sides authenticate using identical public key mechanisms (encryption > or signatures). > > These mechanisms provide no support for the passphrases which are > typically required for legacy mechanisms. While at first glance one > might conclude that passwords are similar to shared secrets, and that > some adaptation of the shared secret mechanism currently supported by > IPsec would resolve this problem, there are at least two issues with > this approach (ignoring for the moment that preshared keys are > susceptible to dictionary attacks, and that users would often make > this simpler by choosing easily guessed passphrases). > > First, there is the problem of identifying the correct secret to > apply at the gateway. IKE, as currently defined, may only identify > shared secrets by IP address if main mode is used, and for most > remote access scenarios, the IP address of the remote user simply is > not known a priori. Even if it were, this would be no help if a one > time passphrase mechanism were in use. This implies that use of > aggressive mode is required for this approach, and this raises a > number of security issues due to vulnerabilities associated with > aggressive mode. Also, many of the same issues relating to one time > passphrases exist for aggressive mode. > > The second issue raised by using passphrases as preshared keys > pertains to scalability. If passphrases are to be in any way useful > from a security perspective, they must be unique for each user. Since > > > > Kelly Expires Jan 2002 [Page 3] > > Internet Draft July, 2001 > > > the gateway must also use this same passphrase (it is being used as a > shared secret), this requires that the gateway be configured with > each remote user's unique identifier and passphrase. This becomes > problematic as the number of remote users grows large. > > Further complicating matters, legacy mechanisms typically provide > one-sided authentication for the user, implicitly trusting that the > challenger (the gateway) is who/what it claims to be. However, IPsec > provides for no such one-sided authentication technique. Hence, in > order to support legacy authentication mechanisms within IPsec, it > must either be possible to authenticate the user and the gateway > asymmetrically, or it must be possible to derive a user credential > from the legacy authentication process which may then be used to > secure an IPsec connection. > > > 1.3 Reader Prerequisites > > Reader familiarity with RFCs 2401-2412 is a minimum prerequisite to > understanding the concepts discussed here. Familiarity with concepts > relating to Public Key Infrastructures (PKIs) is also necessary, as > is familiarity with the various secure remote access proposals > discussed below ([XAUTH/MODECFG], [HYBRID], [ULA], [CRACK], [PIC], > [L2TPSEC], [GETCERT]). An understanding of various classes of attacks > on cryptographic primitives and network connections will further > facilitate understanding. > > > 1.4 Requirements Terminology > > The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, > SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this > document, are to be interpreted as described in [KEYWORDS]. > > > 1.5 General Terminology > > Following are definitions of terms as they are used in this document. > > o MiM: Man-in-the-Middle, as in the case where an adversary > positions an intercepting system between two endpoints, and > traffic in both directions must pass through this intercepting > system, giving the adversary the opportunity to modify the > data stream in either or both directions. > > o DoS: Denial of Service, as in the case where a system is > prevented from delivering essential services due to outside > interference. > > > > Kelly Expires Jan 2002 [Page 4] > > Internet Draft July, 2001 > > > o User Identifier: this term refers to the value used to uniquely > identify the remote user, typically a user name. > > o Passphrase: this term refers to the value the remote user > presents in conjunction with the user identifier in order to > verify the user's identity; it may be a value the user commits > to memory (such as an ascii string), it may be retrieved from > storage, or it may be generated by a device the user possesses or > interacts with at the time of the access attempt. In the case of > n-factor authentication mechanisms, a user may be required to > present multiple passphrases in order to satisfy admission > criteria. > > o SGW - Security GateWay, the IPsec termination point for the > target network to which remote acess is to be provided. > > o PSK - PreShared Key, as in a shared secret value used for proof > of identity and/or group membership. > > o IRAC - Ipsec Remote Access Client > > o IRAS - Ipsec Remote Access Server (or SGW) > > o DH exchange - Diffie-Hellman key exchange > > 2. General Solution Requirements > > In evaluating the various proposed solutions, the first order of > business is to hold them up against the user authentication > requirements for secure remote access to determine how completely > satisfied the requirements are by each proposal. Basic requirements > for user authentication as it applies to secure remote access using > IPsec are presented in [KR01], and these requirements are not > detailed here, except for a brief synopsis (taken from [KR01]). > > In general, proposed IPsec remote access mechanisms should meet the > following goals: > > o should provide direct support for legacy user authentication > systems such as RADIUS > > o should encourage migration from existing low-entropy > password-based systems to more secure authentication systems > > o if legacy support cannot be provided without some sort of > migration, the impact of such migration should be minimized > > o user authentication information must be protected against > > > > Kelly Expires Jan 2002 [Page 5] > > Internet Draft July, 2001 > > > eavesdropping and replay (including the user identity) > > o single sign-on capability should be provided in configurations > employing load-balancing and/or redundancy > > o n-factor authentication mechanisms should be supported > > Two additional goals not listed above are suggested in this document: > > o Security gateway vulnerability to DoS attacks should be > minimized, and if possible, should not be greater than the > vulnerability which exists in SGW systems not providing remote > access > > o The chosen mechanism(s) should minimize any reduction in the > baseline security of the underlying IPsec connection > > In most cases, the motivation for each of the security goals in the > initial list above is obvious. However, the need for the two > additional suggested goals may be less evident, so supporting > discussion is provided below. > > Regarding vulnerability to DoS attacks, we should note that the SGW > represents a shared access point for the target network, and as such, > has the potential to adversely affect multiple users in case of > failure, both inside and outside of the target network. Further, in > cases where there is only one SGW for a given network, it represents > a single point of failure. Hence, it seems reasonable to suggest that > the chosen solution should not increase the DoS vulnerability of this > critical system if this can be avoided. > > Regarding the security of the underlying connection, IPsec, as > currently defined, provides for a baseline measure of security with > certain assumptions. That is, if we may assume that the keying > material generated by the DH exchange is effectively random (i.e. > unguessable), and by implication that the keying material used for > authenticating the key exchange is effectively random (as well as > securely stored), then other assumptions regarding relative security > of the resulting connection (i.e. the effort required to compromise > the connection) are warranted. > > However, it is possible to choose methods of producing and/or storing > authentication keying material which invalidate these assumptions. If > such a method is chosen, then the baseline security of the underlying > connection will be reduced when compared to a connection which uses > more secure keying material production and storage methods. > > This implies that the overall security characteristics of the user > > > > Kelly Expires Jan 2002 [Page 6] > > Internet Draft July, 2001 > > > authentication mechanism may directly influence the security of the > underlying IPsec connection. This being the case, it seems reasonable > to suggest that either the chosen mechanism should not reduce the > baseline effectiveness of the underlying IPsec connection in > comparison to non-remote-access connections, or (if this cannot be > avoided) that the resulting security reduction should be minimized. > > A secondary area of concern pertains to the manner in which we might > unwittingly reduce security by adding functionality which interacts > with the base IPsec subsystem in unforseen ways. As systems grow in > complexity, it becomes increasingly difficult to reasonably assert > that such unforseen interactions are either not possible or not > occurring. This is largely due to the increase in the number of > system inputs and their corresponding outputs, and to our inability > to accurately characterize these quantities. That is, increasing > complexity makes the task of recognizing all of the possible system > input/output combinations quite difficult (if not impossible) for a > human mind. Hence, the probability of an oversight or error which > impacts on critical system function is proportional to system > complexity, and software development experience to date suggests that > as systems grow increasingly complex, this probability nears unity. > > In response to this issue, computer-based analytical techniques have > been developed to assist in the task of characterizing complex > systems. These techniques seem effective in transcending the > computational and organizational limitations of the human mind in > many cases. However, while computer-based analytical engines might > improve performance with respect to organizing and understanding > complexity, these engines are ultimately designed and interpreted by > the same sorts of agents as they are intended to aid, and hence may > not be as accurate as hoped. > > Recognition of the implications of these observations is apparently > difficult for some, perhaps due in part to the lack of clearcut > quantifying measures for accuracy (or in this case, security) as a > function of code complexity. The fact that one cannot insert the > number of added lines of code into an equation to arrive at the > conclusion that either a critical bug has or has not been introduced > makes it difficult for some to accept the criticality of this issue > when designing and implementing secure systems. Nonetheless, given > the stakes in scenarios requiring high security, the implications of > added complexity must not be ignored. Hence, we should strive to > balance the added complexity of the chosen solution with other design > goals. > > > 3. Brief Enumeration of Proposed Solutions > > > > > Kelly Expires Jan 2002 [Page 7] > > Internet Draft July, 2001 > > > As noted, there are a number of proposed solutions to date. These are > as follows: > > o XAUTH/MODECFG - XAUTH refers to eXtended AUTHentication (within > IKE), and is detailed in [XAUTH]. It is tightly bound to another > proposal, the ISAKMP configuration method [MODECFG]. > > o HYBRID - this proposal builds upon the XAUTH/MODECFG combination, > adding one-sided server authentication. It is detailed in > [HYBRID]. > > o ULA - ULA refers to User-Level Authentication; this proposal was > withdrawn due to various shortcomings, but is included here for > the sake of completeness. See [ULA] for additional detail. > > o CRACK - CRACK stands for Challenge/Response for Authenticated > Cryptographic Keys, and is discussed in [CRACK]. > > o L2TP - L2TP (Layer 2 Tunneling Protocol) uses PPP-based > authentication. Use of L2TP with IPsec is discussed in > [L2TPSEC]. > > o PIC - PIC stands for Pre-Ike Credential provisioning protocol, > and is discussed in [PIC] > > o GetCert - GetCert is a shorthand name for "Client Certificate and > Key Retrieval for IKE", and is discussed in [GETCERT]. > > This document provides a (currently very) brief analysis of how each > of these stacks up against the remote access user authentication > requirements discussed above. > > > 4. Common Features of Proposed Solutions > > Before looking at the individual proposals, it may be useful to > examine some of the issues which multiple proposals have in common. A > number of the proposals provide for the use of preshared keys to > authenticate an IKE session prior to authenticating the user (XAUTH, > ULA, L2TP), and an overlapping subset provides for the use of public > key mechanisms for the same purpose. These are discussed below. > > 4.1 Common Issues for Proposals Supporting Preshared Keys > > A subset of the proposals (XAUTH/MODECFG, ULA, L2TP) provide the > ability to use preshared keys as a part of the authentication > process. All of these proposals, when used in this manner, share > common issues, which are discussed in section 4.1.1 below. > > > > Kelly Expires Jan 2002 [Page 8] > > Internet Draft July, 2001 > > > In addition, preshared keys may be used in a number of network > configurations, including the following: > > o remote client uses fixed IP address with unique preshared key > > o remote client uses non-fixed IP address with global preshared key > > o remote client uses non-fixed IP address with unique preshared key > (requires use of IKE aggressive mode) > > The individual issues associated with these are discussed in sections > 4.1.2-4.1.4. > > > 4.1.1 General issues for configurations using preshared keys > > Preshared keys, when compared to well-managed public/private key > pairs, provide a significantly weaker form of authentication for > IPsec. Brute force man-in-the-middle attacks on the preshared keys > are possible. For example, an adversary might juxtapose himself > between the remote user and the security gateway, and attempt to > intercept the remote access user's connection attempt with the > gateway. If the SGW can be impersonated in this manner by the > attacker, the remote access client will provide the attacker with > enough information so that the preshared key may be subjected to an > offline dictionary attack. > > Once a preshared key is compromised, additional information regarding > the user identity and legacy authentication passphrase is vulnerable, > and if the authentication passphrase is compromised, the system has > failed entirely: the attacker may impersonate the remote user. This > risk may be mitigated by using one-time legacy authentication tokens, > but it should be noted that the identity information will still not > be protected. Further, if an attacker with MiM capability succeeds in > determining the preshared key, he may then launch MiM attacks on > subsequent remote access sessions in which he sits transparently in > the connection path, impersonating the sgw to the remote user, and > impersonating the remote user to the sgw. The implications of this > are clear. > > These risks are not mitigated by using aggressive mode with preshared > keys, which is a much more likely scenario for remote access given > that the IP address of the remote access user will vary. Furthermore, > the attacker need not interact with the data stream in this case, but > only needs to observe the exchange. Aggressive mode proceeds as > follows: > > Remote User Security Gateway > > > > Kelly Expires Jan 2002 [Page 9] > > Internet Draft July, 2001 > > > ------------------ ---------------------- > HDR, SA, KE, Ni, IDii --> > <-- HDR, SA, KE, Nr, IDir, HASH_R > HDR, HASH_I --> > > Note that in this case, the attacker has access to the HASH_R value, > along with all relevant inputs, so that a dictionary attack may again > be mounted on the preshared key. > > Also note that in this case the SGW is forced to compute HASH_R prior > to verifying the remote user's identity, implying an increased > vulnerability to DoS attacks, and if the user (attacker) sends a > spurious third message, the SGW must complete the DH exponentiation > to detect it. In fact, methods which rely on preshared keys and > aggressive mode may be trivially susceptible to DoS attacks due to > this vulnerability, in that an attacker has but to construct a valid > IDii payload, and this may be used again and again in order to cause > the SGW to repeatedly allocate context memory, compute HASH_R, and > perhaps compute the DH value. > > Finally, support for use of preshared keys does scale well, and does > not encourage migration to stronger authentication mechanisms, and in > fact, may encourage the opposite. Hence, it may be prudent from a > security perspective to disallow such support in any proposed > solution. > > Issues specific to particular uses of preshared keys for the various > network configurations enumerated in section 4.1 above are discussed > in the following sections. > > > 4.1.2 Fixed Address (unique PSK) > > In the case where the IP address is fixed, IKE main mode may be used > with a preshared key. This is an unusual situation for remote access, > but it does present the ability to use a unique preshared key for > each user, meaning it may be at least as secure as typical site-to- > site configurations employing preshared keys. However, preshared keys > within main mode are susceptible to attack as noted above, so this > may provide a false sense of security. Also, use of per-user > preshared keys raises obvious scalability issues as the number of > users grows. > > > 4.1.2 Non-fixed Address, Global Preshared Key > > In some cases, a single preshared key may be used for all remote > users. A global preshared key has obvious shortcomings, and must not > > > > Kelly Expires Jan 2002 [Page 10] > > Internet Draft July, 2001 > > > be recommended. Such keys may be compromised in numerous ways without > detection, and once this has occurred, eavesdropping and MiM attacks > are greatly simplified. This is unacceptable from a security > perspective. > > > 4.1.3 Non-fixed Address, Unique Preshared Key > > Unique preshared keys may be used with non-fixed addresses if IKE > aggressive mode is used. However, this method is vulnerable to DoS > attacks on the sgw, as the user identity is not protected, and > intercepted packets may be replayed, causing the sgw to needlessly > engage in hash and exponentiation calculations. This method is also > susceptible to dictionary attacks on the preshared key. In addition, > per-user keys do not scale as the number of users grows. > > > 4.2 General Issues For Configurations Using Mutual Certificates > > In general, public key authentication mechanisms are much stronger > than shared secret mechanisms. However, there are a number of issues > even with these. Due to the overhead associated with authentication > operations, there is some unavoidable DoS susceptibility. For > example, using IKE main mode, an attacker may cause the SGW to > needlessly perform expensive public key and/or Diffie-Hellman > operations just to prove that the attacker is not authorized to > connect. If aggressive mode is used instead of main mode, the SGW may > be forced to generate its own signature without first verifying the > identity of the remote user. A sufficient number of such spurious > computations will impinge upon the SGW's ability to deliver services > to authorized users. > > Note that these issues exist for site to site installations as well > as remote access scenarios, although in site-to-site connections the > remote IP address may be used by the SGW as an additional filter, > raising the bar somewhat for the attacker. In selecting such a > mechanism for remote access, we should strive to not introduce any > more vulnerability than already exists in site to site scenarios. > > A second area of consideration pertains to the storage mechanism for > the private key used to authenticate the user. If this key is > compromised, the entity it authenticates may be impersonated without > detection. Hence, the integrity of the derived authentication is > directly proportional to the security of the private key storage > technique. > > If the private key is stored on the hard drive of the subject system, > it is vulnerable to a number of attacks, and may be compromised > > > > Kelly Expires Jan 2002 [Page 11] > > Internet Draft July, 2001 > > > without detection. Therefore, the integrity of the resulting > authentication in this case is directly proportional to the security > of the system in which the hard drive resides. If this system is > hardened, physical access is strictly controlled, and system > configuration is strictly controlled, the associated level of > security may be relatively high. However, if the system is (for > example) a laptop containing a commercial operating system, and the > user has typical freedoms regarding system usage and configuration, > the associated level of security is likely quite low. > > In such cases, the private key may be compromised without detection > in numerous ways, and even if an additional factor of authentication > is used (such as a username/passphrase pair) the SGW is subject to > increased vulnerability to DoS attacks (the attacker can negotiate > multiple phase 1 SAs using the private key). If a post-IKE legacy > user authentication mechanism is used, the underlying user > authentication mechanism is also subject to attack, which may > ultimately expose the protected network(s) and data. > > These risks may be mitigated if the private key is securely contained > (e.g. in a smartcard), and if key usage requires an additional factor > of authentication in advance (i,.e. stealing the key container does > not necessarily guarantee access). However, it should be recognized > that a sufficiently secured private key may also obviate the need for > a username-passphrase exchange, unless n-factor authentication is > required. > > So, while public key methods may seem to remedy many of the issues > raised by the use of preshared keys, we must be careful to evaluate > the relative security of the private keys in such scenarios. > Solutions relying on insufficiently secured private keys are > correspondingly insecure. > > 5. Comparing the Proposals > > 5.1 XAUTH/MODECFG > > Xauth is a user authentication mechanism which functions by first > forming a phase 1 IKE SA using one of the conventional IKE > authentication techniques (preshared key or public key), and by then > extending the IKE exchange to include additional user authentication > exchanges. The xauth payloads ride atop an additional proposed IKE > extension (referred to as "modecfg" or "ikecfg") which is essentially > a DHCP-like mechanism meant to provide host configuration parameters > to remote access clients. > > Xauth may be deployed in at least five different configurations: > > > > > Kelly Expires Jan 2002 [Page 12] > > Internet Draft July, 2001 > > > o main mode using unique preshared keys (fixed IRAC address) > o main mode using global preshared key (non-fixed IRAC address) > o aggressive mode using unique or global preshared key and keyid > o main mode using certificates > o aggressive mode using certificates > > When used with preshared keys, xauth suffers from all of the > associated shortcomings discussed above in section 4.1. When used > with certificates, either the associated private keys are adequately > safeguarded, or they are not. If so, xauth is superfluous, unless n- > factor authentication is required. If not, the associated > shortcomings are present. > > Specific xauth issues (in addition to the general issues discussed > above) include the following: > > o Xauth requires the SGW to participate in the user authentication > process, which increases SGW vulnerability both in terms of > complexity and denial of service. > > o Adding an open-ended number of challenge-rsp exchanges to a key > exchange increases vulnerability to denial of service attack > under some circumstances, and absolutely increases the complexity > of the key exchange mechanism under all circumstances. While an > open-ended exchange may not be entirely avoidable given the > n-factor authentication requirement, xauth does not begin such > exchanges until a phase 1 IKE SA has been instantiated, and this > with either limited or no knowledge of the user identity in > several of the supported configurations. The overhead associated > with the DH exchange is significant, and the fact that an > anonymous peer may force expenditure of this effort implies that > a system supporting the associated configuration is trivially > susceptible to denial of service. Further, once such phase 1 > sessions are established, the SGW may be "led on" by a malicious > peer for some (hopefully limited) period of time, guaranteeing > that the associated system resources will remain unavailable > during this period. > > o Xauth requires proxy support in the SGW for up to 16 different > authentication methods, which greatly increases system > complexity. > > o There may be some known ascii plaintext at fixed locations within > packets due to support for user prompts. The amount of text will > normally be small, but should not be ignored. If a reusable > passphrase is contained within the xauth exchange, an attacker > may have significant motivation for breaking the IKE session > encryption, and known plaintext will simplify this task. > > > > Kelly Expires Jan 2002 [Page 13] > > Internet Draft July, 2001 > > > o Xauth requires support for its companion, modecfg. This > duplicates some of the functionality of DHCP, but lacks support > for critical components, implying that it is redundant, and > therefore adds unnecessary complexity. However, one has no choice > but to implement modecfg if one wishes to implement xauth. > > > 5.2 Hybrid > > The "Hybrid" authentication mechanism [HYBRID] attempts to address > some of the shortcomings of xauth, most notably the need to support > global preshared keys when remote access client certificates are not > available. The hybrid mechanism modifies the xauth mechanism by > requiring the IRAS to authenticate itself using public key > techniques, and deferring user authentication until after the phase 1 > IKE SA is in place. That is, hybrid requires the IRAS to authenticate > to the IRAC, but not vice versa - it is a one-sided authentication. > > This mechanism is trivially susceptible to DoS attacks, as it > requires the IRAS to engage in an unauthenticated Diffie-Hellman > exchange which includes an expensive public key operation, and then > to continue the conversation for some period of time beyond that, > perhaps in error. In addition, all of the specific xauth > shortcomings not relating specifically to preshared keys apply > equally to hybrid. > > > 5.3 ULA > > The previously proposed ULA method* [ULA] consists in forming an > authenticated phase 1 SA in the same manner as xauth, followed by > creation of a phase 2 SA whose sole purpose is to protect the > authentication exchange. Following successful authentication, the > phase 2 SA is either replaced, or the selectors are modified to > permit access to appropriate resources. While this method improves > somewhat on xauth by providing the ability to offload the user > authentication to an outboard server (reachable through the tunnel), > it suffers from many of the same problems as xauth. In particular, > this method has the following shortcomings: > > o if preshared keys are used, this technique suffers from all of > the general shortcoming associated with these which were > identified above, e.g. vulnerability to MiM, offline dictionary > attacks, undetected compromise, lack of scalability, etc. > > o requires IRAS to create phase 1 and phase 2 SAs without verifying > user identity; this has obvious DoS implications, and is also > susceptible to attacks on the underlying authentication > > > > Kelly Expires Jan 2002 [Page 14] > > Internet Draft July, 2001 > > > infrastructure. These risks may be mitigated if mutual > certificates are used, but as with xauth, either the user's > private key is securely stored or not. If so, ULA is superfluous > unless n-factor authentication is required, and if not, the > associated shortcomings are present. > > *This proposal was withdrawn due to security issues > > > 5.4 CRACK > > The CRACK technique [CRACK] integrates the user authentication > process into the key exchange negotiation within IKE by defining a > new exchange type. The IRAS authenticates using public key > techniques, while the user authenticates using an identity and one or > more passphrases. The exchange proceeds as follows: > > Client (I) Gateway (R) > ----------- ----------- > HDR, SAi, KEi, Ni > [, CERTREQ] ---> > <--- HDR, SAr, [CERT, ] KEr, > SIG1, Nr > HDR*, CHRE, PK ---> > <--- HDR*, < SIG2 | CHRE > > HDR*, < SIG3 | CHRE > ---> > > For payload definitions, see [CRACK]. This technique limits the > denial of service implications for the IRAS when compared to xauth, > hybrid, or ula, as the user must authenticate very early in the > protocol. However, this method suffers from the following > shortcomings: > > o IRAS must produce signature prior to authenticating user > o IRAS must complete DH computation to detect spurious second > message from attacker > o IRAS must participate in the legacy user authentication process > o requires support for an additional IKE exchange type > > > 5.5 L2TP > > The L2TP user authentication mechanism is very similar to the ULA > mechanism, and consists in forming both phase 1 and phase 2 SAs prior > to authenticating the user. Hence, it suffers from precisely the same > shortcomings as ULA (and by proxy, many of the shortcomings of > xauth). However, the L2TP method also completely removes the user > authentication from IPsec and moves it into PPP, so that per-user > > > > Kelly Expires Jan 2002 [Page 15] > > Internet Draft July, 2001 > > > network access security must also be managed within the L2TP/PPP > subsystem. This has significant implications in terms of increased > system complexity. > > The current proposals for using L2TP with IPsec suggest using a > "machine certificate" to authenticate the IKE SA. Note that as with > xauth, either the user's private key is securely stored or not. If > so, the L2TP user authentication may be superfluous (unless n-factor > authentication is required), and if not, the associated shortcomings > are present. > > > 5.6 PIC > > The PIC mechanism provides a method for integrating legacy user > authentication with existing IPsec deployments without the need for > modifying the underlying IPsec implementations. This is accomplished > by authenticating the user outside of the IPsec session proper, and > providing the user with a short-lived certificate which may then be > used within IKE using currently defined public key authentication > mechanisms. > > The PIC method accomplishes user authentication using an ISAKMP > exchange which supports legacy mechanisms, and then provides the user > with a private/public keypair and certificate which are used for > subsequent authentication operations with the security gateway. While > PIC may be terminated by the target security gateway, it may also be > terminated by a separate authentication server. The exchange is as > follows: > > Client Authentication Server > ------ --------------------------- > (1) HDR, SA, KE, Ni --> > > (2) <-- HDR, SA, KE, Nr, IDir,[CERT,] > SIG_R, HASH, [,...] > > (3) HDR*, HASH, EAP, [EAP...,] --> > [CREDENTIAL-REQUEST] > > (4) <-- HDR*, HASH, EAP, [EAP...,] > [CREDENTIAL] > > Security issues with this method include the following: > > o if PIC is run on the sgw, the sgw is subject to DoS attacks due > the fact that it must generate a signature and compute a DH > exponential prior to authenticating the remote access user. > > > > Kelly Expires Jan 2002 [Page 16] > > Internet Draft July, 2001 > > > o separate connections are required for authentication and access; > however, this implementation detail may be rendered transparent > to the user > > > > 5.7 GetCert > > The GetCert method is a percursor to PIC, having provided the first > example of the underlying model: as a result of a non-IPsec user > authentication exchange, the user obtains a certificate which is used > to authenticate a subsequent IKE session. The primary difference > between GetCert and PIC is in the transport. While PIC runs over a > new ISAKMP exchange, GetCert is completely independent of IPsec, and > runs over a HTTPS/TCP connection. > > Security issues with this method include the following: > > o if GetCert is run on the IRAS, the IRAS is subject to DoS attacks > due the fact that it must field incoming SSL connections from > unauthenticated users > > o separate connections are required for authentication and access; > however, this implementation detail may be rendered transparent > to the user. > > > 6. Comparison of Proposals to Requirements > > All of the proposed mechanisms solve the most basic problem, which is > to authenticate remote access users by way of legacy authentication > systems. However, they do so in several different ways. The > techniques fall into 3 general categories, from a high level: > > o those which complete IPsec negotiation (phase 1 and/or phase 2 > IKE) prior to authenticating the user (XAUTH, HYBRID, ULA, L2TP). > > o those which integrate the user authentication into IKE phase > 1 negotiation (CRACK). > > o those which move the user interaction outside of IPsec > entirely (PIC, GETCERT) > > Another way to group these is as follows: > > o those which require the IRAS to participate in the user > authentication process (XAUTH, HYBRID, ULA, L2TP, CRACK) > > > > > Kelly Expires Jan 2002 [Page 17] > > Internet Draft July, 2001 > > > o those which do not require the IRAS to participate in the user > authentication process (PIC, GETCERT) > > > > Recalling our goals from section 2, it is appropriate to compare the > proposals against each of these at this time. > > 6.1 Provide direct support for legacy user authentication systems > such as RADIUS > > All proposals meet this goal. > > > 6.2 Encourages migration from existing low-entropy password-based > systems to more secure authentication systems > > Proposals requiring use of public key mechanisms certainly meet this > goal, while proposals supporting both preshared keys and public key > mechanisms meet it to a lesser extent. PIC, GETCERT, CRACK, and > HYBRID all require support for public key mechanisms. If XAUTH, ULA, > and L2TP are used with preshared keys, they do not meet this goal. > > > 6.3 If legacy support cannot be provided without some sort of > migration, the impact of such migration should be minimized > > Since all proposals meet 6.1, this is moot. > > > 6.4 User authentication information must be protected against > eavesdropping and replay (including the user identity) > > Proposals requiring the use of aggressive mode do not meet this goal, > meaning the preshared key modes of XAUTH, ULA, and L2TP. It might be > argued that these mechanisms may use preshared keys with fixed IP > addresses (and hence use main mode), but this raises obvious SGW > scaling issues, and therefore these cases do not represent likely > remote access scenarios. Hence, XAUTH, ULA, and L2TP only meet this > goal when used with IKE main mode and public keys. All other > proposals meet this goal unconditionally. > > > 6.5 Single sign-on capability should be provided in configurations > employing load-balancing and/or redundancy > > Only proposals which permit the user to instantiate a connection with > a redundant IRAS without re-entering user authentication information > > > > Kelly Expires Jan 2002 [Page 18] > > Internet Draft July, 2001 > > > (username, password, etc) meet this goal, i.e. PIC and GetCert. > > > 6.6 N-factor authentication mechanisms should be supported > > All proposals meet this goal. > > > 6.7 Security gateway vulnerability to DoS attacks should be > minimized, and if possible, should not be greater than the > vulnerability which exists in SGW systems not providing remote > access. > > Proposals requiring no modification to the underlying IPsec > implementation unconditionally meet this goal. The only proposals > having this characteristic are PIC and GetCert, when they are run on > outboard authentication servers. Proposals requiring modification to > the underlying IPsec implementation must be examined more closely. > > All members of the class of proposals which defer user authentication > until after a phase 1 SA has been negotiated (XAUTH, HYBRID, ULA, > L2TP) are more vulnerable to DoS attacks than those not sharing this > characteristic. CRACK, while not strictly in this class (it > authenticates the user *during* phase one), must also be considered > with this group due to other similarities. Of these proposals, HYBRID > and CRACK are clearly the most vulnerable, since they require the SGW > to perform Diffie-Hellman and public key computations for an > unauthenticated peer. > > In the case of the other 3, the DoS implications might be minimized > if main mode with (random) preshared key authentication were used for > phase 1, but this is not feasible due to scaling issues. Hence, for > XAUTH, ULA, and L2TP, main mode with signatures is the only realistic > approach. This has a slightly higher DoS risk, but no more so than > for other non-remote-access IKE exchanges using public key > techniques. However, the validity of this assumption depends upon > the security of the private keys used for authenticating the remote > access client. As noted previously, if this key is not securely > stored, DoS attacks become trivial for a determined adversary. > > > 6.8 The chosen mechanism(s) should minimize any reduction in the > baseline security of the underlying IPsec connection > > Proposals requiring no modification to the underlying IPsec > implementation clearly meet this goal. The only proposals having this > characteristic are PIC and GetCert (when implemented on outboard > authentication servers). Proposals requiring modification to the > > > > Kelly Expires Jan 2002 [Page 19] > > Internet Draft July, 2001 > > > underlying IPsec implementation must be examined more closely. > > All proposals other than PIC and GetCert modify the underlying IPsec > implementation, and so introduce some probability that the security > of the underlying implementation (and therefore, that of the > connection) has been reduced. The XAUTH, HYBRID, and CRACK approaches > all directly modify IKE by adding new states and protocol elements. > This certainly increases code complexity, along with the probability > of an implementation error. However, this effect is most difficult to > quantify. > > In addition, all approaches other than PIC and GetCert (and perhaps > L2TP) require the SGW to act as a proxy in the user authentication > protocol. L2TP may avoid this by terminating the L2TP tunnel on a > host behind the SGW rather than on the SGW itself, but if this is > done, then there must also be some protocol between the L2TP > termination point and the SGW which permits access revocation if the > user fails to properly authenticate - otherwise, the L2TP server may > terminate the connection, but the SGW won't know it - which again > adds complexity to the SGW. > > > 7. Summary > > The various proposals come out on fairly equal footing regarding > several of the stated requirements, with differences emerging in the > following 3 areas: > > o increased SGW susceptibility to DoS attacks > > o increased SGW complexity > > o single sign-on support > > These are discussed in more detail below. > > 7.1 DoS Susceptibility > > XAUTH, HYBRID, ULA, CRACK, and L2TP are all susceptible to DoS > attacks under some circumstances. HYBRID and CRACK are trivially > susceptible to DoS attacks. PIC and GetCert only increase the SGW's > DoS susceptibility if they are implemented on the SGW. L2TP, ULA, and > XAUTH are less susceptible than HYBRID and CRACK if the remote user's > private key is securely contained, but only in this case. To the > extent that the private key is susceptible to compromise, the DoS > risk increases proportionally. As noted earlier, a private key stored > on the hard drive of a typical user system would not stand up to a > determined adversary. > > > > Kelly Expires Jan 2002 [Page 20] > > Internet Draft July, 2001 > > > While it may be argued that using a smartcard (or other secure > container) goes a long way toward resolving this problem, it must be > noted that this imposes a significant increase in the cost of the > solution, both economically and logistically. In this case, > smartcards (or whatever security container is used) must be provided > for each remote access user, and these must be managed. And if one is > stolen, it may be used for DoS attacks (or worse, unfettered access) > until it is discovered missing. > > An alternative to secure containers is to provide a short-lived key > at the time access is desired which is good for a limited time only. > The short lifetime of the key significantly narrows the window during > which it might be compromised, and if such a key were somehow > compromised, the damage potential would be bounded by its lifetime. > That is, if the key lifetime is sufficiently short, the only > realistic compromise scenario (for DoS purposes) entails gaining > control of the system while the key is valid and passing it along to > the attacker. However, an attacker with this capability can also gain > control of a system relying on a smartcard, and by proxy, full access > to the network beyond the SGW - so the smartcard is not much help in > this case, and in such a case, DoS attacks should be the least of our > concerns. > > > > 7.2 Code Complexity > > XAUTH, HYBRID, ULA, CRACK, and L2TP all significantly increase the > complexity of the IRAS code base, while PIC and GetCert need not be > implemented on the IRAS. > > > 7.3 Single Sign-on Support > > XAUTH, HYBRID, ULA, CRACK, and L2TP do not provide for single sign-on > support, while GetCert and PIC do (the short-lived certificate may be > used to connect to a redundant IRAS). > > > 7.4 Conclusion > > The only proposals which meet all criteria are GetCert and PIC (when > implemented on an outboard authentication server). > > > 8. Security Considerations > > The topic of this document is secure remote access. Security > > > > Kelly Expires Jan 2002 [Page 21] > > Internet Draft July, 2001 > > > considerations are discussed throughout the document. > > 9. Editors' Addresses > > Scott Kelly > RedCreek Communications > 3900 Newpark Mall Road > Newark, CA 94560 USA > email: skelly@redcreek.com > Telephone: +1 (510) 745-3969 > > 10. References > > [RFC2026] Bradner, S., "The Internet Standards Process -- > Revision 3", BCP 9, RFC 2026, October 1996. > > [KEYWORDS] Bradner, S., "Key Words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997 > > > [KR01] S. Kelly, S.Ramamoorthi, "Requirements for IPsec Remote Access > Scenarios", draft-ietf-ipsra-reqmts-03.txt (work in progress). > > > [XAUTH] Pereira and Beaulieu, "Extended Authentication within > ISAKMP/Oakley XAUTH)", draft-ietf-ipsec-isakmp-xauth-06.txt > (work in progress). > > > [MODECFG] R Pereira, S. Anand, B. Patel, "The ISAKMP Configuration Method", > draft-ietf-ipsec-isakmp-mode-cfg-05.txt (work in progress) > > [ULA] S. Kelly, J. Knowles, B. Aboba, "User-level Authentication > Mechanisms for IPsec", draft-kelly-ipsra-userauth-00.txt, > (work in progress) > > [CRACK] D Harkins, B Korver, D Piper, "IKE Challenge/Response for > Authenticated Cryptographic Keys", draft-harkins-ipsec-ike- > crack-00.txt (work in progress). > > [L2TPSEC] B. Patel, B. Aboba, W. Dixon, G. Zorn, S. Booth, "Securing > L2TP using IPSEC", draft-ietf-l2tpext-security-02.txt" > (work in progress) > > [PIC] Y. Sheffer, H. Krawczyk, "PIC, A Pre-IKE Credential > Provisioning Protocol ", draft-ietf-ipsra-pic-01.txt, > (work in progress) > > > > > Kelly Expires Jan 2002 [Page 22] > > Internet Draft July, 2001 > > > [GETCERT] Bellovin and Moskowitz, "Client Certificate and Key Retrieval > for IKE", draft-bellovin-ipsra-getcert-00.txt (work in progress). > > > 11. Full Copyright Statement > > Copyright (C) The Internet Society (1998). 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. > > > > > > > > > > > > > > > > > > > > > Kelly Expires Jan 2002 [Page 23] > From owner-ietf-ipsra@mail.vpnc.org Mon Jul 9 19:35:15 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA01090 for ; Mon, 9 Jul 2001 19:35:13 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f69MnNX02046 for ietf-ipsra-bks; Mon, 9 Jul 2001 15:49:23 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f69MnHm02040 for ; Mon, 9 Jul 2001 15:49:17 -0700 (PDT) Received: from toque.cisco.com (toque.cisco.com [161.44.208.153]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f69MlSH11220; Mon, 9 Jul 2001 15:47:30 -0700 (PDT) Received: from DDUKESW2K (ott-b1-dhcp-10-85-28-157.cisco.com [10.85.28.157]) by toque.cisco.com (Mirapoint) with SMTP id ABD09363; Mon, 9 Jul 2001 18:49:06 -0400 (EDT) Message-ID: <015901c108c9$733eaaa0$9d1c550a@cisco.com> Reply-To: "Darren Dukes" From: "Darren Dukes" To: "Darren Dukes" , "ietf-ipsra" References: <3B4502BE.3A7295CD@redcreek.com> <014b01c108c0$596fb280$9d1c550a@cisco.com> Subject: Re: evaluation draft Date: Mon, 9 Jul 2001 18:49:45 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Acronyms acronyms acronyms... Please note where I used IRAS in my last email it should have read AS (Authentication Server) for PIC. ----- Original Message ----- From: "Darren Dukes" To: "ietf-ipsra" Sent: Monday, July 09, 2001 5:44 PM Subject: Re: evaluation draft > > Scott, here are some initial comments. > > 1 - You should add a section stating provisioning complexities. If a user > wants to provision a remote access VPN but does not want to provision a PKI, > why would they want to deploy an AS for PIC, which is just a CA using > legacy authentication mechanisms for enrolment? > > 2 - You suggest a reduction in security with an increase in complexity > "Hence, the probability of an oversight or error which impacts on critical > system function is proportional to system complexity, and software > development experience to date suggests that as systems grow increasingly > complex, this probability nears unity." Is this your own idea or do you > have some data or a published authority that can back this up? > > 4 - Does an increase in complexity causing a unity decrease in security > also extend to provisioning of the security solution with multiple servers > that must now be configured? If so are the "Two additional goals" you state > in section 2 still valid? > > 5 - If a separate AS is not deployed for PIC but it exists on the SGW, PIC > and Hybrid have the same DoS vulnerabilities. > > 6 - If Hybrid and PIC offer the same vulnerabilities to DoS on the SGW then > both implementations must offer some "throttle" capability to avoid dieing > from a DoS attack. This negates the problem of disrupting existing traffic > with an IKE-based (or PIC-based) DoS attack does it not? > > 7 - Hybrid requires half of the DH computations that PIC does, especially > important if they are on the same SGW. This is worth mentioning in your > review of PIC > > 8 - I disagree with the Hybrid/Xauth issues: > You write "Xauth requires the SGW to participate in the user > authentication process, which increases SGW vulnerability both in terms of > complexity and denial of service." If the complexity of writing and > deploying an AS is anything close to the complexity of writing and testing > Hybrid then this argument also applies to PIC. > > You write "Adding an open-ended number of challenge-rsp exchanges to a > key exchange increases vulnerability to denial of service attack under some > circumstances, and absolutely increases the complexity of the key exchange > mechanism under all circumstances[... etc]" This is the same as the issue > above, and all SGW implementations must deal with this by throttling the > amount of processor time they will allow IKE (or PIC) to use > > You write "There may be some known ascii plaintext at fixed locations > within packets due to support for user prompts. [...]" I believe others have > commented on this too, but any protocol has known bytes in each packet. EAP > has message text as well, so you should include this in PIC if you believe > it is significant. > > You write "Xauth requires support for its companion, modecfg." Others > have already provided valid comments here... > > You write "[HYBRID] is trivially susceptible to DoS attacks, as it > requires the AS to engage in an unauthenticated Diffie-Hellman exchange > which includes an expensive public key operation, and then to continue the > conversation for some period of time beyond that, perhaps in error." Yes > and this should be throttled by the implementation to prevent DoS attacks. > PIC will also suffer from this if run on the SGW. > > > Overall an interesting read but I still believe PIC has too much > infrastructure and computational overhead as compared to Hybrid. > > Darren. > > > > > ----- Original Message ----- > From: "Scott G. Kelly" > To: > Sent: Thursday, July 05, 2001 8:13 PM > Subject: evaluation draft > > > > Hi All, > > > > Attached is a copy of the draft which compares pic, getcert, crack, ula, > > hybrid, and xauth that I promised months ago. I've submitted it to the > > ID editor (as a personal submission), but also wanted to archive it here > > in the mailing list. I vastly underestimated the amount of work > > involved, and feel as though I'd like to work on it for another week or > > so even now. On the other hand, we need to move forward, so I'm putting > > it out now in order to solicit comments. > > > > Scott > > > > > > > > > > > > > IPsec Remote Access Working Group Scott Kelly > > INTERNET-DRAFT RedCreek Communications > > draft-kelly-ipsra-eval-00.txt July, 2001 > > > > > > > > Comparing Proposed Solutions for > > IPsec Remote Access Legacy User Authentication > > > > > > > > Status of This Memo > > > > This document is an Internet Draft and is in full conformance with > > all provisions of Section 10 of [RFC2026]. Internet Drafts are > > working documents of the Internet Engineering Task Force (IETF), its > > areas, and working groups. Note that other groups may also distribute > > working documents as Internet Drafts. > > > > Internet-Drafts are draft documents valid for a maximum of six months > > and may be updated, replaced, or obsoleted by other documents at any > > time. It is inappropriate to use Internet-Drafts as reference > > material or to cite them other than as ``work in progress.'' > > > > The list of current Internet-Drafts can be accessed at > > > > http://www.ietf.org/ietf/1id-abstracts.txt > > > > The list of Internet-Draft Shadow Directories can be accessed at > > http://www.ietf.org/shadow.html. > > > > Comments on this document should be sent to the IETF IPsec remote > > access discussion list (ietf-ipsra@vpnc.org). > > > > > > Abstract > > > > A number of competing methods for integrating legacy remote access > > user authentication into IPsec have been proposed, resulting in > > confusion as to which method(s) might be best for solving the > > problems at hand. This document briefly compares these proposals in > > an effort to clarify the relative standing of each with respect to > > the problem space and requirements. > > > > > > > > > > > > > > > > > > > > > > Kelly Expires Jan 2002 [Page 1] > > > > Internet Draft July, 2001 > > > > > > Table of Contents > > > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 > > 1.2 Basic Problem Space Description . . . . . . . . . . . . . . . . 3 > > 1.3 Reader Prerequisites . . . . . . . . . . . . . . . . . . . . . . 4 > > 1.4 Requirements Terminology . . . . . . . . . . . . . . . . . . . . 4 > > 1.5 General Terminology . . . . . . . . . . . . . . . . . . . . . . 4 > > 2. General Solution Requirements . . . . . . . . . . . . . . . . . . 5 > > 3. Brief Enumeration of Proposed Solutions . . . . . . . . . . . . . 7 > > 4. Common Features of Proposed Solutions . . . . . . . . . . . . . . 8 > > 4.1 Common Issues for Proposals Supporting Preshared Keys . . . . . 8 > > 4.1.1 General issues for configurations using preshared keys . . . . 9 > > 4.1.2 Fixed Address (unique PSK) . . . . . . . . . . . . . . . . . . 10 > > 4.1.2 Non-fixed Address, Global Preshared Key . . . . . . . . . . . 10 > > 4.1.3 Non-fixed Address, Unique Preshared Key . . . . . . . . . . . 11 > > 4.2 General Issues For Configurations Using Mutual Certificates . . 11 > > 5. Comparing the Proposals . . . . . . . . . . . . . . . . . . . . . 12 > > 5.1 XAUTH/MODECFG . . . . . . . . . . . . . . . . . . . . . . . . . 12 > > 5.2 Hybrid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 > > 5.3 ULA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 > > 5.4 CRACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 > > 5.5 L2TP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 > > 5.6 PIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 > > 5.7 GetCert . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 > > 6. Comparison of Proposals to Requirements . . . . . . . . . . . . . 17 > > 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 > > 7.1 DoS Susceptibility . . . . . . . . . . . . . . . . . . . . . . . 20 > > 7.2 Code Complexity . . . . . . . . . . . . . . . . . . . . . . . . 21 > > 7.3 Single Sign-on Support . . . . . . . . . . . . . . . . . . . . . 21 > > 7.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 > > 8. Security Considerations . . . . . . . . . . . . . . . . . . . . . 21 > > 9. Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 > > 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 > > 11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 23 > > > > > > > > > > > > > > > > Kelly Expires Jan 2002 [Page 2] > > > > Internet Draft July, 2001 > > > > > > 1. Introduction > > > > > > The IPsec remote access working group (ipsra) was formed in order to > > settle upon a solution set for providing secure remote access using > > IPsec components. Integral to the secure remote access problem is the > > desire to provide support for existing legacy authentication > > mechanisms, most notably RADIUS and SecureID. A number of competing > > methods for integrating such user authentication into IPsec have been > > proposed, resulting in confusion as to which method(s) might be best > > for solving the problems at hand. This document briefly compares > > these proposals in an effort to clarify the relative standing of each > > with respect to the problem space and requirements. > > > > 1.2 Basic Problem Space Description > > > > Customers want to provide secure remote access to their networks > > using IPsec along with authentication methods which leverage > > currently deployed user authentication mechanisms (primarily RADIUS > > and SecureID). This is difficult, as currently defined authentication > > mechanisms for IPsec are symmetric, e.g. either both sides (the user > > and the security gateway) authenticate using a shared secret, or both > > sides authenticate using identical public key mechanisms (encryption > > or signatures). > > > > These mechanisms provide no support for the passphrases which are > > typically required for legacy mechanisms. While at first glance one > > might conclude that passwords are similar to shared secrets, and that > > some adaptation of the shared secret mechanism currently supported by > > IPsec would resolve this problem, there are at least two issues with > > this approach (ignoring for the moment that preshared keys are > > susceptible to dictionary attacks, and that users would often make > > this simpler by choosing easily guessed passphrases). > > > > First, there is the problem of identifying the correct secret to > > apply at the gateway. IKE, as currently defined, may only identify > > shared secrets by IP address if main mode is used, and for most > > remote access scenarios, the IP address of the remote user simply is > > not known a priori. Even if it were, this would be no help if a one > > time passphrase mechanism were in use. This implies that use of > > aggressive mode is required for this approach, and this raises a > > number of security issues due to vulnerabilities associated with > > aggressive mode. Also, many of the same issues relating to one time > > passphrases exist for aggressive mode. > > > > The second issue raised by using passphrases as preshared keys > > pertains to scalability. If passphrases are to be in any way useful > > from a security perspective, they must be unique for each user. Since > > > > > > > > Kelly Expires Jan 2002 [Page 3] > > > > Internet Draft July, 2001 > > > > > > the gateway must also use this same passphrase (it is being used as a > > shared secret), this requires that the gateway be configured with > > each remote user's unique identifier and passphrase. This becomes > > problematic as the number of remote users grows large. > > > > Further complicating matters, legacy mechanisms typically provide > > one-sided authentication for the user, implicitly trusting that the > > challenger (the gateway) is who/what it claims to be. However, IPsec > > provides for no such one-sided authentication technique. Hence, in > > order to support legacy authentication mechanisms within IPsec, it > > must either be possible to authenticate the user and the gateway > > asymmetrically, or it must be possible to derive a user credential > > from the legacy authentication process which may then be used to > > secure an IPsec connection. > > > > > > 1.3 Reader Prerequisites > > > > Reader familiarity with RFCs 2401-2412 is a minimum prerequisite to > > understanding the concepts discussed here. Familiarity with concepts > > relating to Public Key Infrastructures (PKIs) is also necessary, as > > is familiarity with the various secure remote access proposals > > discussed below ([XAUTH/MODECFG], [HYBRID], [ULA], [CRACK], [PIC], > > [L2TPSEC], [GETCERT]). An understanding of various classes of attacks > > on cryptographic primitives and network connections will further > > facilitate understanding. > > > > > > 1.4 Requirements Terminology > > > > The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, > > SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this > > document, are to be interpreted as described in [KEYWORDS]. > > > > > > 1.5 General Terminology > > > > Following are definitions of terms as they are used in this document. > > > > o MiM: Man-in-the-Middle, as in the case where an adversary > > positions an intercepting system between two endpoints, and > > traffic in both directions must pass through this intercepting > > system, giving the adversary the opportunity to modify the > > data stream in either or both directions. > > > > o DoS: Denial of Service, as in the case where a system is > > prevented from delivering essential services due to outside > > interference. > > > > > > > > Kelly Expires Jan 2002 [Page 4] > > > > Internet Draft July, 2001 > > > > > > o User Identifier: this term refers to the value used to uniquely > > identify the remote user, typically a user name. > > > > o Passphrase: this term refers to the value the remote user > > presents in conjunction with the user identifier in order to > > verify the user's identity; it may be a value the user commits > > to memory (such as an ascii string), it may be retrieved from > > storage, or it may be generated by a device the user possesses or > > interacts with at the time of the access attempt. In the case of > > n-factor authentication mechanisms, a user may be required to > > present multiple passphrases in order to satisfy admission > > criteria. > > > > o SGW - Security GateWay, the IPsec termination point for the > > target network to which remote acess is to be provided. > > > > o PSK - PreShared Key, as in a shared secret value used for proof > > of identity and/or group membership. > > > > o IRAC - Ipsec Remote Access Client > > > > o IRAS - Ipsec Remote Access Server (or SGW) > > > > o DH exchange - Diffie-Hellman key exchange > > > > 2. General Solution Requirements > > > > In evaluating the various proposed solutions, the first order of > > business is to hold them up against the user authentication > > requirements for secure remote access to determine how completely > > satisfied the requirements are by each proposal. Basic requirements > > for user authentication as it applies to secure remote access using > > IPsec are presented in [KR01], and these requirements are not > > detailed here, except for a brief synopsis (taken from [KR01]). > > > > In general, proposed IPsec remote access mechanisms should meet the > > following goals: > > > > o should provide direct support for legacy user authentication > > systems such as RADIUS > > > > o should encourage migration from existing low-entropy > > password-based systems to more secure authentication systems > > > > o if legacy support cannot be provided without some sort of > > migration, the impact of such migration should be minimized > > > > o user authentication information must be protected against > > > > > > > > Kelly Expires Jan 2002 [Page 5] > > > > Internet Draft July, 2001 > > > > > > eavesdropping and replay (including the user identity) > > > > o single sign-on capability should be provided in configurations > > employing load-balancing and/or redundancy > > > > o n-factor authentication mechanisms should be supported > > > > Two additional goals not listed above are suggested in this document: > > > > o Security gateway vulnerability to DoS attacks should be > > minimized, and if possible, should not be greater than the > > vulnerability which exists in SGW systems not providing remote > > access > > > > o The chosen mechanism(s) should minimize any reduction in the > > baseline security of the underlying IPsec connection > > > > In most cases, the motivation for each of the security goals in the > > initial list above is obvious. However, the need for the two > > additional suggested goals may be less evident, so supporting > > discussion is provided below. > > > > Regarding vulnerability to DoS attacks, we should note that the SGW > > represents a shared access point for the target network, and as such, > > has the potential to adversely affect multiple users in case of > > failure, both inside and outside of the target network. Further, in > > cases where there is only one SGW for a given network, it represents > > a single point of failure. Hence, it seems reasonable to suggest that > > the chosen solution should not increase the DoS vulnerability of this > > critical system if this can be avoided. > > > > Regarding the security of the underlying connection, IPsec, as > > currently defined, provides for a baseline measure of security with > > certain assumptions. That is, if we may assume that the keying > > material generated by the DH exchange is effectively random (i.e. > > unguessable), and by implication that the keying material used for > > authenticating the key exchange is effectively random (as well as > > securely stored), then other assumptions regarding relative security > > of the resulting connection (i.e. the effort required to compromise > > the connection) are warranted. > > > > However, it is possible to choose methods of producing and/or storing > > authentication keying material which invalidate these assumptions. If > > such a method is chosen, then the baseline security of the underlying > > connection will be reduced when compared to a connection which uses > > more secure keying material production and storage methods. > > > > This implies that the overall security characteristics of the user > > > > > > > > Kelly Expires Jan 2002 [Page 6] > > > > Internet Draft July, 2001 > > > > > > authentication mechanism may directly influence the security of the > > underlying IPsec connection. This being the case, it seems reasonable > > to suggest that either the chosen mechanism should not reduce the > > baseline effectiveness of the underlying IPsec connection in > > comparison to non-remote-access connections, or (if this cannot be > > avoided) that the resulting security reduction should be minimized. > > > > A secondary area of concern pertains to the manner in which we might > > unwittingly reduce security by adding functionality which interacts > > with the base IPsec subsystem in unforseen ways. As systems grow in > > complexity, it becomes increasingly difficult to reasonably assert > > that such unforseen interactions are either not possible or not > > occurring. This is largely due to the increase in the number of > > system inputs and their corresponding outputs, and to our inability > > to accurately characterize these quantities. That is, increasing > > complexity makes the task of recognizing all of the possible system > > input/output combinations quite difficult (if not impossible) for a > > human mind. Hence, the probability of an oversight or error which > > impacts on critical system function is proportional to system > > complexity, and software development experience to date suggests that > > as systems grow increasingly complex, this probability nears unity. > > > > In response to this issue, computer-based analytical techniques have > > been developed to assist in the task of characterizing complex > > systems. These techniques seem effective in transcending the > > computational and organizational limitations of the human mind in > > many cases. However, while computer-based analytical engines might > > improve performance with respect to organizing and understanding > > complexity, these engines are ultimately designed and interpreted by > > the same sorts of agents as they are intended to aid, and hence may > > not be as accurate as hoped. > > > > Recognition of the implications of these observations is apparently > > difficult for some, perhaps due in part to the lack of clearcut > > quantifying measures for accuracy (or in this case, security) as a > > function of code complexity. The fact that one cannot insert the > > number of added lines of code into an equation to arrive at the > > conclusion that either a critical bug has or has not been introduced > > makes it difficult for some to accept the criticality of this issue > > when designing and implementing secure systems. Nonetheless, given > > the stakes in scenarios requiring high security, the implications of > > added complexity must not be ignored. Hence, we should strive to > > balance the added complexity of the chosen solution with other design > > goals. > > > > > > 3. Brief Enumeration of Proposed Solutions > > > > > > > > > > Kelly Expires Jan 2002 [Page 7] > > > > Internet Draft July, 2001 > > > > > > As noted, there are a number of proposed solutions to date. These are > > as follows: > > > > o XAUTH/MODECFG - XAUTH refers to eXtended AUTHentication (within > > IKE), and is detailed in [XAUTH]. It is tightly bound to another > > proposal, the ISAKMP configuration method [MODECFG]. > > > > o HYBRID - this proposal builds upon the XAUTH/MODECFG combination, > > adding one-sided server authentication. It is detailed in > > [HYBRID]. > > > > o ULA - ULA refers to User-Level Authentication; this proposal was > > withdrawn due to various shortcomings, but is included here for > > the sake of completeness. See [ULA] for additional detail. > > > > o CRACK - CRACK stands for Challenge/Response for Authenticated > > Cryptographic Keys, and is discussed in [CRACK]. > > > > o L2TP - L2TP (Layer 2 Tunneling Protocol) uses PPP-based > > authentication. Use of L2TP with IPsec is discussed in > > [L2TPSEC]. > > > > o PIC - PIC stands for Pre-Ike Credential provisioning protocol, > > and is discussed in [PIC] > > > > o GetCert - GetCert is a shorthand name for "Client Certificate and > > Key Retrieval for IKE", and is discussed in [GETCERT]. > > > > This document provides a (currently very) brief analysis of how each > > of these stacks up against the remote access user authentication > > requirements discussed above. > > > > > > 4. Common Features of Proposed Solutions > > > > Before looking at the individual proposals, it may be useful to > > examine some of the issues which multiple proposals have in common. A > > number of the proposals provide for the use of preshared keys to > > authenticate an IKE session prior to authenticating the user (XAUTH, > > ULA, L2TP), and an overlapping subset provides for the use of public > > key mechanisms for the same purpose. These are discussed below. > > > > 4.1 Common Issues for Proposals Supporting Preshared Keys > > > > A subset of the proposals (XAUTH/MODECFG, ULA, L2TP) provide the > > ability to use preshared keys as a part of the authentication > > process. All of these proposals, when used in this manner, share > > common issues, which are discussed in section 4.1.1 below. > > > > > > > > Kelly Expires Jan 2002 [Page 8] > > > > Internet Draft July, 2001 > > > > > > In addition, preshared keys may be used in a number of network > > configurations, including the following: > > > > o remote client uses fixed IP address with unique preshared key > > > > o remote client uses non-fixed IP address with global preshared key > > > > o remote client uses non-fixed IP address with unique preshared key > > (requires use of IKE aggressive mode) > > > > The individual issues associated with these are discussed in sections > > 4.1.2-4.1.4. > > > > > > 4.1.1 General issues for configurations using preshared keys > > > > Preshared keys, when compared to well-managed public/private key > > pairs, provide a significantly weaker form of authentication for > > IPsec. Brute force man-in-the-middle attacks on the preshared keys > > are possible. For example, an adversary might juxtapose himself > > between the remote user and the security gateway, and attempt to > > intercept the remote access user's connection attempt with the > > gateway. If the SGW can be impersonated in this manner by the > > attacker, the remote access client will provide the attacker with > > enough information so that the preshared key may be subjected to an > > offline dictionary attack. > > > > Once a preshared key is compromised, additional information regarding > > the user identity and legacy authentication passphrase is vulnerable, > > and if the authentication passphrase is compromised, the system has > > failed entirely: the attacker may impersonate the remote user. This > > risk may be mitigated by using one-time legacy authentication tokens, > > but it should be noted that the identity information will still not > > be protected. Further, if an attacker with MiM capability succeeds in > > determining the preshared key, he may then launch MiM attacks on > > subsequent remote access sessions in which he sits transparently in > > the connection path, impersonating the sgw to the remote user, and > > impersonating the remote user to the sgw. The implications of this > > are clear. > > > > These risks are not mitigated by using aggressive mode with preshared > > keys, which is a much more likely scenario for remote access given > > that the IP address of the remote access user will vary. Furthermore, > > the attacker need not interact with the data stream in this case, but > > only needs to observe the exchange. Aggressive mode proceeds as > > follows: > > > > Remote User Security Gateway > > > > > > > > Kelly Expires Jan 2002 [Page 9] > > > > Internet Draft July, 2001 > > > > > > ------------------ ---------------------- > > HDR, SA, KE, Ni, IDii --> > > <-- HDR, SA, KE, Nr, IDir, HASH_R > > HDR, HASH_I --> > > > > Note that in this case, the attacker has access to the HASH_R value, > > along with all relevant inputs, so that a dictionary attack may again > > be mounted on the preshared key. > > > > Also note that in this case the SGW is forced to compute HASH_R prior > > to verifying the remote user's identity, implying an increased > > vulnerability to DoS attacks, and if the user (attacker) sends a > > spurious third message, the SGW must complete the DH exponentiation > > to detect it. In fact, methods which rely on preshared keys and > > aggressive mode may be trivially susceptible to DoS attacks due to > > this vulnerability, in that an attacker has but to construct a valid > > IDii payload, and this may be used again and again in order to cause > > the SGW to repeatedly allocate context memory, compute HASH_R, and > > perhaps compute the DH value. > > > > Finally, support for use of preshared keys does scale well, and does > > not encourage migration to stronger authentication mechanisms, and in > > fact, may encourage the opposite. Hence, it may be prudent from a > > security perspective to disallow such support in any proposed > > solution. > > > > Issues specific to particular uses of preshared keys for the various > > network configurations enumerated in section 4.1 above are discussed > > in the following sections. > > > > > > 4.1.2 Fixed Address (unique PSK) > > > > In the case where the IP address is fixed, IKE main mode may be used > > with a preshared key. This is an unusual situation for remote access, > > but it does present the ability to use a unique preshared key for > > each user, meaning it may be at least as secure as typical site-to- > > site configurations employing preshared keys. However, preshared keys > > within main mode are susceptible to attack as noted above, so this > > may provide a false sense of security. Also, use of per-user > > preshared keys raises obvious scalability issues as the number of > > users grows. > > > > > > 4.1.2 Non-fixed Address, Global Preshared Key > > > > In some cases, a single preshared key may be used for all remote > > users. A global preshared key has obvious shortcomings, and must not > > > > > > > > Kelly Expires Jan 2002 [Page 10] > > > > Internet Draft July, 2001 > > > > > > be recommended. Such keys may be compromised in numerous ways without > > detection, and once this has occurred, eavesdropping and MiM attacks > > are greatly simplified. This is unacceptable from a security > > perspective. > > > > > > 4.1.3 Non-fixed Address, Unique Preshared Key > > > > Unique preshared keys may be used with non-fixed addresses if IKE > > aggressive mode is used. However, this method is vulnerable to DoS > > attacks on the sgw, as the user identity is not protected, and > > intercepted packets may be replayed, causing the sgw to needlessly > > engage in hash and exponentiation calculations. This method is also > > susceptible to dictionary attacks on the preshared key. In addition, > > per-user keys do not scale as the number of users grows. > > > > > > 4.2 General Issues For Configurations Using Mutual Certificates > > > > In general, public key authentication mechanisms are much stronger > > than shared secret mechanisms. However, there are a number of issues > > even with these. Due to the overhead associated with authentication > > operations, there is some unavoidable DoS susceptibility. For > > example, using IKE main mode, an attacker may cause the SGW to > > needlessly perform expensive public key and/or Diffie-Hellman > > operations just to prove that the attacker is not authorized to > > connect. If aggressive mode is used instead of main mode, the SGW may > > be forced to generate its own signature without first verifying the > > identity of the remote user. A sufficient number of such spurious > > computations will impinge upon the SGW's ability to deliver services > > to authorized users. > > > > Note that these issues exist for site to site installations as well > > as remote access scenarios, although in site-to-site connections the > > remote IP address may be used by the SGW as an additional filter, > > raising the bar somewhat for the attacker. In selecting such a > > mechanism for remote access, we should strive to not introduce any > > more vulnerability than already exists in site to site scenarios. > > > > A second area of consideration pertains to the storage mechanism for > > the private key used to authenticate the user. If this key is > > compromised, the entity it authenticates may be impersonated without > > detection. Hence, the integrity of the derived authentication is > > directly proportional to the security of the private key storage > > technique. > > > > If the private key is stored on the hard drive of the subject system, > > it is vulnerable to a number of attacks, and may be compromised > > > > > > > > Kelly Expires Jan 2002 [Page 11] > > > > Internet Draft July, 2001 > > > > > > without detection. Therefore, the integrity of the resulting > > authentication in this case is directly proportional to the security > > of the system in which the hard drive resides. If this system is > > hardened, physical access is strictly controlled, and system > > configuration is strictly controlled, the associated level of > > security may be relatively high. However, if the system is (for > > example) a laptop containing a commercial operating system, and the > > user has typical freedoms regarding system usage and configuration, > > the associated level of security is likely quite low. > > > > In such cases, the private key may be compromised without detection > > in numerous ways, and even if an additional factor of authentication > > is used (such as a username/passphrase pair) the SGW is subject to > > increased vulnerability to DoS attacks (the attacker can negotiate > > multiple phase 1 SAs using the private key). If a post-IKE legacy > > user authentication mechanism is used, the underlying user > > authentication mechanism is also subject to attack, which may > > ultimately expose the protected network(s) and data. > > > > These risks may be mitigated if the private key is securely contained > > (e.g. in a smartcard), and if key usage requires an additional factor > > of authentication in advance (i,.e. stealing the key container does > > not necessarily guarantee access). However, it should be recognized > > that a sufficiently secured private key may also obviate the need for > > a username-passphrase exchange, unless n-factor authentication is > > required. > > > > So, while public key methods may seem to remedy many of the issues > > raised by the use of preshared keys, we must be careful to evaluate > > the relative security of the private keys in such scenarios. > > Solutions relying on insufficiently secured private keys are > > correspondingly insecure. > > > > 5. Comparing the Proposals > > > > 5.1 XAUTH/MODECFG > > > > Xauth is a user authentication mechanism which functions by first > > forming a phase 1 IKE SA using one of the conventional IKE > > authentication techniques (preshared key or public key), and by then > > extending the IKE exchange to include additional user authentication > > exchanges. The xauth payloads ride atop an additional proposed IKE > > extension (referred to as "modecfg" or "ikecfg") which is essentially > > a DHCP-like mechanism meant to provide host configuration parameters > > to remote access clients. > > > > Xauth may be deployed in at least five different configurations: > > > > > > > > > > Kelly Expires Jan 2002 [Page 12] > > > > Internet Draft July, 2001 > > > > > > o main mode using unique preshared keys (fixed IRAC address) > > o main mode using global preshared key (non-fixed IRAC address) > > o aggressive mode using unique or global preshared key and keyid > > o main mode using certificates > > o aggressive mode using certificates > > > > When used with preshared keys, xauth suffers from all of the > > associated shortcomings discussed above in section 4.1. When used > > with certificates, either the associated private keys are adequately > > safeguarded, or they are not. If so, xauth is superfluous, unless n- > > factor authentication is required. If not, the associated > > shortcomings are present. > > > > Specific xauth issues (in addition to the general issues discussed > > above) include the following: > > > > o Xauth requires the SGW to participate in the user authentication > > process, which increases SGW vulnerability both in terms of > > complexity and denial of service. > > > > o Adding an open-ended number of challenge-rsp exchanges to a key > > exchange increases vulnerability to denial of service attack > > under some circumstances, and absolutely increases the complexity > > of the key exchange mechanism under all circumstances. While an > > open-ended exchange may not be entirely avoidable given the > > n-factor authentication requirement, xauth does not begin such > > exchanges until a phase 1 IKE SA has been instantiated, and this > > with either limited or no knowledge of the user identity in > > several of the supported configurations. The overhead associated > > with the DH exchange is significant, and the fact that an > > anonymous peer may force expenditure of this effort implies that > > a system supporting the associated configuration is trivially > > susceptible to denial of service. Further, once such phase 1 > > sessions are established, the SGW may be "led on" by a malicious > > peer for some (hopefully limited) period of time, guaranteeing > > that the associated system resources will remain unavailable > > during this period. > > > > o Xauth requires proxy support in the SGW for up to 16 different > > authentication methods, which greatly increases system > > complexity. > > > > o There may be some known ascii plaintext at fixed locations within > > packets due to support for user prompts. The amount of text will > > normally be small, but should not be ignored. If a reusable > > passphrase is contained within the xauth exchange, an attacker > > may have significant motivation for breaking the IKE session > > encryption, and known plaintext will simplify this task. > > > > > > > > Kelly Expires Jan 2002 [Page 13] > > > > Internet Draft July, 2001 > > > > > > o Xauth requires support for its companion, modecfg. This > > duplicates some of the functionality of DHCP, but lacks support > > for critical components, implying that it is redundant, and > > therefore adds unnecessary complexity. However, one has no choice > > but to implement modecfg if one wishes to implement xauth. > > > > > > 5.2 Hybrid > > > > The "Hybrid" authentication mechanism [HYBRID] attempts to address > > some of the shortcomings of xauth, most notably the need to support > > global preshared keys when remote access client certificates are not > > available. The hybrid mechanism modifies the xauth mechanism by > > requiring the IRAS to authenticate itself using public key > > techniques, and deferring user authentication until after the phase 1 > > IKE SA is in place. That is, hybrid requires the IRAS to authenticate > > to the IRAC, but not vice versa - it is a one-sided authentication. > > > > This mechanism is trivially susceptible to DoS attacks, as it > > requires the IRAS to engage in an unauthenticated Diffie-Hellman > > exchange which includes an expensive public key operation, and then > > to continue the conversation for some period of time beyond that, > > perhaps in error. In addition, all of the specific xauth > > shortcomings not relating specifically to preshared keys apply > > equally to hybrid. > > > > > > 5.3 ULA > > > > The previously proposed ULA method* [ULA] consists in forming an > > authenticated phase 1 SA in the same manner as xauth, followed by > > creation of a phase 2 SA whose sole purpose is to protect the > > authentication exchange. Following successful authentication, the > > phase 2 SA is either replaced, or the selectors are modified to > > permit access to appropriate resources. While this method improves > > somewhat on xauth by providing the ability to offload the user > > authentication to an outboard server (reachable through the tunnel), > > it suffers from many of the same problems as xauth. In particular, > > this method has the following shortcomings: > > > > o if preshared keys are used, this technique suffers from all of > > the general shortcoming associated with these which were > > identified above, e.g. vulnerability to MiM, offline dictionary > > attacks, undetected compromise, lack of scalability, etc. > > > > o requires IRAS to create phase 1 and phase 2 SAs without verifying > > user identity; this has obvious DoS implications, and is also > > susceptible to attacks on the underlying authentication > > > > > > > > Kelly Expires Jan 2002 [Page 14] > > > > Internet Draft July, 2001 > > > > > > infrastructure. These risks may be mitigated if mutual > > certificates are used, but as with xauth, either the user's > > private key is securely stored or not. If so, ULA is superfluous > > unless n-factor authentication is required, and if not, the > > associated shortcomings are present. > > > > *This proposal was withdrawn due to security issues > > > > > > 5.4 CRACK > > > > The CRACK technique [CRACK] integrates the user authentication > > process into the key exchange negotiation within IKE by defining a > > new exchange type. The IRAS authenticates using public key > > techniques, while the user authenticates using an identity and one or > > more passphrases. The exchange proceeds as follows: > > > > Client (I) Gateway (R) > > ----------- ----------- > > HDR, SAi, KEi, Ni > > [, CERTREQ] ---> > > <--- HDR, SAr, [CERT, ] KEr, > > SIG1, Nr > > HDR*, CHRE, PK ---> > > <--- HDR*, < SIG2 | CHRE > > > HDR*, < SIG3 | CHRE > ---> > > > > For payload definitions, see [CRACK]. This technique limits the > > denial of service implications for the IRAS when compared to xauth, > > hybrid, or ula, as the user must authenticate very early in the > > protocol. However, this method suffers from the following > > shortcomings: > > > > o IRAS must produce signature prior to authenticating user > > o IRAS must complete DH computation to detect spurious second > > message from attacker > > o IRAS must participate in the legacy user authentication process > > o requires support for an additional IKE exchange type > > > > > > 5.5 L2TP > > > > The L2TP user authentication mechanism is very similar to the ULA > > mechanism, and consists in forming both phase 1 and phase 2 SAs prior > > to authenticating the user. Hence, it suffers from precisely the same > > shortcomings as ULA (and by proxy, many of the shortcomings of > > xauth). However, the L2TP method also completely removes the user > > authentication from IPsec and moves it into PPP, so that per-user > > > > > > > > Kelly Expires Jan 2002 [Page 15] > > > > Internet Draft July, 2001 > > > > > > network access security must also be managed within the L2TP/PPP > > subsystem. This has significant implications in terms of increased > > system complexity. > > > > The current proposals for using L2TP with IPsec suggest using a > > "machine certificate" to authenticate the IKE SA. Note that as with > > xauth, either the user's private key is securely stored or not. If > > so, the L2TP user authentication may be superfluous (unless n-factor > > authentication is required), and if not, the associated shortcomings > > are present. > > > > > > 5.6 PIC > > > > The PIC mechanism provides a method for integrating legacy user > > authentication with existing IPsec deployments without the need for > > modifying the underlying IPsec implementations. This is accomplished > > by authenticating the user outside of the IPsec session proper, and > > providing the user with a short-lived certificate which may then be > > used within IKE using currently defined public key authentication > > mechanisms. > > > > The PIC method accomplishes user authentication using an ISAKMP > > exchange which supports legacy mechanisms, and then provides the user > > with a private/public keypair and certificate which are used for > > subsequent authentication operations with the security gateway. While > > PIC may be terminated by the target security gateway, it may also be > > terminated by a separate authentication server. The exchange is as > > follows: > > > > Client Authentication Server > > ------ --------------------------- > > (1) HDR, SA, KE, Ni --> > > > > (2) <-- HDR, SA, KE, Nr, IDir,[CERT,] > > SIG_R, HASH, [,...] > > > > (3) HDR*, HASH, EAP, [EAP...,] --> > > [CREDENTIAL-REQUEST] > > > > (4) <-- HDR*, HASH, EAP, [EAP...,] > > [CREDENTIAL] > > > > Security issues with this method include the following: > > > > o if PIC is run on the sgw, the sgw is subject to DoS attacks due > > the fact that it must generate a signature and compute a DH > > exponential prior to authenticating the remote access user. > > > > > > > > Kelly Expires Jan 2002 [Page 16] > > > > Internet Draft July, 2001 > > > > > > o separate connections are required for authentication and access; > > however, this implementation detail may be rendered transparent > > to the user > > > > > > > > 5.7 GetCert > > > > The GetCert method is a percursor to PIC, having provided the first > > example of the underlying model: as a result of a non-IPsec user > > authentication exchange, the user obtains a certificate which is used > > to authenticate a subsequent IKE session. The primary difference > > between GetCert and PIC is in the transport. While PIC runs over a > > new ISAKMP exchange, GetCert is completely independent of IPsec, and > > runs over a HTTPS/TCP connection. > > > > Security issues with this method include the following: > > > > o if GetCert is run on the IRAS, the IRAS is subject to DoS attacks > > due the fact that it must field incoming SSL connections from > > unauthenticated users > > > > o separate connections are required for authentication and access; > > however, this implementation detail may be rendered transparent > > to the user. > > > > > > 6. Comparison of Proposals to Requirements > > > > All of the proposed mechanisms solve the most basic problem, which is > > to authenticate remote access users by way of legacy authentication > > systems. However, they do so in several different ways. The > > techniques fall into 3 general categories, from a high level: > > > > o those which complete IPsec negotiation (phase 1 and/or phase 2 > > IKE) prior to authenticating the user (XAUTH, HYBRID, ULA, L2TP). > > > > o those which integrate the user authentication into IKE phase > > 1 negotiation (CRACK). > > > > o those which move the user interaction outside of IPsec > > entirely (PIC, GETCERT) > > > > Another way to group these is as follows: > > > > o those which require the IRAS to participate in the user > > authentication process (XAUTH, HYBRID, ULA, L2TP, CRACK) > > > > > > > > > > Kelly Expires Jan 2002 [Page 17] > > > > Internet Draft July, 2001 > > > > > > o those which do not require the IRAS to participate in the user > > authentication process (PIC, GETCERT) > > > > > > > > Recalling our goals from section 2, it is appropriate to compare the > > proposals against each of these at this time. > > > > 6.1 Provide direct support for legacy user authentication systems > > such as RADIUS > > > > All proposals meet this goal. > > > > > > 6.2 Encourages migration from existing low-entropy password-based > > systems to more secure authentication systems > > > > Proposals requiring use of public key mechanisms certainly meet this > > goal, while proposals supporting both preshared keys and public key > > mechanisms meet it to a lesser extent. PIC, GETCERT, CRACK, and > > HYBRID all require support for public key mechanisms. If XAUTH, ULA, > > and L2TP are used with preshared keys, they do not meet this goal. > > > > > > 6.3 If legacy support cannot be provided without some sort of > > migration, the impact of such migration should be minimized > > > > Since all proposals meet 6.1, this is moot. > > > > > > 6.4 User authentication information must be protected against > > eavesdropping and replay (including the user identity) > > > > Proposals requiring the use of aggressive mode do not meet this goal, > > meaning the preshared key modes of XAUTH, ULA, and L2TP. It might be > > argued that these mechanisms may use preshared keys with fixed IP > > addresses (and hence use main mode), but this raises obvious SGW > > scaling issues, and therefore these cases do not represent likely > > remote access scenarios. Hence, XAUTH, ULA, and L2TP only meet this > > goal when used with IKE main mode and public keys. All other > > proposals meet this goal unconditionally. > > > > > > 6.5 Single sign-on capability should be provided in configurations > > employing load-balancing and/or redundancy > > > > Only proposals which permit the user to instantiate a connection with > > a redundant IRAS without re-entering user authentication information > > > > > > > > Kelly Expires Jan 2002 [Page 18] > > > > Internet Draft July, 2001 > > > > > > (username, password, etc) meet this goal, i.e. PIC and GetCert. > > > > > > 6.6 N-factor authentication mechanisms should be supported > > > > All proposals meet this goal. > > > > > > 6.7 Security gateway vulnerability to DoS attacks should be > > minimized, and if possible, should not be greater than the > > vulnerability which exists in SGW systems not providing remote > > access. > > > > Proposals requiring no modification to the underlying IPsec > > implementation unconditionally meet this goal. The only proposals > > having this characteristic are PIC and GetCert, when they are run on > > outboard authentication servers. Proposals requiring modification to > > the underlying IPsec implementation must be examined more closely. > > > > All members of the class of proposals which defer user authentication > > until after a phase 1 SA has been negotiated (XAUTH, HYBRID, ULA, > > L2TP) are more vulnerable to DoS attacks than those not sharing this > > characteristic. CRACK, while not strictly in this class (it > > authenticates the user *during* phase one), must also be considered > > with this group due to other similarities. Of these proposals, HYBRID > > and CRACK are clearly the most vulnerable, since they require the SGW > > to perform Diffie-Hellman and public key computations for an > > unauthenticated peer. > > > > In the case of the other 3, the DoS implications might be minimized > > if main mode with (random) preshared key authentication were used for > > phase 1, but this is not feasible due to scaling issues. Hence, for > > XAUTH, ULA, and L2TP, main mode with signatures is the only realistic > > approach. This has a slightly higher DoS risk, but no more so than > > for other non-remote-access IKE exchanges using public key > > techniques. However, the validity of this assumption depends upon > > the security of the private keys used for authenticating the remote > > access client. As noted previously, if this key is not securely > > stored, DoS attacks become trivial for a determined adversary. > > > > > > 6.8 The chosen mechanism(s) should minimize any reduction in the > > baseline security of the underlying IPsec connection > > > > Proposals requiring no modification to the underlying IPsec > > implementation clearly meet this goal. The only proposals having this > > characteristic are PIC and GetCert (when implemented on outboard > > authentication servers). Proposals requiring modification to the > > > > > > > > Kelly Expires Jan 2002 [Page 19] > > > > Internet Draft July, 2001 > > > > > > underlying IPsec implementation must be examined more closely. > > > > All proposals other than PIC and GetCert modify the underlying IPsec > > implementation, and so introduce some probability that the security > > of the underlying implementation (and therefore, that of the > > connection) has been reduced. The XAUTH, HYBRID, and CRACK approaches > > all directly modify IKE by adding new states and protocol elements. > > This certainly increases code complexity, along with the probability > > of an implementation error. However, this effect is most difficult to > > quantify. > > > > In addition, all approaches other than PIC and GetCert (and perhaps > > L2TP) require the SGW to act as a proxy in the user authentication > > protocol. L2TP may avoid this by terminating the L2TP tunnel on a > > host behind the SGW rather than on the SGW itself, but if this is > > done, then there must also be some protocol between the L2TP > > termination point and the SGW which permits access revocation if the > > user fails to properly authenticate - otherwise, the L2TP server may > > terminate the connection, but the SGW won't know it - which again > > adds complexity to the SGW. > > > > > > 7. Summary > > > > The various proposals come out on fairly equal footing regarding > > several of the stated requirements, with differences emerging in the > > following 3 areas: > > > > o increased SGW susceptibility to DoS attacks > > > > o increased SGW complexity > > > > o single sign-on support > > > > These are discussed in more detail below. > > > > 7.1 DoS Susceptibility > > > > XAUTH, HYBRID, ULA, CRACK, and L2TP are all susceptible to DoS > > attacks under some circumstances. HYBRID and CRACK are trivially > > susceptible to DoS attacks. PIC and GetCert only increase the SGW's > > DoS susceptibility if they are implemented on the SGW. L2TP, ULA, and > > XAUTH are less susceptible than HYBRID and CRACK if the remote user's > > private key is securely contained, but only in this case. To the > > extent that the private key is susceptible to compromise, the DoS > > risk increases proportionally. As noted earlier, a private key stored > > on the hard drive of a typical user system would not stand up to a > > determined adversary. > > > > > > > > Kelly Expires Jan 2002 [Page 20] > > > > Internet Draft July, 2001 > > > > > > While it may be argued that using a smartcard (or other secure > > container) goes a long way toward resolving this problem, it must be > > noted that this imposes a significant increase in the cost of the > > solution, both economically and logistically. In this case, > > smartcards (or whatever security container is used) must be provided > > for each remote access user, and these must be managed. And if one is > > stolen, it may be used for DoS attacks (or worse, unfettered access) > > until it is discovered missing. > > > > An alternative to secure containers is to provide a short-lived key > > at the time access is desired which is good for a limited time only. > > The short lifetime of the key significantly narrows the window during > > which it might be compromised, and if such a key were somehow > > compromised, the damage potential would be bounded by its lifetime. > > That is, if the key lifetime is sufficiently short, the only > > realistic compromise scenario (for DoS purposes) entails gaining > > control of the system while the key is valid and passing it along to > > the attacker. However, an attacker with this capability can also gain > > control of a system relying on a smartcard, and by proxy, full access > > to the network beyond the SGW - so the smartcard is not much help in > > this case, and in such a case, DoS attacks should be the least of our > > concerns. > > > > > > > > 7.2 Code Complexity > > > > XAUTH, HYBRID, ULA, CRACK, and L2TP all significantly increase the > > complexity of the IRAS code base, while PIC and GetCert need not be > > implemented on the IRAS. > > > > > > 7.3 Single Sign-on Support > > > > XAUTH, HYBRID, ULA, CRACK, and L2TP do not provide for single sign-on > > support, while GetCert and PIC do (the short-lived certificate may be > > used to connect to a redundant IRAS). > > > > > > 7.4 Conclusion > > > > The only proposals which meet all criteria are GetCert and PIC (when > > implemented on an outboard authentication server). > > > > > > 8. Security Considerations > > > > The topic of this document is secure remote access. Security > > > > > > > > Kelly Expires Jan 2002 [Page 21] > > > > Internet Draft July, 2001 > > > > > > considerations are discussed throughout the document. > > > > 9. Editors' Addresses > > > > Scott Kelly > > RedCreek Communications > > 3900 Newpark Mall Road > > Newark, CA 94560 USA > > email: skelly@redcreek.com > > Telephone: +1 (510) 745-3969 > > > > 10. References > > > > [RFC2026] Bradner, S., "The Internet Standards Process -- > > Revision 3", BCP 9, RFC 2026, October 1996. > > > > [KEYWORDS] Bradner, S., "Key Words for use in RFCs to Indicate > > Requirement Levels", BCP 14, RFC 2119, March 1997 > > > > > > [KR01] S. Kelly, S.Ramamoorthi, "Requirements for IPsec Remote > Access > > Scenarios", draft-ietf-ipsra-reqmts-03.txt (work in > progress). > > > > > > [XAUTH] Pereira and Beaulieu, "Extended Authentication within > > ISAKMP/Oakley XAUTH)", draft-ietf-ipsec-isakmp-xauth-06.txt > > (work in progress). > > > > > > [MODECFG] R Pereira, S. Anand, B. Patel, "The ISAKMP Configuration > Method", > > draft-ietf-ipsec-isakmp-mode-cfg-05.txt (work in progress) > > > > [ULA] S. Kelly, J. Knowles, B. Aboba, "User-level Authentication > > Mechanisms for IPsec", draft-kelly-ipsra-userauth-00.txt, > > (work in progress) > > > > [CRACK] D Harkins, B Korver, D Piper, "IKE Challenge/Response for > > Authenticated Cryptographic Keys", draft-harkins-ipsec-ike- > > crack-00.txt (work in progress). > > > > [L2TPSEC] B. Patel, B. Aboba, W. Dixon, G. Zorn, S. Booth, "Securing > > L2TP using IPSEC", draft-ietf-l2tpext-security-02.txt" > > (work in progress) > > > > [PIC] Y. Sheffer, H. Krawczyk, "PIC, A Pre-IKE Credential > > Provisioning Protocol ", draft-ietf-ipsra-pic-01.txt, > > (work in progress) > > > > > > > > > > Kelly Expires Jan 2002 [Page 22] > > > > Internet Draft July, 2001 > > > > > > [GETCERT] Bellovin and Moskowitz, "Client Certificate and Key > Retrieval > > for IKE", draft-bellovin-ipsra-getcert-00.txt (work in > progress). > > > > > > 11. Full Copyright Statement > > > > Copyright (C) The Internet Society (1998). 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kelly Expires Jan 2002 [Page 23] > > > From owner-ietf-ipsra@mail.vpnc.org Tue Jul 10 01:24:28 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA10728 for ; Tue, 10 Jul 2001 01:24:27 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6A4i9208629 for ietf-ipsra-bks; Mon, 9 Jul 2001 21:44:09 -0700 (PDT) Received: from ns02.newbridge.com (ns02.newbridge.com [192.75.23.75]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6A4i8m08625 for ; Mon, 9 Jul 2001 21:44:08 -0700 (PDT) Received: (qmail 22237 invoked from network); 10 Jul 2001 04:42:17 -0000 Received: from portal1.newbridge.com (HELO kanata-mh1.ca.newbridge.com) (192.75.23.76) by ns02.newbridge.com with SMTP; 10 Jul 2001 04:42:17 -0000 Received: from kanmail02.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for ietf-ipsra@vpnc.org; Tue, 10 Jul 2001 00:40:19 -0400 Received: from andrewk3 ([138.120.49.111]) by kanmail02.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA74FF; Tue, 10 Jul 2001 00:40:17 -0400 Reply-To: From: "Andrew Krywaniuk" To: "'Scott G. Kelly'" , Cc: Subject: RE: evaluation draft Date: Mon, 9 Jul 2001 23:55:32 -0400 Message-Id: <001d01c108f9$89b7fd60$1e72788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal In-Reply-To: <3B49BD0D.38C97136@redcreek.com> Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > Any of the possible amendments to IKE to deal with DoS, > from base mode to > > client puzzles to stateless cookies, would have a direct > impact on the IPSRA > > solution. If you fix the problem at the root, it will not > exist at the > > branches. > > Exactly how would any of these "ammendments" impact on the fact that > hybrid requires the gateway to support *unauthenticated* incoming > connections from anyone? And what effect would they have on any ipsra > solution which uses some weak form of authentication to get > through ike > so that the "real" authtentication, consisting of username/pwd, can > proceed? *EVERY SESSION INITIATION PROTOCOL* is required to support unauthenticated incoming connections from anyone. That's the whole point. The connection request is initially unauthenticated; part of the purpose of IKE is the authentication of the peer. The DoS risk is based on how much work the unauthenticated client can make the gateway do, how much work the client has to do, and what is the *RELATIVE WORK FACTOR*. Plain Old IKE is vulnerable to DoS because an attacker can forge a KE (low work factor), which causes a gateway to do a DH computatation (high work factor). Main mode requires a cookie exchange, which makes the attack more traceable, but does not prevent it. This attack has a relative work factor which *HEAVILY FAVOURS THE ATTACKER*. You have suggested that hybrid introduces an attack in which the client computes the DH and then fakes a user auth (high work factor) in order to cause the gateway to compute a DH, do a PK signature, and verify a user auth (high work factor). Yes, the relative work factor favours the attacker, but not nearly as much as in the above attack against plain old IKE. Here's an example of a solution. If client puzzles were added to IKE then the client would face a performance penalty for initiating an exchange. This performance penalty could be adjusted so that the attack against plain old IKE would have a relative work factor which favours the gateway. If this was the case, then the attack against Hybrid would be even more unprofitable because the relative work factor would *HEAVILY FAVOUR THE GATEWAY*. > Your "explanation" in (d) is that I should put another > gateway with the > same problem next to the first one to resolve this. This ups > the ante a > bit, but does not change the fact that, for many of the proposed > mechansims, an attack on the user authentication system is an > attack on > the security gateway (and all users with established sessions). This > should not be ignored, especially given that some of the proposed > mechanisms do not have this problem. Are you trying to argue that this > is not an important distinction? Yes, I am saying that this is not an important distinction. No, I'm not saying that you should use load-sharing gateways in order to solve the problem, because I have consistantly denied that this "problem" really exists. Of course it is impossible to deny that moving the user authentication stage to a separate server will have *SOME EFFECT* the DoS problem. How could it not? However, the effect is almost insignificant, and the only reason it makes any difference at all is because adding a second network entity doubles the amount of CPU power you have at your disposal, thus increasing your performance. However, the PIC/GetCert solution makes very inefficient use of this extra CPU power and the performance boost is minimal. I was merely pointing out that if you want to make this comparison then you have to compare apples to apples. If you double the CPU power of a server running Hybrid (e.g. by using a load-sharing second gateway) then you will get literally double the performance and therefore double the DoS resistance. > > g) Both IKE and ESP have significant amounts of known > plaintext (think > > tunneled IP header). This is an assumption in the protocol > design, as I > > explained yesterday. > > Use of PFS and identity protection make a significant difference here, > greatly reducing the (probable) known plaintext. Oh, really? > Using tokens > instead of > arbitrary text phrases in xauth would accomplish the same thing. Good > cryptographic protocol design includes effort to minimize known > plaintext. This is a very simple change. This is the last I'll say on > this topic, given earlier comments. I'm sad to hear it, since I'd love to hear you try to defend your above statement about PFS and identity protection. > If you can present a persuasive, non-emotional argument as to > why xauth > or hybrid or xxx is a better > solution than the other proposals, please do so immediately. We have > already wasted far too much time here, and we need to get our > work done. This WG, through a semi-dictatorial/semi-democratic process has already decided to proceed with PIC, has it not? Therefore, I hardly see how a draft which compares the various user authentication methods that were "considered" really constitutes actual work. Rather, it seems more like propaganda. If you go ahead and produce some actual work, you will get no trouble from me. Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. From owner-ietf-ipsra@mail.vpnc.org Tue Jul 10 11:03:35 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02566 for ; Tue, 10 Jul 2001 11:03:35 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6AEFLJ12467 for ietf-ipsra-bks; Tue, 10 Jul 2001 07:15:21 -0700 (PDT) Received: from perfero.tnc.virtela.cc ([12.41.66.116]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6AEFJm12463 for ; Tue, 10 Jul 2001 07:15:20 -0700 (PDT) Received: from posthaus.virtela.cc ([172.16.97.7]) by perfero.tnc.virtela.cc (8.9.3/8.9.3) with ESMTP id HAA06011 for ; Tue, 10 Jul 2001 07:15:15 -0700 Received: by posthaus.virtela.cc with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Jul 2001 08:15:15 -0600 Message-ID: From: "Horn, Mike" To: "'ietf-ipsra@vpnc.org'" Cc: "Horn, Mike" Subject: Requirements Draft Date: Tue, 10 Jul 2001 08:15:15 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sorry if this is a duplicate, there might have been an issue on my first post of this to the list. Thanks. I have been exchanging several private emails with Scott Kelly about the current requirements draft. There are a few issues which are referenced briefly in the draft, but are not explicitly stated as requirements. Most of these issues are contentious, but I think the VPN user community has already established these as requirements by developing proprietary solutions for most, if not all of these issues. Issues: 1) The IRAS and IRAC SHOULD support NAT traversal. 2) The IRAC SHOULD support redundant gateways. 3) The IRAS and IRAC SHOULD support a keepalive or make dead mechanism. 4) The IRAS SHOULD support auditing of the assigned VIP, public IP, and username in addition to the start and end time. 5) The IRAS and IRAC MAY support load balancing. I understand these issues might fall into a gray area between the IPSRA and IPSEC working groups, but these are true needs of the user community and should be addressed. I think the requirements draft is the right place to capture user requirements, it shouldn't mandate the solutions for how these requirements are met, but it should clearly define the needs of the user community. Mike Horn From owner-ietf-ipsra@mail.vpnc.org Tue Jul 10 12:15:26 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06573 for ; Tue, 10 Jul 2001 12:15:25 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f6AFZRa19798 for ietf-ipsra-bks; Tue, 10 Jul 2001 08:35:27 -0700 (PDT) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6AFZPm19787 for ; Tue, 10 Jul 2001 08:35:25 -0700 (PDT) Received: by mail.redcreek.com with Internet Mail Service (5.5.2653.19) id <3G8WXH4Z>; Tue, 10 Jul 2001 08:36:07 -0700 Received: from redcreek.com (host43.redcreek.com [209.218.26.43]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3G8WXH4Y; Tue, 10 Jul 2001 08:35:55 -0700 From: "Scott G. Kelly" To: ipsra list Message-ID: <3B4B20DC.EFC8A65@redcreek.com> Date: Tue, 10 Jul 2001 08:35:56 -0700 Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: motivation for eval draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit A question has been raised as to whether this draft constitutes useful work within the context of the ipsra wg, so I thought I'd explain my aims in writing the draft. It seems clear that we haven't reached strong consensus regarding the best way to solve the legacy authentication problem in ipsec. Bernard pointed out some time ago that moving a protocol forward without establishing such consensus would set a dangerous precedent. I agree. It seems to me that we are intelligent people, capable of effective collective reasoning when we set our minds to it. Many of us have strongly held opinions that we've carried for a long time, but I believe that, given persuasive evidence to the contrary, most of us would be willing to re-examine these opinions, and perhaps change them. The purpose of writing the draft is to provide a discussion tool, one which documents the path leading to the choice of a solution. Obviously, the first pass at the draft reflects my personal, current view, and some folks disagree rather strongly with me. My view is malleable, and in fact, has changed significantly since I began working on the draft. Once all mechanisms were held up to the requirements, it became clear to me that there aren't all that many differences, although there certainly are a few. I released the draft prior to completing my own analysis, largely because I believed it was taking too long. I promised the draft 2 months ago, but have been consumed by other commitments at work. As a result, I wrote the draft entirely in my "spare" time at home, mostly on weekends. The subject matter turned out to be more complex than I expected in the beginning, and the work dragged on as I stopped repeatedly to ponder various things. Last week, I decided that it had been long enough, and that while the draft is incomplete, folks here would offer insights which would move the process forward. That is occurring now, to some extent. We must reach some semblance of consensus, and in the process, one would hope that we will select the best solution available to us. Scott From owner-ietf-ipsra@mail.vpnc.org Tue Jul 10 13:19:27 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09662 for ; Tue, 10 Jul 2001 13:19:26 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6AGeNu25486 for ietf-ipsra-bks; Tue, 10 Jul 2001 09:40:23 -0700 (PDT) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6AGeLm25482 for ; Tue, 10 Jul 2001 09:40:21 -0700 (PDT) Received: by mail.redcreek.com with Internet Mail Service (5.5.2653.19) id <3G8WXH7C>; Tue, 10 Jul 2001 09:41:06 -0700 Received: from redcreek.com (host43.redcreek.com [209.218.26.43]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3G8WXH7B; Tue, 10 Jul 2001 09:41:00 -0700 From: "Scott G. Kelly" To: Darren Dukes Cc: ietf-ipsra Message-ID: <3B4B301E.915A64E4@redcreek.com> Date: Tue, 10 Jul 2001 09:41:02 -0700 Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: evaluation draft References: <3B4502BE.3A7295CD@redcreek.com> <014b01c108c0$596fb280$9d1c550a@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Darren, Thanks for taking the time to read the draft and comment. Responses interspersed below... Darren Dukes wrote: > > Scott, here are some initial comments. > > 1 - You should add a section stating provisioning complexities. If a user > wants to provision a remote access VPN but does not want to provision a PKI, > why would they want to deploy an IRAS for PIC, which is just a CA using > legacy authentication mechanisms for enrolment? There is some truth here, and I can add some text to the draft to reflect this. However, we should note that a very limited "PKI" is required. If you use any of the proposed techniques with certificates (and since preshared keys simply won't scale, you likely will have to), you must support a number of PKI components anyway. The additional requirement here is a cert generator. As an aside, the current definition of PIC provides for generation of a shared secret in place of a cert. I don't know if this feature will survive or not, but it does address your concern, I think. > 2 - You suggest a reduction in security with an increase in complexity > "Hence, the probability of an oversight or error which impacts on critical > system function is proportional to system complexity, and software > development experience to date suggests that as systems grow increasingly > complex, this probability nears unity." Is this your own idea or do you > have some data or a published authority that can back this up? Well, I don't have any citations handy, though I suspect that it wouldn't be too hard to come up with some which support the general premise (number of bugs increases with code complexity). Bruce Schneier has asserted this in publications, and you can find similar statements in software engineering texts. You could also look at the Software Engineering Institute's web site. In terms of real-world data, you could go to your own QA lab (as I could go to mine), we could look at the numerous patches we see for virtually every release of every operating system, and those of us with extensive coding experience can draw upon our own past experience to confirm this premise. I think this is obvious. > 4 - Does an increase in complexity causing a unity decrease in security > also extend to provisioning of the security solution with multiple servers > that must now be configured? If so are the "Two additional goals" you state > in section 2 still valid? This twists things around a bit, I think. The draft does not say there is a "unity decrease in security", it says... well, read the quote for yourself in your previous comment above. On the other hand, you are right that there is a complexity increase. More on this in a separate thread... > 5 - If a separate IRAS is not deployed for PIC but it exists on the SGW, PIC > and Hybrid have the same DoS vulnerabilities. As an aside, IRAS has been defined as being equivalent to a SGW which provides remote access. The PIC draft defines an AS (Authentication Server), which is what I think you mean. While it is true that they have similar vulnerabilities, they are not the same. Nonetheless, PIC is clearly vulnerable to DoS attacks. I don't think it is possible to completely eliminate this vulnerability, given that you have to accept connections from anyone, but I think it we should strive to minimize it. More on this later... > 6 - If Hybrid and PIC offer the same vulnerabilities to DoS on the SGW then > both implementations must offer some "throttle" capability to avoid dieing > from a DoS attack. This negates the problem of disrupting existing traffic > with an IKE-based (or PIC-based) DoS attack does it not? More on this later (I think this particular discussion deserves a thread all its own). > 7 - Hybrid requires half of the DH computations that PIC does, especially > important if they are on the same SGW. This is worth mentioning in your > review of PIC Okay. > 8 - I disagree with the Hybrid/Xauth issues: > You write "Xauth requires the SGW to participate in the user > authentication process, which increases SGW vulnerability both in terms of > complexity and denial of service." If the complexity of writing and > deploying an IRAS is anything close to the complexity of writing and testing > Hybrid then this argument also applies to PIC. More on this later (I think this particular discussion also deserves a thread all its own). > You write "Adding an open-ended number of challenge-rsp exchanges to a > key exchange increases vulnerability to denial of service attack under some > circumstances, and absolutely increases the complexity of the key exchange > mechanism under all circumstances[... etc]" This is the same as the issue > above, and all SGW implementations must deal with this by throttling the > amount of processor time they will allow IKE (or PIC) to use If they throttle the amount of processor they allow ike, this may prevent legitimate users from connecting, right? I'm not saying this isn't a valid response to a DoS attack, I'm only pointing out that it doesn't make the problem go away. > You write "Xauth requires support for its companion, modecfg." Others > have already provided valid comments here... I don't have an xauth draft handy right now, so correct me if I'm wrong: I believe that xauth references modecfg, and the "transaction exchange" it uses is defined in the modecfg draft. This means that for xauth to advance, either the modecfg draft must advance with it, or the modecfg draft must be discarded, with the functionality required for xauth defined solely in the xauth draft (as a unique exchange). I don't think modecfg will advance, given that the ipsec-dhcp draft has advanced. > You write "[HYBRID] is trivially susceptible to DoS attacks, as it > requires the IRAS to engage in an unauthenticated Diffie-Hellman exchange > which includes an expensive public key operation, and then to continue the > conversation for some period of time beyond that, perhaps in error." Yes > and this should be throttled by the implementation to prevent DoS attacks. > PIC will also suffer from this if run on the SGW. Which is why, if this is a concern, the fact that PIC can run on a standalone AS may be an attractive feature. Scott From owner-ietf-ipsra@mail.vpnc.org Tue Jul 10 13:37:59 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10579 for ; Tue, 10 Jul 2001 13:37:58 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6AH3G026228 for ietf-ipsra-bks; Tue, 10 Jul 2001 10:03:16 -0700 (PDT) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6AH3Em26223 for ; Tue, 10 Jul 2001 10:03:14 -0700 (PDT) Received: by mail.redcreek.com with Internet Mail Service (5.5.2653.19) id <3G8WXH8V>; Tue, 10 Jul 2001 10:03:59 -0700 Received: from redcreek.com (host43.redcreek.com [209.218.26.43]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3G8WXH84; Tue, 10 Jul 2001 10:03:52 -0700 From: "Scott G. Kelly" To: andrew.krywaniuk@alcatel.com Cc: ietf-ipsra@vpnc.org Message-ID: <3B4B3579.C02D6178@redcreek.com> Date: Tue, 10 Jul 2001 10:03:53 -0700 Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: evaluation draft References: <001d01c108f9$89b7fd60$1e72788a@andrewk3.ca.newbridge.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Andrew Krywaniuk wrote: > > > > Any of the possible amendments to IKE to deal with DoS, > > from base mode to > > > client puzzles to stateless cookies, would have a direct > > impact on the IPSRA > > > solution. If you fix the problem at the root, it will not > > exist at the > > > branches. > > > > Exactly how would any of these "ammendments" impact on the fact that > > hybrid requires the gateway to support *unauthenticated* incoming > > connections from anyone? And what effect would they have on any ipsra > > solution which uses some weak form of authentication to get > > through ike > > so that the "real" authtentication, consisting of username/pwd, can > > proceed? > > *EVERY SESSION INITIATION PROTOCOL* is required to support unauthenticated > incoming connections from anyone. That's the whole point. The connection > request is initially unauthenticated; part of the purpose of IKE is the > authentication of the peer. The DoS risk is based on how much work the > unauthenticated client can make the gateway do, how much work the client has > to do, and what is the *RELATIVE WORK FACTOR*. I think I may have been careless with my wording. I realize that any relevant protocol will have to allow incoming connections to be initiated by anyone. My point was that hybrid requires anyone to force the gateway to completely establish an IKE SA with anyone, with no assurance reqarding their identity. More on this in a more general DoS thread to follow. > You have suggested that hybrid introduces an attack in which the client > computes the DH and then fakes a user auth (high work factor) in order to > cause the gateway to compute a DH, do a PK signature, and verify a user auth > (high work factor). Yes, the relative work factor favours the attacker, but > not nearly as much as in the above attack against plain old IKE. The user does not necessarily have to fake user authentication. The attacker's DH exponent may be very small, greatly limiting the work he does, and he need not verify the SGW's signature in the final packet. Now, virtually anything can be sent through the ike SA. Say, for example, that an attacker repeats the final hybrid message at intervals, and drops any challenge the SGW sends. What will the SGW do? Probably, it will reconstruct the last message of the exchange and retransmit it some number of times. How many times will it do this? And how many times will the SGW retransmit ignored challenges? What happens if the attacker sends other things instead, like notify messages? What if the attacker drops challenges until some threshhold is reached, and then sends some bogus response? How long might an attacker tie up memory resources in this manner? DoS entails more than just processor overhead. More on this in an upcoming DoS discussion thread... > Here's an example of a solution. If client puzzles were added to IKE then > the client would face a performance penalty for initiating an exchange. This > performance penalty could be adjusted so that the attack against plain old > IKE would have a relative work factor which favours the gateway. If this was > the case, then the attack against Hybrid would be even more unprofitable > because the relative work factor would *HEAVILY FAVOUR THE GATEWAY*. I agree that client puzzles might be helpful here. However, I think it is important to distinguish between issues IKE currently has, and issues we add by virtue of the mechanism we choose. > > > g) Both IKE and ESP have significant amounts of known > > plaintext (think > > > tunneled IP header). This is an assumption in the protocol > > design, as I > > > explained yesterday. > > > > Use of PFS and identity protection make a significant difference here, > > greatly reducing the (probable) known plaintext. > > Oh, really? Actually, I shouldn't have said PFS, as identity protection is the only factor here. I'm assuming ESP tunnel mode. If you don't use identity protection, an attacker can know the version, header length, TOS, flags (maybe), TTL (maybe), src/dst IP addresses, protocol, and possibly TCP/UDP ports from the encapsulated header. If you use identity protection, an attacker can only know version, header length, TOS, maybe flags, and maybe TTL. This is 27 bits, vs at least 141 bits - this is a significant difference. Scott From owner-ietf-ipsra@mail.vpnc.org Tue Jul 10 14:36:00 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13855 for ; Tue, 10 Jul 2001 14:36:00 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6AHuSV28096 for ietf-ipsra-bks; Tue, 10 Jul 2001 10:56:28 -0700 (PDT) Received: from ee.technion.ac.il (ee.technion.ac.il [132.68.48.5]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6AHuQm28092 for ; Tue, 10 Jul 2001 10:56:26 -0700 (PDT) Received: from localhost (hugo@localhost) by ee.technion.ac.il (8.9.3+Sun/8.9.3) with ESMTP id UAA29943 for ; Tue, 10 Jul 2001 20:56:37 +0300 (IDT) Date: Tue, 10 Jul 2001 20:56:37 +0300 (IDT) From: Hugo Krawczyk To: ietf-ipsra Subject: Re: evaluation draft In-Reply-To: <3B4B301E.915A64E4@redcreek.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Discussion in this thread should treat separately two questions 1) Should IPSRA allow for protocols that change IKE (and therefore force a change in existing ipsec/IKE security gateways)? and 2) Given the requirement not to change IKE (and gateways) is PIC the right solution? Question (1) is clearly answered by the ipsra's charter. While this does not make this answer to be "right", it is certainly a requirement that any product of the ipsra wg needs to satisfy. Whoever disagrees will need to bring to a change of the charter (or form another WG...) Personally, I have no problem with those that want to change the charter (I wouldn't be against, except that convergence in this case seems impossible). But if we assume the charter is there to stay then 95% of the discussion in this thread which centers around comparison with the options that change IKE is irrelevant. Moreover, under the current charter's requirements, getcert's "credentials retrieval" approach is the only feasible solution as a front-end to IKE. That is what PIC implements, and in that sense it is "IPSRA's right solution" (even if the PIC+IKE "via dolorosa" is painfully slow). Now the operative question is: given the charter's requirements, are the details of PIC OK? and where should we improve it? Hugo From owner-ietf-ipsra@mail.vpnc.org Tue Jul 10 15:05:23 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15358 for ; Tue, 10 Jul 2001 15:05:22 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6AIUUl29182 for ietf-ipsra-bks; Tue, 10 Jul 2001 11:30:30 -0700 (PDT) Received: from [165.227.249.20] (ip20.proper.com [165.227.249.20]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6AIUPm29173; Tue, 10 Jul 2001 11:30:25 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: Date: Tue, 10 Jul 2001 11:29:38 -0700 To: Hugo Krawczyk , ietf-ipsra From: Paul Hoffman / VPNC Subject: Re: evaluation draft Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 8:56 PM +0300 7/10/01, Hugo Krawczyk wrote: >Personally, I have no problem with those that want to change the charter >(I wouldn't be against, except that convergence in this case seems >impossible). Any discussion of the charter is out of scope. Scott pointed out in an earlier message that we are all intelligent adults. Why, then, do many of us keep forgetting what has happened in the recent past? We have been told repeatedly that the protocol that comes from the WG may not change IKE. Many of us have replied "but we think that a change to IKE is a better solution". The response from the Area Directors has been unequivocal: no changing IKE, no changing the charter. --Paul Hoffman, Director --VPN Consortium From owner-ietf-ipsra@mail.vpnc.org Tue Jul 10 15:56:51 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19154 for ; Tue, 10 Jul 2001 15:56:50 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6AJGgS00897 for ietf-ipsra-bks; Tue, 10 Jul 2001 12:16:42 -0700 (PDT) Received: from ns02.newbridge.com (ns02.newbridge.com [192.75.23.75]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6AJGdm00893 for ; Tue, 10 Jul 2001 12:16:40 -0700 (PDT) Received: (qmail 27624 invoked from network); 10 Jul 2001 19:14:43 -0000 Received: from portal1.newbridge.com (HELO kanata-mh1.ca.newbridge.com) (192.75.23.76) by ns02.newbridge.com with SMTP; 10 Jul 2001 19:14:43 -0000 Received: from kanmail02.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for ietf-ipsra@vpnc.org; Tue, 10 Jul 2001 15:14:42 -0400 Received: from andrewk3 ([138.120.114.30]) by kanmail02.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA344F; Tue, 10 Jul 2001 15:14:41 -0400 Reply-To: From: "Andrew Krywaniuk" To: "'Scott G. Kelly'" , Cc: Subject: RE: evaluation draft Date: Tue, 10 Jul 2001 15:07:52 -0400 Message-Id: <003c01c10973$b09cce40$1e72788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal In-Reply-To: <3B4B3579.C02D6178@redcreek.com> Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > *EVERY SESSION INITIATION PROTOCOL* is required to support > unauthenticated > > incoming connections from anyone. That's the whole point. > The connection > > request is initially unauthenticated; part of the purpose > of IKE is the > > authentication of the peer. The DoS risk is based on how > much work the > > unauthenticated client can make the gateway do, how much > work the client has > > to do, and what is the *RELATIVE WORK FACTOR*. > > I think I may have been careless with my wording. I realize that any > relevant protocol will have to allow incoming connections to be > initiated by anyone. My point was that hybrid requires anyone to force > the gateway to completely establish an IKE SA with anyone, with no > assurance reqarding their identity. More on this in a more general DoS > thread to follow. And my point is that this is irrelevant. In the draft, you make a distinction between Hybrid and Crack because Hybrid allows the user to complete the phase 1 before fully authenticating the user whereas Crack does not. Later you admit this is not really an important distinction. Where you draw the line between phase 1 and phase 2 is moot. Sure the attacker can establish a phase 1, but he cannot intitiate quick modes (or modecfg or heartbeats for that matter) until the legacy auth is complete (and the SA will time out in a short, predetermined time if the user does not complete the auth). What the attacker can do is make the gateway do DH followed by PK sign followed by some legacy auth protocol, which is exactly the same vulnerability that exists with any of the other proposals. Yes, you can claim that in PIC the DoS attack can only be launched against the AS, not the gateway, but this is irrelevant for the two reasons I mentioned before: 1) A more severe DoS attack already exists against POI, and 2) Additional hardware could combat the DoS attack by more direct means. > > You have suggested that hybrid introduces an attack in > which the client > > computes the DH and then fakes a user auth (high work > factor) in order to > > cause the gateway to compute a DH, do a PK signature, and > verify a user auth > > (high work factor). Yes, the relative work factor favours > the attacker, but > > not nearly as much as in the above attack against plain old IKE. > > The user does not necessarily have to fake user authentication. The > attacker's DH exponent may be very small, greatly limiting the work he > does He could conceivably cut his work in half by reusing the same exponent every time. > , and he need not verify the SGW's signature in the final packet. Which is why I didn't include that in my description above. > Now, virtually anything can be sent through the ike SA. Say, for > example, that an attacker repeats the final hybrid message at > intervals, > and drops any challenge the SGW sends. What will the SGW do? Probably, > it will reconstruct the last message of the exchange and retransmit it > some number of times. How many times will it do this? And how many > times will the SGW retransmit ignored challenges? What happens if the > attacker sends other things instead, like notify messages? What if the > attacker drops challenges until some threshhold is reached, and then > sends some bogus response? How long might an attacker tie up memory > resources in this manner? DoS entails more than just > processor overhead. > More on this in an upcoming DoS discussion thread... The relative work factor is still insignificant compared to the direct attack against main mode. The gateway should terminate a user's connection if they don't complete the authentication within X seconds and or Y attempts. Everything you have said has an equivalent attack against PIC. This is relavent because of my "equal CPU power" assumption. And if you want, you can tie up memory resources on the gateway simply by never completing main mode. > I agree that client puzzles might be helpful here. However, I think it > is important to distinguish between issues IKE currently has, > and issues > we add by virtue of the mechanism we choose. My point is that the issues we have exist here only because they already existed in IKE. Fix IKE and you fix everything. > > > Use of PFS and identity protection make a significant > difference here, > > > greatly reducing the (probable) known plaintext. > > > > Oh, really? > > Actually, I shouldn't have said PFS, as identity protection > is the only > factor here. I'm assuming ESP tunnel mode. So when you said identity protection you meant tunnel mode? Granted that is a form of identity protection, but it would help if you used the names that we are familiar with. (Also, I thought we were talking about IKE, not ESP.) > If you don't use identity > protection, an attacker can know the version, header length, > TOS, flags > (maybe), TTL (maybe), src/dst IP addresses, protocol, and possibly > TCP/UDP ports from the encapsulated header. If you use identity > protection, an attacker can only know version, header length, > TOS, maybe > flags, and maybe TTL. This is 27 bits, vs at least 141 bits - > this is a > significant difference. There is much more than that. Real network traffic follows predictable patterns. Sure you can add random padding, but at a high performace cost. It is possible to guess the protocol in use from packet sizes and timing. Once you guess that, you can probably guess a whole bunch more plaintext. A brute force attack only requires one block of known plaintext. The bits don't even have to be consecutive. Reducing known plaintext doesn't help here unless you can completely eliminate it. And you also have to make the plaintext statistically indistinguishable from random data or the attacker can still crack it through analysis. Every known plaintext attack I have seen requires enormous amounts of data (and is not terribly feasible against today's large-key ciphers). 27 bits vs. 141 bits is not terribly significant when we're talking in orders of magnitude (that's 2^5 as opposed to 2^7). I suspect that if anyone ever invented an attack that worked against 141 bits of known plaintext per packet then ESP would be in for a complete redesign. Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. > From owner-ietf-ipsra@mail.vpnc.org Tue Jul 10 16:07:33 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20154 for ; Tue, 10 Jul 2001 16:07:32 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f6AJXiP01952 for ietf-ipsra-bks; Tue, 10 Jul 2001 12:33:44 -0700 (PDT) Received: from relay2.nai.com (relay2.nai.com [161.69.3.67]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6AJXhm01947 for ; Tue, 10 Jul 2001 12:33:43 -0700 (PDT) Received: from scwsout1.nai.com (undef-3-73.nai.com [161.69.3.73] (may be forged)) by relay2.nai.com (8.9.3/8.9.3) with SMTP id OAA08484 for ; Tue, 10 Jul 2001 14:33:40 -0500 (CDT) Received: FROM ca-ex-bridge1.nai.com BY scwsout1.nai.com ; Tue Jul 10 12:31:11 2001 -0700 Received: by SNC-5-23.nai.com with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Jul 2001 12:33:12 -0700 Message-ID: <8894CA1F87A5D411BD24009027EE78381281BB@ROC-76-204.nai.com> From: "Mason, David" To: "'Paul Hoffman / VPNC'" , Hugo Krawczyk , ietf-ipsra Subject: RE: evaluation draft Date: Tue, 10 Jul 2001 12:32:24 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This must be why the NAT-traversal IDs weren't submitted under the IPSRA WG even though they are a direct requirement (sections 2.5, 3.2.5, 3.3.5, 3.4.5, 3.6.5, 4 of IPSRA requirements ID). Can someone in charge please explain the criteria of why it's ok to change IKE/IPsec for some new features and not others? -dave -----Original Message----- From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org] Sent: Tuesday, July 10, 2001 2:30 PM To: Hugo Krawczyk; ietf-ipsra Subject: Re: evaluation draft At 8:56 PM +0300 7/10/01, Hugo Krawczyk wrote: >Personally, I have no problem with those that want to change the charter >(I wouldn't be against, except that convergence in this case seems >impossible). Any discussion of the charter is out of scope. Scott pointed out in an earlier message that we are all intelligent adults. Why, then, do many of us keep forgetting what has happened in the recent past? We have been told repeatedly that the protocol that comes from the WG may not change IKE. Many of us have replied "but we think that a change to IKE is a better solution". The response from the Area Directors has been unequivocal: no changing IKE, no changing the charter. --Paul Hoffman, Director --VPN Consortium From owner-ietf-ipsra@mail.vpnc.org Tue Jul 10 18:46:08 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28091 for ; Tue, 10 Jul 2001 18:46:08 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6AMFtw07282 for ietf-ipsra-bks; Tue, 10 Jul 2001 15:15:55 -0700 (PDT) Received: from perfero.tnc.virtela.cc ([12.41.66.116]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6AMFrm07278 for ; Tue, 10 Jul 2001 15:15:53 -0700 (PDT) Received: from posthaus.virtela.cc ([172.16.97.7]) by perfero.tnc.virtela.cc (8.9.3/8.9.3) with ESMTP id PAA24806; Tue, 10 Jul 2001 15:15:44 -0700 Received: by posthaus.virtela.cc with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Jul 2001 16:15:44 -0600 Message-ID: From: "Horn, Mike" To: "'Scott G. Kelly'" , ietf-ipsra@vpnc.org Cc: "Horn, Mike" Subject: RE: evaluation draft Date: Tue, 10 Jul 2001 16:15:43 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I think a few things are missing in the XAUTH section (5.1): 1) XAUTH/MODECFG has been widely implemented and has undergone several iterations of interoperability testing. The last count I saw had 17 vendors claiming some form of XAUTH support. I think this is a key differentiator over other proposed solutions. 2) While XAUTH does share many of the inherent vulnerabilities of preshared keys, it does not appear to weaken the security of the underlying IPsec. I agree that it is more vulnerable to DoS if the preshared key is not appropriately protected. 3) Since XAUTH uses an established IKE SA, some other method less complicated than MODECFG might be able to be used to pass the username and passphrase to the SGW. Depending on the solution, this might help get around the "no changes to IKE" requirement. 4) XAUTH requires support for 16 different authentication methods increasing the complexity. If XAUTH was selected for the standards track, I'm sure that some (if not most) of the authentication methods could be changed to optional. It's not that I biased towards XAUTH for technical reasons, but I'm concerned that it is here to stay anyway (since it has been so widely deployed). I would rather see improvements made to existing technology (XAUTH) than watch the working group try to figure out what technology it MIGHT develop. I would argue that most of the developers on this list are already intimately familiar with XAUTH and might even have some suggestions for how to make it better. Mike Horn > -----Original Message----- > From: Scott G. Kelly [mailto:skelly@redcreek.com] > Sent: Thursday, July 05, 2001 6:14 PM > To: ietf-ipsra@vpnc.org > Subject: evaluation draft > > > Hi All, > > Attached is a copy of the draft which compares pic, getcert, > crack, ula, > hybrid, and xauth that I promised months ago. I've submitted it to the > ID editor (as a personal submission), but also wanted to > archive it here > in the mailing list. I vastly underestimated the amount of work > involved, and feel as though I'd like to work on it for > another week or > so even now. On the other hand, we need to move forward, so > I'm putting > it out now in order to solicit comments. > > Scott > > From owner-ietf-ipsra@mail.vpnc.org Tue Jul 10 18:53:52 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28483 for ; Tue, 10 Jul 2001 18:53:51 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6AMQ3j07458 for ietf-ipsra-bks; Tue, 10 Jul 2001 15:26:03 -0700 (PDT) Received: from [165.227.249.20] (ip20.proper.com [165.227.249.20]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6AMQ0m07454; Tue, 10 Jul 2001 15:26:00 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: Date: Tue, 10 Jul 2001 15:25:14 -0700 To: "Horn, Mike" , "'ietf-ipsra@vpnc.org'" From: Paul Hoffman / VPNC Subject: Re: Requirements Draft Cc: "Horn, Mike" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 8:15 AM -0600 7/10/01, Horn, Mike wrote: >I have been exchanging several private emails with Scott Kelly about the >current requirements draft. There are a few issues which are referenced >briefly in the draft, but are not explicitly stated as requirements. Most >of these issues are contentious, but I think the VPN user community has >already established these as requirements by developing proprietary >solutions for most, if not all of these issues. There is a big difference between market desires and market requirements. There are many very successful products available that do not match more or more of the features you list below. >1) The IRAS and IRAC SHOULD support NAT traversal. We don't yet have a standard for that. >2) The IRAC SHOULD support redundant gateways. This is an application issue, not a protocol issue. >3) The IRAS and IRAC SHOULD support a keepalive or make dead mechanism. We don't yet have a standard for that. >4) The IRAS SHOULD support auditing of the assigned VIP, public IP, and >username in addition to the start and end time. Auditing is not covered in this WG. >5) The IRAS and IRAC MAY support load balancing. It can't be a requirement and a "MAY" at the same time. And, again, it's not a protocol issue. >I understand these issues might fall into a gray area between the IPSRA and >IPSEC working groups, but these are true needs of the user community and >should be addressed. They are being addressed by many vendors. > I think the requirements draft is the right place to >capture user requirements, it shouldn't mandate the solutions for how these >requirements are met, but it should clearly define the needs of the user >community. Again, "needs" is probably too strong a term to use here. --Paul Hoffman, Director --VPN Consortium From owner-ietf-ipsra@mail.vpnc.org Tue Jul 10 19:27:45 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29580 for ; Tue, 10 Jul 2001 19:27:44 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6AMtlg08160 for ietf-ipsra-bks; Tue, 10 Jul 2001 15:55:47 -0700 (PDT) Received: from [165.227.249.20] (ip20.proper.com [165.227.249.20]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6AMtjm08156 for ; Tue, 10 Jul 2001 15:55:45 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: Date: Tue, 10 Jul 2001 15:55:00 -0700 To: ietf-ipsra@vpnc.org From: Paul Hoffman / VPNC Subject: Notes on pic-02 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Thanks again to the authors for doing this revision. I hope everyone on this list has read the document or intends to do so soon. A few notes for the authors: The document has a fair number of non-ASCII characters that do not render correctly on non-Windows machines (and probably some Windows-based machines as well). The whole historical discussion will have to be revisited as we get closer to completion. Remember, this document will need to be able to make sense decades from now, long after all memories of the IPSRA charter arguments have been thankfully wiped from our minds. In section 3.1, please add a note saying "This exchange type will change to a value between 6 and 31 when this document becomes an RFC." (The current value is in the private use area.) Do we really want to use port 500 for PIC? For systems that combines gateways and ASs, this *forces* them to do both PIC and IKE in one piece of software. In section 4.5, the extensive quoting from other documents makes it hard to follow the arguments. Could you cut the quotations but briefly summarize? In the IANA considerations, please change "Next Payload identifiers" to "Payload identifiers". Yes, these appear in the "next payload" field, but they are really identifiers of the payloads themselves. --Paul Hoffman, Director --VPN Consortium From owner-ietf-ipsra@mail.vpnc.org Tue Jul 10 19:46:55 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA00100 for ; Tue, 10 Jul 2001 19:46:54 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f6ANDwI08689 for ietf-ipsra-bks; Tue, 10 Jul 2001 16:13:58 -0700 (PDT) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6ANDum08682; Tue, 10 Jul 2001 16:13:56 -0700 (PDT) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA03805; Tue, 10 Jul 2001 17:13:57 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA27824; Tue, 10 Jul 2001 19:13:58 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f6ANDPx02701; Tue, 10 Jul 2001 19:13:25 -0400 (EDT) Message-Id: <200107102313.f6ANDPx02701@thunk.east.sun.com> From: Bill Sommerfeld To: Paul Hoffman / VPNC cc: ietf-ipsra@vpnc.org Subject: Re: Notes on pic-02 In-reply-to: Your message of "Tue, 10 Jul 2001 15:55:00 PDT." Reply-to: sommerfeld@east.sun.com Date: Tue, 10 Jul 2001 19:13:24 -0400 Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Do we really want to use port 500 for PIC? For systems that combines > gateways and ASs, this *forces* them to do both PIC and IKE in one > piece of software. I definitely DO NOT want to reuse port 500 for this. - Bill From owner-ietf-ipsra@mail.vpnc.org Tue Jul 10 21:52:37 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA04023 for ; Tue, 10 Jul 2001 21:52:36 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6B18lX11313 for ietf-ipsra-bks; Tue, 10 Jul 2001 18:08:47 -0700 (PDT) Received: from perfero.tnc.virtela.cc ([12.41.66.116]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6B18jm11307; Tue, 10 Jul 2001 18:08:45 -0700 (PDT) Received: from posthaus.virtela.cc ([172.16.97.7]) by perfero.tnc.virtela.cc (8.9.3/8.9.3) with ESMTP id SAA31337; Tue, 10 Jul 2001 18:08:43 -0700 Received: by posthaus.virtela.cc with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Jul 2001 19:08:43 -0600 Message-ID: From: "Horn, Mike" To: "'Paul Hoffman / VPNC'" , "'ietf-ipsra@vpnc.org'" Subject: RE: Requirements Draft Date: Tue, 10 Jul 2001 19:08:42 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I guess my point is that "We don't yet have a standard for that." Without it being explicitly stated as a requirement, how will it ever become standardized? Additional comments inline. > > There is a big difference between market desires and market > requirements. There are many very successful products available that > do not match more or more of the features you list below. > I do not agree. Name one client vendor that is not claiming to support XAUTH. A quick search shows the following vendors currently supporting it include Lucent, Cisco, SSH, Symantec, Nortel, IRE [SafeNet], etc. The list is almost as long for NAT traversal. If these weren't really market requirements I don't think all these vendors would have implemented proprietary solutions to meet the requirements I list. > >1) The IRAS and IRAC SHOULD support NAT traversal. > > We don't yet have a standard for that. Should it not be _explicitly_ stated as a requirement? The problem is generic to IPsec, but it has the biggest impact in the remote client implementation. > > >2) The IRAC SHOULD support redundant gateways. > > This is an application issue, not a protocol issue. Sometimes there are required enhancements to the protocol to make redundancy work properly. For instance dynamically passing a secondary SGW to the client upon tunnel establishment would be a nice thing to have. Also keepalives (or makedeads) are important. I can think of several other redundancy features that might also require protocol enhancements. > > >3) The IRAS and IRAC SHOULD support a keepalive or make dead > mechanism. > > We don't yet have a standard for that. See my comment on NAT traversal. > > >4) The IRAS SHOULD support auditing of the assigned VIP, > public IP, and > >username in addition to the start and end time. > > Auditing is not covered in this WG. Then why is auditing stated as a requirement at all? If you are going to capture start and end times, there is some useful information that could also be captured. One thing that I don't see being covered anywhere (except potentially with DHCP) is the VIP. This could be critical in auditing a security event. > > >5) The IRAS and IRAC MAY support load balancing. > > It can't be a requirement and a "MAY" at the same time. And, again, > it's not a protocol issue. Ok. Make it SHOULD. Again see my comments on redundant gateways. > > >I understand these issues might fall into a gray area > between the IPSRA and > >IPSEC working groups, but these are true needs of the user > community and > >should be addressed. > > They are being addressed by many vendors. Without consensus from the IETF WG's!! This is a major stumbling point for many IPsec technology deployers. I need to use a specific client with a specific SGW to get the functionality I need. That is not what standards are about. I wish everyone was ready to embrace PKI, but to date that has not happened. Also, it is interesting that the focus of this WG is supposed to be primarily legacy authentication support, but the first approved standard is for DHCP. > > > I think the requirements draft is the right place to > >capture user requirements, it shouldn't mandate the > solutions for how these > >requirements are met, but it should clearly define the needs > of the user > >community. > > Again, "needs" is probably too strong a term to use here. > > --Paul Hoffman, Director > --VPN Consortium > From owner-ietf-ipsra@mail.vpnc.org Wed Jul 11 03:51:31 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA27541 for ; Wed, 11 Jul 2001 03:51:30 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f6B7DD800367 for ietf-ipsra-bks; Wed, 11 Jul 2001 00:13:13 -0700 (PDT) Received: from internaut.com ([64.38.134.99]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6B7DBm00357; Wed, 11 Jul 2001 00:13:11 -0700 (PDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id AAA48260; Wed, 11 Jul 2001 00:05:23 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Wed, 11 Jul 2001 00:05:23 -0700 (PDT) From: Bernard Aboba To: Paul Hoffman / VPNC cc: Hugo Krawczyk , ietf-ipsra Subject: Re: evaluation draft In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Scott pointed out in an earlier message that we are all intelligent > adults. Why, then, do many of us keep forgetting what has happened in > the recent past? People tend to fixate on traumatic experiences for which there is no logical explanation. This is the foundation for the plots of several B movies. > We have been told repeatedly that the protocol that comes from the WG > may not change IKE. There is a movie with Edgar G. Robinson in which an adopted daughter is repeatedly told "not to go out in the woods". Guess where she eventually ends up? > The response from the Area Directors has been unequivocal: no changing > IKE, no changing the charter. After the daughter ended up in the woods for the first time, Edgar G. Robinson got very mad. He also made unequivocal statements, threats even. Of course, the warnings went unheeded. That movie did not end well. I hope ours has a better ending. I suspect things would have turned out better had Jimmy Stewart played the part instead of Edgar G. Robinson. Mr. Stewart might have explained the situation in a more complete way, resolving the inherent contradictions. He might, for example, have explained why IKE, er the forrest, must not be entered. What dangers lie there. He might also have noted that renaming the forrest would not necessarily change the dangers, much in the way that designing a protocol with the same port numbers and payloads as IKE does not change its security properties. He would have, in that way that only Jimmy Stewart can do, explained complex security issues in a way that the average viewer could understand and internalize. OK, I'm done. Back to the regularly scheduled flame war... From owner-ietf-ipsra@mail.vpnc.org Wed Jul 11 07:08:48 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA00082 for ; Wed, 11 Jul 2001 07:08:47 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6BAUdw13625 for ietf-ipsra-bks; Wed, 11 Jul 2001 03:30:39 -0700 (PDT) Received: from ee.technion.ac.il (ee.technion.ac.il [132.68.48.5]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6BAUam13619; Wed, 11 Jul 2001 03:30:37 -0700 (PDT) Received: from localhost (hugo@localhost) by ee.technion.ac.il (8.9.3+Sun/8.9.3) with ESMTP id NAA12822; Wed, 11 Jul 2001 13:30:47 +0300 (IDT) Date: Wed, 11 Jul 2001 13:30:47 +0300 (IDT) From: Hugo Krawczyk To: Paul Hoffman / VPNC cc: ietf-ipsra@vpnc.org Subject: Re: Notes on pic-02 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > The whole historical discussion will have to be revisited as we get > closer to completion. Remember, this document will need to be able to > make sense decades from now, long after all memories of the IPSRA > charter arguments have been thankfully wiped from our minds. > The text can always be refined and improved, but the discussion should be there. For comparison, I wish IKE had some of this type of context and rationale discussion. A lot of misunderstanding, arguments, and out-of-context criticism would have been avoided. When you design security by rough consensus you better document its "roughness" (or you'll keep raising questions ten years from now too) Hugo From owner-ietf-ipsra@mail.vpnc.org Wed Jul 11 07:11:45 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA00159 for ; Wed, 11 Jul 2001 07:11:44 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6BAF2k13364 for ietf-ipsra-bks; Wed, 11 Jul 2001 03:15:02 -0700 (PDT) Received: from ee.technion.ac.il (ee.technion.ac.il [132.68.48.5]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6BAF0m13358; Wed, 11 Jul 2001 03:15:00 -0700 (PDT) Received: from localhost (hugo@localhost) by ee.technion.ac.il (8.9.3+Sun/8.9.3) with ESMTP id NAA12532; Wed, 11 Jul 2001 13:15:10 +0300 (IDT) Date: Wed, 11 Jul 2001 13:15:10 +0300 (IDT) From: Hugo Krawczyk To: Paul Hoffman / VPNC cc: ietf-ipsra Subject: Re: evaluation draft In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 10 Jul 2001, Paul Hoffman / VPNC wrote: > > At 8:56 PM +0300 7/10/01, Hugo Krawczyk wrote: > >Personally, I have no problem with those that want to change the charter > >(I wouldn't be against, except that convergence in this case seems > >impossible). > > Any discussion of the charter is out of scope. Therefore any evaluation of, and comparison with, solutions that do not comply with the charter should be out of scope too. Under the current state of affairs such discussion is noise. A constructive subject of discussion is how to maximize the benefits, functionality, simplicity, and security of PIC given the "charter's axioms" Hugo > > Scott pointed out in an earlier message that we are all intelligent > adults. Why, then, do many of us keep forgetting what has happened in > the recent past? We have been told repeatedly that the protocol that > comes from the WG may not change IKE. Many of us have replied "but we > think that a change to IKE is a better solution". The response from > the Area Directors has been unequivocal: no changing IKE, no changing > the charter. > > --Paul Hoffman, Director > --VPN Consortium > From owner-ietf-ipsra@mail.vpnc.org Wed Jul 11 10:19:32 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04316 for ; Wed, 11 Jul 2001 10:19:32 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6BDjBt18567 for ietf-ipsra-bks; Wed, 11 Jul 2001 06:45:11 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6BDjAm18561; Wed, 11 Jul 2001 06:45:10 -0700 (PDT) Received: from toque.cisco.com (toque.cisco.com [161.44.208.153]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f6BDgS517532; Wed, 11 Jul 2001 06:42:30 -0700 (PDT) Received: from stephanent3 (ott-b1-dhcp-10-85-28-168.cisco.com [10.85.28.168]) by toque.cisco.com (Mirapoint) with SMTP id ABK06189; Wed, 11 Jul 2001 09:44:09 -0400 (EDT) Message-ID: <063101c10a0f$c0dd4b80$a81c550a@cisco.com> From: "Stephane Beaulieu" To: "Hugo Krawczyk" , "ietf-ipsra" , "Paul Hoffman / VPNC" References: Subject: Re: evaluation draft Date: Wed, 11 Jul 2001 09:45:30 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > At 8:56 PM +0300 7/10/01, Hugo Krawczyk wrote: > >Personally, I have no problem with those that want to change the charter > >(I wouldn't be against, except that convergence in this case seems > >impossible). > > Any discussion of the charter is out of scope. Why is it out of scope? It seems to me that the charter was more imposed than agreed upon. If the majority of the vendors believe that such a change would be beneficial, then what stops us from doing that? Is it the ADs? If so then perhaps this work should be mandatted to the IPSec WG which has the power to improve IKE. If memory serves, the justification I had heard for the charter limitations was to reduce complexity. I think we have proven (with PIC and GetCert proposals) that the problem cannot be solved without some added complexity. I would even be inclined to say that the Charter restrictions have increased complexity. So, why is discussion of the charter out of scope? Or is that out of scope too ;) From owner-ietf-ipsra@mail.vpnc.org Wed Jul 11 11:22:49 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07296 for ; Wed, 11 Jul 2001 11:22:49 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f6BEkOX20095 for ietf-ipsra-bks; Wed, 11 Jul 2001 07:46:24 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6BEkOm20091 for ; Wed, 11 Jul 2001 07:46:24 -0700 (PDT) Received: from toque.cisco.com (toque.cisco.com [161.44.208.153]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f6BEiY516850 for ; Wed, 11 Jul 2001 07:44:34 -0700 (PDT) Received: from DDUKESW2K (ott-b1-dhcp-10-85-28-157.cisco.com [10.85.28.157]) by toque.cisco.com (Mirapoint) with SMTP id ABK07097; Wed, 11 Jul 2001 10:46:06 -0400 (EDT) Message-ID: <006a01c10a18$4e29a710$9d1c550a@cisco.com> Reply-To: "Darren Dukes" From: "Darren Dukes" To: "ietf-ipsra" References: Subject: PIC is IKE (was Re: evaluation draft)` Date: Wed, 11 Jul 2001 10:46:44 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit A PIC SA is an IKE SA, like it or not. PIC, as a authentication system, is even more complex than those 'out of scope' proposals that use an IKE SA since you now must provision and configure multiple services. If you simplify the overall authentication system you could put PIC on the SGW, now you've doubled your supported code for IKE-like exchanges. That's going to be hard to support so why not have PIC and IKE share most of their code. Now PIC is on the same box as IKE, using the same UDP port number, and better yet IKE and PIC are interdependent since they're sharing much of the same code. Why not just use IKE and simplify the code more? I don't know. Other opinions are encouraged. Darren ----- Original Message ----- From: "Hugo Krawczyk" To: "Paul Hoffman / VPNC" Cc: "ietf-ipsra" Sent: Wednesday, July 11, 2001 6:15 AM Subject: Re: evaluation draft > > > > On Tue, 10 Jul 2001, Paul Hoffman / VPNC wrote: > > > > > At 8:56 PM +0300 7/10/01, Hugo Krawczyk wrote: > > >Personally, I have no problem with those that want to change the charter > > >(I wouldn't be against, except that convergence in this case seems > > >impossible). > > > > Any discussion of the charter is out of scope. > > Therefore any evaluation of, and comparison with, solutions that do not > comply with the charter should be out of scope too. Under the current > state of affairs such discussion is noise. A constructive subject of > discussion is how to maximize the benefits, functionality, simplicity, and > security of PIC given the "charter's axioms" > > Hugo > > > > > Scott pointed out in an earlier message that we are all intelligent > > adults. Why, then, do many of us keep forgetting what has happened in > > the recent past? We have been told repeatedly that the protocol that > > comes from the WG may not change IKE. Many of us have replied "but we > > think that a change to IKE is a better solution". The response from > > the Area Directors has been unequivocal: no changing IKE, no changing > > the charter. > > > > --Paul Hoffman, Director > > --VPN Consortium > > > From owner-ietf-ipsra@mail.vpnc.org Wed Jul 11 13:08:20 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11706 for ; Wed, 11 Jul 2001 13:08:20 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6BGVjx28080 for ietf-ipsra-bks; Wed, 11 Jul 2001 09:31:45 -0700 (PDT) Received: from mail.nexsi.com ([63.121.79.248]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6BGVhm28076 for ; Wed, 11 Jul 2001 09:31:44 -0700 (PDT) Received: from NEWJERSEY (dynam99.hw.nexsi.com [172.18.14.99]) by mail.nexsi.com (8.9.3/8.9.3) with SMTP id JAA10161; Wed, 11 Jul 2001 09:38:33 -0700 From: "sankar ramamoorthi" To: "Darren Dukes" , "ietf-ipsra" Subject: RE: PIC is IKE (was Re: evaluation draft)` Date: Wed, 11 Jul 2001 09:31:47 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <006a01c10a18$4e29a710$9d1c550a@cisco.com> Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit My 2 cents, I like the layering offered by PIC while maintaining the ability to share code with IKE. PIC deals with remote access, fetching configuration information, user authentication and other issues pertaining to remote access. PIC offers a nice way to integrate with existing remote access solutions. PIC can be enhanced to handle new/additional remote access requirements independent of changes to IKE. PIC can integrate the work done in other remote access groups. IKE concerns with establishing and maintaining a secure channel with the assumption that the communicating parties have necessary configuration information in place. -- sankar -- -----Original Message----- From: owner-ietf-ipsra@mail.vpnc.org [mailto:owner-ietf-ipsra@mail.vpnc.org]On Behalf Of Darren Dukes Sent: Wednesday, July 11, 2001 7:47 AM To: ietf-ipsra Subject: PIC is IKE (was Re: evaluation draft)` A PIC SA is an IKE SA, like it or not. PIC, as a authentication system, is even more complex than those 'out of scope' proposals that use an IKE SA since you now must provision and configure multiple services. If you simplify the overall authentication system you could put PIC on the SGW, now you've doubled your supported code for IKE-like exchanges. That's going to be hard to support so why not have PIC and IKE share most of their code. Now PIC is on the same box as IKE, using the same UDP port number, and better yet IKE and PIC are interdependent since they're sharing much of the same code. Why not just use IKE and simplify the code more? I don't know. Other opinions are encouraged. Darren ----- Original Message ----- From: "Hugo Krawczyk" To: "Paul Hoffman / VPNC" Cc: "ietf-ipsra" Sent: Wednesday, July 11, 2001 6:15 AM Subject: Re: evaluation draft > > > > On Tue, 10 Jul 2001, Paul Hoffman / VPNC wrote: > > > > > At 8:56 PM +0300 7/10/01, Hugo Krawczyk wrote: > > >Personally, I have no problem with those that want to change the charter > > >(I wouldn't be against, except that convergence in this case seems > > >impossible). > > > > Any discussion of the charter is out of scope. > > Therefore any evaluation of, and comparison with, solutions that do not > comply with the charter should be out of scope too. Under the current > state of affairs such discussion is noise. A constructive subject of > discussion is how to maximize the benefits, functionality, simplicity, and > security of PIC given the "charter's axioms" > > Hugo > > > > > Scott pointed out in an earlier message that we are all intelligent > > adults. Why, then, do many of us keep forgetting what has happened in > > the recent past? We have been told repeatedly that the protocol that > > comes from the WG may not change IKE. Many of us have replied "but we > > think that a change to IKE is a better solution". The response from > > the Area Directors has been unequivocal: no changing IKE, no changing > > the charter. > > > > --Paul Hoffman, Director > > --VPN Consortium > > > From owner-ietf-ipsra@mail.vpnc.org Wed Jul 11 13:10:58 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11825 for ; Wed, 11 Jul 2001 13:10:57 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6BFGZK21212 for ietf-ipsra-bks; Wed, 11 Jul 2001 08:16:35 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6BFGYm21208 for ; Wed, 11 Jul 2001 08:16:34 -0700 (PDT) Received: from toque.cisco.com (toque.cisco.com [161.44.208.153]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6BFGUl13265; Wed, 11 Jul 2001 08:16:32 -0700 (PDT) Received: from DDUKESW2K (ott-b1-dhcp-10-85-28-157.cisco.com [10.85.28.157]) by toque.cisco.com (Mirapoint) with SMTP id ABK07567; Wed, 11 Jul 2001 11:16:17 -0400 (EDT) Message-ID: <008401c10a1c$863cfb30$9d1c550a@cisco.com> Reply-To: "Darren Dukes" From: "Darren Dukes" To: "Scott G. Kelly" Cc: "ietf-ipsra" References: <3B4502BE.3A7295CD@redcreek.com> <014b01c108c0$596fb280$9d1c550a@cisco.com> <3B4B301E.915A64E4@redcreek.com> Subject: Re: evaluation draft Date: Wed, 11 Jul 2001 11:16:55 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Scott, Yet more comments inline. ----- Original Message ----- From: "Scott G. Kelly" To: "Darren Dukes" Cc: "ietf-ipsra" Sent: Tuesday, July 10, 2001 12:41 PM Subject: Re: evaluation draft > > Hi Darren, > > Thanks for taking the time to read the draft and comment. Responses > interspersed below... > > > Darren Dukes wrote: > > > > Scott, here are some initial comments. > > > > 1 - You should add a section stating provisioning complexities. If a user > > wants to provision a remote access VPN but does not want to provision a PKI, > > why would they want to deploy an AS for PIC, which is just a CA using > > legacy authentication mechanisms for enrolment? > > There is some truth here, and I can add some text to the draft to > reflect this. However, we should note that a very limited "PKI" is > required. If you use any of the proposed techniques with certificates > (and since preshared keys simply won't scale, you likely will have to), > you must support a number of PKI components anyway. The additional > requirement here is a cert generator. As an aside, the current > definition of PIC provides for generation of a shared secret in place of > a cert. I don't know if this feature will survive or not, but it does > address your concern, I think. The cert generator is the main differentiator here and its implementation and provisioning will initially be the main point of failure if people implement PIC. I doubt the shared secret idea will survive since it requires some possibly complex interoperation with the SGW and AS using some as yet undefined protocol. > > > 2 - You suggest a reduction in security with an increase in complexity > > "Hence, the probability of an oversight or error which impacts on critical > > system function is proportional to system complexity, and software > > development experience to date suggests that as systems grow increasingly > > complex, this probability nears unity." Is this your own idea or do you > > have some data or a published authority that can back this up? > > Well, I don't have any citations handy, though I suspect that it > wouldn't be too hard to come up with some which support the general > premise (number of bugs increases with code complexity). Bruce Schneier > has asserted this in publications, and you can find similar statements > in software engineering texts. You could also look at the Software > Engineering Institute's web site. In terms of real-world data, you could > go to your own QA lab (as I could go to mine), we could look at the > numerous patches we see for virtually every release of every operating > system, and those of us with extensive coding experience can draw upon > our own past experience to confirm this premise. I think this is > obvious. OK, what I was looking for here was some published data to back this up since simply stating a 'fact' and providing many sentances of anicdotal evidance does not make the 'fact' any more true. My basic point is that many solutions can add complexity in different ways. One of the problems Ferguson and Schneier point out with IPSec is the diferent modes of operation (transport and Tunnel, ESP and AH). Do you think adding yet another Pre-ESP SA is going to simplify the overall system? I don't. > > > 4 - Does an increase in complexity causing a unity decrease in security > > also extend to provisioning of the security solution with multiple servers > > that must now be configured? If so are the "Two additional goals" you state > > in section 2 still valid? > > This twists things around a bit, I think. The draft does not say there > is a "unity decrease in security", it says... well, read the quote for > yourself in your previous comment above. > > On the other hand, you are right that there is a complexity increase. > More on this in a separate thread... Actually I'm not twisting your words here. A decrease in security due to an increase in complexity is exactly what you were suggesting. I'm suggesting that your definition of complexity is too simplistic and must look at the overall system design. Maybe you could expand on that in the separate thread? > > > 5 - If a separate IRAS is not deployed for PIC but it exists on the SGW, PIC > > and Hybrid have the same DoS vulnerabilities. > > As an aside, IRAS has been defined as being equivalent to a SGW which > provides remote access. The PIC draft defines an AS (Authentication > Server), which is what I think you mean. While it is true that they have > similar vulnerabilities, they are not the same. Nonetheless, PIC is > clearly vulnerable to DoS attacks. I don't think it is possible to > completely eliminate this vulnerability, given that you have to accept > connections from anyone, but I think it we should strive to minimize it. > More on this later... You've hit the nail on the head here. You can't eliminate the DoS attack vulnerability so why bother creating a new protocol with the same DoS vulnerability (must accept connections from anybody)? > [...snip...] > > > 8 - I disagree with the Hybrid/Xauth issues: [snip] > > You write "Adding an open-ended number of challenge-rsp exchanges to a > > key exchange increases vulnerability to denial of service attack under some > > circumstances, and absolutely increases the complexity of the key exchange > > mechanism under all circumstances[... etc]" This is the same as the issue > > above, and all SGW implementations must deal with this by throttling the > > amount of processor time they will allow IKE (or PIC) to use > > If they throttle the amount of processor they allow ike, this may > prevent legitimate users from connecting, right? I'm not saying this > isn't a valid response to a DoS attack, I'm only pointing out that it > doesn't make the problem go away. The exact same is true for PIC. > > > > You write "Xauth requires support for its companion, modecfg." Others > > have already provided valid comments here... > > I don't have an xauth draft handy right now, so correct me if I'm wrong: > I believe that xauth references modecfg, and the "transaction exchange" > it uses is defined in the modecfg draft. This means that for xauth to > advance, either the modecfg draft must advance with it, or the modecfg > draft must be discarded, with the functionality required for xauth > defined solely in the xauth draft (as a unique exchange). I don't think > modecfg will advance, given that the ipsec-dhcp draft has advanced. There are options here to be explored and merging the drafts may be one of them. > > > You write "[HYBRID] is trivially susceptible to DoS attacks, as it > > requires the IRAS to engage in an unauthenticated Diffie-Hellman exchange > > which includes an expensive public key operation, and then to continue the > > conversation for some period of time beyond that, perhaps in error." Yes > > and this should be throttled by the implementation to prevent DoS attacks. > > PIC will also suffer from this if run on the SGW. > > Which is why, if this is a concern, the fact that PIC can run on a > standalone AS may be an attractive feature. > This is true but the end result is the same. > Scott From owner-ietf-ipsra@mail.vpnc.org Wed Jul 11 16:59:52 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20368 for ; Wed, 11 Jul 2001 16:59:52 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6BKJ0I06022 for ietf-ipsra-bks; Wed, 11 Jul 2001 13:19:00 -0700 (PDT) Received: from beach.sctc.com (beach.sctc.com [192.55.214.50]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6BKIwm06017 for ; Wed, 11 Jul 2001 13:18:59 -0700 (PDT) Received: from beach.sctc.com (root@localhost) by beach.sctc.com with ESMTP id f6BJwhH05299; Wed, 11 Jul 2001 14:58:43 -0500 (CDT) Received: from sphinx.sctc.com (sphinx.sctc.com [172.17.192.3]) by beach.sctc.com with ESMTP id f6BJwhm05295; Wed, 11 Jul 2001 14:58:43 -0500 (CDT) Received: from gandalf.sctc.com (gandalf.sctc.com [172.17.192.103]) by sphinx.sctc.com (8.8.8+Sun/8.7.3) with ESMTP id PAA21466; Wed, 11 Jul 2001 15:18:59 -0500 (CDT) Received: from localhost (allison@localhost) by gandalf.sctc.com (8.9.3+Sun/) with ESMTP id PAA29397; Wed, 11 Jul 2001 15:18:58 -0500 (CDT) Date: Wed, 11 Jul 2001 15:18:57 -0500 (CDT) From: Tylor Allison X-X-Sender: To: Darren Dukes cc: ietf-ipsra Subject: Re: PIC is IKE (was Re: evaluation draft)` In-Reply-To: <006a01c10a18$4e29a710$9d1c550a@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Is there any hope of compromise and consensus towards reaching a solution? I've spent some time now going back through the archives, through the massive flame wars, through the issues which have been iterated and reiterated in the hopes that I could find some semblance of consensus towards a solution. Unfortunately I have reaffirmed my current belief that there is none. There has never been any clear consensus towards a single solution. Take a look at the last strawpoll as an example. It showed that the group is split between doing an OOB method (pref. PIC) and methods which require a new authentication method to IKE (CRACK/Hybrid). And yes, there is a slight majority which prefers the OOB method. Consensus however is not a slight majority. I know this point has been made previously as well. And members of this group have warned what it might mean for a WG group to come up with standards which were formed when no real consensus was established. And the thought of having to support multiple Remote Access protocols because that is what is out there in the real world does not make sense to me. Nor will it make sense to our customers who have to manage our products and make them work together. Again I ask is there anyway that we can reach a compromise, and hopefully a consensus? I've thought of a way that at least makes sense to me. The compromise is based on the argument that Darren is trying to make. I also believe I saw atleast a couple of references to this proposal in the various threads from the archives... What I am proposing is to merge what is trying to be done with PIC with what is trying to be done with CRACK (Hybrid may also work). If you look at what is being done with PIC, it is very similar to what CRACK does. You have IKE code which establishes a secure connection using legacy authentication. PIC then uses this secure connection to retrieve credential information, while CRACK uses the secure connection as a Phase 1 SA. One of the pros that PIC proponents have contended is that because PIC provides for credentials to be used by IKE, the PIC components can be separate from the traditional IPSEC components. Furthermore, PIC provides a way to implement PKI single-sign on capabilities because these IKE credentials can be re-used. Now, what if these functions could be combined? Define a new method or exchange to perform legacy-based authentication in IKE (this could be a blend of PIC and CRACK). Next define a new method or exchange to perform user credential retrieval in IKE. Now define how these new methods can be used together and also how they can be used to establish a phase 2 connection. Basically I see a few scenarios here: o The CRACK scenario - The new legacy-based auth method is used to create a secure connection (phase 1 SA). This phase 1 SA is used directly to start phase 2 SA. o The PIC scenario - The new legacy-based auth method is used to create a secure connection. The new credential retrieval method is used to retrieve user credentials. The new credentials are used to establish phase 1 SA. The phase 1 SA is then used to establish phase 2 SA. o The PIC scenario - (another option) The new legacy-based auth method is used to create a secure connection (phase 1 SA). The new credential retrieval method is used (under protection from phase 1 SA) to retrieve user credentials (to be used for rekey or single sign on). The phase 1 SA is then used to establish phase 2 SA. This solution provides a way to field the following implementations: o New IKE component hosted by separate server which only does the above PIC scenario... it only provides user credentials. This implementation could then be used with existing traditional IKE implementations without having to change those implementations. This is the same basic concept as PIC. o New SGW modifies existing IKE component and implements only the CRACK scenario above. This is the same basic concept as CRACK. o New SGW modifies existing IKE component and implements the PIC scenario. This method allows new SGW to add remote access features plus single-sign on features. I know that this may not be a perfect solution, and I haven't thought through all of the implications of this solution. But I'm trying to figure out a way a to reach a compromise between the PIC group and the "modify IKE" group. I am very open to other ideas which can lead this group to consensus. A couple of thoughts on IKE modification, as I'm sure it will come up. The charter currently states: "The WG strongly prefers mechanisms that require no changes to AH, ESP or IKE protocols". After reading Paul's messages it would appear that the Area Directors take in this is absolute. IPSRA may not change IKE at all. Is this to prevent IPSRA from mucking with existing protocol (e.g. Main Mode/Quick Mode) or to prevent IKE's feature set from growing thus adding complexity? From the arguments on the list I would assume the latter, but I just wanted to check. --- Tylor Allison tylor_allison@securecomputing.com Secure Computing Corporation On Wed, 11 Jul 2001, Darren Dukes wrote: > > A PIC SA is an IKE SA, like it or not. PIC, as a authentication system, is > even more complex than those 'out of scope' proposals that use an IKE SA > since you now must provision and configure multiple services. If you > simplify the overall authentication system you could put PIC on the SGW, now > you've doubled your supported code for IKE-like exchanges. That's going to > be hard to support so why not have PIC and IKE share most of their code. > Now PIC is on the same box as IKE, using the same UDP port number, and > better yet IKE and PIC are interdependent since they're sharing much of the > same code. Why not just use IKE and simplify the code more? I don't know. > > Other opinions are encouraged. > > Darren > > ----- Original Message ----- > From: "Hugo Krawczyk" > To: "Paul Hoffman / VPNC" > Cc: "ietf-ipsra" > Sent: Wednesday, July 11, 2001 6:15 AM > Subject: Re: evaluation draft > > > > > > > > > > On Tue, 10 Jul 2001, Paul Hoffman / VPNC wrote: > > > > > > > > At 8:56 PM +0300 7/10/01, Hugo Krawczyk wrote: > > > >Personally, I have no problem with those that want to change the > charter > > > >(I wouldn't be against, except that convergence in this case seems > > > >impossible). > > > > > > Any discussion of the charter is out of scope. > > > > Therefore any evaluation of, and comparison with, solutions that do not > > comply with the charter should be out of scope too. Under the current > > state of affairs such discussion is noise. A constructive subject of > > discussion is how to maximize the benefits, functionality, simplicity, and > > security of PIC given the "charter's axioms" > > > > Hugo > > > > > > > > Scott pointed out in an earlier message that we are all intelligent > > > adults. Why, then, do many of us keep forgetting what has happened in > > > the recent past? We have been told repeatedly that the protocol that > > > comes from the WG may not change IKE. Many of us have replied "but we > > > think that a change to IKE is a better solution". The response from > > > the Area Directors has been unequivocal: no changing IKE, no changing > > > the charter. > > > > > > --Paul Hoffman, Director > > > --VPN Consortium > > > > > > > From owner-ietf-ipsra@mail.vpnc.org Wed Jul 11 20:55:54 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26221 for ; Wed, 11 Jul 2001 20:55:53 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f6C0LqF12221 for ietf-ipsra-bks; Wed, 11 Jul 2001 17:21:52 -0700 (PDT) Received: from internaut.com ([64.38.134.99]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6C0Lpm12216 for ; Wed, 11 Jul 2001 17:21:51 -0700 (PDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id RAA49441; Wed, 11 Jul 2001 17:14:00 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Wed, 11 Jul 2001 17:14:00 -0700 (PDT) From: Bernard Aboba To: Darren Dukes cc: ietf-ipsra Subject: Re: PIC is IKE (was Re: evaluation draft)` In-Reply-To: <006a01c10a18$4e29a710$9d1c550a@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Darren Dukes said: > > A PIC SA is an IKE SA, like it or not. PIC, as a authentication system, is > even more complex than those 'out of scope' proposals that use an IKE SA > since you now must provision and configure multiple services. If you > simplify the overall authentication system you could put PIC on the SGW, now > you've doubled your supported code for IKE-like exchanges. That's going to > be hard to support so why not have PIC and IKE share most of their code. > Now PIC is on the same box as IKE, using the same UDP port number, and > better yet IKE and PIC are interdependent since they're sharing much of the > same code. Why not just use IKE and simplify the code more? I don't know. > Well, it certainly begs the question of why the dual implementation would be thought to be more secure than the single integrated approach. If more code = less security, then the solution with less code would be better, right? Another question that comes to mind is why the IPSRA WG is designing what is essentially a certificate enrollment protocol. Isn't that the role of PKIX? I realize there may be lots of reasons why they don't want to handle this right now, but at the very least, some consultation and review would be helpful. As a practical matter, selling a cert enrollment solution requires the buyin of the certificate infrastructure folks. Trying to do an end run around them seems doomed to failure. Overall, I have this sinking feeling that we are on a road to nowhere. I don't know when or where the other shoe will drop, but I feel relatively certain that it will happen, and I'd rather have it be sooner so that we can get on with working on an approach that is likely to be successful. From owner-ietf-ipsra@mail.vpnc.org Wed Jul 11 21:28:43 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA26668 for ; Wed, 11 Jul 2001 21:28:43 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6C0qsT12930 for ietf-ipsra-bks; Wed, 11 Jul 2001 17:52:54 -0700 (PDT) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6C0qrm12926 for ; Wed, 11 Jul 2001 17:52:53 -0700 (PDT) Received: by mail.redcreek.com with Internet Mail Service (5.5.2653.19) id <3G8WYDYR>; Wed, 11 Jul 2001 17:53:39 -0700 Received: from redcreek.com (host43.redcreek.com [209.218.26.43]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3G8WYDYQ; Wed, 11 Jul 2001 17:53:36 -0700 From: "Scott G. Kelly" To: ipsra list Message-ID: <3B4CF50D.C1C172D@redcreek.com> Date: Wed, 11 Jul 2001 17:53:33 -0700 Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: doh! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I have it on good cryptographic authority that my complaints about known plaintext in xauth, assuming 3DES CBC, are entirely unfounded. Boy, do I feel stupid. My apologies for the spectacle... Scott From owner-ietf-ipsra@mail.vpnc.org Thu Jul 12 01:59:50 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA21110 for ; Thu, 12 Jul 2001 01:59:49 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f6C5MCk18077 for ietf-ipsra-bks; Wed, 11 Jul 2001 22:22:12 -0700 (PDT) Received: from internaut.com ([64.38.134.99]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6C5MAm18070; Wed, 11 Jul 2001 22:22:10 -0700 (PDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id WAA49661; Wed, 11 Jul 2001 22:14:17 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Wed, 11 Jul 2001 22:14:17 -0700 (PDT) From: Bernard Aboba To: Hugo Krawczyk cc: Paul Hoffman / VPNC , ietf-ipsra Subject: Re: evaluation draft In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > A constructive subject of > discussion is how to maximize the benefits, functionality, simplicity, and > security of PIC given the "charter's axioms" > Well, for us to achieve this, I think we need to have a requirements document which helps us decide whether we are getting closer or further to our end goal. Otherwise, it's hard to know when we're done. A lot of what we have been talking about in this email thread is the way in which we measure the quality of a solution. In looking at the requirements document, I'm not at all clear that it gives us the kind of guidance that we need for the current set of problems we are addressing. For example, the requirements document does not address: 1. Requirements for integration with existing or developing certificate management protocols. In fact, it doesn't talk about certificate management issues at all, even though that is now the central activity of this WG. 2. Requirements for implementability, expressed in terms of concrete metrics. For example, some people have argued that code size (a proxy for complexity) is very important. Others think that separation of functions is valuable. Until we have a clear idea of what makes a solution more or less secure, or more or less implementable, it's hard to figure out how to improve it. In general, I think that one of the worst aspects of the dictates that we have been under is that, by closing off discussion, they have prevented us from understanding what the valid metrics are for measuring success. The dictates, by being invariant, either constitute universal truths, in which case we must achieve a deep understanding of them and incorporate them into the requirements, or they they represent a knee jerk response to a complex problem, in which case they should be discarded. Unless we're allowed to discuss and understand them, it's hard to tell which of these alternatives is closer to the truth. From owner-ietf-ipsra@mail.vpnc.org Thu Jul 12 02:35:08 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA02832 for ; Thu, 12 Jul 2001 02:35:07 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6C5tpn18631 for ietf-ipsra-bks; Wed, 11 Jul 2001 22:55:51 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6C5tnm18623; Wed, 11 Jul 2001 22:55:49 -0700 (PDT) Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f6C5twj29873; Wed, 11 Jul 2001 22:55:58 -0700 (PDT) Received: from SFANNINGW2K (golshan-dsl3.cisco.com [10.19.0.44]) by mira-sjcm-3.cisco.com (Mirapoint) with SMTP id AAH03172; Wed, 11 Jul 2001 22:55:47 -0700 (PDT) From: "Scott Fanning" To: "'Bernard Aboba'" , "'Hugo Krawczyk'" Cc: "'Paul Hoffman / VPNC'" , "'ietf-ipsra'" Subject: RE: evaluation draft Date: Wed, 11 Jul 2001 22:57:58 -0700 Message-ID: <000e01c10a97$9ba9cae0$2c00130a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit See inline (STF).. -----Original Message----- From: owner-ietf-ipsra@mail.vpnc.org [mailto:owner-ietf-ipsra@mail.vpnc.org]On Behalf Of Bernard Aboba Sent: Wednesday, July 11, 2001 10:14 PM To: Hugo Krawczyk Cc: Paul Hoffman / VPNC; ietf-ipsra Subject: Re: evaluation draft > A constructive subject of > discussion is how to maximize the benefits, functionality, simplicity, and > security of PIC given the "charter's axioms" > Well, for us to achieve this, I think we need to have a requirements document which helps us decide whether we are getting closer or further to our end goal. Otherwise, it's hard to know when we're done. A lot of what we have been talking about in this email thread is the way in which we measure the quality of a solution. In looking at the requirements document, I'm not at all clear that it gives us the kind of guidance that we need for the current set of problems we are addressing. STF>> I would hope that the quality of the solution is judged by what the user community wants. We are trying to solve real problems that real people are running into, and not just an academic exercise. Complexity of the solution is not just a weakness in a secure solution, but a barrier to adoption by the people this group serves. For example, the requirements document does not address: 1. Requirements for integration with existing or developing certificate management protocols. In fact, it doesn't talk about certificate management issues at all, even though that is now the central activity of this WG. STF>> I am not sure when this became the central activity of this working group. I have some concerns about that. I always thought it was to facilitate the configuration requirements for remote access and to support legacy authentication/authorization infrastructures. If certificates are the mechanism for this to be done, then the PKIX WG seems more appropriate. 2. Requirements for implementability, expressed in terms of concrete metrics. For example, some people have argued that code size (a proxy for complexity) is very important. Others think that separation of functions is valuable. Until we have a clear idea of what makes a solution more or less secure, or more or less implementable, it's hard to figure out how to improve it. STF>>I agree. I think that since there are some requirements that are more remote access (yes, this definition may be where the central question lies), and have little to do with the site-to-site domain, having remote access delimited from the existing IPSec requirement seems architecturally sound. In general, I think that one of the worst aspects of the dictates that we have been under is that, by closing off discussion, they have prevented us from understanding what the valid metrics are for measuring success. The dictates, by being invariant, either constitute universal truths, in which case we must achieve a deep understanding of them and incorporate them into the requirements, or they they represent a knee jerk response to a complex problem, in which case they should be discarded. Unless we're allowed to discuss and understand them, it's hard to tell which of these alternatives is closer to the truth. STF>>At many an IETF, I have mentioned (and many others) that any charter that cuts off the free flow of ideas within the problem space provided was doomed to fail. I would humbly suggest that we put all the cards on the table, and start looking at a solution to this problem, before the credibility of the security framework we have all worked to hard to promote, dies a horrible death. STF>> Although I may not agree with some of Scotts assertions, I do appreciate his willingness to promote an open discussion. Thanks. Regards Scott From owner-ietf-ipsra@mail.vpnc.org Thu Jul 12 14:08:37 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28602 for ; Thu, 12 Jul 2001 14:08:36 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6CH78R02316 for ietf-ipsra-bks; Thu, 12 Jul 2001 10:07:08 -0700 (PDT) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6CH77m02312 for ; Thu, 12 Jul 2001 10:07:07 -0700 (PDT) Received: by mail.redcreek.com with Internet Mail Service (5.5.2653.19) id <3G8WYF17>; Thu, 12 Jul 2001 10:07:52 -0700 Received: from redcreek.com (host43.redcreek.com [209.218.26.43]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3G8WYF16; Thu, 12 Jul 2001 10:07:51 -0700 From: "Scott G. Kelly" To: ipsra list Message-ID: <3B4DD962.26891D80@redcreek.com> Date: Thu, 12 Jul 2001 10:07:46 -0700 Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: continuing the discussion on complexity (long post) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit This is to continue the discussion of complexity as it relates to the legacy authentication problem and security. Think of it as me thinking out loud. I'd say "feel free to disagree, criticize, etc.", but I don't think anyone will be shy about that... Clearly, anything we do is going to add complexity to the overall system of remote user and whatever systems he must interact with (IRAS, AS, CA, or whatever). As Hugo pointed out in an earlier post to the ipsec list, nothing is free, and added security typically means added complexity (as does added functionality). I don't think anyone would disagree that as code becomes more complex, it becomes more difficult to assert that it does exactly (and only) what it is intended to do. On the other hand, we want our systems to deliver more and more functionality, so we typically choose to accept some risk in exchange. Normally, the additional incurred risk is mitigated through conscientious and well-thought-out testing, but no matter how careful we are, we cannot typically be certain that we've thought of everything. Obviously, the level of effort we devote to careful design and testing is proportional to the value the subject system (or program) provides, and to the risk we face in case of malfunction. If an error is likely to carry a high price tag, we tend to be much more careful in our approach, and rightly so. In such cases, we have to balance the desire for added functionality against the cost of system failure. In cases where the cost of failure is relatively low, we may choose not to concern ourselves with this. In cases where the cost might be very high, we often look for ways to improve the likelihood that failure will not occur. Perhaps the most obvious way to reduce risk is to simplify the system in every way possible. The simpler the system, the more likely it is that we may accurately characterize and understand it. However, in some cases this may lead to unacceptable functional loss, and in such cases we must either give up entirely, or add the functionality anyway, and attempt to derive a test plan which gives us a relatively high level of confidence in the stability and resilience of the subject system. Numerous considerations must be weighed against the desire to reduce complexity. An IPsec security gateway is a very complex system. To some extent, this is unavoidable, as the underlying functionality requirements demand it. For many security gateways, the cost of some types of failure could be extremely high. In order to limit exposure, the designer of such a system has two options: simplify wherever possible, and test as thoroughly as practicable. Unfortunately, IETF standards do not prescribe test procedures, nor should they. This might lead one to ask whether it might not be most appropriate to be conservative with respect to complexity when producing an IETF standard for a security system. It should also be noted that security requirements vary by circumstance. In some cases, it is imperative that communications integrity be as nearly absolute as may be obtained. In other cases, where the cost of integrity loss is lower, it is not as important. In between, there is something of a continuum along which other deployments may be placed according to circumstance. When there is a desire to create a product anywhere along this continuum, there is a tendency to select the least costly mechanism which suffices. When creating networking products, there is a simultaneous desire to standardize the solution. Clearly, we cannot standardize individual solutions to meet the needs of every discrete situation along the security spectrum. The more reasonable solution is to select a manageable subset, and let folks choose the closest fit. In terms of both of getting the work done and of making the number of choices reasonable from a security perspective, less choices are better, as the alternative is to place additional deployment complexity squarely in front of the user, and hope that they make the right choice. It should be noted that a solution which satisfies the most stringent security requirements will meet the security requirements of all, and that such a solution is required if we are to meet the needs of the high end of the spectrum. On the other hand, this solution may prove too costly for those with lesser security requirements. For some of these cases, we already have at least one standards track alternative: L2TP in IPsec. So, we need a very strong mechanism, and we have a middle-of-the-road mechanism. Do we need more than this? Maybe not - but this question must be definitively answered. ---------------------------- As regards our problem, IKE provides no support for username/passphrase authentication, but the market clearly requires this support if IPsec is to be used for remote access. It has been argued that IKE is too complex already, and that if possible, a solution which requires no changes to IKE should be found. What is the basis of this argument? IKE, due in part to the general design of ISAKMP, supports a large number of options in various combinations. The preceding complexity discussion illustrates why this entails more risk from a security perspective than a simpler more limited key exchange protocol implementation might. It is very difficult to guage the effect of interactions between the code implementing various options in varying combinations, and put simply, it requires lots more code, implying the likelihood of more undetected bugs. Bugs in security gateway code could result in system compromise. Adding functionality to this code base simply serves to increase this risk. This has prompted the call for proposals for independent solutions which do not modify IKE. The point has been made that PIC/GetCert + enrollment is more complex than hybrid (or whatever). In a global system sense this is certainly true. However, it is not true with respect to the security gateway if the AS is a standalone system. That is, this particular approach may be implemented without changing the underlying IPsec implementation. This means that the code running on the security gateway is less complex than it would be otherwise, and that from this we gain some relative assurance that we have not introduced new problems into the gateway code. This may or may not be an important consideration, depending upon the exposure in case of gateway failure. Now, is the gateway actually more secure with an outboard AS implementation than it would be with simpler changes to IKE? Well... we don't know for sure. What we may believe is that it *probably* is, or that it might be. On the other hand, if we implement the same solution on the gateway rather than on a standalone AS, we have certainly increased the code complexity on the gateway. Hence, by the same reasoning we must conclude that the security of the gateway may be reduced due to this added complexity, especially when compared with a similar system implementing a simpler mechanism. Additionally, with the choice of PIC or GetCert, the remote access client code will be more complex than it could be with some other approach. In order to isolate the legacy user authentication operation from IKE, it is necessary for this operation to produce a credential of some sort which may be used in subsequent IKE communications. This credential may be either a public key certificate, or a shared secret. The client must interact with the AS in order to obtain this, and then make it available to the IPsec subsystem. If we choose a shared secret, this must be distributed to both the remote client and the gateway upon successful user authentication. Even if a standalone AS is employed, this still increases code complexity on the gateway. If failover and/or load balancing support is provided, the secret must be provided to all participating gateways prior to providing it to the client, and this significantly increases gateway code complexity regardless of where the AS is implemented. If we choose the certificate, no interaction is needed with participating gateways, though the gateway(s) must have a mechanism for verifying the certificate. If the client certificates are sufficiently short-lived, gateway possession of a valid verification certificate may be sufficient in this regard. Otherwise, CRL or online status checking is required. However, these functionalities are required for site-to-site gateways as well. If the AS is implemented in the gateway, either an outboard CA function is required, or all associated failover/load-balancing gateways must share the signing key. It seems clear that if we allow the AS to co-reside on the gateway, the code complexity is significantly higher than with other IKE-based techniques which do not provide a reusable credential (due to the certificate generation functionality). Hence, from a security perspective, there is some likelihood that we are better off to use an outboard AS for this particular solution type. On the other hand, this adds overall solution complexity for system as a whole, and for the user. It may increase gateway security, but it costs more. There may also be a question as to whether this added complexity serves to decrease the overall remote access system security. If we choose one of the other proposed IKE-based solutions, what do we gain (or lose)? Eliminating the need for a CA component reduces cost and system complexity, but also eliminates the single sign-on capability a short-lived certificate would provide. Additionally, it may provide less market incentive to move to stronger user authentication mechanisms. On the other hand, when compared to a gateway AS implementation, the alternative mechanisms likely result in significantly less complex gateway code than the AS, but there would still be a net complexity increase. It seems that no matter which solution we choose, we must accept some increased complexity in exchange for the added functionality. Also, the two proposed solution classes offer different features, and the need for these features must be weighed against the security requirements and the desire to reduce complexity. If single sign-on and PKI migration are important goals, these will drive the solution in one direction. If not, there is far less justification for the AS approach. ------------------- Scott From owner-ietf-ipsra@mail.vpnc.org Thu Jul 12 17:34:07 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27864 for ; Thu, 12 Jul 2001 17:34:07 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6CKbBA06374 for ietf-ipsra-bks; Thu, 12 Jul 2001 13:37:11 -0700 (PDT) Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6CKb9m06369 for ; Thu, 12 Jul 2001 13:37:09 -0700 (PDT) Received: (qmail 23173 invoked by uid 0); 12 Jul 2001 20:37:03 -0000 Received: from c3600-2-70.bezeqnet135.netvision.net.il (HELO pop3.norton.antivirus) (62.0.186.194) by mail.gmx.net (mp007-rz3) with SMTP; 12 Jul 2001 20:37:03 -0000 Received: by pop3.norton.antivirus with Microsoft Mail id <01C10B2B.8AAD5880@pop3.norton.antivirus>; Thu, 12 Jul 2001 23:36:58 +0200 Message-ID: <01C10B2B.8AAD5880@pop3.norton.antivirus> From: Yaron Sheffer To: "IPSRA List (E-mail)" Subject: PIC port assignment Date: Thu, 12 Jul 2001 23:36:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f6CKbAm06370 Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit As an aside to the current flame war, I'd like to clarify the issue of a separate port for PIC. In the current draft, we have chosen to reuse the ISAKMP (*not* IKE) port, UDP/500. PIC is distinguished from IKE by a different ISAKMP Exchange Type, so this is formally OK. This works fine theoretically, but may present problems when implementing a PIC Client and especially Authentication Server, on a machine that has an existing IKE implementation - port 500 is taken, and you're stuck unless you have access to the source code. On the other hand, adding another port makes deployment a little more difficult, since the new port needs to be defined on firewalls. And one more point, the recent IPSec-in-UDP draft uses port 500 for the whole IPSec session! If itbecomes standard, the port will be multiplexed anyway. I'd like to hear opinions from the list, before applying (or not) for a port assignment. Thanks, Yaron From owner-ietf-ipsra@mail.vpnc.org Fri Jul 13 04:06:19 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA27804 for ; Fri, 13 Jul 2001 04:06:18 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6D7Tee01747 for ietf-ipsra-bks; Fri, 13 Jul 2001 00:29:40 -0700 (PDT) Received: from mta1-3.us4.outblaze.com (205-158-62-44.outblaze.com [205.158.62.44]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6D7Tdq01739 for ; Fri, 13 Jul 2001 00:29:39 -0700 (PDT) Received: (qmail 23199 invoked from network); 13 Jul 2001 07:28:32 -0000 Received: from unknown (HELO mta1-1.us4.outblaze.com) (205.158.62.45) by 205-158-62-44.outblaze.com with SMTP; 13 Jul 2001 07:28:32 -0000 Received: (qmail 11065 invoked by uid 0); 13 Jul 2001 07:28:32 -0000 MBOX-Line: From owner-ietf-ipsra@mail.vpnc.org Fri Jul 06 03:22:34 2001 Received: (qmail 27421 invoked from network); 5 Jul 2001 18:20:46 -0000 Received: from unknown (HELO spf5.us4.outblaze.com) (205.158.62.27) by 205-158-62-45.outblaze.com with SMTP; 5 Jul 2001 18:20:46 -0000 Received: from above.proper.com (above.proper.com [208.184.76.39]) by spf5.us4.outblaze.com (8.11.0/8.11.0) with ESMTP id f65Gmfd18621; Thu, 5 Jul 2001 16:48:41 GMT Received: by above.proper.com (8.11.3/8.11.3) id f65GD7m17347 for ietf-ipsra-bks; Thu, 5 Jul 2001 09:13:07 -0700 (PDT) Received: from [165.227.249.20] (ip20.proper.com [165.227.249.20]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f65GD6m17342 for ; Thu, 5 Jul 2001 09:13:06 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: Date: Thu, 5 Jul 2001 09:12:40 -0700 To: ietf-ipsra@vpnc.org From: Paul Hoffman / VPNC Subject: Fwd: Protocol Action: DHCPv4 Configuration of IPSEC Tunnel Mode to Proposed Standard Content-Type: text/plain; charset="us-ascii" ; format="flowed" List-Archive: List-ID: List-Unsubscribe: Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Congratulations to the WG; we have our first standard out. >To: IETF-Announce: ; >Cc: RFC Editor >Cc: Internet Architecture Board >Cc: ipsec@lists.tislabs.com >From: The IESG >Subject: Protocol Action: DHCPv4 Configuration of IPSEC Tunnel Mode to > Proposed Standard >Date: Thu, 05 Jul 2001 10:23:59 -0400 >Sender: owner-ipsec@lists.tislabs.com > > > >The IESG has approved the Internet-Draft 'DHCPv4 Configuration of IPSEC >Tunnel Mode' as a Proposed Standard. >This document is the product of the IPSEC Remote Access (IPSRA) Working >Group. The IESG contact persons are Jeffrey Schiller and Marcus >Leech. > > >Technical Summary > > This protocol provides a mechanism for IPSEC tunnel configuration using > the existing DHCP, IKE and IPSEC protocols. It defines a new HTYPE > for IPSEC virtual interfaces, and describes the steps necessary to make > DHCP work correctly and securely for IPSEC tunnel configuration. > >Working Group Summary > > The competitor to this protocol, IKECFG, has been largely dismissed by > both the IPSEC and IPSRA working groups. There was no significant dissent > during the LAST CALL period. The document outlines why it is a more > appropriate solution than IKECFG. > >Protocol Quality > > This document was reviewed by Marcus Leech. At least two implementations > are known to exist. From owner-ietf-ipsra@mail.vpnc.org Fri Jul 13 04:06:30 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA27839 for ; Fri, 13 Jul 2001 04:06:30 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6D7RTe01226 for ietf-ipsra-bks; Fri, 13 Jul 2001 00:27:29 -0700 (PDT) Received: from mta1-3.us4.outblaze.com (205-158-62-44.outblaze.com [205.158.62.44]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6D7RRq01218 for ; Fri, 13 Jul 2001 00:27:27 -0700 (PDT) Received: (qmail 20952 invoked from network); 13 Jul 2001 07:27:11 -0000 Received: from unknown (HELO mta1-1.us4.outblaze.com) (205.158.62.45) by 205-158-62-44.outblaze.com with SMTP; 13 Jul 2001 07:27:11 -0000 Received: (qmail 8164 invoked by uid 0); 13 Jul 2001 07:27:08 -0000 MBOX-Line: From owner-ietf-ipsra@mail.vpnc.org Thu Jul 05 21:30:24 2001 Received: (qmail 8104 invoked from network); 5 Jul 2001 11:36:26 -0000 Received: from unknown (HELO spf3.us4.outblaze.com) (205.158.62.25) by 205-158-62-45.outblaze.com with SMTP; 5 Jul 2001 11:36:26 -0000 Received: from above.proper.com (above.proper.com [208.184.76.39]) by spf3.us4.outblaze.com (8.11.0/8.11.0) with ESMTP id f65BaFt30369; Thu, 5 Jul 2001 11:36:15 GMT Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f65ArDM28646 for ietf-ipsra-bks; Thu, 5 Jul 2001 03:53:13 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f65ArCm28639 for ; Thu, 5 Jul 2001 03:53:12 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06348; Thu, 5 Jul 2001 06:52:28 -0400 (EDT) Message-Id: <200107051052.GAA06348@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ipsra@vpnc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsra-pic-02.txt Date: Thu, 05 Jul 2001 06:52:27 -0400 List-Archive: List-ID: List-Unsubscribe: Sender: owner-ietf-ipsra@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 Remote Access Working Group of the IETF. Title : PIC, A Pre-IKE Credential Provisioning Protocol Author(s) : Y. Sheffer, H. Krawczyk, B. Aboba Filename : draft-ietf-ipsra-pic-02.txt Pages : 23 Date : 03-Jul-01 This document presents a method to bootstrap IPSec authentication via an 'Authentication Server' (AS) and legacy user authentication (e.g., RADIUS). The client machine communicates with the AS using a key exchange protocol where only the server is authenticated, and the derived keys are used to protect the legacy user authentication. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsra-pic-02.txt 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-ipsra-pic-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-ipsra-pic-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: <20010703124508.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsra-pic-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsra-pic-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010703124508.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ipsra@mail.vpnc.org Fri Jul 13 04:18:34 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA29077 for ; Fri, 13 Jul 2001 04:18:33 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6D7gNl03349 for ietf-ipsra-bks; Fri, 13 Jul 2001 00:42:23 -0700 (PDT) Received: from mta1-3.us4.outblaze.com (205-158-62-44.outblaze.com [205.158.62.44]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6D7gMq03345 for ; Fri, 13 Jul 2001 00:42:22 -0700 (PDT) Received: (qmail 1488 invoked from network); 13 Jul 2001 07:34:09 -0000 Received: from unknown (HELO mta1-1.us4.outblaze.com) (205.158.62.45) by 205-158-62-44.outblaze.com with SMTP; 13 Jul 2001 07:34:09 -0000 Received: (qmail 23250 invoked by uid 0); 13 Jul 2001 07:33:52 -0000 MBOX-Line: From owner-ietf-ipsra@mail.vpnc.org Sun Jul 08 08:28:22 2001 Received: (qmail 26424 invoked from network); 8 Jul 2001 08:28:22 -0000 Received: from unknown (HELO spf7.us4.outblaze.com) (205.158.62.41) by 205-158-62-45.outblaze.com with SMTP; 8 Jul 2001 08:28:22 -0000 Received: from above.proper.com (above.proper.com [208.184.76.39]) by spf7.us4.outblaze.com (8.11.0/8.11.0) with ESMTP id f688SFa26449; Sun, 8 Jul 2001 08:28:15 GMT Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f687oMA17348 for ietf-ipsra-bks; Sun, 8 Jul 2001 00:50:22 -0700 (PDT) Received: from ns02.newbridge.com (ns02.newbridge.com [192.75.23.75]) by above.proper.com (8.11.3/8.11.3) with SMTP id f687oFm17309 for ; Sun, 8 Jul 2001 00:50:15 -0700 (PDT) Received: (qmail 4034 invoked from network); 8 Jul 2001 07:48:20 -0000 Received: from portal1.newbridge.com (HELO kanata-mh1.ca.newbridge.com) (192.75.23.76) by ns02.newbridge.com with SMTP; 8 Jul 2001 07:48:20 -0000 Received: from kanmail02.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for ietf-ipsra@vpnc.org; Sun, 8 Jul 2001 03:46:31 -0400 Received: from andrewk3 ([138.120.49.124]) by kanmail02.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA5C47; Sun, 8 Jul 2001 03:46:29 -0400 Reply-To: From: "Andrew Krywaniuk" To: "'Scott G. Kelly'" , "'Tamir Zegman'" Cc: Subject: RE: evaluation draft Date: Sun, 8 Jul 2001 03:39:19 -0400 Message-Id: <000801c10781$39de2540$1e72788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 In-Reply-To: <3B475E7D.BA229435@redcreek.com> Importance: Normal List-Archive: List-ID: List-Unsubscribe: Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Scott, 90% of your draft could be summarized down to the simple fact that IKE is vulnerable to some kinds of DoS. The draft acknowledges that DoS attacks are in fact possible with any of the proposed authentication methods, but it is organized in such a way as to sensationalize the DoS attacks against some modes while downplaying the attacks against others. I personally consider DoS protection to be a very important feature of an encryption protocol. However, I have noticed that DoS vulnerability tends to be trivialized during actual protocol design, but it is routinely trotted out whenever someone scrapes the bottom of the evidence barrel. The fact is that IKE is vulnerable to DoS, period. Main mode forces the initiator to at least be sending packets from a routeable address, but that's about the extent of the DoS protection. Unless you are using some kind of DoS avoidance strategy that is not mentioned in the RFCs, an attacker can sit there and make you compute Diffie-Hellman keys to his heart's content. Of course, the attacker could also make you do a signature verification in addition to computing the DH secret, but why would he do this? What makes the DH attack more devestating is the fact that the attacker doesn't even have to use real DH values. He can just send you a bunch of random data and let you try to decrypt it. If he wanted to make you verify a signature, he would have to generate a properly formed message, which involves doing the DH calculation himself; that gives the attacker a much less attractive work factor. So yes, user authentication might open up new vulnerabilities that weren't previously available (in the sense that an anonymous user can force the server to do DH, PK, *and* legacy operations before the intrusion is detected), but these attacks are far less severe than the attacks that already were previously available. You might also ask yourself which is more DoS resistant: 1 dedicated gateway doing only Main Mode + 1 dedicated server doing only user auth, or 2 load-sharing gateways doing both Main Mode & user auth... > > You have made some remraks that XAUTH has a weakness of > known plaintext at > > fixed locations. > > I believe that you have raised this issue more than once > and more than once > > have been proven wrong. > > This was a very minor point, and it makes little sense to expend much > energy on it. However, I raised it once in the past (in the > ULA draft), > and it has never been proven wrong. Or rather, you have consistently ignored the proof that you were wrong. Last I heard, it has also "never been proven" that the moon landing wasn't faked or that the earth is more than 5,000 years old. If it is such a minor point then why do you bring it up every time you go off on one of your tirades about ModeCfg/XAuth/Hybrid? You consistently repeat the opinion that Hybrid has "serious security issues" yet you are unwilling to make any clear statement of what these issues are. The few points you do bring up are easily refuted. Being vague and non-commital may seem to be a good arguing strategy, but I think you misjudge the ability of the people on this list to see through you. Your claim that IKE requires implementations to accept payloads in any order for the purpose of thwarting known plaintext attacks just doesn't hold water. Most IKE messages only contain 2-3 payloads and they are of predictable length, so the number of possible permutations is small. Someone already pointed out to you a couple of years ago that the certificate payload already contains a huge block of known plaintext. The fact is that IKE is not designed to be used with ciphers that are vulnerable to known plaintext attacks. If we wanted to use that kind of weak cipher, then we wouldn't be using CBC mode; instead, we would probably use a mode of operation with infinite error propagation. And BTW, even ignoring the fact that the whole premise of your argument is wrong, XAuth allows attributes to be sent in any order anyway, so your specious premise refutes your specious argument. Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. From owner-ietf-ipsra@mail.vpnc.org Fri Jul 13 04:25:46 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA29818 for ; Fri, 13 Jul 2001 04:25:45 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6D7nHL03759 for ietf-ipsra-bks; Fri, 13 Jul 2001 00:49:17 -0700 (PDT) Received: from mta1-3.us4.outblaze.com (205-158-62-44.outblaze.com [205.158.62.44]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6D7nGq03755 for ; Fri, 13 Jul 2001 00:49:16 -0700 (PDT) Received: (qmail 5274 invoked from network); 13 Jul 2001 07:35:48 -0000 Received: from unknown (HELO mta1-1.us4.outblaze.com) (205.158.62.45) by 205-158-62-44.outblaze.com with SMTP; 13 Jul 2001 07:35:48 -0000 Received: (qmail 27860 invoked by uid 0); 13 Jul 2001 07:35:44 -0000 MBOX-Line: From owner-ietf-ipsra@mail.vpnc.org Mon Jul 09 10:03:56 2001 Received: (qmail 31899 invoked from network); 9 Jul 2001 08:52:55 -0000 Received: from unknown (HELO spf5.us4.outblaze.com) (205.158.62.27) by 205-158-62-45.outblaze.com with SMTP; 9 Jul 2001 08:52:55 -0000 Received: from above.proper.com (above.proper.com [208.184.76.39]) by spf5.us4.outblaze.com (8.11.0/8.11.0) with ESMTP id f698qmp08216; Mon, 9 Jul 2001 08:52:48 GMT Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f698GIC06271 for ietf-ipsra-bks; Mon, 9 Jul 2001 01:16:18 -0700 (PDT) Received: from ns02.newbridge.com (ns02.newbridge.com [192.75.23.75]) by above.proper.com (8.11.3/8.11.3) with SMTP id f698GHm06267 for ; Mon, 9 Jul 2001 01:16:17 -0700 (PDT) Received: (qmail 5783 invoked from network); 9 Jul 2001 08:14:13 -0000 Received: from portal1.newbridge.com (HELO kanata-mh1.ca.newbridge.com) (192.75.23.76) by ns02.newbridge.com with SMTP; 9 Jul 2001 08:14:13 -0000 Received: from kanmail02.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for ietf-ipsra@vpnc.org; Mon, 9 Jul 2001 04:14:47 -0400 Received: from andrewk3 ([138.120.49.159]) by kanmail02.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAAC79; Mon, 9 Jul 2001 04:14:45 -0400 Reply-To: From: "Andrew Krywaniuk" To: "'Scott G. Kelly'" Cc: Subject: RE: evaluation draft Date: Mon, 9 Jul 2001 04:04:09 -0400 Message-Id: <000d01c1084e$56483a90$1e72788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 In-Reply-To: <3B492E38.49D8B48B@redcreek.com> Importance: Normal List-Archive: List-ID: List-Unsubscribe: Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > First, I'll remove the known plaintext discussion from the draft, for > the following reasons: > > - I have commented both in the draft and in emails that it is a very > minor issue > - it is clearly a lightning rod which is detracting from more > substantive issues > - if xauth (hybrid) were to become a serious contender in ipsra, it > could be easily remedied at that time I would rather you removed it for the reason that the problem is not a problem. > > I personally consider DoS protection to be a very important > feature of an > > encryption protocol. However, I have noticed that DoS > vulnerability tends to > > be trivialized during actual protocol design, but it is > routinely trotted > > out whenever someone scrapes the bottom of the evidence barrel. > > In case you haven't noticed, I am not trivializing it during *this* > actual protocol design, but apparently you are. > > Regarding the various vulnerabilities in IKE, perhaps some of them > could be improved upon during the son of IKE work. However, son of IKE > won't be able to undo whatever we do here, so we had better > mind our own > shop in the meantime. Any of the possible amendments to IKE to deal with DoS, from base mode to client puzzles to stateless cookies, would have a direct impact on the IPSRA solution. If you fix the problem at the root, it will not exist at the branches. > > You > consistently > > repeat the opinion that Hybrid has "serious security > issues" yet you are > > unwilling to make any clear statement of what these issues > are. The few > > points you do bring up are easily refuted. > > Again, read the draft - it makes very clear statements about what the > issues are. Here is what it says in the draft: This mechanism is trivially susceptible to DoS attacks, as it requires the IRAS to engage in an unauthenticated Diffie-Hellman exchange which includes an expensive public key operation, a) I explained in the last e-mail how plain old IKE has the exact same vulnerability. and then to continue the conversation for some period of time beyond that, perhaps in error. b) This is not a serious vulnerability, and it is common to all such protocols. If you move the user authentication to a dedicated server then yes, this DoS attack is moved to the IRAS. I explain in (d) why that is not significant. In addition, all of the specific xauth shortcomings not relating specifically to preshared keys apply equally to hybrid. Copied from draft: Specific xauth issues (in addition to the general issues discussed above) include the following: o Xauth requires the SGW to participate in the user authentication process, which increases SGW vulnerability both in terms of complexity c) Arguments which state that X is complex are easy to make and impossible to disprove. and denial of service. d) If you discount the fact that moving the user authentication to a dedicated IRAS requires the purchase of new hardware... and this money could have alternately been spent on a load-sharing second gateway, which would have helped handle the DoS. o Adding an open-ended number of challenge-rsp exchanges to a key exchange increases vulnerability to denial of service attack under some circumstances, and absolutely increases the complexity of the key exchange mechanism under all circumstances. While an open-ended exchange may not be entirely avoidable given the n-factor authentication requirement, xauth does not begin such exchanges until a phase 1 IKE SA has been instantiated, and this with either limited or no knowledge of the user identity in several of the supported configurations. The overhead associated with the DH exchange is significant, and the fact that an anonymous peer may force expenditure of this effort implies that a system supporting the associated configuration is trivially susceptible to denial of service. Further, once such phase 1 sessions are established, the SGW may be "led on" by a malicious peer for some (hopefully limited) period of time, guaranteeing that the associated system resources will remain unavailable during this period. e) see all of a, b, c, and d. o Xauth requires proxy support in the SGW for up to 16 different authentication methods, which greatly increases system complexity. f) the key phrase here is "up to" o There may be some known ascii plaintext at fixed locations within packets due to support for user prompts. The amount of text will normally be small, but should not be ignored. g) Both IKE and ESP have significant amounts of known plaintext (think tunneled IP header). This is an assumption in the protocol design, as I explained yesterday. If a reusable passphrase is contained within the xauth exchange, an attacker may have significant motivation for breaking the IKE session encryption, h) the draft states that CHAP is preferable to PAP in general. and known plaintext will simplify this task. i) Try rekeying more often. Last I heard, known plaintext attacks required 2^(big number) of code blocks. o Xauth requires support for its companion, modecfg. This duplicates some of the functionality of DHCP, but lacks support for critical components, implying that it is redundant, and therefore adds unnecessary complexity. However, one has no choice but to implement modecfg if one wishes to implement xauth. j) XAuth only uses a small part of the modecfg draft. It is not "tightly bound" as you have stated previously. It would be easy to move that part out into a separate draft, as I in fact did in the Attribute Exchange draft. None of these are new arguments. I have pointed out all of the above many times over the course of the last 2 years. > If you can present a persuasive, > non-emotional argument as to why xauth or hybrid or xxx is a better > solution than the other proposals, please do so immediately. We have > already wasted far too much time here, and we need to get our > work done. I'm not trying to convince you that xauth or hybrid is a better solution than GetCert/PIC. I am merely asking that you stop publicly making incorrect claims about vulnerabilities in these protocols so I can stop having to refute them. You go ahead and write your little drafts about whatever you want, and as long as you stop writing about non-existant security flaws in other people's protocols, I won't give you any trouble. Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. From owner-ietf-ipsra@mail.vpnc.org Fri Jul 13 04:31:03 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA00436 for ; Fri, 13 Jul 2001 04:31:03 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6D7uQX04724 for ietf-ipsra-bks; Fri, 13 Jul 2001 00:56:26 -0700 (PDT) Received: from mta1-3.us4.outblaze.com (205-158-62-44.outblaze.com [205.158.62.44]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6D7uOq04720 for ; Fri, 13 Jul 2001 00:56:24 -0700 (PDT) Received: (qmail 15324 invoked from network); 13 Jul 2001 07:41:58 -0000 Received: from unknown (HELO mta1-1.us4.outblaze.com) (205.158.62.45) by 205-158-62-44.outblaze.com with SMTP; 13 Jul 2001 07:41:58 -0000 Received: (qmail 4337 invoked by uid 0); 13 Jul 2001 07:39:55 -0000 MBOX-Line: From owner-ietf-ipsra@mail.vpnc.org Tue Jul 10 23:00:39 2001 Received: (qmail 20045 invoked from network); 10 Jul 2001 15:03:58 -0000 Received: from unknown (HELO spf11.us4.outblaze.com) (205.158.62.43) by 205-158-62-45.outblaze.com with SMTP; 10 Jul 2001 15:03:58 -0000 Received: from spf3.us4.outblaze.com (205-158-62-25.outblaze.com [205.158.62.25]) by spf11.us4.outblaze.com (8.11.0/8.11.0) with ESMTP id f6AF3vE23042 for ; Tue, 10 Jul 2001 15:03:57 GMT Received: from above.proper.com (above.proper.com [208.184.76.39]) by spf3.us4.outblaze.com (8.11.0/8.11.0) with ESMTP id f6AF3uh17294; Tue, 10 Jul 2001 15:03:56 GMT Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6AEFLJ12467 for ietf-ipsra-bks; Tue, 10 Jul 2001 07:15:21 -0700 (PDT) Received: from perfero.tnc.virtela.cc ([12.41.66.116]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6AEFJm12463 for ; Tue, 10 Jul 2001 07:15:20 -0700 (PDT) Received: from posthaus.virtela.cc ([172.16.97.7]) by perfero.tnc.virtela.cc (8.9.3/8.9.3) with ESMTP id HAA06011 for ; Tue, 10 Jul 2001 07:15:15 -0700 Received: by posthaus.virtela.cc with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Jul 2001 08:15:15 -0600 Message-ID: From: "Horn, Mike" To: "'ietf-ipsra@vpnc.org'" Cc: "Horn, Mike" Subject: Requirements Draft Date: Tue, 10 Jul 2001 08:15:15 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" List-Archive: List-ID: List-Unsubscribe: Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sorry if this is a duplicate, there might have been an issue on my first post of this to the list. Thanks. I have been exchanging several private emails with Scott Kelly about the current requirements draft. There are a few issues which are referenced briefly in the draft, but are not explicitly stated as requirements. Most of these issues are contentious, but I think the VPN user community has already established these as requirements by developing proprietary solutions for most, if not all of these issues. Issues: 1) The IRAS and IRAC SHOULD support NAT traversal. 2) The IRAC SHOULD support redundant gateways. 3) The IRAS and IRAC SHOULD support a keepalive or make dead mechanism. 4) The IRAS SHOULD support auditing of the assigned VIP, public IP, and username in addition to the start and end time. 5) The IRAS and IRAC MAY support load balancing. I understand these issues might fall into a gray area between the IPSRA and IPSEC working groups, but these are true needs of the user community and should be addressed. I think the requirements draft is the right place to capture user requirements, it shouldn't mandate the solutions for how these requirements are met, but it should clearly define the needs of the user community. Mike Horn From owner-ietf-ipsra@mail.vpnc.org Fri Jul 13 04:31:59 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA00547 for ; Fri, 13 Jul 2001 04:31:59 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f6D7xcA04778 for ietf-ipsra-bks; Fri, 13 Jul 2001 00:59:38 -0700 (PDT) Received: from mta1-3.us4.outblaze.com (205-158-62-44.outblaze.com [205.158.62.44]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6D7xbq04774 for ; Fri, 13 Jul 2001 00:59:37 -0700 (PDT) Received: (qmail 17878 invoked from network); 13 Jul 2001 07:43:17 -0000 Received: from unknown (HELO mta1-1.us4.outblaze.com) (205.158.62.45) by 205-158-62-44.outblaze.com with SMTP; 13 Jul 2001 07:43:17 -0000 Received: (qmail 6558 invoked by uid 0); 13 Jul 2001 07:41:06 -0000 MBOX-Line: From owner-ietf-ipsra@mail.vpnc.org Wed Jul 11 11:52:37 2001 Received: (qmail 4813 invoked from network); 11 Jul 2001 11:12:13 -0000 Received: from unknown (HELO spf11.us4.outblaze.com) (205.158.62.43) by 205-158-62-45.outblaze.com with SMTP; 11 Jul 2001 11:12:13 -0000 Received: from spf5.us4.outblaze.com (205-158-62-27.outblaze.com [205.158.62.27]) by spf11.us4.outblaze.com (8.11.0/8.11.0) with ESMTP id f6BBCD209480 for ; Wed, 11 Jul 2001 11:12:13 GMT Received: from above.proper.com (above.proper.com [208.184.76.39]) by spf5.us4.outblaze.com (8.11.0/8.11.0) with ESMTP id f6BBCBG07759; Wed, 11 Jul 2001 11:12:11 GMT Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6BAF2k13364 for ietf-ipsra-bks; Wed, 11 Jul 2001 03:15:02 -0700 (PDT) Received: from ee.technion.ac.il (ee.technion.ac.il [132.68.48.5]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6BAF0m13358; Wed, 11 Jul 2001 03:15:00 -0700 (PDT) Received: from localhost (hugo@localhost) by ee.technion.ac.il (8.9.3+Sun/8.9.3) with ESMTP id NAA12532; Wed, 11 Jul 2001 13:15:10 +0300 (IDT) Date: Wed, 11 Jul 2001 13:15:10 +0300 (IDT) From: Hugo Krawczyk To: Paul Hoffman / VPNC cc: ietf-ipsra Subject: Re: evaluation draft In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Archive: List-ID: List-Unsubscribe: Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 10 Jul 2001, Paul Hoffman / VPNC wrote: > > At 8:56 PM +0300 7/10/01, Hugo Krawczyk wrote: > >Personally, I have no problem with those that want to change the charter > >(I wouldn't be against, except that convergence in this case seems > >impossible). > > Any discussion of the charter is out of scope. Therefore any evaluation of, and comparison with, solutions that do not comply with the charter should be out of scope too. Under the current state of affairs such discussion is noise. A constructive subject of discussion is how to maximize the benefits, functionality, simplicity, and security of PIC given the "charter's axioms" Hugo > > Scott pointed out in an earlier message that we are all intelligent > adults. Why, then, do many of us keep forgetting what has happened in > the recent past? We have been told repeatedly that the protocol that > comes from the WG may not change IKE. Many of us have replied "but we > think that a change to IKE is a better solution". The response from > the Area Directors has been unequivocal: no changing IKE, no changing > the charter. > > --Paul Hoffman, Director > --VPN Consortium > From owner-ietf-ipsra@mail.vpnc.org Fri Jul 13 04:34:16 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA00822 for ; Fri, 13 Jul 2001 04:34:15 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6D7xpt04791 for ietf-ipsra-bks; Fri, 13 Jul 2001 00:59:51 -0700 (PDT) Received: from mta1-3.us4.outblaze.com (205-158-62-44.outblaze.com [205.158.62.44]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6D7xoq04787 for ; Fri, 13 Jul 2001 00:59:50 -0700 (PDT) Received: (qmail 19162 invoked from network); 13 Jul 2001 07:44:14 -0000 Received: from unknown (HELO mta1-1.us4.outblaze.com) (205.158.62.45) by 205-158-62-44.outblaze.com with SMTP; 13 Jul 2001 07:44:14 -0000 Received: (qmail 7628 invoked by uid 0); 13 Jul 2001 07:41:36 -0000 MBOX-Line: From owner-ietf-ipsra@mail.vpnc.org Wed Jul 11 16:14:20 2001 Received: (qmail 3921 invoked from network); 11 Jul 2001 15:23:30 -0000 Received: from unknown (HELO spf11.us4.outblaze.com) (205.158.62.43) by 205-158-62-45.outblaze.com with SMTP; 11 Jul 2001 15:23:30 -0000 Received: from spf9.us4.outblaze.com (205-158-62-42.outblaze.com [205.158.62.42]) by spf11.us4.outblaze.com (8.11.0/8.11.0) with ESMTP id f6BFNU213878 for ; Wed, 11 Jul 2001 15:23:30 GMT Received: from above.proper.com (above.proper.com [208.184.76.39]) by spf9.us4.outblaze.com (8.11.0/8.11.0) with ESMTP id f6BFNSB14131; Wed, 11 Jul 2001 15:23:28 GMT Received: by above.proper.com (8.11.3/8.11.3) id f6BEkOX20095 for ietf-ipsra-bks; Wed, 11 Jul 2001 07:46:24 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6BEkOm20091 for ; Wed, 11 Jul 2001 07:46:24 -0700 (PDT) Received: from toque.cisco.com (toque.cisco.com [161.44.208.153]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f6BEiY516850 for ; Wed, 11 Jul 2001 07:44:34 -0700 (PDT) Received: from DDUKESW2K (ott-b1-dhcp-10-85-28-157.cisco.com [10.85.28.157]) by toque.cisco.com (Mirapoint) with SMTP id ABK07097; Wed, 11 Jul 2001 10:46:06 -0400 (EDT) Message-ID: <006a01c10a18$4e29a710$9d1c550a@cisco.com> Reply-To: "Darren Dukes" From: "Darren Dukes" To: "ietf-ipsra" References: Subject: PIC is IKE (was Re: evaluation draft)` Date: Wed, 11 Jul 2001 10:46:44 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 List-Archive: List-ID: List-Unsubscribe: Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit A PIC SA is an IKE SA, like it or not. PIC, as a authentication system, is even more complex than those 'out of scope' proposals that use an IKE SA since you now must provision and configure multiple services. If you simplify the overall authentication system you could put PIC on the SGW, now you've doubled your supported code for IKE-like exchanges. That's going to be hard to support so why not have PIC and IKE share most of their code. Now PIC is on the same box as IKE, using the same UDP port number, and better yet IKE and PIC are interdependent since they're sharing much of the same code. Why not just use IKE and simplify the code more? I don't know. Other opinions are encouraged. Darren ----- Original Message ----- From: "Hugo Krawczyk" To: "Paul Hoffman / VPNC" Cc: "ietf-ipsra" Sent: Wednesday, July 11, 2001 6:15 AM Subject: Re: evaluation draft > > > > On Tue, 10 Jul 2001, Paul Hoffman / VPNC wrote: > > > > > At 8:56 PM +0300 7/10/01, Hugo Krawczyk wrote: > > >Personally, I have no problem with those that want to change the charter > > >(I wouldn't be against, except that convergence in this case seems > > >impossible). > > > > Any discussion of the charter is out of scope. > > Therefore any evaluation of, and comparison with, solutions that do not > comply with the charter should be out of scope too. Under the current > state of affairs such discussion is noise. A constructive subject of > discussion is how to maximize the benefits, functionality, simplicity, and > security of PIC given the "charter's axioms" > > Hugo > > > > > Scott pointed out in an earlier message that we are all intelligent > > adults. Why, then, do many of us keep forgetting what has happened in > > the recent past? We have been told repeatedly that the protocol that > > comes from the WG may not change IKE. Many of us have replied "but we > > think that a change to IKE is a better solution". The response from > > the Area Directors has been unequivocal: no changing IKE, no changing > > the charter. > > > > --Paul Hoffman, Director > > --VPN Consortium > > > From owner-ietf-ipsra@mail.vpnc.org Fri Jul 13 04:45:52 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02116 for ; Fri, 13 Jul 2001 04:45:51 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6D85QM06037 for ietf-ipsra-bks; Fri, 13 Jul 2001 01:05:26 -0700 (PDT) Received: from mta1-3.us4.outblaze.com (205-158-62-44.outblaze.com [205.158.62.44]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6D85Pq06029 for ; Fri, 13 Jul 2001 01:05:25 -0700 (PDT) Received: (qmail 24324 invoked from network); 13 Jul 2001 07:46:38 -0000 Received: from unknown (HELO mta1-1.us4.outblaze.com) (205.158.62.45) by 205-158-62-44.outblaze.com with SMTP; 13 Jul 2001 07:46:38 -0000 Received: (qmail 13940 invoked by uid 0); 13 Jul 2001 07:44:12 -0000 MBOX-Line: From owner-ietf-ipsra@mail.vpnc.org Thu Jul 12 09:55:35 2001 Received: (qmail 28334 invoked from network); 12 Jul 2001 06:00:41 -0000 Received: from unknown (HELO spf11.us4.outblaze.com) (205.158.62.43) by 205-158-62-45.outblaze.com with SMTP; 12 Jul 2001 06:00:41 -0000 Received: from spf1.us4.outblaze.com (205-158-62-23.outblaze.com [205.158.62.23]) by spf11.us4.outblaze.com (8.11.0/8.11.0) with ESMTP id f6C60U229651 for ; Thu, 12 Jul 2001 06:00:30 GMT Received: from above.proper.com (above.proper.com [208.184.76.39]) by spf1.us4.outblaze.com (8.11.0/8.11.0) with ESMTP id f6C60SZ10317; Thu, 12 Jul 2001 06:00:28 GMT Received: by above.proper.com (8.11.3/8.11.3) id f6C5MCk18077 for ietf-ipsra-bks; Wed, 11 Jul 2001 22:22:12 -0700 (PDT) Received: from internaut.com ([64.38.134.99]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6C5MAm18070; Wed, 11 Jul 2001 22:22:10 -0700 (PDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id WAA49661; Wed, 11 Jul 2001 22:14:17 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Wed, 11 Jul 2001 22:14:17 -0700 (PDT) From: Bernard Aboba To: Hugo Krawczyk cc: Paul Hoffman / VPNC , ietf-ipsra Subject: Re: evaluation draft In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Archive: List-ID: List-Unsubscribe: Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > A constructive subject of > discussion is how to maximize the benefits, functionality, simplicity, and > security of PIC given the "charter's axioms" > Well, for us to achieve this, I think we need to have a requirements document which helps us decide whether we are getting closer or further to our end goal. Otherwise, it's hard to know when we're done. A lot of what we have been talking about in this email thread is the way in which we measure the quality of a solution. In looking at the requirements document, I'm not at all clear that it gives us the kind of guidance that we need for the current set of problems we are addressing. For example, the requirements document does not address: 1. Requirements for integration with existing or developing certificate management protocols. In fact, it doesn't talk about certificate management issues at all, even though that is now the central activity of this WG. 2. Requirements for implementability, expressed in terms of concrete metrics. For example, some people have argued that code size (a proxy for complexity) is very important. Others think that separation of functions is valuable. Until we have a clear idea of what makes a solution more or less secure, or more or less implementable, it's hard to figure out how to improve it. In general, I think that one of the worst aspects of the dictates that we have been under is that, by closing off discussion, they have prevented us from understanding what the valid metrics are for measuring success. The dictates, by being invariant, either constitute universal truths, in which case we must achieve a deep understanding of them and incorporate them into the requirements, or they they represent a knee jerk response to a complex problem, in which case they should be discarded. Unless we're allowed to discuss and understand them, it's hard to tell which of these alternatives is closer to the truth. From owner-ietf-ipsra@mail.vpnc.org Fri Jul 13 15:07:18 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24601 for ; Fri, 13 Jul 2001 15:07:18 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6DI3Dm00320 for ietf-ipsra-bks; Fri, 13 Jul 2001 11:03:13 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6DI3Bq00315 for ; Fri, 13 Jul 2001 11:03:12 -0700 (PDT) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA09580; Fri, 13 Jul 2001 11:03:08 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA25679; Fri, 13 Jul 2001 14:03:07 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f6DI2Yx05809; Fri, 13 Jul 2001 14:02:34 -0400 (EDT) Message-Id: <200107131802.f6DI2Yx05809@thunk.east.sun.com> From: Bill Sommerfeld To: "Darren Dukes" cc: "ietf-ipsra" Subject: Re: PIC is IKE (was Re: evaluation draft)` In-reply-to: Your message of "Wed, 11 Jul 2001 10:46:44 EDT." <006a01c10a18$4e29a710$9d1c550a@cisco.com> Reply-to: sommerfeld@east.sun.com Date: Fri, 13 Jul 2001 14:02:33 -0400 Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I'm sure that folks will figure out ways for IKE and PIC implementations to share code without needing to share a port number. I'd like the freedom to deliver a PIC implementation as a separate daemon; giving it a different port is the easiest way to do that. having one daemon listen on two ports is much easier than having two daemons try to share the same port. Picking off IPsec-over-UDP-over-NAT traffic sent to port 500 is a much simpler problem; I don't see it as relevant to this question. - Bill From owner-ietf-ipsra@mail.vpnc.org Fri Jul 13 15:52:38 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00552 for ; Fri, 13 Jul 2001 15:52:37 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6DIt6Q01195 for ietf-ipsra-bks; Fri, 13 Jul 2001 11:55:06 -0700 (PDT) Received: from spsystems.net (spsystems.net [209.47.149.227]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6DIt4q01191 for ; Fri, 13 Jul 2001 11:55:04 -0700 (PDT) Received: (from henry@localhost) by spsystems.net (8.9.3/8.9.3) id OAA12917; Fri, 13 Jul 2001 14:54:27 -0400 (EDT) Date: Fri, 13 Jul 2001 14:54:27 -0400 (EDT) From: Henry Spencer To: ietf-ipsra Subject: Re: PIC is IKE (was Re: evaluation draft)` In-Reply-To: <200107131802.f6DI2Yx05809@thunk.east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 13 Jul 2001, Bill Sommerfeld wrote: > I'm sure that folks will figure out ways for IKE and PIC > implementations to share code without needing to share a port number. > > I'd like the freedom to deliver a PIC implementation as a separate > daemon; giving it a different port is the easiest way to do that. > > having one daemon listen on two ports is much easier than having two > daemons try to share the same port. Agreed, all three times. A separate port is strongly preferable. Henry Spencer henry@spsystems.net From owner-ietf-ipsra@mail.vpnc.org Fri Jul 13 18:55:58 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24356 for ; Fri, 13 Jul 2001 18:55:58 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6DMF1P05238 for ietf-ipsra-bks; Fri, 13 Jul 2001 15:15:01 -0700 (PDT) Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6DMF0q05233 for ; Fri, 13 Jul 2001 15:15:00 -0700 (PDT) Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.vpnc.org [208.184.76.50]) with SMTP; 13 Jul 2001 22:13:31 UT Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA08478; Fri, 13 Jul 2001 09:11:08 -0400 (EDT) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Jul 2001 09:11:05 -0400 Message-ID: From: "Kavsan, Bronislav" To: "'Scott G. Kelly'" , ipsra list Subject: RE: continuing the discussion on complexity (long post) Date: Fri, 13 Jul 2001 09:10:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: My comments: - IKE/IPSec doesn't have a monopoly on the need for authentication - legacy or otherwise. - Therefore complexity of this problem is better solved by sharing this burden amongst applications and technologies that are consumers of the solution and will share its benefits. - PKI-based authentication is a very good unifying authentication instrument, but it is complex - effort targeted on reducing PKI complexity will benefit us more than localized efforts targeted on reducing IKE authentication complexity - "Virtual smart cards" carrying PKI credentials can be issued and accessed using legacy authentication methods, sort of legacy->PKI bootstrapping, which in turn can be used by IKE/IPSec, SSL, DigSig, Authorization, Messaging, etc, etc... Assuming above premise - separate IETF body should address this topic on behalf of this and other WGs. Slava -----Original Message----- From: Scott G. Kelly [mailto:skelly@redcreek.com] Sent: Thursday, July 12, 2001 1:08 PM To: ipsra list Subject: continuing the discussion on complexity (long post) This is to continue the discussion of complexity as it relates to the legacy authentication problem and security. Think of it as me thinking out loud. I'd say "feel free to disagree, criticize, etc.", but I don't think anyone will be shy about that... Clearly, anything we do is going to add complexity to the overall system of remote user and whatever systems he must interact with (IRAS, AS, CA, or whatever). As Hugo pointed out in an earlier post to the ipsec list, nothing is free, and added security typically means added complexity (as does added functionality). I don't think anyone would disagree that as code becomes more complex, it becomes more difficult to assert that it does exactly (and only) what it is intended to do. On the other hand, we want our systems to deliver more and more functionality, so we typically choose to accept some risk in exchange. Normally, the additional incurred risk is mitigated through conscientious and well-thought-out testing, but no matter how careful we are, we cannot typically be certain that we've thought of everything. Obviously, the level of effort we devote to careful design and testing is proportional to the value the subject system (or program) provides, and to the risk we face in case of malfunction. If an error is likely to carry a high price tag, we tend to be much more careful in our approach, and rightly so. In such cases, we have to balance the desire for added functionality against the cost of system failure. In cases where the cost of failure is relatively low, we may choose not to concern ourselves with this. In cases where the cost might be very high, we often look for ways to improve the likelihood that failure will not occur. Perhaps the most obvious way to reduce risk is to simplify the system in every way possible. The simpler the system, the more likely it is that we may accurately characterize and understand it. However, in some cases this may lead to unacceptable functional loss, and in such cases we must either give up entirely, or add the functionality anyway, and attempt to derive a test plan which gives us a relatively high level of confidence in the stability and resilience of the subject system. Numerous considerations must be weighed against the desire to reduce complexity. An IPsec security gateway is a very complex system. To some extent, this is unavoidable, as the underlying functionality requirements demand it. For many security gateways, the cost of some types of failure could be extremely high. In order to limit exposure, the designer of such a system has two options: simplify wherever possible, and test as thoroughly as practicable. Unfortunately, IETF standards do not prescribe test procedures, nor should they. This might lead one to ask whether it might not be most appropriate to be conservative with respect to complexity when producing an IETF standard for a security system. It should also be noted that security requirements vary by circumstance. In some cases, it is imperative that communications integrity be as nearly absolute as may be obtained. In other cases, where the cost of integrity loss is lower, it is not as important. In between, there is something of a continuum along which other deployments may be placed according to circumstance. When there is a desire to create a product anywhere along this continuum, there is a tendency to select the least costly mechanism which suffices. When creating networking products, there is a simultaneous desire to standardize the solution. Clearly, we cannot standardize individual solutions to meet the needs of every discrete situation along the security spectrum. The more reasonable solution is to select a manageable subset, and let folks choose the closest fit. In terms of both of getting the work done and of making the number of choices reasonable from a security perspective, less choices are better, as the alternative is to place additional deployment complexity squarely in front of the user, and hope that they make the right choice. It should be noted that a solution which satisfies the most stringent security requirements will meet the security requirements of all, and that such a solution is required if we are to meet the needs of the high end of the spectrum. On the other hand, this solution may prove too costly for those with lesser security requirements. For some of these cases, we already have at least one standards track alternative: L2TP in IPsec. So, we need a very strong mechanism, and we have a middle-of-the-road mechanism. Do we need more than this? Maybe not - but this question must be definitively answered. ---------------------------- As regards our problem, IKE provides no support for username/passphrase authentication, but the market clearly requires this support if IPsec is to be used for remote access. It has been argued that IKE is too complex already, and that if possible, a solution which requires no changes to IKE should be found. What is the basis of this argument? IKE, due in part to the general design of ISAKMP, supports a large number of options in various combinations. The preceding complexity discussion illustrates why this entails more risk from a security perspective than a simpler more limited key exchange protocol implementation might. It is very difficult to guage the effect of interactions between the code implementing various options in varying combinations, and put simply, it requires lots more code, implying the likelihood of more undetected bugs. Bugs in security gateway code could result in system compromise. Adding functionality to this code base simply serves to increase this risk. This has prompted the call for proposals for independent solutions which do not modify IKE. The point has been made that PIC/GetCert + enrollment is more complex than hybrid (or whatever). In a global system sense this is certainly true. However, it is not true with respect to the security gateway if the AS is a standalone system. That is, this particular approach may be implemented without changing the underlying IPsec implementation. This means that the code running on the security gateway is less complex than it would be otherwise, and that from this we gain some relative assurance that we have not introduced new problems into the gateway code. This may or may not be an important consideration, depending upon the exposure in case of gateway failure. Now, is the gateway actually more secure with an outboard AS implementation than it would be with simpler changes to IKE? Well... we don't know for sure. What we may believe is that it *probably* is, or that it might be. On the other hand, if we implement the same solution on the gateway rather than on a standalone AS, we have certainly increased the code complexity on the gateway. Hence, by the same reasoning we must conclude that the security of the gateway may be reduced due to this added complexity, especially when compared with a similar system implementing a simpler mechanism. Additionally, with the choice of PIC or GetCert, the remote access client code will be more complex than it could be with some other approach. In order to isolate the legacy user authentication operation from IKE, it is necessary for this operation to produce a credential of some sort which may be used in subsequent IKE communications. This credential may be either a public key certificate, or a shared secret. The client must interact with the AS in order to obtain this, and then make it available to the IPsec subsystem. If we choose a shared secret, this must be distributed to both the remote client and the gateway upon successful user authentication. Even if a standalone AS is employed, this still increases code complexity on the gateway. If failover and/or load balancing support is provided, the secret must be provided to all participating gateways prior to providing it to the client, and this significantly increases gateway code complexity regardless of where the AS is implemented. If we choose the certificate, no interaction is needed with participating gateways, though the gateway(s) must have a mechanism for verifying the certificate. If the client certificates are sufficiently short-lived, gateway possession of a valid verification certificate may be sufficient in this regard. Otherwise, CRL or online status checking is required. However, these functionalities are required for site-to-site gateways as well. If the AS is implemented in the gateway, either an outboard CA function is required, or all associated failover/load-balancing gateways must share the signing key. It seems clear that if we allow the AS to co-reside on the gateway, the code complexity is significantly higher than with other IKE-based techniques which do not provide a reusable credential (due to the certificate generation functionality). Hence, from a security perspective, there is some likelihood that we are better off to use an outboard AS for this particular solution type. On the other hand, this adds overall solution complexity for system as a whole, and for the user. It may increase gateway security, but it costs more. There may also be a question as to whether this added complexity serves to decrease the overall remote access system security. If we choose one of the other proposed IKE-based solutions, what do we gain (or lose)? Eliminating the need for a CA component reduces cost and system complexity, but also eliminates the single sign-on capability a short-lived certificate would provide. Additionally, it may provide less market incentive to move to stronger user authentication mechanisms. On the other hand, when compared to a gateway AS implementation, the alternative mechanisms likely result in significantly less complex gateway code than the AS, but there would still be a net complexity increase. It seems that no matter which solution we choose, we must accept some increased complexity in exchange for the added functionality. Also, the two proposed solution classes offer different features, and the need for these features must be weighed against the security requirements and the desire to reduce complexity. If single sign-on and PKI migration are important goals, these will drive the solution in one direction. If not, there is far less justification for the AS approach. ------------------- Scott From owner-ietf-ipsra@mail.vpnc.org Fri Jul 13 21:44:22 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA15247 for ; Fri, 13 Jul 2001 21:44:21 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6E165f08435 for ietf-ipsra-bks; Fri, 13 Jul 2001 18:06:05 -0700 (PDT) Received: from mta1-3.us4.outblaze.com (205-158-62-44.outblaze.com [205.158.62.44]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6E164q08431 for ; Fri, 13 Jul 2001 18:06:04 -0700 (PDT) Received: (qmail 11418 invoked from network); 14 Jul 2001 01:03:32 -0000 Received: from unknown (HELO mta1-1.us4.outblaze.com) (205.158.62.45) by 205-158-62-44.outblaze.com with SMTP; 14 Jul 2001 01:03:32 -0000 Received: (qmail 27250 invoked by uid 0); 14 Jul 2001 01:02:26 -0000 MBOX-Line: From owner-ietf-ipsra@mail.vpnc.org Fri Jul 13 10:28:47 2001 Received: (qmail 17111 invoked from network); 13 Jul 2001 08:32:45 -0000 Received: from unknown (HELO spf11.us4.outblaze.com) (205.158.62.43) by 205-158-62-45.outblaze.com with SMTP; 13 Jul 2001 08:32:45 -0000 Received: from spf5.us4.outblaze.com (205-158-62-27.outblaze.com [205.158.62.27]) by spf11.us4.outblaze.com (8.11.0/8.11.0) with ESMTP id f6D8Wb223226 for ; Fri, 13 Jul 2001 08:32:37 GMT Received: from above.proper.com (above.proper.com [208.184.76.39]) by spf5.us4.outblaze.com (8.11.0/8.11.0) with ESMTP id f6D8WZG05266; Fri, 13 Jul 2001 08:32:35 GMT Received: by above.proper.com (8.11.3/8.11.3) id f6D7xcA04778 for ietf-ipsra-bks; Fri, 13 Jul 2001 00:59:38 -0700 (PDT) Received: from mta1-3.us4.outblaze.com (205-158-62-44.outblaze.com [205.158.62.44]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6D7xbq04774 for ; Fri, 13 Jul 2001 00:59:37 -0700 (PDT) Received: (qmail 17878 invoked from network); 13 Jul 2001 07:43:17 -0000 Received: from unknown (HELO mta1-1.us4.outblaze.com) (205.158.62.45) by 205-158-62-44.outblaze.com with SMTP; 13 Jul 2001 07:43:17 -0000 Received: (qmail 6558 invoked by uid 0); 13 Jul 2001 07:41:06 -0000 MBOX-Line: From owner-ietf-ipsra@mail.vpnc.org Wed Jul 11 11:52:37 2001 Received: (qmail 4813 invoked from network); 11 Jul 2001 11:12:13 -0000 Received: from unknown (HELO spf11.us4.outblaze.com) (205.158.62.43) by 205-158-62-45.outblaze.com with SMTP; 11 Jul 2001 11:12:13 -0000 Received: from spf5.us4.outblaze.com (205-158-62-27.outblaze.com [205.158.62.27]) by spf11.us4.outblaze.com (8.11.0/8.11.0) with ESMTP id f6BBCD209480 for ; Wed, 11 Jul 2001 11:12:13 GMT Received: from above.proper.com (above.proper.com [208.184.76.39]) by spf5.us4.outblaze.com (8.11.0/8.11.0) with ESMTP id f6BBCBG07759; Wed, 11 Jul 2001 11:12:11 GMT Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6BAF2k13364 for ietf-ipsra-bks; Wed, 11 Jul 2001 03:15:02 -0700 (PDT) Received: from ee.technion.ac.il (ee.technion.ac.il [132.68.48.5]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6BAF0m13358; Wed, 11 Jul 2001 03:15:00 -0700 (PDT) Received: from localhost (hugo@localhost) by ee.technion.ac.il (8.9.3+Sun/8.9.3) with ESMTP id NAA12532; Wed, 11 Jul 2001 13:15:10 +0300 (IDT) Date: Wed, 11 Jul 2001 13:15:10 +0300 (IDT) From: Hugo Krawczyk To: Paul Hoffman / VPNC cc: ietf-ipsra Subject: Re: evaluation draft In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Archive: List-ID: List-Unsubscribe: List-Archive: List-ID: List-Unsubscribe: Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 10 Jul 2001, Paul Hoffman / VPNC wrote: > > At 8:56 PM +0300 7/10/01, Hugo Krawczyk wrote: > >Personally, I have no problem with those that want to change the charter > >(I wouldn't be against, except that convergence in this case seems > >impossible). > > Any discussion of the charter is out of scope. Therefore any evaluation of, and comparison with, solutions that do not comply with the charter should be out of scope too. Under the current state of affairs such discussion is noise. A constructive subject of discussion is how to maximize the benefits, functionality, simplicity, and security of PIC given the "charter's axioms" Hugo > > Scott pointed out in an earlier message that we are all intelligent > adults. Why, then, do many of us keep forgetting what has happened in > the recent past? We have been told repeatedly that the protocol that > comes from the WG may not change IKE. Many of us have replied "but we > think that a change to IKE is a better solution". The response from > the Area Directors has been unequivocal: no changing IKE, no changing > the charter. > > --Paul Hoffman, Director > --VPN Consortium > From owner-ietf-ipsra@mail.vpnc.org Fri Jul 20 06:21:56 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA17508 for ; Fri, 20 Jul 2001 06:21:55 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f6K9Zcl18926 for ietf-ipsra-bks; Fri, 20 Jul 2001 02:35:38 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6K9Zaq18922 for ; Fri, 20 Jul 2001 02:35:36 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05137; Fri, 20 Jul 2001 05:34:39 -0400 (EDT) Message-Id: <200107200934.FAA05137@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ipsra@vpnc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsra-pic-03.txt Date: Fri, 20 Jul 2001 05:34:38 -0400 Sender: owner-ietf-ipsra@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 Remote Access Working Group of the IETF. Title : PIC, A Pre-IKE Credential Provisioning Protocol Author(s) : Y. Sheffer, H. Krawczyk, B. Aboba Filename : draft-ietf-ipsra-pic-03.txt Pages : 18 Date : 19-Jul-01 This document presents a method to bootstrap IPSec authentication via an 'Authentication Server' (AS) and legacy user authentication (e.g., RADIUS). The client machine communicates with the AS using a key exchange protocol where only the server is authenticated, and the derived keys are used to protect the legacy user authentication. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsra-pic-03.txt 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-ipsra-pic-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-ipsra-pic-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: <20010719145639.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsra-pic-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsra-pic-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010719145639.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ipsra@mail.vpnc.org Tue Jul 31 17:31:10 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23605 for ; Tue, 31 Jul 2001 17:31:09 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6VKQ1l11783 for ietf-ipsra-bks; Tue, 31 Jul 2001 13:26:01 -0700 (PDT) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6VKPxs11779 for ; Tue, 31 Jul 2001 13:25:59 -0700 (PDT) Received: by mail.redcreek.com with Internet Mail Service (5.5.2653.19) id ; Tue, 31 Jul 2001 13:26:47 -0700 Received: from redcreek.com (host43.redcreek.com [209.218.26.43]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PDY55FBV; Tue, 31 Jul 2001 13:26:42 -0700 From: "Scott G. Kelly" To: ipsra list Message-ID: <3B67148F.62CD9715@redcreek.com> Date: Tue, 31 Jul 2001 13:26:55 -0700 Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: requirements draft rev 04 Content-Type: multipart/mixed; boundary="------------A7E067FEA22AC57209017897" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------A7E067FEA22AC57209017897 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All, I've rev'd the draft based on wg last call comments. I missed the submission deadline, so I've attached it. I'll submit it to the ID editor after the London meeting. Scott --------------A7E067FEA22AC57209017897 Content-Type: text/plain; charset=us-ascii; name="draft-ietf-ipsra-reqmts-04.txt" Content-Disposition: inline; filename="draft-ietf-ipsra-reqmts-04.txt" Content-Transfer-Encoding: 7bit IPsec Remote Access Working Group Scott Kelly, RedCreek INTERNET-DRAFT Sankar Ramamoorthi, Nexsi draft-ietf-ipsra-reqmts-04.txt July, 2001 Requirements for IPsec Remote Access Scenarios Status of This Memo This document is an Internet Draft and is in full conformance with all provisions of Section 10 of [RFC2026]. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Comments on this document should be sent to the IETF IPsec remote access discussion list (ietf-ipsra@vpnc.org). Abstract IPsec offers much promise as a secure remote access mechanism. However, there are a number of differing remote access scenarios, each having some shared and some unique requirements. A thorough understanding of these requirements is necessary in order to effectively evaluate the suitability of a specific set of mechanisms for any particular remote access scenario. This document enumerates the requirements for a number of common remote access scenarios. Kelly, Ramamoorthi Expires January 2002 [Page 1] Internet Draft July, 2001 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Requirements Terminology . . . . . . . . . . . . . . . . . . . . 4 1.2 Reader Prerequisites . . . . . . . . . . . . . . . . . . . . . . 5 1.3 General Terminology . . . . . . . . . . . . . . . . . . . . . . 5 1.4 Document Organization . . . . . . . . . . . . . . . . . . . . . 6 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1 Endpoint Authentication . . . . . . . . . . . . . . . . . . . . 7 2.1.1 Machine-Level Authentication . . . . . . . . . . . . . . . . . 7 2.1.2 User-Level Authentication . . . . . . . . . . . . . . . . . . 8 2.1.3 Combined User/Machine Authentication . . . . . . . . . . . . . 8 2.1.4 Remote Access Authentication . . . . . . . . . . . . . . . . . 9 2.1.5 Compatibility With Legacy Remote Access Mechanisms . . . . . . 10 2.2 Remote Host Configuration . . . . . . . . . . . . . . . . . . . 11 2.3 Security Policy Configuration . . . . . . . . . . . . . . . . . 12 2.4 Auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.5 Intermediary Traversal . . . . . . . . . . . . . . . . . . . . . 14 3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.1 Telecommuters (Dialup/DSL/Cablemodem) . . . . . . . . . . . . . 15 3.1.1 Endpoint Authentication Requirements . . . . . . . . . . . . . 16 3.1.2 Device Configuration Requirements . . . . . . . . . . . . . . 17 3.1.3 Policy Configuration Requirements . . . . . . . . . . . . . . 18 3.1.4 Auditing Requirements . . . . . . . . . . . . . . . . . . . . 19 3.1.5 Intermediary Traversal Requirements . . . . . . . . . . . . . 19 3.2 Corporate to Remote Extranet . . . . . . . . . . . . . . . . . . 20 3.2.1 Authentication Requirements . . . . . . . . . . . . . . . . . 21 3.2.2 Device Configuration Requirements . . . . . . . . . . . . . . 21 3.2.3 Policy Configuration Requirements . . . . . . . . . . . . . . 22 3.2.4 Auditing Requirements . . . . . . . . . . . . . . . . . . . . 22 3.2.5 Intermediary Traversal Requirements . . . . . . . . . . . . . 22 3.3 Extranet Laptop to Home Corporate Net . . . . . . . . . . . . . 23 3.3.1 Authentication Requirements . . . . . . . . . . . . . . . . . 23 3.3.2 Device Configuration Requirements . . . . . . . . . . . . . . 24 3.3.3 Policy Configuration Requirements . . . . . . . . . . . . . . 24 3.3.4 Auditing Requirements . . . . . . . . . . . . . . . . . . . . 25 3.3.5 Intermediary Traversal Requirements . . . . . . . . . . . . . 25 3.4 Extranet Desktop to Home Corporate Net . . . . . . . . . . . . . 26 3.4.1 Authentication Requirements . . . . . . . . . . . . . . . . . 26 3.4.2 Device Configuration Requirements . . . . . . . . . . . . . . 27 3.4.3 Policy Configuration Requirements . . . . . . . . . . . . . . 27 3.4.4 Auditing Requirements . . . . . . . . . . . . . . . . . . . . 27 3.4.5 Intermediary Traversal Requirements . . . . . . . . . . . . . 27 3.5 Public System to Target Network . . . . . . . . . . . . . . . . 28 3.5.1 Authentication Requirements . . . . . . . . . . . . . . . . . 28 3.5.2 Device Configuration Requirements . . . . . . . . . . . . . . 29 Kelly, Ramamoorthi Expires January 2002 [Page 2] Internet Draft July, 2001 Table of Contents 3.5.3 Policy Configuration Requirements . . . . . . . . . . . . . . 30 3.5.4 Auditing Requirements . . . . . . . . . . . . . . . . . . . . 30 3.5.5 Intermediary Traversal Requirements . . . . . . . . . . . . . 30 4. Scenario Commonalities . . . . . . . . . . . . . . . . . . . . . 30 5. Security Considerations . . . . . . . . . . . . . . . . . . . . . 31 6. Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 31 9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 32 Appendix A: Change Log . . . . . . . . . . . . . . . . . . . . . . . 32 Kelly, Ramamoorthi Expires January 2002 [Page 3] Internet Draft July, 2001 1. Introduction Until recently, remote access has typically been characterized by dial-up users accessing the target network via the Public Switched Telephone Network (PSTN), with the dial-up connection terminating at a Network Access Server (NAS) within the target domain. The protocols facilitating this have usually been PPP-based, and access control, authorization, and accounting functions have typically been provided using one or more of a number of available mechanisms, including RADIUS [RADIUS]. Note that for such access, it has often been assumed that the communications infrastructure supporting the ISP connection (the PSTN) is relatively secure, and poses no significant threats to communications integrity or confidentiality. Based on this assumption, connection security has been limited to access control at the NAS based on username/passphrase pairs. In reality, PSTN dialup connections have never been impervious to a determined adversary. The availability of widespread broadband access, in concert with the desire to reduce the cost of PSTN toll access, have driven the development of Internet-based remote access mechanisms. In some cases, PPP-based tunneling mechanisms have been used to provide remote access by allowing the dial user to first access a local ISP account, and then tunnel an additional PPP connection over the Internet into the target network. In the case of broadband users, such connections are tunneled directly over the Internet. While these mechanisms have been lacking in terms of security features, the increasing availability of IPsec renders it possible to provide more secure remote access to the remote resources via the Internet. Remote access via the Internet has numerous benefits, financial and otherwise. However, security is paramount, and this presents strong incentives for migration from the old dial-up model to a more secure IPsec-based remote access model. Meeting the security requirements of various classes of remote access users presents a number of challenges. It is the aim of this document to explore and enumerate the requirements of various IPsec remote access scenarios, without suggesting particular solutions for them. 1.1 Requirements Terminology The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [3]. Kelly, Ramamoorthi Expires January 2002 [Page 4] Internet Draft July, 2001 1.2 Reader Prerequisites Reader familiarity with RFCs 2401-2412 is a minimum prerequisite to understanding the concepts discussed here. Familiarity with concepts relating to Public Key Infrastructures (PKIs) is also necessary. Familiarity with RADIUS, PPP, PPTP, L2F, L2TP, and other remote access support protocols will also be helpful, though not strictly necessary. 1.3 General Terminology o Remote Access - this term is used to refer to the case in which the remote user does not necessarily reside at a fixed location, i.e. in which the user's IP address is not fixed, and therefore usually not known prior to connection establishment. o Secure Remote Access - this term refers to remote access which is secured using elements of the IPsec protocol suite. o IPsec Remote Access Client (IRAC)- this term is used to refer to the remote access user's system. o IPsec Remote Access Server (IRAS) - this term refers to the device providing access to the target network. An alternative term is "Security Gateway". o Security GateWay (SGW) - this refers to the device providing access to the target network. An alternative term is IRAS. o Virtual IP address (VIP) - this term describes an address from a subnet local to the target network which is assigned to a remote client, giving the appearance that the remote client actually resides on the target network. o Machine-Level Authentication - this term describes the case where the identity of a machine is verified by virtue of the machine's possession and application of some combination of authenticators. For a more complete definition, see section 2. o User-Level Authentication - this term describes the case where the identity of a user (as opposed to that of a machine) is verified by virtue of the user's possession and application of some combination of authenticators. For a more complete definition, see section 2. o NAPT - Network Address/Port Translation Kelly, Ramamoorthi Expires January 2002 [Page 5] Internet Draft July, 2001 1.4 Document Organization The balance of this document is organized as follows: First, there is a general overview of the basic requirements categories, including definitions relevant to these categories. Following this is a section devoted to each remote access scenario. Within each of these sections there are subsections detailing requirements specific to that scenario in each of the following areas: endpoint authentication, remote host configuration, policy configuration, auditing, and intermediary traversal. 2. Overview In a very general sense, all secure remote access scenarios have a similar high-level appearance: target network | | +---+ +-------------+ +-----------+ |---| | |remote access| Internet | security | | +---+ | client |=============| gateway |--| | (IRAC) | |(SGW/IRAS) | | +---+ +-------------+ +-----------+ |---| | | +---+ In all cases, a remote client wishes to securely access resources either behind a SGW or on an IPsec-protected host, and/or wishes to provide other (specific) systems with secure access to the client's own resources. There are numerous details which may differ, depending on the particular scenario. For example, the IRAC may be within another corporate network, or connected to an ISP via dialup, DSL, or CATV media. There may be additional intermediaries between the remote client and the security gateway, but ultimately, all of these configurations may be viewed somewhat equivalently from a high level. In general, there are several basic categories of requirements relevant to secure remote access scenarios, including endpoint authentication, remote host configuration, security policy configuration, auditing, and intermediary traversal. Endpoint authentication refers to verification of the identities of the communication partners (e.g. the IRAC and the IRAS). Remote host configuration refers to the device configuration parameters of the IRAC system. Security policy configuration refers to IPsec policy configuration of both the security gateway and the remote host, and might also be termed "access control and authorization Kelly, Ramamoorthi Expires January 2002 [Page 6] Internet Draft July, 2001 configuration". Auditing refers to the generation and collection of connection status information which is required for the purpose of maintaining the overall security and integrity of the connected networks. Intermediary traversal refers to the ability to pass secured traffic across intermediaries, some of which may modify the packets in some manner. Such intermediaries include NAPT and firewall devices. These various categories are treated in more detail below. 2.1 Endpoint Authentication Before discussing endpoint authentication with respect to remote access, it is important to distinguish between data source authentication and end user authentication. Data source authentication in the IPsec context consists in providing assurance that a network packet originates from a specific endpoint, typically a user, host, or application. IPsec offers mechanisms for this via AH or ESP. End user authentication within the IPsec context consists in providing assurance that the endpoint is what or who it claims to be. IPsec currently offers mechanisms for this as part of IKE [IKE]. While the two types of authentication differ, they are not unrelated. In fact, data source authentication relies upon endpoint authentication, because it is possible to inject packets with a particular IP address into the Internet from many arbitrary locations, so that we cannot be certain in many instances that a packet actually originates from a particular host, or even from the network upon which that host resides. To resolve this, one must first authenticate the particular endpoint somehow, and then bind the addressing information (e.g. IP address, protocol, port) of this endpoint into the trust relationship established by the authentication process. In the context of secure remote access, the authenticated entity may be a machine, a user (application), or both. The authentication methods currently supported by IPsec range from preshared secrets to various signature and encryption schemes employing private keys and their corresponding public key certificates. These mechanisms may be used to authenticate the end user alone, the device alone, or both the end user and the device. These are each discussed in more detail below. 2.1.1 Machine-Level Authentication In the case where no user input is required in order for an authentication credential to be used, the entity authenticated will primarily be the device in which the credential is stored, and the level of derived assurance regarding this authentication is directly Kelly, Ramamoorthi Expires January 2002 [Page 7] Internet Draft July, 2001 related to how securely the machine's credential is maintained during both storage and use. That is, a shared secret or a private key corresponding to a public key certificate may be either stored within the device or contained in another device which is securely accessible by the device (e.g. a smartcard). If the knowledge required for the use of such authentication credentials is entirely contained within the subject device (i.e. no user input is required), then it is problematic to state that such credential usage authenticates anything other than the subject device. In some cases, a user may be required to satisfy certain criteria prior to being given access to stored credentials. In such cases, the level of user authentication provided by the use of such credentials is somewhat difficult to derive. If sufficiently strong access controls exist for the system housing the credential, then there may be a strong binding between the authorized system user and the credential. However, at the time the credential is presented, the IRAS itself has no such assurance. That is, the IRAS in isolation may have some level of assurance that a particular device (the one in which the credential resides) is the one from which access is being attempted, but there is no explicit assurance regarding the identity of the user of the system. In order for the IRAS to derive additional assurance regarding the user identity, an additional user credential of some sort would be required. This is discussed further below. 2.1.2 User-Level Authentication In some cases, the user may possess an authentication token (preshared key, private key, passphrase, etc.), and may provide this or some derivative of this whenever authentication is required. If this token or derivative is delivered directly to the other endpoint without modification by the IRAC system, and if the IRAC system provides no further credentials of its own, then it is the user alone which has been authenticated. That is, while there may be some assurance as to the network address from which the user is originating packets, there is no assurance as to the particular machine from which the user is attempting access. 2.1.3 Combined User/Machine Authentication To authenticate both the user and the system, user input of some sort is required in addition to a credential which is securely stored upon the device. In some cases, such user input may be used in order to "complete" the credential stored on the device (e.g. a private key is password-encrypted), while in others the user's input is supplied independently of the stored credential. In the case where the Kelly, Ramamoorthi Expires January 2002 [Page 8] Internet Draft July, 2001 passphrase is applied to the credential prior to use, the level of assurance derived from successful application of the credential varies according to your viewpoint. From the perspective of a system consisting of user, IRAC, IRAS, and a collection of system protections and security procedures, it may be said that the user has been authenticated to an extent which depends upon the strength of the security procedures and system protections which are in place. However, from the perspective of the IRAS alone, there is little assurance with respect to user identity. That is, schemes requiring that stored credentials be modified by user input prior to use may only be said to provide user-level authentication within the context of the larger system, and then, the level of assurance derived is directly proportional to the weakest security attribute of the entire system. When considering remote access from a general perspective, assumptions regarding the overall system are liable to prove incorrect. This is because the IRAS and the IRAC may not be within the same domain of control; extranet scenarios are a good example of this. Hence, the most desirable joint user/machine authentication mechanisms in this context are those which provide a high level of assurance to both the IRAS and the IRAC, independently of the larger system of which the user, IRAS, and IRAC are a part. 2.1.4 Remote Access Authentication In the general case for remote access, authentication requirements are typically asymmetric. From the IRAC's perspective, it is important to ensure that the IRAS at the other end of the connection is indeed what it seems to be, and not some rogue system masquerading as the SGW. That is, the IRAC requires machine-level authentication for the IRAS. This is fairly straightforward, given the authentication mechanisms supported by IKE and IPsec. Further, this sort of authentication tends to persist through time, although the extent of this persistence depends upon the mechanism chosen. While machine-level authentication for the IRAS is sufficient, this is not the case for the IRAC. Here, it is often important to know that the entity at the other end of the connection is one who is authorized to access local resources rather than someone who happened upon an unoccupied but otherwise authorized system, or a malicious trojan horse application on that user's system, or some other unauthorized entity. Authenticating the user presents different requirements than authenticating the user's machine; this requires some form of user input, and often the authentication must be periodically renewed. Kelly, Ramamoorthi Expires January 2002 [Page 9] Internet Draft July, 2001 In situations where a high level of physical security does not exist, it is common to require a user-input secret as part of the authentication process, and then to periodically renew the authentication. Furthermore, since such circumstances may include the possibility of the presence of a trojan horse application on the IRAC system, one-time passphrase mechanisms are often advisable. Choosing passphrase mechanisms and renewal intervals which provide an acceptable level of risk, but which do not annoy the user too much, may be challenging. It should be obvious that even this approach offers limited assurance in many cases. Clearly, there are variable assurance levels which are attainable with the various endpoint authentication techniques, and none of the techniques discussed offer absolute assurance. Also, there are variations in the authentication requirements among different remote access scenarios. This means there is no "cookie cutter" solution for this problem, and that individual scenarios must be carefully examined in order to derive specific requirements for each. These are examined on a case by case basis below in the detailed scenario descriptions. 2.1.5 Compatibility With Legacy Remote Access Mechanisms There are a number of currently deployed remote access mechanisms which were installed prior to the deployment of IPsec. Typically, these are dialup systems which rely upon RADIUS for user authentication and accounting, but there are other mechanisms as well. An ideal IPsec remote access solution might utilize the components of the underlying framework without modification. Inasmuch as this is possible, this should be a goal. However, there may be cases where this simply cannot be accomplished, due to security and/or other considerations. In such cases, the IPsec remote access framework should be designed to accommodate migration from these mechanisms as painlessly as is possible. In general, proposed IPsec remote access mechanisms should meet the following goals: o should provide direct support for legacy user authentication and accounting systems such as RADIUS o should encourage migration from existing low-entropy password-based systems to more secure authentication systems o if legacy user authentication support cannot be provided without some sort of migration, the impact of such migration should be minimized Kelly, Ramamoorthi Expires January 2002 [Page 10] Internet Draft July, 2001 o user authentication information must be protected against eavesdropping and replay (including the user identity) o single sign-on capability should be provided in configurations employing load-balancing and/or redundancy o n-factor authentication mechanisms should be supported 2.2 Remote Host Configuration Remote host configuration refers to the network-related device configuration of the client system. This configuration may be fixed or dynamic. It may be completely provided by the administrator of the network upon which the remote user currently resides (e.g. the ISP), or it may be partially provided by that administrator, with the balance provided by an entity on the remote corporate network which the client is accessing. In general, this configuration may include the following: o IP address(es) o Subnet mask(s) o Broadcast address(es) o Host name o Domain name o Time offset o Servers (e.g. SMTP, POP, WWW, DNS/NIS, LPR, syslog, WINS, NTP, etc. ) o Router(s) o Router discovery options o Static routes o MTU o Default TTL o Source routing options o IP Forwarding enable/disable o PMTU options o ARP cache timeout o X Windows options o NIS options o NetBIOS options o Vendor-specific options o (other options) Cases where such configuration is fixed are uninteresting; it is the cases where specific IRAC configuration occurs as a result of remote access with which we are concerned. For example, in some cases the IRAC may be assigned a "virtual address", giving the appearance that Kelly, Ramamoorthi Expires January 2002 [Page 11] Internet Draft July, 2001 it resides on the target network: target net +------------------+ | | Remote Access | +--------+ | ( ~ ~ ~ ~ ~ ) |+-------+ Client | | | | ( IRAC ) ||virtual| | |security| |~~~( virtual ) || host | |--------|gateway | | ( presence ) || |<================>| |----| ~ ~ ~ ~ ~ |+-------+ |--------| | | +------------------+ ^ +--------+ | +--------+ | |---| local | IPsec tunnel | | host | with encapsulated | +--------+ traffic inside In this case, the IRAC system begins with an externally routable address. An additional target network address is assigned to the IRAC, and packets containing this assigned address are encapsulated, with the outer headers containing the IRAC's routable address, and forwarded to the IRAS through the tunnel. This provides the IRAC with a virtual presence on the target network via an IPsec tunnel. Note that the IRAC now has two active addresses: the ISP-assigned address, and the VIP. Having obtained this virtual presence on the corporate network, the IRAC may now require other sorts of topology-related configuration, e.g. default routers, DNS server(s), etc., just as a dynamically configured host which physically resides upon the target network would. It is this sort of configuration with which this requirements category is concerned. 2.3 Security Policy Configuration Security policy configuration refers to IPsec access policies for both the remote access client and the security gateway. It may be desirable to configure access policies on connecting IRAC systems which will protect the target network. For example, since a client has access to the Internet (via its routable address), other systems on the Internet also have some level of reciprocal access to the client. In some cases, it may be desirable to block this Internet access (or force it to pass through the tunnel) while the client has a tunneled connection to the target network. This is a matter of client security policy configuration. Kelly, Ramamoorthi Expires January 2002 [Page 12] Internet Draft July, 2001 For the security gateway, it may also be desirable to dynamically adjust policies based upon the user with which a connection has been established. For example, say there are two remote users, named Alice and Bob. We wish to provide Alice with unrestricted access to the target network, while we wish to restrict Bob's access to specific segments. One way to accomplish this would be to statically assign internal "virtual" addresses to each user in a one-to-one mapping, so that each user always has the same address. Then, a particular user's access could be controlled via policies based upon the particular address. However, this does not scale well. A more scalable solution for remote client access control would be to dynamically assign IP addresses from a specific pool based upon the authenticated endpoint identity, with access to specific resources controlled by address-based policies in the SGW. This is very similar to the static mapping described above, except that a given group of users (those with identical access controls) would share a given pool of IP addresses (those which are granted the required access), rather than a given user always mapping to a given address. However, this also has scaling issues, though not as pronounced as for the static mapping. Alternatively, an arbitrary address could be assigned to a user, with the security gateway's policy being dynamically updated based upon the identity of the remote client (and its assigned virtual address) to permit access to particular resources. In these cases, the relevant security policy configuration is specific to the IRAS, rather than to the IRAC. Both IRAS and IRAC security policy configuration are encompassed by this requirements category. 2.4 Auditing Auditing is used here to refer to the collection and reporting of connection status information by the IRAS, for the purpose of maintaining the security and integrity of the network the IRAS protects. For remote access, the following auditing information is useful from a security perspective: o connection start time o connection end time Note that the requirement for a connection-end-time attribute implies the need for a connection heartbeat mechanism of some sort so that the IRAS can accurately determine this quantity in cases where the IRAC does not explicitly terminate the connection. Also note that the heartbeat mechanism in this case is always directed from the IRAC to the IRAS. Kelly, Ramamoorthi Expires January 2002 [Page 13] Internet Draft July, 2001 In some cases, use of a heartbeat may negatively influence a connection. For example, if the heartbeat interval is very short, and the connection is reset after loss of very few heartbeat packets, there is a possibility that network congestion could lead to unnecessary connection resets. The heartbeat interval and reset threshold should be chosen with this in mind, and it should be possible to adjust these quantities either through configuration or negotiation. 2.5 Intermediary Traversal Intermediary traversal is used here to refer to passing a secured data stream through an intermediary such as a firewall or NAPT device. In the case of firewalls, numerous deployed products do not recognize the IPsec protocol suite, making it difficult (sometimes impossible) to configure them to pass it through. In such cases, a mechanism is required for making the data stream appear to be of a type which the firewall is capable of managing. In the case of NAPT devices, there are a number of issues with attempting to pass an encrypted or authenticated data stream. For example, NAPT devices typically modify the source IP address and UDP/TCP port of outgoing packets, and the destination IP address and UDP/TCP port of incoming packets, and in some cases, they modify additional fields in the data portion of the packet. Such modifications render the use of the AH protocol impossible. In the case of ESP, the UDP/TCP port fields fields are sometimes unreadable and always unmodifiable, making meaningful translation by the NAPT device impossible. There are numerous other protocol-field combinations which suffer similarly. This requirements category is concerned with these issues. 3. Scenarios There are numerous remote access scenarios possible using IPsec. This section contains a brief summary enumeration of these, followed by a subsection devoted to each which explores the various requirements in terms of the categories defined above. The following scenarios are discussed: o dialup/dsl/cablemodem telecommuters using their systems to access remote resources o extranet users using local corporate systems to access the remote company network of a business partner Kelly, Ramamoorthi Expires January 2002 [Page 14] Internet Draft July, 2001 o extranet users using their own system within another company's network to access their home corporate network o extranet users using a business partner's system (located on that partner's network) to access their home corporate network o remote users using a borrowed system (e.g. an airport kiosk) to access target network resources 3.1 Telecommuters (Dialup/DSL/Cablemodem) The telecommuter scenario is one of the more common remote access scenarios. The convenience and wide availability of Internet access makes this an attractive option under many circumstances. Users may access the Internet from the comfort of their homes or hotel rooms, and using this Internet connection, access the resources of a target network. In some cases, dialup accounts are used to provide the initial Internet access, while in others some type of "always-on" connection such as a DSL or CATV modem is used. The dialup and always-on cases are very similar, with two significant differences: address assignment mechanism, and connection duration. In most dialup cases, the IRAC's IP address is dynamically assigned as part of connection setup, and with fairly high likelihood, it is different each time the IRAC connects. DSL/CATV users, on the other hand, often have static IP addresses assigned to them, although dynamic assignment is on the increase. As for connection duration, dialup remote access connections are typically short-lived, while always-on connections may maintain remote access connections for significantly longer periods of time. The general configuration in either case looks like this: corporate net | +----+ +-----+ +-----+ /---/ Internet +---+ |--| | |IRAC |---|modem|------|ISP|==========|SGW|--| +----+ +-----+ +-----+ /---/ +---+ | | An alternative to this configuration entails placing a security gateway between the user's system and the modem, in which case this added SGW becomes the IRAC. This is currently most common in cases where DSL/CATV connections are used. Kelly, Ramamoorthi Expires January 2002 [Page 15] Internet Draft July, 2001 3.1.1 Endpoint Authentication Requirements The authentication requirements of this scenario depend in part upon the general security requirements of the network to which access is to be provided. Assuming that the corporate SGW is physically secure, machine authentication for the SGW is sufficient. If this assumption regarding physical security is incorrect, it is not clear that stronger authentication for the SGW could be guaranteed, and derivation of an effective mechanism for that case is beyond the scope of this document. For the IRAC, there are numerous threats to the integrity of the user authentication process. Due to the open nature of common consumer operating systems, some of these threats are quite difficult to protect against. For example, it is very difficult to assert with any level of certainty that a single user system which permits the downloading and running of arbitrary applications from the Internet has not been compromised, and that a covert application is not monitoring and interacting with the user's data at any point in time. However, there are 2 general threats we might realistically hope to somehow mitigate with appropriate authentication mechanisms if we can assume that the system has not been compromised in this manner. First, there is the possibility that a secure connection is established for a particular user, but that someone other than the intended user is currently using that connection. Second, there is the possibility that the user's credential (password, hardware token, etc.) has been somehow compromised, and is being used by someone other than the authorized user to gain access. Mitigation of the first threat, the possibility that someone other than the authorized user is currently using the connection, requires periodic renewal of user authentication. It should be clear that machine authentication will not suffice in this case, and that requiring periodic re-entry of an unchanging user password (which may be written on a post-it note which is stuck to the user's monitor) will have limited effectiveness. Convincing verification of the continued presence of the authorized user will, in many cases, require periodic application of a time-variant credential. Mitigation of the second threat, credential compromise, is difficult, and depends upon a number of factors. If the IRAC system is running a highly secure operating system, then a time-variant credential may again offer some value. A static password is clearly deficient in this scenario, since it may be subject to either online or offline guessing, and eventually compromised - which is the threat we are attempting to mitigate. However, if the IRAC operating system is not hardened, the use of a time-variant credential is only effective if Kelly, Ramamoorthi Expires January 2002 [Page 16] Internet Draft July, 2001 simultaneous access from more than one location is forbidden, and if the credential generation mechanism is not easily compromised. A second approach to the credential compromise problem entails using a PKI-based credential which is stored within a secure container of some sort, and which requires some user interaction prior to operation (e.g. a smartcard). If such a credential requires periodic user interaction to continue operating (e.g. pin re-entry), this may help to limit the access of an unauthorized user who happens upon a connected but unattended systems. However, choosing an acceptable refresh interval is a difficult problem, and if the pin is not time- variant, this provides limited additional assurance. To summarize, the following are the authentication requirements for the IRAS and IRAC: IRAS ---- o machine authentication MUST be provided. IRAC ---- o support for user authentication SHOULD be provided o support for either user or machine authentication MUST be provided o support for user authentication MUST be provided if protection from unauthorized connection use is desired. o if user authentication is provided for short-lived dialup connections, periodic renewal MAY occur o if user authentication is provided for always-on connections, periodic renewal SHOULD occur 3.1.2 Device Configuration Requirements There are 2 possibilities for device configuration in the telecommuter scenario: either access to the target network is permitted for the native ISP-assigned address of the telecommuter's system, or the telecommuter's system is assigned a virtual address from within the target address space. In the first case, there are no device configuration requirements which are not already satisfied by the ISP. However, this case is the exception, rather than the rule. The second case is far more common, due to the numerous benefits derived by providing the IRAC with a virtual presence on the target Kelly, Ramamoorthi Expires January 2002 [Page 17] Internet Draft July, 2001 network. For example, the virtual presence allows the client to receive subnet broadcasts, which permits it to use WINS on the target network. In addition, if the IRAC tunnels all traffic to the target network, then the target policy can be applied to Internet traffic to/from the IRAC. In this case, the IRAC requires, at minimum, assignment of an IP address from the target network. Typically, the IRAC requires anywhere from several more to many more elements of configuration information, depending upon the corporate network's level of topological complexity. For a fairly complete list, see section 2.2. To summarize, the following are the device configuration requirements for the IRAC: o support for a virtual IP (VIP) address MAY be provided o if VIP support is provided, support for all device-related parameters listed in section 2.2 above SHOULD be provided o support for address assignment based upon authenticated identity MAY be provided o if authenticated address assignment is not supported, an identity-based dynamic policy update mechanism such as is described in [ARCH] MUST be supported. 3.1.3 Policy Configuration Requirements In terms of IRAC policy configuration, the most important issue pertains to whether the IRAC has direct Internet access enabled (for browsing, etc.) while a connection to the target network exists. This is important since the fact that the IRAC has access to sites on the Internet implies that those sites have some level of reciprocal access to the IRAC. It may be desirable to completely eliminate this type of access while a tunnel is active. Alternatively, the risks may be mitigated somewhat by forcing all Internet-bound packets leaving the IRAC to first traverse the tunnel to the target network, where they may be subjected to target network policy. A second approach which carries a bit less overhead entails modifying the IRAC's policy configuration to reflect that of the target network during the time the IRAC is connected. In this case, traffic is not forced to loop through the target site prior to exiting or entering the IRAC. This requires some sort of policy download (or modification) capability as part of the SA establishment process. A third approach is to provide a configuration variable for the IRAC which permits specification of "tunnel-all", or "block all traffic not destined for the target network while the SA is up". Kelly, Ramamoorthi Expires January 2002 [Page 18] Internet Draft July, 2001 In terms of IRAS configuration, it may be necessary to dynamically update the security policy database (SPD) when the remote user connects. This is because transit selectors must be based upon network address parameters, but these cannot be known a priori in the remote access case. As is noted above, this may be avoided by provision of a mechanism which permits address assignment based upon authenticated identity. To summarize, the following are the policy configuration requirements for the IRAS and IRAC: IRAS ---- o dynamic policy update mechanism based upon identity and assigned address MAY be supported. o if address assignment-based policy update mechanism is not supported, address assignment based upon authenticated identity SHOULD be supported. IRAC ---- o IRAC SHOULD provide ability to configure for "tunnel-all" and/or "block-all" for traffic not destined for the remote network to which IPsec remote access is being provided. o support for dynamic IRAS update of IRAC policy MAY be provided. 3.1.4 Auditing Requirements For telecommuter sessions, session start/end times must be collected. Reliable derivation of session end time requires that the IRAC somehow periodically signify that the connection remains active. This is implied if the IRAS receives data from the IRAC over the connection, but in cases where no data is sent for some period of time, a signaling mechanism is required by which the IRAC indicates that the connection remains in use. 3.1.5 Intermediary Traversal Requirements If the address assigned by the ISP to the IRAC system is globally routable, and no intermediate devices between the IRAC and the IRAS perform NAPT operations on the data stream, then there are no Kelly, Ramamoorthi Expires January 2002 [Page 19] Internet Draft July, 2001 additional requirements. If NAPT operations are performed on the data stream, some mechanism must be provided in order to render these modifications transparent to the IPsec implementation. 3.2 Corporate to Remote Extranet Extranets are becoming increasingly common, especially as IPsec becomes more widely deployed. In this scenario, a user from one corporation uses a local corporate system to access resources on another corporation's network. Typically, these corporations are cooperating on some level, but not to the degree that unbridled access between the two networks would be acceptable. Hence, this scenario is characterized by limited access. The general topological appearance is similar to this: CORP A CORP B | | +----+ | | +-----+ |USER|---| |--| S1 | +----+ | +------++ ++------+ | +-----+ |---|SGW/FW||===Internet===||SGW/FW|---| | +------++ ++------+ | +-----+ | SGW-A SGW-B |--| S2 | | | +-----+ This is purposely simplified in order to illustrate some basic characteristics without getting bogged down in details. At the edge of each network is a combination security gateway and firewall device. These are labeled "SGW-A" and "SGW-B". In this diagram, corporation B wishes to provide a user from corporation A with access to servers S1 and/or S2. This may be accomplished in one of several different ways: 1) an end-to-end SA is formed from USER to S1 or S2 2) a tunnel-mode SA is formed between SGW-A and SGW-B which only permits traffic between S1/S2 and USER. 3) a tunnel-mode SA is formed between USER and SGW-B which only permits traffic between S1/S2 and USER. These various cases are individually discussed with respect to each requirements category below. Kelly, Ramamoorthi Expires January 2002 [Page 20] Internet Draft July, 2001 3.2.1 Authentication Requirements For the corporate extranet scenario, the authentication requirements vary slightly depending upon the manner in which the connection is accomplished. If only a particular user is permitted to access S1/S2, then user-level authentication is required. If connection types (1) or (3) are used, this may be accomplished in the same manner as it would be for a telecommuter. If connection type (2) is used, one of two things must occur: either SGW-A must provide some local mechanism for authenticating USER and SGW-B must trust this mechanism, or SGW-B must have some mechanism for authenticating USER independently of SGW-A. If access is permitted for anyone within corporation A, then machine authentication will suffice. However, this is highly unlikely. A slightly more likely situation might be one in which access is permitted to anyone within a particular organizational unit in corporation A. This case is very similar the single user access case discussed above, and essentially has the same requirements in terms of the mechanism required for SGW-A, although machine authentication might suffice if the organizational unit which is permitted access has a sufficient level of physical security. Again, this requires that corporation B trust corporation A in this regard. To summarize, the following are the authentication requirements for the IRAS and IRAC: IRAS ---- o machine authentication MUST be provided. IRAC ---- o support for either user or machine authentication MUST be provided o support for a combination of user and machine authentication SHOULD be provided o if user authentication is used, periodic renewal SHOULD occur 3.2.2 Device Configuration Requirements It is possible that corporation B would want to assign a virtual address to USER for the duration of the connection. The only way this could be accomplished would be if USER were a tunnel endpoint (e.g. in cases (1) and (3)). It is not clear what benefits, if any, this Kelly, Ramamoorthi Expires January 2002 [Page 21] Internet Draft July, 2001 would offer. To summarize, the following are the device configuration requirements for the IRAC: o support for a virtual address MAY be provided o if VIP support is provided, support for all device-related parameters listed in section 2.2 above SHOULD be supported o support for address assignment based upon authenticated identity SHOULD be supported o if authenticated address assignment is not supported, an identity-based dynamic policy update mechanism such as is described in [ARCH] MUST be supported. 3.2.3 Policy Configuration Requirements Any of the cases discussed above would present some static policy configuration requirements. Case (1) would require that SGW-A and SGW-B permit IPsec traffic to pass between USER and S1/S2. Case (3) would have similar requirements, except that the IPsec traffic would be between USER and SGW-B. Case (2) would require that the appropriate transit traffic be secured between USER and S1/S2. None of these cases require dynamic policy configuration. 3.2.4 Auditing Requirements For cases (1) and (3), session start/end times must collected. Reliable derivation of session end time requires that the IRAC somehow periodically signify that the connection remains active. This is implied if the IRAS receives data from the IRAC over the connection, but in cases where no data is sent for some period or time, a signaling mechanism is required by which the IRAC indicates that the connection remains in use. For case (2), the type(s) of required auditing data would depend upon whether traffic from multiple users were aggregated within a single tunnel or not. If so, the notion of individual connection start/stop times would be lost. If such measures are desired, this requires that per-user tunnels be set up between SGW-A and SGW-B, and that some sort of timeout interval be used to cause tunnel teardown when traffic does not flow for some interval of time. 3.2.5 Intermediary Traversal Requirements If the address assigned by the host network to the IRAC system is globally routable, and no intermediate devices between the IRAC and Kelly, Ramamoorthi Expires January 2002 [Page 22] Internet Draft July, 2001 the IRAS perform NAPT operations on the data stream, then there are no additional requirements in this regard. If NAPT operations are performed on the data stream, some mechanism must be provided in order to render these modifications transparent to the IPsec implementation. If a firewall situated at the edge of the host network cannot be configured to pass protocols in the IPsec suite, then some mechanism must be provided which converts the data stream to one which the firewall may be configured to pass. If the firewall can be configured to pass IPsec protocols, then this must be accomplished prior to connection establishment. 3.3 Extranet Laptop to Home Corporate Net The use of a laptop while visiting another corporation presents another increasingly common extranet scenario. In this case, a user works temporarily within another corporation, perhaps as part of a service agreement of some sort. The user brings along a CORP-A laptop which is assigned a CORP-B address either statically or dynamically, and the user wishes to securely access resources on CORP-A's network using this laptop. This scenario has the following appearance: CORP A CORP B | | +----+ | | +--------+ |POP |---| |--| CORP-A | +----+ | +------++ ++------+ | | laptop | |---|SGW/FW||===Internet===||SGW/FW|---| +--------+ | +------++ ++------+ | +----+ | SGW-A SGW-B | |FTP |---| | +----+ | | This is very similar to the telecommuter scenario, but it differs in several important ways. First, in this case there is often a SGW and/or firewall at the edge of CORP-B's site. Second, there may be a significantly increased risk that a long-lived connection could become accessible to someone other than the intended user. 3.3.1 Authentication Requirements In most cases, the only acceptable connections from CORP-A's perspective are between the laptop and either SGW-A or the CORP-A servers the laptop wishes to access. Most of the considerations applied to the telecommuter also apply here, and user-level Kelly, Ramamoorthi Expires January 2002 [Page 23] Internet Draft July, 2001 authentication is required to provide assurance that the user who initiated the connection is still the active user. As an added precaution, a combination of user-level and machine-level authentication may be warranted in some cases. Further, in either case this authentication should be renewed frequently. To summarize, the following are the authentication requirements for the IRAS and IRAC: IRAS ---- o machine authentication MUST be provided. IRAC ---- o support for machine authentication SHOULD be provided o support for user authentication MUST be provided o support for a combination of user and machine authentication SHOULD be provided o periodic renewal of user authentication MUST occur 3.3.2 Device Configuration Requirements The device configuration requirements in this scenario are the same as for the telecommuter, i.e. the laptop may be assigned a virtual presence on the corporate network, and if so, will require full infrastructure configuration. To summarize, the following are the device configuration requirements for the IRAC: o support for a virtual address MAY be provided o if VIP support is provided, support for all device-related parameters listed in section 2.2 above SHOULD be supported o support for address assignment based upon authenticated identity SHOULD be supported o if authenticated address assignment is not supported, an identity-based dynamic policy update mechanism such as is described in [ARCH] MUST be supported. 3.3.3 Policy Configuration Requirements The policy configuration requirements in this scenario differ from Kelly, Ramamoorthi Expires January 2002 [Page 24] Internet Draft July, 2001 those of the telecommuter, in that the laptop cannot be assigned a policy which requires all traffic to be forwarded to CORP-A via the tunnel. This is due to the fact that the laptop has a CORP-B address, and as such, may have traffic destined to CORP-B. If this traffic were tunneled to CORP-A, there might be no return path to CORP-B except via the laptop. On the other hand, Internet-bound traffic could be subjected to this restriction if desired, and/or all traffic other than that between CORP-A and the laptop could be blocked for the duration of the connection. IRAC ---- o support for IRAS update of IRAC policy MAY be provided. o if IRAS update of IRAC policy is not supported, IRAC MAY support IRAS directives to "block-all" for non-tunneled traffic. o IRAC SHOULD provide ability to configure for "tunnel-all" and/or "block-all" for traffic not destined for the remote network to which IPsec remote access is being provided. 3.3.4 Auditing Requirements The auditing requirements in this scenario are the same as for the telecommuter scenario. Session start/end times must collected. Reliable derivation of session end time requires that the IRAC somehow periodically signify that the connection remains active. This is implied if the IRAS receives data from the IRAC over the connection, but in cases where no data is sent for some period or time, a signaling mechanism is required by which the IRAC indicates that the connection remains in use. 3.3.5 Intermediary Traversal Requirements If the address assigned by the host network to the IRAC system is globally routable, and no intermediate devices between the IRAC and the IRAS perform NAPT operations on the data stream, then there are no additional requirements in this regard. If NAPT operations are performed on the data stream, some mechanism must be provided in order to render these modifications transparent to the IPsec implementation. Kelly, Ramamoorthi Expires January 2002 [Page 25] Internet Draft July, 2001 If a firewall situated at the edge of the host network cannot be configured to pass protocols in the IPsec suite, then some mechanism must be provided which converts the data stream to one which the firewall may be configured to pass. If the firewall can be configured to pass IPsec protocols, then this must be accomplished prior to connection establishment. 3.4 Extranet Desktop to Home Corporate Net This is very similar to the extranet laptop scenario discussed above, except that a higher degree of trust for CORP-B is required by CORP- A. This scenario has the following appearance: CORP A CORP B | | +----+ | | +--------+ |POP |---| |--| CORP-B | +----+ | +------++ ++------+ | |desktop | |---|SGW/FW||===Internet===||SGW/FW|---| +--------+ | +------++ ++------+ | +----+ | SGW-A SGW-B | |FTP |---| | +----+ | | 3.4.1 Authentication Requirements The authentication requirements for the desktop extranet scenario are very similar to those of the extranet laptop scenario discussed above. The primary difference lies in the authentication type which may be used, i.e. in the laptop case, CORP-A can derive some assurance that the connection is coming from one of CORP-A's systems if a securely stored machine credential is stored on and used by on the laptop. In the desktop case this is not possible, since CORP-A does not own the IRAC system. To summarize, the following are the authentication requirements for the IRAS and IRAC: IRAS ---- o machine authentication MUST be provided. IRAC ---- Kelly, Ramamoorthi Expires January 2002 [Page 26] Internet Draft July, 2001 o support for machine authentication MAY be provided o support for user authentication MUST be provided o support for a combination of user and machine authentication MAY be provided o periodic renewal of user authentication MUST occur 3.4.2 Device Configuration Requirements The device configuration requirements in this scenario are the same as for the laptop extranet scenario, i.e. the desktop system may be assigned a virtual presence on the corporate network, and if so, will require full infrastructure configuration. However, this seems less likely than in the laptop scenario, given CORP-A's lack of control over the software configuration of CORP-B's desktop system. 3.4.3 Policy Configuration Requirements The policy configuration requirements are quite similar to those of the extranet laptop, except that in this scenario there is even less control over CORP-B's desktop than there would be over the laptop. This means it may not be possible to restrict traffic in any way at the desktop system. 3.4.4 Auditing Requirements The auditing requirements in this scenario are the same as for the telecommuter scenario. Session start/end times must collected. Reliable derivation of session end time requires that the IRAC somehow periodically signify that the connection remains active. This is implied if the IRAS receives data from the IRAC over the connection, but in cases where no data is sent for some period or time, a signaling mechanism is required by which the IRAC indicates that the connection remains in use. 3.4.5 Intermediary Traversal Requirements If the address assigned by the host network to the IRAC system is globally routable, and no intermediate devices between the IRAC and the IRAS perform NAPT operations on the data stream, then there are no additional requirements in this regard. If NAPT operations are performed on the data stream, some mechanism must be provided in order to render these modifications transparent to the IPsec implementation. If a firewall situated at the edge of the host network cannot be configured to pass protocols in the IPsec suite, then some mechanism must be provided which converts the data stream to one Kelly, Ramamoorthi Expires January 2002 [Page 27] Internet Draft July, 2001 which the firewall may be configured to pass. If the firewall can be configured to pass IPsec protocols, then this must be accomplished prior to connection establishment. 3.5 Public System to Target Network This scenario entails a traveling user connecting to the target network using a public system owned by someone else. A commonly cited example is an airport kiosk. This looks very similar to the extranet desktop scenario, except that in the extranet scenario, CORP-A might have a trust relationship with CORP-B, whereas in this scenario, CORP-A may not trust a publically accessible system. Note that a trust relationship between CORP-A and the owner of the public system may exist, but in many cases will not. 3.5.1 Authentication Requirements There are two variations to this scenario. In the first, no trust relationship exists between the target network and the borrowed system. In the second, some trust relationship does exist. In the case where no trust relationship exists, machine authentication is out of the question, as it is meaningless in this context. Further, since such a system could easily capture a passphrase, use of a static passphrase from such a system would seem to be ill-advised. If a one-time passphrase were used, this would mitigate the risk of passphrase capture by the public system. On the other hand, if it is acknowledged that such capture is a real threat (i.e. the system itself is malicious), then it must also be recognized that any data transmitted and received via the resulting session would not be confidential or reliable with respect to this malicious system, and that the system could not be trusted to have actually disconnected when the user walks away. This suggests that accessing non-trivial information from such a system would be imprudent. Another possible user authentication option would be a smartcard. However, many smartcards require a pin or passphrase to "unlock" them, which requires some level of trust in the kiosk to not record the pin. Hence, this approach suffers from drawbacks similar to those of the static passphrase in this regard. The primary difference would be that the pin/passphrase could not be used alone for access in the smartcard case. In cases where a trust relationship with the owner of the public system exists, the trust level would modulate the risk levels Kelly, Ramamoorthi Expires January 2002 [Page 28] Internet Draft July, 2001 discussed above. For example, if a sufficient level of trust for the system owner exists, use of a static passphrase might present no more risk than if this were permitted from a system owned by the accessed target. However, the primary benefit of such a trust relationship would be derived from the ability to authenticate the machine from which the user is attempting access. For example, a security policy requiring that remote access only be permitted with combined user/machine authentication might be effected, with further control regarding which machines were allowed. An additional issue to be dealt with in either case pertains to verification of the identity of the IRAS. If the IRAC were to be misdirected somehow, a man in the middle attack could be effected, with the obtained password being then used for malicious access to the true IRAS. Note that even a one-time password mechanism offers little protection in this case. In order to avert such an attack, the IRAC must possess some certifiable or secret knowledge of the IRAS prior to attempting to connect. Note that in the case where no trust relationship exists, this is not possible. To summarize, the following are the authentication requirements for the IRAS and IRAC: IRAS ---- o machine authentication MUST be provided. IRAC ---- o in cases where no trust relationship exists between the accessed network and the system owner, sensitive data SHOULD NOT be transmitted in either direction. o in cases where a trust relationship exists between the accessed network and the system owner, machine authentication SHOULD be supported. o in cases where a trust relationship exists between the accessed network and the system owner, a static passphrase MAY be used in conjunction with machine-level authentication of the IRAC system. o frequent renewal of user authentication MUST occur 3.5.2 Device Configuration Requirements None. Kelly, Ramamoorthi Expires January 2002 [Page 29] Internet Draft July, 2001 3.5.3 Policy Configuration Requirements None. 3.5.4 Auditing Requirements The auditing requirements in this scenario are the same as for the telecommuter scenario. Session start/end times must collected. Reliable derivation of session end time requires that the IRAC somehow periodically signify that the connection remains active. This is implied if the IRAS receives data from the IRAC over the connection, but in cases where no data is sent for some period of time, a signaling mechanism is required by which the IRAC indicates that the connection remains in use. 3.5.5 Intermediary Traversal Requirements If the address of the IRAC system is globally routable, and no intermediate devices between the IRAC and the IRAS perform NAPT operations on the data stream, then there are no additional requirements in this regard. If NAPT operations are performed on the data stream, some mechanism must be provided in order to render these modifications transparent to the IPsec implementation. 4. Scenario Commonalities As we examine the various remote access scenarios, a general set of common requirements emerge. Following is a summary: o Support for user authentication is required in almost all scenarios o Machine authentication for the IRAS is required in all scenarios o A mechanism for providing device configuration for the IRAC is required in most scenarios. Such a mechanism must be extensible. o Machine authentication for IRAC is generally only useful when combined with user authentication. Combined user and and machine authentication is useful in some scenarios. o Dynamic IRAC policy configuration is useful in several scenarios. o Most scenarios require auditing for session start/stop Kelly, Ramamoorthi Expires January 2002 [Page 30] Internet Draft July, 2001 times. o An intermediary traversal mechanism may be required in any of the scenarios. 5. Security Considerations The topic of this document is secure remote access. Security considerations are discussed throughout the document. 6. Editors' Addresses Scott Kelly RedCreek Communications 3900 Newpark Mall Road Newark, CA 94560 USA email: skelly@redcreek.com Telephone: +1 (510) 745-3969 Sankar Ramamoorthi Nexsi 1959 Concourse Drive San Jose, CA 95131 USA E-mail: sankar@nexsi.com Telephone: +1 (408) 579-5718 7. References [ARCH] Kent, S., and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [KEYWORDS] Bradner, S., "Key Words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RADIUS] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC2138 [IKE] Harkins, D., and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. 8. Acknowledgements The editors would like to acknowledge the many helpful comments of Sara Bitan, Steve Kent, Mark Townsley, Bernard Aboba, Mike Horn, and other Kelly, Ramamoorthi Expires January 2002 [Page 31] Internet Draft July, 2001 members of the ipsra working group who have made helpful comments on this work. 9. Full Copyright Statement Copyright (C) The Internet Society (2001). 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. Appendix A: Change Log 00 to 01: o delete mobility requirements o add accounting requirements o extensively modify discussion of endpoint authentication, and machine vs. user authentication o delete roaming/wireless users and user-to-user connections from Scenarios bullet list o Add discussion of trojan horse applications to telecommuter scenario o add statement about encouraging migration to PKI-based systems to legacy compatibility section. o clarified language in section 2.3 (Security Policy Configuration) Kelly, Ramamoorthi Expires January 2002 [Page 32] Internet Draft July, 2001 01 to 02: o add n-factor authentication to general requirements o change "accounting" to "auditing" o delete incoming/outgoing octet counts from auditing requirements o added intermediary traversal requirements o numerous general edits for clarity 02 to 03: o minor edits throughout o significantly modified introduction to provide discussion of L2TP/IPsec o replaced "corporate" with "target" when referring to the network the IRAS protects o modified discussion in section 3.1.1 o changed SHOULD to MAY in section 3.2.2, support for address assignment based on authenticated identity 03 to 04: o minor edits throughout o removed discussion of L2TP/IPsec from introduction o changed some of the remaining "corporate" references to "target" o added "NAPT" to general terminology definitions o collapsed "road warrior" scenario into remote telecommuter scenario Kelly, Ramamoorthi Expires January 2002 [Page 33] --------------A7E067FEA22AC57209017897--