idnits 2.17.1 draft-ietf-tsvwg-sctp-auth-01.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 631. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 608. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 615. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 621. ** 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). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The chunk types for INIT, INIT-ACK, SHUTDOWN-COMPLETE and AUTH chunks MUST not be listed in the CHUNKS parameter. However, if a CHUNKS parameter is received then the types for INIT, INIT-ACK, SHUTDOWN-COMPLETE and AUTH chunks MUST be ignored. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Each SCTP endpoint MUST include in the INIT and INIT-ACK a HMAC-ALGO parameter containing a list of HMAC Identifiers it requests the peer to use. The receiver of a HMAC-ALGO parameter SHOULD use the first listed algorithm it supports. The HMAC algorithm based on SHA-1 MUST be supported and included in the HMAC-ALGO parameter. An SCTP endpoint MUST not change the parameters listed in the HMAC-ALGO parameter during the lifetime of the endpoint. -- 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 (October 15, 2005) is 6768 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) == Missing Reference: '7' is mentioned on line 236, but not defined == Unused Reference: '6' is defined on line 557, 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 2960 (ref. '4') (Obsoleted by RFC 4960) -- Possible downref: Non-RFC (?) normative reference: ref. '6' Summary: 6 errors (**), 0 flaws (~~), 7 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: April 18, 2006 R. Stewart 5 P. Lei 6 Cisco Systems, Inc. 7 E. Rescorla 8 RTFM, Inc. 9 October 15, 2005 11 Authenticated Chunks for Stream Control Transmission Protocol (SCTP) 12 draft-ietf-tsvwg-sctp-auth-01.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 April 18, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). 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 . . . . . . . . . . . . . . 10 66 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 68 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 69 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 70 11. Normative References . . . . . . . . . . . . . . . . . . . . . 13 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 72 Intellectual Property and Copyright Statements . . . . . . . . . . 15 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 bit 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 has to 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 times 2 220 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 [7] | 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 | 0x83 | 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 bit 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 = 0x83 | 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 0x83 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 can appear at most once in an SCTP packet. 339 All control and data chunks which are placed after the AUTH chunk in 340 the packet are sent in an authenticated way. Those chunks placed in 341 a packet before the AUTH chunk are not authenticated. Please note 342 that DATA chunks can not appear before control chunks in an SCTP 343 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 and concatenating it to the 382 endpoint pair shared key. Then concatenating the larger of the 383 random numbers to that. If both random numbers are equal they may be 384 concatenated to the endpoint pair key in any order. The 385 concatenation is performed on byte vectors representing all numbers 386 in network byte order. The result is the association shared key. 388 6.2. Sending authenticated chunks 390 Both endpoints MUST send all those chunks authenticated where this 391 has been requested by the peer. The other chunks MAY be sent 392 authenticated or not. If endpoint pair shared keys are used one of 393 them has to be selected for authentication. 395 To send chunks in an authenticated way, the sender has to include 396 these chunks after an AUTH chunk. This means that a sender MUST 397 bundle chunks in order to authenticate them. 399 The sender MUST calculate the MAC using the hash function H as 400 described by the MAC Identifier and the shared association key K 401 based on the endpoint pair shared key described by the shared key 402 identifier. The 'data' used for the computation of the AUTH-chunk is 403 given by Figure 6 and all chunks that are placed after the AUTH chunk 404 in the SCTP packet. RFC2104 [2] can be used as a guideline for 405 generating the MAC. 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Type = 0x83 | Flags=0 | Chunk Length | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Shared Key Identifier | HMAC Identifier | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | | 413 \ 0 / 414 / \ 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 Figure 6 419 Please note that all fields are in network byte order and that the 420 field which will contain the complete HMAC is filled with zeroes. 421 The length of the field shown as 0 is the length of the HMAC 422 described by the HMAC Identifier. The padding of all chunks being 423 authenticated has to be included in the HMAC computation. 425 The sender fills the HMAC into the HMAC field and sends the packet. 427 6.3. Receiving authenticated chunks 429 The receiver has a list of chunk types which it expects to be 430 received only after an AUTH-chunk. This list has been sent to the 431 peer during the association setup. It MUST silently discard these 432 chunks if they are not placed after an AUTH chunk in the packet. 434 The receiver MUST use the HMAC algorithm indicated in the HMAC 435 Identifier field. If this algorithm is not known the AUTH chunk and 436 all chunks after it MUST be discarded and an ERROR chunk SHOULD be 437 sent with the error cause defined in Section 4.1. 439 If the endpoints has no endpoint pair shared key for the peer it MUST 440 us an empty endpoint pair shared key regardless which Shared Key 441 Identifier is present in the AUTH chunk. If the endpoint has at 442 least one endpoint pair shared key for the peer it MUST use the key 443 specified by the Shared Key Identifier if a key has been configured 444 for that Shared Key Identifier. If no endpoint pair shared key has 445 been configured for that Shared Key Identifier all authenticated 446 chunks MUST be silently discarded. 448 The receiver now performs the same calculation as described for the 449 sender based on Figure 6. If the result of the calculation is the 450 same as given in the HMAC field, all chunks following the AUTH chunk 451 are processed. If the field does not match the result of the 452 calculation all these chunks MUST be silently discarded. 454 It should be noted that if the receiver wants to tear down an 455 association in an authenticated way only, the handling of malformed 456 packets should be in tune with this. 458 It should also be noted that if an endpoints accepts ABORT chunks 459 only in an authenticated way it may take longer to detect that the 460 peer is no longer available. If an endpoint accepts COOKIE chunks 461 only in an authenticated way the restart procedure does not work. 463 7. Examples 465 This section gives examples of message exchanges for association 466 setup. 468 The simplest way of using the extension described in this document is 469 given by the following message exchange. 471 ---------- INIT[RANDOM; CHUNKS; HMAC-ALGO] ----------> 472 <------- INIT-ACK[RANDOM; CHUNKS; HMAC-ALGO] --------- 473 -------------------- COOKIE-ECHO --------------------> 474 <-------------------- COOKIE-ACK --------------------- 476 Please note that the CHUNKS parameter is optional in the INIT and 477 INIT-ACK. 479 If the server wants to receive DATA chunks in an authenticated way, 480 the following message exchange is possible: 482 ---------- INIT[RANDOM; CHUNKS; HMAC-ALGO] ----------> 483 <------- INIT-ACK[RANDOM; CHUNKS; HMAC-ALGO] --------- 484 --------------- COOKIE-ECHO; AUTH; DATA -------------> 485 <----------------- COOKIE-ACK; SACK ------------------ 487 Please note that if the endpoint pair shared key depends on the 488 client and the server and that it is only known by the upper layer 489 this message exchange requires an upper layer intervention between 490 the processing of the COOKIE-ECHO chunk (COMMUNICATION-UP 491 notification followed by the presentation of the endpoint pair shared 492 key by the upper layer to the SCTP stack) and the processing of the 493 AUTH and DATA chunk. If this intervention is not possible due to 494 limitations of the API the server might discard the AUTH and DATA 495 chunk making a retransmission of the DATA chunk necessary. If the 496 same endpoint pair shared key is used for multiple endpoints and does 497 not depend on the client this intervention might not be necessary. 499 8. IANA Considerations 501 A chunk type for the AUTH chunk has to be assigned by IANA. It is 502 suggested to use the value given above. 504 Parameter types have to be assigned for the RANDOM, CHUNKS, and HMAC- 505 ALGO parameter by IANA. It is suggested to use the values given 506 above. 508 HMAC Identifiers have to be maintained by IANA. Three initial values 509 should be assigned by IANA as described above. 511 9. Security Considerations 513 This section is still incomplete. 515 If no endpoint pair shared key is used an attacker which captures the 516 association setup message exchange can later insert arbitrary packets 517 in an authenticated way. However, if the attacker did not capture 518 this initial message exchange he can not successfully inject chunks 519 which are required to be authenticated. 521 If an enpoint pair shared key is used even a true man in the middle 522 can not inject chunks which are required to be authenticated even if 523 he intercepts the initial message exchange. 525 Because SCTP has already a mechanism built-in that handles the 526 reception of duplicated chunks the presented solution makes use of 527 this functionality and does not provide a method to avoid replay 528 attacks by itself. Of course, this only works within each SCTP 529 association. Therefore a separate shared key is used for each SCTP 530 association to handle replay attacks covering multiple SCTP 531 associations. 533 10. Acknowledgments 535 The authors wish to thank Sascha Grau, Ivan Arias Rodriguez, for his 536 invaluable comments. 538 11. Normative References 540 [1] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 541 April 1992. 543 [2] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing 544 for Message Authentication", RFC 2104, February 1997. 546 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 547 Levels", BCP 14, RFC 2119, March 1997. 549 [4] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 550 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, 551 "Stream Control Transmission Protocol", RFC 2960, October 2000. 553 [5] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer 554 Security over Stream Control Transmission Protocol", RFC 3436, 555 December 2002. 557 [6] National Institute of Standards and Technology, "Secure Hash 558 Standard", FIPS PUB 180-1, April 1995, 559 . 561 Authors' Addresses 563 Michael Tuexen 564 Muenster Univ. of Applied Sciences 565 Stegerwaldstr. 39 566 48565 Steinfurt 567 Germany 569 Email: tuexen@fh-muenster.de 571 Randall R. Stewart 572 Cisco Systems, Inc. 573 4875 Forest Drive 574 Suite 200 575 Columbia, SC 29206 576 USA 578 Email: rrs@cisco.com 580 Peter Lei 581 Cisco Systems, Inc. 582 8735 West Higgins Road 583 Suite 300 584 Chicago, IL 60631 585 USA 587 Phone: 588 Email: peterlei@cisco.com 590 Eric Rescorla 591 RTFM, Inc. 592 2064 Edgewood Drive 593 Palo Alto, CA 94303 594 USA 596 Phone: +1 650-320-8549 597 Email: ekr@rtfm.com 599 Intellectual Property Statement 601 The IETF takes no position regarding the validity or scope of any 602 Intellectual Property Rights or other rights that might be claimed to 603 pertain to the implementation or use of the technology described in 604 this document or the extent to which any license under such rights 605 might or might not be available; nor does it represent that it has 606 made any independent effort to identify any such rights. Information 607 on the procedures with respect to rights in RFC documents can be 608 found in BCP 78 and BCP 79. 610 Copies of IPR disclosures made to the IETF Secretariat and any 611 assurances of licenses to be made available, or the result of an 612 attempt made to obtain a general license or permission for the use of 613 such proprietary rights by implementers or users of this 614 specification can be obtained from the IETF on-line IPR repository at 615 http://www.ietf.org/ipr. 617 The IETF invites any interested party to bring to its attention any 618 copyrights, patents or patent applications, or other proprietary 619 rights that may cover technology that may be required to implement 620 this standard. Please address the information to the IETF at 621 ietf-ipr@ietf.org. 623 Disclaimer of Validity 625 This document and the information contained herein are provided on an 626 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 627 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 628 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 629 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 630 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 631 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 633 Copyright Statement 635 Copyright (C) The Internet Society (2005). This document is subject 636 to the rights, licenses and restrictions contained in BCP 78, and 637 except as set forth therein, the authors retain all their rights. 639 Acknowledgment 641 Funding for the RFC Editor function is currently provided by the 642 Internet Society.