idnits 2.17.1 draft-iab-model-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. == There is 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There is 6 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 243: '... This section SHOULD NOT contain det...' RFC 2119 keyword, line 245: '...s and XML schema SHOULD NOT be shown. ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 169 has weird spacing: '...request it pr...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'REF' is mentioned on line 435, but not defined == Missing Reference: 'SYNFLOOD' is mentioned on line 596, but not defined == Unused Reference: 'TODO' is defined on line 747, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'TODO' Summary: 11 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 E. Rescorla 3 RTFM, Inc. 4 INTERNET-DRAFT IAB 5 draft-iab-model-00.txt October 2003 (Expires April 2004) 7 Writing Protocol Models 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference mate- 20 rial or to cite them other than as ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Abstract 30 The IETF process depends on peer review. However, IETF documents are 31 generally written to be useful for implementors, not for reviewers. 32 In particular, while great care is generally taken to provide a com- 33 plete description of the state machines and bits on the wire, this 34 level of detail tends to get in the way of initial understanding. 35 This document describes an approach for providing protocol "models" 36 that allow reviewers to quickly grasp the essence of a system. 38 1. Introduction 40 The IETF process depends on peer review. However, in many cases, the 41 documents submitted for publication are extremely difficult to 42 review. Since reviewers have only limited amounts of time, this leads 43 to extremely long review times, inadequate reviews, or both. In my 44 view, a large part of the problem is that most documents fail to pre- 45 sent an architectural model for how the protocol operated, opting 46 instead to siply describe the protocol and let the reviewer figure it 47 out. 49 This is acceptable when documenting a protocol for implementors, 50 because they need to understand the protocol in any case, but dramat- 51 ically increases the strain on reviewers. Reviewers necessarily need 52 to get the big picture of the system and then focus on particular 53 points. They simply do not have time to give the entire document the 54 attention an implementor would. 56 One way to reduce this load is to present the reviewer with a 57 MODEL--a short description of the system in overview form. This pro- 58 vides the reviewer with the context to identify the important or dif- 59 ficult pieces of the system and focus on them for review. As a side 60 benefit, if the model is done first, it can be serve as an aid to the 61 detailed protocol design and a focus for early review prior to proto- 62 col completion. The intention is that the model would either be the 63 first section of the protocol document or be a separate document pro- 64 vided with the protocol. 66 2. The Purpose of a Protocol Model 68 A protocol model needs to answer three basic questions: 70 1. What problem is the protocol trying to achieve? 71 2. What messages are being transmitted and what do they 72 mean? 73 3. What are the important but un-obvious features of the 74 protocol? 76 The basic idea is to provide enough information that the reader could 77 design a protocol which was roughly isomorphic to the protocol being 78 described. This doesn't, of course, mean that the protocol would be 79 identical, but merely that it would share most important features. 80 For instance, the decision to use a KDC-based authentication model is 81 an essential feature of Kerberos [REF]. By constrast, the use of 82 ASN.1 is a simple implementation decision. S-expressions--or XML, had 83 it existed at the time--would have served equally well. 85 3. Basic Principles 87 In this section we discuss basic principles that should guide your 88 presentation. 90 3.1. Less is more 92 Humans are only capable of keeping a very small number of pieces of 93 information in their head at once. Since we're interested in ensuring 94 that people get the big picture, we therefore have to dispense with a 95 lot of detail. That's good, not bad. The simpler you can make things 96 the better. 98 3.2. Abstraction is good 100 A key technique for representing complex systems is to try to 101 abstract away pieces. For instance, maps are better than photographs 102 for finding out where you want to go because they provide an 103 abstract, stylized, view of the information you're interested in. 104 Don't be afraid to compress multiple protocol elements into a single 105 abstract piece for pedagogical purposes. 107 3.3. A few well-chosen detail sometimes helps 109 The converse of the the previous principle is that sometimes details 110 help to bring a description into focus. Many people work better when 111 given examples. Thus, it's often a good approach to talk about the 112 material in the abstract and then provide a concrete description of 113 one specific piece to bring it into focus. Authors should focus on 114 the normal path. Error cases and corner cases should only be dis- 115 cussed where they help illustrate some important point. 116 [QUESTION: Would it help to explicitly indicate use of these techniques 117 in the examples that follow?] 119 4. Writing Protocol Models 121 Our experience indicates that it's easiest to grasp protocol models 122 when they're presented in visual form. We recommend a presentation 123 format that is centered around a few key diagrams with explanatory 124 text for each. These diagrams should be simple and typically consist 125 of "boxes and arrows"--boxes representing the major components, 126 arrows representing their relationships and labels indicating impor- 127 tant features. 129 We recommend a presentation structured in three parts to match the 130 three questions mentioned in the previous sections. Each part should 131 contain 1-3 diagrams intended to illustrate the relevant points. 133 4.1. Describe the problem you're trying to solve? 135 First, figure out what you are trying to do (this is good 136 advice under most circumstances, and it is especially apropos here. 137 --NNTP Installation Guide 139 The absolutely most critical task that a protocol model must perform 140 is to explain what the protocol is trying to achieve. This provides 141 crucial context for understanding how the protocol works and whether 142 it meets its goals. Given the desired goals, in most cases an 143 experienced reviewer will have an idea of how they would approach the 144 problem and be able to compare that to the approach taken by the pro- 145 tocol under review. 147 The "Problem" section of the model should start out with a short 148 statement of the environments in which the protocol is expected to be 149 used. This section should describe the relevant entities and the 150 likely scenarios under which they participate in the protocol. The 151 Problem section should feature a diagram showing the major communi- 152 cating parties and their inter-relationships. It is particularly 153 important to lay out the trust relationships between the various par- 154 ties as these are often un-obvious. 156 4.1.1. Example: STUN (RFC 3489) 158 Network Address Translation (NAT) makes it difficult to run a number 159 of classes of service from behind the NAT gateway. This is a particu- 160 lar problem when protocols need to advertise address/port pairs as 161 part of the application layer protocol. Although the NAT can be con- 162 figured to accept data destined for that port, address translation 163 means that the address that the application knows about is not the 164 same as the one that it is reachable on. 166 Consider the scenario represented in the figure below. A SIP client 167 is initiating a session with a SIP server in which it wants the SIP 168 server to send it some media. In its Session Description Protocol 169 (SDP) [REF] request it provides the IP and port on which it is lis- 170 tening. However, unbeknownst to the client, a NAT is in the way. It 171 translates the IP address in the header, but unless it is SIP aware, 172 it doesn't change the address in the request. The result is that the 173 media goes into a black hole. 175 +-----------+ 176 | SIP | 177 | Server | 178 | | 179 +-----------+ 180 ^ 181 | [FROM: 198.203.2.1:8954] 182 | [MSG: SEND MEDIA TO 10.0.10.5:6791] 183 | 184 | 185 +-----------+ 186 | | 187 | NAT | 188 --------------+ Gateway +---------------- 189 | | 190 +-----------+ 191 ^ 192 | [FROM: 10.0.10.5:6791] 193 | [MSG: SEND MEDIA TO 10.0.10.5:6791] 194 | 195 10.0.10.5 196 +-----------+ 197 | SIP | 198 | Client | 199 | | 200 +-----------+ 202 The purpose of STUN is to allow clients to detect this situation and 203 determine the address mapping. They can then place the appropriate 204 address in their application-level messages. This is done by making use 205 of an external STUN server. That server is able to determine the trans- 206 lated address and tell the STUN client, as shown below. 208 +-----------+ 209 | STUN | 210 | Server | 211 | | 212 +-----------+ 213 ^ | 214 [IP HDR FROM: 198.203.2.1:8954] | | [IP HDR TO: 198.203.2.1:8954] 215 [MSG: WHAT IS MY ADDRESS?] | | [MSG: YOU ARE 198.203.2.1:8954] 216 | v 217 +-----------+ 218 | | 219 | NAT | 220 --------------+ Gateway +---------------- 221 | | 222 +-----------+ 223 ^ | 224 [IP HDR FROM: 10.0.10.5:6791] | | [IP HDR TO: 10.0.10.5:6791] 225 [MSG: WHAT IS MY ADDRESS?] | | [MSG: YOU ARE 198.203.2.1:8954] 226 | v 227 10.0.10.5 228 +-----------+ 229 | SIP | 230 | Client | 231 | | 232 +-----------+ 234 4.2. Describe the protocol in broad overview 236 Once you've described the problem, the next task is to describe the 237 protocol in broad overview. This means showing, either in "ladder 238 diagram" or "boxes and arrows" form, the protocol messages that flow 239 between the various networking agents. This diagram should be accom- 240 pied with explanatory text that describes the purpose of each message 241 and the MAJOR data elements. 243 This section SHOULD NOT contain detailed descriptions of the protocol 244 messages or of each data element. In particular, bit diagrams, ASN.1 245 modules and XML schema SHOULD NOT be shown. The purpose of this sec- 246 tion is explicitly not to provide a complete description of the pro- 247 tocol. Instead, it is to provide enough of a map so that a person 248 reading the full protocol document can see where each specific piece 249 fits. 251 4.3. State Machines 253 In certain cases, it may be helpful to provide a state machine 254 description of the behavior of network elements. However, such state 255 machines should be kept as minimal as possible. Remember that the 256 purpose is to promote high-level comprehension, not complete under- 257 standing. 259 4.4. Example: DCCP 261 Although DCCP is datagram oriented like UDP, it is stateful like TCP. 262 Connections go through the following phases: 263 1. Initiation 264 2. Feature negotiation 265 3. Data transfer 266 4. Termination 268 4.4.1. Initiation 270 As with TCP, the initiation phase of DCCP involves a three-way hand- 271 shake, shown in Figure 1. 272 Client Server 273 ------ ------ 274 DCCP-Request -> 275 [Ports, Service, 276 Features] 277 <- DCCP-Response 278 [Features, 279 Cookie] 280 DCCP-Ack -> 281 [Features, 282 Cookie] 284 FFiigguurree 11 DCCP 3-way handshake 286 In the DCCP-Request message, the client tells the server the name of 287 the service it wants to talk to and the ports it wants to communicate 288 on. Note that ports are not tightly bound to services the way they 289 are in TCP or UDP common practice. It also starts feature negotia- 290 tion. For pedagogical reasons, we will present feature negotiation 291 separately in the next section. However, realize that the early 292 phases of feature negotiation happen concurrently with initiation. 294 In the DCCP-Response message, the server tells the client that it is 295 willing to accept the connection and continues feature negotiation. 296 In order to prevent SYN-flood style DOS attacks, DCCP incorporates an 297 IKE-style cookie exchange. The server can provide the client with a 298 cookie that contains all the negotiation state. This cookie must be 299 echoed by the client in the DCCP-Ack, thus removing the need for the 300 server to keep state. 302 In the DCCP-Ack message, the client acknowledges the DCCP-Response 303 and returns the cookie to permit the server to compleye its side of 304 the connection. As indicated in Figure 1, this message may also 305 include feature negotiation messages. 307 4.4.2. Feature Negotiation 309 In DCCP, feature negotiation is performed by attaching options to 310 other DCCP packets. Thus feature negotiation can be piggybacked on 311 any other DCCP message. This allows feature negotiation during con- 312 nection initiation as well as feature renegotiation during data flow. 314 Somewhat unusually, DCCP features are one-sided. Thus, it's possible 315 to have a different congestion control regime for data sent from 316 client to server than from server to client. 318 Feature negotiation is done with three options: 320 1. Change 321 2. Prefer 322 3. Confirm 324 A Change message says to the peer "change this option setting on your 325 side". The peer can either respond with a Confirm, meaning "I've 326 changed it" or a Prefer, containing a list of other settings that the 327 peer would like. Multiple exchanges of Change and Prefer may occur as 328 the peers attempt so sort out what options they have in common. Some 329 sample exchanges (partly cribbed from the DCCP spec) follow: 331 Client Server 332 ------ ------ 333 Change(CC,2) -> 334 <- Confirm(CC,2) 336 In this exchange, the peers agree to set CC equal to 2. 338 Client Server 339 ------ ------ 340 Change(CC,3,4) -> 341 <- Prefer(CC,1,2,5) 342 Change(CC,5) -> 343 <- Confirm(CC,5) 345 In this exchange, the client requests CC values 3 and 4. Note that 346 the client can offer multiple values. The server doesn't like any of 347 these and offers 1, 2, and 5. The client chooses 5 and the server 348 agrees. 350 Since features are one-sided, if a party wants to change one of his 351 own options, he must ask the peer to issue a Change. This is done 352 using a Prefer, as shown below, where the client gets the server to 353 request that the client change the value of CC to 3. 355 Client Server 356 ------ ------ 357 Prefer(CC,3,4) -> 358 <- Change(CC,3) 359 Confirm(CC,3) -> 361 4.4.3. Data Transfer 363 Rather than have a single congestion control regime as in TCP, DCCP 364 offers a variety of negotiable congestion control regimes. The DCCP 365 documents describe two congestion control regimes: additive increase, 366 multiplicative decrease (CCID-2 [REF]) and TCP-friendly rate control 367 (CCID-3 [REF]). CCID-2 is intended for applications which want maxi- 368 mum throughput. CCID-3 is intended for real-time applications which 369 want smooth response to congestion. 371 4.4.3.1. CCID-2 373 CCID-2's congestion control is extremely similar to that of TCP. The 374 sender maintains a congestion window and sends packets until that 375 window is full. Packets are Acked by the receiver. Dropped packets 376 and ECN [REF] are used to indicate congestion. The response to con- 377 gestion is to halve the congestion window. One subtle diference 378 between DCCP and TCP is that the Acks in DCCP must contain the 379 sequence numbers of all received packets (within a given window) not 380 just the highest sequence number as in TCP. 382 4.4.3.2. CCID-3 384 CCID-3 is an equation based form of rate control which is intended to 385 provide smoother response to congestion than CCID-2. The sender main- 386 tains a "transmit rate". The receiver sends ACK packets which also 387 contain information about the receiver's estimate of packet loss. The 388 sender uses this information to update its transmit rate. Although 389 CCID-3 behaves somewhat differently from TCP in its short term con- 390 gestion response, it is designed to operate fairly with TCP over the 391 long term. 393 4.4.4. Termination 395 [Still working on this one]. 397 5. Describe any important protocol features 399 The final section (if there is one) should contain an explanation of 400 any important protocol features which are not obvious from the previ- 401 ous sections. In the best case, all the important features of the 402 protocol would be obvious from the message flow. However, this isn't 403 always the case. This section is an opportunity for the author to 404 explicate those features. Authors should think carefully before writ- 405 ing this section. If there are no important points to be made they 406 should not populate this section. 408 Examples of the kind of feature that belongs in this section include: 409 high-level security considerations, congestion control information 410 and overviews of the algorithms that the network elements are 411 intended to follow. For instance, if you have a routing protocol you 412 might use this section to sketch out the algorithm that the router 413 uses to determine the appropriate routes from protocol messages. 415 5.1. Example: XXX 417 [TODO: Suggested targets welcome] 419 6. Formatting Issues 421 The requirement that Internet-Drafts and RFCs be renderable in ASCII 422 is a significant obstacle when writing the sort of graphics-heavy 423 document being described here. Authors may find it more convenient to 424 do a separate protocol model document in Postscript or PDF and simply 425 make it available at review time--though an archival version would 426 certainly be handy. 428 7. A Complete Example: Internet Key Exchange (IKE) 430 7.1. Operating Environment 432 Internet key Exchange (IKE) [REF] is a key establishment and parame- 433 ter negotiation protocol for Internet protocols. Its primary applica- 434 tion is for establishing security associations (SAs) [REF] for IPsec 435 AH [REF] and ESP [REF]. 437 +--------------------+ +--------------------+ 438 | | | | 439 | +------------+ | | +------------+ | 440 | | Key | | IKE | | Key | | 441 | | Management | <-+-----------------------+-> | Management | | 442 | | Process | | | | Process | | 443 | +------------+ | | +------------+ | 444 | ^ | | ^ | 445 | | | | | | 446 | v | | v | 447 | +------------+ | | +------------+ | 448 | | IPsec | | AH/ESP | | IPsec | | 449 | | Stack | <-+-----------------------+-> | Stack | | 450 | | | | | | | | 451 | +------------+ | | +------------+ | 452 | | | | 453 | | | | 454 | Initiator | | Responder | 455 +--------------------+ +--------------------+ 457 The general deployment model for IKE is shown in Figure 2. The IPsec 458 engines and IKE engines typically are separate modules. When a packet 459 needs to be processed (either sent or received) for which no security 460 association exists, the IPsec engine contacts the IKE engine and asks 461 it to establish an appropriate SA. The IKE engine contacts the appro- 462 priate peer and uses IKE to establish the SA. Once the IKE handshake 463 is finished it registers the SA with the IPsec engine. 465 In addition, IKE traffic between the peers can be used to refresh 466 keying material or adjust operating parameters such as algorithms. 468 7.1.1. Initiator and Responder 470 Although IPsec is basically symmetrical, IKE is not. The party who 471 sends the first message is called the INITIATOR. The other party is 472 called the RESPONDER. In the case of TCP connections the INITIATOR 473 will typically be the peer doing the active open (i.e. the client). 475 7.1.2. Perfect Forward Secrecy 477 One of the major concerns in IKE design was that traffic be protected 478 even if they keying material of the nodes was later compromised, pro- 479 vided that the session in question had terminated and so the session- 480 specific keying material was gone. This property is often called PER- 481 FECT FORWARD SECRECY (PFS) or BACK TRAFFIC PROTECTION. 483 7.1.3. Denial of Service Resistance 485 Since IKE allows arbitrary peers to initiate computationally expen- 486 sive cryptographic operations, it potentially allows resource con- 487 sumption denial of service attacks to be mounted against the IKE 488 engine. IKE includes countermeasures designed to minimize this risk. 490 7.1.4. Keying Assumptions 492 Because Security Associations are essentially symmetric, both sides 493 must in general be authenticated. Because IKE needs to be able to 494 establish SAs between a broad range of peers with various kinds of 495 prior relationships, IKE supports a very flexible keying model. Peers 496 can authenticate via shared keys, digital signatures (typically from 497 keys vouched for by certificates), or encryption keys. 499 7.1.5. Identity Protection 501 Although IKE requires the peers to authenticate to each other, it was 502 considered desirable by the working group to provide some identity 503 protection for the communicating peers. In particular, the peers 504 should be able to hide their identity from passive observers and one 505 peer should be able to require the author to authenticate before they 506 self-identity. In this case, the designers chose to make the party 507 who speaks first (the INITIATOR) identify first. 509 7.2. Protocol Overview 511 At a very high level, there are two kinds of IKE handshake: 512 (1) Those which establish an IKE security association. 513 (2) Those which establish an AH or ESP security association. 515 When two peers which have never communicated before need to establish 516 an AH/ESH SA, they must first establish an IKE SA. This allows them 517 to exchange an arbitrary amount of protected IKE traffic. They can 518 then use that SA to do a second handshake to establish SAs for AH and 519 ESP. This process is shown in schematic form below. The notation 520 E(SA,XXXX) is used to indicate that traffic is encrypted under a 521 given SA. 523 Initiator Responder 524 --------- --------- 526 Handshake MSG -> \ 527 <- Handshake MSG \ Establish IKE 528 / SA (IKEsa) 529 [...] / 531 E(IKEsa, Handshake MSG) -> \ Establish AH/ESP 532 <- E(IKEsa, Handshake MSG) / SA 534 IKE terminology is somewhat confusing, referring under different cir- 535 cumstances to "phases" and "modes". For maximal clarity we will refer 536 to the the Establishment of the IKE SA as "Stage 1" and the Estab- 537 lishment of AH/ESP SAs as "Stage 2". Note that it's quite possible 538 for there to be more than one Stage 2 handshake, once Stage 1 has 539 been finished. This might be useful if you wanted to establish multi- 540 ple AH/ESP SAs with different cryptographic properties. 542 The Stage 1 and Stage 2 handshakes are actually rather different, 543 because the Stage 2 handshake can of course assume that its traffic 544 is being protected with an IKE SA. Accordingly, we will first discuss 545 Stage 1 and then Stage 2. 547 7.2.1. Stage 1 549 There are a large number of variants of the IKE Stage 1 handshake, 550 necessitated by use of different authentication mechanisms. However, 551 broadly speaking they fall into one of two basic categories: MAIN 552 MODE, which provides identity protection and DoS resistance, and 553 AGGRESSIVE MODE, which does not. We will cover MAIN MODE first. 555 7.2.1.1. Main Mode 557 Main Mode is a six message (3 round trip) handshake which offers 558 identity protection and DoS resistance. An overview of the handshake 559 is below. 561 Initiator Responder 562 --------- --------- 563 CookieI, Algorithms -> \ Parameter 564 <- CookieR, Algorithms / Establishment 566 CookieR, 567 Nonce, Key Exchange -> 568 <- Nonce, Key Exchange\ Establish 569 / Shared key 571 E(IKEsa, Auth Data) -> 572 <- E(IKEsa, Auth data)\ Authenticate 573 / Peers 575 In the first round trip, the Initiator offers a set of algorithms and 576 parameters. The Responder picks out the single set that it likes and 577 responds with that set. It also provides CookieR, which will be used 578 to prevent DoS attacks. At this point, there is no secure association 579 but the peers have tentatively agreed upon parameters. These parame- 580 ters include a Diffie-Hellman group, which will be used in the second 581 round trip. 583 In the second round trip, the Initiator sends the key exchange infor- 584 mation. This generally consists of the Initiator's Diffie-Hellman 585 public share (Yi). He also supplies CookieR, which was provided by 586 the responder. The Responder replies with his own DH share (Yr). At 587 this point, both Initiator and Responder can compute the shared DH 588 key (ZZ). However, there has been no authentication and so they don't 589 know with any certainty that the connection hasn't been attacked. 590 Note that as long as the peers generate fresh DH shares for each 591 handshake than PFS will be provided. 593 Before we move on, let's take a look at the cookie exchange. The 594 basic anti-DoS measure used by IKE is to force the peer to demon- 595 strate that they can receive traffic from you. This foils blind 596 attacks like SYN floods [SYNFLOOD] and also makes it somewhat easier 597 to track down attackers. The cookie exchange serves this role in IKE. 598 The Responder can verify that the Initiator supplied a valid CookieR 599 before doing the expensive DH key agreement. This does not totally 600 eliminate DoS attacks, since an attacker who was willing to reveal 601 his location could still consume server resources, but it does pro- 602 tect against a certain class of blind attack. 604 In the final round trip, the peers establish their identities. Since 605 they share an (unauthenticated) key, they can send their identities 606 encrypted, thus providing identity protection from eavesdroppers. The 607 exact method of proving identity depends on what form of credential 608 is being used (signing key, encryption key, shared secret, etc.), but 609 in general you can think of it as a signature over some subset of the 610 handshake messages. So, each side would supply its certificate and 611 then sign using the key associated with that certificate. If shared 612 keys are used, the authentication data would be a key id and a MAC. 613 Authentication using public key encryption follows similar principles 614 but is more complicated. Refer to the IKE document for more details. 616 At the end of the Main Mode handshake, the peers share: 617 (1) A set of algorithms for encryption of further IKE traffic. 618 (2) Traffic encryption and authentication keys. 619 (3) Mutual knowledge of the peer's identity. 621 7.2.1.2. Aggressive Mode 623 Although IKE Main Mode provides the required services, there was con- 624 cern that the large number of round trips required added excessive 625 latency. Accordingly, an Aggressive Mode was defined. Aggressive mode 626 packs more data into fewer messages and thus reduces latency. How- 627 ever, it does not provide protection against DoS or identity protec- 628 tion. 629 Initiator Responder 630 --------- --------- 631 Algorithms, Nonce, 632 Key Exchange, -> 633 <- Algorithms, Nonce, 634 Key Exchange, Auth Data 635 Auth Data -> 637 After the first round trip, the peers have all the required proper- 638 ties except that the Initiator has not authenticated to the Respon- 639 der. The third message closes the loop by authenticating the Initia- 640 tor. Note that since the authentication data is sent in the clear, no 641 identity protection is provided and since the Responder does the DH 642 key agreement without a round trip to the Initiator, there is no DoS 643 protection 645 7.2.2. Stage 2 647 Stage 1 on its own isn't very useful. The purpose of IKE, after all, 648 is to establish associations to be used to protect other traffic, not 649 just to establish IKE SAs. Stage 2 (what IKE calls "Quick Mode") is 650 used for this purpose. The basic Stage 2 handshake is shown below. 652 Initiator Responder 653 --------- --------- 654 AH/ESP parameters, 655 Algorithms, Nonce, 656 Handshake Hash -> 658 <- AH/ESP parameters, 659 Algorithms, Nonce, 660 Handshake Hash 661 Handshake Hash -> 663 As with quick mode, the first two messages establish the algorithms 664 and parameters while the final message is a check over the previous 665 messages. In this case, the parameters also include the transforms to 666 be applied to the traffic (AH or ESP) and the kinds of traffic which 667 are to be protected. Note that there is no key exchange information 668 shown in these messages. 670 In this version of Quick Mode, the peers use the pre-existing Stage 1 671 keying material to derive fresh keying material for traffic protec- 672 tion (with the nonces to ensure freshness). Quick mode also allows 673 for a new Diffie-Hellman handshake for per-traffic key PFS. In that 674 case, the first two messages shown above would also include Key 675 Exchange payloads, as shown below. 677 Initiator Responder 678 --------- --------- 679 AH/ESP parameters, 680 Algorithms, Nonce, 681 Key Exchange, -> 682 Handshake Hash 684 <- AH/ESP parameters, 685 Algorithms, Nonce, 686 Key Exchange, 687 Handshake Hash 688 Handshake Hash -> 690 7.3. Other Considerations 692 There are a number of features of IKE that deserve special considera- 693 tion. These are discussed here. 695 7.3.1. Cookie Generation 697 As mentioned previously, IKE uses cookies as a partial defense 698 against DoS attacks. When the responder receives Main Mode message 3 699 containing the Key Exchange data and the cookie, it verifies that the 700 cookie is correct. However, this verification must not involve having 701 a list of valid cookies. Otherwise, an attacker could potentially 702 consume arbitrary amounts of memory by repeatedly requesting cookies 703 from a responder. The recommended way to generate a cookie, suggested 704 by Phil Karn, is by having a single master key and compute a hash of 705 the secret and the initiator's address information. This cookie can 706 be verified by recomputing the cookie value based on information in 707 the third message and seeing if it matches. 709 7.3.2. Endpoint Identities 711 So far we have been rather vague about what sorts of endpoint identi- 712 ties are used. In principle, there are three ways a peer might be 713 identified: by a shared key, a pre-configured public key, and a 714 certificate. 716 7.3.2.1. Shared Key 718 In a shared key scheme, the peers share some symmetric key. This key 719 is associated with a key identifier which is known to both parties. 720 It is assumed that the party verifying that identity also has some 721 sort of table that indicates what sorts of traffic (e.g. what 722 addresses) that identity is allowed to negotiate SAs for. 724 7.3.2.2. Pre-configured public key 726 A pre-configured public key scheme is the same as a shared key scheme 727 except that the verifying party has the authenticating party's public 728 key instead of a shared key. 730 7.3.2.3. Certificate 732 In a certificate scheme, authenticating party presents a certificate 733 containing their public key. It's straightforward to establish that 734 that certificate matches the authentication data provided by the 735 peer. What's less straightforward is to determine whether a given 736 peer is entitled to negotiate for a given class of traffic. In the- 737 ory, one might be able to determine this from the name in the 738 certificate (e.g. the subject name contains an IP address that 739 matches the ostensible IP address). In practice, this is not clearly 740 specified in IKE and therefore not really interoperable. The more 741 likely case at the moment is that there is a configuration table map- 742 ping certificates to policies, as with the other two authentication 743 schemes. 745 References 747 [TODO] 749 Security Considerations 751 This document does not define any protocols and therefore has no 752 security considerations. 754 Author's Address 755 Eric Rescorla 756 RTFM, Inc. 757 2064 Edgewood Drive 758 Palo Alto, CA 94303 759 Phone: (650)-320-8549 761 Internet Architecture Board 762 IAB 764 Appendix A. IAB Members at the time of this writing 766 Bernard Aboba 767 Harald Alvestrand 768 Rob Austein 769 Leslie Daigle 770 Patrik Falstrom 771 Sally Floyd 772 Jun-ichiro Itojun Hagino 773 Mark Handley 774 Geoff Huston 775 Charlie Kaufman 776 James Kempf 777 Eric Rescorla 778 Mike St. Johns