IPSEC Working Group                         Scott Kelly,
INTERNET-DRAFT                              RedCreek Communications
draft-ietf-ipsec-secconf-00.txt             Mike St. Johns,
Expires in 6 months                         @Home Network
                                            October, 1998

         Secure Configuration of IPsec-Enabled Network Devices


Status of This Memo
   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its 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.''

   To view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
   Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
   Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).

   Comments on this document should be sent to "ipsec@tis.com", the IETF
   IPsec WG discussion list.

Abstract

   Remote configuration of network devices which implement IPsec-
   related services is desirable as a matter of convenience and of
   scale. In some cases, these devices are installed on a network with
   no prior configuration. In such cases, secure mechanisms for
   bootstrap configuration are required. In this document the associated
   issues are examined, and a multi-tiered approach is proposed from
   which a specific method may be selected based upon the security
   requirements of the environment in which the security device exists.
   While the primary devices considered here are security gateways and
   bump-in-the-wire encryptors, many of the resulting conclusions may
   extend to other devices, including host IPsec implementations.


1. Problem Space Overview

   In general, the level of inconvenience associated with configuring a
   network device is directly proportional to the level of security



Kelly, St. Johns          Expires April, 1999                  [Page 1]


Internet Draft      draft-ietf-ipsec-secconf-00.txt        October, 1998


   desired of the device once configured. To a somewhat lesser degree,
   it is also a function of the environment in which configuration takes
   place, and of whether the device has been previously configured for
   that environment. When initially  deploying an IP security device
   such as a security gateway or a bump-in-the-wire encryptor, there are
   at least two common requirements. First, the device requires the
   assignment of an IP address and associated infrastructure
   information. Second, it requires additional configuration relating to
   the specific device and to local security policy.

   In obtaining the required configuration, one of 3 general scenarios
   may occur: in the first, the device is placed on the network without
   any initial configuration, and DHCP is used to assign an IP address
   and a next boot or configuration server, after which time the
   additional configuration information is retrieved. This is the
   "bootstrap" method. In the second scenario, the device is entirely
   configured offline (on a private network, using a serial port, or in
   some other manner) before being placed on the network. In the third
   scenario, the device is first assigned an IP address and some sort of
   configuration server designation, and then it is placed on the
   network where it obtains additional configuration information from
   the specified server.

   In all of the above cases, network configuration is followed by
   additional security and device configuration, using SNMP, LDAP, or
   some proprietary mechanism. Depending upon a variety of
   circumstances, the security requirements of a particular installation
   will determine which of these methods represents an acceptable level
   of security. This document examines precisely what the
   vulnerabilities of each method are, and proposes mechanisms which
   eliminate or minimize these vulnerabilities.

1.1 Requirements Terminology

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [RFC-2119].

1.2 Security Terminology

   This document uses the following security terms:

     "Authentication"
       Authentication, when used in this document, refers to a process
       which results in verification of both the identity of a subject,
       and of the assertion that the object in question was originated
       by the subject. For a more comprehensive definition of this term,
       see [ARCH].



Kelly, St. Johns          Expires April, 1999                  [Page 2]


Internet Draft      draft-ietf-ipsec-secconf-00.txt        October, 1998


     "Confidentiality"
       Confidentiality, when used in this document, refers to the degree
       to which exchanged information is unknown to all but the
       endpoints of the exchange. For a more comprehensive definition of
       this term, see [ARCH].

     "Data Integrity"
       Data integrity, when used in this document, refers to the
       reliability of received data, or to the degree of certainty that
       the data which is received has not been altered in transit. For a
       more comprehensive definition of this term, see [ARCH].

