idnits 2.17.1 draft-ietf-tsvwg-sctp-auth-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 646. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 623. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 630. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 636. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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.) -- The document date (March 6, 2006) is 6626 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '1') ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '2') ** Obsolete normative reference: RFC 2960 (ref. '4') (Obsoleted by RFC 4960) -- Possible downref: Non-RFC (?) normative reference: ref. '6' Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Tuexen 3 Internet-Draft Muenster Univ. of Applied Sciences 4 Expires: September 7, 2006 R. Stewart 5 P. Lei 6 Cisco Systems, Inc. 7 E. Rescorla 8 RTFM, Inc. 9 March 6, 2006 11 Authenticated Chunks for Stream Control Transmission Protocol (SCTP) 12 draft-ietf-tsvwg-sctp-auth-02.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on September 7, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). 43 Abstract 45 This document describes a new chunk type, several parameters and 46 procedures for SCTP. This new chunk type can be used to authenticate 47 SCTP chunks by using shared keys between the sender and receiver. 48 The new parameters are used to establish the shared keys. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. New Parameter Types . . . . . . . . . . . . . . . . . . . . . 3 55 3.1. Random Parameter (RANDOM) . . . . . . . . . . . . . . . . 4 56 3.2. Chunk List Parameter (CHUNKS) . . . . . . . . . . . . . . 4 57 3.3. Requested HMAC Algorithm Parameter (HMAC-ALGO) . . . . . . 5 58 4. New Error Cause . . . . . . . . . . . . . . . . . . . . . . . 7 59 4.1. Unsupported HMAC Identifier error cause . . . . . . . . . 7 60 5. New Chunk Type . . . . . . . . . . . . . . . . . . . . . . . . 7 61 5.1. Authentication Chunk (AUTH) . . . . . . . . . . . . . . . 8 62 6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 6.1. Establishment of an association shared key . . . . . . . . 9 64 6.2. Sending authenticated chunks . . . . . . . . . . . . . . . 10 65 6.3. Receiving authenticated chunks . . . . . . . . . . . . . . 11 66 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 68 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 69 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 70 11. Normative References . . . . . . . . . . . . . . . . . . . . . 13 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 72 Intellectual Property and Copyright Statements . . . . . . . . . . 16 74 1. Introduction 76 SCTP uses 32 bit verification tags to protect itself against blind 77 attackers. These values are not changed during the lifetime of an 78 SCTP association. 80 Looking at new SCTP extensions there is the need to have a method of 81 proving that an SCTP chunk(s) was really sent by the original peer 82 that started the association and not by a malicious attacker. 84 Using TLS as defined in RFC3436 [5] does not help here because it 85 only secures SCTP user data. 87 Therefore an SCTP extension is presented in this document which 88 allows an SCTP sender to sign chunks using shared keys between the 89 sender and receiver. The receiver can then verify that the chunks 90 are sent from the sender and not from a malicious attacker. 92 This extension also provides a mechanism for deriving a shared key 93 for each association. This association shared key is derived from 94 endpoint pair shared keys, which are preconfigured and might be 95 empty. 97 2. Conventions 99 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 100 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when 101 they appear in this document, are to be interpreted as described in 102 RFC2119 [3]. 104 3. New Parameter Types 106 This section defines the new parameter types that will be used to 107 negotiate the authentication during association setup. Table 1 108 illustrates the new parameter types. 110 +----------------+------------------------------------------------+ 111 | Parameter Type | Parameter Name | 112 +----------------+------------------------------------------------+ 113 | 0x8002 | Random Parameter (RANDOM) | 114 | 0x8003 | Chunk List Parameter (CHUNKS) | 115 | 0x8004 | Requested HMAC Algorithm Parameter (HMAC-ALGO) | 116 +----------------+------------------------------------------------+ 118 Table 1 120 It should be noted that the parameter format requires the receiver to 121 ignore the parameter and continue processing if it is not understood. 122 This is accomplished as described in RFC2960 [4] section 3.2.1. by 123 the use of the upper bits of the parameter type. 125 3.1. Random Parameter (RANDOM) 127 This parameter is used to carry an arbitrary length random number. 129 0 1 2 3 130 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | Parameter Type = 0x8002 | Parameter Length | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | | 135 \ Random Number / 136 / \ 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 Figure 1 141 Parameter Type: 2 bytes (unsigned integer) 142 This value MUST be set to 0x8002. 144 Parameter Length: 2 bytes (unsigned integer) 145 This value is the length of the Random Number plus 4. 147 Random Number: n bytes (unsigned integer) 148 This value represents an arbitrary Random Number in network byte 149 order. 151 The RANDOM parameter MUST be included once in the INIT or INIT-ACK 152 chunk if the sender wants to send or receive authenticated chunks. 154 3.2. Chunk List Parameter (CHUNKS) 156 This parameter is used to specify which chunk types are required to 157 be sent authenticated by the peer. 159 0 1 2 3 160 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Parameter Type = 0x8003 | Parameter Length | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Chunk Type 1 | Chunk Type 2 | Chunk Type 3 | Chunk Type 4 | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 / / 167 \ ... \ 168 / / 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Chunk Type n | Padding | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 Figure 2 175 Parameter Type: 2 bytes (unsigned integer) 176 This value MUST be set to 0x8003. 178 Parameter Length: 2 bytes (unsigned integer) 179 This value is the number of listed Chunk Types plus 4. 181 Chunk Type n: 1 byte (unsigned integer) 182 Each Chunk Type listed is required to be authenticated when sent 183 by the peer. 185 The CHUNKS parameter MUST be included once in the INIT or INIT-ACK 186 chunk if the sender wants to receive authenticated chunks. Its 187 maximum length is 260 bytes. 189 The chunk types for INIT, INIT-ACK, SHUTDOWN-COMPLETE and AUTH chunks 190 MUST NOT be listed in the CHUNKS parameter. However, if a CHUNKS 191 parameter is received then the types for INIT, INIT-ACK, SHUTDOWN- 192 COMPLETE and AUTH chunks MUST be ignored. 194 3.3. Requested HMAC Algorithm Parameter (HMAC-ALGO) 196 This parameter is used to list the HMAC identifiers the peer MUST 197 use. 199 0 1 2 3 200 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Parameter Type = 0x8004 | Parameter Length | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | HMAC Identifier 1 | HMAC Identifier 2 | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 / / 207 \ ... \ 208 / / 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | HMAC Identifier n | Padding | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 Figure 3 215 Parameter Type: 2 bytes (unsigned integer) 216 This value MUST be set to 0x8004. 218 Parameter Length: 2 bytes (unsigned integer) 219 This value is the length of the number of HMAC identifiers 220 multiplied by 2 plus 4. 222 HMAC Identifier n: 2 bytes (unsigned integer) 223 The values is an HMAC Identifier which should be used. The values 224 are listed by priority. Highest priority first. 226 The HMAC-ALGO parameter MUST be included once in the INIT or INIT-ACK 227 chunk if the sender wants to send or receive authenticated chunks. 229 The following Table 2 shows the currently defined values for HMAC 230 identifiers. 232 +-----------------+--------------------------+ 233 | HMAC Identifier | Message Digest Algorithm | 234 +-----------------+--------------------------+ 235 | 0 | Reserved | 236 | 1 | SHA-1 defined in [6] | 237 | 2 | MD-5 defined in [1] | 238 +-----------------+--------------------------+ 240 Table 2 242 Every endpoint supporting SCTP chunk authentication MUST support the 243 HMAC based on the SHA-1 algorithm. 245 4. New Error Cause 247 This section defines a new error cause that will be sent if an AUTH 248 chunk is received with an unsupported HMAC identifier. Table 3 249 illustrates the new error cause. 251 +------------+-----------------------------+ 252 | Cause Code | Error Cause Name | 253 +------------+-----------------------------+ 254 | 0x0105 | Unsupported HMAC Identifier | 255 +------------+-----------------------------+ 257 Table 3 259 4.1. Unsupported HMAC Identifier error cause 261 This error cause is used to indicate that an AUTH chunk was received 262 with an unsupported HMAC Identifier. 264 0 1 2 3 265 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Cause Code = 0x0105 | Cause Length = 6 | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | HMAC Identifier | Padding | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 Figure 4 274 Cause Code: 2 bytes (unsigned integer) 275 This value MUST be set to 0x0105. 277 Cause Length: 2 bytes (unsigned integer) 278 This value MUST be set to 6. 280 HMAC Identifier: 4 bytes (unsigned integer) 281 This value is the HMAC Identifier which is not supported. 283 5. New Chunk Type 285 This section defines the new chunk type that will be used to 286 authenticate chunks. Table 4 illustrates the new chunk type. 288 +------------+-----------------------------+ 289 | Chunk Type | Chunk Name | 290 +------------+-----------------------------+ 291 | 0x0F | Authentication Chunk (AUTH) | 292 +------------+-----------------------------+ 294 Table 4 296 It should be noted that the AUTH-chunk format requires the receiver 297 to ignore the chunk if it is not understood and silently discard all 298 chunks that follow. This is accomplished as described in RFC2960 [4] 299 section 3.2. by the use of the upper bits of the chunk type. 301 5.1. Authentication Chunk (AUTH) 303 This chunk is used to hold the result of the HMAC calculation. 305 0 1 2 3 306 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Type = 0x0F | Flags=0 | Length | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Shared Key Identifier | HMAC Identifier | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | | 313 \ HMAC / 314 / \ 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 Figure 5 319 Type: 1 byte (unsigned integer) 320 This value MUST be set to 0x0F for all AUTH-chunks. 322 Flags: 1 byte (unsigned integer) 323 Set to zero on transmit and ignored on receipt. 325 Length: 2 bytes (unsigned integer) 326 This value holds the length of the HMAC plus 8. 328 Shared Key Identifier: 2 bytes (unsigned integer) 329 This value describes which endpoint pair shared key is used. 331 HMAC Identifier: 2 bytes (unsigned integer) 332 This value describes which message digest is being used. Table 2 333 shows the currently defined values. 335 HMAC: n bytes (unsigned integer) 336 This hold the result of the HMAC calculation. 338 The control chunk AUTH MUST NOT appear more than once in an SCTP 339 packet. All control and data chunks which are placed after the AUTH 340 chunk in the packet are sent in an authenticated way. Those chunks 341 placed in a packet before the AUTH chunk are not authenticated. 342 Please note that DATA chunks can not appear before control chunks in 343 an SCTP packet. 345 6. Procedures 347 6.1. Establishment of an association shared key 349 An SCTP endpoint willing to receive or send authenticated chunks MUST 350 send one RANDOM parameter in its INIT or INIT-ACK chunk. The RANDOM 351 parameter SHOULD contain a 32 byte random number. In case of INIT 352 collision, the rules governing the handling of this random number 353 follow the same pattern as those for the Verification Tag, as 354 explained in section 5.2.4 of RFC2960 [4]. Therefore each endpoint 355 knows its own random number and the peer's random number after the 356 association has been established. 358 An SCTP endpoint has a list of chunks it only accepts if they are 359 received in an authenticated way. This list is included in the INIT 360 and INIT-ACK and MAY be omitted if it is empty. Since this list does 361 not change during the lifetime of there is no problem in case of INIT 362 collision. 364 Each SCTP endpoint MUST include in the INIT and INIT-ACK a HMAC-ALGO 365 parameter containing a list of HMAC Identifiers it requests the peer 366 to use. The receiver of a HMAC-ALGO parameter SHOULD use the first 367 listed algorithm it supports. The HMAC algorithm based on SHA-1 MUST 368 be supported and included in the HMAC-ALGO parameter. An SCTP 369 endpoint MUST NOT change the parameters listed in the HMAC-ALGO 370 parameter during the lifetime of the endpoint. 372 Both endpoints of an association MAY have endpoint pair shared keys 373 which are byte vectors and preconfigured or established by another 374 mechanism. They are identified by the shared key identifier. If no 375 endpoint pair shared keys are preconfigured or established by another 376 mechanism an empty byte vector is used. 378 From these endpoint pair shared keys the association shared keys are 379 computed by concatenating the endpoint pair shared key with the 380 random numbers exchanged in the INIT and INIT-ACK. This is performed 381 by selecting the smaller random number value and concatenating it to 382 the endpoint pair shared key, and then concatenating the larger of 383 the random number values to that. If both random numbers are equal, 384 then the concatenation order is the random number with the shorter 385 length, followed by the endpoint shared key, followed by the random 386 number with the longer length. If the random number lengths are the 387 same, then they may be concatenated to the endpoint pair key in any 388 order. The concatenation is performed on byte vectors representing 389 all numbers in network byte order. The result is the association 390 shared key. 392 6.2. Sending authenticated chunks 394 Endpoints MUST send all requested chunks authenticated where this has 395 been requested by the peer. The other chunks MAY be sent 396 authenticated or not. If endpoint pair shared keys are used, one of 397 them MUST be selected for authentication. 399 To send chunks in an authenticated way, the sender MUST include these 400 chunks after an AUTH chunk. This means that a sender MUST bundle 401 chunks in order to authenticate them. 403 The sender MUST calculate the MAC using the hash function H as 404 described by the MAC Identifier and the shared association key K 405 based on the endpoint pair shared key described by the shared key 406 identifier. The 'data' used for the computation of the AUTH-chunk is 407 given by Figure 6 and all chunks that are placed after the AUTH chunk 408 in the SCTP packet. RFC2104 [2] can be used as a guideline for 409 generating the MAC. 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Type = 0x0F | Flags=0 | Chunk Length | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Shared Key Identifier | HMAC Identifier | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | | 417 \ 0 / 418 / \ 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 Figure 6 423 Please note that all fields are in network byte order and that the 424 field which will contain the complete HMAC is filled with zeroes. 425 The length of the field shown as 0 is the length of the HMAC 426 described by the HMAC Identifier. The padding of all chunks being 427 authenticated MUST be included in the HMAC computation. 429 The sender fills the HMAC into the HMAC field and sends the packet. 431 6.3. Receiving authenticated chunks 433 The receiver has a list of chunk types which it expects to be 434 received only after an AUTH-chunk. This list has been sent to the 435 peer during the association setup. It MUST silently discard these 436 chunks if they are not placed after an AUTH chunk in the packet. 438 The receiver MUST use the HMAC algorithm indicated in the HMAC 439 Identifier field. If this algorithm was not specified by the 440 receiver in the HMAC-ALGO parameter in the INIT or INIT-ACK chunk 441 during association setup, the AUTH chunk and all chunks after it MUST 442 be discarded and an ERROR chunk SHOULD be sent with the error cause 443 defined in Section 4.1. 445 If the endpoint has no endpoint pair shared key for the peer, it MUST 446 use an empty endpoint pair shared key regardless which Shared Key 447 Identifier is present in the AUTH chunk. If the endpoint has at 448 least one endpoint pair shared key for the peer, it MUST use the key 449 specified by the Shared Key Identifier if a key has been configured 450 for that Shared Key Identifier. If no endpoint pair shared key has 451 been configured for that Shared Key Identifier, all authenticated 452 chunks MUST be silently discarded. 454 The receiver now performs the same calculation as described for the 455 sender based on Figure 6. If the result of the calculation is the 456 same as given in the HMAC field, all chunks following the AUTH chunk 457 are processed. If the field does not match the result of the 458 calculation, all the chunks following the AUTH chunk MUST be silently 459 discarded. 461 It should be noted that if the receiver wants to tear down an 462 association in an authenticated way only, the handling of malformed 463 packets should be in tune with this. 465 If the receiver of the packet does not have a TCB when it needs to 466 process the AUTH chunk, it MUST ignore the AUTH chunk. This applies 467 to a packet containing an AUTH chunk as a first chunk and an COOKIE- 468 ECHO chunk as the second chunk received in the CLOSED state. If the 469 receiver has a TCB, it MUST process the AUTH chunk as described 470 above. 472 It should also be noted that if an endpoint accepts ABORT chunks only 473 in an authenticated way, it may take longer to detect that the peer 474 is no longer available. If an endpoint accepts COOKIE chunks only in 475 an authenticated way, the restart procedure does not work. 477 7. Examples 479 This section gives examples of message exchanges for association 480 setup. 482 The simplest way of using the extension described in this document is 483 given by the following message exchange. 485 ---------- INIT[RANDOM; CHUNKS; HMAC-ALGO] ----------> 486 <------- INIT-ACK[RANDOM; CHUNKS; HMAC-ALGO] --------- 487 -------------------- COOKIE-ECHO --------------------> 488 <-------------------- COOKIE-ACK --------------------- 490 Please note that the CHUNKS parameter is optional in the INIT and 491 INIT-ACK. 493 If the server wants to receive DATA chunks in an authenticated way, 494 the following message exchange is possible: 496 ---------- INIT[RANDOM; CHUNKS; HMAC-ALGO] ----------> 497 <------- INIT-ACK[RANDOM; CHUNKS; HMAC-ALGO] --------- 498 --------------- COOKIE-ECHO; AUTH; DATA -------------> 499 <----------------- COOKIE-ACK; SACK ------------------ 501 Please note that if the endpoint pair shared key depends on the 502 client and the server and that it is only known by the upper layer 503 this message exchange requires an upper layer intervention between 504 the processing of the COOKIE-ECHO chunk (COMMUNICATION-UP 505 notification followed by the presentation of the endpoint pair shared 506 key by the upper layer to the SCTP stack) and the processing of the 507 AUTH and DATA chunk. If this intervention is not possible due to 508 limitations of the API the server might discard the AUTH and DATA 509 chunk making a retransmission of the DATA chunk necessary. If the 510 same endpoint pair shared key is used for multiple endpoints and does 511 not depend on the client this intervention might not be necessary. 513 8. IANA Considerations 515 A chunk type for the AUTH chunk has to be assigned by IANA. It is 516 suggested to use the value given above. 518 Parameter types have to be assigned for the RANDOM, CHUNKS, and HMAC- 519 ALGO parameter by IANA. It is suggested to use the values given 520 above. 522 An error cause for the Unsupported HMAC Identifier error cause has to 523 be assigned. It is suggested to use the value given above. 525 HMAC Identifiers have to be maintained by IANA. Three initial values 526 should be assigned by IANA as described above. 528 9. Security Considerations 530 If no endpoint pair shared key is used an attacker which captures the 531 association setup message exchange can later insert arbitrary packets 532 in an authenticated way. However, if the attacker did not capture 533 this initial message exchange he can not successfully inject chunks 534 which are required to be authenticated. 536 If an enpoint pair shared key is used even a true man in the middle 537 can not inject chunks which are required to be authenticated even if 538 he intercepts the initial message exchange. 540 Because SCTP has already a mechanism built-in that handles the 541 reception of duplicated chunks the presented solution makes use of 542 this functionality and does not provide a method to avoid replay 543 attacks by itself. Of course, this only works within each SCTP 544 association. Therefore a separate shared key is used for each SCTP 545 association to handle replay attacks covering multiple SCTP 546 associations. 548 10. Acknowledgments 550 The authors wish to thank Sascha Grau, Ivan Arias Rodriguez, and 551 Irene Ruengeler for their invaluable comments. 553 11. Normative References 555 [1] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 556 April 1992. 558 [2] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing 559 for Message Authentication", RFC 2104, February 1997. 561 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 562 Levels", BCP 14, RFC 2119, March 1997. 564 [4] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 565 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, 566 "Stream Control Transmission Protocol", RFC 2960, October 2000. 568 [5] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer 569 Security over Stream Control Transmission Protocol", RFC 3436, 570 December 2002. 572 [6] National Institute of Standards and Technology, "Secure Hash 573 Standard", FIPS PUB 180-1, April 1995, 574 . 576 Authors' Addresses 578 Michael Tuexen 579 Muenster Univ. of Applied Sciences 580 Stegerwaldstr. 39 581 48565 Steinfurt 582 Germany 584 Email: tuexen@fh-muenster.de 586 Randall R. Stewart 587 Cisco Systems, Inc. 588 4875 Forest Drive 589 Suite 200 590 Columbia, SC 29206 591 USA 593 Email: rrs@cisco.com 595 Peter Lei 596 Cisco Systems, Inc. 597 8735 West Higgins Road 598 Suite 300 599 Chicago, IL 60631 600 USA 602 Phone: 603 Email: peterlei@cisco.com 605 Eric Rescorla 606 RTFM, Inc. 607 2064 Edgewood Drive 608 Palo Alto, CA 94303 609 USA 611 Phone: +1 650-320-8549 612 Email: ekr@rtfm.com 614 Intellectual Property Statement 616 The IETF takes no position regarding the validity or scope of any 617 Intellectual Property Rights or other rights that might be claimed to 618 pertain to the implementation or use of the technology described in 619 this document or the extent to which any license under such rights 620 might or might not be available; nor does it represent that it has 621 made any independent effort to identify any such rights. Information 622 on the procedures with respect to rights in RFC documents can be 623 found in BCP 78 and BCP 79. 625 Copies of IPR disclosures made to the IETF Secretariat and any 626 assurances of licenses to be made available, or the result of an 627 attempt made to obtain a general license or permission for the use of 628 such proprietary rights by implementers or users of this 629 specification can be obtained from the IETF on-line IPR repository at 630 http://www.ietf.org/ipr. 632 The IETF invites any interested party to bring to its attention any 633 copyrights, patents or patent applications, or other proprietary 634 rights that may cover technology that may be required to implement 635 this standard. Please address the information to the IETF at 636 ietf-ipr@ietf.org. 638 Disclaimer of Validity 640 This document and the information contained herein are provided on an 641 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 642 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 643 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 644 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 645 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 646 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 648 Copyright Statement 650 Copyright (C) The Internet Society (2006). This document is subject 651 to the rights, licenses and restrictions contained in BCP 78, and 652 except as set forth therein, the authors retain all their rights. 654 Acknowledgment 656 Funding for the RFC Editor function is currently provided by the 657 Internet Society.