Subject: evaluation draft

From: "Scott G. Kelly" <[email-masked]>
Date: Thu, 05 Jul 2001 17:13:50 -0700

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 ([email-masked]).

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       <draft-kelly-ipsra-eval-00.txt>          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       <draft-kelly-ipsra-eval-00.txt>          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       <draft-kelly-ipsra-eval-00.txt>          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       <draft-kelly-ipsra-eval-00.txt>          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       <draft-kelly-ipsra-eval-00.txt>          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       <draft-kelly-ipsra-eval-00.txt>          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       <draft-kelly-ipsra-eval-00.txt>          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       <draft-kelly-ipsra-eval-00.txt>          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       <draft-kelly-ipsra-eval-00.txt>          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       <draft-kelly-ipsra-eval-00.txt>          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       <draft-kelly-ipsra-eval-00.txt>          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       <draft-kelly-ipsra-eval-00.txt>          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       <draft-kelly-ipsra-eval-00.txt>          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       <draft-kelly-ipsra-eval-00.txt>          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       <draft-kelly-ipsra-eval-00.txt>          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, <EAP> [,<EAP>...]

   (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       <draft-kelly-ipsra-eval-00.txt>          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       <draft-kelly-ipsra-eval-00.txt>          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       <draft-kelly-ipsra-eval-00.txt>          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       <draft-kelly-ipsra-eval-00.txt>          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       <draft-kelly-ipsra-eval-00.txt>          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       <draft-kelly-ipsra-eval-00.txt>          July, 2001

   considerations are discussed throughout the document.

9. Editors' Addresses

   Scott Kelly
   RedCreek Communications
   3900 Newpark Mall Road
   Newark, CA 94560 USA
   email: [email-masked]
   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       <draft-kelly-ipsra-eval-00.txt>          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: "Tamir Zegman" <[email-masked]>
Date: Sat, 7 Jul 2001 11:04:22 +0200

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: "Scott G. Kelly" <[email-masked]>
Date: Sat, 07 Jul 2001 12:09:49 -0700

Hi Tamir,

Thanks for taking the time to review the draft. Comments interspersed
below...

> 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).

> 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?

> RSA signatures) are more expensive than RSA public operarions (i.e. RSA

I'm not sure what made you think I assumed this - please elaborate.

> operation and is therefore better protected even compared to regular IKE

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).

> 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.

> 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?

> I believe that you have raised this issue more than once and more than once

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

Nonetheless, we generally strive to limit (or eliminate) known plaintext
whenever possible, and this is good practice.

> 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: "Andrew Krywaniuk" <[email-masked]>
Date: Sun, 8 Jul 2001 03:39:19 -0400

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...

> 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: "Scott G. Kelly" <[email-masked]>
Date: Sun, 08 Jul 2001 21:08:24 -0700

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:
<trimmed...>

> 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 + <fill in your favorite legacy user
authentication extension>. 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.

> 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.

<more trimmed...>

> 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.

> 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: "Andrew Krywaniuk" <[email-masked]>
Date: Mon, 9 Jul 2001 04:04:09 -0400

> could be easily remedied at that time

I would rather you removed it for the reason that the problem is not a
problem.

> won't be able to undo whatever we do here, so we had better

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
> > points you do bring up are easily refuted.
>
> 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
   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:

       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.

e) see all of a, b, c, and d.

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
       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.

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,

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

---

From: "Scott G. Kelly" <[email-masked]>
Date: Mon, 09 Jul 2001 07:17:49 -0700

Andrew Krywaniuk wrote:

<trimmed...> 

> solution. If you fix the problem at the root, it will not exist at the

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?

> a) I explained in the last e-mail how plain old IKE has the exact same

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?

> yes, this DoS attack is moved to the IRAS. I explain in (d) why that is not

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?

>    shortcomings not relating specifically to preshared keys apply

I'll look at the draft text to see if this should be clarified somehow.

> c) Arguments which state that X is complex are easy to make and impossible

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.

> 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?

> f) the key phrase here is "up to"

The key phrase here is "why?"

> tunneled IP header). This is an assumption in the protocol design, as I

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. 

> 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?

> 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?

> 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.

> 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: "Darren Dukes" <[email-masked]>
Date: Mon, 9 Jul 2001 17:44:36 -0400

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.

---

From: "Darren Dukes" <[email-masked]>
Date: Mon, 9 Jul 2001 18:49:45 -0400

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" <[email-masked]>
To: "ietf-ipsra" <[email-masked]>
Sent: Monday, July 09, 2001 5:44 PM
Subject: Re: evaluation draft

> why would they want to deploy an AS for PIC, which is just a CA using
> 5 - If a separate AS is not deployed for PIC but it exists on the SGW, PIC
> deploying an AS is anything close to the complexity of writing and testing
> requires the AS to engage in an unauthenticated Diffie-Hellman exchange

---

From: "Andrew Krywaniuk" <[email-masked]>
Date: Mon, 9 Jul 2001 23:55:32 -0400

> so that the "real" authtentication, consisting of username/pwd, can

*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*.