1.3 Secure Configuration Terminology

   This document uses the following terms in describing secure
   configuration:

     "Security Device"
       A security device may be a security gateway or bump-in-the- wire
       encryptor which provides IPsec-related services to networks
       and/or users.

     "Configuration Server"
       The terms "server" and "configuration server" are used when
       referring to either a privately linked configuring system or to a
       DHCP (or other) configuration server reachable over the not
       necessarily local network.

     "Client"
       The term "client" is used when referring to a security device
       which must obtain some portion of its configuration from a
       server.

     "Public network"
       A public network is any network on which the security device and
       configuration server reside which is also accessible to devices
       other than the security device and the configuration server.

2. Configuration Scenarios

   In evaluating the various configuration scenarios, it is useful to
   think in terms of the 2 'phases' of device configuration previously
   discussed. In the first phase, the IP address of the device is
   assigned, and in some cases an identifier representing an authorized
   configuration server may also be assigned. In the second phase,
   additional configuration relating to device function (including
   security policy parameters) is accomplished, and this may be done
   either by the same server which participated in the first phase, or



Kelly, St. Johns          Expires April, 1999                  [Page 3]


Internet Draft      draft-ietf-ipsec-secconf-00.txt        October, 1998


   by another server.

   It is also useful to think in terms of tuples corresponding to the
   phases described above, with the tuple elements denoting the method
   employed in each phase. These methods take on one of two values: a
   network interface of the device, provided that no other system has
   access to the device via that network connection during
   configuration, or it could instead be accomplished using a private
   serial (or other) interface. There are four possible tuples:

         Address Assignment     Configuration
            Mechanism             Mechanism
         =====================================
            Private               Private
            Private               Network
            Network               Private
            Network               Network

   In general, the tuple (network, private) is so unlikely that no
   further consideration is given to that mechanism here. The others
   have varying likelihood, depending upon the circumstances of
   deployment. The prominent characteristics of each tuple are defined
   in the following sections.

2.1 Entirely Private Configuration: (private, private)


         +------------+   private connection     +---------------+
         |  Security  |--------------------------| configuration |
         |   device   |                          |    server     |
         +------------+                          +---------------+

   Entirely out-of-band configuration represents a seemingly trivial
   case, although this process could be compromised in various ways.
   These are discussed in section 3. The private connection in the above
   illustration could  be a serial line, an ethernet link, or of some
   other proprietary type. For our purposes these are all equivalent,
   the distinguishing characteristic being that no other system may
   interfere with the exchange.

   This mechanism, while reasonably secure, does not scale well.
   Consider the provisioning of home users' devices, e.g. for CATV
   network systems or ADSL installations. In some cases, the devices
   will be installed by users after picking up the equipment from a
   central office. In such cases, the level of user expertise may be
   such that configuring the device is difficult or impractical. Also,
   while the configuration could arguably be done at the central office
   (or even at the manufacturing site), this obviously presents scaling



Kelly, St. Johns          Expires April, 1999                  [Page 4]


Internet Draft      draft-ietf-ipsec-secconf-00.txt        October, 1998


   problems. It seems quite clear that to maximize the scalability of
   the installation process, we must minimize the effort (and expertise)
   required.

2.2 Private/Public Configuration: (private, network)


                    Network, possibly disjoint
                             |         |
     +------------+          |         |    +---------------+
     |  Security  |----------+--/  /---|----|   secondary   |
     |   device   |          |         |    | configuration |
     +------+-----+          |         |    |    server     |
            |                               +---------------+
            |(initial) private link
            |
     +------+--------+
     |   initial     |
     | configuration |
     |    server     |
     +---------------+

   Partially out-of-band configuration represents the case in which the
   initial IP address and configuration server identifier(s) (and
   perhaps credentials) are assigned privately, after which the device
   is installed on the network. When the device is powered on after
   network installation, it attempts to obtain its device configuration
   from the configured server ('secondary configuration server' in
   diagram).

2.3 Completely Public Configuration: (network, network)

                       Network, possibly disjoint

   +------------+          |         |    +---------------+
   |  Security  |----------+--/  /---|----|     DHCP      |
   |   device   |          |         |    |    server     |
   +------------+          |         |    +---------------+
                                     ~
                                     |    +---------------+
                                     |----| configuration |
                                     |    |    server     |
                                     |    +---------------+

   Completely public configuration represents the case in which the
   unconfigured device is connected to the public network, and in which
   the device first attempts to procure an address and next-boot-server
   indication from a DHCP server, and then attempts to obtain its



Kelly, St. Johns          Expires April, 1999                  [Page 5]


Internet Draft      draft-ietf-ipsec-secconf-00.txt        October, 1998


   configuration from the server with the provided identity, which may
   be the same as the DHCP server. This is a common provisioning model
   in the CATV/ADSL home network access industry.

3. Vulnerabilities

   In evaluating the vulnerabilities of each scenario, it is appropriate
   to recognize that in the worst case the attacker will be highly
   skilled, have plenty of resources, and have at least one of the
   devices in question available for leisurely examination. Furthermore,
   it should also be assumed that the attacker will have access to a
   network upon which such devices are installed, so that if the devices
   are publicly configured, there will be ample opportunity to observe
   this process.

   Under these circumstances it is very difficult to provide a foolproof
   security system, although we may come very close if we combine
   physical security with some of the methodologies proposed below.
   Additionally, we must recognize that in some cases, even nearly-
   foolproof security is financially or logistically infeasible. In such
   cases, a lesser degree of security may be acceptable.

   There are essentially 3 points within this process which may be
   attacked, depending upon which configuration scenario we choose: the
   (private) configuring system, the device which is to be configured,
   and the remote configuration server. These various attacks are
   explored in the context of individual configuration scenarios below.
   Attacks on the network medium itself may generally be classed as
   Denial-of-Service (DoS) or passive "man in the middle" (MiM) attacks
   on the various devices, so this is not discussed as a separate point
   of attack.

3.1 Vulnerabilities of Entirely Private Configuration

     +------------+   private connection     +---------------+
     |  Security  |--------------------------| configuration |
     |   device   |                          |    server     |
     +------------+                          +---------------+

   There are 2 points of attack in this situation: the configuration
   server, and the security device itself. Attacks upon the
   configuration server might include installation of hostile software,
   or simply misappropriation and unauthorized use. Attacks upon the
   device which is to be configured include device substitution or
   firmware replacement. DoS is not a viable attack in this case,
   although it could theoretically be (temporarily) mounted by damaging
   the configuring interface of either device.




Kelly, St. Johns          Expires April, 1999                  [Page 6]


Internet Draft      draft-ietf-ipsec-secconf-00.txt        October, 1998


   If we can insure the physical inaccessibility of the devices to
   anyone other than the authorized system administrator, remaining
   concerns are minimal. However, insuring inaccessibility of the
   security device between the time of manufacturing and time of
   delivery may be difficult. If access to either system by unauthorized
   parties is a possibility, then additional steps are required to
   secure the device configuration process. Similar mechanisms may be
   applied in other configuration scenarios, and discussion of these is
   deferred to section 4 below.


3.2 Vulnerabilities of Partially Private and Public Configuration
                      Network, possibly disjoint
     +------------+          |         |    +---------------+
     |  Security  |----------+--/  /---|----|     DHCP      |
     |   device   |          |         |    |    server     |
     +------------+          |         |    +---------------+
                                       ~
                                       |    +---------------+
                                       |----| configuration |
                                       |    |    server     |
                                       |    +---------------+

     The initial phase of configuration in this scenario is susceptible
     to the same attacks as for the previous scenario. If the physical
     security of the devices prior to configuration cannot be
     guaranteed, both are subject to substitution or damage. Assuming
     the first phase of configuration (IP address, config server
     identification) are completed successfully, then the second phase
     is the only one of concern.

                             |              |
                     +---+   |     +---+    |  +---+
                     | C |---+-//--| M |-//-+--| S |
                     +---+   |     +---+    |  +---+
                             |              |

     Referring to the diagram above, let C represent the 'client'
     security device, let M represent a malicious user, and let S
     represent the configuration server. It should be obvious at this
     point that we are concerned with man-in-the-middle attacks. In this
     case, M may be capable of impersonating S with respect to C, and of
     impersonating C with respect to S, effectively tricking both sides
     into thinking C is appropriately configured, when in fact it is
     not. Or, M could simply examine all intervening packets, thus
     (perhaps) learning something useful about C's configuration - in
     this case, M would not necessarily be between C and S, but would
     have access to one or the other's network.



