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]