Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-01.txt

From: [email-masked]
Date: Wed, 08 Feb 2012 09:52:09 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF.

	Title           : HTTP Authentication: MAC Access Authentication
	Author(s)       : Eran Hammer-Lahav
	Filename        : draft-ietf-oauth-v2-http-mac-01.txt
	Pages           : 20
	Date            : 2012-02-08

   This document specifies the HTTP MAC access authentication scheme, an
   HTTP authentication method using a message authentication code (MAC)
   algorithm to provide cryptographic verification of portions of HTTP
   requests.  The document also defines an OAuth 2.0 binding for use as
   an access-token type.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-http-mac-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-http-mac-01.txt

---

From: Eran Hammer <[email-masked]>
Date: Wed, 8 Feb 2012 10:54:40 -0700

Main changes:

Removed cookies support
Removed body hash
Clarified timestamp verification

I still have more comments to process but wanted to get a new draft out first as the current one expired.

Please review the new timestamp prose and let me know what you think. I'm trying to allow the client to use any timestamp it can easily produce, and move the verification logic to the server as much as possible.

EH

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of [email-masked]
> Sent: Wednesday, February 08, 2012 9:52 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-01.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Web Authorization Protocol Working Group of
> the IETF.
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: William Mills <[email-masked]>
Date: Wed, 8 Feb 2012 10:41:03 -0800 (PST)

Might be worthwhile to ask to have the previous draft marked as superceded by this one.

________________________________
 From: Eran Hammer <[email-masked]>
To: "[email-masked]" <[email-masked]> 
Sent: Wednesday, February 8, 2012 9:54 AM
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-01.txt
 
Main changes:

Removed cookies support
Removed body hash

EH

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 9 Feb 2012 17:51:08 +1100

Eran, a couple of comments on the new MAC spec:

The example (§1.1) does not seem to be correct. That is, I calculate mac="6T3zZzy2Emppni6bzL7kdRxUWL4=" instead of the given value.

The example in §3.2.1 has a typo. It says "using timestamp "264095:7d8f3e4a"", but should say "using timestamp "264095"".

Timestamp verification (§4.1) is described as preventing replay attacks. However, the 3 dot points that server  MUST do only ensure that requests (other than the first) are approximately fresh (assuming the first was fresh). Of course, it is fairly obvious that the service can keep a copy of {ts,nonce,id} tuples (while the ts is still approximately fresh) to detect replays.

When the ts field is defined (§3.1) it is probably worth mentioning that the fixed point in time (epoch) chosen to calculate ts MUST remain the same for the lifetime of the key. That is, a client app cannot pick a new epoch each time it starts if it is using the same key across restarts.

Personally, I would almost prefer it to say: ts is seconds since 1970 were possible; clients without a real-time clock can choose an arbitrary epoch, but it must remain the same for the lifetime of the key; servers SHOULD NOT assume client clocks are well synchronized to their own. It is RECOMMENDED that a server assumes the 1st request with a given key is fresh, and use the ts value in that request to determine the offset between the client & servers clocks. That offset (assumed to remain constant) can be used to determine if subsequent requests are fresh.

--
James Manger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer
Sent: Thursday, 9 February 2012 4:55 AM
To: [email-masked]
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-01.txt

Main changes:

Removed cookies support
Removed body hash

EH

---

From: Erlend Hamnaberg <[email-masked]>
Date: Thu, 16 Feb 2012 10:55:53 +0100

Comments inline:

On Thu, Feb 9, 2012 at 7:51 AM, Manger, James H <
[email-masked]> wrote:

> The example (§1.1) does not seem to be correct. That is, I calculate
> mac="6T3zZzy2Emppni6bzL7kdRxUWL4=" instead of the given value.
>

I get this as well.

> The example in §3.2.1 has a typo. It says "using timestamp
> "264095:7d8f3e4a"", but should say "using timestamp "264095"".
>
> +1

> Timestamp verification (§4.1) is described as preventing replay attacks.
> However, the 3 dot points that server  MUST do only ensure that requests
> (other than the first) are approximately fresh (assuming the first was
> fresh). Of course, it is fairly obvious that the service can keep a copy of
> {ts,nonce,id} tuples (while the ts is still approximately fresh) to detect
> replays.
>
> When the ts field is defined (§3.1) it is probably worth mentioning that
> the fixed point in time (epoch) chosen to calculate ts MUST remain the same
> for the lifetime of the key. That is, a client app cannot pick a new epoch
> each time it starts if it is using the same key across restarts.
>
> Personally, I would almost prefer it to say: ts is seconds since 1970 were
> possible; clients without a real-time clock can choose an arbitrary epoch,
> but it must remain the same for the lifetime of the key; servers SHOULD NOT
> assume client clocks are well synchronized to their own. It is RECOMMENDED
> that a server assumes the 1st request with a given key is fresh, and use
> the ts value in that request to determine the offset between the client &
> servers clocks. That offset (assumed to remain constant) can be used to
> determine if subsequent requests are fresh.
>
> Seems reasonable.

-E

---

From: Eran Hammer <[email-masked]>
Date: Thu, 16 Feb 2012 16:14:30 -0700

I haven't seen much feedback so I assume this is almost ready for LC. I
will apply the suggestions below and will request a WGLC for -02.

EH

On 2/8/12 10:51 PM, "Manger, James H" <[email-masked]>
wrote:

>fresh). Of course, it is fairly obvious that the service can keep a copy
>of {ts,nonce,id} tuples (while the ts is still approximately fresh) to
>detect replays.
>
>the fixed point in time (epoch) chosen to calculate ts MUST remain the
>same for the lifetime of the key. That is, a client app cannot pick a new
>epoch each time it starts if it is using the same key across restarts.
>
>Personally, I would almost prefer it to say: ts is seconds since 1970
>were possible; clients without a real-time clock can choose an arbitrary
>epoch, but it must remain the same for the lifetime of the key; servers
>SHOULD NOT assume client clocks are well synchronized to their own. It is
>RECOMMENDED that a server assumes the 1st request with a given key is
>fresh, and use the ts value in that request to determine the offset
>between the client & servers clocks. That offset (assumed to remain
>constant) can be used to determine if subsequent requests are fresh.
>
>--
>James Manger
>
>Please review the new timestamp prose and let me know what you think. I'm
>trying to allow the client to use any timestamp it can easily produce,
>and move the verification logic to the server as much as possible.
>
>EH
>

---

From: Julian Reschke <[email-masked]>
Date: Fri, 17 Feb 2012 09:16:57 +0100

> will apply the suggestions below and will request a WGLC for -02.

You should align with the Bearer spec on referencing httpbis P7, and 
apply some of the changes we discussed for that spec 
(challenge/credentials ABNF etc).

Best regards, Julian