Kelly, St. Johns          Expires April, 1999                  [Page 7]


Internet Draft      draft-ietf-ipsec-secconf-00.txt        October, 1998


     Alternatively, M could simply launch a DoS attack in several
     different ways. For a discussion of various DHCP-related attacks,
     see [DHCSEC]. Finally, the configuration information on the server
     itself could be somehow compromised prior to download to the
     security device, in which case the attacker might subsequently gain
     control of the security device.


3.3 Vulnerabilities of Entirely Public Configuration

     Entirely public configuration represents the case where the device
     is placed on the network with no prior configuration. It first must
     use DHCP to determine its IP address and configuration server, and
     it then must obtain its configuration from the server. This is by
     far the most vulnerable of the 3 scenarios, being subject to active
     or passive man in the middle attacks, denial of service, or
     configuration compromise. Discussion of various mechanisms for
     securing the each of these scenarios follows.


4. Securing the Configuration Process

     If we cannot insure complete physical security for the devices
     involved in the configuration process, the risks presented by
     unauthorized access may be mitigated in a number of ways, if
     desired. The means for providing additional security may be broadly
     grouped in 2 categories: authentication mechanisms, and
     confidentiality mechanisms. While the value of confidentiality
     during this process may be debatable, authentication is a critical
     ingredient of any configuration security scheme. For simplicity, we
     may group authentication mechanisms into 4 general categories:

     o None, where the security device simply accepts configuration from
       any system which has the appropriate interface, and which
       presents the appropriate commands or protocols.

     o Low, where the security device and the configuration server have
       a rudimentary authentication mechanism for each other, such as a
       shared secret which is manufactured into the device.

     o Medium, where the security device and perhaps the configuration
       server are preconfigured with digital certificates, and have some
       mechanism which employs them for authentication.

     o High, where the security device and the configuration server rely
       on hardware protection of the authentication keying material and
       perhaps some form of secondary authentication. Hardware
       protection might include use of a symmetric hardware token pair



Kelly, St. Johns          Expires April, 1999                  [Page 8]


Internet Draft      draft-ietf-ipsec-secconf-00.txt        October, 1998


       (e.g. smartcards), although it could also consist of any tamper-
       proof hardware storage mechanism.

     Obviously, there are gradations within the various levels. This
     classification is simplified in the interest of clarity, and to
     facilitate discussion. These levels may be modulated by a number of
     factors, including the addition of confidentiality mechanisms to
     the configuration process. There are a number of mechanisms
     available for provision of confidentiality, several of which are
     discussed below.

     It should be noted that there are two components to the
     authentication process with respect to the configuring server: the
     first relates to authenticating the server as a network entity,
     while the second relates to authenticating the configuration
     application which resides on the server. This distinction becomes
     important in cases where the configuration server resides on a
     multi-tasking system.

     In general, both authentication and confidentiality may be provided
     to the configuration process using the infrastructure provided by
     IP security (see [ARCH] et al), although there are other mechanisms
     available. However, as noted above, the authentication provided by
     IPsec alone may not suffice under all circumstances. It is one
     thing to form an authenticated security association with the host
     upon which a configuring application may run, while it is another
     entirely to form an authenticated security association with the
     configuring application itself.

     In the case where the configuring device does not implement IPsec,
     or in the case where the configuring application runs on a multi-
     tasking system, either SNMPv3 or TLS are options for securing the
     configuration protocol. If the device implements IPsec, the
     transport security protocol may run within an IPsec SA. The details
     of the such mechanisms are given below.

     It is also appropriate to assume, at least for the present, that
     DHCP is insecure. Since IPsec is a layer 3 construct, it cannot be
     used to protect DHCP transactions, or to authenticate DHCP servers.
     While some discussion is currently under way regarding DHCP
     authentication and security [DHCSEC, DHCAUTH], no such mechanisms
     have yet been widely adopted. Hence, in cases where DHCP must be
     used for initial address assignment, security devices MUST not rely
     on the involved IP addresses as identifiers or credentials. That
     is, the authentication and confidentiality mechanisms used to
     secure the configuration process MUST be independent of the IP
     addresses of the security device and configuration server.




