imply doing a HMAC over the URL
nonce and time since the consequence of a MITM attack is relatively
unimportant.
-Peter
On Mon, Apr 11, 2011 at 7:21 PM, Eran Hammer-Lahav wrote:
>
>
>> -Original Message-----
>> From: Peter Wolanin [mailto:peter.wola...@acquia.com]
>> Se
I think it's perfectly reasonably - if inside the service you need to
rewrite the URI, it's not hard to preserve the original as an extra
header or ENV.
We have a HMAC-sha1 implementation in production where the load
balancer (nginx) may rewrite the URI before passing it to a java app
that authent
What about using the cookie header?
We have a sha1-HMAC authentication scheme where we are passing the
HMAC, nonce, timestamp as parts of the cookie header since scripting
languages that cannot access arbitrary headers still usually can
access this header.
-Peter
On Mon, May 9, 2011 at 3:34 PM,
function hash_file('sha256', $filename) ), so I could
then construct all the headers and stream the file to the server.
-Peter
On Wed, May 18, 2011 at 12:38 PM, Eran Hammer-Lahav wrote:
>
>
> > -Original Message-
> > From: Peter Wolanin [mailto:peter.
I am also concerned by the fragility of using
time-since-credentials-issued, and also the added complexity of
specifying this construction.
I think it would be preferable to always require a timestamp as part
of the authorization header, and maybe even include in the spec a
maximum time difference
As long as a specific service can make an ext containing the body hash
required, I think this is fine. Can the spec include body hash as an
example of an ext?
Thanks,
Peter
On Sat, Nov 19, 2011 at 10:39 AM, Eran Hammer-Lahav wrote:
> I want to reaffirm our previous consensus to drop the body-h
No objection from me, but it's too bad the browser vendors aren't interested.
-Peter
On Sat, Nov 19, 2011 at 10:33 AM, Eran Hammer-Lahav wrote:
> I would like to drop the cookies support defined in the MAC document due to
> lack of interest from the browser vendors. At this point it is most like
tting it in the ext field,
any client could include the hash even if the server doesn't require
it?
Best,
Peter
On Thu, Nov 24, 2011 at 12:21 AM, Eran Hammer-Lahav wrote:
> In prose, sure. But I'd rather not go further than that.
>
> EHL
>
>> -Original M
Dear Eran,
I'm still hoping you will consider adding back the MAC spec a
requirement for a body hash covered by the MAC. I still also feel
that the lack of a hash covered by the MAC that protects the value of
the response and response body makes this proposed spec quite a bit
weaker than it shoul
Looking at this document, I don't see much discussion of the risk due
to a tampered response except possibly 5.1.2. For example, injection
of spam or phishing links into search results.
Given the known issues with CA issuers, and the fact that some
transactions may be carried out over non-SSL cha
Dear Mr. Hammer-Lahav
regarding http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-02
I was quite happy to find this, since I had overlooked it before and
it define the sort of robust HMAC-based auth we have been using for
our APIs in various forms, but has the advantage of being a standa
ould not use an HMAC based
signature instead of sending the secret.
Best,
-Peter Wolanin
On Sun, Feb 27, 2011 at 9:59 AM, Peter Wolanin wrote:
> Dear Mr. Hammer-Lahav
>
> regarding http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-02
>
> I was quite happy to find this, si
12 matches
Mail list logo
