idnits 2.17.1 draft-hohendorf-secure-sctp-16.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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 05, 2013) is 3942 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: January 6, 2014 Mongolian University 6 T. Dreibholz 7 Simula Research Laboratory 8 July 05, 2013 10 Secure SCTP 11 draft-hohendorf-secure-sctp-16.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 January 6, 2014. 38 Copyright Notice 40 Copyright (c) 2013 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 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before November 55 10, 2008. The person(s) controlling the copyright in some of this 56 material may not have granted the IETF Trust the right to allow 57 modifications of such material outside the IETF Standards Process. 58 Without obtaining an adequate license from the person(s) controlling 59 the copyright in such materials, this document may not be modified 60 outside the IETF Standards Process, and derivative works of it may 61 not be created outside the IETF Standards Process, except to format 62 it for publication as an RFC or to translate it into languages other 63 than English. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. A brief description of S-SCTP . . . . . . . . . . . . . . . . 4 70 4. Key terms . . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 5. Additional chunks and parameters . . . . . . . . . . . . . . . 5 72 5.1. New type chunks and definitions . . . . . . . . . . . . . 5 73 5.1.1. Secure Session Open request chunk (SSOpReq) . . . . . 6 74 5.1.2. Secure Session Certificate chunk: (SSCert) . . . . . . 9 75 5.1.3. Secure Session Open Acknowledge chunk (SSOpReq_Ack) . 11 76 5.1.4. Secure Session Server Key chunk (SSSerKey) . . . . . . 12 77 5.1.5. Secure Session Client Key chunk (SSCliKey) . . . . . . 15 78 5.1.6. Secure Session Open Complete chunk (SSOpCom) . . . . . 17 79 5.1.7. Secure Session Close chunk (SSClose) . . . . . . . . . 18 80 5.1.8. Secure Session Close Acknowledge chunk 81 (SSClose_Ack) . . . . . . . . . . . . . . . . . . . . 18 82 5.1.9. Security Level Changed chunk (SecLevCHD) . . . . . . . 19 83 5.1.10. Security Level Changed Acknowledged chunk 84 (SecLevCHD_Ack) . . . . . . . . . . . . . . . . . . . 19 85 5.1.11. Encrypted Data Chunk (EncData) . . . . . . . . . . . . 19 86 5.1.12. Padding chunk (PADDING) . . . . . . . . . . . . . . . 21 87 5.1.13. Authentication chunk (AUTH) . . . . . . . . . . . . . 21 88 6. New Error Cause . . . . . . . . . . . . . . . . . . . . . . . 22 89 6.1. Secure Session failure . . . . . . . . . . . . . . . . . . 23 90 6.2. Secure Session Certificate failure . . . . . . . . . . . . 24 91 6.3. Decryption failure . . . . . . . . . . . . . . . . . . . . 24 92 6.4. Authentication failure . . . . . . . . . . . . . . . . . . 25 93 6.5. Decompression failure . . . . . . . . . . . . . . . . . . 25 94 7. S-SCTP packet format and security levels . . . . . . . . . . . 25 95 8. S-SCTP data format . . . . . . . . . . . . . . . . . . . . . . 26 96 9. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 26 97 9.1. Establishment of a secure session . . . . . . . . . . . . 26 98 9.2. Choice of cipher suite and compression method . . . . . . 28 99 9.3. Data transfer . . . . . . . . . . . . . . . . . . . . . . 29 100 9.4. Closing of a secure session . . . . . . . . . . . . . . . 30 101 9.5. Generation of the Master secret key . . . . . . . . . . . 31 102 9.6. Update of the master secret key . . . . . . . . . . . . . 31 103 9.7. Random number generation . . . . . . . . . . . . . . . . . 32 104 9.8. HMAC algorithm . . . . . . . . . . . . . . . . . . . . . . 32 105 10. HMAC algorithm . . . . . . . . . . . . . . . . . . . . . . . . 33 106 11. S-SCTP to ULP . . . . . . . . . . . . . . . . . . . . . . . . 34 107 12. Transmission Control Block (TCB) extension . . . . . . . . . . 35 108 13. Socket API extensions for Secure SCTP . . . . . . . . . . . . 36 109 14. Testbed Platform . . . . . . . . . . . . . . . . . . . . . . . 39 110 15. Security Considerations . . . . . . . . . . . . . . . . . . . 39 111 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 112 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 113 17.1. Normative References . . . . . . . . . . . . . . . . . . . 39 114 17.2. Informative References . . . . . . . . . . . . . . . . . . 40 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 117 1. Introduction 119 SCTP is a message oriented reliable transmission protocol which works 120 on top of the IP-based network. It provides several advantages over 121 other transmission protocols, such as TCP and UDP over IP. One of 122 the advantages is multistreaming -- user data transported by 123 individual streams. When multistreaming is used, network blocking 124 can be avoided in certain cases (e.g. network loss). Also, SCTP 125 supports multihoming -- the endpoints support multiple IP addresses. 126 SCTP provides unordered delivery, so that a receiver immediately 127 delivers user data to the upper layers upon receipt. For more 128 details, see RFC4960 [RFC4960]. 130 2. Conventions 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in [RFC2119]. 136 3. A brief description of S-SCTP 138 S-SCTP provides security functionalities in the transport layer 139 without the need for any other security protocols (e.g. TLS or IP- 140 sec). Normally, a data transport over SCTP can either be secured 141 with TLS or can be protected by IPsec. As both TLS over SCTP and 142 SCTP over IPsec have disadvantages in certain scenarios, it is 143 preferable to integrate cryptographic functions into SCTP. 145 The main issues for the security solutions TLS over SCTP RFC3436 146 [RFC3436] and SCTP over IPSec RFC3554 [RFC3554] is scalability with 147 the number of streams. For N secure streams, N TLS connections have 148 to be created, and N handshakes have to be performed. If N is small, 149 this is not a big issue, but as N grows larger, it becomes a problem 150 because a handshake is a slow and expensive process. So, when an 151 application performs N handshakes, the load in terms of memory use, 152 CPU use etc. increases linearly over time. This problem could be 153 overcome by using IPsec. However, IPsec is not so flexible and on 154 the other hand SCTP over IPsec has to establish new security 155 associations (SA) for newly added IP addresses in dynamic address 156 reconfiguration scenario. In this case, the application has to 157 configure a new SA and to negotiate a new key exchange. 159 4. Key terms 161 This part gives the definitions of the key terms, which are used in 162 this draft: 164 o Secure session: This is the session, which provides the security 165 functionalities for an established SCTP association. 167 o Master secret key: S-SCTP uses two kinds of secret keys. One is 168 the secret key for the S-SCTP packet authentication, and the other 169 is the secret key for the data encryption and decryption. 171 o Cipher suite: This is the suite of cryptographic algorithms, which 172 are used for key exchange, data encryption/decryption and the 173 packet authentication. 175 o Pre-enc-data: This is the collection of the data chunks, which 176 requires encryption. The data chunks are concatenated together 177 and create pre-enc-data. Pre-enc-data may include the padding 178 chunk. 180 o Cipher suite sequence: This is the bundle of cipher suites chosen 181 by an endpoint from the supported cipher suites. 183 5. Additional chunks and parameters 185 Several new chunks and parameters are defined in S-SCTP. This 186 section explains those chunks and parameters. All new chunks can be 187 bundled with other chunks. The new parameters follow the Type- 188 Length-Value format as defined in section 3.2.1 of RFC4960. 190 5.1. New type chunks and definitions 192 The following table shows the new chunks. All new chunks, except for 193 the Encrypted Data (EncData) chunk, Authentication (AUTH) chunk and 194 Padding (PADDING) chunk, are used for building the secure session and 195 to update the master secret key. The new chunks are to be 196 interpreted as described in Section 3.2 of RFC 4960, by the receiver. 198 Chunktype Chunk name 199 --------- --------------------- 200 0xD0 Secure Session Open Request Chunk 201 0xD1 Secure Session Certificate Chunk 202 0xD2 Secure Session Acknowledge Chunk 203 0xD3 Secure Session Server Key Chunk 204 0xD4 Secure Session Client Key Chunk 205 0xD5 Secure Session Open Complete Chunk 206 0xD6 Secure Session Close Chunk 207 0xD7 Secure Session Close Acknowledge Chunk 208 0xD8 Security Level Change Chunk 209 0xD9 Security Level Change Acknowledge Chunk 210 0x10 Encrypted Data Chunk 211 0x11 Authentication Chunk 212 0x12 Padding Chunk 214 The new parameters are defined in this section. 216 5.1.1. Secure Session Open request chunk (SSOpReq) 218 An endpoint creates the Secure Session Open Request chunk (see next 219 table)when it wishes to establish a secure session. The chunk can be 220 bundled with other chunks. The SSOpReq chunk can also be used to 221 update the master secret key or cipher suite after a secure session 222 establishment. During the association lifetime, both associated 223 endpoints can request an update of the master secret key or cipher 224 suite; in this case, the requesting endpoint sends the SSSOpReq chunk 225 immediately to the other endpoint. 227 0 1 2 3 228 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 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Type=0xD0 | Reserved=0 |CF| Length | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Version | Key material length | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 \ \ 235 / Optional parameters / 236 \ \ 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 CF: Certificate flag: 1 bit 241 This flag indicates whether or not the client will send a 242 certificate. It is set to 1 when the client sends a certificate. If 243 a receiver receives SSOpReq chunk with CF=1 and does not receive a 244 certificate it raises an error and terminates the secure session 245 initialisation. 247 Length: 16 bits unsigned integer 249 The length field contains the size of the chunk in bytes, including 250 the chunk header, version, random number length and optional 251 parameter(s). 253 Version: 16 bits unsigned integer 255 This field indicates the S-SCTP version 1.0. The high eight bits 256 indicate the major version, the low eight bits indicate minor 257 version. 259 Key material length: 16 bits unsigned integer 261 This number has two meanings: 263 o when the handshake is made using the RSA key exchange protocol, 264 the key material length defines the random number length, which is 265 generated by the server and client to calculate a master secret 266 key (see RSA parameters of the SSSerKey and SSCliKey chunks) 268 o when the handshake is made using the DH key exchange protocol, the 269 key material length defines the DH prime number length (see DH 270 parameters of the SSSerKey and SSCliKey chunks). For security 271 reasons, the key material length MUST be 512 bits (default) or 272 longer when the key exchange mechanism uses RSA, and 1024 bits 273 (default) or longer when the key exchange mechanism uses DH. The 274 key material length is increased in steps of 64 bits. If a user 275 defines the key material length to be shorter than the default 276 value, S-SCTP automatically sets it to the default. 278 Parameter(S): 280 SSOpReq chunk includes the cipher suite and compression method 281 parameters, which are described below: 283 Cipher suite parameter: 285 This parameter contains the cipher suites, which are chosen from all 286 supported cipher suites by the client. One of them is used for the 287 secure session. The user can choose certain cipher suites from the 288 cipher suites supported by the client. 290 0 1 2 3 291 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 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Type=30 | Length | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Cipher suite 1 | Cipher suite 2 | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | .............. | .............. | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Cipher suite N-1 | Cipher suite N | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 Cipher suite: 16 bits unsigned integer: 304 This field indicates a cipher suite, which is supported by the 305 client. The next table includes cipher suites supported in S-SCTP. 306 Additional cipher suites can be specified. 308 Value Cipher suite Key exchange Encryption Hash 309 ----- ------------------------- ------------ ---------- --------- 310 1 RSA_with_DES_CBC_MD5 RSA DES_CBC MD5 311 2 RSA_with_DES_CBC_SHA-1 RSA DES_CBC SHA-1 312 3 RSA_with_3DES_CBC_MD5 RSA 3DES_CBC MD5 313 4 RSA_with_3DES_CBC_SHA-1 RSA 3DES_CBC SHA-1 314 5 RSA_with_AES-128_CBC_MD5 RSA AES-128 MD5 315 6 RSA_with_AES-128_CBC_SHA-1 RSA AES-128 SHA-1 316 7 DH_with_DES_CBC_MD5 DH DES_CBC MD5 317 8 DH_with_DES_CBC_SHA-1 DH DES_CBC SHA-1 318 9 DH_with_3DES_CBC_MD5 DH 3DES_CBC MD5 319 10 DH_with_3DES_CBC_SHA-1 DH 3DES_CBC SHA-1 320 11 DH_with_AES-128_CBC_MD5 DH AES-128 MD5 321 12 DH_with_AES-128_CBC_SHA-1 DH AES-128 SHA-1 322 13 RSA_with_NULL_MD5 RSA NULL MD5 323 14 RSA_with_NULL_SHA-1 RSA NULL SHA-1 324 15 DH_with_NULL_MD5 DH NULL MD5 325 16 DH_with_NULL_SHA-1 DH NULL SHA-1 326 17 RSA_with_AES-192_CBC_MD5 RSA AES-192 MD5 327 18 RSA_with_AES-192_CBC_SHA-1 RSA AES-192 SHA-1 328 19 RSA_with_AES-256_CBC_MD5 RSA AES-256 MD5 329 20 RSA_with_AES-256_CBC_SHA-1 RSA AES-256 SHA-1 330 21 DH_with_AES-192_CBC_MD5 DH AES-192 MD5 331 22 DH_with_AES-192_CBC_SHA-1 DH AES-192 SHA-1 332 23 DH_with_AES-256_CBC_MD5 DH AES-256 MD5 333 24 DH_with_AES-256_CBC_SHA-1 DH AES-256 SHA-1 335 The hash algorithms, defined in cipher suites, are used only for the 336 S-SCTP packet authentication, and not for the signature of the 337 handshake messages. An S-SCTP implementation MUST at least support 338 the default cipher suite, DH_with_3DES_CBC_SHA-1 (value=0). If the 339 SSOpReq chunk does not contain a cipher suite parameter, then: 341 a.) S-SCTP will use the default, or: 343 b.) S-SCTP will use the old cipher suite. 345 The case "a" will be used at the beginning of the secure session. 346 The case "b" will be used when the SSOpReq chunk is created after a 347 secure session establishment. The signature schemes are derived from 348 both the client and server certificates, and may be different. 350 Compression method parameter 352 This parameter contains compression methods, which are used for data 353 compression. The data compression uses lossless compression methods. 354 The user chooses several compression methods and sends it to the 355 receiver. The receiver chooses one compression method. 357 0 1 2 3 358 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 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Compression | Compression | Compression | Compression | 361 | method 1 | method 2 | method 3 | method 4 | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | .... | .... | Compression | Compression | 364 | | | method N-1 | method N | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 Compression method: 8 bits unsigned char 369 This field indicates a compression method, which is supported by the 370 client. The next table includes compression methods supported in 371 S-SCTP. Additional compression methods can be specified. 373 Value Compression method 374 ----- --------------------- 375 1 Huffman Code 376 2 Lempel-Ziv Code 378 The secure session uses null compression when the SSOpReq chunk 379 contains no compression parameters. 381 5.1.2. Secure Session Certificate chunk: (SSCert) 383 This chunk can be sent by both endpoints. The certificate helps to 384 authenticate the endpoint, that establishes a S-SCTP session. This 385 chunk contains only one parameter, the certificate parameter. The 386 SSCert chunk is optional. For security reasons, both endpoints 387 SHOULD use a certificate to authenticate each other. 389 0 1 2 3 390 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 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Type=0xD1 | Reserved=0 | Length | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 \ \ 395 / Certificate / 396 \ \ 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 \ \ 399 / Optional parameter / 400 \ \ 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 Length: 16 bits unsigned integer 405 The length field contains the size of the chunk in bytes, including 406 the chunk header and parameter. 408 Certificate: Variable length 410 The certificate field contains the certificate of the endpoint. 411 S-SCTP uses the X.509v3 certificate which is defined in RFC5280 412 [RFC5280]. 414 Optional parameter 416 SSCert chunk has only one optional parameter. 418 Certificate parameter 420 The SSCert chunk uses the certificate parameter for additional 421 certificates, when the endpoint has two or more certificates. 423 0 1 2 3 424 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 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | Type=33 | Length | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 \ \ 429 / Certificate / 430 \ \ 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 Certificate: Variable length 434 The endpoint can send two or more certificates. In this case the 435 certificate field contains the endpoint's additional certificate. 436 S-SCTP uses the X.509v3 certificate, which is defined in RFC5280 437 [RFC5280]. 439 5.1.3. Secure Session Open Acknowledge chunk (SSOpReq_Ack) 441 The Secure Session Open Acknowledge chunk is sent by the server to 442 tell the client that the secure session open request is accepted. 444 0 1 2 3 445 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 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | Type=0xD2 | Reserved=0 |CF| Length | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | Version | Cipher suite | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | Compression method | Reserved = 0 | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 CF: Certificate flag: 1 bit 456 This flag indicates whether or not the server has a certificate. 457 This flag is set to 1 when the server has a certificate, else it is 458 zero. 460 Length: 16 bits unsigned integer 462 The chunk length is 8 bytes, including the chunk header, version and 463 cipher suite field. 465 Version: 16 bits unsigned integer 467 This field indicates the S-SCTP version 1.0. The high eight bits 468 indicate the major version, the low eight bits indicate the minor 469 version. 471 Cipher suite: 16 bits unsigned integer 473 This field indicates the cipher suite, which is used for a secure 474 session. The cipher suite includes necessary information for the key 475 derivation, message encoding and MAC computation. The server uses 476 the following rules to choose the cipher suite: 478 o Client and Server do not have a certificate: Use DH key exchange. 480 o Client or Server has a certificate: Use DH key exchange. 482 o Client and Server have a RSA certificate: Use RSA key exchange. 484 o Client and Server have a DSS certificate: Use DH key exchange. 486 Compression method: 16 bits unsigned char 488 This field indicates the compression method, which is used for data 489 compression in the secure session. 491 5.1.4. Secure Session Server Key chunk (SSSerKey) 493 This chunk includes the parameter which is used for the key exchange 494 algorithm. The Server Key Exchange chunk consists of the chunk 495 header and one parameter. The parameter type depends on the key 496 exchange algorithm. 498 0 1 2 3 499 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 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | Type=0xD3 | Reserved=0 |SL| Length | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 \ \ 504 / Parameter / 505 \ \ 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 Security level (SL): 2 bits 510 This 2-bit value indicates a server's security level of the reserved 511 flags. 513 Length: 16 bit unsigned integer 515 The length field contains the size of the chunk in bytes, including 516 the chunk header and parameter. 518 Parameters: 520 The following two parameters define the key exchange protocols. 521 Their parameter formats are shown in the next two tables. When a 522 user specifies a new cipher suite with a new key exchange algorithm, 523 then they must define a new parameter. 525 Diffie-Hellman parameter 527 The SSSerKey chunk uses this parameter when the handshake is done via 528 the DH key exchange algorithm. 530 0 1 2 3 531 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 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | Type=0xD001 | Length | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | Length of DH prime number, P | Length of DH prmitive root, R | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | Length of DH public key, Y | Reserved=0 | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 \ \ 540 / DH prime number, P / 541 \ \ 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 \ \ 544 / DH primitive root, R / 545 \ \ 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 \ \ 548 / DH value, Y / 549 \ \ 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 \ \ 552 / Signature / 553 \ \ 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 Length: 16 bit unsigned integer 558 The length field contains the size of the parameter in bytes, 559 including the parameter header, length of DH prime number, length of 560 DH primitive root, length of DH public key, reserved, DH prime 561 number, DH primitive root, DH public key and signature. 563 Length of DH prime number, P: 16 bits unsigned integer 565 This field contains the size of the DH prime number. 567 Length of DH primitive root, Q: 16 bits unsigned integer 569 This field contains the size of the DH primitive root. The size of 570 the prime number is equal R, where R is a random number defined in 571 the SSOpReq chunk. 573 Length of DH value, Y: 16 bits unsigned integer 575 This field contains the size of the DH public key. 577 DH value, P: Variable length 578 This is the prime number of the DH key exchange protocol. 580 DH value, Q: Variable length 582 This is the primitive root of the prime number P. 584 DH value, Y: Variable length 586 This is the public key of the DH key exchange protocol. 588 Signature: Variable length 590 The field contains the signature which is derived from the chunk 591 header and the whole parameter except the signature field. The 592 signature computation uses the signature algorithm which is defined 593 in the server certificate. If the server does not have a 594 certificate, this field does not exist in the parameter. 596 RSA parameter 598 The SSSerKey chunk uses this parameter when the handshake uses the 599 RSA key exchange algorithm. 601 0 1 2 3 602 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 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | Type=0xD002 | Length | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 \ \ 607 / Encrypted (random number, R) / 608 \ \ 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 \ \ 611 / Signature / 612 \ \ 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 Length: 16 bits unsigned integer 617 The length field contains the size of the parameter in bytes, 618 including the parameter header, the encrypted random number and the 619 signature. 621 Encrypted (Random number, R): Variable length 623 The random number is used to generate the secret keys for user data 624 encryption and authentication. The random number encryption uses the 625 client public key. 627 Signature: Variable length 629 The field contains the signature, which is derived from the chunk 630 header and the whole parameter except the signature field. The 631 signature computation uses the signature algorithm which is defined 632 in the server certificate. 634 5.1.5. Secure Session Client Key chunk (SSCliKey) 636 This chunk includes the parameters which are used for the key 637 exchange algorithm. The Secure Session Client Key Exchange chunk 638 consists of the chunk header and one parameter. The parameter format 639 depends on the key exchange algorithm. 641 0 1 2 3 642 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 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | Type=0xD4 | Reserved=0 |SL| Length | 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 \ \ 647 / Parameter / 648 \ \ 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 Security level (SL): 2 bits 653 This 2-bit value indicates a client's security level. 655 Length: 16 bit unsigned integer 657 The length field contains the size of the chunk in bytes, including 658 the chunk header and parameter. 660 Parameters: 662 Two new parameters are defined here that can appear in the SSCliKey 663 chunk. Their parameter formats are shown in the next two tables. 665 Diffie-Hellman parameter 667 The SSCliKey chunk uses this parameter when the handshake uses the DH 668 key exchange algorithm. 670 0 1 2 3 671 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 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 | Type=0xD003 | Length | 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 \ \ 676 / DH value, Y / 677 \ \ 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 \ \ 680 / Signature / 681 \ \ 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 Length: 16 bit unsigned integer 686 The length field contains the size of the parameter in bytes, 687 including the parameter header, the DH public key and the signature. 689 DH value, Y: Variable length 691 This field contains the public key of the DH key exchange protocol. 693 Signature: Variable length 695 The field contains a signature which is derived from the chunk header 696 and the whole parameter except the signature field. The signature 697 computation uses the signature algorithm defined in the client 698 certificate. If the client does not have a certificate, then this 699 field does not exist in the parameter. 701 RSA parameter 703 The SSCliKey chunk uses this parameter when the handshake uses RSA 704 key exchange algorithm. 706 0 1 2 3 707 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 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | Type=0xD003 | Length | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 \ \ 712 / Encrypted (random number, R) / 713 \ \ 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 \ \ 716 / Signature / 717 \ \ 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 Length: 16 bits unsigned integer 722 The length field contains the size of the parameter in bytes, 723 including the parameter header, the encrypted random number and a 724 signature. 726 Encrypted (Random number): Variable length 728 This field contains the random number, encrypted by the server's 729 public key, which is used to generate the master secret key for 730 encryption and authentication. 732 Signature: Variable length 734 The field contains the signature which is derived from the chunk 735 header and the whole parameter except the signature field. The 736 signature computation uses the signature algorithm defined in the 737 server certificate. 739 5.1.6. Secure Session Open Complete chunk (SSOpCom) 741 This chunk is the last chunk of the handshake and it indicates the 742 completion of the secure session establishment. After receiving this 743 chunk the endpoint verifies the verification data which is contained 744 in the chunk. The secure session procedure is complete when the 745 verification is successful. Otherwise the secure session will be 746 closed. 748 0 1 2 3 749 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 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | Type=0xD5 | Reserved=0 | Length | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 \ \ 754 / Verification data / 755 \ \ 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 Length: 16 bits unsigned integer 760 The length field contains the size of the chunk in bytes, including 761 the chunk header and verification data. 763 Verification data: Variable length 765 The verification data contains a hashed value which is an output of 766 the HMAC function. The HMAC uses the authentication secret key, 767 which is individually generated by the endpoints. The HMAC input 768 contains all received secure session handshake chunks of the current 769 endpoint. Both endpoints compute the hash value individually and 770 exchange it using the SSOpCom chunk. The receiver computes the hash 771 value using the same algorithm as the sender, and compares it with 772 the verification data. If the receiver's computed value is the same 773 as the sender's verification data, then the receiver assures that the 774 secure session open is successfully completed. If it is not the 775 same, then the receiver sends an ERROR message to the sender, and 776 immediately closes the secure session. 778 5.1.7. Secure Session Close chunk (SSClose) 780 This chunk indicates a request to close the current secure session. 781 The sender MUST NOT send any encrypted or authenticated chunks after 782 it has sent this chunk. 784 0 1 2 3 785 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 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | Type=0xD6 | Reserved=0 |OF| Length | 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 | TSN | 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 Outstanding flag (OF): 1 bit 794 This flag indicates that the endpoint has sent the SSClose chunk and 795 has no outstanding secured data. 797 Length: 16 bits unsigned integer 799 The length field contains the size of the chunk in bytes, including 800 the chunk header and TSN. 802 Transmission sequence number (TSN): 16 bits unsigned integer 804 This is the transmission sequence number of the data chunk that was 805 last encrypted and sent. The TSN helps the server to detect 806 outstanding EncData chunks. 808 5.1.8. Secure Session Close Acknowledge chunk (SSClose_Ack) 810 This chunk is used to acknowledge the receipt of the secure session 811 close chunk. When the endpoint receives the secure session close 812 chunk, it immediately stops sending encrypted or authenticated 813 chunks. The Secure Session Close Acknowledge chunk only consists of 814 the chunk header. 816 0 1 2 3 817 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 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 | Type=0xD7 | Reserved=0 | Length=4 | 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 5.1.9. Security Level Changed chunk (SecLevCHD) 824 This chunk is used to convey the other associated endpoint of the 825 endpoint's new security level. The endpoint sends SecLevCHD chunk 826 every time it selects a new security level. The endpoint uses the 827 new selected security level when it receives the Security Level 828 Changed Acknowledged chunk. The sender MUST NOT send a new SecLevCHD 829 chunk when an unacknowledged SecLevCHD chunk exists. 831 0 1 2 3 832 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 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 | Type=0xD8 | Reserved=0 |SL| Length=4 | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 Security level (SL): 2 bits 839 This 2-bit value indicates the sender's new security level. 841 5.1.10. Security Level Changed Acknowledged chunk (SecLevCHD_Ack) 843 This chunk is used to acknowledge the receipt of the SecLevCHD chunk. 844 When the endpoint receives the SecLevCHD chunk, it immediately sends 845 the SecLevCHD_Ack chunk. 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=0xD9 | Reserved=0 | Length=4 | 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 5.1.11. Encrypted Data Chunk (EncData) 855 Each S-SCTP packet includes at most one encrypted data chunk, and the 856 packet could also include several (normal, unencrypted) data chunks. 857 The encrypted data chunk may contain one or several data chunks. The 858 EncData chunk includes a padding chunk when it is needed. 860 0 1 2 3 861 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 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 | Type=0x10 | Reserved=0 | Length | 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 | Master secret key reference # | Random number length | 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 \ \ 868 / Random number / 869 \ \ 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 \ \ 872 / Encrypted data / 873 \ \ 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 Length: 16 bits unsigned integer 878 The length field contains the size of the chunk in bytes,including 879 the chunk header and encrypted data. 881 Master secret key reference number: 16 bits unsigned integer 883 The association can be updated by changing the master secret key 884 several times during the association lifetime. The association keeps 885 old secret keys. The number of the kept old secret keys depends on 886 the implementation. This field helps to identify which key (old or 887 new) has been used for encryption. That means the endpoint is able 888 to receive messages, which were encrypted with an old key, after the 889 update of a master secret key. 891 Random number length: 16 bits unsigned integer 893 This field contains the size of the random number which is defined 894 below. 896 Random number: Variable length 898 This field indicates the random number which is used as 899 initialisation vector of the cipher block chaining (CBC) mode for 900 encryption. 902 Encrypted data: Variable length 904 Contains a byte vector that consists of the encrypted data chunks. 905 Before encryption, the chunk(s) MUST fulfil the following conditions. 906 If encryption is performed using the DES or 3DES algorithm, the total 907 size of the chunk(s) MUST be a multiple of 8 bytes. If encryption is 908 performed using the AES algorithm, the total size of the chunk(s) 909 MUST be a multiple of 16 bytes. If the total size of the chunk(s) is 910 not a multiple of 8 bytes or 16 bytes, the sender MUST add 911 appropriate padding at the chunk's end. 913 5.1.12. Padding chunk (PADDING) 915 This padding chunk is used with an EncData chunk. The symmetric 916 encryption algorithms use a block oriented encryption of the user 917 data. For example DES uses 64 bit blocks, and AES uses 128 bit 918 blocks. Before encryption, the user data which has to be encrypted 919 has to be formatted according to the required block size. If the 920 last block is not completely full, padding has to be added. If less 921 than 4 bytes padding are required, the block is filled up will all 922 zeros. The receiver can calculate the number of padding bytes based 923 on the length field of the original data chunks. If 4 bytes or more 924 are required, a padding chunk of appropriate length is added. 926 The algorithms split user data into blocks when the data length is 927 greater than the block size. The blocks MUST be full. If 104 bits 928 are to be encrypted using DES algorithm with 64 bit block size, user 929 data is split into two blocks of 64 and 40 bits. The second block 930 must be padded with 24 bits up to the full block size of 64 bits. 932 0 1 2 3 933 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 934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 | Type=0x12 | Reserved=0 | Length | 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 | Padding | 938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 Length: Variable length 942 This field indicates the padding size. The padding follows the 943 padding chunk. The length includes the padding chunk and padding. 945 Padding: Variable length 947 The padding is a random number. The random number generation is 948 implementation specific. 950 5.1.13. Authentication chunk (AUTH) 952 This chunk is dedicated to the authentication of an S-SCTP packet. 953 S-SCTP inserts this chunk into the packet when the security level 954 requires authentication. 956 0 1 2 3 957 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 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 | Type=0x11 | Reserved=0 | Length | 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 | Master secret key reference # | Reserved=0 | 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 \ \ 964 / HMAC / 965 \ \ 966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 968 Length: 16 bits unsigned integer 970 The length field contains the size of the chunk in bytes, including 971 the chunk header, master secret key reference, reserved field and 972 MAC. 974 Master secret key reference number: 16 bits unsigned integer 976 The association can update the secret keys several times during the 977 association lifetime. The association keeps old secret keys. The 978 number of the kept old secret keys depends on the implementation. 979 This field identifies the key which is used for authentication. If 980 the endpoint receives a message which was authenticated by an old 981 key, this message can still be authenticated after an update of the 982 master secret key. 984 HMAC: Variable length 986 This field contains the authentication code for the SCTP packet. The 987 message authentication uses the HMAC algorithm defined in RFC 2104. 988 The hash function used in the HMAC algorithm is derived from the 989 negotiated cipher suite, which was chosen by the server. 991 6. New Error Cause 993 This part explains the new error causes defined for S-SCTP. When a 994 secure session or certificate failure is detected in the secure 995 session open process, the S-SCTP association immediately stops the 996 process. However, the association continues (without any security 997 functionality). When the secure session failure happens during an 998 update of the master secret key the association stops the update 999 operation and closes the secure session. The following table shows 1000 four general failure groups. 1002 Cause Code Value Cause Code 1003 ---------------- --------------------------------------- 1004 0x20 Secure Session failure 1005 0x21 Secure Session Certificate failure 1006 0x22 Secure Session Decryption failure 1007 0x23 Secure Session Authentication failure 1008 0x24 Secure Session Decompression failure 1010 6.1. Secure Session failure 1012 0 1 2 3 1013 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 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 | Cause Code=0x20 | Cause length = 8 | 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 | Error Code | Reserved=0 | 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 If any error happens in the secure session open and update process, 1021 endpoints alert their peers with these error codes. The next table 1022 shows error codes for what can happen. 1024 Error Code Value Error Code 1025 ---------------- ------------------------------------- 1026 0 Timer expired 1027 1 Signature failure 1028 2 Secure Session Open Complete failure 1030 o Timer expired: The sender starts a timer when it sends the secure 1031 session message. When the sender receives no response from the 1032 receiver before the timer expires, it sends this error code. 1034 o Signature failure: Some secure session chunks include a signature, 1035 which identifies and protects the secure session message. If the 1036 receiver checks the signature and cannot identify the chunk, this 1037 error code is used in the error chunk. 1039 o Secure Session Open Complete failure: This chunk is a very 1040 important part of the secure session. Both server and client 1041 individually compute the master secret and HMAC secret keys. Both 1042 sides check these secret keys and parameters (i.e. secure session 1043 chunks exchanged before, source and destination ports). If these 1044 keys are not identical, an error chunk is sent containing this 1045 error code. 1047 6.2. Secure Session Certificate failure 1049 0 1 2 3 1050 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 1051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1052 | Cause Code=0x21 | Cause length = 8 | 1053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1054 | Error Code | Reserved=0 | 1055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1057 The certificate failure signals that an error has occurred in 1058 processing the certificates. The next table shows error codes for 1059 what can happen. 1061 Error Code Value Error Code 1062 ---------------- ------------------------------------- 1063 0 No certificate 1064 1 Bad certificate 1065 2 Certificate expired 1066 3 Unknown certificate 1068 o No certificate: This error happens when the sender sets the CF 1069 flag and the receiver does not receive the certificate. 1071 o Bad certificate: The signature of the certificate is bad and the 1072 certificate could not be verified. 1074 o Certificate expired: The certificate is no longer valid. 1076 o Unknown certificate: The received certificate a X.509v3 1077 certificate. 1079 6.3. Decryption failure 1081 This error happens when the EncData chunk cannot be decrypted or the 1082 data chunk(s) cannot be identified after decryption. The receiver 1083 discards the EncData and increases a counter by 1. This counter 1084 counts errors. If the number of errors reaches a limit, the secure 1085 session is terminated. The limit of the errors depends on the 1086 implementation. 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=0x22 | Cause length = 4 | 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1094 6.4. Authentication failure 1096 In the event of a HMAC error, the packet is discarded by the 1097 receiver. To check for an error, the receiver computes the HMAC and 1098 compares it to the HMAC field of the packet. If they do not match, 1099 an error is reported back. 1101 0 1 2 3 1102 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 1103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1104 | Cause Code=0x23 | Cause length = 4 | 1105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1107 6.5. Decompression failure 1109 This error happens when the compressed chunk(s) cannot be 1110 decompressed or the data chunk(s) cannot be identified after 1111 decompression. The receiver discards the decompressed chunk(s). 1113 0 1 2 3 1114 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 1115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1116 | Cause Code=0x24 | Cause length = 4 | 1117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 7. S-SCTP packet format and security levels 1121 S-SCTP has four different security levels, which cover privacy 1122 settings of an S-SCTP association. The S-SCTP application can change 1123 the security levels at any time during the security session lifetime. 1125 o Security level 0: This is the null security level. S-SCTP does 1126 use neither data chunk encryption nor authentication. The S-SCTP 1127 packet is the same as the SCTP packet (this level is fully 1128 compatible to SCTP). 1130 o Security level 1: This security level requires packet 1131 authentication but does not use encryption. Every outgoing packet 1132 (including the SCTP common header) is authenticated. 1134 o Security level 2: In this security level, data chunks may be 1135 encrypted. When an S-SCTP packet contains an encrypted data 1136 chunk, it MUST include an AUTH chunk as well. That means every 1137 chunk and the packet header are authenticated. When a packet 1138 includes only unencrypted data chunks or control chunks or both 1139 unencrypted data chunks and control chunks, the packet will not be 1140 authenticated. 1142 o Security level 3: This is the highest security level. S-SCTP 1143 requires both encryption and authentication. Every outgoing chunk 1144 is encrypted and the packet is authenticated. 1146 Both endpoints can use different security levels, e.g. the 1147 association can use security functions only for one direction, e.g. 1148 from server to client. In this case the server uses security level 3 1149 and the client uses security level 0. The transmission control block 1150 (TCB) of the association includes the security level as a new 1151 parameter. 1153 8. S-SCTP data format 1155 S-SCTP sorts data chunks before bundling them into the outgoing SCTP 1156 packet. The data chunks are sorted according to whether they have to 1157 be encrypted or not. The chunks belonging to the encryption group 1158 are concatenated and encrypted into an EncData chunk. May be a 1159 PADDING chunk is inserted into the encryption group. Insertion of a 1160 PADDING chunk is done depending on data length and encryption block 1161 size. 1163 An assortment of encrypted and non-encrypted chunks are bundled in 1164 the packet. The control chunk(s) are placed first in the packet when 1165 bundled with other chunks. Finally, an AUTH chunk may be added to 1166 the packet. 1168 HMAC computation is performed over all chunks and the SCTP common 1169 header with a 0 checksum. The checksum is then computed over the 1170 complete packet (including AUTH chunk). The HMAC length depends on 1171 the hash function in the cipher suite. In every security level, the 1172 SCTP packet construction is slightly different. In security level 0 1173 the packet format is same as the SCTP packet format. 1175 9. Procedures 1177 In this section an explanation of the procedures of secure session: 1178 initialisation, termination, update and etc., is given. 1180 9.1. Establishment of a secure session 1182 The following process is used to establish the S-SCTP secure session. 1183 The handshake process runs in parallel with the data transmission. 1184 The secure session start and close is controlled by the user. The 1185 user can establish and close a secure session at any time during the 1186 association lifetime. Each time a secure session is established, a 1187 new set of keys is generated. It is not possible to create a new 1188 secure session when a secure session already exists. The following 1189 describes secure session establishment, which makes use of a 1190 handshake timer and retransmissions in case packets are lost during 1191 transmission. S-SCTP uses a four-way handshake. After all messages 1192 of one of the connection "legs" have been sent, client or server 1193 starts a RTO.hand (handshake retransmission time out) timer. For 1194 example, the secure session certificate is the last handshake message 1195 of the first leg. The sender waits for a response from the receiver 1196 until the RTO.hand timer expires. The sender stops the RTO.hand 1197 timer when it receives the expected message(s). If the RTO.hand 1198 timer expires before all expected messages have been received, the 1199 sender retransmits the handshake message(s). 1201 The retransmission uses the following algorithm. The RTO.hand timer 1202 gets a value from RTO of the path where the message is sent to, which 1203 is defined in RFC4960. Before a retransmission, the sender checks 1204 RTN.hand.max (handshake maximum retransmission number). This initial 1205 value is dependent upon specific implementations. The suggested 1206 value for RTN.hand.max is Path.Max.Retrans (see RFC 4960). 1208 RTN.hand.max should be a constant parameter. We introduce a counter 1209 for the number of retransmissions, and if that counter exceeds the 1210 parameter RTN.hand.max, the timer expired error message is sent to 1211 the peer. If a retransmission is required then S-SCTP uses the same 1212 retransmission rules as defined in RFC4960. If the receiver receives 1213 a retransmission of a handshake message that was already received, 1214 the message last received MUST be dropped. The endpoint discards the 1215 message(s) when they are unexpected. A secure session initialisation 1216 begins when one of the associated endpoints sets the security level 1217 to a value higher than 0. The endpoint starting a secure session 1218 initialisation is called client and the other associated endpoint is 1219 called server. 1221 o The client sends the SSOpReq chunk to the server. If the client 1222 has a certificate, it sets the CF flag of the SSOPReq chunk to 1. 1223 The client sends the SSCert chunk immediately after the SSOpReq 1224 chunk. The SSCert chunk can be bundled with the SSOpReq chunk or 1225 with other chunk(s). When the CF flag is set to 0, the client 1226 sends only the SSOpReq chunk. 1228 o The server receives a SSOpReq chunk and checks the CF flag. If 1229 the CF flag is set to 1, the server waits for the SSCert chunk. 1230 Upon receipt, the server checks the certificate and if there is a 1231 problem with it, the server stops the handshake and goes to an 1232 error state, aborts secure session setup and reports the cause to 1233 its peer. It there is no error, the server chooses the cipher 1234 suite and sends the SSOpReq_Ack chunk with CF=1 flag to the client 1235 when the server has a certificate. The server immediately sends 1236 the certificate and the SSSerKey chunks after the SSOpReq_Ack 1237 chunk. All three chunks may be bundled together or with other 1238 chunks. The server sends only the SSOpReq_Ack chunk with the 1239 SSSerKey chunk if CF=0. Before sending the server key exchange 1240 chunk, the server generates key material. The server starts the 1241 update master secret key operation when it receives the SSOpReq 1242 chunk after secure session establishment. If the server receives 1243 the SSCert chunk before the SSOpReq chunk, it stores the SSCert 1244 chunk and waits until it receives the SSOpReq chunk. But the 1245 server drops a second SSCert chunk. 1247 o The client receives the handshake messages and checks the 1248 certificate in the SSSerKey chunk. If the client detects any 1249 errors, it stops the handshake and goes to an error state, aborts 1250 secure session setup and reports the cause to its peer. The 1251 client generates key material and sends the SSCliKey chunk to the 1252 server. The client sends the SSOpCom chunk immediately after the 1253 client key exchange chunk. Before sending the handshake-finished 1254 chunk, the client computes the encryption secret and MAC secret 1255 keys. 1257 o The server receives the SSCliKey chunk and computes the master 1258 secret and the MAC secret keys. It then computes the SSOpCom 1259 chunk and sends it to the client. Finally, the server checks the 1260 SSOpCom chunk of the client. If the server detects any error, it 1261 reports a secure session open complete error and closes the 1262 handshake. The secure session is established only when both sides 1263 detect no errors. The server is ready for secure transmission 1264 when it detects no errors, but the client must wait for the 1265 SSOpCom chunk of the server. When this is received, the client 1266 checks it and reports to the peer a secure session open complete 1267 error if any error is detected before aborting secure session 1268 setup. The handshake may run simultaneously with normal SCTP data 1269 transmission. If the client receives encrypted or authenticated 1270 data chunks before it receives the server's SSOpCom chunk, then 1271 those chunks MUST be discarded. 1273 When both associated endpoints request the initialisation of a secure 1274 session simultaneously (both endpoints send an SSOpReq message), both 1275 ignore the received SSOpReq message and wait a random time before 1276 resending the SSOpReq message. Each endpoint generates the random 1277 time independently. The random number must be small, e.g. 120 1278 seconds maximum. 1280 9.2. Choice of cipher suite and compression method 1282 This section explains how to choose the cipher suite and compression 1283 method which are used for the secure session. Each endpoint 1284 maintains an ordered list of supported cipher suites (cipher suite 1285 list). The ordering in the list indicates the preference with which 1286 a cipher suite should be used (first in the list have higher 1287 preference). The order in the list is defined by the retrospective 1288 S-SCTP user. 1290 S-SCTP users on both sides can allow all cipher suited in the list 1291 when establishing a secure session or limit the allowed cipher suites 1292 to a subset. The complete list or the selected subset can be 1293 indicated to the server in the SSOpReq. If the complete list is 1294 sent, the default cipher suite list must be located first in the 1295 list. The server uses the following rules to choose the cipher suite 1296 to be used for the secure session: 1298 The server chooses the default cipher suite, if the SSOpReq chunk 1299 does not contain any cipher suite. 1301 The server gets the first cipher suites from SSOpReq chunk and 1302 server's cipher suite sequence. When both cipher suites are 1303 identical the server chooses this cipher suite for the secure 1304 session. Otherwise, the server takes its first cipher suite and 1305 looks for a match in the cipher suite sequence of the client. When 1306 there is no matche, the server takes the client's first cipher suite 1307 and searches for match in its cipher suite sequence. S-SCTP checks 1308 the first cipher suite in the SSOpReq chunk against all cipher suites 1309 in the cipher suite list of the server. If no match is found, all 1310 subsequent cipher suites in the SSOpReq are checked sequentially in 1311 the order they appear in the SSOPReq until a match is found. The 1312 first cipher suite supported by both endpoints is chosen. When two 1313 cipher suites match each other then this cipher suite is selected for 1314 the secure session. If not, the server looks, its second cipher 1315 suite, for a match in the cipher suite sequence of the client. 1316 Furthermore, the server uses the same mechanism to look a cipher 1317 suite for the secure session. 1319 The server chooses the default cipher suite, when the cipher suites 1320 in the SSOpReq chunk are not supported by the server. 1322 Both client and server also maintain a list of compression methods. 1323 The choice of the compression mechanism works similarly to the cipher 1324 suite selection mechanism described above. S-SCTP uses a NULL 1325 compression method as default compression method. 1327 9.3. Data transfer 1329 Before transporting the packet over the network, S-SCTP takes the 1330 following steps. First, it checks the security level. If the 1331 security level is: 1333 o 0, jump to step "d" 1335 o 1, jump to step "c" 1337 o 2, check the user data. If the user data requires encryption, 1338 jump to step "a" . If the user data does not require encryption, 1339 jump to step "c" 1341 o 3, jump to step "a" 1343 a) S-SCTP sorts data chunks in two groups, which are encrypted and 1344 unencrypted. The encrypted group consists of those data chunks 1345 requiring encryption. The unencrypted group consists of those 1346 data chunks not requiring encryption. If the secure session's 1347 security level is set to 3, all chunks are sorted into the 1348 encrypted group. 1350 b) The data chunks in the encrypted group are concatenated. After 1351 this, S-SCTP calculates the padding chunk and inserts the padding 1352 chunk on the last position into pre-enc-data if necessary. The 1353 Pre-enc-data size MUST be smaller than the current MTU. If the 1354 pre-enc-data is bigger than the current MTU, S-SCTP must create 1355 two pre-enc-datas. Every pre-enc-data is encrypted and stored in 1356 the encryption data field of the EncData chunk. 1358 c) SCTP builds the packet according to the security level and 1359 inserts the AUTH chunk in the last position in the packet. 1361 d) S-SCTP sends the packet. 1363 9.4. Closing of a secure session 1365 The termination of a secure session begins when one of the endpoints 1366 sends the secure session close chunk. This chunk includes the last 1367 encrypted data TSN and OF. The endpoint (sender) stops the 1368 encryption or authentication of all chunks or packets after it has 1369 sent the secure session close chunk. But normal (unsecured) data 1370 transfer will continue. The endpoint then waits until it receives 1371 the SSClose_Ack chunk. After receiving the SSClose_Ack chunk, the 1372 association clears the TCB parameters belonging to the secure 1373 session. The receiver (other endpoint) immediately stops encryption 1374 and authentication of all chunks or packets after it receives the 1375 secure session close chunk. Before sending the SSClose_Ack, the 1376 receiver waits for outstanding data (encrypted or authenticated 1377 data), which are the receiver's unacknowledged data chunks and 1378 sender's data chunks that have a TSN less than the last encrypted 1379 data TSN in the SSClose chunk. If the receiver does not receive the 1380 outstanding data chunks before RTO.hand timer expires, the S-SCTP 1381 association closes the secure session and outstanding data chunks 1382 will be dropped. The receiver ignores the last TSN of SSClose chunk 1383 and waits only for the receiver's unacknowledged data chunks when 1384 SSClose chunk's OF=1. The SSClose and SSClose_Ack chunks may be 1385 bundled with other chunks. If the sender does not receive the 1386 acknowledge chunk, the client follows the standard retransmission 1387 rule for messages. After the termination of the secure session, the 1388 TCB parameters belonging to the secure session MUST be set to zero. 1389 If the SCTP association begins to close the current association, the 1390 SSClose chunk is sent. If the SCTP association creates an ABORT 1391 chunk, the secure session closes immediately and the TCB parameters 1392 belonging to the secure session MUST be set to zero. 1394 9.5. Generation of the Master secret key 1396 Secret key generation uses the 3DES_CBC algorithm. Both server and 1397 client compute the master secret key separately. The key material is 1398 split into 64 bit blocks. Every block will be input to the 3DES_CBC 1399 encryption. The key material is as follows: 1401 o If the secure session key exchange algorithm uses DH, the key 1402 material consists of the DH's secret key. 1404 o If the secure session key exchange algorithm uses RSA, the key 1405 material consists of random numbers of both client and server. 1407 9.6. Update of the master secret key 1409 A secure update mechanism of the secret keys is a very important 1410 requirement for a secure session. The secret keys consist of the 1411 master secret key, which is used for data chunk encryption, and the 1412 HMAC secret key, which is used for packet authentication. If an 1413 association exists for a long time, the S-SCTP association needs to 1414 update the secret keys. Both the client and the server can request 1415 an update of the secret keys. A three way handshake, called an 1416 abbreviated handshake, is used to update the master secret keys. All 1417 actions of the handshake are encrypted by the current master secret 1418 key. The current security level does not affect the packets, which 1419 contain the handshake messages. The key update handshake works 1420 similar to the first establishment handshake (e.g. the endpoints 1421 start an RTO.hand timer when sending handshake chunks). Format and 1422 function of the chunks used to update keys are the same as for the 1423 handshake. When an endpoint receives a SSOpReq chunk (after a secure 1424 session establishment) it begins to update secret keys. Both the 1425 server and client key exchange chunks always use the RSA key exchange 1426 algorithm. The random numbers in SSSerKey and SSCliKey chunks are 1427 encrypted by the current master secret key. The following describes 1428 the method used to update the master secret key: 1430 The client generates a random number and sends the SSopReq chunk with 1431 the SSCliKey chunk. The key material length in the handshake request 1432 chunk may be equal to 0. If not, the number indicates the size of 1433 the new key material. If 0, both sides will use the key material 1434 length which was used in the last handshake. The server sends the 1435 SSop_Ack, the SSSerKey and the SSOpCom chunks immediately after 1436 receiving the SSOpReq and the SSCliKey chunks. After receiving the 1437 handshake messages from the server, the client computes a new master 1438 secret key and checks the SSOpCom chunk of the server. If it detects 1439 any error, the client closes the secure session and reports an error 1440 to the peer. The client computes the SSOpCom chunk and sends it to 1441 the server. After sending the SSOpCom chunk the client is ready to 1442 use the new master secret key. The server receives the SSOpCom chunk 1443 of the client and checks the new keys. If it detects any error, the 1444 server closes the secure session and reports an error to the peer. 1445 Before receiving the client's SSOpCom chunk, the server discards any 1446 encrypted or authenticated chunk that make use of the new master 1447 secret key. 1449 The encrypted and unencrypted user data transmission works in 1450 parallel with the update operation. After the update operation, the 1451 new master secret key is used for data encryption and authentication. 1452 When both client and server receive an SSOpReq chunk simultaneously, 1453 the client ignores the server's SSopReq chunk and the server accepts 1454 the client's SSOpReq chunk. The next steps are the same as for the 1455 secure session initialisation. 1457 The new master secret key generation uses the same algorithm as 1458 described above. The secure session includes one parameter which is 1459 called secure session lifetime. This parameter is used to initialise 1460 a timer which indicates the secure session secret key's lifetime in 1461 seconds. When the timer expires, the association automatically 1462 updates the secret keys. The user can define this parameter. If the 1463 user does not define it, the parameter assumes a default value. This 1464 default value depends on the implementation. The implementation MUST 1465 define secure session's lifetime initial value. We suggest a value 1466 of 600 seconds for the lifetime as a compromise between security and 1467 overhead. 1469 9.7. Random number generation 1471 As the security of S-SCTP depends on the quality of the random number 1472 generator, we suggest to use one according to RFC4086 [RFC4086]. 1474 9.8. HMAC algorithm 1476 S-SCTP uses the HMAC algorithm which is defined in RFC2104 [RFC2104] 1477 for the packet authentication. 1479 10. HMAC algorithm 1481 ULP-to-SCTP primitives deliver upper layer requests to S-SCTP. The 1482 following part describes new ULP-to-SCTP primitives and thus enhances 1483 the section 10 of RFC4960. All new ULP-to-SCTP primitives described 1484 below are defined in the ssctp.h header file. 1486 INITSECSESS: This primitive initialises a new secure session. 1488 Format: {initSecSess(secure session ID, key material length, cipher 1489 suites list, compression methods list, certiticate(s) ) --> result} 1491 o secure session ID: This parameter identifies a secure session. 1493 o key material length: This defines the key material length which is 1494 used in the SSOPReq chunk. 1496 o cipher suite list: Eligible cipher suites for a new secure 1497 session. 1499 o compression method list: Eligible compression methods for a new 1500 secure session. 1502 o certificate(s): Local endpoint certificate(s). 1504 SETSECLEVEL: This primitive sets a new security level for an existing 1505 secure session. 1507 Format: {setSecLevel(secure session ID, security level) --> result} 1509 o secure session ID: local handle to the secure session 1511 o security level: This parameter indicates the new security level 1513 GETSECLEVEL: This primitive gets the current security level of a 1514 secure session. 1516 Format: {getSecLevel(secure session ID) --> security level} 1518 o secure session ID: local handle to the secure session 1520 SENDSEC: This primitive sends secure data via S-SCTP. 1522 Format: {sctp_send_enc(association id, buffer address, byte count, 1523 context, stream id, life time, destination transport address, unorder 1524 flag, no-bundle flag, payload protocol-id, encryption flag, 1525 compression flag) --> result} 1526 Every parameter, except the encryption and compression flags, defined 1527 in this function is the same as the corresponding parameter defined 1528 in the SEND function of RFC4960 section 10. 1530 o encryption flag: This flag defines if a current user data message 1531 needs encryption or not. 1533 o compression flag: This flag defines if a current user data message 1534 needs compression or not. 1536 GETSECSTATUS: This primitive gets the security status of an 1537 association. The security status indicates if the SCTP association 1538 is using a secure session or not. 1540 Format: {setSecStatus(association ID) --> status} 1542 o association ID: local handle to the SCTP association. 1544 SETSECSESSTTL: This primitive sets a new lifetime for a secure 1545 session. 1547 Format: {setSecSessTTL(secure session ID, Time) --> result} 1549 o secure session ID: local handle to the secure session. 1551 o time: The new lifetime in seconds. 1553 SHUTSECSESS: This primitive deletes a secure session. 1555 Format: {shutSecSess(secure session ID) --> result} 1557 o secure session ID: local handle to the secure session. 1559 o security level: This parameter indicates the new security level. 1561 11. S-SCTP to ULP 1563 S-SCTP defines new notifications to deliver information to the upper 1564 layer. The notifications extend the section 10.2 of RFC4960 1565 [RFC4960]. All new notifications are defined in the ssctp.h header 1566 file. 1568 SECSESSUP: 1570 This notification indicates that S-SCTP is ready to send or receive 1571 secure data ({secsessUpNotif()}). 1573 SECSESSDOWN: 1575 This notification indicates that an association has lost a secure 1576 session ({secsessdownNotif()}). 1578 SECSESSREKEY: 1580 This notification indicates that a secure session updated the secret 1581 keys ({secsessrekeyNotif()}). 1583 Additional changes had to be made in the socket API implementation to 1584 access the new sctplib functions described above. A user calls the 1585 same socket API functions as in standard SCTP to send and receive 1586 user data, but has to set an additional encryption flag (MSG_ENC) to 1587 request encryption of user data. Also, a compression flag (MSG_COMP) 1588 has to be set in ext_send, ext_sendto, ext_sendmsg to request 1589 compression of user data. S-SCTP compression performs per user 1590 message not per chunk or per packet. In the SCTP DATA chunk, a new 1591 flag is defined, which indicates if the data is compressed or not. 1592 On the receiver side there are no changes. 1594 12. Transmission Control Block (TCB) extension 1596 A SCTP TCB contains parameters which are related to an association 1597 (e.g. an association id, port number, IP address list...). S-SCTP 1598 defines several parameters which are related to a secure session and 1599 it extends the TCB defined in section 12 of RFC4960. 1601 Security level: 1603 This parameter contains the association's current security level. 1605 Second security level: 1607 This is the security level of the associated second endpoint. 1609 Key material length: 1611 The size of the key material, which was last used for key generation. 1613 Secure session status: 1615 This parameter indicates whether the association is using a secure 1616 session or not. 1618 Secure session lifetime: 1620 This parameter indicates the lifetime of the secret keys of a secure 1621 session. 1623 Server indication: 1625 This parameter indicates if an endpoint is server or client. If the 1626 parameter is equal to 1 then it is a server, otherwise it is a 1627 client. 1629 Secure session ID: 1631 This parameter indicates the local secure session ID. 1633 Master secret key reference: 1635 This is an "array of secret data" collection and every array element 1636 includes the following parameters. 1638 o Selected cipher suite: This parameter indicates the encryption and 1639 authentication algorithms that are used in a secure session. 1641 o Selected compression: This parameter indicates the compression 1642 method that is used in a secure session. 1644 o Encryption key: This is a secret key which is used for encryption. 1646 o Authentication key: This is a secret key which is used for 1647 authentication. 1649 This information is used in EncData and AUTH chunks. 1651 13. Socket API extensions for Secure SCTP 1653 S-SCTP defines new socket options for the ext_setsockopt() and 1654 ext_getsockopt() socket functions to initialise, delete and rekey a 1655 secure session. A user calls the ext_setsockopt or ext_getsockopt 1656 functions with a new option. It is not necessary to define new 1657 socket API functions, as this is a more standard socket API fashion. 1658 The following paragraphs describe the new socket options. 1660 SSCTP-INIT: 1662 This socket option is used to initialise or update a secure session. 1663 The following structure is used to access these parameters. 1665 struct ssctp_init { 1666 uint16_t secsessID; 1667 uint16_t key_length; 1668 uint8_t num_cipher; 1669 uint8_t *cipher_suites; 1670 uint8_t num_comp; 1671 uint8_t *comp_methods; 1672 uint8_t *certificate; 1673 }; 1675 o secsessID: This parameter indicates a current secure session ID. 1677 o key_length: This parameter defines the length of a key material. 1679 o num_cipher: This parameter defines the number of cipher suites. 1681 o cipher_suites: This parameter includes a list of cipher suites. 1683 o num_comp: This parameter defines the number of compression 1684 methods. 1686 o comp_methods: This parameter includes a list of compression 1687 methods. 1689 o certificate: This parameter includes a certificate of the 1690 endpoint. 1692 SSCTP-SECLEVEL: 1694 This socket option is used to set and get a secure session security 1695 level. The following structure is used to access and modify these 1696 parameters. 1698 struct ssctp_seclevel { 1699 uint16_t secsessID; 1700 uint8_t seclevel; 1701 }; 1703 o secsessID: This parameter indicates a current secure session ID. 1704 This parameter MUST be zero when beginning a secure session 1705 initialisation. 1707 o seclevel: This parameter contains a new security level before 1708 socket write access or contains the current security level after 1709 socket read access. 1711 SSCTP-SECSTATUS: 1713 This socket option is used to get the secure session status and 1714 secure session ID when a secure session exists. The following 1715 structure is used to access these parameters. 1717 struct ssctp_secstatus { 1718 uint16_t secsessID; 1719 uint8_t sec_status; 1720 }; 1722 o secsessID: This parameter contains the current secure session ID. 1723 This parameter MUST be zero when a secure session does not exist. 1725 o sec_status: This parameter contains a security status. This 1726 parameter MUST be zero when a secure session does not exist. This 1727 parameter is equal to 1 when a secure session exists. 1729 SSCTP-SECSESSTTL: 1731 This socket option is used to set and get the secure session 1732 lifetime. The following structure is used to access and modify these 1733 parameters. 1735 struct ssctp_secsessTTL { 1736 uint16_t secsessID; 1737 uint16_t secsessTTL; 1738 }; 1740 o secsessID: This parameter indicates the current secure session ID. 1742 o secsessTTL (seconds): This parameter contains a new secure session 1743 lifetime before socket write access or contains a current secure 1744 session lifetime after socket read access. 1746 SSCTP-CLOSE: 1748 This socket option is used to close an existing secure session. The 1749 following structure is used to access these parameters. 1751 struct ssctp_secclose { 1752 uint16_t secsessID; 1753 }; 1755 o secsessID: This parameter contains the current secure session ID. 1757 14. Testbed Platform 1759 A large-scale and realistic Internet testbed platform with support 1760 for the multi-homing feature of the underlying SCTP protocol is 1761 NorNet. A description of NorNet is provided in [PAMS2013-NorNet], 1762 some further information can be found on the project website 1763 [NorNet-Website]. 1765 15. Security Considerations 1767 Security has been described in the previous sections. 1769 16. IANA Considerations 1771 This document introduces no additional considerations for IANA. 1773 17. References 1775 17.1. Normative References 1777 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1778 Hashing for Message Authentication", RFC 2104, 1779 February 1997. 1781 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1782 Requirement Levels", BCP 14, RFC 2119, March 1997. 1784 [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport 1785 Layer Security over Stream Control Transmission Protocol", 1786 RFC 3436, December 2002. 1788 [RFC3554] Bellovin, S., Ioannidis, J., Keromytis, A., and R. 1789 Stewart, "On the Use of Stream Control Transmission 1790 Protocol (SCTP) with IPsec", RFC 3554, July 2003. 1792 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1793 Requirements for Security", BCP 106, RFC 4086, June 2005. 1795 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 1796 RFC 4960, September 2007. 1798 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1799 Housley, R., and W. Polk, "Internet X.509 Public Key 1800 Infrastructure Certificate and Certificate Revocation List 1801 (CRL) Profile", RFC 5280, May 2008. 1803 17.2. Informative References 1805 [NorNet-Website] 1806 Dreibholz, T., "NorNet -- A Real-World, Large-Scale Multi- 1807 Homing Testbed", Online: http://www.nntb.no/, 2013. 1809 [PAMS2013-NorNet] 1810 Dreibholz, T. and E. Gran, "Design and Implementation of 1811 the NorNet Core Research Testbed for Multi-Homed Systems", 1812 Proceedings of the 3nd International Workshop on Protocols 1813 and Applications with Multi-Homing Support (PAMS) , 1814 March 2013. 1816 Authors' Addresses 1818 Carsten Hohendorf 1819 University of Duisburg-Essen, Institute for Experimental Mathematics 1820 Ellernstrasse 29 1821 45326 Essen, Nordrhein-Westfalen 1822 Germany 1824 Email: hohend@iem.uni-due.de 1826 Esbold Unurkhaan 1827 Mongolian University of Science and Technology 1828 Bayanzurkh duureg, 2-nd khoroo 1829 313/49 Ulaanbaatar 1830 Mongolia 1832 Email: esbold@csms.edu.mn 1834 Thomas Dreibholz 1835 Simula Research Laboratory, Network Systems Group 1836 Martin Linges vei 17 1837 1364 Fornebu, Akershus 1838 Norway 1840 Phone: +47-6782-8200 1841 Fax: +47-6782-8201 1842 Email: dreibh@simula.no 1843 URI: http://www.iem.uni-due.de/~dreibh/