Kelly, St. Johns          Expires April, 1999                  [Page 9]


Internet Draft      draft-ietf-ipsec-secconf-00.txt        October, 1998


     In the following sections, each of the general security levels
     referenced above are discussed in detail with respect to the
     various configuration tuples.


4.1 No Preconfigured Authentication Mechanism (NOAUTH)

     While there might seem to be nothing one could do to prevent the
     various attacks on this approach, this is not necessarily the case.
     The associated protective measures for each of the relevant
     configuration tuples is examined below.

4.1.1 NOAUTH - Entirely Private Configuration: (private, private)

     In the case of entirely offline configuration, the primary defense
     is physical security for the devices in question. If this method is
     chosen, the weak points in the system should be recognized and
     eliminated inasmuch as this is possible. If the security device
     uses tamper-evident packaging, then it may be reasonable to assume
     that devices which exhibit no signs of tampering are safe to
     configure. If the device is not packaged in a tamper-evident (or
     tamper-proof) manner, the possibility exists that the device has
     been altered in some way. This must be recognized as a risk.

     Perhaps of more concern is the integrity of the configuring system.
     Configuring system integrity concerns may be mitigated in the
     following ways:

     o physically isolate the configuring system.

     o password-protect the configuring system (with a nontrivial
       password), and report repeated password failures using a secure
       auditing procedure.

     o password-protect the configuring software (with a nontrivial
       password). The software could be signed with using the password
       (or a hash of it), and refuse to run if the signature does not
       match. This would also be an auditable event.

     o require a hardware token for system access.

     Obviously, using a hardware token in conjunction with password-
     protecting both the configuring system and the configuring software
     provides the highest level of security for the case where no
     authentication is employed. Concerns more directly related to the
     unauthenticated configuration process may be mitigated in the
     following ways:




Kelly, St. Johns          Expires April, 1999                 [Page 10]


Internet Draft      draft-ietf-ipsec-secconf-00.txt        October, 1998


     o require a physical key of some sort to be inserted into the
       security device for the duration of the configuration process.

     o [TBD - must be other things we can do...]


4.1.2 NOAUTH - Partially Private Configuration: (private, public)

     Assuming that the initial configuration phase has been
     accomplished, the concern now is in reducing the exposure risk for
     the configuration download. Using no authentication mechanisms, the
     various mechanisms discussed above for securing the configuration
     server and device are available. In addition, there are 2 other
     ways in which to protect the configuration process. First, the
     device will contact the server (or vice versa) in the clear. Since
     the protocol is known, the risks of this approach may be mitigated
     by monitoring the network for such transactions. Second, further
     reduction of the risks may be attained by insuring that no
     malicious middle man may detach the network on which the server
     resides from the network on which the device resides while
     inserting himself in between the two.


