| Network Working Group | C. Hohendorf |
| Internet-Draft | University of Duisburg-Essen |
| Intended status: Experimental Protocol | E. Unurkhaan |
| Expires: January 01, 2013 | Mongolian University |
| T. Dreibholz | |
| Simula Research Laboratory | |
| July 2, 2012 |
Secure SCTP
draft-hohendorf-secure-sctp-14.txt
This document explains the reason for the integration of security functionality into SCTP, and gives a short description of S-SCTP and its services. S-SCTP is fully compatible with SCTP defined in RFC4960, it is designed to integrate cryptographic functions into SCTP.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 01, 2013.
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
SCTP is a message oriented reliable transmission protocol which works on top of the IP-based network. It provides several advantages over other transmission protocols, such as TCP and UDP over IP. One of the advantages is multistreaming -- user data transported by individual streams. When multistreaming is used, network blocking can be avoided in certain cases (e.g. network loss). Also, SCTP supports multihoming -- the endpoints support multiple IP addresses. SCTP provides unordered delivery, so that a receiver immediately delivers user data to the upper layers upon receipt. For more details, see RFC4960 [RFC4960].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
S-SCTP provides security functionalities in the transport layer without the need for any other security protocols (e.g. TLS or IP-sec). Normally, a data transport over SCTP can either be secured with TLS or can be protected by IPsec. As both TLS over SCTP and SCTP over IPsec have disadvantages in certain scenarios, it is preferable to integrate cryptographic functions into SCTP.
The main issues for the security solutions TLS over SCTP RFC3436 [RFC3436] and SCTP over IPSec RFC3554 [RFC3554] is scalability with the number of streams. For N secure streams, N TLS connections have to be created, and N handshakes have to be performed. If N is small, this is not a big issue, but as N grows larger, it becomes a problem because a handshake is a slow and expensive process. So, when an application performs N handshakes, the load in terms of memory use, CPU use etc. increases linearly over time. This problem could be overcome by using IPsec. However, IPsec is not so flexible and on the other hand SCTP over IPsec has to establish new security associations (SA) for newly added IP addresses in dynamic address reconfiguration scenario. In this case, the application has to configure a new SA and to negotiate a new key exchange.
This part gives the definitions of the key terms, which are used in this draft:
Several new chunks and parameters are defined in S-SCTP. This section explains those chunks and parameters. All new chunks can be bundled with other chunks. The new parameters follow the Type-Length-Value format as defined in section 3.2.1 of RFC4960.
The following table shows the new chunks. All new chunks, except for the Encrypted Data (EncData) chunk, Authentication (AUTH) chunk and Padding (PADDING) chunk, are used for building the secure session and to update the master secret key. The new chunks are to be interpreted as described in Section 3.2 of RFC 4960, by the receiver.
Chunktype Chunk name
--------- ---------------------
0xD0 Secure Session Open Request Chunk
0xD1 Secure Session Certificate Chunk
0xD2 Secure Session Acknowledge Chunk
0xD3 Secure Session Server Key Chunk
0xD4 Secure Session Client Key Chunk
0xD5 Secure Session Open Complete Chunk
0xD6 Secure Session Close Chunk
0xD7 Secure Session Close Acknowledge Chunk
0xD8 Security Level Change Chunk
0xD9 Security Level Change Acknowledge Chunk
0x10 Encrypted Data Chunk
0x11 Authentication Chunk
0x12 Padding Chunk
The new parameters are defined in this section.
An endpoint creates the Secure Session Open Request chunk (see next table)when it wishes to establish a secure session. The chunk can be bundled with other chunks. The SSOpReq chunk can also be used to update the master secret key or cipher suite after a secure session establishment. During the association lifetime, both associated endpoints can request an update of the master secret key or cipher suite; in this case, the requesting endpoint sends the SSSOpReq chunk immediately to the other endpoint.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0xD0 | Reserved=0 |CF| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Key material length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Optional parameters /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CF: Certificate flag: 1 bit
This flag indicates whether or not the client will send a certificate. It is set to 1 when the client sends a certificate. If a receiver receives SSOpReq chunk with CF=1 and does not receive a certificate it raises an error and terminates the secure session initialisation.
Length: 16 bits unsigned integer
The length field contains the size of the chunk in bytes, including the chunk header, version, random number length and optional parameter(s).
Version: 16 bits unsigned integer
This field indicates the S-SCTP version 1.0. The high eight bits indicate the major version, the low eight bits indicate minor version.
Key material length: 16 bits unsigned integer
This number has two meanings:
Parameter(S):
SSOpReq chunk includes the cipher suite and compression method parameters, which are described below:
Cipher suite parameter:
This parameter contains the cipher suites, which are chosen from all supported cipher suites by the client. One of them is used for the secure session. The user can choose certain cipher suites from the cipher suites supported by the client.
0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=30 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cipher suite 1 | Cipher suite 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .............. | .............. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cipher suite N-1 | Cipher suite N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cipher suite: 16 bits unsigned integer:
This field indicates a cipher suite, which is supported by the client. The next table includes cipher suites supported in S-SCTP. Additional cipher suites can be specified.
Value Cipher suite Key exchange Encryption Hash
----- ------------------------- ------------ ---------- ---------
1 RSA_with_DES_CBC_MD5 RSA DES_CBC MD5
2 RSA_with_DES_CBC_SHA-1 RSA DES_CBC SHA-1
3 RSA_with_3DES_CBC_MD5 RSA 3DES_CBC MD5
4 RSA_with_3DES_CBC_SHA-1 RSA 3DES_CBC SHA-1
5 RSA_with_AES-128_CBC_MD5 RSA AES-128 MD5
6 RSA_with_AES-128_CBC_SHA-1 RSA AES-128 SHA-1
7 DH_with_DES_CBC_MD5 DH DES_CBC MD5
8 DH_with_DES_CBC_SHA-1 DH DES_CBC SHA-1
9 DH_with_3DES_CBC_MD5 DH 3DES_CBC MD5
10 DH_with_3DES_CBC_SHA-1 DH 3DES_CBC SHA-1
11 DH_with_AES-128_CBC_MD5 DH AES-128 MD5
12 DH_with_AES-128_CBC_SHA-1 DH AES-128 SHA-1
13 RSA_with_NULL_MD5 RSA NULL MD5
14 RSA_with_NULL_SHA-1 RSA NULL SHA-1
15 DH_with_NULL_MD5 DH NULL MD5
16 DH_with_NULL_SHA-1 DH NULL SHA-1
17 RSA_with_AES-192_CBC_MD5 RSA AES-192 MD5
18 RSA_with_AES-192_CBC_SHA-1 RSA AES-192 SHA-1
19 RSA_with_AES-256_CBC_MD5 RSA AES-256 MD5
20 RSA_with_AES-256_CBC_SHA-1 RSA AES-256 SHA-1
21 DH_with_AES-192_CBC_MD5 DH AES-192 MD5
22 DH_with_AES-192_CBC_SHA-1 DH AES-192 SHA-1
23 DH_with_AES-256_CBC_MD5 DH AES-256 MD5
24 DH_with_AES-256_CBC_SHA-1 DH AES-256 SHA-1
The hash algorithms, defined in cipher suites, are used only for the S-SCTP packet authentication, and not for the signature of the handshake messages. An S-SCTP implementation MUST at least support the default cipher suite, DH_with_3DES_CBC_SHA-1 (value=0). If the SSOpReq chunk does not contain a cipher suite parameter, then:
a.) S-SCTP will use the default, or:
b.) S-SCTP will use the old cipher suite.
The case "a" will be used at the beginning of the secure session. The case "b" will be used when the SSOpReq chunk is created after a secure session establishment. The signature schemes are derived from both the client and server certificates, and may be different.
Compression method parameter
This parameter contains compression methods, which are used for data compression. The data compression uses lossless compression methods. The user chooses several compression methods and sends it to the receiver. The receiver chooses one compression method.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Compression | Compression | Compression | Compression |
| method 1 | method 2 | method 3 | method 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .... | .... | Compression | Compression |
| | | method N-1 | method N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Compression method: 8 bits unsigned char
This field indicates a compression method, which is supported by the client. The next table includes compression methods supported in S-SCTP. Additional compression methods can be specified.
Value Compression method
----- ---------------------
1 Huffman Code
2 Lempel-Ziv Code
The secure session uses null compression when the SSOpReq chunk contains no compression parameters.
This chunk can be sent by both endpoints. The certificate helps to authenticate the endpoint, that establishes a S-SCTP session. This chunk contains only one parameter, the certificate parameter. The SSCert chunk is optional. For security reasons, both endpoints SHOULD use a certificate to authenticate each other.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0xD1 | Reserved=0 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Certificate /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Optional parameter /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length: 16 bits unsigned integer
The length field contains the size of the chunk in bytes, including the chunk header and parameter.
Certificate: Variable length
The certificate field contains the certificate of the endpoint. S-SCTP uses the X.509v3 certificate which is defined in RFC5280 [RFC5280].
Optional parameter
SSCert chunk has only one optional parameter.
Certificate parameter
The SSCert chunk uses the certificate parameter for additional certificates, when the endpoint has two or more certificates.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=33 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Certificate /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Certificate: Variable length
The endpoint can send two or more certificates. In this case the certificate field contains the endpoint's additional certificate. S-SCTP uses the X.509v3 certificate, which is defined in RFC5280 [RFC5280].
The Secure Session Open Acknowledge chunk is sent by the server to tell the client that the secure session open request is accepted.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0xD2 | Reserved=0 |CF| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Cipher suite |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Compression method | Reserved = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CF: Certificate flag: 1 bit
This flag indicates whether or not the server has a certificate. This flag is set to 1 when the server has a certificate, else it is zero.
Length: 16 bits unsigned integer
The chunk length is 8 bytes, including the chunk header, version and cipher suite field.
Version: 16 bits unsigned integer
This field indicates the S-SCTP version 1.0. The high eight bits indicate the major version, the low eight bits indicate the minor version.
Cipher suite: 16 bits unsigned integer
This field indicates the cipher suite, which is used for a secure session. The cipher suite includes necessary information for the key derivation, message encoding and MAC computation. The server uses the following rules to choose the cipher suite:
Compression method: 16 bits unsigned char
This field indicates the compression method, which is used for data compression in the secure session.
This chunk includes the parameter which is used for the key exchange algorithm. The Server Key Exchange chunk consists of the chunk header and one parameter. The parameter type depends on the key exchange algorithm.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0xD3 | Reserved=0 |SL| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Parameter /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Security level (SL): 2 bits
This 2-bit value indicates a server's security level of the reserved flags.
Length: 16 bit unsigned integer
The length field contains the size of the chunk in bytes, including the chunk header and parameter.
Parameters:
The following two parameters define the key exchange protocols. Their parameter formats are shown in the next two tables. When a user specifies a new cipher suite with a new key exchange algorithm, then they must define a new parameter.
Diffie-Hellman parameter
The SSSerKey chunk uses this parameter when the handshake is done via the DH key exchange algorithm.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0xD001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of DH prime number, P | Length of DH prmitive root, R |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of DH public key, Y | Reserved=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ DH prime number, P /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ DH primitive root, R /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ DH value, Y /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Signature /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length: 16 bit unsigned integer
The length field contains the size of the parameter in bytes, including the parameter header, length of DH prime number, length of DH primitive root, length of DH public key, reserved, DH prime number, DH primitive root, DH public key and signature.
Length of DH prime number, P: 16 bits unsigned integer
This field contains the size of the DH prime number.
Length of DH primitive root, Q: 16 bits unsigned integer
This field contains the size of the DH primitive root. The size of the prime number is equal R, where R is a random number defined in the SSOpReq chunk.
Length of DH value, Y: 16 bits unsigned integer
This field contains the size of the DH public key.
DH value, P: Variable length
This is the prime number of the DH key exchange protocol.
DH value, Q: Variable length
This is the primitive root of the prime number P.
DH value, Y: Variable length
This is the public key of the DH key exchange protocol.
Signature: Variable length
The field contains the signature which is derived from the chunk header and the whole parameter except the signature field. The signature computation uses the signature algorithm which is defined in the server certificate. If the server does not have a certificate, this field does not exist in the parameter.
RSA parameter
The SSSerKey chunk uses this parameter when the handshake uses the RSA key exchange algorithm.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0xD002 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Encrypted (random number, R) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Signature /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length: 16 bits unsigned integer
The length field contains the size of the parameter in bytes, including the parameter header, the encrypted random number and the signature.
Encrypted (Random number, R): Variable length
The random number is used to generate the secret keys for user data encryption and authentication. The random number encryption uses the client public key.
Signature: Variable length
The field contains the signature, which is derived from the chunk header and the whole parameter except the signature field. The signature computation uses the signature algorithm which is defined in the server certificate.
This chunk includes the parameters which are used for the key exchange algorithm. The Secure Session Client Key Exchange chunk consists of the chunk header and one parameter. The parameter format depends on the key exchange algorithm.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0xD4 | Reserved=0 |SL| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Parameter /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Security level (SL): 2 bits
This 2-bit value indicates a client's security level.
Length: 16 bit unsigned integer
The length field contains the size of the chunk in bytes, including the chunk header and parameter.
Parameters:
Two new parameters are defined here that can appear in the SSCliKey chunk. Their parameter formats are shown in the next two tables.
Diffie-Hellman parameter
The SSCliKey chunk uses this parameter when the handshake uses the DH key exchange algorithm.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0xD003 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ DH value, Y /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Signature /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length: 16 bit unsigned integer
The length field contains the size of the parameter in bytes, including the parameter header, the DH public key and the signature.
DH value, Y: Variable length
This field contains the public key of the DH key exchange protocol.
Signature: Variable length
The field contains a signature which is derived from the chunk header and the whole parameter except the signature field. The signature computation uses the signature algorithm defined in the client certificate. If the client does not have a certificate, then this field does not exist in the parameter.
RSA parameter
The SSCliKey chunk uses this parameter when the handshake uses RSA key exchange algorithm.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0xD003 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Encrypted (random number, R) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Signature /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length: 16 bits unsigned integer
The length field contains the size of the parameter in bytes, including the parameter header, the encrypted random number and a signature.
Encrypted (Random number): Variable length
This field contains the random number, encrypted by the server's public key, which is used to generate the master secret key for encryption and authentication.
Signature: Variable length
The field contains the signature which is derived from the chunk header and the whole parameter except the signature field. The signature computation uses the signature algorithm defined in the server certificate.
This chunk is the last chunk of the handshake and it indicates the completion of the secure session establishment. After receiving this chunk the endpoint verifies the verification data which is contained in the chunk. The secure session procedure is complete when the verification is successful. Otherwise the secure session will be closed.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0xD5 | Reserved=0 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Verification data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length: 16 bits unsigned integer
The length field contains the size of the chunk in bytes, including the chunk header and verification data.
Verification data: Variable length
The verification data contains a hashed value which is an output of the HMAC function. The HMAC uses the authentication secret key, which is individually generated by the endpoints. The HMAC input contains all received secure session handshake chunks of the current endpoint. Both endpoints compute the hash value individually and exchange it using the SSOpCom chunk. The receiver computes the hash value using the same algorithm as the sender, and compares it with the verification data. If the receiver's computed value is the same as the sender's verification data, then the receiver assures that the secure session open is successfully completed. If it is not the same, then the receiver sends an ERROR message to the sender, and immediately closes the secure session.
This chunk indicates a request to close the current secure session. The sender MUST NOT send any encrypted or authenticated chunks after it has sent this chunk.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0xD6 | Reserved=0 |OF| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Outstanding flag (OF): 1 bit
This flag indicates that the endpoint has sent the SSClose chunk and has no outstanding secured data.
Length: 16 bits unsigned integer
The length field contains the size of the chunk in bytes, including the chunk header and TSN.
Transmission sequence number (TSN): 16 bits unsigned integer
This is the transmission sequence number of the data chunk that was last encrypted and sent. The TSN helps the server to detect outstanding EncData chunks.
This chunk is used to acknowledge the receipt of the secure session close chunk. When the endpoint receives the secure session close chunk, it immediately stops sending encrypted or authenticated chunks. The Secure Session Close Acknowledge chunk only consists of the chunk header.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0xD7 | Reserved=0 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This chunk is used to convey the other associated endpoint of the endpoint's new security level. The endpoint sends SecLevCHD chunk every time it selects a new security level. The endpoint uses the new selected security level when it receives the Security Level Changed Acknowledged chunk. The sender MUST NOT send a new SecLevCHD chunk when an unacknowledged SecLevCHD chunk exists.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0xD8 | Reserved=0 |SL| Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Security level (SL): 2 bits
This 2-bit value indicates the sender's new security level.
This chunk is used to acknowledge the receipt of the SecLevCHD chunk. When the endpoint receives the SecLevCHD chunk, it immediately sends the SecLevCHD_Ack chunk.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0xD9 | Reserved=0 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Each S-SCTP packet includes at most one encrypted data chunk, and the packet could also include several (normal, unencrypted) data chunks. The encrypted data chunk may contain one or several data chunks. The EncData chunk includes a padding chunk when it is needed.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x10 | Reserved=0 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Master secret key reference # | Random number length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Random number /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Encrypted data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length: 16 bits unsigned integer
The length field contains the size of the chunk in bytes,including the chunk header and encrypted data.
Master secret key reference number: 16 bits unsigned integer
The association can be updated by changing the master secret key several times during the association lifetime. The association keeps old secret keys. The number of the kept old secret keys depends on the implementation. This field helps to identify which key (old or new) has been used for encryption. That means the endpoint is able to receive messages, which were encrypted with an old key, after the update of a master secret key.
Random number length: 16 bits unsigned integer
This field contains the size of the random number which is defined below.
Random number: Variable length
This field indicates the random number which is used as initialisation vector of the cipher block chaining (CBC) mode for encryption.
Encrypted data: Variable length
Contains a byte vector that consists of the encrypted data chunks. Before encryption, the chunk(s) MUST fulfil the following conditions. If encryption is performed using the DES or 3DES algorithm, the total size of the chunk(s) MUST be a multiple of 8 bytes. If encryption is performed using the AES algorithm, the total size of the chunk(s) MUST be a multiple of 16 bytes. If the total size of the chunk(s) is not a multiple of 8 bytes or 16 bytes, the sender MUST add appropriate padding at the chunk's end.
This padding chunk is used with an EncData chunk. The symmetric encryption algorithms use a block oriented encryption of the user data. For example DES uses 64 bit blocks, and AES uses 128 bit blocks. Before encryption, the user data which has to be encrypted has to be formatted according to the required block size. If the last block is not completely full, padding has to be added. If less than 4 bytes padding are required, the block is filled up will all zeros. The receiver can calculate the number of padding bytes based on the length field of the original data chunks. If 4 bytes or more are required, a padding chunk of appropriate length is added.
The algorithms split user data into blocks when the data length is greater than the block size. The blocks MUST be full. If 104 bits are to be encrypted using DES algorithm with 64 bit block size, user data is split into two blocks of 64 and 40 bits. The second block must be padded with 24 bits up to the full block size of 64 bits.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x12 | Reserved=0 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length: Variable length
This field indicates the padding size. The padding follows the padding chunk. The length includes the padding chunk and padding.
Padding: Variable length
The padding is a random number. The random number generation is implementation specific.
This chunk is dedicated to the authentication of an S-SCTP packet. S-SCTP inserts this chunk into the packet when the security level requires authentication.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x11 | Reserved=0 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Master secret key reference # | Reserved=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ HMAC /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length: 16 bits unsigned integer
The length field contains the size of the chunk in bytes, including the chunk header, master secret key reference, reserved field and MAC.
Master secret key reference number: 16 bits unsigned integer
The association can update the secret keys several times during the association lifetime. The association keeps old secret keys. The number of the kept old secret keys depends on the implementation. This field identifies the key which is used for authentication. If the endpoint receives a message which was authenticated by an old key, this message can still be authenticated after an update of the master secret key.
HMAC: Variable length
This field contains the authentication code for the SCTP packet. The message authentication uses the HMAC algorithm defined in RFC 2104. The hash function used in the HMAC algorithm is derived from the negotiated cipher suite, which was chosen by the server.
This part explains the new error causes defined for S-SCTP. When a secure session or certificate failure is detected in the secure session open process, the S-SCTP association immediately stops the process. However, the association continues (without any security functionality). When the secure session failure happens during an update of the master secret key the association stops the update operation and closes the secure session. The following table shows four general failure groups.
Cause Code Value Cause Code
---------------- ---------------------------------------
0x20 Secure Session failure
0x21 Secure Session Certificate failure
0x22 Secure Session Decryption failure
0x23 Secure Session Authentication failure
0x24 Secure Session Decompression failure
0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=0x20 | Cause length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Code | Reserved=0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If any error happens in the secure session open and update process, endpoints alert their peers with these error codes. The next table shows error codes for what can happen.
Error Code Value Error Code
---------------- -------------------------------------
0 Timer expired
1 Signature failure
2 Secure Session Open Complete failure
0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=0x21 | Cause length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Code | Reserved=0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The certificate failure signals that an error has occurred in processing the certificates. The next table shows error codes for what can happen.
Error Code Value Error Code
---------------- -------------------------------------
0 No certificate
1 Bad certificate
2 Certificate expired
3 Unknown certificate
This error happens when the EncData chunk cannot be decrypted or the data chunk(s) cannot be identified after decryption. The receiver discards the EncData and increases a counter by 1. This counter counts errors. If the number of errors reaches a limit, the secure session is terminated. The limit of the errors depends on the implementation.
0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=0x22 | Cause length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In the event of a HMAC error, the packet is discarded by the receiver. To check for an error, the receiver computes the HMAC and compares it to the HMAC field of the packet. If they do not match, an error is reported back.
0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=0x23 | Cause length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This error happens when the compressed chunk(s) cannot be decompressed or the data chunk(s) cannot be identified after decompression. The receiver discards the decompressed chunk(s).
0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=0x24 | Cause length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S-SCTP has four different security levels, which cover privacy settings of an S-SCTP association. The S-SCTP application can change the security levels at any time during the security session lifetime.
Both endpoints can use different security levels, e.g. the association can use security functions only for one direction, e.g. from server to client. In this case the server uses security level 3 and the client uses security level 0. The transmission control block (TCB) of the association includes the security level as a new parameter.
S-SCTP sorts data chunks before bundling them into the outgoing SCTP packet. The data chunks are sorted according to whether they have to be encrypted or not. The chunks belonging to the encryption group are concatenated and encrypted into an EncData chunk. May be a PADDING chunk is inserted into the encryption group. Insertion of a PADDING chunk is done depending on data length and encryption block size.
An assortment of encrypted and non-encrypted chunks are bundled in the packet. The control chunk(s) are placed first in the packet when bundled with other chunks. Finally, an AUTH chunk may be added to the packet.
HMAC computation is performed over all chunks and the SCTP common header with a 0 checksum. The checksum is then computed over the complete packet (including AUTH chunk). The HMAC length depends on the hash function in the cipher suite. In every security level, the SCTP packet construction is slightly different. In security level 0 the packet format is same as the SCTP packet format.
In this section an explanation of the procedures of secure session: initialisation, termination, update and etc., is given.
The following process is used to establish the S-SCTP secure session. The handshake process runs in parallel with the data transmission. The secure session start and close is controlled by the user. The user can establish and close a secure session at any time during the association lifetime. Each time a secure session is established, a new set of keys is generated. It is not possible to create a new secure session when a secure session already exists. The following describes secure session establishment, which makes use of a handshake timer and retransmissions in case packets are lost during transmission. S-SCTP uses a four-way handshake. After all messages of one of the connection "legs" have been sent, client or server starts a RTO.hand (handshake retransmission time out) timer. For example, the secure session certificate is the last handshake message of the first leg. The sender waits for a response from the receiver until the RTO.hand timer expires. The sender stops the RTO.hand timer when it receives the expected message(s). If the RTO.hand timer expires before all expected messages have been received, the sender retransmits the handshake message(s).
The retransmission uses the following algorithm. The RTO.hand timer gets a value from RTO of the path where the message is sent to, which is defined in RFC4960. Before a retransmission, the sender checks RTN.hand.max (handshake maximum retransmission number). This initial value is dependent upon specific implementations. The suggested value for RTN.hand.max is Path.Max.Retrans (see RFC 4960).
RTN.hand.max should be a constant parameter. We introduce a counter for the number of retransmissions, and if that counter exceeds the parameter RTN.hand.max, the timer expired error message is sent to the peer. If a retransmission is required then S-SCTP uses the same retransmission rules as defined in RFC4960. If the receiver receives a retransmission of a handshake message that was already received, the message last received MUST be dropped. The endpoint discards the message(s) when they are unexpected. A secure session initialisation begins when one of the associated endpoints sets the security level to a value higher than 0. The endpoint starting a secure session initialisation is called client and the other associated endpoint is called server.
When both associated endpoints request the initialisation of a secure session simultaneously (both endpoints send an SSOpReq message), both ignore the received SSOpReq message and wait a random time before resending the SSOpReq message. Each endpoint generates the random time independently. The random number must be small, e.g. 120 seconds maximum.
This section explains how to choose the cipher suite and compression method which are used for the secure session. Each endpoint maintains an ordered list of supported cipher suites (cipher suite list). The ordering in the list indicates the preference with which a cipher suite should be used (first in the list have higher preference). The order in the list is defined by the retrospective S-SCTP user.
S-SCTP users on both sides can allow all cipher suited in the list when establishing a secure session or limit the allowed cipher suites to a subset. The complete list or the selected subset can be indicated to the server in the SSOpReq. If the complete list is sent, the default cipher suite list must be located first in the list. The server uses the following rules to choose the cipher suite to be used for the secure session:
The server chooses the default cipher suite, if the SSOpReq chunk does not contain any cipher suite.
The server gets the first cipher suites from SSOpReq chunk and server's cipher suite sequence. When both cipher suites are identical the server chooses this cipher suite for the secure session. Otherwise, the server takes its first cipher suite and looks for a match in the cipher suite sequence of the client. When there is no matche, the server takes the client's first cipher suite and searches for match in its cipher suite sequence. S-SCTP checks the first cipher suite in the SSOpReq chunk against all cipher suites in the cipher suite list of the server. If no match is found, all subsequent cipher suites in the SSOpReq are checked sequentially in the order they appear in the SSOPReq until a match is found. The first cipher suite supported by both endpoints is chosen. When two cipher suites match each other then this cipher suite is selected for the secure session. If not, the server looks, its second cipher suite, for a match in the cipher suite sequence of the client. Furthermore, the server uses the same mechanism to look a cipher suite for the secure session.
The server chooses the default cipher suite, when the cipher suites in the SSOpReq chunk are not supported by the server.
Both client and server also maintain a list of compression methods. The choice of the compression mechanism works similarly to the cipher suite selection mechanism described above. S-SCTP uses a NULL compression method as default compression method.
Before transporting the packet over the network, S-SCTP takes the following steps. First, it checks the security level. If the security level is:
The termination of a secure session begins when one of the endpoints sends the secure session close chunk. This chunk includes the last encrypted data TSN and OF. The endpoint (sender) stops the encryption or authentication of all chunks or packets after it has sent the secure session close chunk. But normal (unsecured) data transfer will continue. The endpoint then waits until it receives the SSClose_Ack chunk. After receiving the SSClose_Ack chunk, the association clears the TCB parameters belonging to the secure session. The receiver (other endpoint) immediately stops encryption and authentication of all chunks or packets after it receives the secure session close chunk. Before sending the SSClose_Ack, the receiver waits for outstanding data (encrypted or authenticated data), which are the receiver's unacknowledged data chunks and sender's data chunks that have a TSN less than the last encrypted data TSN in the SSClose chunk. If the receiver does not receive the outstanding data chunks before RTO.hand timer expires, the S-SCTP association closes the secure session and outstanding data chunks will be dropped. The receiver ignores the last TSN of SSClose chunk and waits only for the receiver's unacknowledged data chunks when SSClose chunk's OF=1. The SSClose and SSClose_Ack chunks may be bundled with other chunks. If the sender does not receive the acknowledge chunk, the client follows the standard retransmission rule for messages. After the termination of the secure session, the TCB parameters belonging to the secure session MUST be set to zero. If the SCTP association begins to close the current association, the SSClose chunk is sent. If the SCTP association creates an ABORT chunk, the secure session closes immediately and the TCB parameters belonging to the secure session MUST be set to zero.
Secret key generation uses the 3DES_CBC algorithm. Both server and client compute the master secret key separately. The key material is split into 64 bit blocks. Every block will be input to the 3DES_CBC encryption. The key material is as follows:
A secure update mechanism of the secret keys is a very important requirement for a secure session. The secret keys consist of the master secret key, which is used for data chunk encryption, and the HMAC secret key, which is used for packet authentication. If an association exists for a long time, the S-SCTP association needs to update the secret keys. Both the client and the server can request an update of the secret keys. A three way handshake, called an abbreviated handshake, is used to update the master secret keys. All actions of the handshake are encrypted by the current master secret key. The current security level does not affect the packets, which contain the handshake messages. The key update handshake works similar to the first establishment handshake (e.g. the endpoints start an RTO.hand timer when sending handshake chunks). Format and function of the chunks used to update keys are the same as for the handshake. When an endpoint receives a SSOpReq chunk (after a secure session establishment) it begins to update secret keys. Both the server and client key exchange chunks always use the RSA key exchange algorithm. The random numbers in SSSerKey and SSCliKey chunks are encrypted by the current master secret key. The following describes the method used to update the master secret key:
The client generates a random number and sends the SSopReq chunk with the SSCliKey chunk. The key material length in the handshake request chunk may be equal to 0. If not, the number indicates the size of the new key material. If 0, both sides will use the key material length which was used in the last handshake. The server sends the SSop_Ack, the SSSerKey and the SSOpCom chunks immediately after receiving the SSOpReq and the SSCliKey chunks. After receiving the handshake messages from the server, the client computes a new master secret key and checks the SSOpCom chunk of the server. If it detects any error, the client closes the secure session and reports an error to the peer. The client computes the SSOpCom chunk and sends it to the server. After sending the SSOpCom chunk the client is ready to use the new master secret key. The server receives the SSOpCom chunk of the client and checks the new keys. If it detects any error, the server closes the secure session and reports an error to the peer. Before receiving the client's SSOpCom chunk, the server discards any encrypted or authenticated chunk that make use of the new master secret key.
The encrypted and unencrypted user data transmission works in parallel with the update operation. After the update operation, the new master secret key is used for data encryption and authentication. When both client and server receive an SSOpReq chunk simultaneously, the client ignores the server's SSopReq chunk and the server accepts the client's SSOpReq chunk. The next steps are the same as for the secure session initialisation.
The new master secret key generation uses the same algorithm as described above. The secure session includes one parameter which is called secure session lifetime. This parameter is used to initialise a timer which indicates the secure session secret key's lifetime in seconds. When the timer expires, the association automatically updates the secret keys. The user can define this parameter. If the user does not define it, the parameter assumes a default value. This default value depends on the implementation. The implementation MUST define secure session's lifetime initial value. We suggest a value of 600 seconds for the lifetime as a compromise between security and overhead.
As the security of S-SCTP depends on the quality of the random number generator, we suggest to use one according to RFC4086 [RFC4086].
S-SCTP uses the HMAC algorithm which is defined in RFC2104 [RFC2104] for the packet authentication.
ULP-to-SCTP primitives deliver upper layer requests to S-SCTP. The following part describes new ULP-to-SCTP primitives and thus enhances the section 10 of RFC4960. All new ULP-to-SCTP primitives described below are defined in the ssctp.h header file.
INITSECSESS: This primitive initialises a new secure session.
Format: {initSecSess(secure session ID, key material length, cipher suites list, compression methods list, certiticate(s) ) --> result}
SETSECLEVEL: This primitive sets a new security level for an existing secure session.
Format: {setSecLevel(secure session ID, security level) --> result}
GETSECLEVEL: This primitive gets the current security level of a secure session.
Format: {getSecLevel(secure session ID) --> security level}
SENDSEC: This primitive sends secure data via S-SCTP.
Format: {sctp_send_enc(association id, buffer address, byte count, context, stream id, life time, destination transport address, unorder flag, no-bundle flag, payload protocol-id, encryption flag, compression flag) --> result}
Every parameter, except the encryption and compression flags, defined in this function is the same as the corresponding parameter defined in the SEND function of RFC4960 section 10.
GETSECSTATUS: This primitive gets the security status of an association. The security status indicates if the SCTP association is using a secure session or not.
Format: {setSecStatus(association ID) --> status}
SETSECSESSTTL: This primitive sets a new lifetime for a secure session.
Format: {setSecSessTTL(secure session ID, Time) --> result}
SHUTSECSESS: This primitive deletes a secure session.
Format: {shutSecSess(secure session ID) --> result}
S-SCTP defines new notifications to deliver information to the upper layer. The notifications extend the section 10.2 of RFC4960 [RFC4960]. All new notifications are defined in the ssctp.h header file.
SECSESSUP:
This notification indicates that S-SCTP is ready to send or receive secure data ({secsessUpNotif()}).
SECSESSDOWN:
This notification indicates that an association has lost a secure session ({secsessdownNotif()}).
SECSESSREKEY:
This notification indicates that a secure session updated the secret keys ({secsessrekeyNotif()}).
Additional changes had to be made in the socket API implementation to access the new sctplib functions described above. A user calls the same socket API functions as in standard SCTP to send and receive user data, but has to set an additional encryption flag (MSG_ENC) to request encryption of user data. Also, a compression flag (MSG_COMP) has to be set in ext_send, ext_sendto, ext_sendmsg to request compression of user data. S-SCTP compression performs per user message not per chunk or per packet. In the SCTP DATA chunk, a new flag is defined, which indicates if the data is compressed or not. On the receiver side there are no changes.
A SCTP TCB contains parameters which are related to an association (e.g. an association id, port number, IP address list...). S-SCTP defines several parameters which are related to a secure session and it extends the TCB defined in section 12 of RFC4960.
Security level:
This parameter contains the association's current security level.
Second security level:
This is the security level of the associated second endpoint.
Key material length:
The size of the key material, which was last used for key generation.
Secure session status:
This parameter indicates whether the association is using a secure session or not.
Secure session lifetime:
This parameter indicates the lifetime of the secret keys of a secure session.
Server indication:
This parameter indicates if an endpoint is server or client. If the parameter is equal to 1 then it is a server, otherwise it is a client.
Secure session ID:
This parameter indicates the local secure session ID.
Master secret key reference:
This is an "array of secret data" collection and every array element includes the following parameters.
This information is used in EncData and AUTH chunks.
S-SCTP defines new socket options for the ext_setsockopt() and ext_getsockopt() socket functions to initialise, delete and rekey a secure session. A user calls the ext_setsockopt or ext_getsockopt functions with a new option. It is not necessary to define new socket API functions, as this is a more standard socket API fashion. The following paragraphs describe the new socket options.
SSCTP-INIT:
This socket option is used to initialise or update a secure session. The following structure is used to access these parameters.
struct ssctp_init {
uint16_t secsessID;
uint16_t key_length;
uint8_t num_cipher;
uint8_t *cipher_suites;
uint8_t num_comp;
uint8_t *comp_methods;
uint8_t *certificate;
};
SSCTP-SECLEVEL:
This socket option is used to set and get a secure session security level. The following structure is used to access and modify these parameters.
struct ssctp_seclevel {
uint16_t secsessID;
uint8_t seclevel;
};
SSCTP-SECSTATUS:
This socket option is used to get the secure session status and secure session ID when a secure session exists. The following structure is used to access these parameters.
struct ssctp_secstatus {
uint16_t secsessID;
uint8_t sec_status;
};
SSCTP-SECSESSTTL:
This socket option is used to set and get the secure session lifetime. The following structure is used to access and modify these parameters.
struct ssctp_secsessTTL {
uint16_t secsessID;
uint16_t secsessTTL;
};
SSCTP-CLOSE:
This socket option is used to close an existing secure session. The following structure is used to access these parameters.
struct ssctp_secclose {
uint16_t secsessID;
};
Security has been described in the previous sections.
This document introduces no additional considerations for IANA.
| [RFC2104] | Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC3436] | Jungmaier, A., Rescorla, E. and M. Tuexen, "Transport Layer Security over Stream Control Transmission Protocol", RFC 3436, December 2002. |
| [RFC3554] | Bellovin, S., Ioannidis, J., Keromytis, A. and R. Stewart, "On the Use of Stream Control Transmission Protocol (SCTP) with IPsec", RFC 3554, July 2003. |
| [RFC4086] | Eastlake, D., Schiller, J. and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. |
| [RFC4960] | Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007. |
| [RFC5280] | Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R. and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. |