|
|
All the built-in features for your own safety... :)
MPTCP uses a mechanism based on asymmetric cryptography and certificates in the X.509 standard.
The specs don't describe how certificates are signed, distributed and revoked, so an external PKI becomes required.
We assume that every node in the system has the following elements:
- a pair of private and public key, generated with a chosen algorithm
and key length. We will call them {PRIVc, PUBc} for the Client,
{PRIVmp, PUBmp} for the MP and {PRIVs, PUBs} for the Server.
- a X.509 certificate by which a commonly trusted Certification
Authority (CA) signs the public key of the node. We will call them
CRTc for the Client, CRTmp for the MP and CRTs for the Server.
- the self-signed certificate of the CA.
MPTCP uses the CRT for both authentication and authorization, since no account names nor password are defined.
Every single MPTCP operation has a "security level" specified by the variable SeLvL contained
in the head_crypt subheader. The user can decide how strict the security checks should be by modifying its value.
A SeLvL of zero means that cryptography is completely disabled. Higher levels provide complete mutual authentication between nodes.
In the following paragraphs the steps performed for Direct and Reverse requests are described.
Direct Requests
1. The Client sends a SDR/MDR packet to the MP attaching CRTc by
using a mptcp_auth header. Optionally for SeLvL >= 2, MP
sends back CRTmp to C to ensure mutual authentication.
2. MP sends a SDR/MDR request to the Server attaching CRTc. For
SeLvL >= 3, MP attaches also CRTmp and receives CRTs from
the Server.
3. The Server sends to MP the data encrypted with the public key of the
Client.
4. The Client requests data from the MP sending CRTc and, for
SeLvL >= 2, requesting CRTmp.
We define the following security levels:
SeLvL | Description
----------------+-------------------------------------------------
0x0 | No authentication at all. Cryptography disabled.
0x1 | Client sends CRTc to the MP.
0x2 | As above, plus MP sends CRTmp to the Client.
0x3 | As above, plus MP sends CRTmp to the Server and
| receives CRTs from the Server.
Reverse Requests
1. The Client sends a SRR/MRR packet to the Server attaching CRTc by
using a mptcp_auth header. Client and Server exchange then the
pre-secrets keys in order to create a session key.
At this point, the Client and the Server are mutually identified and they share the knowledge of a secret key.
2. The Server sends to the MP: its own certificate CRTs and data
encrypted using the shared key (that MP ignores). Optionally, for
SeLvL >= 3, MP sends back CRTmp to S to ensure to be
trustworthy.
3. The Client gets the data from the MP by using its own CRTc as
identifier. Optionally, for the SeLvL 4, MP sends its own
CRT to C.
We define the following security levels:
SeLvL | Description
----------------+-------------------------------------------------
0x0 | No authentication at all. Cryptography disabled.
0x1 | Client sends CRTc to the Server.
0x2 | As above, plus Server sends CRTs to the Client.
0x3 | As above, plus MP sends CRTmp to the Server.
0x4 | As above, plus MP sends CRTmp to the Client.
By using these security measures we can avoid the following attack patterns:
- A malicious node could "spoof" the IP Address and take the place of
the actual MP to direct towards itself the traffic coming from the
Server. This attack is not feasible because:
- the malicious node cannot read the data since it was encrypted
with a session key known only to the Server and the Client.
- with SeLvL >= 3, MP must send CRTmp to the Server.
- Even if an eavesdropper would capture all the data send in the three
steps above, it would be impossible for it to find the session key.
- In case the Server or the MP or both would become compromised, MPTCP
ensures "perfect forward secrecy" of the data stored on the MP's
disk, since they are encrypted with different and unknown session
keys.
|
