idnits 2.17.1 draft-hohendorf-secure-sctp-25.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 5, 2018) is 2216 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 6, 2018 Mongolian University 6 T. Dreibholz 7 Simula@OsloMET 8 March 5, 2018 10 Secure SCTP 11 draft-hohendorf-secure-sctp-25.txt 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 http://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 6, 2018. 38 Copyright Notice 40 Copyright (c) 2018 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 (http://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", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 3. A brief description of S-SCTP 125 S-SCTP provides security functionalities in the transport layer 126 without the need for any other security protocols (e.g. TLS or IP- 127 sec). Normally, a data transport over SCTP can either be secured 128 with TLS or can be protected by IPsec. As both TLS over SCTP and 129 SCTP over IPsec have disadvantages in certain scenarios, it is 130 preferable to integrate cryptographic functions into SCTP. 132 The main issues for the security solutions TLS over SCTP RFC3436 133 [RFC3436] and SCTP over IPSec RFC3554 [RFC3554] is scalability with 134 the number of streams. For N secure streams, N TLS connections have 135 to be created, and N handshakes have to be performed. If N is small, 136 this is not a big issue, but as N grows larger, it becomes a problem 137 because a handshake is a slow and expensive process. So, when an 138 application performs N handshakes, the load in terms of memory use, 139 CPU use etc. increases linearly over time. This problem could be 140 overcome by using IPsec. However, IPsec is not so flexible and on 141 the other hand SCTP over IPsec has to establish new security 142 associations (SA) for newly added IP addresses in dynamic address 143 reconfiguration scenario. In this case, the application has to 144 configure a new SA and to negotiate a new key exchange. 146 4. Key terms 148 This part gives the definitions of the key terms, which are used in 149 this draft: 151 o Secure session: This is the session, which provides the security 152 functionalities for an established SCTP association. 154 o Master secret key: S-SCTP uses two kinds of secret keys. One is 155 the secret key for the S-SCTP packet authentication, and the other 156 is the secret key for the data encryption and decryption. 158 o Cipher suite: This is the suite of cryptographic algorithms, which 159 are used for key exchange, data encryption/decryption and the 160 packet authentication. 162 o Pre-enc-data: This is the collection of the data chunks, which 163 requires encryption. The data chunks are concatenated together 164 and create pre-enc-data. Pre-enc-data may include the padding 165 chunk. 167 o Cipher suite sequence: This is the bundle of cipher suites chosen 168 by an endpoint from the supported cipher suites. 170 5. Additional chunks and parameters 172 Several new chunks and parameters are defined in S-SCTP. This 173 section explains those chunks and parameters. All new chunks can be 174 bundled with other chunks. The new parameters follow the Type- 175 Length-Value format as defined in section 3.2.1 of RFC4960. 177 5.1. New type chunks and definitions 179 The following table shows the new chunks. All new chunks, except for 180 the Encrypted Data (EncData) chunk, Authentication (AUTH) chunk and 181 Padding (PADDING) chunk, are used for building the secure session and 182 to update the master secret key. The new chunks are to be 183 interpreted as described in Section 3.2 of RFC 4960, by the receiver. 185 Chunktype Chunk name 186 --------- --------------------- 187 0xD0 Secure Session Open Request Chunk 188 0xD1 Secure Session Certificate Chunk 189 0xD2 Secure Session Acknowledge Chunk 190 0xD3 Secure Session Server Key Chunk 191 0xD4 Secure Session Client Key Chunk 192 0xD5 Secure Session Open Complete Chunk 193 0xD6 Secure Session Close Chunk 194 0xD7 Secure Session Close Acknowledge Chunk 195 0xD8 Security Level Change Chunk 196 0xD9 Security Level Change Acknowledge Chunk 197 0x10 Encrypted Data Chunk 198 0x11 Authentication Chunk 199 0x12 Padding Chunk 201 The new parameters are defined in this section. 203 5.1.1. Secure Session Open request chunk (SSOpReq) 205 An endpoint creates the Secure Session Open Request chunk (see next 206 table)when it wishes to establish a secure session. The chunk can be 207 bundled with other chunks. The SSOpReq chunk can also be used to 208 update the master secret key or cipher suite after a secure session 209 establishment. During the association lifetime, both associated 210 endpoints can request an update of the master secret key or cipher 211 suite; in this case, the requesting endpoint sends the SSSOpReq chunk 212 immediately to the other endpoint. 214 0 1 2 3 215 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 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Type=0xD0 | Reserved=0 |CF| Length | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Version | Key material length | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 \ \ 222 / Optional parameters / 223 \ \ 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 CF: Certificate flag: 1 bit 228 This flag indicates whether or not the client will send a 229 certificate. It is set to 1 when the client sends a certificate. If 230 a receiver receives SSOpReq chunk with CF=1 and does not receive a 231 certificate it raises an error and terminates the secure session 232 initialisation. 234 Length: 16 bits unsigned integer 236 The length field contains the size of the chunk in bytes, including 237 the chunk header, version, random number length and optional 238 parameter(s). 240 Version: 16 bits unsigned integer 242 This field indicates the S-SCTP version 1.0. The high eight bits 243 indicate the major version, the low eight bits indicate minor 244 version. 246 Key material length: 16 bits unsigned integer 248 This number has two meanings: 250 o when the handshake is made using the RSA key exchange protocol, 251 the key material length defines the random number length, which is 252 generated by the server and client to calculate a master secret 253 key (see RSA parameters of the SSSerKey and SSCliKey chunks) 255 o when the handshake is made using the DH key exchange protocol, the 256 key material length defines the DH prime number length (see DH 257 parameters of the SSSerKey and SSCliKey chunks). For security 258 reasons, the key material length MUST be 512 bits (default) or 259 longer when the key exchange mechanism uses RSA, and 1024 bits 260 (default) or longer when the key exchange mechanism uses DH. The 261 key material length is increased in steps of 64 bits. If a user 262 defines the key material length to be shorter than the default 263 value, S-SCTP automatically sets it to the default. 265 Parameter(S): 267 SSOpReq chunk includes the cipher suite and compression method 268 parameters, which are described below: 270 Cipher suite parameter: 272 This parameter contains the cipher suites, which are chosen from all 273 supported cipher suites by the client. One of them is used for the 274 secure session. The user can choose certain cipher suites from the 275 cipher suites supported by the client. 277 0 1 2 3 278 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 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Type=30 | Length | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Cipher suite 1 | Cipher suite 2 | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | .............. | .............. | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Cipher suite N-1 | Cipher suite N | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 Cipher suite: 16 bits unsigned integer: 291 This field indicates a cipher suite, which is supported by the 292 client. The next table includes cipher suites supported in S-SCTP. 293 Additional cipher suites can be specified. 295 Value Cipher suite Key exchange Encryption Hash 296 ----- ------------------------- ------------ ---------- --------- 297 1 RSA_with_DES_CBC_MD5 RSA DES_CBC MD5 298 2 RSA_with_DES_CBC_SHA-1 RSA DES_CBC SHA-1 299 3 RSA_with_3DES_CBC_MD5 RSA 3DES_CBC MD5 300 4 RSA_with_3DES_CBC_SHA-1 RSA 3DES_CBC SHA-1 301 5 RSA_with_AES-128_CBC_MD5 RSA AES-128 MD5 302 6 RSA_with_AES-128_CBC_SHA-1 RSA AES-128 SHA-1 303 7 DH_with_DES_CBC_MD5 DH DES_CBC MD5 304 8 DH_with_DES_CBC_SHA-1 DH DES_CBC SHA-1 305 9 DH_with_3DES_CBC_MD5 DH 3DES_CBC MD5 306 10 DH_with_3DES_CBC_SHA-1 DH 3DES_CBC SHA-1 307 11 DH_with_AES-128_CBC_MD5 DH AES-128 MD5 308 12 DH_with_AES-128_CBC_SHA-1 DH AES-128 SHA-1 309 13 RSA_with_NULL_MD5 RSA NULL MD5 310 14 RSA_with_NULL_SHA-1 RSA NULL SHA-1 311 15 DH_with_NULL_MD5 DH NULL MD5 312 16 DH_with_NULL_SHA-1 DH NULL SHA-1 313 17 RSA_with_AES-192_CBC_MD5 RSA AES-192 MD5 314 18 RSA_with_AES-192_CBC_SHA-1 RSA AES-192 SHA-1 315 19 RSA_with_AES-256_CBC_MD5 RSA AES-256 MD5 316 20 RSA_with_AES-256_CBC_SHA-1 RSA AES-256 SHA-1 317 21 DH_with_AES-192_CBC_MD5 DH AES-192 MD5 318 22 DH_with_AES-192_CBC_SHA-1 DH AES-192 SHA-1 319 23 DH_with_AES-256_CBC_MD5 DH AES-256 MD5 320 24 DH_with_AES-256_CBC_SHA-1 DH AES-256 SHA-1 322 The hash algorithms, defined in cipher suites, are used only for the 323 S-SCTP packet authentication, and not for the signature of the 324 handshake messages. An S-SCTP implementation MUST at least support 325 the default cipher suite, DH_with_3DES_CBC_SHA-1 (value=0). If the 326 SSOpReq chunk does not contain a cipher suite parameter, then: 328 a.) S-SCTP will use the default, or: 330 b.) S-SCTP will use the old cipher suite. 332 The case "a" will be used at the beginning of the secure session. 333 The case "b" will be used when the SSOpReq chunk is created after a 334 secure session establishment. The signature schemes are derived from 335 both the client and server certificates, and may be different. 337 Compression method parameter 339 This parameter contains compression methods, which are used for data 340 compression. The data compression uses lossless compression methods. 341 The user chooses several compression methods and sends it to the 342 receiver. The receiver chooses one compression method. 344 0 1 2 3 345 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 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Compression | Compression | Compression | Compression | 348 | method 1 | method 2 | method 3 | method 4 | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | .... | .... | Compression | Compression | 351 | | | method N-1 | method N | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 Compression method: 8 bits unsigned char 356 This field indicates a compression method, which is supported by the 357 client. The next table includes compression methods supported in 358 S-SCTP. Additional compression methods can be specified. 360 Value Compression method 361 ----- --------------------- 362 1 Huffman Code 363 2 Lempel-Ziv Code 365 The secure session uses null compression when the SSOpReq chunk 366 contains no compression parameters. 368 5.1.2. Secure Session Certificate chunk: (SSCert) 370 This chunk can be sent by both endpoints. The certificate helps to 371 authenticate the endpoint, that establishes a S-SCTP session. This 372 chunk contains only one parameter, the certificate parameter. The 373 SSCert chunk is optional. For security reasons, both endpoints 374 SHOULD use a certificate to authenticate each other. 376 0 1 2 3 377 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 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Type=0xD1 | Reserved=0 | Length | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 \ \ 382 / Certificate / 383 \ \ 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 \ \ 386 / Optional parameter / 387 \ \ 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 Length: 16 bits unsigned integer 392 The length field contains the size of the chunk in bytes, including 393 the chunk header and parameter. 395 Certificate: Variable length 397 The certificate field contains the certificate of the endpoint. 398 S-SCTP uses the X.509v3 certificate which is defined in RFC5280 399 [RFC5280]. 401 Optional parameter 403 SSCert chunk has only one optional parameter. 405 Certificate parameter 407 The SSCert chunk uses the certificate parameter for additional 408 certificates, when the endpoint has two or more certificates. 410 0 1 2 3 411 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 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Type=33 | Length | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 \ \ 416 / Certificate / 417 \ \ 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 Certificate: Variable length 421 The endpoint can send two or more certificates. In this case the 422 certificate field contains the endpoint's additional certificate. 423 S-SCTP uses the X.509v3 certificate, which is defined in RFC5280 424 [RFC5280]. 426 5.1.3. Secure Session Open Acknowledge chunk (SSOpReq_Ack) 428 The Secure Session Open Acknowledge chunk is sent by the server to 429 tell the client that the secure session open request is accepted. 431 0 1 2 3 432 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 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | Type=0xD2 | Reserved=0 |CF| Length | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | Version | Cipher suite | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | Compression method | Reserved = 0 | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 CF: Certificate flag: 1 bit 443 This flag indicates whether or not the server has a certificate. 444 This flag is set to 1 when the server has a certificate, else it is 445 zero. 447 Length: 16 bits unsigned integer 449 The chunk length is 8 bytes, including the chunk header, version and 450 cipher suite field. 452 Version: 16 bits unsigned integer 454 This field indicates the S-SCTP version 1.0. The high eight bits 455 indicate the major version, the low eight bits indicate the minor 456 version. 458 Cipher suite: 16 bits unsigned integer 460 This field indicates the cipher suite, which is used for a secure 461 session. The cipher suite includes necessary information for the key 462 derivation, message encoding and MAC computation. The server uses 463 the following rules to choose the cipher suite: 465 o Client and Server do not have a certificate: Use DH key exchange. 467 o Client or Server has a certificate: Use DH key exchange. 469 o Client and Server have a RSA certificate: Use RSA key exchange. 471 o Client and Server have a DSS certificate: Use DH key exchange. 473 Compression method: 16 bits unsigned char 475 This field indicates the compression method, which is used for data 476 compression in the secure session. 478 5.1.4. Secure Session Server Key chunk (SSSerKey) 480 This chunk includes the parameter which is used for the key exchange 481 algorithm. The Server Key Exchange chunk consists of the chunk 482 header and one parameter. The parameter type depends on the key 483 exchange algorithm. 485 0 1 2 3 486 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 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Type=0xD3 | Reserved=0 |SL| Length | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 \ \ 491 / Parameter / 492 \ \ 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 Security level (SL): 2 bits 497 This 2-bit value indicates a server's security level of the reserved 498 flags. 500 Length: 16 bit unsigned integer 502 The length field contains the size of the chunk in bytes, including 503 the chunk header and parameter. 505 Parameters: 507 The following two parameters define the key exchange protocols. 508 Their parameter formats are shown in the next two tables. When a 509 user specifies a new cipher suite with a new key exchange algorithm, 510 then they must define a new parameter. 512 Diffie-Hellman parameter 514 The SSSerKey chunk uses this parameter when the handshake is done via 515 the DH key exchange algorithm. 517 0 1 2 3 518 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 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | Type=0xD001 | Length | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | Length of DH prime number, P | Length of DH prmitive root, R | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | Length of DH public key, Y | Reserved=0 | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 \ \ 527 / DH prime number, P / 528 \ \ 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 \ \ 531 / DH primitive root, R / 532 \ \ 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 \ \ 535 / DH value, Y / 536 \ \ 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 \ \ 539 / Signature / 540 \ \ 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 Length: 16 bit unsigned integer 545 The length field contains the size of the parameter in bytes, 546 including the parameter header, length of DH prime number, length of 547 DH primitive root, length of DH public key, reserved, DH prime 548 number, DH primitive root, DH public key and signature. 550 Length of DH prime number, P: 16 bits unsigned integer 552 This field contains the size of the DH prime number. 554 Length of DH primitive root, Q: 16 bits unsigned integer 556 This field contains the size of the DH primitive root. The size of 557 the prime number is equal R, where R is a random number defined in 558 the SSOpReq chunk. 560 Length of DH value, Y: 16 bits unsigned integer 562 This field contains the size of the DH public key. 564 DH value, P: Variable length 565 This is the prime number of the DH key exchange protocol. 567 DH value, Q: Variable length 569 This is the primitive root of the prime number P. 571 DH value, Y: Variable length 573 This is the public key of the DH key exchange protocol. 575 Signature: Variable length 577 The field contains the signature which is derived from the chunk 578 header and the whole parameter except the signature field. The 579 signature computation uses the signature algorithm which is defined 580 in the server certificate. If the server does not have a 581 certificate, this field does not exist in the parameter. 583 RSA parameter 585 The SSSerKey chunk uses this parameter when the handshake uses the 586 RSA key exchange algorithm. 588 0 1 2 3 589 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 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | Type=0xD002 | Length | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 \ \ 594 / Encrypted (random number, R) / 595 \ \ 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 \ \ 598 / Signature / 599 \ \ 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 Length: 16 bits unsigned integer 604 The length field contains the size of the parameter in bytes, 605 including the parameter header, the encrypted random number and the 606 signature. 608 Encrypted (Random number, R): Variable length 610 The random number is used to generate the secret keys for user data 611 encryption and authentication. The random number encryption uses the 612 client public key. 614 Signature: Variable length 616 The field contains the signature, which is derived from the chunk 617 header and the whole parameter except the signature field. The 618 signature computation uses the signature algorithm which is defined 619 in the server certificate. 621 5.1.5. Secure Session Client Key chunk (SSCliKey) 623 This chunk includes the parameters which are used for the key 624 exchange algorithm. The Secure Session Client Key Exchange chunk 625 consists of the chunk header and one parameter. The parameter format 626 depends on the key exchange algorithm. 628 0 1 2 3 629 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 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | Type=0xD4 | Reserved=0 |SL| Length | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 \ \ 634 / Parameter / 635 \ \ 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 Security level (SL): 2 bits 640 This 2-bit value indicates a client's security level. 642 Length: 16 bit unsigned integer 644 The length field contains the size of the chunk in bytes, including 645 the chunk header and parameter. 647 Parameters: 649 Two new parameters are defined here that can appear in the SSCliKey 650 chunk. Their parameter formats are shown in the next two tables. 652 Diffie-Hellman parameter 654 The SSCliKey chunk uses this parameter when the handshake uses the DH 655 key exchange algorithm. 657 0 1 2 3 658 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 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 | Type=0xD003 | Length | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 \ \ 663 / DH value, Y / 664 \ \ 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 \ \ 667 / Signature / 668 \ \ 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 Length: 16 bit unsigned integer 673 The length field contains the size of the parameter in bytes, 674 including the parameter header, the DH public key and the signature. 676 DH value, Y: Variable length 678 This field contains the public key of the DH key exchange protocol. 680 Signature: Variable length 682 The field contains a signature which is derived from the chunk header 683 and the whole parameter except the signature field. The signature 684 computation uses the signature algorithm defined in the client 685 certificate. If the client does not have a certificate, then this 686 field does not exist in the parameter. 688 RSA parameter 690 The SSCliKey chunk uses this parameter when the handshake uses RSA 691 key exchange algorithm. 693 0 1 2 3 694 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 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | Type=0xD003 | Length | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 \ \ 699 / Encrypted (random number, R) / 700 \ \ 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 \ \ 703 / Signature / 704 \ \ 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 Length: 16 bits unsigned integer 709 The length field contains the size of the parameter in bytes, 710 including the parameter header, the encrypted random number and a 711 signature. 713 Encrypted (Random number): Variable length 715 This field contains the random number, encrypted by the server's 716 public key, which is used to generate the master secret key for 717 encryption and authentication. 719 Signature: Variable length 721 The field contains the signature which is derived from the chunk 722 header and the whole parameter except the signature field. The 723 signature computation uses the signature algorithm defined in the 724 server certificate. 726 5.1.6. Secure Session Open Complete chunk (SSOpCom) 728 This chunk is the last chunk of the handshake and it indicates the 729 completion of the secure session establishment. After receiving this 730 chunk the endpoint verifies the verification data which is contained 731 in the chunk. The secure session procedure is complete when the 732 verification is successful. Otherwise the secure session will be 733 closed. 735 0 1 2 3 736 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 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | Type=0xD5 | Reserved=0 | Length | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 \ \ 741 / Verification data / 742 \ \ 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 Length: 16 bits unsigned integer 747 The length field contains the size of the chunk in bytes, including 748 the chunk header and verification data. 750 Verification data: Variable length 752 The verification data contains a hashed value which is an output of 753 the HMAC function. The HMAC uses the authentication secret key, 754 which is individually generated by the endpoints. The HMAC input 755 contains all received secure session handshake chunks of the current 756 endpoint. Both endpoints compute the hash value individually and 757 exchange it using the SSOpCom chunk. The receiver computes the hash 758 value using the same algorithm as the sender, and compares it with 759 the verification data. If the receiver's computed value is the same 760 as the sender's verification data, then the receiver assures that the 761 secure session open is successfully completed. If it is not the 762 same, then the receiver sends an ERROR message to the sender, and 763 immediately closes the secure session. 765 5.1.7. Secure Session Close chunk (SSClose) 767 This chunk indicates a request to close the current secure session. 768 The sender MUST NOT send any encrypted or authenticated chunks after 769 it has sent this chunk. 771 0 1 2 3 772 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 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 | Type=0xD6 | Reserved=0 |OF| Length | 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 | TSN | 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 Outstanding flag (OF): 1 bit 781 This flag indicates that the endpoint has sent the SSClose chunk and 782 has no outstanding secured data. 784 Length: 16 bits unsigned integer 786 The length field contains the size of the chunk in bytes, including 787 the chunk header and TSN. 789 Transmission sequence number (TSN): 16 bits unsigned integer 791 This is the transmission sequence number of the data chunk that was 792 last encrypted and sent. The TSN helps the server to detect 793 outstanding EncData chunks. 795 5.1.8. Secure Session Close Acknowledge chunk (SSClose_Ack) 797 This chunk is used to acknowledge the receipt of the secure session 798 close chunk. When the endpoint receives the secure session close 799 chunk, it immediately stops sending encrypted or authenticated 800 chunks. The Secure Session Close Acknowledge chunk only consists of 801 the chunk header. 803 0 1 2 3 804 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 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 | Type=0xD7 | Reserved=0 | Length=4 | 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 5.1.9. Security Level Changed chunk (SecLevCHD) 811 This chunk is used to convey the other associated endpoint of the 812 endpoint's new security level. The endpoint sends SecLevCHD chunk 813 every time it selects a new security level. The endpoint uses the 814 new selected security level when it receives the Security Level 815 Changed Acknowledged chunk. The sender MUST NOT send a new SecLevCHD 816 chunk when an unacknowledged SecLevCHD chunk exists. 818 0 1 2 3 819 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 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 | Type=0xD8 | Reserved=0 |SL| Length=4 | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 Security level (SL): 2 bits 826 This 2-bit value indicates the sender's new security level. 828 5.1.10. Security Level Changed Acknowledged chunk (SecLevCHD_Ack) 830 This chunk is used to acknowledge the receipt of the SecLevCHD chunk. 831 When the endpoint receives the SecLevCHD chunk, it immediately sends 832 the SecLevCHD_Ack chunk. 834 0 1 2 3 835 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 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 | Type=0xD9 | Reserved=0 | Length=4 | 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 5.1.11. Encrypted Data Chunk (EncData) 842 Each S-SCTP packet includes at most one encrypted data chunk, and the 843 packet could also include several (normal, unencrypted) data chunks. 844 The encrypted data chunk may contain one or several data chunks. The 845 EncData chunk includes a padding chunk when it is needed. 847 0 1 2 3 848 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 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 | Type=0x10 | Reserved=0 | Length | 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 | Master secret key reference # | Random number length | 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 \ \ 855 / Random number / 856 \ \ 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 \ \ 859 / Encrypted data / 860 \ \ 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 Length: 16 bits unsigned integer 865 The length field contains the size of the chunk in bytes,including 866 the chunk header and encrypted data. 868 Master secret key reference number: 16 bits unsigned integer 870 The association can be updated by changing the master secret key 871 several times during the association lifetime. The association keeps 872 old secret keys. The number of the kept old secret keys depends on 873 the implementation. This field helps to identify which key (old or 874 new) has been used for encryption. That means the endpoint is able 875 to receive messages, which were encrypted with an old key, after the 876 update of a master secret key. 878 Random number length: 16 bits unsigned integer 880 This field contains the size of the random number which is defined 881 below. 883 Random number: Variable length 885 This field indicates the random number which is used as 886 initialisation vector of the cipher block chaining (CBC) mode for 887 encryption. 889 Encrypted data: Variable length 891 Contains a byte vector that consists of the encrypted data chunks. 892 Before encryption, the chunk(s) MUST fulfil the following conditions. 893 If encryption is performed using the DES or 3DES algorithm, the total 894 size of the chunk(s) MUST be a multiple of 8 bytes. If encryption is 895 performed using the AES algorithm, the total size of the chunk(s) 896 MUST be a multiple of 16 bytes. If the total size of the chunk(s) is 897 not a multiple of 8 bytes or 16 bytes, the sender MUST add 898 appropriate padding at the chunk's end. 900 5.1.12. Padding chunk (PADDING) 902 This padding chunk is used with an EncData chunk. The symmetric 903 encryption algorithms use a block oriented encryption of the user 904 data. For example DES uses 64 bit blocks, and AES uses 128 bit 905 blocks. Before encryption, the user data which has to be encrypted 906 has to be formatted according to the required block size. If the 907 last block is not completely full, padding has to be added. If less 908 than 4 bytes padding are required, the block is filled up will all 909 zeros. The receiver can calculate the number of padding bytes based 910 on the length field of the original data chunks. If 4 bytes or more 911 are required, a padding chunk of appropriate length is added. 913 The algorithms split user data into blocks when the data length is 914 greater than the block size. The blocks MUST be full. If 104 bits 915 are to be encrypted using DES algorithm with 64 bit block size, user 916 data is split into two blocks of 64 and 40 bits. The second block 917 must be padded with 24 bits up to the full block size of 64 bits. 919 0 1 2 3 920 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 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 | Type=0x12 | Reserved=0 | Length | 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 | Padding | 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 Length: Variable length 929 This field indicates the padding size. The padding follows the 930 padding chunk. The length includes the padding chunk and padding. 932 Padding: Variable length 934 The padding is a random number. The random number generation is 935 implementation specific. 937 5.1.13. Authentication chunk (AUTH) 939 This chunk is dedicated to the authentication of an S-SCTP packet. 940 S-SCTP inserts this chunk into the packet when the security level 941 requires authentication. 943 0 1 2 3 944 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 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 | Type=0x11 | Reserved=0 | Length | 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 | Master secret key reference # | Reserved=0 | 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 \ \ 951 / HMAC / 952 \ \ 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 955 Length: 16 bits unsigned integer 957 The length field contains the size of the chunk in bytes, including 958 the chunk header, master secret key reference, reserved field and 959 MAC. 961 Master secret key reference number: 16 bits unsigned integer 963 The association can update the secret keys several times during the 964 association lifetime. The association keeps old secret keys. The 965 number of the kept old secret keys depends on the implementation. 966 This field identifies the key which is used for authentication. If 967 the endpoint receives a message which was authenticated by an old 968 key, this message can still be authenticated after an update of the 969 master secret key. 971 HMAC: Variable length 973 This field contains the authentication code for the SCTP packet. The 974 message authentication uses the HMAC algorithm defined in RFC 2104. 975 The hash function used in the HMAC algorithm is derived from the 976 negotiated cipher suite, which was chosen by the server. 978 6. New Error Cause 980 This part explains the new error causes defined for S-SCTP. When a 981 secure session or certificate failure is detected in the secure 982 session open process, the S-SCTP association immediately stops the 983 process. However, the association continues (without any security 984 functionality). When the secure session failure happens during an 985 update of the master secret key the association stops the update 986 operation and closes the secure session. The following table shows 987 four general failure groups. 989 Cause Code Value Cause Code 990 ---------------- --------------------------------------- 991 0x20 Secure Session failure 992 0x21 Secure Session Certificate failure 993 0x22 Secure Session Decryption failure 994 0x23 Secure Session Authentication failure 995 0x24 Secure Session Decompression failure 997 6.1. Secure Session failure 999 0 1 2 3 1000 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 1001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1002 | Cause Code=0x20 | Cause length = 8 | 1003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1004 | Error Code | Reserved=0 | 1005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1007 If any error happens in the secure session open and update process, 1008 endpoints alert their peers with these error codes. The next table 1009 shows error codes for what can happen. 1011 Error Code Value Error Code 1012 ---------------- ------------------------------------- 1013 0 Timer expired 1014 1 Signature failure 1015 2 Secure Session Open Complete failure 1017 o Timer expired: The sender starts a timer when it sends the secure 1018 session message. When the sender receives no response from the 1019 receiver before the timer expires, it sends this error code. 1021 o Signature failure: Some secure session chunks include a signature, 1022 which identifies and protects the secure session message. If the 1023 receiver checks the signature and cannot identify the chunk, this 1024 error code is used in the error chunk. 1026 o Secure Session Open Complete failure: This chunk is a very 1027 important part of the secure session. Both server and client 1028 individually compute the master secret and HMAC secret keys. Both 1029 sides check these secret keys and parameters (i.e. secure session 1030 chunks exchanged before, source and destination ports). If these 1031 keys are not identical, an error chunk is sent containing this 1032 error code. 1034 6.2. Secure Session Certificate failure 1036 0 1 2 3 1037 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 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 | Cause Code=0x21 | Cause length = 8 | 1040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1041 | Error Code | Reserved=0 | 1042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1044 The certificate failure signals that an error has occurred in 1045 processing the certificates. The next table shows error codes for 1046 what can happen. 1048 Error Code Value Error Code 1049 ---------------- ------------------------------------- 1050 0 No certificate 1051 1 Bad certificate 1052 2 Certificate expired 1053 3 Unknown certificate 1055 o No certificate: This error happens when the sender sets the CF 1056 flag and the receiver does not receive the certificate. 1058 o Bad certificate: The signature of the certificate is bad and the 1059 certificate could not be verified. 1061 o Certificate expired: The certificate is no longer valid. 1063 o Unknown certificate: The received certificate a X.509v3 1064 certificate. 1066 6.3. Decryption failure 1068 This error happens when the EncData chunk cannot be decrypted or the 1069 data chunk(s) cannot be identified after decryption. The receiver 1070 discards the EncData and increases a counter by 1. This counter 1071 counts errors. If the number of errors reaches a limit, the secure 1072 session is terminated. The limit of the errors depends on the 1073 implementation. 1075 0 1 2 3 1076 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 1077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1078 | Cause Code=0x22 | Cause length = 4 | 1079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 6.4. Authentication failure 1083 In the event of a HMAC error, the packet is discarded by the 1084 receiver. To check for an error, the receiver computes the HMAC and 1085 compares it to the HMAC field of the packet. If they do not match, 1086 an error is reported back. 1088 0 1 2 3 1089 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 1090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1091 | Cause Code=0x23 | Cause length = 4 | 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1094 6.5. Decompression failure 1096 This error happens when the compressed chunk(s) cannot be 1097 decompressed or the data chunk(s) cannot be identified after 1098 decompression. The receiver discards the decompressed chunk(s). 1100 0 1 2 3 1101 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 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 | Cause Code=0x24 | Cause length = 4 | 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 7. S-SCTP packet format and security levels 1108 S-SCTP has four different security levels, which cover privacy 1109 settings of an S-SCTP association. The S-SCTP application can change 1110 the security levels at any time during the security session lifetime. 1112 o Security level 0: This is the null security level. S-SCTP does 1113 use neither data chunk encryption nor authentication. The S-SCTP 1114 packet is the same as the SCTP packet (this level is fully 1115 compatible to SCTP). 1117 o Security level 1: This security level requires packet 1118 authentication but does not use encryption. Every outgoing packet 1119 (including the SCTP common header) is authenticated. 1121 o Security level 2: In this security level, data chunks may be 1122 encrypted. When an S-SCTP packet contains an encrypted data 1123 chunk, it MUST include an AUTH chunk as well. That means every 1124 chunk and the packet header are authenticated. When a packet 1125 includes only unencrypted data chunks or control chunks or both 1126 unencrypted data chunks and control chunks, the packet will not be 1127 authenticated. 1129 o Security level 3: This is the highest security level. S-SCTP 1130 requires both encryption and authentication. Every outgoing chunk 1131 is encrypted and the packet is authenticated. 1133 Both endpoints can use different security levels, e.g. the 1134 association can use security functions only for one direction, e.g. 1135 from server to client. In this case the server uses security level 3 1136 and the client uses security level 0. The transmission control block 1137 (TCB) of the association includes the security level as a new 1138 parameter. 1140 8. S-SCTP data format 1142 S-SCTP sorts data chunks before bundling them into the outgoing SCTP 1143 packet. The data chunks are sorted according to whether they have to 1144 be encrypted or not. The chunks belonging to the encryption group 1145 are concatenated and encrypted into an EncData chunk. May be a 1146 PADDING chunk is inserted into the encryption group. Insertion of a 1147 PADDING chunk is done depending on data length and encryption block 1148 size. 1150 An assortment of encrypted and non-encrypted chunks are bundled in 1151 the packet. The control chunk(s) are placed first in the packet when 1152 bundled with other chunks. Finally, an AUTH chunk may be added to 1153 the packet. 1155 HMAC computation is performed over all chunks and the SCTP common 1156 header with a 0 checksum. The checksum is then computed over the 1157 complete packet (including AUTH chunk). The HMAC length depends on 1158 the hash function in the cipher suite. In every security level, the 1159 SCTP packet construction is slightly different. In security level 0 1160 the packet format is same as the SCTP packet format. 1162 9. Procedures 1164 In this section an explanation of the procedures of secure session: 1165 initialisation, termination, update and etc., is given. 1167 9.1. Establishment of a secure session 1169 The following process is used to establish the S-SCTP secure session. 1170 The handshake process runs in parallel with the data transmission. 1171 The secure session start and close is controlled by the user. The 1172 user can establish and close a secure session at any time during the 1173 association lifetime. Each time a secure session is established, a 1174 new set of keys is generated. It is not possible to create a new 1175 secure session when a secure session already exists. The following 1176 describes secure session establishment, which makes use of a 1177 handshake timer and retransmissions in case packets are lost during 1178 transmission. S-SCTP uses a four-way handshake. After all messages 1179 of one of the connection "legs" have been sent, client or server 1180 starts a RTO.hand (handshake retransmission time out) timer. For 1181 example, the secure session certificate is the last handshake message 1182 of the first leg. The sender waits for a response from the receiver 1183 until the RTO.hand timer expires. The sender stops the RTO.hand 1184 timer when it receives the expected message(s). If the RTO.hand 1185 timer expires before all expected messages have been received, the 1186 sender retransmits the handshake message(s). 1188 The retransmission uses the following algorithm. The RTO.hand timer 1189 gets a value from RTO of the path where the message is sent to, which 1190 is defined in RFC4960. Before a retransmission, the sender checks 1191 RTN.hand.max (handshake maximum retransmission number). This initial 1192 value is dependent upon specific implementations. The suggested 1193 value for RTN.hand.max is Path.Max.Retrans (see RFC 4960). 1195 RTN.hand.max should be a constant parameter. We introduce a counter 1196 for the number of retransmissions, and if that counter exceeds the 1197 parameter RTN.hand.max, the timer expired error message is sent to 1198 the peer. If a retransmission is required then S-SCTP uses the same 1199 retransmission rules as defined in RFC4960. If the receiver receives 1200 a retransmission of a handshake message that was already received, 1201 the message last received MUST be dropped. The endpoint discards the 1202 message(s) when they are unexpected. A secure session initialisation 1203 begins when one of the associated endpoints sets the security level 1204 to a value higher than 0. The endpoint starting a secure session 1205 initialisation is called client and the other associated endpoint is 1206 called server. 1208 o The client sends the SSOpReq chunk to the server. If the client 1209 has a certificate, it sets the CF flag of the SSOPReq chunk to 1. 1210 The client sends the SSCert chunk immediately after the SSOpReq 1211 chunk. The SSCert chunk can be bundled with the SSOpReq chunk or 1212 with other chunk(s). When the CF flag is set to 0, the client 1213 sends only the SSOpReq chunk. 1215 o The server receives a SSOpReq chunk and checks the CF flag. If 1216 the CF flag is set to 1, the server waits for the SSCert chunk. 1217 Upon receipt, the server checks the certificate and if there is a 1218 problem with it, the server stops the handshake and goes to an 1219 error state, aborts secure session setup and reports the cause to 1220 its peer. It there is no error, the server chooses the cipher 1221 suite and sends the SSOpReq_Ack chunk with CF=1 flag to the client 1222 when the server has a certificate. The server immediately sends 1223 the certificate and the SSSerKey chunks after the SSOpReq_Ack 1224 chunk. All three chunks may be bundled together or with other 1225 chunks. The server sends only the SSOpReq_Ack chunk with the 1226 SSSerKey chunk if CF=0. Before sending the server key exchange 1227 chunk, the server generates key material. The server starts the 1228 update master secret key operation when it receives the SSOpReq 1229 chunk after secure session establishment. If the server receives 1230 the SSCert chunk before the SSOpReq chunk, it stores the SSCert 1231 chunk and waits until it receives the SSOpReq chunk. But the 1232 server drops a second SSCert chunk. 1234 o The client receives the handshake messages and checks the 1235 certificate in the SSSerKey chunk. If the client detects any 1236 errors, it stops the handshake and goes to an error state, aborts 1237 secure session setup and reports the cause to its peer. The 1238 client generates key material and sends the SSCliKey chunk to the 1239 server. The client sends the SSOpCom chunk immediately after the 1240 client key exchange chunk. Before sending the handshake-finished 1241 chunk, the client computes the encryption secret and MAC secret 1242 keys. 1244 o The server receives the SSCliKey chunk and computes the master 1245 secret and the MAC secret keys. It then computes the SSOpCom 1246 chunk and sends it to the client. Finally, the server checks the 1247 SSOpCom chunk of the client. If the server detects any error, it 1248 reports a secure session open complete error and closes the 1249 handshake. The secure session is established only when both sides 1250 detect no errors. The server is ready for secure transmission 1251 when it detects no errors, but the client must wait for the 1252 SSOpCom chunk of the server. When this is received, the client 1253 checks it and reports to the peer a secure session open complete 1254 error if any error is detected before aborting secure session 1255 setup. The handshake may run simultaneously with normal SCTP data 1256 transmission. If the client receives encrypted or authenticated 1257 data chunks before it receives the server's SSOpCom chunk, then 1258 those chunks MUST be discarded. 1260 When both associated endpoints request the initialisation of a secure 1261 session simultaneously (both endpoints send an SSOpReq message), both 1262 ignore the received SSOpReq message and wait a random time before 1263 resending the SSOpReq message. Each endpoint generates the random 1264 time independently. The random number must be small, e.g. 120 1265 seconds maximum. 1267 9.2. Choice of cipher suite and compression method 1269 This section explains how to choose the cipher suite and compression 1270 method which are used for the secure session. Each endpoint 1271 maintains an ordered list of supported cipher suites (cipher suite 1272 list). The ordering in the list indicates the preference with which 1273 a cipher suite should be used (first in the list have higher 1274 preference). The order in the list is defined by the retrospective 1275 S-SCTP user. 1277 S-SCTP users on both sides can allow all cipher suited in the list 1278 when establishing a secure session or limit the allowed cipher suites 1279 to a subset. The complete list or the selected subset can be 1280 indicated to the server in the SSOpReq. If the complete list is 1281 sent, the default cipher suite list must be located first in the 1282 list. The server uses the following rules to choose the cipher suite 1283 to be used for the secure session: 1285 The server chooses the default cipher suite, if the SSOpReq chunk 1286 does not contain any cipher suite. 1288 The server gets the first cipher suites from SSOpReq chunk and 1289 server's cipher suite sequence. When both cipher suites are 1290 identical the server chooses this cipher suite for the secure 1291 session. Otherwise, the server takes its first cipher suite and 1292 looks for a match in the cipher suite sequence of the client. When 1293 there is no matche, the server takes the client's first cipher suite 1294 and searches for match in its cipher suite sequence. S-SCTP checks 1295 the first cipher suite in the SSOpReq chunk against all cipher suites 1296 in the cipher suite list of the server. If no match is found, all 1297 subsequent cipher suites in the SSOpReq are checked sequentially in 1298 the order they appear in the SSOPReq until a match is found. The 1299 first cipher suite supported by both endpoints is chosen. When two 1300 cipher suites match each other then this cipher suite is selected for 1301 the secure session. If not, the server looks, its second cipher 1302 suite, for a match in the cipher suite sequence of the client. 1303 Furthermore, the server uses the same mechanism to look a cipher 1304 suite for the secure session. 1306 The server chooses the default cipher suite, when the cipher suites 1307 in the SSOpReq chunk are not supported by the server. 1309 Both client and server also maintain a list of compression methods. 1310 The choice of the compression mechanism works similarly to the cipher 1311 suite selection mechanism described above. S-SCTP uses a NULL 1312 compression method as default compression method. 1314 9.3. Data transfer 1316 Before transporting the packet over the network, S-SCTP takes the 1317 following steps. First, it checks the security level. If the 1318 security level is: 1320 o 0, jump to step "d" 1322 o 1, jump to step "c" 1324 o 2, check the user data. If the user data requires encryption, 1325 jump to step "a" . If the user data does not require encryption, 1326 jump to step "c" 1328 o 3, jump to step "a" 1330 a) S-SCTP sorts data chunks in two groups, which are encrypted and 1331 unencrypted. The encrypted group consists of those data chunks 1332 requiring encryption. The unencrypted group consists of those 1333 data chunks not requiring encryption. If the secure session's 1334 security level is set to 3, all chunks are sorted into the 1335 encrypted group. 1337 b) The data chunks in the encrypted group are concatenated. After 1338 this, S-SCTP calculates the padding chunk and inserts the padding 1339 chunk on the last position into pre-enc-data if necessary. The 1340 Pre-enc-data size MUST be smaller than the current MTU. If the 1341 pre-enc-data is bigger than the current MTU, S-SCTP must create 1342 two pre-enc-datas. Every pre-enc-data is encrypted and stored in 1343 the encryption data field of the EncData chunk. 1345 c) SCTP builds the packet according to the security level and 1346 inserts the AUTH chunk in the last position in the packet. 1348 d) S-SCTP sends the packet. 1350 9.4. Closing of a secure session 1352 The termination of a secure session begins when one of the endpoints 1353 sends the secure session close chunk. This chunk includes the last 1354 encrypted data TSN and OF. The endpoint (sender) stops the 1355 encryption or authentication of all chunks or packets after it has 1356 sent the secure session close chunk. But normal (unsecured) data 1357 transfer will continue. The endpoint then waits until it receives 1358 the SSClose_Ack chunk. After receiving the SSClose_Ack chunk, the 1359 association clears the TCB parameters belonging to the secure 1360 session. The receiver (other endpoint) immediately stops encryption 1361 and authentication of all chunks or packets after it receives the 1362 secure session close chunk. Before sending the SSClose_Ack, the 1363 receiver waits for outstanding data (encrypted or authenticated 1364 data), which are the receiver's unacknowledged data chunks and 1365 sender's data chunks that have a TSN less than the last encrypted 1366 data TSN in the SSClose chunk. If the receiver does not receive the 1367 outstanding data chunks before RTO.hand timer expires, the S-SCTP 1368 association closes the secure session and outstanding data chunks 1369 will be dropped. The receiver ignores the last TSN of SSClose chunk 1370 and waits only for the receiver's unacknowledged data chunks when 1371 SSClose chunk's OF=1. The SSClose and SSClose_Ack chunks may be 1372 bundled with other chunks. If the sender does not receive the 1373 acknowledge chunk, the client follows the standard retransmission 1374 rule for messages. After the termination of the secure session, the 1375 TCB parameters belonging to the secure session MUST be set to zero. 1376 If the SCTP association begins to close the current association, the 1377 SSClose chunk is sent. If the SCTP association creates an ABORT 1378 chunk, the secure session closes immediately and the TCB parameters 1379 belonging to the secure session MUST be set to zero. 1381 9.5. Generation of the Master secret key 1383 Secret key generation uses the 3DES_CBC algorithm. Both server and 1384 client compute the master secret key separately. The key material is 1385 split into 64 bit blocks. Every block will be input to the 3DES_CBC 1386 encryption. The key material is as follows: 1388 o If the secure session key exchange algorithm uses DH, the key 1389 material consists of the DH's secret key. 1391 o If the secure session key exchange algorithm uses RSA, the key 1392 material consists of random numbers of both client and server. 1394 9.6. Update of the master secret key 1396 A secure update mechanism of the secret keys is a very important 1397 requirement for a secure session. The secret keys consist of the 1398 master secret key, which is used for data chunk encryption, and the 1399 HMAC secret key, which is used for packet authentication. If an 1400 association exists for a long time, the S-SCTP association needs to 1401 update the secret keys. Both the client and the server can request 1402 an update of the secret keys. A three way handshake, called an 1403 abbreviated handshake, is used to update the master secret keys. All 1404 actions of the handshake are encrypted by the current master secret 1405 key. The current security level does not affect the packets, which 1406 contain the handshake messages. The key update handshake works 1407 similar to the first establishment handshake (e.g. the endpoints 1408 start an RTO.hand timer when sending handshake chunks). Format and 1409 function of the chunks used to update keys are the same as for the 1410 handshake. When an endpoint receives a SSOpReq chunk (after a secure 1411 session establishment) it begins to update secret keys. Both the 1412 server and client key exchange chunks always use the RSA key exchange 1413 algorithm. The random numbers in SSSerKey and SSCliKey chunks are 1414 encrypted by the current master secret key. The following describes 1415 the method used to update the master secret key: 1417 The client generates a random number and sends the SSopReq chunk with 1418 the SSCliKey chunk. The key material length in the handshake request 1419 chunk may be equal to 0. If not, the number indicates the size of 1420 the new key material. If 0, both sides will use the key material 1421 length which was used in the last handshake. The server sends the 1422 SSop_Ack, the SSSerKey and the SSOpCom chunks immediately after 1423 receiving the SSOpReq and the SSCliKey chunks. After receiving the 1424 handshake messages from the server, the client computes a new master 1425 secret key and checks the SSOpCom chunk of the server. If it detects 1426 any error, the client closes the secure session and reports an error 1427 to the peer. The client computes the SSOpCom chunk and sends it to 1428 the server. After sending the SSOpCom chunk the client is ready to 1429 use the new master secret key. The server receives the SSOpCom chunk 1430 of the client and checks the new keys. If it detects any error, the 1431 server closes the secure session and reports an error to the peer. 1432 Before receiving the client's SSOpCom chunk, the server discards any 1433 encrypted or authenticated chunk that make use of the new master 1434 secret key. 1436 The encrypted and unencrypted user data transmission works in 1437 parallel with the update operation. After the update operation, the 1438 new master secret key is used for data encryption and authentication. 1439 When both client and server receive an SSOpReq chunk simultaneously, 1440 the client ignores the server's SSopReq chunk and the server accepts 1441 the client's SSOpReq chunk. The next steps are the same as for the 1442 secure session initialisation. 1444 The new master secret key generation uses the same algorithm as 1445 described above. The secure session includes one parameter which is 1446 called secure session lifetime. This parameter is used to initialise 1447 a timer which indicates the secure session secret key's lifetime in 1448 seconds. When the timer expires, the association automatically 1449 updates the secret keys. The user can define this parameter. If the 1450 user does not define it, the parameter assumes a default value. This 1451 default value depends on the implementation. The implementation MUST 1452 define secure session's lifetime initial value. We suggest a value 1453 of 600 seconds for the lifetime as a compromise between security and 1454 overhead. 1456 9.7. Random number generation 1458 As the security of S-SCTP depends on the quality of the random number 1459 generator, we suggest to use one according to RFC4086 [RFC4086]. 1461 9.8. HMAC algorithm 1463 S-SCTP uses the HMAC algorithm which is defined in RFC2104 [RFC2104] 1464 for the packet authentication. 1466 10. HMAC algorithm 1468 ULP-to-SCTP primitives deliver upper layer requests to S-SCTP. The 1469 following part describes new ULP-to-SCTP primitives and thus enhances 1470 the section 10 of RFC4960. All new ULP-to-SCTP primitives described 1471 below are defined in the ssctp.h header file. 1473 INITSECSESS: This primitive initialises a new secure session. 1475 Format: {initSecSess(secure session ID, key material length, cipher 1476 suites list, compression methods list, certiticate(s) ) --> result} 1478 o secure session ID: This parameter identifies a secure session. 1480 o key material length: This defines the key material length which is 1481 used in the SSOPReq chunk. 1483 o cipher suite list: Eligible cipher suites for a new secure 1484 session. 1486 o compression method list: Eligible compression methods for a new 1487 secure session. 1489 o certificate(s): Local endpoint certificate(s). 1491 SETSECLEVEL: This primitive sets a new security level for an existing 1492 secure session. 1494 Format: {setSecLevel(secure session ID, security level) --> result} 1496 o secure session ID: local handle to the secure session 1498 o security level: This parameter indicates the new security level 1500 GETSECLEVEL: This primitive gets the current security level of a 1501 secure session. 1503 Format: {getSecLevel(secure session ID) --> security level} 1505 o secure session ID: local handle to the secure session 1507 SENDSEC: This primitive sends secure data via S-SCTP. 1509 Format: {sctp_send_enc(association id, buffer address, byte count, 1510 context, stream id, life time, destination transport address, unorder 1511 flag, no-bundle flag, payload protocol-id, encryption flag, 1512 compression flag) --> result} 1514 Every parameter, except the encryption and compression flags, defined 1515 in this function is the same as the corresponding parameter defined 1516 in the SEND function of RFC4960 section 10. 1518 o encryption flag: This flag defines if a current user data message 1519 needs encryption or not. 1521 o compression flag: This flag defines if a current user data message 1522 needs compression or not. 1524 GETSECSTATUS: This primitive gets the security status of an 1525 association. The security status indicates if the SCTP association 1526 is using a secure session or not. 1528 Format: {setSecStatus(association ID) --> status} 1530 o association ID: local handle to the SCTP association. 1532 SETSECSESSTTL: This primitive sets a new lifetime for a secure 1533 session. 1535 Format: {setSecSessTTL(secure session ID, Time) --> result} 1536 o secure session ID: local handle to the secure session. 1538 o time: The new lifetime in seconds. 1540 SHUTSECSESS: This primitive deletes a secure session. 1542 Format: {shutSecSess(secure session ID) --> result} 1544 o secure session ID: local handle to the secure session. 1546 o security level: This parameter indicates the new security level. 1548 11. S-SCTP to ULP 1550 S-SCTP defines new notifications to deliver information to the upper 1551 layer. The notifications extend the section 10.2 of RFC4960 1552 [RFC4960]. All new notifications are defined in the ssctp.h header 1553 file. 1555 SECSESSUP: 1557 This notification indicates that S-SCTP is ready to send or receive 1558 secure data ({secsessUpNotif()}). 1560 SECSESSDOWN: 1562 This notification indicates that an association has lost a secure 1563 session ({secsessdownNotif()}). 1565 SECSESSREKEY: 1567 This notification indicates that a secure session updated the secret 1568 keys ({secsessrekeyNotif()}). 1570 Additional changes had to be made in the socket API implementation to 1571 access the new sctplib functions described above. A user calls the 1572 same socket API functions as in standard SCTP to send and receive 1573 user data, but has to set an additional encryption flag (MSG_ENC) to 1574 request encryption of user data. Also, a compression flag (MSG_COMP) 1575 has to be set in ext_send, ext_sendto, ext_sendmsg to request 1576 compression of user data. S-SCTP compression performs per user 1577 message not per chunk or per packet. In the SCTP DATA chunk, a new 1578 flag is defined, which indicates if the data is compressed or not. 1579 On the receiver side there are no changes. 1581 12. Transmission Control Block (TCB) extension 1583 A SCTP TCB contains parameters which are related to an association 1584 (e.g. an association id, port number, IP address list...). S-SCTP 1585 defines several parameters which are related to a secure session and 1586 it extends the TCB defined in section 12 of RFC4960. 1588 Security level: 1590 This parameter contains the association's current security level. 1592 Second security level: 1594 This is the security level of the associated second endpoint. 1596 Key material length: 1598 The size of the key material, which was last used for key generation. 1600 Secure session status: 1602 This parameter indicates whether the association is using a secure 1603 session or not. 1605 Secure session lifetime: 1607 This parameter indicates the lifetime of the secret keys of a secure 1608 session. 1610 Server indication: 1612 This parameter indicates if an endpoint is server or client. If the 1613 parameter is equal to 1 then it is a server, otherwise it is a 1614 client. 1616 Secure session ID: 1618 This parameter indicates the local secure session ID. 1620 Master secret key reference: 1622 This is an "array of secret data" collection and every array element 1623 includes the following parameters. 1625 o Selected cipher suite: This parameter indicates the encryption and 1626 authentication algorithms that are used in a secure session. 1628 o Selected compression: This parameter indicates the compression 1629 method that is used in a secure session. 1631 o Encryption key: This is a secret key which is used for encryption. 1633 o Authentication key: This is a secret key which is used for 1634 authentication. 1636 This information is used in EncData and AUTH chunks. 1638 13. Socket API extensions for Secure SCTP 1640 S-SCTP defines new socket options for the ext_setsockopt() and 1641 ext_getsockopt() socket functions to initialise, delete and rekey a 1642 secure session. A user calls the ext_setsockopt or ext_getsockopt 1643 functions with a new option. It is not necessary to define new 1644 socket API functions, as this is a more standard socket API fashion. 1645 The following paragraphs describe the new socket options. 1647 SSCTP-INIT: 1649 This socket option is used to initialise or update a secure session. 1650 The following structure is used to access these parameters. 1652 struct ssctp_init { 1653 uint16_t secsessID; 1654 uint16_t key_length; 1655 uint8_t num_cipher; 1656 uint8_t *cipher_suites; 1657 uint8_t num_comp; 1658 uint8_t *comp_methods; 1659 uint8_t *certificate; 1660 }; 1662 o secsessID: This parameter indicates a current secure session ID. 1664 o key_length: This parameter defines the length of a key material. 1666 o num_cipher: This parameter defines the number of cipher suites. 1668 o cipher_suites: This parameter includes a list of cipher suites. 1670 o num_comp: This parameter defines the number of compression 1671 methods. 1673 o comp_methods: This parameter includes a list of compression 1674 methods. 1676 o certificate: This parameter includes a certificate of the 1677 endpoint. 1679 SSCTP-SECLEVEL: 1681 This socket option is used to set and get a secure session security 1682 level. The following structure is used to access and modify these 1683 parameters. 1685 struct ssctp_seclevel { 1686 uint16_t secsessID; 1687 uint8_t seclevel; 1688 }; 1690 o secsessID: This parameter indicates a current secure session ID. 1691 This parameter MUST be zero when beginning a secure session 1692 initialisation. 1694 o seclevel: This parameter contains a new security level before 1695 socket write access or contains the current security level after 1696 socket read access. 1698 SSCTP-SECSTATUS: 1700 This socket option is used to get the secure session status and 1701 secure session ID when a secure session exists. The following 1702 structure is used to access these parameters. 1704 struct ssctp_secstatus { 1705 uint16_t secsessID; 1706 uint8_t sec_status; 1707 }; 1709 o secsessID: This parameter contains the current secure session ID. 1710 This parameter MUST be zero when a secure session does not exist. 1712 o sec_status: This parameter contains a security status. This 1713 parameter MUST be zero when a secure session does not exist. This 1714 parameter is equal to 1 when a secure session exists. 1716 SSCTP-SECSESSTTL: 1718 This socket option is used to set and get the secure session 1719 lifetime. The following structure is used to access and modify these 1720 parameters. 1722 struct ssctp_secsessTTL { 1723 uint16_t secsessID; 1724 uint16_t secsessTTL; 1725 }; 1727 o secsessID: This parameter indicates the current secure session ID. 1729 o secsessTTL (seconds): This parameter contains a new secure session 1730 lifetime before socket write access or contains a current secure 1731 session lifetime after socket read access. 1733 SSCTP-CLOSE: 1735 This socket option is used to close an existing secure session. The 1736 following structure is used to access these parameters. 1738 struct ssctp_secclose { 1739 uint16_t secsessID; 1740 }; 1742 o secsessID: This parameter contains the current secure session ID. 1744 14. Testbed Platform 1746 A large-scale and realistic Internet testbed platform with support 1747 for the multi-homing feature of the underlying SCTP protocol is 1748 NorNet. A description of NorNet is provided in [PAMS2013-NorNet], 1749 some further information can be found on the project website 1750 [NorNet-Website]. 1752 15. Security Considerations 1754 Security has been described in the previous sections. 1756 16. IANA Considerations 1758 This document introduces no additional considerations for IANA. 1760 17. References 1762 17.1. Normative References 1764 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1765 Hashing for Message Authentication", RFC 2104, 1766 DOI 10.17487/RFC2104, February 1997, . 1769 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1770 Requirement Levels", BCP 14, RFC 2119, 1771 DOI 10.17487/RFC2119, March 1997, . 1774 [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport 1775 Layer Security over Stream Control Transmission Protocol", 1776 RFC 3436, DOI 10.17487/RFC3436, December 2002, 1777 . 1779 [RFC3554] Bellovin, S., Ioannidis, J., Keromytis, A., and R. 1780 Stewart, "On the Use of Stream Control Transmission 1781 Protocol (SCTP) with IPsec", RFC 3554, 1782 DOI 10.17487/RFC3554, July 2003, . 1785 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1786 "Randomness Requirements for Security", BCP 106, RFC 4086, 1787 DOI 10.17487/RFC4086, June 2005, . 1790 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1791 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1792 . 1794 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1795 Housley, R., and W. Polk, "Internet X.509 Public Key 1796 Infrastructure Certificate and Certificate Revocation List 1797 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1798 . 1800 17.2. Informative References 1802 [PAMS2013-NorNet] 1803 Dreibholz, T. and E. Gran, "Design and Implementation of 1804 the NorNet Core Research Testbed for Multi-Homed Systems", 1805 Proceedings of the 3nd International Workshop on Protocols 1806 and Applications with Multi-Homing Support (PAMS) Pages 1807 1094-1100, ISBN 978-0-7695-4952-1, 1808 DOI 10.1109/WAINA.2013.71, March 2013, 1809 . 1813 [NorNet-Website] 1814 Dreibholz, T., "NorNet - A Real-World, Large-Scale Multi- 1815 Homing Testbed", Online: https://www.nntb.no/, 2017, 1816 . 1818 Authors' Addresses 1820 Carsten Hohendorf 1821 University of Duisburg-Essen, Institute for Experimental Mathematics 1822 Ellernstrasse 29 1823 45326 Essen, Nordrhein-Westfalen 1824 Germany 1826 Email: hohend@iem.uni-due.de 1828 Esbold Unurkhaan 1829 Mongolian University of Science and Technology 1830 Bayanzurkh duureg, 2-nd khoroo 1831 313/49 Ulaanbaatar 1832 Mongolia 1834 Email: esbold@csms.edu.mn 1836 Thomas Dreibholz 1837 Simula Centre for Digital Engineering 1838 Martin Linges vei 17 1839 1364 Fornebu, Akershus 1840 Norway 1842 Phone: +47-6782-8200 1843 Fax: +47-6782-8201 1844 Email: dreibh@simula.no 1845 URI: https://www.uni-due.de/~be0001/