Network Working Group IPsec Working Group
INTERNET DRAFT C. Madson
Expires: May 2001 Cisco Systems Inc.
November 2001
Protocol Requirements for Son-of-IKE
<draft-ietf-ipsec-son-of-ike-protocol-reqts-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and 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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
Various proposals have been made for updating the IKE protocol.
One thing which is missing from the dicussion is an evaluation of the
scope of IKE, identifying which problems it should solve. Once this
scoping is done, it becomes easier to specify the requirements for
the protocol, as well as the protocol itself. Sections of this
document discuss various scenarios that are considered important for
IKE; this list needs to be refined by the WG.
This document also makes recommendations for protocol improvement in
such areas as modularity, extensibility, protocol convergence and
simplicity, which are important regardless of the scope of IKE.
1. Introduction
While there have been various proposals made over time of how to
"improve" IKE, in order to address issues such as complexity, it's
important to decide what are the important characteristics for the
Madson [Page 1]
INTERNET DRAFT November 2001 Expires May 2002
protocol, and then determine what changes need to be made in order to
accomplish this.
Another way of stating this is "what are the characteristics of an
optimal protocol, and what does it take to get there?" It will be
important to prioritize these characteristics, in order to help focus
on making changes in areas that will have the biggest benefit.
This document does not disucss security requirements in the sense
that it does not cover things like DoS, replay protection,
cryptographic protection, etc. It concentrates more on the protocol
aspects of IKE -- in general these concepts could be applied to other
non-security protocols.
2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [1].
3. A Need for Protocol Scoping
While the WG considers what should be changed within IKE, one of the
early questions that should be answered is one of "what should be the
scope of IKE?" This issue has several different facets.
There has been this (at least implicit) general philosophy that if
any other protocols need security, that the security needs to be
provided by IPsec, and by proxy, the key management needs to be
provided by IKE.
While IKE should be the key management mechanism of choice for the
vast majority of usage domains, requiring any mechanism to "solve the
world's problems" is not only inappropriate, but results in a
protocol that is difficult to work with.
There are several examples in the IETF where the lack of a well-
defined scope results in protocols and mechanisms that are either
overly generalized (and therefore harder to evaluate and understand),
or where various parties attempt to shoehorn in the "little piece
that will solve their problem". Any protocol/mechanism forced to grow
such appendages in abnormal places over time becomes unrecognizable.
Or, to restate it in a more straightforward way, even if the
mechanism started out simple, these little pieces shoved into such a
mechanism can over time vastly increase the complexity of the
mechanism. Such a protocol can become cursed by its own success.
There needs to be a description of just what IKE will (and won't) do.
The WG also needs to decide upon the important environments in which
Madson [Page 2]
INTERNET DRAFT November 2001 Expires May 2002
IKE will be used, in order to ensure that IKE meets the needs to
those environments. In some cases, there are pieces needed that
aren't currently supplied by IKE; a conscious decision needs to be
made whether or not to accommodate that piece within IKE, or to leave
it to an external mechanism. [In the latter case, if that mechanism
does not exist, a statement of requirements associated with that
mechanism must be written.]
While a well-defined scope is very important, this does not mean that
IKE should not be considered as a solution for other usage domains.
However, while there is an understandable desire to use IKE
everywhere, it is appropriate to consider how much would need to be
added/changed to IKE, and somehow evaluate just "how much is too
much?" In certain cases, the answer may be to add something to IKE,
while in other cases a separate protocol may be needed, to be used
either in conjunction with IKE or instead of IKE.
While it may not always be appropriate to use IKE in its normal form,
that doesn't mean that IKE needs to be jettisoned altogether. To a
large extent, many of the things provided by IKE are also things that
are needed regardless of the mechanism used.
One such current example is KINK, which has used a lot of IKE
components, while replacing the key exchange and authentication
components. The WG evaluated the various components of IKE, and
decided which pieces it could reuse from IKE and which it had to
replace. Another current example is multicast, where a key management
mechanism that needs to address such issues as delivering keying
material to a group of "valid" members is also reusing various
components of IKE.
There has been this long-standing view that at least ISAKMP can be
used to secure things other than IPsec (and possibly the
encapsulation protocols coming out of MSEC). In fact, this represents
one of the fundamental design criteria applied to ISAKMP, via the use
of Domains of Interpretation. The vision of the Domains of
Interpretation was to allow other entities to use the vast bulk of
the ISAKMP protocol, while simply filling in a few pieces that are
protocol-specific. In other words, the protocol payloads, exchanges,
etc., are the same, but some of the payload contents could be unique
to the particular DOI.
There have been those that have argued that the concept of Domains of
Interpretation has overly complicated the protocol, in part because
it forces the use of multiple documents to describe the protocol for
a particular DOI. On the other hand, it currently represents the
only "official" mechanism for specifying IKE variants that are
actually very close to IKE in many ways.
There have been several short-lived IETF-based proposals made in the
past attempting to use the DOI concept. Today there are two current
proposals: one for the multicast keying mechanism, known as "Group
Madson [Page 3]
INTERNET DRAFT November 2001 Expires May 2002
DOI" (GDOI) coming out of MSEC, and another is the MAP Security
Domain of Interpretation (MAPSEC DOI), which instantiates ISAKMP for
use with MAP.
Another area of scooping has to do with "what percentage of the
problem should be solved by IKE and what should be solved by an
external mechanism?" While IKE provides a nice protected pipe to pass
information between the two crypto peers, it shouldn't be viewed as a
license to cram everything into there. Nonetheless, in some cases
the best answer may be to have the information passed through IKE.
[The current proposal associated with XAUTH and MODECFG uses IKE to
pass protocol information which is needed prior to IKE phase 2
processing.]
Many of the above issues need to be considered when deciding the
appropriate scooping for IKE. What is also important is that the WG
needs to consider some number critical domains of usage that must be
addressed within the base protocol; in other words, which subset of
the "world's problems" are important to be tacked by IKE.
As an initial proposal, the base IKE protocol should address the
following scenarios: (a) end-to-end security, (b) secure remote
access for clients connecting to a device that will subsequently
enable them to access the networks behind it, and (c) VPN site-to-
site tunnels. The appendix will discuss the requirements for these
scenarios.
It will also become very important to consider protocol modularity:
as the WG decides what should be considered "IKE", it will be
important to develop an approach towards modularity that can provide
a means for others to use components of IKE within their own
protocols. A well-thought out strategy for extensibility will also be
important. Input and output criteria for each component of IKE must
be carefully described.
4. Ease of Extensibility
Extensibility becomes a critical characteristic: if it becomes too
difficult to extend a protocol, the protocol is as good as dead in
the face of ever-changing network topologies. [This does not mean
that the solution to all the problems is to simply extend the
protocol - in certain cases the more appropriate answer is to use
pieces of IKE where appropriate, as discussed in Section 3.]
Via the use of IANA-controlled numbering spaces, it is possible to
specify new field values (e.g. new algorithms) or even new payloads
or exchanges. There are a few obvious issues with the current IKE as
outlined below:
1. The biggest problem here is that the protocol (or at least most
Madson [Page 4]
INTERNET DRAFT November 2001 Expires May 2002
implementations of it) will not only reject unrecognized payloads,
but will also force a termination of the connection. In certain
cases, this behavior is too drastic, especially for payloads that
could be considered optional and probably not security-critical.
When there is a strong need to use a payload that did not exist in
the original IKE specification, the parties are forced to use
Vendor-ID payloads to either pre-negotiate support for such a
payload, or to actually encode the payload itself. This works
because most vendors will ignore unrecognized Vendor-ID payloads.
Forcing the use of such mechanisms results in unnecessary
complexity. The new IKE specification must be able to at least
represent payloads in such a way that the receiver can clearly
understand whether or not it is valid to ignore a particular
payload that it doesn't recognize. In other words, if a payload is
"critical", it will be represented in a way that the receiver will
reject it if it doesn't understand it (and possibly terminate the
connection). If the payload is "non-critical", it will be
represented in such a way that the receiver can ignore it. When
new payloads are defined, they will be required to state whether
they are always critical, critical by choice of sender, or non-
critical.
2. IKE currently only hashes part of the packet. The algorithm to
decide which fields to hash does not accommodate new payloads,
regardless of their security criticality. The new IKE
specification must address this deficiency.
3. An analysis needs to be done with respect to other fields, in
order to decide the appropriate behavior for handling unrecognized
values. This should be spelled out in the new IKE specification.
Besides these issues associated with extensibility of fields and
values, extensibility also needs to be considered along with
modularity in order to address some of the issues discussed in
Section 3. A good definition of modularity can help in terms of
thinking about extensibility, and vice-versa.
One such example is the use of the DOI as an extension point -
depending upon how protocol modularity is approached, a decision
can be better made as to whether to retain the DOI concept or to
replace it with something different that accomplishes the same
thing.
Another area of extensibility has to do with the general idea of "now
that there is a protected (IKE) connection between the two crypto
endpoints, what else besides phase 2 negotiation can be protected via
this connection?" [This could also apply to new exchanges happening
during phase 1, or even before phase 1.] If these new messages or
exchanges have an effect on other parts of the protocol, such as a
phase 2 negotiation, or even introducing a new phase to the protocol,
the specification of the new message/exchange must analyze and
document this.
Madson [Page 5]
INTERNET DRAFT November 2001 Expires May 2002
5. Modularity
Protocol modularity can be helpful in several ways: it can help sub-
divide the protocol itself into components that are more easily
grasped and more easily analyzable.
Protocol modularity can also help to make "modules" available for use
by other key management mechanisms, in the case where it is
determined the IKE is not the best fit, or to allow other mechanism
to use "most" of IKE and only replacing the one or two modules
necessary for supporting that mechanism's requirements.
The effort of sub-dividing the protocol needs to include some
definition of the boundaries, e.g. what does this module require from
other modules, and what will be produced by this module? In general,
a module can be replaced by another module as long as that second
module meets the needs that were supplied by that first module. [A
high-level illustrative example could be "anything could replace IKE
as long as that new mechanism(s) met the needs of IPsec, which
include negotiating SAs and supplying bulk keying material.]
One example of a module might be key agreement; given the security
importance of key agreement, having good modularity would allow the
key agreement piece to be replaced if, for example, the original
mechanism were deemed to be no longer secure. [Or, certain
environments could call out for even stronger key agreement
mechanisms that are too processing-intensive for normal use. Or other
environments may wish to replace the key agreement with another
mechanism based on base key material being generated by a trusted
third party.]
If key agreement were its own module, it could be evaluated in
isolation. The evaluation could place some criteria on the module
inputs (randomness requirements, etc.), and try to make a statement
as to the amount of security provided by this module. It could also
make some statements about processing impact (time/number of
messages, etc.). Such information could help to decide whether to use
module A or module B for a particular environment.
6. Improve Convergence Characteristics
It is important for a protocol to behave in a predictable manner,
even in the face of retransmissions, lost packets, receipt of invalid
packets or payloads, loss of communication between the peers, etc.
It is especially important that once an IKE exchange starts, that the
two peers have a very similar view of the state of the connection
between them.
It is also important for the behaviors to be well understood, so that
implementers can make sure that they have implemented the protocol
correctly.
Madson [Page 6]
INTERNET DRAFT November 2001 Expires May 2002
This can be addressed by various means. While representations such as
protocol state machines are always useful, it is especially important
to analyze error conditions and to document the analysis.
The base protocol must specify all of the pieces needed to ensure
convergence. For example, there have been various mechanisms
suggested over time to address such things as detecting loss of
communication with the IKE peer, and how to handle synchronization
between the IKE peers in terms of rekeying. While in some cases the
suggested mechanism might be the best solution to the problem, in
some cases, the mechanism has been introduced in order to address a
deficiency in the base protocol (e.g. lack of guaranteed
notify/delete messages). The eventual solution may involve the
merging of both the new mechanism and other protocol changes.
In any case, the base protocol specification must be expanded to
address the following issues, which affect the ability of the two
peers to have the same view of the connection:
* Rekeying: the behaviors associated with rekeying must be spelled
out
* Detection of loss of communication with peer
* Documenting errors, especially if it results in a state change
to a peer. Especially if it involves sending an error message to
the peer. Besides documenting the error, there needs to be
documentation describing what a peer needs to do when receiving
the error message. Defining a list of well-known errors and well-
known behaviors relative to the errors can help to ensure more
consistent behavior.
* Negotiation matching rules need to be spelled out (e.g. SA
lifetimes, etc.)
As new things (exchanges, etc.) are introduced to the protocol, these
specifications will also be required to perform a similar analysis.
This becomes especially important if the addition has an impact on
protocol behaviors.
7. Improve Simplicity
Simplicity has various facets to it. The primary goal is to make a
protocol that is understandable and easier to implement.
One approach to simplicity is getting rid of unnecessary fields,
exchanges, etc. and reducing the number of documents needed to
describe the protocol.
Good scoping and modularity can also help to make a protocol easier
to understand. Good descriptions of protocol behaviors can also make
the protocol easier to understand and implement.
Madson [Page 7]
INTERNET DRAFT November 2001 Expires May 2002
Another facet of simplicity has to do with "ease of accomplishing a
particular function". One example is the area of negotiation - while
having one peer simply send a list of proposals to the other peer,
and having the receiver simply pick one is "simple" on the one hand,
if the goal is "connectivity even without a-priori complete knowledge
of the policy configured on the receiver", things get complicated
quickly. If the negotiation only included two attributes, it would be
(relatively) easy for the initiator to derive a complete list of
possibilities. When there are more than two attributes, and some of
the attributes are variables such as lifetime, things becomes
complicated quickly.
In some cases, such as the negotiation one above, it may be that the
"simplicity" will be accomplished by the use of something external to
IKE (e.g. policy discovery mechanism, etc.). Such assumptions and
decisions must be documented.
8. Authentication and IKE
There has been this commonly held view that "IKE requires an X.509
PKI", possibly because the use of X.509 certificates and pre-shared
keys are the two main authentication mechanisms spelled out in the
base draft (at least to the point of specifying payloads and the use
of information derived from the authentication to generate the
SKEYID). In some cases, this perception results in people not wanting
to consider using IKE. Others simply feel that such a specification
should not be a part of the IKE document, that such an inclusion
discourages the development/deployment/use of other mechanisms.
One solution is to remove the specifics to separate drafts (except
for pre-shared keys), while the base document spells out requirements
for authentication. Then separate documents could be written for the
protocol and handling requirements for each authentication mechanism
(e.g. "if you want to do X.509 certificates, you must support these
payloads, you must support these encoding formats, you must send
these payloads at this point in the exchange, you must send
certificate chains that look like this, you must be able to support
certificate path discovery (or not), you must feed this blob into
SKEYID generation this way, etc..."). The document should also spell
out if the particular authentication mechanism implies a particular
trust model.
Over time, there has also been confusion with respect to user-vs.-
machine authentication via IKE. Over time, it seems that the general
consensus has been that IKE provides machine authentication; part of
it has to do with the wide variety of user authentication mechanisms,
and where or not they should be accommodated for IKE phase 1,
especially given that IKE is typically constrained to a 6-message
exchange. If this model holds, there may be a need for user
authentication as a part of IKE (and not just in the remote access
scenario). At a minimum, the base draft should specify that IKE
supplies machine-level authentication.
Madson [Page 8]
INTERNET DRAFT November 2001 Expires May 2002
9. Security Considerations
This document describes various considerations that should be taken
into account for developing a follow-on protocol to IKE. The primary
goals of these considerations is to provide guidance for a protocol
that is more easily understood/evaluated in terms of security
properties and behaviors.
10. Acknowledgements
Thanks to various members of the IPsec WG whose comments over a long
period of time have contributed to the thinking which resulted in
this document. Thanks also to Brian Weis for reviewing this document
and making many helpful suggestions.
11. References
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
12. Editor's Address
Cheryl Madson
<cmadson@cisco.com>
Cisco Systems, Inc.
The IPsec working group can be contacted through the chairs:
Barbara Fraser
<byfraser@cisco.com>
Cisco Systems, Inc.
Ted T'so
<tytso@mit.edu>
Massachusetts Institute of Technology
A. Scoping: Primary Domains of Usage
As was discussed earlier, it is important for IKE to focus on some
number of usage domains, and make sure that the domains' requirements
have been met. The following sections describe several
characteristics of each domain of usage which are noteworthy.
The scenarios listed here are considered to be the major ones that
should be addressed, although the list is not exhaustive and needs to
be refined by the WG.
Many times, IP traffic between a given source and destination will be
Madson [Page 9]
INTERNET DRAFT November 2001 Expires May 2002
secured via one of these scenarios; however, many of these can be
nested (e.g. a client has to run the remote access scenario to get
into the corporate network, and within that IPsec-protected
connection it can run another IPsec connection between the client and
the intended server.
[Note: In this version of the draft, the information on these
scenarios is intentionally sparse. While this tries to call out key
characteristics, further analysis is needed to determine if the
categories are sufficient. Need to decide how SCTP should be
integrated with these scenarios. May need discussion of QoS in
certain scenarios.]
A.1. Virtual Private Network Site-to-Site Tunnels
* Operational Characteristics: VPN Site-to-Site Tunnels are between
two devices acting as Security Gateways (SGWs). IPsec can either
directly encapsulate the IP traffic that it will secure, or it can
secure another tunneling protocol (e.g. IPinIP) running between the
two SGWs that has already encapsulated the data.
A pair of SGWs can support several simultaneous IPsec tunnels in
between them. These tunnels can have the same or different
protection.
* Policy: In many cases, in order to ensure common policy on the
SGWs, the SGWs need to be configured/provisioned. However, policy
discovery mechanisms are also desirable.
* NAT: The IPsec connection may be NAT'd between the SGWs. The
traffic inside the IPsec connection may also be NAT'd by one of the
SGWs.
* Dynamic Addresses: In many cases one of the SGWs may have a
dynamically-assigned address. If both SGWs have dynamically-assigned
addresses, at least one requires a fixed DNS name where the DNS entry
is updated appropriately.
* Authentication: Machine-level only.
A.2. Secure Remote Access
* Operational Characteristics: When the client is outside the
protected network that it needs to access, it will have to interact
with a Remote Access Server (RAS) in order to access that network.
In many cases, the Secure Remote Access scenario is replacing a
remote access scenario that uses dial-up access to reach a network.
The client would dial up to the Remote Access Server (RAS) and
interact with the RAS to perform user-level authentication (e.g.
Madson [Page 10]
INTERNET DRAFT November 2001 Expires May 2002
userid/password, SecureID, etc.). If the authentication is
successful, the RAS would permit access to that network, and may also
push down configuration information to the client.
In the Secure Remote Access case, before the IPsec tunnel is
constructed between the client and the RAS, the client must first
authenticate itself (most likely using legacy authentication
mechanisms). The IPsec connection will most likely operate in tunnel
mode.
The entity that supplies the RAS typically requires a great deal of
accounting of connections and resources consumed, in order to do
capacity planning.
* Policy: In many scenarios, there is a need to download policy
information from the RAS to the client. [Note: are both policy pull
(client request) and policy push (server push to client) models
supported?]
* NAT: The outside IPsec connection may be NAT'd between the client
and the SGW. If an internal address is assigned to the client, there
should be no need for the RAS to perform NAT translation on the
traffic that is sent/received in the IPsec connection.
* Dynamic Addresses: The client will have a dynamically assigned
outside IP address assigned from its local POP. In many cases it will
get an internal address assigned by the RAS so that the RAS will not
have to NAT translate the traffic. The client could request this
address, or the RAS could push it down along with other configuration
information needed by the client (info on how to reach the inside DNS
server, etc.).
The RAS will typically have a static IP address (or at least a static
DNS name, where the DNS entry is updated appropriately).
* Authentication: In many cases (e.g. the Internet Kiosk), machine-
level authentication becomes meaningless. In other cases (e.g., a
remote laptop) both machine-level authentication and user-level
authentication are valuable. However, there is a strong requirement
for user-level authentication, requiring some amount of user
interaction. The user- level authentication is mainly done via legacy
authentication mechanisms (e.g. SecureID, userid/password, etc.).
A.3. End-to-End Security
What this scenario attempts to describe is the characteristics
associated with the common end-to-end scenarios. The primary
definition of end-to-end here is that the traffic sourced by/destined
to a pair of nodes is secured by those nodes.
The most common "end-to-end" scenario is an IPsec connection between
two workstations. "End-to-end" can also apply to securing a network
management path between the management station and a router.
Madson [Page 11]
INTERNET DRAFT November 2001 Expires May 2002
However the "end-to-end" concept can be applied to a lot of different
scenarios that may have additional requirements. For example,
securing OSPF traffic between OSPF neighbors requires a system to
share a key amongst its neighbors on a link, as it doesn't explicitly
learn about its neighbors until it runs the OSPF "hello" protocol.
Scenarios with special requirements should be called out separately.
* Operational Characteristics: An IPsec "connection" is used to
secure traffic between the two IP endpoints for that traffic. The
granularity of the connection may be an individual socket, or all
traffic between the two systems. If multiple connections exist, they
can have the same or different protections. The IPsec connection can
operate in either tunnel or transport mode.
* Policy: In some cases this is pre-configured/provisioned. However,
policy discovery mechanisms are desirable here.
* NAT: The IPsec connection may undergo NAT translation. The traffic
within the IPsec connection most likely will not be NAT'd.
* Dynamic Addresses: It's possible for one node to have a dynamic
address. In most cases the other node will have a fixed address, or
at least a fixed DNS name, where the DNS entry is updated
appropriately.
* Authentication: In many cases, machine-level authentication is
desirable and sufficient.
In some cases, such as client-to-server connections, user-level
authentication may also be necessary. User-level authentication via
legacy mechanisms is currently outside the scope of IKE. However, it
may be desirable to have such user authentication happen before IPsec
connections could be established, similar to what happens in the
remote access scenario. User-level authentication can also be done
via user credentials that can be easily passed in IKE phase 1 (e.g.
X.509 user certificates).
A.4. Mobile IP
[No doubt there are gaps in this particular scenario...]
* Operational Characteristics: IPsec is used to secure a Mobile IP
tunnel (which has its own encapsulation). In some ways this scenario
is like a remote access scenario. The IPsec connection can operate in
either tunnel or transport mode. IPsec is also used to secure the
Binding Update messages.
* Policy: Most likely pre-configured/provisioned while the mobile
user is on the home network.
* NAT: The IPsec connection may be NAT'd. The traffic carried by the
IPsec connection most likely will not be NAT'd.
Madson [Page 12]
INTERNET DRAFT November 2001 Expires May 2002
* Dynamic Addresses: The mobile node will have a dynamic address. In
fact, it will have several different ones over a period of time.
* Authentication: Depending upon the environment, the mobile device
may be required to authenticate to a local node that gives it
permission to access the local media; such authentication is outside
the scope of IKE/IPsec.
In many environments, machine authentication for IKE will be
sufficient, in that the user must possess a mobile node device that
has the appropriate credentials already pre-installed as a part of
initial provisioning.
Madson [Page 13]