> 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.

> greatly reducing the (probable) known plaintext.

Oh, really?

> Using tokens
> instead of

I'm sad to hear it, since I'd love to hear you try to defend your above
statement about PFS and identity protection.

> already wasted far too much time here, and we need to get our

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

---

From: "Scott G. Kelly" <[email-masked]>
Date: Tue, 10 Jul 2001 09:41:02 -0700

Hi Darren,

Thanks for taking the time to read the draft and comment. Responses
interspersed below...

> 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.

> 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.

> 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...

> 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...

> 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).

> important if they are on the same SGW.  This is worth mentioning in your

Okay.

> Hybrid then this argument also applies to PIC.

More on this later (I think this particular discussion also deserves a
thread all its own).

> 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.

> 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.

> 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: "Scott G. Kelly" <[email-masked]>
Date: Tue, 10 Jul 2001 10:03:53 -0700

<much trimmed, to be discussed in other threads>

> 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. 

> 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...

> 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. 

> > greatly reducing the (probable) known plaintext.

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: Hugo Krawczyk <[email-masked]>
Date: Tue, 10 Jul 2001 20:56:37 +0300 (IDT)

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: Paul Hoffman / VPNC <[email-masked]>
Date: Tue, 10 Jul 2001 11:29:38 -0700

>(I wouldn't be against, except that convergence in this case seems 

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: "Andrew Krywaniuk" <[email-masked]>
Date: Tue, 10 Jul 2001 15:07:52 -0400

> assurance reqarding their identity. More on this in a more general DoS

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.

> 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.

> 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.

> 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.

> 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

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

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 11 Jul 2001 00:05:23 -0700 (PDT)

> 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: Hugo Krawczyk <[email-masked]>
Date: Wed, 11 Jul 2001 13:15:10 +0300 (IDT)

> 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

---

From: "Stephane Beaulieu" <[email-masked]>
Date: Wed, 11 Jul 2001 09:45:30 -0400

> 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: "Darren Dukes" <[email-masked]>
Date: Wed, 11 Jul 2001 10:46:44 -0400

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

---

From: "sankar ramamoorthi" <[email-masked]>
Date: Wed, 11 Jul 2001 09:31:47 -0700

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: [email-masked]
[mailto:[email-masked]]On Behalf Of Darren Dukes
Sent: Wednesday, July 11, 2001 7:47 AM
To: ietf-ipsra
Subject: PIC is IKE (was Re: evaluation draft)`

Darren

---

From: "Darren Dukes" <[email-masked]>
Date: Wed, 11 Jul 2001 11:16:55 -0400

Scott, Yet more comments inline.
----- Original Message -----
From: "Scott G. Kelly" <[email-masked]>
To: "Darren Dukes" <[email-masked]>
Cc: "ietf-ipsra" <[email-masked]>
Sent: Tuesday, July 10, 2001 12:41 PM
Subject: Re: evaluation draft

> 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.

> our own past experience to confirm this premise. I think this is

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.

> 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?

> connections from anyone, but I think it we should strive to minimize it.
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]
> doesn't make the problem go away.

The exact same is true for PIC.

> 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.

> > requires the IRAS to engage in an unauthenticated Diffie-Hellman
exchange
> standalone AS may be an attractive feature.
This is true but the end result is the same.

---

From: Tylor Allison <[email-masked]>
Date: Wed, 11 Jul 2001 15:18:57 -0500 (CDT)

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         [email-masked]
Secure Computing Corporation

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 11 Jul 2001 17:14:00 -0700 (PDT)

> 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: Bernard Aboba <[email-masked]>
Date: Wed, 11 Jul 2001 22:14:17 -0700 (PDT)

> A constructive subject of

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: "Scott Fanning" <[email-masked]>
Date: Wed, 11 Jul 2001 22:57:58 -0700

See inline (STF)..

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]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

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.

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.

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.

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: "Andrew Krywaniuk" <[email-masked]>
Date: Sun, 8 Jul 2001 03:39:19 -0400

Scott,

Andrew

---

From: "Andrew Krywaniuk" <[email-masked]>
Date: Mon, 9 Jul 2001 04:04:09 -0400

and then

Copied from draft:

       and denial of service.

       If a reusable

Andrew

---

From: Hugo Krawczyk <[email-masked]>
Date: Wed, 11 Jul 2001 13:15:10 +0300 (IDT)

Hugo

---

From: "Darren Dukes" <[email-masked]>
Date: Wed, 11 Jul 2001 10:46:44 -0400

Darren

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 11 Jul 2001 22:14:17 -0700 (PDT)

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 13 Jul 2001 14:02:33 -0400

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: Henry Spencer <[email-masked]>
Date: Fri, 13 Jul 2001 14:54:27 -0400 (EDT)

> daemons try to share the same port.

Agreed, all three times.  A separate port is strongly preferable.

                                                          Henry Spencer
                                                       [email-masked]

---

From: Hugo Krawczyk <[email-masked]>
Date: Wed, 11 Jul 2001 13:15:10 +0300 (IDT)

Hugo