# On the Need for a General REST-Security Framework
## 7 Implementation of REST Message Authentication
### REST-Full CoAP Message Authentication (RECMA)  
This section introduces the REST-ful CoAP instantiation of REMA denoted as REST-ful CoAP Message Authentication (RECMA). The following table shows the adoption of the REST-ful message signature algorithm defined in Section 6.2.2 for CoAP. It contains two templates, each constructing a byte concatenation (symbolized by \(\parallel\)) of a sequence of all security-relevant message elements including a time-variant parameter (\(tvp\)). The resulting concatenation is transformed into a byte array that is the \(tbs\) variable for CoAP. The implementation considers signing request and response messages as well as acknowledgment (\(T=0\,\times\,02\)) and reset (\(T=0\,\times\,03\)) messages. The template contained in the left column describes the construction rules of \(tbs\) for requests as well as responses and the template contained in the right column defines the construction of \(tbs\) for reset and acknowledgment messages. Assume that the following two example messages require to be authenticated. The message on the right is a POST request represented by the code value \(0\,\times\,02\) (\(C=0\,\times\,02\)), which requires a confirmation by the server, whether the message has successfully been received. Confirmable messages are denoted by the message type value \(0\,\times\,00\) (\(T=0\,\times\,00\)). Moreover, the example request contains the protocol version number \(0\,\times\,01\) (\(V=0\,\times\,01\)), the message identifier \(0\,\times\,01\) (\(MID=0\,\times\,01\)) and the token value \(0\,\times\,0A\) that has a length of one byte (\(TKL=0\,\times\,01\)). The left example message is an acknowledgement message for the POST request specified on the left. It confirms the reception (\(T=0\,\times\,02\)) of a request identified by \(MID=0\,\times\,01\). The delimiter to separate the header form the body in all CoAP messages is \(0\,\times\,FF\). ```
ExampleCoAPrequestmessage V=0x01,T=0x00,TKL=0x01,C=0x02,MID=0x01 V=0x01,T=0x02,TKL=0x00,C=0x00,MID=0x01 Token:0x0A Uri-path:0x6974656073#items Content-format:0x32 Payload-length:0 xF (\"item\";\"Work\")
```  
According to the previous table and the requirements defined by [PERSON] [31] and [PERSON] [70], the \(tbs\) for both messages are constructed as follows:The concatenation order of the CoAP start header items and the token follows the order of the predefined positions stated in the CoAP specification. The CoAP options are added in numerical order of the option numbers. Once the construction of \(tbs\) for the two messages is finished, it is signed with the signature key \(k\). \[sv=sign(k,tbs)\]  
The last step incorporates the resulting signature value \(sv\) and the corresponding signature meta-data to newly introduced CoAP options, which are signature-value, signature-algorithm, hash-algorithm, TVP and a key-ID. ```
1 SignedCoAP request message
``` V=0x01,T=0x00,RTL=0x01,C=0x02,MID=0x01 Token =0x0A ```
Signature-algorithm: 0x01 Uri-path: \"items\"
``` Hash-algorithm: @x01 Content-format: 0x32 VTP: @x1d14486n57 Payload-length: @x0P Signature-value: <<x> Signature-algorithm: @x01 Hash-algorithm: @x01 VMF V=0x1d14486n51 Signature-value: <x> Signature-value: <x> Key-ID: <xid> OxFF ```  
Both messages use numbers to declare the signature and hash algorithm name. Here, the number 0 \(\times\) 01 within the signature-algorithm option represents an HMAC-SHA256 signature and the same number defines a SHA256 hash for the hash-algorithm option. A description on the additional and application-specific header entries is not present in both messages, since an acknowledgment must not contain further options besides the options for the signature description and the request does not intend to include additional header entries. As the CoAP standard does not define a meta-data element for defining the length of the body, RECMA uses the payload-length option to declare the size of the body [71].