From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4101.txt | 1235 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1235 insertions(+) create mode 100644 doc/rfc/rfc4101.txt (limited to 'doc/rfc/rfc4101.txt') diff --git a/doc/rfc/rfc4101.txt b/doc/rfc/rfc4101.txt new file mode 100644 index 0000000..f97b129 --- /dev/null +++ b/doc/rfc/rfc4101.txt @@ -0,0 +1,1235 @@ + + + + + + +Network Working Group E. Rescorla +Request for Comments: 4101 RTFM, Inc. +Category: Informational IAB + June 2005 + + Writing Protocol Models + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + The IETF process depends on peer review. However, IETF documents are + generally written to be useful for implementors, not reviewers. In + particular, while great care is generally taken to provide a complete + description of the state machines and bits on the wire, this level of + detail tends to get in the way of initial understanding. This + document describes an approach for providing protocol "models" that + allow reviewers to quickly grasp the essence of a system. + +1. Introduction + + The IETF process depends on peer review. However, in many cases, the + documents submitted for publication are extremely difficult to + review. Because reviewers have only limited amounts of time, this + leads to extremely long review times, inadequate reviews, or both. + In our view, a large part of the problem is that most documents fail + to present an architectural model for how the protocol operates, + opting instead to simply describe the protocol and let the reviewer + figure it out. + + This is acceptable when documenting a protocol for implementors, + because they need to understand the protocol in any case; but it + dramatically increases the strain on reviewers. Reviewers need to + get the big picture of the system and then focus on particular + points. They simply do not have time to give the entire document the + attention an implementor would. + + + + + + + +Rescorla Informational [Page 1] + +RFC 4101 Writing Protocol Models June 2005 + + + One way to reduce this load is to present the reviewer with a + MODEL -- a short description of the system in overview form. This + provides the reviewer with the context to identify the important or + difficult pieces of the system and focus on them for review. As a + side benefit, if the model is done first, it can be serve as an aid + to the detailed protocol design and a focus for early review, prior + to protocol completion. The intention is that the model would either + be the first section of the protocol document or be a separate + document provided with the protocol. + +2. The Purpose of a Protocol Model + + A protocol model needs to answer three basic questions: + + 1. What problem is the protocol trying to achieve? + 2. What messages are being transmitted and what do they mean? + 3. What are the important, but unobvious, features of the protocol? + + The basic idea is to provide enough information that the reader could + design a protocol which was roughly isomorphic to the protocol being + described. Of course, this doesn't mean that the protocol would be + identical, but merely that it would share most important features. + For instance, the decision to use a KDC-based authentication model is + an essential feature of Kerberos [KERBEROS]. By contrast, the use of + ASN.1 is a simple implementation decision. S-expressions -- or XML, + had it existed at the time -- would have served equally well. + + The purpose of a protocol model is explicitly not to provide a + complete or alternate description of the protocol being discussed. + Instead, it is to provide a big picture overview of the protocol so + that readers can quickly understand the essential elements of how it + works. + +3. Basic Principles + + In this section we discuss basic principles that should guide your + presentation. + +3.1. Less is more + + Humans are only capable of keeping a very small number of pieces of + information in their head at once. Because we're interested in + ensuring that people get the big picture, we have to dispense with a + lot of detail. That's good, not bad. The simpler you can make + things the better. + + + + + + +Rescorla Informational [Page 2] + +RFC 4101 Writing Protocol Models June 2005 + + +3.2. Abstraction is good + + A key technique for representing complex systems is to try to + abstract away pieces. For instance, maps are better than photographs + for finding out where you want to go because they provide an + abstract, stylized, view of the information you're interested in. + Don't be afraid to compress multiple protocol elements into a single + abstract piece for pedagogical purposes. + +3.3. A few well-chosen details sometimes help + + The converse of the previous principle is that sometimes details help + to bring a description into focus. Many people work better when + given examples. Thus, it's often a good approach to talk about the + material in the abstract and then provide a concrete description of + one specific piece to bring it into focus. Authors should focus on + the normal path. Error cases and corner cases should only be + discussed where they help illustrate an important point. + +4. Writing Protocol Models + + Our experience indicates that it is easiest to grasp protocol models + when they are presented in visual form. We recommend a presentation + format centered around a few key diagrams, with explanatory text for + each. These diagrams should be simple and typically consist of + "boxes and arrows" -- boxes representing the major components, arrows + representing their relationships, and labels indicating important + features. + + We recommend a presentation structured in three parts to match the + three questions mentioned in the previous sections. Each part should + contain 1-3 diagrams intended to illustrate the relevant points. + +4.1. Describe the problem you're trying to solve + + The most critical task that a protocol model must perform is to + explain what the protocol is trying to achieve. This provides + crucial context for understanding how the protocol works, and whether + it meets its goals. Given the desired goals, an experienced reviewer + will usually have an idea of how they would approach the problem and, + thus, be able to compare that approach with the approach taken by the + protocol under review. + + The "Problem" section of the model should start with a short + statement of the environments in which the protocol is expected to be + used. This section should describe the relevant entities and the + likely scenarios under which they would participate in the protocol. + The Problem section should feature a diagram of the major + + + +Rescorla Informational [Page 3] + +RFC 4101 Writing Protocol Models June 2005 + + + communicating parties and their inter-relationships. It is + particularly important to lay out the trust relationships between the + various parties, as these are often unobvious. + +4.1.1. Example: STUN (RFC 3489) + + STUN [STUN] is a UNilateral Self-Address Fixing (UNSAF) [UNSAF] + protocol that allows a machine located behind a NAT to determine what + its external apparent IP address is. Although STUN provides a + complete and thorough description of the operation of the protocol, + it does not provide a brief, up-front overview suitable for a quick + understanding of its operation. The rest of this section shows what + a suitable overview might look like. + + Network Address Translation (NAT) makes it difficult to run a number + of classes of service from behind the NAT gateway. This is + particularly a problem when protocols need to advertise address/port + pairs as part of the application layer protocol. Although the NAT + can be configured to accept data destined for that port, address + translation means the address that the application knows about is not + the same as the one on which it is reachable. + + Consider the scenario represented in the figure below. A SIP client + is initiating a session with a SIP server in which it wants the SIP + server to send it some media. In its Session Description Protocol + (SDP) [SDP] request it provides the IP address and port on which it + is listening. However, unbeknownst to the client, a NAT is in the + way. The NAT translates the IP address in the header, but unless it + is SIP aware, it doesn't change the address in the request. The + result is that the media goes into a black hole. + + + + + + + + + + + + + + + + + + + + + +Rescorla Informational [Page 4] + +RFC 4101 Writing Protocol Models June 2005 + + + +-----------+ + | SIP | + | Server | + | | + +-----------+ + ^ + | [FROM: 198.203.2.1:8954] + | [MSG: SEND MEDIA TO 10.0.10.5:6791] + | + | + +-----------+ + | | + | NAT | + --------------+ Gateway +---------------- + | | + +-----------+ + ^ + | [FROM: 10.0.10.5:6791] + | [MSG: SEND MEDIA TO 10.0.10.5:6791] + | + 10.0.10.5 + +-----------+ + | SIP | + | Client | + | | + +-----------+ + + The purpose of STUN is to allow clients to detect this situation and + determine the address mapping. They can then place the appropriate + address in their application-level messages. This is done by using + an external STUN server. That server is able to determine the + translated address and tell the STUN client, as shown below. + + + + + + + + + + + + + + + + + + + +Rescorla Informational [Page 5] + +RFC 4101 Writing Protocol Models June 2005 + + + +-----------+ + | STUN | + | Server | + | | + +-----------+ + ^ | + [IP HDR FROM: 198.203.2.1:8954] | | [IP HDR TO: 198.203.2.1:8954] + [MSG: WHAT IS MY ADDRESS?] | | [MSG: YOU ARE 198.203.2.1:8954] + | v + +-----------+ + | | + | NAT | + --------------+ Gateway +---------------- + | | + +-----------+ + ^ | + [IP HDR FROM: 10.0.10.5:6791] | | [IP HDR TO: 10.0.10.5:6791] + [MSG: WHAT IS MY ADDRESS?] | | [MSG: YOU ARE 198.203.2.1:8954] + | v + 10.0.10.5 + +-----------+ + | SIP | + | Client | + | | + +-----------+ + +4.2. Describe the protocol in broad overview + + Once the problem has been described, the next task is to give a broad + overview of the protocol. This means showing, either in "ladder + diagram" or "boxes and arrows" form, the protocol messages that flow + between the various networking agents. This diagram should be + accompanied with explanatory text that describes the purpose of each + message and the MAJOR data elements. + + This section SHOULD NOT contain detailed descriptions of the + protocol messages or of each data element. In particular, bit + diagrams, ASN.1 modules, and XML schema SHOULD NOT be shown. The + purpose of this section is not to provide a complete + description of the protocol, but to provide enough of a + map that a person reading the full protocol document can see + where each specific piece fits. + + In certain cases, it may be helpful to provide a state machine + description of the behavior of network elements. However, such + state machines should be kept as minimal as possible. Remember that + the purpose is to promote high-level comprehension, not complete + understanding. + + + +Rescorla Informational [Page 6] + +RFC 4101 Writing Protocol Models June 2005 + + +4.2.1. Example: DCCP + + Datagram Congestion Control Protocol [DCCP] is a protocol for + providing datagram transport with network-friendly congestion + avoidance behavior. The DCCP base protocol document is over 100 + pages long and the congestion control mechanisms themselves are + separate. Therefore, it is very helpful to have a an architectural + overview of DCCP that abstracts away the details. The remainder of + this section is an attempt to do so. + + NOTE: The author of this document was on the DCCP review team and + his experience with that document was one of the motivating factors + for this document. Since the review, the DCCP authors have added + some overview material, some of which derives from earlier versions + of this document. + + Although DCCP is datagram-oriented like UDP, it is stateful + like TCP. Connections go through the following phases: + + 1. Initiation + 2. Feature negotiation + 3. Data transfer + 4. Termination + +4.2.1.1. Initiation + + As with TCP, the initiation phase of DCCP involves a three-way + handshake, shown below. + + Client Server + ------ ------ + DCCP-Request -> + [Ports, Service, + Features] + <- DCCP-Response + [Features, + Cookie] + DCCP-Ack -> + [Features, + Cookie] + + DCCP 3-way handshake + + In the DCCP-Request message, the client tells the server the name of + the service it wants to talk to and the ports it wants to communicate + on. Note that ports are not tightly bound to services, as they are + in TCP or UDP common practice. It also starts feature negotiation. + For pedagogical reasons, we will present feature negotiation + + + +Rescorla Informational [Page 7] + +RFC 4101 Writing Protocol Models June 2005 + + + separately in the next section. However, realize that the early + phases of feature negotiation happen concurrently with initiation. + + In the DCCP-Response message, the server tells the client that it is + willing to accept the connection and continues feature negotiation. + In order to prevent SYN flood-style DOS attacks, DCCP incorporates an + IKE-style cookie exchange. The server can provide the client with a + cookie that contains all of the negotiation state. This cookie must + be echoed by the client in the DCCP-Ack, thus removing the need for + the server to keep state. + + In the DCCP-Ack message, the client acknowledges the DCCP-Response + and returns the cookie to permit the server to complete its side of + the connection. As indicated above, this message may also include + feature negotiation messages. + +4.2.1.2. Feature Negotiation + + In DCCP, feature negotiation is performed by attaching options to + other DCCP packets. Thus, feature negotiation can be piggybacked on + any other DCCP message. This allows feature negotiation during + connection initiation as well as during data flow. + + Somewhat unusually, DCCP features are one-sided. Thus, it's possible + to have a different congestion control regime for data sent from + client to server than from server to client. + + Feature negotiation is done with the Change and Confirm options. + There are four feature negotiation options in all: Change L, Confirm + L, Change R, and Confirm R. The "L" options are sent by the feature + location, where the feature is maintained, and the "R" options are + sent by the feature remote. + + A Change R message says to the peer "change this option setting on + your side". The peer can respond with a Confirm L, meaning "I've + changed it". Some features allow Change R options to contain + multiple values, sorted in preference order. For example: + + Client Server + ------ ------ + Change R(CCID, 2) --> + <-- Confirm L(CCID, 2) + * agreement that CCID/Server = 2 * + + Change R(CCID, 3 4) --> + <-- Confirm L(CCID, 4, 4 2) + * agreement that CCID/Server = 4 * + + + + +Rescorla Informational [Page 8] + +RFC 4101 Writing Protocol Models June 2005 + + + In the second exchange, the client requests that the server use + either CCID 3 or CCID 4, with 3 preferred. The server chooses 4 and + supplies its preference list, "4 2". + + The Change L and Confirm R options are used for feature negotiations + that are initiated by the feature location. In the following + example, the server requests that CCID/Server be set to 3 or 2 (with + 3 being preferred), and the client agrees. + + Client Server + ------ ------ + <-- Change L(CCID, 3 2) + Confirm R(CCID, 3, 3 2) --> + * agreement that CCID/Server = 3 * + +4.2.1.3. Data Transfer + + Rather than have a single congestion control regime, as in TCP, DCCP + offers a variety of negotiable congestion control regimes. The DCCP + documents describe two congestion control regimes: additive increase, + multiplicative decrease (CCID-2 [CCID2]), and TCP-friendly rate + control (CCID-3 [CCID3]). CCID-2 is intended for applications that + want maximum throughput. CCID-3 is intended for real-time + applications that want smooth response to congestion. + +4.2.1.3.1. CCID-2 + + CCID-2's congestion control is extremely similar to that of TCP. The + sender maintains a congestion window and sends packets until that + window is full. Packets are Acked by the receiver. Dropped packets + and ECN [ECN] are used to indicate congestion. The response to + congestion is to halve the congestion window. One subtle difference + between DCCP and TCP is that the Acks in DCCP must contain the + sequence numbers of all received packets (within a given window), not + just the highest sequence number, as in TCP. + +4.2.1.3.2. CCID-3 + + CCID-3 is an equation-based form of rate control, intended to provide + smoother response to congestion than CCID-2. The sender maintains a + "transmit rate". The receiver sends Ack packets that contain + information about the receiver's estimate of packet loss. The sender + uses this information to update its transmit rate. Although CCID-3 + behaves somewhat differently than TCP in its short-term congestion + response, it is designed to operate fairly with TCP over the long + term. + + + + + +Rescorla Informational [Page 9] + +RFC 4101 Writing Protocol Models June 2005 + + +4.2.1.4. Termination + + Connection termination in DCCP is initiated by sending a Close + message. Either side can send a Close message. The peer then + responds with a Reset message, at which point the connection is + closed. The side that sent the Close message must quietly preserve + the socket in TIMEWAIT state for 2MSL. + + Client Server + ------ ------ + Close -> + <- Reset + [Remains in TIMEWAIT] + + Note that the server may wish to close the connection but not remain + in TIMEWAIT (e.g., due to a desire to minimize server-side state). + In order to accomplish this, the server can elicit a Close from the + client by sending a CloseReq message and, thus, keep the TIMEWAIT + state on the client. + +4.3. Describe any important protocol features + + The final section (if there is one) should contain an explanation of + any important protocol features that are not obvious from the + previous sections. In the best case, all the important features of + the protocol would be obvious from the message flow. However, this + isn't always the case. This section is an opportunity for the author + to explain those features. Authors should think carefully before + writing this section. If there are no important points to be made, + they should not populate this section. + + Examples of the kind of feature that belongs in this section include: + high-level security considerations, congestion control information, + and overviews of the algorithms that the network elements are + intended to follow. For instance, if you have a routing protocol, + you might use this section to sketch out the algorithm that the + router uses to determine the appropriate routes from protocol + messages. + +4.3.1. Example: WebDAV COPY and MOVE + + The WebDAV standard [WEBDAV] is fairly terse, preferring to define + the required behaviors and let the reader work out the implications. + In some situations, explanatory material that details those + implications can help the reader understand the overall model. The + rest of this section describes one such case. + + + + + +Rescorla Informational [Page 10] + +RFC 4101 Writing Protocol Models June 2005 + + + 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. + + + + + + + + + + + +Rescorla Informational [Page 11] + +RFC 4101 Writing Protocol Models June 2005 + + +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). + + + + + + + +Rescorla Informational [Page 12] + +RFC 4101 Writing Protocol Models June 2005 + + +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. + + + + + + + + + + + + + + + + + +Rescorla Informational [Page 13] + +RFC 4101 Writing Protocol Models June 2005 + + +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. + + + + + + + + + + +Rescorla Informational [Page 14] + +RFC 4101 Writing Protocol Models June 2005 + + +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. + + + +Rescorla Informational [Page 15] + +RFC 4101 Writing Protocol Models June 2005 + + + 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) + + + +Rescorla Informational [Page 16] + +RFC 4101 Writing Protocol Models June 2005 + + + 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. + + + + + + + + + + +Rescorla Informational [Page 17] + +RFC 4101 Writing Protocol Models June 2005 + + + 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. + + + +Rescorla Informational [Page 18] + +RFC 4101 Writing Protocol Models June 2005 + + +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. + + + + + + + + + + + + + + + + + + + + + + + + + + +Rescorla Informational [Page 19] + +RFC 4101 Writing Protocol Models June 2005 + + +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. + + + + + +Rescorla Informational [Page 20] + +RFC 4101 Writing Protocol Models June 2005 + + + [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. + + [SYNFLOOD] CERT Advisory CA-1996-21 TCP SYN Flooding and IP Spoofing + Attacks , + September 19, 1996. + + [UNSAF] Daigle, L. and IAB, "IAB Considerations for UNilateral + Self-Address Fixing (UNSAF) Across Network Address + Translation", RFC 3424, November 2002. + + [WEBDAV] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. + Jensen, "HTTP Extensions for Distributed Authoring -- + WEBDAV", RFC 2518, February 1999. + +Authors' Addresses + + Eric Rescorla + RTFM, Inc. + 2064 Edgewood Drive + Palo Alto, CA 94303 + + Phone: (650)-320-8549 + EMail: ekr@rtfm.com + + + Internet Architecture Board + IAB + + EMail: iab@iab.org + + + + + + + + + + + +Rescorla Informational [Page 21] + +RFC 4101 Writing Protocol Models June 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Rescorla Informational [Page 22] + -- cgit v1.2.3