4.1.3 NOAUTH - Entirely Public Configuration: (public, public)

     In the case of public configuration with no authentication
     mechanism, the physical security considerations for the other cases
     must still apply, and may in fact become even more critical. In
     this case, the device will be placed on the network with no
     configuration, and then it will broadcast a DHCP (or proprietary)
     request. Any system on the network could respond to this request.
     In this case, the only protection which may apply will result from
     a strict network monitoring policy, and a response mechanism for
     the case in which a rogue configuration server responds to the
     broadcast. To further reduce the exposure, one of the several
     techniques referenced in section 4.1.1 should be used.

     A more subtle risk exists in that the configuration transaction may
     be passively monitored. If no confidentiality is provided, the
     attacker may gain insights which aid an attack upon the security
     device after configuration is complete. If, on the other hand, the
     security device forms a Security Association (SA - see [ARCH] for
     relevant definitions) with the configuration server, such passive
     observation will be effectively impossible, although there will be
     no authentication provided with the SA.


4.2 Authentication using a Preshared Secret (LOWAUTH)



Kelly, St. Johns          Expires April, 1999                 [Page 11]


Internet Draft      draft-ietf-ipsec-secconf-00.txt        October, 1998


4.2.1 LOWAUTH - Entirely Private Configuration: (private, private)

     In the case of entirely private configuration, essentially the same
     issues apply for preshared secrets which apply for no
     authentication whatsoever, with the caveat that illegal
     configuration by a rogue server may be slightly more difficult to
     accomplish. The security realized by the addition of the preshared
     secret to this scheme is minimal, but certainly better than none at
     all.

4.2.2 LOWAUTH - Partially Private Configuration: (private, public)

     For partially private configuration, the preshared secret has
     somewhat more utility than for entirely private configuration. In
     this case, the preshared secret may be configured as part of the
     manufacturing process. The secret is then used to authenticate the
     configuration server during the second phase. The usual cautions
     pertain to the physical security of the devices prior to
     configuration, but this mechanism does provide some small amount of
     protection from man-in-the-middle attacks, assuming that the
     preshared secret is changed often, and is nontrivial. Also assumed
     is that various password-attack prevention mechanisms are in place.

     In order to utilize this mechanism, the security device negotiates
     a SA with the configuration server upon booting up on the network.
     This SA is authenticated using the preshared key. Subsequent
     configuration is accomplished via this SA. The SA MUST be protected
     with encryption as well as authentication, and the shared secret
     SHOULD be replaced during the configuration process, with the new
     shared secret being used for subsequent configuration.


4.2.3 LOWAUTH - Entirely Public Configuration: (public, public)

     Entirely public configuration is much the same as for partially
     private configuration. In no event should the DHCP-derived
     addresses be considered secure. The shared secret must be
     configured as part of the manufacturing phase. Following assignment
     of an IP address and configuration server identity, the secret may
     then be used to authenticate the configuration server during the
     second phase.

     In order to effectively use the preshared secret during the second
     phase, the security device should negotiate a SA with the
     configuration server. The SA must be authenticated using the
     preshared key, and subsequent configuration is accomplished via
     this SA. This SA MUST be protected with encryption as well as
     authentication, and the shared secret SHOULD be replaced during the



Kelly, St. Johns          Expires April, 1999                 [Page 12]


Internet Draft      draft-ietf-ipsec-secconf-00.txt        October, 1998


     configuration process, with the new shared secret being used for
     subsequent configuration.

     The usual cautions pertain to the physical security of the devices
     prior to configuration, but this mechanism does provide some small
     amount of protection from man-in-the-middle attacks, assuming that
     the shared secret is changed from time to time, and is nontrivial.
     However, the inclusion of the secret in the manufacturing process
     complicates this approach.

