Re: [jose] JOSE and signed REST requests

Hoai Viet Nguyen <nguyen@hoaiviet.de> Tue, 02 August 2016 16:16 UTC

Return-Path: <nguyen@hoaiviet.de>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6BF12D7CA for <jose@ietfa.amsl.com>; Tue, 2 Aug 2016 09:16:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.052
X-Spam-Level:
X-Spam-Status: No, score=0.052 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_DYNAMIC_IPADDR=1.951, HTML_MESSAGE=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXiCntmwlxDd for <jose@ietfa.amsl.com>; Tue, 2 Aug 2016 09:16:11 -0700 (PDT)
Received: from lvps83-169-36-247.dedicated.hosteurope.de (lvps83-169-36-247.dedicated.hosteurope.de [83.169.36.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBA9712D79E for <jose@ietf.org>; Tue, 2 Aug 2016 09:16:09 -0700 (PDT)
Received: (qmail 1480 invoked from network); 2 Aug 2016 18:16:07 +0200
Received: from loiacono2.fo.fh-koeln.de (HELO Viet-MacBook-Air-3.local) (139.6.100.125) by lvps83-169-36-247.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 2 Aug 2016 18:16:07 +0200
From: Hoai Viet Nguyen <nguyen@hoaiviet.de>
To: jose@ietf.org
References: <216bb90e-15d5-efd6-e014-024f06af24f2@gmail.com> <48681c51-a1f2-ff43-9af4-521248b29af3@mit.edu> <CABkgnnWOBJoFZYBW+n3uxd99F+JtyeT7i9eELCaEgQv==D1G+Q@mail.gmail.com> <bdd1c021-e7cd-f96d-e117-cce3a3052cc8@mit.edu>
Message-ID: <05833c0e-0ffa-39ae-250d-76a383998e53@hoaiviet.de>
Date: Tue, 2 Aug 2016 18:16:00 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <bdd1c021-e7cd-f96d-e117-cce3a3052cc8@mit.edu>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="DuFnnhLlArVjVHSEFnH7aFv7EQvXqk9xW"
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/pi9xv9174mLgavtNU3Kii0qpFwM>
Subject: Re: [jose] JOSE and signed REST requests
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jose/>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Aug 2016 16:23:05 -0000

Hi all,

we have developed an authentication scheme which address this topic. Our
scheme is a generic security approach for REST that relies on the same
abstraction level as the architectural style itself. The developed
authentication contains a general notation for describing REST message
elements including header fields and the payload. We used this abstract
notation to specify a policy defining security-relevant header fields
which require to be signed and verified by a corresponding signature and
verification algorithm. Both algorithms are also proposed by our work.
These generic authentication scheme containing the policy and the two
algorithms forms a guideline for implementing message authentication
technologies for REST-based protocols of any kind such as HTTP or CoAP.

Our work has been published in two papers. The first paper includes the
generic authentication scheme and the HTTP implementation. 
https://doi.org/10.1007/978-3-319-19210-9_8

The second paper contains the CoAP implementation of our authentication
scheme. This paper has been presented at the International Workshop on
Secure Internet of Things (SIOT) which has been held in conjunction with
the ESORICS 2015.
https://dx.doi.org/10.1109/SIOT.2015.8

In further works, we will also focus on concepts enabling intermediate
systems to interacting with signed REST messages. This includes the
consideration of changing header fields in transit, a problem which has
been addressed by Martin Thomson.

Regards and looking forward for your feedback,
Viet






Am 02.08.16 um 13:17 schrieb Justin Richer:
> Those limitations are exactly what drove the work in this direction. I
> completely agree that it's always going to be a trade off, and we went
> in the direction of not having a universal solution but instead having
> a limited solution that would work for many (but not all) use cases.
> I've yet to see a universal solution that doesn't break under simple
> counter-examples.
>
> The fact that you can have unsigned elements that could be critical to
> your application is one such limitation. In those cases, you need to
> make sure that not only do the signature and hash validate, but also
> that the elements you care about were protected by it. That doesn't
> mean you can't pass on other parameters to other layers, but it does
> mean that you can't guarantee they were left alone in transit. This is
> an important note in the security considerations section, along with
> parameter ordering.
>
> Side note about the percent encoding, is the spec not clear enough
> about that as input for the hash calculation? Happy to take suggested
> text.
>
>  -- Justin
>
>
> On 8/2/2016 7:10 AM, Martin Thomson wrote:
>> Clearly this is a windmill that many like to tilt at.  After seeing
>> the long procession of failed attempts, my conclusion was that signing
>> HTTP messages in a generic fashion was an enterprise doomed to fail.
>>
>> The main problem is that it's really hard to work out what to protect.
>> Header fields are especially difficult to protect because they lack a
>> stable encoding and they change in transit.  The first means that even
>> the most careful spec ends up with spurious signature failures; the
>> second means that things that should be protected, can't be.  In the
>> end, you get something with byzantine complexity, an overly
>> restrictive applicability, security failures, or combinations of all
>> three.
>>
>> Taking the OAuth work and the "q" parameter:
>>   - the method for creating a canonical encoding of the query string is
>> quite complex,
>>   - but it's not complex enough yet because it doesn't handle
>> percent-encoding;
>>   - also, if the "q" parameter is omitted, but the query string happens
>> to be security critical you get failures.
>>
>> Clearly the more limited focus helps here, but the point is that you
>> have to accept those limitations, which is a whole new set of problems
>> for an implementation.  Say you successfully validate a request, that
>> means that you cannot pass anything that was unvalidated to the next
>> processing stage or you create a side-channel.  And are you sure that
>> there isn't some significance to the information you erased during the
>> validation process that might then be used by the next stage?
>>
>>
>> On 2 August 2016 at 20:43, Justin Richer <jricher@mit.edu> wrote:
>>> There's also this approach:
>>>
>>> https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-02
>>>
>>> It's more limited than a general HTTP signing mechanism, but as a
>>> consequence it's more robust for systems that mess with the HTTP
>>> message in
>>> transit (which we know happens in the real world).
>>>
>>>   -- Justin
>>>
>>>
>>>
>>> On 8/2/2016 1:32 AM, Anders Rundgren wrote:
>>>> Hi All,
>>>>
>>>> I was recently involved in an inter-bank payment project based on a
>>>> REST
>>>> API.
>>>>
>>>> Since my role was "cryptography" I recommended the following approach
>>>>
>>>> http://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-authenticating-requests.html
>>>>
>>>> since an operation is defined not only by the message payload, but
>>>> also by
>>>> the HTTP verb, URI, and header parameters.
>>>>
>>>> The only related standards effort I'm aware of is this:
>>>> https://tools.ietf.org/html/draft-cavage-http-signatures-05
>>>>
>>>> Unfortunately the methods above get rather awkward if you have a
>>>> system
>>>> where requests are supposed to be embedded in other messages or
>>>> just proxied
>>>> to another server.
>>>>
>>>> I would rather have dropped REST in favor of transport-independent
>>>> schemes
>>>> using self-contained JSON-encoded signed message objects.
>>>>
>>>> WDYT?
>>>>
>>>> Anders
>>>>
>>>> _______________________________________________
>>>> jose mailing list
>>>> jose@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/jose
>>>
>>> _______________________________________________
>>> jose mailing list
>>> jose@ietf.org
>>> https://www.ietf.org/mailman/listinfo/jose
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose