Authentication Scheme for REST

Iacono, Luigi Lo; Nguyen, Hoai Viet

doi:10.1007/978-3-319-19210-9_8

Cited by 10 publications

(8 citation statements)

References 13 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…There are existing solutions providing additional authentication for REST-ful HTTP as studied and extended by Lo Iacono et al [28]. However, these solutions include different HTTP headers, would have to be extended for future headers and provide authentication only.…”

Section: B Existing and Strawman Tls Solutionsmentioning

confidence: 99%

TLS-N: Non-repudiation over TLS Enabling Ubiquitous Content Signing

Ritzdorf

Wüst

Gervais

et al. 2018

Proceedings 2018 Network and Distributed System Security Symposium

View full text Add to dashboard Cite

Abstract-An internet user wanting to share observed content is typically restricted to primitive techniques such as screenshots, web caches or share button-like solutions. These acclaimed proofs, however, are either trivial to falsify or require trust in centralized entities (e.g., search engine caches). This motivates the need for a seamless and standardized internet-wide non-repudiation mechanism, allowing users to share data from news sources, social websites or financial data feeds in a provably secure manner.Additionally, blockchain oracles that enable data-rich smart contracts typically rely on a trusted third party (e.g., TLSNotary or Intel SGX). A decentralized method to transfer webbased content into a permissionless blockchain without additional trusted third party would allow for smart contract applications to flourish.In this work, we present TLS-N, the first TLS extension that provides secure non-repudiation and solves both of the mentioned challenges. TLS-N generates non-interactive proofs about the content of a TLS session that can be efficiently verified by third parties and blockchain based smart contracts. As such, TLS-N increases the accountability for content provided on the web and enables a practical and decentralized blockchain oracle for web content. TLS-N is compatible with TLS 1.3 and adds a minor overhead to a typical TLS session. When a proof is generated, parts of the TLS session (e.g., passwords, cookies) can be hidden for privacy reasons, while the remaining content can be verified.

show abstract

Section: B Existing and Strawman Tls Solutionsmentioning

confidence: 99%

TLS-N: Non-repudiation over TLS Enabling Ubiquitous Content Signing

Ritzdorf

Wüst

Gervais

et al. 2018

Proceedings 2018 Network and Distributed System Security Symposium

View full text Add to dashboard Cite

show abstract

“…Even the fundamental message security layer is not available completely (visualized by the dashed area) [13,28]. Some standards related to the authorization of service invocations such as OAuth [29] and drafts on identity federation [30] are at hand, but the rest of the higher order security concepts including trust, secure conversation and so forth are lacking entirely.…”

Section: Rest-ful Services Security Stackmentioning

confidence: 99%

“…Moreover, most of the available work has been conducted in relation to basic service message security with a focus on authentication and authorization. Thus, the subsequent analyzes are driven by these prerequisites [28].…”

Section: Related Work Analysismentioning

confidence: 99%

“…Such security specifications must be defined on the same abstraction layer as REST itself, so that they can be applied to any concrete protocol instantiation in a methodical manner (see Figure 8). To do so, a formal description of REST messages and an identification of security relevant parts in such messages need to be at hand [28].…”

Section: Towards a General Rest-security Frameworkmentioning

confidence: 99%

“…Each error will cancel the signature generation process with an according error message. Algorithm 1 Representational state transfer (REST) message signature generation [28].…”

Section: Rest Message Signature Generationmentioning

confidence: 99%

See 2 more Smart Citations

On the Need for a General REST-Security Framework

2019

Self Cite

View full text Add to dashboard Cite

Contemporary software is inherently distributed. The principles guiding the design of such software have been mainly manifested by the service-oriented architecture (SOA) concept. In a SOA, applications are orchestrated by software services generally operated by distinct entities. Due to the latter fact, service security has been of importance in such systems ever since. A dominant protocol for implementing SOA-based systems is SOAP, which comes with a well-elaborated security framework. As an alternative to SOAP, the architectural style representational state transfer (REST) is gaining traction as a simple, lightweight and flexible guideline for designing distributed service systems that scale at large. This paper starts by introducing the basic constraints representing REST. Based on these foundations, the focus is afterwards drawn on the security needs of REST-based service systems. The limitations of transport-oriented protection means are emphasized and the demand for specific message-oriented safeguards is assessed. The paper then reviews the current activities in respect to REST-security and finds that the available schemes are mostly HTTP-centered and very heterogeneous. More importantly, all of the analyzed schemes contain vulnerabilities. The paper contributes a methodology on how to establish REST-security as a general security framework for protecting REST-based service systems of any kind by consistent and comprehensive protection means. First adoptions of the introduced approach are presented in relation to REST message authentication with instantiations for REST-ful HTTP (web/cloud services) and REST-ful constraint application protocol (CoAP) (internet of things (IoT) services).

show abstract