4.3 Certificates for Authentication (MEDAUTH)

     Certificates provide a much more reliable authentication mechanism
     than preshared secrets, although they are similar in many ways. The
     primary differences lie in their verifiability via a PKI
     infrastructure, and in the fact that compromise of the public
     values within the security device does not give the information
     necessary to impersonate a configuration server. Given the current
     low level of interoperable PKI implementations, there are
     impediments to widespread deployment of this mechanism.
     Nonetheless, this approach is much less susceptible to compromise
     than the shared secret approach.

     For this form of configuration, the considerations for all 3 tuples
     are essentially the same; hence, all are described together. In
     order to secure the private, partially private, and public
     configuration exchanges, the public key (or list of public keys)
     for the allowed configuration server(s) must be assigned to the
     security device during the manufacturing process. The security
     device MUST not rely upon the addresses configured in the first
     phase for authentication.

     The configuration server's public key is used to authenticate an
     IPsec SA which is established after the initial DHCP (or other
     address assignment) operation. In all tuple cases other than
     (private, private), this SA MUST be protected with encryption as
     well as authentication. In all cases, the configuration certificate
     SHOULD be replaced during the configuration process, with the new
     certificate being used for subsequent configuration.

     [TBD - discuss snmpv3 here, along with mechanism for key exchange
     to setup snmp shared secret]

     The usual cautions pertain to the physical security of the devices
     prior to configuration, but this mechanism does provide a much
     larger measure of protection from impersonation attacks than a
     shared secret might. However, the inclusion of the public key in
     the manufacturing process complicates this mechanism.



Kelly, St. Johns          Expires April, 1999                 [Page 13]


Internet Draft      draft-ietf-ipsec-secconf-00.txt        October, 1998


4.4 Hardware Protection for Authentication (HIAUTH)

4.4.1 HIAUTH - Entirely Private Configuration: (private, private)

     This is potentially the most secure mechanism by which to configure
     security devices, and there are several levels of gradation
     depending upon the mechanisms applied. These include the following:

     o symmetric hardware protection; the authentication keying material
       is stored in symmetric hardware devices (e.g. a PCMCIA card pair)
       which must be simultaneously inserted in both devices for
       configuration to proceed.

     o asymmetric hardware protection A; the authentication keying
       material is stored in tamper-proof flash memory on the security
       device, and a hardware device is inserted in the configuring
       server.

     o asymmetric hardware protection B; the authentication keying
       material is communicated to the security device via a hardware
       token (e.g. PCMCIA card) which is inserted prior to
       configuration, and is somehow securely stored on the
       configuration server.

     This technique may be somewhat strengthened in a number of ways.
     First, the server-based implementation may require a (one-time ?)
     password in order to utilize the token. Second, this token/password
     pair could be required in order to decrypt the actual configuration
     software. Third, the device could be manufactured to permit only a
     limited range of hardware tokens the required access. The list goes
     on and on, primarily limited by the amount of trouble the
     administrator is willing to go through in order to insure the
     integrity of the configuration process.

     In the case of hardware protection, concerns for the physical
     security of the devices is much lessened, in that there are
     mechanisms available to effectively prevent compromise even if
     physical access to the equipment is gained.

4.4.2 HIAUTH - Partially Private Configuration: (private, public)

     After entirely private configuration using hardware protection,
     this is the next most secure mechanism by which to configure
     security devices. In this case, the hardware-protected keying
     material for the security device should include a self-
     authenticating key (to generate a signature to be passed to the
     config server), and a public key (list) for the available
     configuration servers.



Kelly, St. Johns          Expires April, 1999                 [Page 14]


Internet Draft      draft-ietf-ipsec-secconf-00.txt        October, 1998


     The initial server configures the security device with its IP
     address and the IP address of the secondary configuration server;
     no authentication of any sort is necessary. Subsequently, the
     security device contacts the secondary server and creates an
     authenticated SA using the hardware protected keying material for
     authentication, and using this SA, downloads its configuration from
     the server. This SA MUST provide for an encrypted data stream.


4.4.3 HIAUTH - Entirely Public Configuration: (public, public)

     This mechanism is very similar to the (private, public) mechanism,
     except that the initial configuration phase may be subject to DoS
     attacks. The hardware-protected keying material for the security
     device should include a self-authenticating key (to generate a
     signature to be passed to the config server), and a public key
     (list) for the available configuration server(s). The hardware
     device is inserted prior to the placement of the security device on
     the network.

     Upon booting up, the security device broadcasts a DHCP request, and
     the response contains the IP address of the security device and of
     the next boot server. Following this, the security device contacts
     the secondary server and creates an authenticated/encrypted SA
     using the protected keying material, and using this SA, downloads
     its configuration from the server.


