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]