implications can help the reader understand the overall model. The
rest of this section describes one such case.
WebDAV [WEBDAV] includes both a COPY method and a MOVE method. While
a MOVE can be thought of as a COPY followed by DELETE, COPY+DELETE
and MOVE aren’t entirely equivalent.
The use of COPY+DELETE as a substitute for MOVE is problematic
because of the creation of the intermediate file. Consider the case
where the user is approaching a quota boundary. A COPY+DELETE should
be forbidden because it would temporarily exceed the quota. However,
a simple rename should work in this situation.
The second issue is permissions. The WebDAV permissions model allows
the server to grant users permission to rename files, but not to
create new ones. This is unusual in ordinary filesystems, but
nothing prevents it in WebDAV. This is clearly not possible if a
client uses COPY+DELETE to do a MOVE.
Finally, a COPY+DELETE does not produce the same logical result as
would be expected with a MOVE. Because COPY creates a new resource,
it is permitted (but not required) to use the time of new file
creation as the creation date property. By contrast, the expectation
for MOVE is that the renamed file will have the same properties as
the original.
5. Formatting Issues
The requirement that Internet-Drafts and RFCs be renderable in ASCII
is a significant obstacle when writing the sort of graphics-heavy
document being described here. Authors may find it more convenient
to do a separate protocol model document in Postscript or PDF and
simply make it available at review time -- though an archival version
would certainly be handy.
6. A Complete Example: Internet Key Exchange (IKE)
Internet Key Exchange (IKE) [IKE] is one of the most complicated
security protocols ever designed by the IETF. Although the basic IKE
core is a fairly straightforward Diffie-Hellman-based handshake, this
can often be difficult for new readers to understand abstractly,
apart from the protocol details. The remainder of this section
provides overview of IKE suitable for those new readers.
6.1. Operating Environment
Internet key Exchange (IKE) [IKE] is a key establishment and
parameter negotiation protocol for Internet protocols. Its primary
application is for establishing security associations (SAs) [IPSEC]
for IPsec AH [AH] and ESP [ESP].
+--------------------+ +--------------------+
| | | |
| +------------+ | | +------------+ |
| | Key | | IKE | | Key | |
| | Management | <-+-----------------------+-> | Management | |
| | Process | | | | Process | |
| +------------+ | | +------------+ |
| ^ | | ^ |
| | | | | |
| v | | v |
| +------------+ | | +------------+ |
| | IPsec | | AH/ESP | | IPsec | |
| | Stack | <-+-----------------------+-> | Stack | |
| | | | | | | |
| +------------+ | | +------------+ |
| | | |
| | | |
| Initiator | | Responder |
+--------------------+ +--------------------+
The general deployment model for IKE is shown above. The IPsec
engines and IKE engines typically are separate modules. When no
security association exists for a packet that needs to be processed
(either sent or received), the IPsec engine contacts the IKE engine
and asks it to establish an appropriate SA. The IKE engine contacts
the appropriate peer and uses IKE to establish the SA. Once the IKE
handshake is finished it registers the SA with the IPsec engine.
In addition, IKE traffic between the peers can be used to refresh
keying material or adjust operating parameters, such as algorithms.
6.1.1. Initiator and Responder
Although IPsec is basically symmetrical, IKE is not. The party who
sends the first message is called the INITIATOR. The other party is
called the RESPONDER. In the case of TCP connections, the INITIATOR
will typically be the peer doing the active open (i.e., the client).
6.1.2. Perfect Forward Secrecy
One of the major concerns in IKE design was that traffic be protected
even if the keying material of the nodes was later compromised,
provided that the session in question had terminated and so the
session-specific keying material was gone. This property is often
called Perfect Forward Secrecy (PFS) or back traffic protection.
6.1.3. Denial of Service Resistance
Because IKE allows arbitrary peers to initiate computationally-
expensive cryptographic operations, it potentially allows resource
consumption denial of service (DoS) attacks to be mounted against the
IKE engine. IKE includes countermeasures designed to minimize this
risk.
6.1.4. Keying Assumptions
Because Security Associations are essentially symmetric, both sides
must, in general, be authenticated. Because IKE needs to be able to
establish SAs between a broad range of peers with various kinds of
prior relationships, IKE supports a very flexible keying model.
Peers can authenticate via shared keys, digital signatures (typically
from keys vouched for by certificates), or encryption keys.
6.1.5. Identity Protection
Although IKE requires the peers to authenticate to each other, it was
considered desirable by the working group to provide some identity
protection for the communicating peers. In particular, the peers
should be able to hide their identity from passive observers and one
peer should be able to require the author to authenticate before they
self-identity. In this case, the designers chose to make the party
who speaks first (the INITIATOR) identify first.
6.2. Protocol Overview
At a very high level, there are two kinds of IKE handshake:
(1) Those that establish an IKE security association.
(2) Those that establish an AH or ESP security association.
When two peers that have never communicated before need to establish
an AH/ESH SA, they must first establish an IKE SA. This allows them
to exchange an arbitrary amount of protected IKE traffic. They can
then use that SA to do a second handshake to establish SAs for AH and
ESP. This process is shown in schematic form below. The notation
E(SA,XXXX) is used to indicate that traffic is encrypted under a
given SA.
Initiator Responder
--------- ---------
Handshake MSG -> \ Stage 1:
<- Handshake MSG \ Establish IKE
/ SA (IKEsa)
[...] /
\ Stage 2:
E(IKEsa, Handshake MSG) -> \ Establish AH/ESP
<- E(IKEsa, Handshake MSG) / SA
The two kinds of IKE handshake
IKE terminology is somewhat confusing, referring under different
circumstances to "phases" and "modes". For maximal clarity we will
refer to the Establishment of the IKE SA as "Stage 1" and the
Establishment of AH/ESP SAs as "Stage 2". Note that it’s quite
possible for there to be more than one Stage 2 handshake, once Stage
1 has been finished. This might be useful for establishing multiple
AH/ESP SAs with different cryptographic properties.
The Stage 1 and Stage 2 handshakes are actually rather different,
because the Stage 2 handshake can, of course, assume that its traffic
is being protected with an IKE SA. Accordingly, we will first
discuss Stage 1 and then Stage 2.
6.2.1. Stage 1
There are a large number of variants of the IKE Stage 1 handshake,
necessitated by use of different authentication mechanisms. However,
broadly speaking Stage 1 handshakes fall into one of two basic
categories: MAIN MODE, which provides identity protection and DoS
resistance, and AGGRESSIVE MODE, which does not. We will cover MAIN
MODE first.
6.2.1.1. Main Mode
Main Mode is a six message (3 round trip) handshake, which offers
identity protection and DoS resistance. An overview of the handshake
is below.
Initiator Responder
--------- ---------
CookieI, Algorithms -> \ Parameter
<- CookieR, Algorithms / Establishment
CookieR,
Nonce, Key Exchange ->
<- Nonce, Key Exchange\ Establish
/ Shared key
E(IKEsa, Auth Data) ->
<- E(IKEsa, Auth data)\ Authenticate
/ Peers
IKE Main Mode handshake (Stage 1)
In the first round trip, the Initiator offers a set of algorithms and
parameters. The Responder picks out the single set that it likes and
responds with that set. It also provides CookieR, which will be used
to prevent DoS attacks. At this point, there is no secure
association but the peers have tentatively agreed upon parameters.
These parameters include a Diffie-Hellman (DH) group, which will be
used in the second round trip.
In the second round trip, the Initiator sends the key exchange
information. This generally consists of the Initiator’s Diffie-
Hellman public share (Yi). He also supplies CookieR, which was
provided by the responder. The Responder replies with his own DH
share (Yr). At this point, both Initiator and Responder can compute
the shared DH key (ZZ). However, there has been no authentication
and, therefore, they don’t know with any certainty that the
connection hasn’t been attacked. Note that as long as the peers
generate fresh DH shares for each handshake, PFS will be provided.
Before we move on, let’s take a look at the cookie exchange. The
basic anti-DoS measure used by IKE is to force the peer to
demonstrate that it can receive traffic from you. This foils blind
attacks like SYN floods [SYNFLOOD] and also makes it somewhat easier
to track down attackers. The cookie exchange serves this role in
IKE. The Responder can verify that the Initiator supplied a valid
CookieR before doing the expensive DH key agreement. This does not
totally eliminate DoS attacks, because an attacker who was willing to
reveal his location could still consume server resources; but it does
protect against a certain class of blind attack.
In the final round trip, the peers establish their identities.
Because they share an (unauthenticated) key, they can send their
identities encrypted, thus providing identity protection from
eavesdroppers. The exact method of proving identity depends on what
form of credential is being used (signing key, encryption key, shared
secret, etc.), but in general you can think of it as a signature over
some subset of the handshake messages. So, each side would supply
its certificate and then sign using the key associated with that
certificate. If shared keys are used, the authentication data would
be a key ID and a MAC. Authentication using public key encryption
follows similar principles, but is more complicated. Refer to the
IKE document for more details.
At the end of the Main Mode handshake, the peers share:
(1) A set of algorithms for encryption of further IKE traffic.
(2) Traffic encryption and authentication keys.
(3) Mutual knowledge of the peer’s identity.
6.2.1.2. Aggressive Mode
Although IKE Main Mode provides the required services, there was
concern that the large number of round trips required added,
excessive latency. Accordingly, an Aggressive Mode was defined.
Aggressive mode packs more data into fewer messages, and thus reduces
latency. However, it does not provide identity protection or
protection against DoS.
Initiator Responder
--------- ---------
Algorithms, Nonce,
Key Exchange, ->
<- Algorithms, Nonce,
Key Exchange, Auth Data
Auth Data ->
IKE Aggressive Mode Handshake (Stage 1)
After the first round trip, the peers have all the required
properties, but the Initiator has not authenticated to the Responder.
The third message closes the loop by authenticating the Initiator.
Note that since the authentication data is sent in the clear, no
identity protection is provided; and because the Responder does the
DH key agreement without a round trip to the Initiator, there is no
DoS protection
6.2.2. Stage 2
Stage 1 on its own isn’t very useful. The purpose of IKE, after all,
is to establish associations to be used to protect other traffic, not
merely to establish IKE SAs. Stage 2 (what IKE calls "Quick Mode")
is used for this purpose. The basic Stage 2 handshake is shown
below.
Initiator Responder
--------- ---------
AH/ESP parameters,
Algorithms, Nonce,
Handshake Hash ->
<- AH/ESP parameters,
Algorithms, Nonce,
Handshake Hash
Handshake Hash ->
The Basic IKE Quick Mode (Stage 2)
As with quick mode, the first two messages establish the algorithms
and parameters while the final message is a check over the previous
messages. In this case, the parameters also include the transforms
to be applied to the traffic (AH or ESP) and the kinds of traffic
that are to be protected. Note that there is no key exchange
information shown in these messages.
In this version of Quick Mode, the peers use the preexisting Stage 1
keying material to derive fresh keying material for traffic
protection (with the nonces to ensure freshness). Quick mode also
allows for a new Diffie-Hellman handshake for per-traffic key PFS.
In that case, the first two messages shown above would also include
Key Exchange payloads, as shown below.
Initiator Responder
--------- ---------
AH/ESP parameters,
Algorithms, Nonce,
Key Exchange, ->
Handshake Hash
<- AH/ESP parameters,
Algorithms, Nonce,
Key Exchange,
Handshake Hash
Handshake Hash ->
A Variant of Quick Mode with PFS (Stage 2)
6.3. Other Considerations
There are a number of features of IKE that deserve special
consideration. They are discussed here.
6.3.1. Cookie Generation
As mentioned previously, IKE uses cookies as a partial defense
against DoS attacks. When the responder receives Main Mode message 3
containing the Key Exchange data and the cookie, it verifies that the
cookie is correct. However, this verification must not involve
having a list of valid cookies. Otherwise, an attacker could
potentially consume arbitrary amounts of memory by repeatedly
requesting cookies from a responder. The recommended way to generate
a cookie, as suggested by Phil Karn, is to have a single master key
and compute a hash of the secret and the initiator’s address
information. This cookie can be verified by recomputing the cookie
value based on information in the third message, and seeing if it
matches.
6.3.2. Endpoint Identities
So far we have been rather vague about what kinds of endpoint
identities are used. In principle, there are three ways a peer might
be identified: by a shared key, a pre-configured public key, or a
certificate.
6.3.2.1. Shared Key
In a shared key scheme, the peers share a symmetric key. This key is
associated with a key identifier, which is known to both parties. It
is assumed that the party verifying that identity also has a table
that indicates for which traffic (i.e., what addresses) that identity
is allowed to negotiate SAs.
6.3.2.2. Pre-Configured Public Key
A pre-configured public key scheme is the same as a shared key scheme
except that the verifying party has the authenticating party’s public
key instead of a shared key.
6.3.2.3. Certificate
In a certificate scheme, the authenticating party presents a
certificate containing their public key. It is straightforward to
establish that this certificate matches the authentication data
provided by the peer. What is less straightforward is to determine
whether a given peer is entitled to negotiate for a given class of
traffic. In theory, one might be able to determine this from the
name in the certificate (e.g., the subject name contains an IP
address that matches the ostensible IP address). In practice, this
is not clearly specified in IKE and, therefore, is not really
interoperable. Currently, it is likely that a configuration table
maps certificates to policies, as in the other two authentication
schemes.
7. Security Considerations
This document does not define any protocols and therefore has no
security issues.
A. Appendix: IAB Members at the Time of This Writing
Bernard Aboba
Harald Alvestrand
Rob Austein
Leslie Daigle
Patrik Falstrom
Sally Floyd
Jun-ichiro Itojun Hagino
Mark Handley
Bob Hinden
Geoff Huston
Eric Rescorla
Pete Resnick
Jonathan Rosenberg
Normative References
There are no normative references for this document.
Informative References
[AH] Kent, S., and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998.
[CCID2] Floyd, S. and E. Kohler, "Profile for DCCP Congestion
Control ID 2: TCP-like Congestion Control", Work in
Progress, October 2003.
[CCID3] Floyd, S., Kohler, E., and J. Padhye, "Profile for DCCP
Congestion Control ID 3: TFRC Congestion Control", Work in
Progress, February 2004.
[DCCP] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", Work in Progress,
November 2004.
[ECN] Ramakrishnan, K. Floyd, S., and D. Black, "The Addition of
Explicit Congestion Notification (ECN) to IP", RFC 3168,
September 2001.
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[IPSEC] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[KERBEROS] Kohl, J. and C. Neuman, "The Kerberos Network
Authentication Service (V5)", RFC 1510, September 1993.
[SDP] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol" RFC 2327, April 1998.
[STUN] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP)",
RFC 3489, March 2003.