idnits 2.17.1 draft-ietf-tsvwg-sctp-auth-08.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, updated by RFC 4748 on line 838. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 849. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 856. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 862. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (February 26, 2007) is 6270 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) -- Looks like a reference, but probably isn't: 'RFCXXXX' on line 659 == Unused Reference: '1' is defined on line 757, but no explicit reference was found in the text ** 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 2434 (ref. '4') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2960 (ref. '5') (Obsoleted by RFC 4960) -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 10 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 Intended status: Standards Track R. Stewart 5 Expires: August 30, 2007 P. Lei 6 Cisco Systems, Inc. 7 E. Rescorla 8 RTFM, Inc. 9 February 26, 2007 11 Authenticated Chunks for Stream Control Transmission Protocol (SCTP) 12 draft-ietf-tsvwg-sctp-auth-08.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 August 30, 2007. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 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 . . . . . . . . . . . . . . . . . . . . . 4 55 3.1. Random Parameter (RANDOM) . . . . . . . . . . . . . . . . 4 56 3.2. Chunk List Parameter (CHUNKS) . . . . . . . . . . . . . . 5 57 3.3. Requested HMAC Algorithm Parameter (HMAC-ALGO) . . . . . . 6 58 4. New Error Cause . . . . . . . . . . . . . . . . . . . . . . . 7 59 4.1. Unsupported HMAC Identifier error cause . . . . . . . . . 7 60 5. New Chunk Type . . . . . . . . . . . . . . . . . . . . . . . . 8 61 5.1. Authentication Chunk (AUTH) . . . . . . . . . . . . . . . 8 62 6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 6.1. Establishment of an association shared key . . . . . . . . 10 64 6.2. Sending authenticated chunks . . . . . . . . . . . . . . . 11 65 6.3. Receiving authenticated chunks . . . . . . . . . . . . . . 12 66 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 68 8.1. A New Chunk Type . . . . . . . . . . . . . . . . . . . . . 15 69 8.2. Three New Parameter Types . . . . . . . . . . . . . . . . 15 70 8.3. A New Error Cause . . . . . . . . . . . . . . . . . . . . 15 71 8.4. A New Table For HMAC Identifiers . . . . . . . . . . . . . 16 72 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 73 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 74 11. Normative References . . . . . . . . . . . . . . . . . . . . . 17 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 76 Intellectual Property and Copyright Statements . . . . . . . . . . 20 78 1. Introduction 80 SCTP uses 32 bit verification tags to protect itself against blind 81 attackers. These values are not changed during the lifetime of an 82 SCTP association. 84 Looking at new SCTP extensions there is the need to have a method of 85 proving that an SCTP chunk(s) was really sent by the original peer 86 that started the association and not by a malicious attacker. 88 Using TLS as defined in RFC3436 [6] does not help here because it 89 only secures SCTP user data. 91 Therefore an SCTP extension is presented which provides a mechanism 92 for deriving shared keys for each association. These association 93 shared keys are derived from endpoint pair shared keys, which are 94 configured and might be empty, and data which is exchanged during the 95 SCTP association setup. 97 The extension presented in this document allows an SCTP sender to 98 authenticate chunks using shared keys between the sender and 99 receiver. The receiver can then verify that the chunks are sent from 100 the sender and not from a malicious attacker as long as the attacker 101 does not know an association shared key. 103 The extension described in this document puts the result of an HMAC 104 computation before the data covered by that computation. Putting it 105 at the end of the packet would have required putting a control chunk 106 after DATA chunks in case of authenticating DATA chunks. This would 107 break the rule that control chunks occur before DATA chunks in SCTP 108 packets. It should also be noted that putting the result of the HMAC 109 computation after the data being covered would not allow sending the 110 packet during the computation of the HMAC because the result of the 111 HMAC computation is needed to compute the CRC32C checksum of the SCTP 112 packet which is placed in the common header of the SCTP packet. 114 The SCTP extension for Dynamic Address Reconfiguration (ADD-IP) 115 requires the usage of the extension described in this document. The 116 SCTP Partial Reliability Extension (PR-SCTP) can be used in 117 conjunction with the extension described in this document. 119 2. Conventions 121 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 123 "OPTIONAL", when they appear in this document, are to be interpreted 124 as described in RFC2119 [3]. 126 3. New Parameter Types 128 This section defines the new parameter types that will be used to 129 negotiate the authentication during association setup. Table 1 130 illustrates the new parameter types. 132 +----------------+------------------------------------------------+ 133 | Parameter Type | Parameter Name | 134 +----------------+------------------------------------------------+ 135 | 0x8002 | Random Parameter (RANDOM) | 136 | 0x8003 | Chunk List Parameter (CHUNKS) | 137 | 0x8004 | Requested HMAC Algorithm Parameter (HMAC-ALGO) | 138 +----------------+------------------------------------------------+ 140 Table 1 142 It should be noted that the parameter format requires the receiver to 143 ignore the parameter and continue processing if it is not understood. 144 This is accomplished as described in RFC2960 [5] section 3.2.1. by 145 the use of the upper bits of the parameter type. 147 3.1. Random Parameter (RANDOM) 149 This parameter is used to carry an arbitrary length random number. 151 0 1 2 3 152 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 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Parameter Type = 0x8002 | Parameter Length | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | | 157 \ Random Number / 158 / +-------------------------------\ 159 | | Padding | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 Figure 1 164 Parameter Type: 2 bytes (unsigned integer) 165 This value MUST be set to 0x8002. 167 Parameter Length: 2 bytes (unsigned integer) 168 This value is the length of the Random Number in bytes plus 4. 170 Random Number: n bytes (unsigned integer) 171 This value represents an arbitrary Random Number in network byte 172 order. 174 Padding: 0, 1, 2, or 3 bytes (unsigned integer) 175 If the length of the random number is not a multiple of 4 bytes, 176 the sender MUST pad the parameter with all zero bytes to make the 177 parameter 32-bit aligned. The Padding MUST NOT be longer than 3 178 bytes and it MUST be ignored by the receiver. 180 The RANDOM parameter MUST be included once in the INIT or INIT-ACK 181 chunk if the sender wants to send or receive authenticated chunks to 182 provide a 32 byte Random Number. For 32 byte Random Numbers the 183 Padding is empty. 185 3.2. Chunk List Parameter (CHUNKS) 187 This parameter is used to specify which chunk types are required to 188 be sent authenticated by the peer. 190 0 1 2 3 191 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 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Parameter Type = 0x8003 | Parameter Length | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Chunk Type 1 | Chunk Type 2 | Chunk Type 3 | Chunk Type 4 | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 / / 198 \ ... \ 199 / / 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Chunk Type n | Padding | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 Figure 2 206 Parameter Type: 2 bytes (unsigned integer) 207 This value MUST be set to 0x8003. 209 Parameter Length: 2 bytes (unsigned integer) 210 This value is the number of listed Chunk Types plus 4. 212 Chunk Type n: 1 byte (unsigned integer) 213 Each Chunk Type listed is required to be authenticated when sent 214 by the peer. 216 Padding: 0, 1, 2, or 3 bytes (unsigned integer) 217 If the number of Chunk Types is not a multiple of 4, the sender 218 MUST pad the parameter with all zero bytes to make the parameter 219 32-bit aligned. The Padding MUST NOT be longer than 3 bytes and 220 it MUST be ignored by the receiver. 222 The CHUNKS parameter MUST be included once in the INIT or INIT-ACK 223 chunk if the sender wants to receive authenticated chunks. Its 224 maximum length is 260 bytes. 226 The chunk types for INIT, INIT-ACK, SHUTDOWN-COMPLETE and AUTH chunks 227 MUST NOT be listed in the CHUNKS parameter. However, if a CHUNKS 228 parameter is received then the types for INIT, INIT-ACK, SHUTDOWN- 229 COMPLETE and AUTH chunks MUST be ignored. 231 3.3. Requested HMAC Algorithm Parameter (HMAC-ALGO) 233 This parameter is used to list the HMAC identifiers the peer MUST 234 use. 236 0 1 2 3 237 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 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Parameter Type = 0x8004 | Parameter Length | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | HMAC Identifier 1 | HMAC Identifier 2 | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 / / 244 \ ... \ 245 / / 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | HMAC Identifier n | Padding | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 Figure 3 252 Parameter Type: 2 bytes (unsigned integer) 253 This value MUST be set to 0x8004. 255 Parameter Length: 2 bytes (unsigned integer) 256 This value is the number of HMAC identifiers multiplied by 2 plus 257 4. 259 HMAC Identifier n: 2 bytes (unsigned integer) 260 The values expressed are a list of HMAC identifiers that may be 261 used by the peer. The values are listed by preference, with 262 respect to the sender, where the first HMAC identifier listed is 263 the one most preferable to the sender. 265 Padding: 0 or 2 bytes (unsigned integer) 266 If the number of HMAC Identifiers is not even, the sender MUST pad 267 the parameter with all zero bytes to make the parameter 32-bit 268 aligned. The Padding MUST be 0 or 2 bytes long and it MUST be 269 ignored by the receiver. 271 The HMAC-ALGO parameter MUST be included once in the INIT or INIT-ACK 272 chunk if the sender wants to send or receive authenticated chunks. 274 The following Table 2 shows the currently defined values for HMAC 275 identifiers. 277 +-----------------+--------------------------+ 278 | HMAC Identifier | Message Digest Algorithm | 279 +-----------------+--------------------------+ 280 | 0 | Reserved | 281 | 1 | SHA-1 defined in [8] | 282 | 2 | Reserved | 283 | 3 | SHA-256 defined in [8] | 284 +-----------------+--------------------------+ 286 Table 2 288 Every endpoint supporting SCTP chunk authentication MUST support the 289 HMAC based on the SHA-1 algorithm. 291 4. New Error Cause 293 This section defines a new error cause that will be sent if an AUTH 294 chunk is received with an unsupported HMAC identifier. Table 3 295 illustrates the new error cause. 297 +------------+-----------------------------+ 298 | Cause Code | Error Cause Name | 299 +------------+-----------------------------+ 300 | 0x0105 | Unsupported HMAC Identifier | 301 +------------+-----------------------------+ 303 Table 3 305 4.1. Unsupported HMAC Identifier error cause 307 This error cause is used to indicate that an AUTH chunk was received 308 with an unsupported HMAC Identifier. 310 0 1 2 3 311 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 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Cause Code = 0x0105 | Cause Length = 6 | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | HMAC Identifier | Padding | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 Figure 4 319 Cause Code: 2 bytes (unsigned integer) 320 This value MUST be set to 0x0105. 322 Cause Length: 2 bytes (unsigned integer) 323 This value MUST be set to 6. 325 HMAC Identifier: 2 bytes (unsigned integer) 326 This value is the HMAC Identifier which is not supported. 328 Padding: 2 bytes (unsigned integer) 329 The sender MUST pad the error cause with all zero bytes to make 330 the cause 32-bit aligned. The Padding MUST be 2 bytes long and it 331 MUST be ignored by the receiver. 333 5. New Chunk Type 335 This section defines the new chunk type that will be used to 336 authenticate chunks. Table 4 illustrates the new chunk type. 338 +------------+-----------------------------+ 339 | Chunk Type | Chunk Name | 340 +------------+-----------------------------+ 341 | 0x0F | Authentication Chunk (AUTH) | 342 +------------+-----------------------------+ 344 Table 4 346 It should be noted that the AUTH-chunk format requires the receiver 347 to ignore the chunk if it is not understood and silently discard all 348 chunks that follow. This is accomplished as described in RFC2960 [5] 349 section 3.2. by the use of the upper bits of the chunk type. 351 5.1. Authentication Chunk (AUTH) 353 This chunk is used to hold the result of the HMAC calculation. 355 0 1 2 3 356 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 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Type = 0x0F | Flags=0 | Length | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Shared Key Identifier | HMAC Identifier | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | | 363 \ HMAC / 364 / \ 365 / +-------------------------------\ 366 | | Padding | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 Figure 5 371 Type: 1 byte (unsigned integer) 372 This value MUST be set to 0x0F for all AUTH-chunks. 374 Flags: 1 byte (unsigned integer) 375 SHOULD be set to zero on transmit and MUST be ignored on receipt. 377 Length: 2 bytes (unsigned integer) 378 This value holds the length of the HMAC in bytes plus 8. 380 Shared Key Identifier: 2 bytes (unsigned integer) 381 This value describes which endpoint pair shared key is used. 383 HMAC Identifier: 2 bytes (unsigned integer) 384 This value describes which message digest is being used. Table 2 385 shows the currently defined values. 387 HMAC: n bytes (unsigned integer) 388 This hold the result of the HMAC calculation. 390 Padding: 0, 1, 2, or 3 bytes (unsigned integer) 391 If the length of the HMAC is not a multiple of 4 bytes, the sender 392 MUST pad the chunk with all zero bytes to make the chunk 32-bit 393 aligned. The Padding MUST NOT be longer than 3 bytes and it MUST 394 be ignored by the receiver. 396 The control chunk AUTH MUST NOT appear more than once in an SCTP 397 packet. All control and data chunks which are placed after the AUTH 398 chunk in the packet are sent in an authenticated way. Those chunks 399 placed in a packet before the AUTH chunk are not authenticated. 400 Please note that DATA chunks can not appear before control chunks in 401 an SCTP packet. 403 6. Procedures 405 6.1. Establishment of an association shared key 407 An SCTP endpoint willing to receive or send authenticated chunks MUST 408 send one RANDOM parameter in its INIT or INIT-ACK chunk. The RANDOM 409 parameter MUST contain a 32 byte random number. The random number 410 should be generated in accordance with RFC4086 [7]. If the random 411 number is not 32 byte long the association MUST be aborted. The 412 ABORT chunk SHOULD contain the error cause 'Protocol Violation'. In 413 case of INIT collision, the rules governing the handling of this 414 random number follow the same pattern as those for the Verification 415 Tag, as explained in section 5.2.4 of RFC2960 [5]. Therefore each 416 endpoint knows its own random number and the peer's random number 417 after the association has been established. 419 An SCTP endpoint has a list of chunks it only accepts if they are 420 received in an authenticated way. This list is included in the INIT 421 and INIT-ACK and MAY be omitted if it is empty. Since this list does 422 not change during the lifetime of there is no problem in case of INIT 423 collision. 425 Each SCTP endpoint MUST include in the INIT and INIT-ACK a HMAC-ALGO 426 parameter containing a list of HMAC Identifiers it requests the peer 427 to use. The receiver of a HMAC-ALGO parameter SHOULD use the first 428 listed algorithm it supports. The HMAC algorithm based on SHA-1 MUST 429 be supported and included in the HMAC-ALGO parameter. An SCTP 430 endpoint MUST NOT change the parameters listed in the HMAC-ALGO 431 parameter during the lifetime of the endpoint. 433 Both endpoints of an association MAY have endpoint pair shared keys 434 which are byte vectors and pre-configured or established by another 435 mechanism. They are identified by the shared key identifier. For 436 each endpoint pair shared key an association shared key is computed. 437 If there is no endpoint pair shared key only one association shared 438 key is computed by using an empty byte vector as the endpoint pair 439 shared key. 441 The RANDOM parameter, the CHUNKS parameter and the HMAC-ALGO 442 parameter sent by each endpoint are concatenated as byte vectors. 443 These parameters include the parameter type, parameter length, and 444 the parameter value, but padding is omitted; all padding MUST be 445 removed from this concatenation before proceeding with further 446 computation of keys. Parameters which were not sent are simply 447 omitted from the concatenation process. The resulting two vectors 448 are called the two key vectors. 450 From the endpoint pair shared keys and the key vectors the 451 association shared keys are computed. This is performed by selecting 452 the numerically smaller key vector and concatenating it to the 453 endpoint pair shared key, and then concatenating the numerically 454 larger key vector to that. If the key vectors are equal as numbers 455 but differ in length, then the concatenation order is the endpoint 456 shared key, followed by the shorter key vector, followed by the 457 longer key vector. Otherwise, the key vectors are identical, and may 458 be concatenated to the endpoint pair key in any order. The 459 concatenation is performed on byte vectors, and all numerical 460 comparisons use network byte order to convert the key vectors to a 461 number. The result of the concatenation is the association shared 462 key. 464 6.2. Sending authenticated chunks 466 Endpoints MUST send all requested chunks authenticated where this has 467 been requested by the peer. The other chunks MAY be sent 468 authenticated or not. If endpoint pair shared keys are used, one of 469 them MUST be selected for authentication. 471 To send chunks in an authenticated way, the sender MUST include these 472 chunks after an AUTH chunk. This means that a sender MUST bundle 473 chunks in order to authenticate them. 475 If the endpoint has no endpoint pair shared key for the peer, it MUST 476 use Shared Key Identifier 0 with an empty endpoint pair shared key. 477 If there are multiple endpoint shared keys the sender selects one and 478 uses the corresponding Shared Key Identifier. 480 The sender MUST calculate the MAC as described in RFC2104 [2] using 481 the hash function H as described by the MAC Identifier and the shared 482 association key K based on the endpoint pair shared key described by 483 the shared key identifier. The 'data' used for the computation of 484 the AUTH-chunk is given by the AUTH chunk with its HMAC field set to 485 zero (as shown in Figure 6) followed by all chunks that are placed 486 after the AUTH chunk in the SCTP packet. 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Type = 0x0F | Flags=0 | Chunk Length | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Shared Key Identifier | HMAC Identifier | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | | 494 \ 0 / 495 / +-------------------------------\ 496 | | Padding | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 Figure 6 500 Please note that all fields are in network byte order and that the 501 field which will contain the complete HMAC is filled with zeroes. 502 The length of the field shown as 0 is the length of the HMAC 503 described by the HMAC Identifier. The padding of all chunks being 504 authenticated MUST be included in the HMAC computation. 506 The sender fills the HMAC into the HMAC field and sends the packet. 508 6.3. Receiving authenticated chunks 510 The receiver has a list of chunk types which it expects to be 511 received only after an AUTH-chunk. This list has been sent to the 512 peer during the association setup. It MUST silently discard these 513 chunks if they are not placed after an AUTH chunk in the packet. 515 The receiver MUST use the HMAC algorithm indicated in the HMAC 516 Identifier field. If this algorithm was not specified by the 517 receiver in the HMAC-ALGO parameter in the INIT or INIT-ACK chunk 518 during association setup, the AUTH chunk and all chunks after it MUST 519 be discarded and an ERROR chunk SHOULD be sent with the error cause 520 defined in Section 4.1. 522 If an endpoint with no shared key receives a Shared Key Identifier 523 other than 0, it MUST silently discard all authenticated chunks. If 524 the endpoint has at least one endpoint pair shared key for the peer, 525 it MUST use the key specified by the Shared Key Identifier if a key 526 has been configured for that Shared Key Identifier. If no endpoint 527 pair shared key has been configured for that Shared Key Identifier, 528 all authenticated chunks MUST be silently discarded. 530 The receiver now performs the same calculation as described for the 531 sender based on Figure 6. If the result of the calculation is the 532 same as given in the HMAC field, all chunks following the AUTH chunk 533 are processed. If the field does not match the result of the 534 calculation, all the chunks following the AUTH chunk MUST be silently 535 discarded. 537 It should be noted that if the receiver wants to tear down an 538 association in an authenticated way only, the handling of malformed 539 packets should not result in tearing down the association. 541 An SCTP implementation has to maintain state for each SCTP 542 association. In the following we call this data structure the SCTP 543 transmission control block (STCB). 545 When an endpoint requires COOKIE-ECHO chunks to be authenticated some 546 special procedures have to be followed because the reception of an 547 COOKIE-ECHO chunk might result in the creation of an SCTP 548 association. If a packet arrives containing an AUTH chunk as a first 549 chunk, a COOKIE-ECHO chunk as the second chunk and possibly more 550 chunks after them, and the receiver does not have an STCB for that 551 packet, then authentication is based on the contents of the COOKIE- 552 ECHO chunk. In this situation, the receiver MUST authenticate the 553 chunks in the packet by using the RANDOM parameters, CHUNKS 554 parameters and HMAC_ALGO parameters obtained from the COOKIE-ECHO 555 chunk, and possibly a local shared secret as inputs to the 556 authentication procedure specified in Section 6.3. If authentication 557 fails then the packet is discarded. If the authentication is 558 successful the COOKIE-ECHO and all chunks after the COOKIE-ECHO MUST 559 be processed. If the receiver has a STCB, it MUST process the AUTH 560 chunk as described above using the STCB from the existing association 561 to authenticate the COOKIE-ECHO chunk and all chunks after it. 563 If the receiver does not find a STCB for a packet containing an AUTH 564 chunk as the first chunk and not a COOKIE-ECHO chunk as the second 565 chunk, it MUST use the chunks after the AUTH chunk to look up an 566 existing association. If no association is found, the packet MUST be 567 considered as out of the blue. The out of the blue handling MUST be 568 based on the packet without taking the AUTH chunk into account. If 569 an association is found, it MUST process the AUTH chunk using the 570 STCB from the existing association as described earlier. 572 Requiring ABORT chunks and COOKIE-ECHO chunks to be authenticated 573 makes it impossible for an attacker to bring down or restart an 574 association as long as the attacker does not know the association 575 shared key. But it should also be noted that if an endpoint accepts 576 ABORT chunks only in an authenticated way, it may take longer to 577 detect that the peer is no longer available. If an endpoint accepts 578 COOKIE-ECHO chunks only in an authenticated way, the restart 579 procedure does not work, because the restarting end-point most likely 580 does not know the association shared key of the old association to be 581 restarted. However, if the restarting end-point does know the old 582 association shared key he can send successfully the COOKIE-ECHO chunk 583 in a way that it is accepted by the peer by using this old 584 association shared key for the packet containing the AUTH chunk. 585 After this operation both end-points have to use the new association 586 shared key. 588 If a server has an endpoint pair shared key with some clients it can 589 request the COOKIE_ECHO chunk to be authenticated and can ensure that 590 only associations from client with a correct endpoint pair shared key 591 are accepted. 593 Furthermore it is important that the cookie contained in an INIT-ACK 594 chunk and in a COOKIE-ECHO chunk MUST NOT contain any end-point pair 595 shared keys. 597 7. Examples 599 This section gives examples of message exchanges for association 600 setup. 602 The simplest way of using the extension described in this document is 603 given by the following message exchange. 605 ---------- INIT[RANDOM; CHUNKS; HMAC-ALGO] ----------> 606 <------- INIT-ACK[RANDOM; CHUNKS; HMAC-ALGO] --------- 607 -------------------- COOKIE-ECHO --------------------> 608 <-------------------- COOKIE-ACK --------------------- 610 Please note that the CHUNKS parameter is optional in the INIT and 611 INIT-ACK. 613 If the server wants to receive DATA chunks in an authenticated way, 614 the following message exchange is possible: 616 ---------- INIT[RANDOM; CHUNKS; HMAC-ALGO] ----------> 617 <------- INIT-ACK[RANDOM; CHUNKS; HMAC-ALGO] --------- 618 --------------- COOKIE-ECHO; AUTH; DATA -------------> 619 <----------------- COOKIE-ACK; SACK ------------------ 621 Please note that if the endpoint pair shared key depends on the 622 client and the server and that it is only known by the upper layer 623 this message exchange requires an upper layer intervention between 624 the processing of the COOKIE-ECHO chunk and the processing of the 625 AUTH and DATA chunk at the server side. This intervention may be 626 realized by a COMMUNICATION-UP notification followed by the 627 presentation of the endpoint pair shared key by the upper layer to 628 the SCTP stack, see for example section 10 of RFC2960 [5]. If this 629 intervention is not possible due to limitations of the API (for 630 example the socket API) the server might discard the AUTH and DATA 631 chunk making a retransmission of the DATA chunk necessary. If the 632 same endpoint pair shared key is used for multiple endpoints and does 633 not depend on the client this intervention might not be necessary. 635 8. IANA Considerations 637 [NOTE to RFC-Editor: 639 "RFCXXXX" is to be replaced by the RFC number you assign this 640 document. 642 ] 644 This document (RFCXXX) is the reference for all registrations 645 described in this section. All registrations need to be listed in 646 the document available at sctp-parameters [9]. The suggested changes 647 are described below. 649 8.1. A New Chunk Type 651 A chunk type for the AUTH chunk has to be assigned by IANA. It is 652 suggested to use the value given in Table 4. This requires an 653 additional line in the "CHUNK TYPES" table of sctp-parameters [9]: 655 CHUNK TYPES 657 ID Value Chunk Type Reference 658 ----- ---------- --------- 659 15 Authentication Chunk (AUTH) [RFCXXXX] 661 8.2. Three New Parameter Types 663 Parameter types have to be assigned for the RANDOM, CHUNKS, and HMAC- 664 ALGO parameter by IANA. It is suggested to use the values given in 665 Table 1. This requires two modifications of the "CHUNK PARAMETER 666 TPYES" tables in sctp-parameters [9]: The first change is the 667 addition of three new lines to the "INIT Chunk Parameter Types" 668 table: 670 Chunk Parameter Type Value 671 -------------------- ----- 672 Random 32770 (0x8002) 673 Chunk List 32771 (0x8003) 674 Requested HMAC Algorithm Parameter 32772 (0x8004) 676 The second required change is the addition of the same three lines to 677 the to the "INIT ACK Chunk Parameter Types" table. 679 8.3. A New Error Cause 681 An error cause for the Unsupported HMAC Identifier error cause has to 682 be assigned. It is suggested to use the value given in Table 3. 683 This requires an additional line of the "CAUSE CODES" table in sctp- 684 parameters [9]: 686 VALUE CAUSE CODE REFERENCE 687 ----- ---------------- --------- 688 261 (0x0105) Unsupported HMAC Identifier RFCXXXX 690 8.4. A New Table For HMAC Identifiers 692 HMAC Identifiers have to be maintained by IANA. Four initial values 693 should be assigned by IANA as described in Table 2. This requires a 694 new table "HMAC IDENTIFIERS" in sctp-parameters [9]: 696 HMAC Identifier Message Digest Algorithm REFERENCE 697 --------------- ------------------------ --------- 698 0 Reserved RFCXXXX 699 1 SHA-1 RFCXXXX 700 2 Reserved RFCXXXX 701 3 SHA-256 RFCXXXX 703 For registering at IANA a new HMAC Identifier in this table a request 704 has to be made to assign such a number. This number must be unique 705 and a message digest algorithm usable with the HMAC defined in 706 RFC2104 [2] MUST be specified. The "Specification Required" policy 707 of RFC2434 [4] MUST be applied. 709 9. Security Considerations 711 Without using endpoint shared keys this extension only protects 712 against modification or injection of authenticated chunks by 713 attackers who did not capture the initial handshake setting up the 714 SCTP association. 716 If an endpoint pair shared key is used even a true man in the middle 717 cannot inject chunks which are required to be authenticated even if 718 he intercepts the initial message exchange. The endpoint also knows 719 that it is accepting authenticated chunks from a peer who knows the 720 endpoint pair shared key. 722 The establishment of endpoint pair shared keys is out of scope of 723 this document. Other mechanisms can be used like using TLS or manual 724 configuration. 726 When an endpoint accepts COOKIE-ECHO chunks only in an authenticated 727 way the restart procedure does not work. Neither an attacker nor a 728 restarted end-point not knowing the association shared key can 729 perform an restart. However, if the association shared key is known, 730 it is possible to restart the association. 732 Because SCTP has already a mechanism built-in that handles the 733 reception of duplicated chunks, the presented solution makes use of 734 this functionality and does not provide a method to avoid replay 735 attacks by itself. Of course, this only works within each SCTP 736 association. Therefore a separate shared key is used for each SCTP 737 association to handle replay attacks covering multiple SCTP 738 associations. 740 Each endpoint presenting a list of more than one element in the HMAC- 741 ALGO parameter must be prepared that the peer uses the weakest 742 algorithm listed. 744 When an endpoint pair uses non-NULL endpoint pair shared keys and one 745 of the endpoints still accepts a NULL key an attacker who captured 746 the initial handshake can still inject or modify authenticated chunks 747 by using the NULL key. 749 10. Acknowledgments 751 The authors wish to thank David Black, Sascha Grau, Russ Housley, 752 Ivan Arias Rodriguez, Irene Ruengeler, and Magnus Westerlund for 753 their invaluable comments. 755 11. Normative References 757 [1] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 758 April 1992. 760 [2] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing 761 for Message Authentication", RFC 2104, February 1997. 763 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 764 Levels", BCP 14, RFC 2119, March 1997. 766 [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 767 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 769 [5] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 770 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, 771 "Stream Control Transmission Protocol", RFC 2960, October 2000. 773 [6] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer 774 Security over Stream Control Transmission Protocol", RFC 3436, 775 December 2002. 777 [7] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 778 Requirements for Security", BCP 106, RFC 4086, June 2005. 780 [8] National Institute of Standards and Technology, "Secure Hash 781 Standard", FIPS PUB 180-2, August 2002, 782 . 785 [9] 787 Authors' Addresses 789 Michael Tuexen 790 Muenster Univ. of Applied Sciences 791 Stegerwaldstr. 39 792 48565 Steinfurt 793 Germany 795 Email: tuexen@fh-muenster.de 797 Randall R. Stewart 798 Cisco Systems, Inc. 799 4875 Forest Drive 800 Suite 200 801 Columbia, SC 29206 802 USA 804 Email: rrs@cisco.com 806 Peter Lei 807 Cisco Systems, Inc. 808 8735 West Higgins Road 809 Suite 300 810 Chicago, IL 60631 811 USA 813 Phone: 814 Email: peterlei@cisco.com 815 Eric Rescorla 816 RTFM, Inc. 817 2064 Edgewood Drive 818 Palo Alto, CA 94303 819 USA 821 Phone: +1 650-320-8549 822 Email: ekr@rtfm.com 824 Full Copyright Statement 826 Copyright (C) The IETF Trust (2007). 828 This document is subject to the rights, licenses and restrictions 829 contained in BCP 78, and except as set forth therein, the authors 830 retain all their rights. 832 This document and the information contained herein are provided on an 833 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 834 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 835 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 836 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 837 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 838 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 840 Intellectual Property 842 The IETF takes no position regarding the validity or scope of any 843 Intellectual Property Rights or other rights that might be claimed to 844 pertain to the implementation or use of the technology described in 845 this document or the extent to which any license under such rights 846 might or might not be available; nor does it represent that it has 847 made any independent effort to identify any such rights. Information 848 on the procedures with respect to rights in RFC documents can be 849 found in BCP 78 and BCP 79. 851 Copies of IPR disclosures made to the IETF Secretariat and any 852 assurances of licenses to be made available, or the result of an 853 attempt made to obtain a general license or permission for the use of 854 such proprietary rights by implementers or users of this 855 specification can be obtained from the IETF on-line IPR repository at 856 http://www.ietf.org/ipr. 858 The IETF invites any interested party to bring to its attention any 859 copyrights, patents or patent applications, or other proprietary 860 rights that may cover technology that may be required to implement 861 this standard. Please address the information to the IETF at 862 ietf-ipr@ietf.org. 864 Acknowledgment 866 Funding for the RFC Editor function is provided by the IETF 867 Administrative Support Activity (IASA).