On 2016-08-02 18:16, Hoai Viet Nguyen wrote:
Hi Viet,
It is quite possible that I didn't follow the links properly but I actually
ended up having to purchase the papers :-(
I was recently advised to buy an X.9 standard which is supposed to cover the
security solutions required by the US financial industry. Sounds pretty
interesting, right?
However, I did not. Not because a few hundred bucks represents a "budgetary
problem", but due to the fact that paid for standards are difficult to handle
(without violating the copyright) in a world powered by open source.
Regards
Anders
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 <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
