48 communication layer specification improvements

website/docs/communication-layer/discovery-pairing-authentication.md

@@ -101,7 +101,7 @@ This is used to denote the endpoint of both the REST API client and the WebSocke
 
 A person or entity that manages S2 nodes. For the purpose of this specification it is assumed that there is already a trust relationship in place between this person and the S2 nodes. The means that the way the trust relationship has been established is out of scope for this specification.
 
-# Mapping the CEM and RM to S2 Server and Client Nodes
+## Mapping CEM and RM to S2 Server and Client Nodes
 
 The CEM and RM roles defined by the S2 protocol are distinct from the Server and Client roles of the S2 pairing process. The following rules apply to determine whether the RM or CEM acts as a Client or Server in the pairing process.
 
@@ -144,7 +144,7 @@ A LAN scenario where both RM and CEM are running on the same local network. Disc
 
 ## The pairing process
 
-The pairing process is based on the trust relation that the end user has with both the CEM and the RM. That trust relation is out of scope for this specification and is up to CEM and RM providers to implement. Given the deployment scenario, it [follows](# Mapping the CEM and RM to S2 Server and Client Nodes) which of the RM and the CEM is server and which is the client in the pairing process.
+The pairing process is based on the trust relation that the end user has with both the CEM and the RM. That trust relation is out of scope for this specification and is up to CEM and RM providers to implement. Given the deployment scenario, it [follows](#mapping-cem-and-rm-to-s2-server-and-client-nodes) which of the RM and the CEM is server and which is the client in the pairing process.
 
 The pairing process can either be initiated from the client or from the server.
 

website/docs/communication-layer/security-considerations.md

@@ -160,7 +160,7 @@ SelfSignedCA --> LocalServerCertificate
 </details>
 
 
-### Trusting aself signed root certificate
+### Trusting a self-signed root certificate
 
 The self signed root certificate is by default not trusted. However during the pairing phase, the server with the self signed root certificate will share part of the root's certificate fingerprint as part of the pairing token, via a second channel. This will enable the client to verify the self signed root certificate, and create trust. From this moment on, the client will store the complete fingerprint of the self signed root certificate, and use it to verify the server certificate for all future connections.
 
@@ -172,6 +172,9 @@ A server can update its certificate. When a cloud server updates it's certificat
 
 If the server is in local-local mode, and uses a self-signed CA certificate, the CA certificate **SHOULD** be created with a validity period which is long enough for the expected lifetime of the server. If the used crypto for the the CA certificate is broken, or the lifetime of the server is longer than the validity of the certificate, the server **MUST** create a new self-signed CA certificate and all clients need to be paired again. Like cloud servers, a local server **SHOULD** update its server certificate at least once every 6 months.
 
+## Brute-force protection
+To prevent brute-force pairing request, the server MUST implement rate limiting on the requestPairing endpoint. It is up to the server implementation to define the type of rate limiting.
+
 ## How are the requirements met?
 
 In the follow section, reasoning for each security requirement will be given.