idnits 2.17.1 draft-hohendorf-secure-sctp-27.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year -- 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 06, 2019) is 1849 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Hohendorf 3 Internet-Draft University of Duisburg-Essen 4 Intended status: Experimental E. Unurkhaan 5 Expires: September 7, 2019 Mongolian University 6 T. Dreibholz 7 SimulaMet 8 March 06, 2019 10 Secure SCTP 11 draft-hohendorf-secure-sctp-27 13 Abstract 15 This document explains the reason for the integration of security 16 functionality into SCTP, and gives a short description of S-SCTP and 17 its services. S-SCTP is fully compatible with SCTP defined in 18 RFC4960, it is designed to integrate cryptographic functions into 19 SCTP. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 7, 2019. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. A brief description of S-SCTP . . . . . . . . . . . . . . . . 3 58 4. Key terms . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 5. Additional chunks and parameters . . . . . . . . . . . . . . 4 60 5.1. New type chunks and definitions . . . . . . . . . . . . . 4 61 5.1.1. Secure Session Open request chunk (SSOpReq) . . . . . 5 62 5.1.2. Secure Session Certificate chunk: (SSCert) . . . . . 8 63 5.1.3. Secure Session Open Acknowledge chunk (SSOpReq_Ack) . 10 64 5.1.4. Secure Session Server Key chunk (SSSerKey) . . . . . 11 65 5.1.5. Secure Session Client Key chunk (SSCliKey) . . . . . 14 66 5.1.6. Secure Session Open Complete chunk (SSOpCom) . . . . 16 67 5.1.7. Secure Session Close chunk (SSClose) . . . . . . . . 17 68 5.1.8. Secure Session Close Acknowledge chunk (SSClose_Ack) 18 69 5.1.9. Security Level Changed chunk (SecLevCHD) . . . . . . 18 70 5.1.10. Security Level Changed Acknowledged chunk 71 (SecLevCHD_Ack) . . . . . . . . . . . . . . . . . . . 19 72 5.1.11. Encrypted Data Chunk (EncData) . . . . . . . . . . . 19 73 5.1.12. Padding chunk (PADDING) . . . . . . . . . . . . . . . 20 74 5.1.13. Authentication chunk (AUTH) . . . . . . . . . . . . . 21 75 6. New Error Cause . . . . . . . . . . . . . . . . . . . . . . . 22 76 6.1. Secure Session failure . . . . . . . . . . . . . . . . . 22 77 6.2. Secure Session Certificate failure . . . . . . . . . . . 23 78 6.3. Decryption failure . . . . . . . . . . . . . . . . . . . 24 79 6.4. Authentication failure . . . . . . . . . . . . . . . . . 24 80 6.5. Decompression failure . . . . . . . . . . . . . . . . . . 24 81 7. S-SCTP packet format and security levels . . . . . . . . . . 25 82 8. S-SCTP data format . . . . . . . . . . . . . . . . . . . . . 25 83 9. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 26 84 9.1. Establishment of a secure session . . . . . . . . . . . . 26 85 9.2. Choice of cipher suite and compression method . . . . . . 28 86 9.3. Data transfer . . . . . . . . . . . . . . . . . . . . . . 29 87 9.4. Closing of a secure session . . . . . . . . . . . . . . . 30 88 9.5. Generation of the Master secret key . . . . . . . . . . . 30 89 9.6. Update of the master secret key . . . . . . . . . . . . . 31 90 9.7. Random number generation . . . . . . . . . . . . . . . . 32 91 9.8. HMAC algorithm . . . . . . . . . . . . . . . . . . . . . 32 92 10. HMAC algorithm . . . . . . . . . . . . . . . . . . . . . . . 32 93 11. S-SCTP to ULP . . . . . . . . . . . . . . . . . . . . . . . . 34 94 12. Transmission Control Block (TCB) extension . . . . . . . . . 35 95 13. Socket API extensions for Secure SCTP . . . . . . . . . . . . 36 96 14. Testbed Platform . . . . . . . . . . . . . . . . . . . . . . 38 97 15. Security Considerations . . . . . . . . . . . . . . . . . . . 38 98 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 99 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 100 17.1. Normative References . . . . . . . . . . . . . . . . . . 38 101 17.2. Informative References . . . . . . . . . . . . . . . . . 39 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 104 1. Introduction 106 SCTP is a message oriented reliable transmission protocol which works 107 on top of the IP-based network. It provides several advantages over 108 other transmission protocols, such as TCP and UDP over IP. One of 109 the advantages is multistreaming -- user data transported by 110 individual streams. When multistreaming is used, network blocking 111 can be avoided in certain cases (e.g. network loss). Also, SCTP 112 supports multihoming -- the endpoints support multiple IP addresses. 113 SCTP provides unordered delivery, so that a receiver immediately 114 delivers user data to the upper layers upon receipt. For more 115 details, see RFC4960 [RFC4960]. 117 2. Conventions 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 121 "OPTIONAL" in this document are to be interpreted as described in BCP 122 14 [RFC2119] [RFC8174] when, and only when, they appear in all 123 capitals, as shown here. 125 3. A brief description of S-SCTP 127 S-SCTP provides security functionalities in the transport layer 128 without the need for any other security protocols (e.g. TLS or IP- 129 sec). Normally, a data transport over SCTP can either be secured 130 with TLS or can be protected by IPsec. As both TLS over SCTP and 131 SCTP over IPsec have disadvantages in certain scenarios, it is 132 preferable to integrate cryptographic functions into SCTP. 134 The main issues for the security solutions TLS over SCTP RFC3436 135 [RFC3436] and SCTP over IPSec RFC3554 [RFC3554] is scalability with 136 the number of streams. For N secure streams, N TLS connections have 137 to be created, and N handshakes have to be performed. If N is small, 138 this is not a big issue, but as N grows larger, it becomes a problem 139 because a handshake is a slow and expensive process. So, when an 140 application performs N handshakes, the load in terms of memory use, 141 CPU use etc. increases linearly over time. This problem could be 142 overcome by using IPsec. However, IPsec is not so flexible and on 143 the other hand SCTP over IPsec has to establish new security 144 associations (SA) for newly added IP addresses in dynamic address 145 reconfiguration scenario. In this case, the application has to 146 configure a new SA and to negotiate a new key exchange. 148 4. Key terms 150 This part gives the definitions of the key terms, which are used in 151 this draft: 153 o Secure session: This is the session, which provides the security 154 functionalities for an established SCTP association. 156 o Master secret key: S-SCTP uses two kinds of secret keys. One is 157 the secret key for the S-SCTP packet authentication, and the other 158 is the secret key for the data encryption and decryption. 160 o Cipher suite: This is the suite of cryptographic algorithms, which 161 are used for key exchange, data encryption/decryption and the 162 packet authentication. 164 o Pre-enc-data: This is the collection of the data chunks, which 165 requires encryption. The data chunks are concatenated together 166 and create pre-enc-data. Pre-enc-data may include the padding 167 chunk. 169 o Cipher suite sequence: This is the bundle of cipher suites chosen 170 by an endpoint from the supported cipher suites. 172 5. Additional chunks and parameters 174 Several new chunks and parameters are defined in S-SCTP. This 175 section explains those chunks and parameters. All new chunks can be 176 bundled with other chunks. The new parameters follow the Type- 177 Length-Value format as defined in section 3.2.1 of RFC4960. 179 5.1. New type chunks and definitions 181 The following table shows the new chunks. All new chunks, except for 182 the Encrypted Data (EncData) chunk, Authentication (AUTH) chunk and 183 Padding (PADDING) chunk, are used for building the secure session and 184 to update the master secret key. The new chunks are to be 185 interpreted as described in Section 3.2 of RFC 4960, by the receiver. 187 Chunktype Chunk name 188 --------- --------------------- 189 0xD0 Secure Session Open Request Chunk 190 0xD1 Secure Session Certificate Chunk 191 0xD2 Secure Session Acknowledge Chunk 192 0xD3 Secure Session Server Key Chunk 193 0xD4 Secure Session Client Key Chunk 194 0xD5 Secure Session Open Complete Chunk 195 0xD6 Secure Session Close Chunk 196 0xD7 Secure Session Close Acknowledge Chunk 197 0xD8 Security Level Change Chunk 198 0xD9 Security Level Change Acknowledge Chunk 199 0x10 Encrypted Data Chunk 200 0x11 Authentication Chunk 201 0x12 Padding Chunk 203 The new parameters are defined in this section. 205 5.1.1. Secure Session Open request chunk (SSOpReq) 207 An endpoint creates the Secure Session Open Request chunk (see next 208 table)when it wishes to establish a secure session. The chunk can be 209 bundled with other chunks. The SSOpReq chunk can also be used to 210 update the master secret key or cipher suite after a secure session 211 establishment. During the association lifetime, both associated 212 endpoints can request an update of the master secret key or cipher 213 suite; in this case, the requesting endpoint sends the SSSOpReq chunk 214 immediately to the other endpoint. 216 0 1 2 3 217 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 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Type=0xD0 | Reserved=0 |CF| Length | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Version | Key material length | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 \ \ 224 / Optional parameters / 225 \ \ 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 CF: Certificate flag: 1 bit 230 This flag indicates whether or not the client will send a 231 certificate. It is set to 1 when the client sends a certificate. If 232 a receiver receives SSOpReq chunk with CF=1 and does not receive a 233 certificate it raises an error and terminates the secure session 234 initialisation. 236 Length: 16 bits unsigned integer 238 The length field contains the size of the chunk in bytes, including 239 the chunk header, version, random number length and optional 240 parameter(s). 242 Version: 16 bits unsigned integer 244 This field indicates the S-SCTP version 1.0. The high eight bits 245 indicate the major version, the low eight bits indicate minor 246 version. 248 Key material length: 16 bits unsigned integer 250 This number has two meanings: 252 o when the handshake is made using the RSA key exchange protocol, 253 the key material length defines the random number length, which is 254 generated by the server and client to calculate a master secret 255 key (see RSA parameters of the SSSerKey and SSCliKey chunks) 257 o when the handshake is made using the DH key exchange protocol, the 258 key material length defines the DH prime number length (see DH 259 parameters of the SSSerKey and SSCliKey chunks). For security 260 reasons, the key material length MUST be 512 bits (default) or 261 longer when the key exchange mechanism uses RSA, and 1024 bits 262 (default) or longer when the key exchange mechanism uses DH. The 263 key material length is increased in steps of 64 bits. If a user 264 defines the key material length to be shorter than the default 265 value, S-SCTP automatically sets it to the default. 267 Parameter(S): 269 SSOpReq chunk includes the cipher suite and compression method 270 parameters, which are described below: 272 Cipher suite parameter: 274 This parameter contains the cipher suites, which are chosen from all 275 supported cipher suites by the client. One of them is used for the 276 secure session. The user can choose certain cipher suites from the 277 cipher suites supported by the client. 279 0 1 2 3 280 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 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Type=30 | Length | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Cipher suite 1 | Cipher suite 2 | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | .............. | .............. | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Cipher suite N-1 | Cipher suite N | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 Cipher suite: 16 bits unsigned integer: 293 This field indicates a cipher suite, which is supported by the 294 client. The next table includes cipher suites supported in S-SCTP. 295 Additional cipher suites can be specified. 297 Value Cipher suite Key exchange Encryption Hash 298 ----- ------------------------- ------------ ---------- --------- 299 1 RSA_with_DES_CBC_MD5 RSA DES_CBC MD5 300 2 RSA_with_DES_CBC_SHA-1 RSA DES_CBC SHA-1 301 3 RSA_with_3DES_CBC_MD5 RSA 3DES_CBC MD5 302 4 RSA_with_3DES_CBC_SHA-1 RSA 3DES_CBC SHA-1 303 5 RSA_with_AES-128_CBC_MD5 RSA AES-128 MD5 304 6 RSA_with_AES-128_CBC_SHA-1 RSA AES-128 SHA-1 305 7 DH_with_DES_CBC_MD5 DH DES_CBC MD5 306 8 DH_with_DES_CBC_SHA-1 DH DES_CBC SHA-1 307 9 DH_with_3DES_CBC_MD5 DH 3DES_CBC MD5 308 10 DH_with_3DES_CBC_SHA-1 DH 3DES_CBC SHA-1 309 11 DH_with_AES-128_CBC_MD5 DH AES-128 MD5 310 12 DH_with_AES-128_CBC_SHA-1 DH AES-128 SHA-1 311 13 RSA_with_NULL_MD5 RSA NULL MD5 312 14 RSA_with_NULL_SHA-1 RSA NULL SHA-1 313 15 DH_with_NULL_MD5 DH NULL MD5 314 16 DH_with_NULL_SHA-1 DH NULL SHA-1 315 17 RSA_with_AES-192_CBC_MD5 RSA AES-192 MD5 316 18 RSA_with_AES-192_CBC_SHA-1 RSA AES-192 SHA-1 317 19 RSA_with_AES-256_CBC_MD5 RSA AES-256 MD5 318 20 RSA_with_AES-256_CBC_SHA-1 RSA AES-256 SHA-1 319 21 DH_with_AES-192_CBC_MD5 DH AES-192 MD5 320 22 DH_with_AES-192_CBC_SHA-1 DH AES-192 SHA-1 321 23 DH_with_AES-256_CBC_MD5 DH AES-256 MD5 322 24 DH_with_AES-256_CBC_SHA-1 DH AES-256 SHA-1 324 The hash algorithms, defined in cipher suites, are used only for the 325 S-SCTP packet authentication, and not for the signature of the 326 handshake messages. An S-SCTP implementation MUST at least support 327 the default cipher suite, DH_with_3DES_CBC_SHA-1 (value=0). If the 328 SSOpReq chunk does not contain a cipher suite parameter, then: 330 a.) S-SCTP will use the default, or: 332 b.) S-SCTP will use the old cipher suite. 334 The case "a" will be used at the beginning of the secure session. 335 The case "b" will be used when the SSOpReq chunk is created after a 336 secure session establishment. The signature schemes are derived from 337 both the client and server certificates, and may be different. 339 Compression method parameter 341 This parameter contains compression methods, which are used for data 342 compression. The data compression uses lossless compression methods. 343 The user chooses several compression methods and sends it to the 344 receiver. The receiver chooses one compression method. 346 0 1 2 3 347 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 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Compression | Compression | Compression | Compression | 350 | method 1 | method 2 | method 3 | method 4 | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | .... | .... | Compression | Compression | 353 | | | method N-1 | method N | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 Compression method: 8 bits unsigned char 358 This field indicates a compression method, which is supported by the 359 client. The next table includes compression methods supported in 360 S-SCTP. Additional compression methods can be specified. 362 Value Compression method 363 ----- --------------------- 364 1 Huffman Code 365 2 Lempel-Ziv Code 367 The secure session uses null compression when the SSOpReq chunk 368 contains no compression parameters. 370 5.1.2. Secure Session Certificate chunk: (SSCert) 372 This chunk can be sent by both endpoints. The certificate helps to 373 authenticate the endpoint, that establishes a S-SCTP session. This 374 chunk contains only one parameter, the certificate parameter. The 375 SSCert chunk is optional. For security reasons, both endpoints 376 SHOULD use a certificate to authenticate each other. 378 0 1 2 3 379 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 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Type=0xD1 | Reserved=0 | Length | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 \ \ 384 / Certificate / 385 \ \ 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 \ \ 388 / Optional parameter / 389 \ \ 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 Length: 16 bits unsigned integer 394 The length field contains the size of the chunk in bytes, including 395 the chunk header and parameter. 397 Certificate: Variable length 399 The certificate field contains the certificate of the endpoint. 400 S-SCTP uses the X.509v3 certificate which is defined in RFC5280 401 [RFC5280]. 403 Optional parameter 405 SSCert chunk has only one optional parameter. 407 Certificate parameter 409 The SSCert chunk uses the certificate parameter for additional 410 certificates, when the endpoint has two or more certificates. 412 0 1 2 3 413 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 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Type=33 | Length | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 \ \ 418 / Certificate / 419 \ \ 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 Certificate: Variable length 423 The endpoint can send two or more certificates. In this case the 424 certificate field contains the endpoint's additional certificate. 425 S-SCTP uses the X.509v3 certificate, which is defined in RFC5280 426 [RFC5280]. 428 5.1.3. Secure Session Open Acknowledge chunk (SSOpReq_Ack) 430 The Secure Session Open Acknowledge chunk is sent by the server to 431 tell the client that the secure session open request is accepted. 433 0 1 2 3 434 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 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | Type=0xD2 | Reserved=0 |CF| Length | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | Version | Cipher suite | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | Compression method | Reserved = 0 | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 CF: Certificate flag: 1 bit 445 This flag indicates whether or not the server has a certificate. 446 This flag is set to 1 when the server has a certificate, else it is 447 zero. 449 Length: 16 bits unsigned integer 451 The chunk length is 8 bytes, including the chunk header, version and 452 cipher suite field. 454 Version: 16 bits unsigned integer 456 This field indicates the S-SCTP version 1.0. The high eight bits 457 indicate the major version, the low eight bits indicate the minor 458 version. 460 Cipher suite: 16 bits unsigned integer 462 This field indicates the cipher suite, which is used for a secure 463 session. The cipher suite includes necessary information for the key 464 derivation, message encoding and MAC computation. The server uses 465 the following rules to choose the cipher suite: 467 o Client and Server do not have a certificate: Use DH key exchange. 469 o Client or Server has a certificate: Use DH key exchange. 471 o Client and Server have a RSA certificate: Use RSA key exchange. 473 o Client and Server have a DSS certificate: Use DH key exchange. 475 Compression method: 16 bits unsigned char 477 This field indicates the compression method, which is used for data 478 compression in the secure session. 480 5.1.4. Secure Session Server Key chunk (SSSerKey) 482 This chunk includes the parameter which is used for the key exchange 483 algorithm. The Server Key Exchange chunk consists of the chunk 484 header and one parameter. The parameter type depends on the key 485 exchange algorithm. 487 0 1 2 3 488 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 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | Type=0xD3 | Reserved=0 |SL| Length | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 \ \ 493 / Parameter / 494 \ \ 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 Security level (SL): 2 bits 499 This 2-bit value indicates a server's security level of the reserved 500 flags. 502 Length: 16 bit unsigned integer 504 The length field contains the size of the chunk in bytes, including 505 the chunk header and parameter. 507 Parameters: 509 The following two parameters define the key exchange protocols. 510 Their parameter formats are shown in the next two tables. When a 511 user specifies a new cipher suite with a new key exchange algorithm, 512 then they must define a new parameter. 514 Diffie-Hellman parameter 516 The SSSerKey chunk uses this parameter when the handshake is done via 517 the DH key exchange algorithm. 519 0 1 2 3 520 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 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | Type=0xD001 | Length | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | Length of DH prime number, P | Length of DH prmitive root, R | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | Length of DH public key, Y | Reserved=0 | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 \ \ 529 / DH prime number, P / 530 \ \ 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 \ \ 533 / DH primitive root, R / 534 \ \ 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 \ \ 537 / DH value, Y / 538 \ \ 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 \ \ 541 / Signature / 542 \ \ 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 Length: 16 bit unsigned integer 547 The length field contains the size of the parameter in bytes, 548 including the parameter header, length of DH prime number, length of 549 DH primitive root, length of DH public key, reserved, DH prime 550 number, DH primitive root, DH public key and signature. 552 Length of DH prime number, P: 16 bits unsigned integer 554 This field contains the size of the DH prime number. 556 Length of DH primitive root, Q: 16 bits unsigned integer 558 This field contains the size of the DH primitive root. The size of 559 the prime number is equal R, where R is a random number defined in 560 the SSOpReq chunk. 562 Length of DH value, Y: 16 bits unsigned integer 564 This field contains the size of the DH public key. 566 DH value, P: Variable length 567 This is the prime number of the DH key exchange protocol. 569 DH value, Q: Variable length 571 This is the primitive root of the prime number P. 573 DH value, Y: Variable length 575 This is the public key of the DH key exchange protocol. 577 Signature: Variable length 579 The field contains the signature which is derived from the chunk 580 header and the whole parameter except the signature field. The 581 signature computation uses the signature algorithm which is defined 582 in the server certificate. If the server does not have a 583 certificate, this field does not exist in the parameter. 585 RSA parameter 587 The SSSerKey chunk uses this parameter when the handshake uses the 588 RSA key exchange algorithm. 590 0 1 2 3 591 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 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Type=0xD002 | Length | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 \ \ 596 / Encrypted (random number, R) / 597 \ \ 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 \ \ 600 / Signature / 601 \ \ 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 Length: 16 bits unsigned integer 606 The length field contains the size of the parameter in bytes, 607 including the parameter header, the encrypted random number and the 608 signature. 610 Encrypted (Random number, R): Variable length 612 The random number is used to generate the secret keys for user data 613 encryption and authentication. The random number encryption uses the 614 client public key. 616 Signature: Variable length 618 The field contains the signature, which is derived from the chunk 619 header and the whole parameter except the signature field. The 620 signature computation uses the signature algorithm which is defined 621 in the server certificate. 623 5.1.5. Secure Session Client Key chunk (SSCliKey) 625 This chunk includes the parameters which are used for the key 626 exchange algorithm. The Secure Session Client Key Exchange chunk 627 consists of the chunk header and one parameter. The parameter format 628 depends on the key exchange algorithm. 630 0 1 2 3 631 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 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | Type=0xD4 | Reserved=0 |SL| Length | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 \ \ 636 / Parameter / 637 \ \ 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 Security level (SL): 2 bits 642 This 2-bit value indicates a client's security level. 644 Length: 16 bit unsigned integer 646 The length field contains the size of the chunk in bytes, including 647 the chunk header and parameter. 649 Parameters: 651 Two new parameters are defined here that can appear in the SSCliKey 652 chunk. Their parameter formats are shown in the next two tables. 654 Diffie-Hellman parameter 656 The SSCliKey chunk uses this parameter when the handshake uses the DH 657 key exchange algorithm. 659 0 1 2 3 660 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 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 | Type=0xD003 | Length | 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 \ \ 665 / DH value, Y / 666 \ \ 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 \ \ 669 / Signature / 670 \ \ 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 Length: 16 bit unsigned integer 675 The length field contains the size of the parameter in bytes, 676 including the parameter header, the DH public key and the signature. 678 DH value, Y: Variable length 680 This field contains the public key of the DH key exchange protocol. 682 Signature: Variable length 684 The field contains a signature which is derived from the chunk header 685 and the whole parameter except the signature field. The signature 686 computation uses the signature algorithm defined in the client 687 certificate. If the client does not have a certificate, then this 688 field does not exist in the parameter. 690 RSA parameter 692 The SSCliKey chunk uses this parameter when the handshake uses RSA 693 key exchange algorithm. 695 0 1 2 3 696 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 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | Type=0xD003 | Length | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 \ \ 701 / Encrypted (random number, R) / 702 \ \ 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 \ \ 705 / Signature / 706 \ \ 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 Length: 16 bits unsigned integer 711 The length field contains the size of the parameter in bytes, 712 including the parameter header, the encrypted random number and a 713 signature. 715 Encrypted (Random number): Variable length 717 This field contains the random number, encrypted by the server's 718 public key, which is used to generate the master secret key for 719 encryption and authentication. 721 Signature: Variable length 723 The field contains the signature which is derived from the chunk 724 header and the whole parameter except the signature field. The 725 signature computation uses the signature algorithm defined in the 726 server certificate. 728 5.1.6. Secure Session Open Complete chunk (SSOpCom) 730 This chunk is the last chunk of the handshake and it indicates the 731 completion of the secure session establishment. After receiving this 732 chunk the endpoint verifies the verification data which is contained 733 in the chunk. The secure session procedure is complete when the 734 verification is successful. Otherwise the secure session will be 735 closed. 737 0 1 2 3 738 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 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | Type=0xD5 | Reserved=0 | Length | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 \ \ 743 / Verification data / 744 \ \ 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 Length: 16 bits unsigned integer 749 The length field contains the size of the chunk in bytes, including 750 the chunk header and verification data. 752 Verification data: Variable length 754 The verification data contains a hashed value which is an output of 755 the HMAC function. The HMAC uses the authentication secret key, 756 which is individually generated by the endpoints. The HMAC input 757 contains all received secure session handshake chunks of the current 758 endpoint. Both endpoints compute the hash value individually and 759 exchange it using the SSOpCom chunk. The receiver computes the hash 760 value using the same algorithm as the sender, and compares it with 761 the verification data. If the receiver's computed value is the same 762 as the sender's verification data, then the receiver assures that the 763 secure session open is successfully completed. If it is not the 764 same, then the receiver sends an ERROR message to the sender, and 765 immediately closes the secure session. 767 5.1.7. Secure Session Close chunk (SSClose) 769 This chunk indicates a request to close the current secure session. 770 The sender MUST NOT send any encrypted or authenticated chunks after 771 it has sent this chunk. 773 0 1 2 3 774 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 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 | Type=0xD6 | Reserved=0 |OF| Length | 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 | TSN | 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 Outstanding flag (OF): 1 bit 783 This flag indicates that the endpoint has sent the SSClose chunk and 784 has no outstanding secured data. 786 Length: 16 bits unsigned integer 788 The length field contains the size of the chunk in bytes, including 789 the chunk header and TSN. 791 Transmission sequence number (TSN): 16 bits unsigned integer 793 This is the transmission sequence number of the data chunk that was 794 last encrypted and sent. The TSN helps the server to detect 795 outstanding EncData chunks. 797 5.1.8. Secure Session Close Acknowledge chunk (SSClose_Ack) 799 This chunk is used to acknowledge the receipt of the secure session 800 close chunk. When the endpoint receives the secure session close 801 chunk, it immediately stops sending encrypted or authenticated 802 chunks. The Secure Session Close Acknowledge chunk only consists of 803 the chunk header. 805 0 1 2 3 806 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 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 | Type=0xD7 | Reserved=0 | Length=4 | 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 5.1.9. Security Level Changed chunk (SecLevCHD) 813 This chunk is used to convey the other associated endpoint of the 814 endpoint's new security level. The endpoint sends SecLevCHD chunk 815 every time it selects a new security level. The endpoint uses the 816 new selected security level when it receives the Security Level 817 Changed Acknowledged chunk. The sender MUST NOT send a new SecLevCHD 818 chunk when an unacknowledged SecLevCHD chunk exists. 820 0 1 2 3 821 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 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 | Type=0xD8 | Reserved=0 |SL| Length=4 | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 Security level (SL): 2 bits 828 This 2-bit value indicates the sender's new security level. 830 5.1.10. Security Level Changed Acknowledged chunk (SecLevCHD_Ack) 832 This chunk is used to acknowledge the receipt of the SecLevCHD chunk. 833 When the endpoint receives the SecLevCHD chunk, it immediately sends 834 the SecLevCHD_Ack chunk. 836 0 1 2 3 837 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 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | Type=0xD9 | Reserved=0 | Length=4 | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 5.1.11. Encrypted Data Chunk (EncData) 844 Each S-SCTP packet includes at most one encrypted data chunk, and the 845 packet could also include several (normal, unencrypted) data chunks. 846 The encrypted data chunk may contain one or several data chunks. The 847 EncData chunk includes a padding chunk when it is needed. 849 0 1 2 3 850 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 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 | Type=0x10 | Reserved=0 | Length | 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | Master secret key reference # | Random number length | 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 \ \ 857 / Random number / 858 \ \ 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 \ \ 861 / Encrypted data / 862 \ \ 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 Length: 16 bits unsigned integer 867 The length field contains the size of the chunk in bytes,including 868 the chunk header and encrypted data. 870 Master secret key reference number: 16 bits unsigned integer 872 The association can be updated by changing the master secret key 873 several times during the association lifetime. The association keeps 874 old secret keys. The number of the kept old secret keys depends on 875 the implementation. This field helps to identify which key (old or 876 new) has been used for encryption. That means the endpoint is able 877 to receive messages, which were encrypted with an old key, after the 878 update of a master secret key. 880 Random number length: 16 bits unsigned integer 882 This field contains the size of the random number which is defined 883 below. 885 Random number: Variable length 887 This field indicates the random number which is used as 888 initialisation vector of the cipher block chaining (CBC) mode for 889 encryption. 891 Encrypted data: Variable length 893 Contains a byte vector that consists of the encrypted data chunks. 894 Before encryption, the chunk(s) MUST fulfil the following conditions. 895 If encryption is performed using the DES or 3DES algorithm, the total 896 size of the chunk(s) MUST be a multiple of 8 bytes. If encryption is 897 performed using the AES algorithm, the total size of the chunk(s) 898 MUST be a multiple of 16 bytes. If the total size of the chunk(s) is 899 not a multiple of 8 bytes or 16 bytes, the sender MUST add 900 appropriate padding at the chunk's end. 902 5.1.12. Padding chunk (PADDING) 904 This padding chunk is used with an EncData chunk. The symmetric 905 encryption algorithms use a block oriented encryption of the user 906 data. For example DES uses 64 bit blocks, and AES uses 128 bit 907 blocks. Before encryption, the user data which has to be encrypted 908 has to be formatted according to the required block size. If the 909 last block is not completely full, padding has to be added. If less 910 than 4 bytes padding are required, the block is filled up will all 911 zeros. The receiver can calculate the number of padding bytes based 912 on the length field of the original data chunks. If 4 bytes or more 913 are required, a padding chunk of appropriate length is added. 915 The algorithms split user data into blocks when the data length is 916 greater than the block size. The blocks MUST be full. If 104 bits 917 are to be encrypted using DES algorithm with 64 bit block size, user 918 data is split into two blocks of 64 and 40 bits. The second block 919 must be padded with 24 bits up to the full block size of 64 bits. 921 0 1 2 3 922 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 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 | Type=0x12 | Reserved=0 | Length | 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 | Padding | 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 Length: Variable length 931 This field indicates the padding size. The padding follows the 932 padding chunk. The length includes the padding chunk and padding. 934 Padding: Variable length 936 The padding is a random number. The random number generation is 937 implementation specific. 939 5.1.13. Authentication chunk (AUTH) 941 This chunk is dedicated to the authentication of an S-SCTP packet. 942 S-SCTP inserts this chunk into the packet when the security level 943 requires authentication. 945 0 1 2 3 946 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 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 | Type=0x11 | Reserved=0 | Length | 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 | Master secret key reference # | Reserved=0 | 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 952 \ \ 953 / HMAC / 954 \ \ 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 957 Length: 16 bits unsigned integer 959 The length field contains the size of the chunk in bytes, including 960 the chunk header, master secret key reference, reserved field and 961 MAC. 963 Master secret key reference number: 16 bits unsigned integer 965 The association can update the secret keys several times during the 966 association lifetime. The association keeps old secret keys. The 967 number of the kept old secret keys depends on the implementation. 968 This field identifies the key which is used for authentication. If 969 the endpoint receives a message which was authenticated by an old 970 key, this message can still be authenticated after an update of the 971 master secret key. 973 HMAC: Variable length 975 This field contains the authentication code for the SCTP packet. The 976 message authentication uses the HMAC algorithm defined in RFC 2104. 977 The hash function used in the HMAC algorithm is derived from the 978 negotiated cipher suite, which was chosen by the server. 980 6. New Error Cause 982 This part explains the new error causes defined for S-SCTP. When a 983 secure session or certificate failure is detected in the secure 984 session open process, the S-SCTP association immediately stops the 985 process. However, the association continues (without any security 986 functionality). When the secure session failure happens during an 987 update of the master secret key the association stops the update 988 operation and closes the secure session. The following table shows 989 four general failure groups. 991 Cause Code Value Cause Code 992 ---------------- --------------------------------------- 993 0x20 Secure Session failure 994 0x21 Secure Session Certificate failure 995 0x22 Secure Session Decryption failure 996 0x23 Secure Session Authentication failure 997 0x24 Secure Session Decompression failure 999 6.1. Secure Session failure 1001 0 1 2 3 1002 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 1003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1004 | Cause Code=0x20 | Cause length = 8 | 1005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1006 | Error Code | Reserved=0 | 1007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1009 If any error happens in the secure session open and update process, 1010 endpoints alert their peers with these error codes. The next table 1011 shows error codes for what can happen. 1013 Error Code Value Error Code 1014 ---------------- ------------------------------------- 1015 0 Timer expired 1016 1 Signature failure 1017 2 Secure Session Open Complete failure 1019 o Timer expired: The sender starts a timer when it sends the secure 1020 session message. When the sender receives no response from the 1021 receiver before the timer expires, it sends this error code. 1023 o Signature failure: Some secure session chunks include a signature, 1024 which identifies and protects the secure session message. If the 1025 receiver checks the signature and cannot identify the chunk, this 1026 error code is used in the error chunk. 1028 o Secure Session Open Complete failure: This chunk is a very 1029 important part of the secure session. Both server and client 1030 individually compute the master secret and HMAC secret keys. Both 1031 sides check these secret keys and parameters (i.e. secure session 1032 chunks exchanged before, source and destination ports). If these 1033 keys are not identical, an error chunk is sent containing this 1034 error code. 1036 6.2. Secure Session Certificate failure 1038 0 1 2 3 1039 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 1040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1041 | Cause Code=0x21 | Cause length = 8 | 1042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1043 | Error Code | Reserved=0 | 1044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1046 The certificate failure signals that an error has occurred in 1047 processing the certificates. The next table shows error codes for 1048 what can happen. 1050 Error Code Value Error Code 1051 ---------------- ------------------------------------- 1052 0 No certificate 1053 1 Bad certificate 1054 2 Certificate expired 1055 3 Unknown certificate 1057 o No certificate: This error happens when the sender sets the CF 1058 flag and the receiver does not receive the certificate. 1060 o Bad certificate: The signature of the certificate is bad and the 1061 certificate could not be verified. 1063 o Certificate expired: The certificate is no longer valid. 1065 o Unknown certificate: The received certificate a X.509v3 1066 certificate. 1068 6.3. Decryption failure 1070 This error happens when the EncData chunk cannot be decrypted or the 1071 data chunk(s) cannot be identified after decryption. The receiver 1072 discards the EncData and increases a counter by 1. This counter 1073 counts errors. If the number of errors reaches a limit, the secure 1074 session is terminated. The limit of the errors depends on the 1075 implementation. 1077 0 1 2 3 1078 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 1079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1080 | Cause Code=0x22 | Cause length = 4 | 1081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 6.4. Authentication failure 1085 In the event of a HMAC error, the packet is discarded by the 1086 receiver. To check for an error, the receiver computes the HMAC and 1087 compares it to the HMAC field of the packet. If they do not match, 1088 an error is reported back. 1090 0 1 2 3 1091 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 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 | Cause Code=0x23 | Cause length = 4 | 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1096 6.5. Decompression failure 1098 This error happens when the compressed chunk(s) cannot be 1099 decompressed or the data chunk(s) cannot be identified after 1100 decompression. The receiver discards the decompressed chunk(s). 1102 0 1 2 3 1103 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 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1105 | Cause Code=0x24 | Cause length = 4 | 1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1108 7. S-SCTP packet format and security levels 1110 S-SCTP has four different security levels, which cover privacy 1111 settings of an S-SCTP association. The S-SCTP application can change 1112 the security levels at any time during the security session lifetime. 1114 o Security level 0: This is the null security level. S-SCTP does 1115 use neither data chunk encryption nor authentication. The S-SCTP 1116 packet is the same as the SCTP packet (this level is fully 1117 compatible to SCTP). 1119 o Security level 1: This security level requires packet 1120 authentication but does not use encryption. Every outgoing packet 1121 (including the SCTP common header) is authenticated. 1123 o Security level 2: In this security level, data chunks may be 1124 encrypted. When an S-SCTP packet contains an encrypted data 1125 chunk, it MUST include an AUTH chunk as well. That means every 1126 chunk and the packet header are authenticated. When a packet 1127 includes only unencrypted data chunks or control chunks or both 1128 unencrypted data chunks and control chunks, the packet will not be 1129 authenticated. 1131 o Security level 3: This is the highest security level. S-SCTP 1132 requires both encryption and authentication. Every outgoing chunk 1133 is encrypted and the packet is authenticated. 1135 Both endpoints can use different security levels, e.g. the 1136 association can use security functions only for one direction, e.g. 1137 from server to client. In this case the server uses security level 3 1138 and the client uses security level 0. The transmission control block 1139 (TCB) of the association includes the security level as a new 1140 parameter. 1142 8. S-SCTP data format 1144 S-SCTP sorts data chunks before bundling them into the outgoing SCTP 1145 packet. The data chunks are sorted according to whether they have to 1146 be encrypted or not. The chunks belonging to the encryption group 1147 are concatenated and encrypted into an EncData chunk. May be a 1148 PADDING chunk is inserted into the encryption group. Insertion of a 1149 PADDING chunk is done depending on data length and encryption block 1150 size. 1152 An assortment of encrypted and non-encrypted chunks are bundled in 1153 the packet. The control chunk(s) are placed first in the packet when 1154 bundled with other chunks. Finally, an AUTH chunk may be added to 1155 the packet. 1157 HMAC computation is performed over all chunks and the SCTP common 1158 header with a 0 checksum. The checksum is then computed over the 1159 complete packet (including AUTH chunk). The HMAC length depends on 1160 the hash function in the cipher suite. In every security level, the 1161 SCTP packet construction is slightly different. In security level 0 1162 the packet format is same as the SCTP packet format. 1164 9. Procedures 1166 In this section an explanation of the procedures of secure session: 1167 initialisation, termination, update and etc., is given. 1169 9.1. Establishment of a secure session 1171 The following process is used to establish the S-SCTP secure session. 1172 The handshake process runs in parallel with the data transmission. 1173 The secure session start and close is controlled by the user. The 1174 user can establish and close a secure session at any time during the 1175 association lifetime. Each time a secure session is established, a 1176 new set of keys is generated. It is not possible to create a new 1177 secure session when a secure session already exists. The following 1178 describes secure session establishment, which makes use of a 1179 handshake timer and retransmissions in case packets are lost during 1180 transmission. S-SCTP uses a four-way handshake. After all messages 1181 of one of the connection "legs" have been sent, client or server 1182 starts a RTO.hand (handshake retransmission time out) timer. For 1183 example, the secure session certificate is the last handshake message 1184 of the first leg. The sender waits for a response from the receiver 1185 until the RTO.hand timer expires. The sender stops the RTO.hand 1186 timer when it receives the expected message(s). If the RTO.hand 1187 timer expires before all expected messages have been received, the 1188 sender retransmits the handshake message(s). 1190 The retransmission uses the following algorithm. The RTO.hand timer 1191 gets a value from RTO of the path where the message is sent to, which 1192 is defined in RFC4960. Before a retransmission, the sender checks 1193 RTN.hand.max (handshake maximum retransmission number). This initial 1194 value is dependent upon specific implementations. The suggested 1195 value for RTN.hand.max is Path.Max.Retrans (see RFC 4960). 1197 RTN.hand.max should be a constant parameter. We introduce a counter 1198 for the number of retransmissions, and if that counter exceeds the 1199 parameter RTN.hand.max, the timer expired error message is sent to 1200 the peer. If a retransmission is required then S-SCTP uses the same 1201 retransmission rules as defined in RFC4960. If the receiver receives 1202 a retransmission of a handshake message that was already received, 1203 the message last received MUST be dropped. The endpoint discards the 1204 message(s) when they are unexpected. A secure session initialisation 1205 begins when one of the associated endpoints sets the security level 1206 to a value higher than 0. The endpoint starting a secure session 1207 initialisation is called client and the other associated endpoint is 1208 called server. 1210 o The client sends the SSOpReq chunk to the server. If the client 1211 has a certificate, it sets the CF flag of the SSOPReq chunk to 1. 1212 The client sends the SSCert chunk immediately after the SSOpReq 1213 chunk. The SSCert chunk can be bundled with the SSOpReq chunk or 1214 with other chunk(s). When the CF flag is set to 0, the client 1215 sends only the SSOpReq chunk. 1217 o The server receives a SSOpReq chunk and checks the CF flag. If 1218 the CF flag is set to 1, the server waits for the SSCert chunk. 1219 Upon receipt, the server checks the certificate and if there is a 1220 problem with it, the server stops the handshake and goes to an 1221 error state, aborts secure session setup and reports the cause to 1222 its peer. It there is no error, the server chooses the cipher 1223 suite and sends the SSOpReq_Ack chunk with CF=1 flag to the client 1224 when the server has a certificate. The server immediately sends 1225 the certificate and the SSSerKey chunks after the SSOpReq_Ack 1226 chunk. All three chunks may be bundled together or with other 1227 chunks. The server sends only the SSOpReq_Ack chunk with the 1228 SSSerKey chunk if CF=0. Before sending the server key exchange 1229 chunk, the server generates key material. The server starts the 1230 update master secret key operation when it receives the SSOpReq 1231 chunk after secure session establishment. If the server receives 1232 the SSCert chunk before the SSOpReq chunk, it stores the SSCert 1233 chunk and waits until it receives the SSOpReq chunk. But the 1234 server drops a second SSCert chunk. 1236 o The client receives the handshake messages and checks the 1237 certificate in the SSSerKey chunk. If the client detects any 1238 errors, it stops the handshake and goes to an error state, aborts 1239 secure session setup and reports the cause to its peer. The 1240 client generates key material and sends the SSCliKey chunk to the 1241 server. The client sends the SSOpCom chunk immediately after the 1242 client key exchange chunk. Before sending the handshake-finished 1243 chunk, the client computes the encryption secret and MAC secret 1244 keys. 1246 o The server receives the SSCliKey chunk and computes the master 1247 secret and the MAC secret keys. It then computes the SSOpCom 1248 chunk and sends it to the client. Finally, the server checks the 1249 SSOpCom chunk of the client. If the server detects any error, it 1250 reports a secure session open complete error and closes the 1251 handshake. The secure session is established only when both sides 1252 detect no errors. The server is ready for secure transmission 1253 when it detects no errors, but the client must wait for the 1254 SSOpCom chunk of the server. When this is received, the client 1255 checks it and reports to the peer a secure session open complete 1256 error if any error is detected before aborting secure session 1257 setup. The handshake may run simultaneously with normal SCTP data 1258 transmission. If the client receives encrypted or authenticated 1259 data chunks before it receives the server's SSOpCom chunk, then 1260 those chunks MUST be discarded. 1262 When both associated endpoints request the initialisation of a secure 1263 session simultaneously (both endpoints send an SSOpReq message), both 1264 ignore the received SSOpReq message and wait a random time before 1265 resending the SSOpReq message. Each endpoint generates the random 1266 time independently. The random number must be small, e.g. 120 1267 seconds maximum. 1269 9.2. Choice of cipher suite and compression method 1271 This section explains how to choose the cipher suite and compression 1272 method which are used for the secure session. Each endpoint 1273 maintains an ordered list of supported cipher suites (cipher suite 1274 list). The ordering in the list indicates the preference with which 1275 a cipher suite should be used (first in the list have higher 1276 preference). The order in the list is defined by the retrospective 1277 S-SCTP user. 1279 S-SCTP users on both sides can allow all cipher suited in the list 1280 when establishing a secure session or limit the allowed cipher suites 1281 to a subset. The complete list or the selected subset can be 1282 indicated to the server in the SSOpReq. If the complete list is 1283 sent, the default cipher suite list must be located first in the 1284 list. The server uses the following rules to choose the cipher suite 1285 to be used for the secure session: 1287 The server chooses the default cipher suite, if the SSOpReq chunk 1288 does not contain any cipher suite. 1290 The server gets the first cipher suites from SSOpReq chunk and 1291 server's cipher suite sequence. When both cipher suites are 1292 identical the server chooses this cipher suite for the secure 1293 session. Otherwise, the server takes its first cipher suite and 1294 looks for a match in the cipher suite sequence of the client. When 1295 there is no matche, the server takes the client's first cipher suite 1296 and searches for match in its cipher suite sequence. S-SCTP checks 1297 the first cipher suite in the SSOpReq chunk against all cipher suites 1298 in the cipher suite list of the server. If no match is found, all 1299 subsequent cipher suites in the SSOpReq are checked sequentially in 1300 the order they appear in the SSOPReq until a match is found. The 1301 first cipher suite supported by both endpoints is chosen. When two 1302 cipher suites match each other then this cipher suite is selected for 1303 the secure session. If not, the server looks, its second cipher 1304 suite, for a match in the cipher suite sequence of the client. 1305 Furthermore, the server uses the same mechanism to look a cipher 1306 suite for the secure session. 1308 The server chooses the default cipher suite, when the cipher suites 1309 in the SSOpReq chunk are not supported by the server. 1311 Both client and server also maintain a list of compression methods. 1312 The choice of the compression mechanism works similarly to the cipher 1313 suite selection mechanism described above. S-SCTP uses a NULL 1314 compression method as default compression method. 1316 9.3. Data transfer 1318 Before transporting the packet over the network, S-SCTP takes the 1319 following steps. First, it checks the security level. If the 1320 security level is: 1322 o 0, jump to step "d" 1324 o 1, jump to step "c" 1326 o 2, check the user data. If the user data requires encryption, 1327 jump to step "a" . If the user data does not require encryption, 1328 jump to step "c" 1330 o 3, jump to step "a" 1332 a) S-SCTP sorts data chunks in two groups, which are encrypted and 1333 unencrypted. The encrypted group consists of those data chunks 1334 requiring encryption. The unencrypted group consists of those 1335 data chunks not requiring encryption. If the secure session's 1336 security level is set to 3, all chunks are sorted into the 1337 encrypted group. 1339 b) The data chunks in the encrypted group are concatenated. After 1340 this, S-SCTP calculates the padding chunk and inserts the padding 1341 chunk on the last position into pre-enc-data if necessary. The 1342 Pre-enc-data size MUST be smaller than the current MTU. If the 1343 pre-enc-data is bigger than the current MTU, S-SCTP must create 1344 two pre-enc-datas. Every pre-enc-data is encrypted and stored in 1345 the encryption data field of the EncData chunk. 1347 c) SCTP builds the packet according to the security level and 1348 inserts the AUTH chunk in the last position in the packet. 1350 d) S-SCTP sends the packet. 1352 9.4. Closing of a secure session 1354 The termination of a secure session begins when one of the endpoints 1355 sends the secure session close chunk. This chunk includes the last 1356 encrypted data TSN and OF. The endpoint (sender) stops the 1357 encryption or authentication of all chunks or packets after it has 1358 sent the secure session close chunk. But normal (unsecured) data 1359 transfer will continue. The endpoint then waits until it receives 1360 the SSClose_Ack chunk. After receiving the SSClose_Ack chunk, the 1361 association clears the TCB parameters belonging to the secure 1362 session. The receiver (other endpoint) immediately stops encryption 1363 and authentication of all chunks or packets after it receives the 1364 secure session close chunk. Before sending the SSClose_Ack, the 1365 receiver waits for outstanding data (encrypted or authenticated 1366 data), which are the receiver's unacknowledged data chunks and 1367 sender's data chunks that have a TSN less than the last encrypted 1368 data TSN in the SSClose chunk. If the receiver does not receive the 1369 outstanding data chunks before RTO.hand timer expires, the S-SCTP 1370 association closes the secure session and outstanding data chunks 1371 will be dropped. The receiver ignores the last TSN of SSClose chunk 1372 and waits only for the receiver's unacknowledged data chunks when 1373 SSClose chunk's OF=1. The SSClose and SSClose_Ack chunks may be 1374 bundled with other chunks. If the sender does not receive the 1375 acknowledge chunk, the client follows the standard retransmission 1376 rule for messages. After the termination of the secure session, the 1377 TCB parameters belonging to the secure session MUST be set to zero. 1378 If the SCTP association begins to close the current association, the 1379 SSClose chunk is sent. If the SCTP association creates an ABORT 1380 chunk, the secure session closes immediately and the TCB parameters 1381 belonging to the secure session MUST be set to zero. 1383 9.5. Generation of the Master secret key 1385 Secret key generation uses the 3DES_CBC algorithm. Both server and 1386 client compute the master secret key separately. The key material is 1387 split into 64 bit blocks. Every block will be input to the 3DES_CBC 1388 encryption. The key material is as follows: 1390 o If the secure session key exchange algorithm uses DH, the key 1391 material consists of the DH's secret key. 1393 o If the secure session key exchange algorithm uses RSA, the key 1394 material consists of random numbers of both client and server. 1396 9.6. Update of the master secret key 1398 A secure update mechanism of the secret keys is a very important 1399 requirement for a secure session. The secret keys consist of the 1400 master secret key, which is used for data chunk encryption, and the 1401 HMAC secret key, which is used for packet authentication. If an 1402 association exists for a long time, the S-SCTP association needs to 1403 update the secret keys. Both the client and the server can request 1404 an update of the secret keys. A three way handshake, called an 1405 abbreviated handshake, is used to update the master secret keys. All 1406 actions of the handshake are encrypted by the current master secret 1407 key. The current security level does not affect the packets, which 1408 contain the handshake messages. The key update handshake works 1409 similar to the first establishment handshake (e.g. the endpoints 1410 start an RTO.hand timer when sending handshake chunks). Format and 1411 function of the chunks used to update keys are the same as for the 1412 handshake. When an endpoint receives a SSOpReq chunk (after a secure 1413 session establishment) it begins to update secret keys. Both the 1414 server and client key exchange chunks always use the RSA key exchange 1415 algorithm. The random numbers in SSSerKey and SSCliKey chunks are 1416 encrypted by the current master secret key. The following describes 1417 the method used to update the master secret key: 1419 The client generates a random number and sends the SSopReq chunk with 1420 the SSCliKey chunk. The key material length in the handshake request 1421 chunk may be equal to 0. If not, the number indicates the size of 1422 the new key material. If 0, both sides will use the key material 1423 length which was used in the last handshake. The server sends the 1424 SSop_Ack, the SSSerKey and the SSOpCom chunks immediately after 1425 receiving the SSOpReq and the SSCliKey chunks. After receiving the 1426 handshake messages from the server, the client computes a new master 1427 secret key and checks the SSOpCom chunk of the server. If it detects 1428 any error, the client closes the secure session and reports an error 1429 to the peer. The client computes the SSOpCom chunk and sends it to 1430 the server. After sending the SSOpCom chunk the client is ready to 1431 use the new master secret key. The server receives the SSOpCom chunk 1432 of the client and checks the new keys. If it detects any error, the 1433 server closes the secure session and reports an error to the peer. 1434 Before receiving the client's SSOpCom chunk, the server discards any 1435 encrypted or authenticated chunk that make use of the new master 1436 secret key. 1438 The encrypted and unencrypted user data transmission works in 1439 parallel with the update operation. After the update operation, the 1440 new master secret key is used for data encryption and authentication. 1441 When both client and server receive an SSOpReq chunk simultaneously, 1442 the client ignores the server's SSopReq chunk and the server accepts 1443 the client's SSOpReq chunk. The next steps are the same as for the 1444 secure session initialisation. 1446 The new master secret key generation uses the same algorithm as 1447 described above. The secure session includes one parameter which is 1448 called secure session lifetime. This parameter is used to initialise 1449 a timer which indicates the secure session secret key's lifetime in 1450 seconds. When the timer expires, the association automatically 1451 updates the secret keys. The user can define this parameter. If the 1452 user does not define it, the parameter assumes a default value. This 1453 default value depends on the implementation. The implementation MUST 1454 define secure session's lifetime initial value. We suggest a value 1455 of 600 seconds for the lifetime as a compromise between security and 1456 overhead. 1458 9.7. Random number generation 1460 As the security of S-SCTP depends on the quality of the random number 1461 generator, we suggest to use one according to RFC4086 [RFC4086]. 1463 9.8. HMAC algorithm 1465 S-SCTP uses the HMAC algorithm which is defined in RFC2104 [RFC2104] 1466 for the packet authentication. 1468 10. HMAC algorithm 1470 ULP-to-SCTP primitives deliver upper layer requests to S-SCTP. The 1471 following part describes new ULP-to-SCTP primitives and thus enhances 1472 the section 10 of RFC4960. All new ULP-to-SCTP primitives described 1473 below are defined in the ssctp.h header file. 1475 INITSECSESS: This primitive initialises a new secure session. 1477 Format: {initSecSess(secure session ID, key material length, cipher 1478 suites list, compression methods list, certiticate(s) ) --> result} 1480 o secure session ID: This parameter identifies a secure session. 1482 o key material length: This defines the key material length which is 1483 used in the SSOPReq chunk. 1485 o cipher suite list: Eligible cipher suites for a new secure 1486 session. 1488 o compression method list: Eligible compression methods for a new 1489 secure session. 1491 o certificate(s): Local endpoint certificate(s). 1493 SETSECLEVEL: This primitive sets a new security level for an existing 1494 secure session. 1496 Format: {setSecLevel(secure session ID, security level) --> result} 1498 o secure session ID: local handle to the secure session 1500 o security level: This parameter indicates the new security level 1502 GETSECLEVEL: This primitive gets the current security level of a 1503 secure session. 1505 Format: {getSecLevel(secure session ID) --> security level} 1507 o secure session ID: local handle to the secure session 1509 SENDSEC: This primitive sends secure data via S-SCTP. 1511 Format: {sctp_send_enc(association id, buffer address, byte count, 1512 context, stream id, life time, destination transport address, unorder 1513 flag, no-bundle flag, payload protocol-id, encryption flag, 1514 compression flag) --> result} 1516 Every parameter, except the encryption and compression flags, defined 1517 in this function is the same as the corresponding parameter defined 1518 in the SEND function of RFC4960 section 10. 1520 o encryption flag: This flag defines if a current user data message 1521 needs encryption or not. 1523 o compression flag: This flag defines if a current user data message 1524 needs compression or not. 1526 GETSECSTATUS: This primitive gets the security status of an 1527 association. The security status indicates if the SCTP association 1528 is using a secure session or not. 1530 Format: {setSecStatus(association ID) --> status} 1532 o association ID: local handle to the SCTP association. 1534 SETSECSESSTTL: This primitive sets a new lifetime for a secure 1535 session. 1537 Format: {setSecSessTTL(secure session ID, Time) --> result} 1538 o secure session ID: local handle to the secure session. 1540 o time: The new lifetime in seconds. 1542 SHUTSECSESS: This primitive deletes a secure session. 1544 Format: {shutSecSess(secure session ID) --> result} 1546 o secure session ID: local handle to the secure session. 1548 o security level: This parameter indicates the new security level. 1550 11. S-SCTP to ULP 1552 S-SCTP defines new notifications to deliver information to the upper 1553 layer. The notifications extend the section 10.2 of RFC4960 1554 [RFC4960]. All new notifications are defined in the ssctp.h header 1555 file. 1557 SECSESSUP: 1559 This notification indicates that S-SCTP is ready to send or receive 1560 secure data ({secsessUpNotif()}). 1562 SECSESSDOWN: 1564 This notification indicates that an association has lost a secure 1565 session ({secsessdownNotif()}). 1567 SECSESSREKEY: 1569 This notification indicates that a secure session updated the secret 1570 keys ({secsessrekeyNotif()}). 1572 Additional changes had to be made in the socket API implementation to 1573 access the new sctplib functions described above. A user calls the 1574 same socket API functions as in standard SCTP to send and receive 1575 user data, but has to set an additional encryption flag (MSG_ENC) to 1576 request encryption of user data. Also, a compression flag (MSG_COMP) 1577 has to be set in ext_send, ext_sendto, ext_sendmsg to request 1578 compression of user data. S-SCTP compression performs per user 1579 message not per chunk or per packet. In the SCTP DATA chunk, a new 1580 flag is defined, which indicates if the data is compressed or not. 1581 On the receiver side there are no changes. 1583 12. Transmission Control Block (TCB) extension 1585 A SCTP TCB contains parameters which are related to an association 1586 (e.g. an association id, port number, IP address list...). S-SCTP 1587 defines several parameters which are related to a secure session and 1588 it extends the TCB defined in section 12 of RFC4960. 1590 Security level: 1592 This parameter contains the association's current security level. 1594 Second security level: 1596 This is the security level of the associated second endpoint. 1598 Key material length: 1600 The size of the key material, which was last used for key generation. 1602 Secure session status: 1604 This parameter indicates whether the association is using a secure 1605 session or not. 1607 Secure session lifetime: 1609 This parameter indicates the lifetime of the secret keys of a secure 1610 session. 1612 Server indication: 1614 This parameter indicates if an endpoint is server or client. If the 1615 parameter is equal to 1 then it is a server, otherwise it is a 1616 client. 1618 Secure session ID: 1620 This parameter indicates the local secure session ID. 1622 Master secret key reference: 1624 This is an "array of secret data" collection and every array element 1625 includes the following parameters. 1627 o Selected cipher suite: This parameter indicates the encryption and 1628 authentication algorithms that are used in a secure session. 1630 o Selected compression: This parameter indicates the compression 1631 method that is used in a secure session. 1633 o Encryption key: This is a secret key which is used for encryption. 1635 o Authentication key: This is a secret key which is used for 1636 authentication. 1638 This information is used in EncData and AUTH chunks. 1640 13. Socket API extensions for Secure SCTP 1642 S-SCTP defines new socket options for the ext_setsockopt() and 1643 ext_getsockopt() socket functions to initialise, delete and rekey a 1644 secure session. A user calls the ext_setsockopt or ext_getsockopt 1645 functions with a new option. It is not necessary to define new 1646 socket API functions, as this is a more standard socket API fashion. 1647 The following paragraphs describe the new socket options. 1649 SSCTP-INIT: 1651 This socket option is used to initialise or update a secure session. 1652 The following structure is used to access these parameters. 1654 struct ssctp_init { 1655 uint16_t secsessID; 1656 uint16_t key_length; 1657 uint8_t num_cipher; 1658 uint8_t *cipher_suites; 1659 uint8_t num_comp; 1660 uint8_t *comp_methods; 1661 uint8_t *certificate; 1662 }; 1664 o secsessID: This parameter indicates a current secure session ID. 1666 o key_length: This parameter defines the length of a key material. 1668 o num_cipher: This parameter defines the number of cipher suites. 1670 o cipher_suites: This parameter includes a list of cipher suites. 1672 o num_comp: This parameter defines the number of compression 1673 methods. 1675 o comp_methods: This parameter includes a list of compression 1676 methods. 1678 o certificate: This parameter includes a certificate of the 1679 endpoint. 1681 SSCTP-SECLEVEL: 1683 This socket option is used to set and get a secure session security 1684 level. The following structure is used to access and modify these 1685 parameters. 1687 struct ssctp_seclevel { 1688 uint16_t secsessID; 1689 uint8_t seclevel; 1690 }; 1692 o secsessID: This parameter indicates a current secure session ID. 1693 This parameter MUST be zero when beginning a secure session 1694 initialisation. 1696 o seclevel: This parameter contains a new security level before 1697 socket write access or contains the current security level after 1698 socket read access. 1700 SSCTP-SECSTATUS: 1702 This socket option is used to get the secure session status and 1703 secure session ID when a secure session exists. The following 1704 structure is used to access these parameters. 1706 struct ssctp_secstatus { 1707 uint16_t secsessID; 1708 uint8_t sec_status; 1709 }; 1711 o secsessID: This parameter contains the current secure session ID. 1712 This parameter MUST be zero when a secure session does not exist. 1714 o sec_status: This parameter contains a security status. This 1715 parameter MUST be zero when a secure session does not exist. This 1716 parameter is equal to 1 when a secure session exists. 1718 SSCTP-SECSESSTTL: 1720 This socket option is used to set and get the secure session 1721 lifetime. The following structure is used to access and modify these 1722 parameters. 1724 struct ssctp_secsessTTL { 1725 uint16_t secsessID; 1726 uint16_t secsessTTL; 1727 }; 1729 o secsessID: This parameter indicates the current secure session ID. 1731 o secsessTTL (seconds): This parameter contains a new secure session 1732 lifetime before socket write access or contains a current secure 1733 session lifetime after socket read access. 1735 SSCTP-CLOSE: 1737 This socket option is used to close an existing secure session. The 1738 following structure is used to access these parameters. 1740 struct ssctp_secclose { 1741 uint16_t secsessID; 1742 }; 1744 o secsessID: This parameter contains the current secure session ID. 1746 14. Testbed Platform 1748 A large-scale and realistic Internet testbed platform with support 1749 for the multi-homing feature of the underlying SCTP protocol is 1750 NorNet. A description of NorNet is provided in [PAMS2013-NorNet], 1751 some further information can be found on the project website 1752 [NorNet-Website]. 1754 15. Security Considerations 1756 Security has been described in the previous sections. 1758 16. IANA Considerations 1760 This document introduces no additional considerations for IANA. 1762 17. References 1764 17.1. Normative References 1766 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1767 Hashing for Message Authentication", RFC 2104, 1768 DOI 10.17487/RFC2104, February 1997, 1769 . 1771 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1772 Requirement Levels", BCP 14, RFC 2119, 1773 DOI 10.17487/RFC2119, March 1997, 1774 . 1776 [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport 1777 Layer Security over Stream Control Transmission Protocol", 1778 RFC 3436, DOI 10.17487/RFC3436, December 2002, 1779 . 1781 [RFC3554] Bellovin, S., Ioannidis, J., Keromytis, A., and R. 1782 Stewart, "On the Use of Stream Control Transmission 1783 Protocol (SCTP) with IPsec", RFC 3554, 1784 DOI 10.17487/RFC3554, July 2003, 1785 . 1787 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1788 "Randomness Requirements for Security", BCP 106, RFC 4086, 1789 DOI 10.17487/RFC4086, June 2005, 1790 . 1792 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1793 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1794 . 1796 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1797 Housley, R., and W. Polk, "Internet X.509 Public Key 1798 Infrastructure Certificate and Certificate Revocation List 1799 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1800 . 1802 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1803 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1804 May 2017, . 1806 17.2. Informative References 1808 [NorNet-Website] 1809 Dreibholz, T., "NorNet - A Real-World, Large-Scale Multi- 1810 Homing Testbed", Online: https://www.nntb.no/, 2019, 1811 . 1813 [PAMS2013-NorNet] 1814 Dreibholz, T. and E. Gran, "Design and Implementation of 1815 the NorNet Core Research Testbed for Multi-Homed Systems", 1816 Proceedings of the 3nd International Workshop on Protocols 1817 and Applications with Multi-Homing Support (PAMS) Pages 1818 1094-1100, ISBN 978-0-7695-4952-1, 1819 DOI 10.1109/WAINA.2013.71, March 2013, 1820 . 1824 Authors' Addresses 1826 Carsten Hohendorf 1827 University of Duisburg-Essen, Institute for Experimental Mathematics 1828 Ellernstrasse 29 1829 45326 Essen, Nordrhein-Westfalen 1830 Germany 1832 Email: hohend@iem.uni-due.de 1834 Esbold Unurkhaan 1835 Mongolian University of Science and Technology 1836 Bayanzurkh duureg, 2-nd khoroo 1837 313/49 Ulaanbaatar 1838 Mongolia 1840 Email: esbold@csms.edu.mn 1842 Thomas Dreibholz 1843 Simula Metropolitan Centre for Digital Engineering 1844 Pilestredet 52 1845 0167 Oslo, Oslo 1846 Norway 1848 Phone: +47-6782-8200 1849 Fax: +47-6782-8201 1850 Email: dreibh@simula.no 1851 URI: https://www.simula.no/people/dreibh