# On the Need for a General REST-Security Framework
## 8 Evaluation and Discussion  
The proposed REST message authentication scheme and the requirements defined for implementing REST message confidentiality are the first steps towards a general REST-security framework. The REMA-policy defines mandatory message elements for requests and responses, which need to be available in order to render a message self-descriptive. As these message entitiesare mandatory, they are also security-critical. Hence message elements defined in the REMA-policy must be signed in order to be protected against malicious modifications. REHMA [28] as well as RECMA [31] apply the REMA-policy as a security-baseline for identifying corresponding mandatory and security-critical HTTP and CoAP message elements respectively. Moreover, the policy on the to be signed message elements in REHMA and RECMA are extended by protocol-specific mandatory header entries which are required for the self-descriptiveness of HTTP and CoAP messages.  
The concrete adoption of the REST message authentication scheme in HTTP and CoAP are therefore not vulnerable to the attacks defined in Table 1 as well as the threats detected by the related work analysis, since all essential and security-critical message elements are signed (see Table 4). Note that the to be signed message elements defined in REMA, REHMA and RECMA protect against attacks which are generally-valid for all REST-based applications implemented with HTTP, CoAP other REST-based protocols. If another REST-based protocol or a distinct application domain utilize additional security-critical header entries, these elements must be added either to the policy of the concrete adoption or to the list of application-specific header entries included in _desc_ in order to thwart protocol- or application-specific man-in-the-middle attacks.  
Table 4 illustrates the message elements signed by REHMA and RECMA. As the REMA-Policy as well as the corresponding adoptions in REHMA and RECMA cover all the to be signed header in order to avoid the documented vulnerabilities (see Section 4, Tables 2 and 3), it can also be utilized as an analytical framework for the evaluation and enhancement of related work in HTTP/CoAP signature schemes. For instance, REHMA may serve as a guideline for adding the missing to be signed message elements of the HTTP signature schemes required by the cloud storage services of Amazon [49], Microsoft [48], Google [46] and HP [47]. The signature schemes of these cloud storage providers will benefit from the security specification of REHMA, as it will increase the level of security. This is especially important as many companies use the cloud storage services of Amazon, Microsoft, Google and HP in production.  
This paper shows that a general REST-security scheme builds the basis for generally-valid policies and requirements. By means of this common foundation, REST-ful security technologies can be implemented based on the same security-baseline. This methodology has been conducted for the REST message authentication. The implementation of REMA in HTTP and CoAP shows an increasement of the level of security, as the documented vulnerabilities can be avoided. Other or future REST-based protocols such as RACS [11] can use the same methodology for defining security schemes. An adoption of REHMA in RACS is proposed in [70]. The reader is henceforth referred to this paper for further details.