5. Additional Security Mechanisms

     There are a number of additional steps which will further secure
     the configuration process. These various mechanisms may be applied
     regardless of the other security mechanisms used, so they are
     discussed separately.

5.1 SNMPv3

     SNMPv3 [SNMP3] may be used as a secondary configuration
     authentication mechanism as well as for data confidentiality. In
     fact, in some cases, it may be the only mechanism employed. It
     should be noted that the encryption or authentication key strengths
     to be used for the SNMP exchanges are a function of the level of
     device security you wish to obtain. In general, the algorithms used
     for configuration should be at least as strong as the strongest
     algorithms the security device will apply to data flows that it
     secures. If security policy dictates the use of 3DES for the
     secured flows, then 3DES should be the minimum security employed
     for the configuration exchange.



Kelly, St. Johns          Expires April, 1999                 [Page 15]


Internet Draft      draft-ietf-ipsec-secconf-00.txt        October, 1998


     SNMPv3 uses shared secrets in order to provide confidentiality.
     While [SNMP3] states that the protocol must not be tied to any
     specific Key Management Protocol (KMP), this would not seem to
     preclude the employment of a KMP if desirable. For our purposes, we
     should consider the use of KMPs to further secure SNMPv3. There are
     at least 3 ways in which the shared secrets may be configured:
     statically, during the initial private phase of a (private, public)
     scenario, or dynamically. The first 2 cases are relatively
     straightforward to implement, so they are not discussed further
     here. The dynamic case is discussed below.

     [TBD - use ISAKMP with new DOI for this?]


5.2 Transport Layer Security (TLS)

     TLS [TLS] may be used as a secondary authentication mechanism as
     well as for data confidentiality. As discussed earlier, if the
     configuration process runs on a multi-tasking system, then IPsec
     can only authenticate the host - not the configuring application.
     Further, even if the configuration information is encrypted on the
     wire due to the IPsec SA, there is still the possibility that it
     could be observed and/or modified before being encrypted.

     [TBD - fill in]

6. Security Considerations

     IPsec device configuration security is the subject of this
     document. Thus, all relevant security considerations are discussed
     above.


7. Editor's Addresses

     Scott Kelly
     RedCreek Communications
     3900 Newpark Mall Road
     Newark, CA 94560
     USA
     email: skelly@redcreek.com
     Telephone: +1 (510) 745-3969

     Mike St. Johns
     @Home Network
     425 Broadway
     Redwood City, CA 94063
     USA



Kelly, St. Johns          Expires April, 1999                 [Page 16]


Internet Draft      draft-ietf-ipsec-secconf-00.txt        October, 1998


     email: stjohns@corp.home.net
     Telephone: +1 (650) 569-5368


References

     [ARCH]  S. Kent and R. Atkinson, "Security Architecture for IP",
                 Internet Draft, July 1998

     [IKE]         D. Harkins and D. Carrell, "The Internet Key Exchange",
                 Internet Draft, July 1998

     [DHCSEC]        O. Gudmundsson, R. Droms "Security Requirements for the
                 DHCP protocol", Internet Draft, March 1998

     [DHCAUTH]   R. Droms, W. Arbaugh, "Authentication for DHCP Messages",
                   Internet Draft, August 1998

     [TLS]         T. Dierks, C. Allen, "The TLS Protocol", Internet Draft,
                 May 1998


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



Kelly, St. Johns          Expires April, 1999                 [Page 17]


Internet Draft      draft-ietf-ipsec-secconf-00.txt        October, 1998


     HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
     MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

















































Kelly, St. Johns          Expires April, 1999                 [Page 18]