Comments inline:
On Thu, Feb 9, 2012 at 7:51 AM, Manger, James H <
[email protected]> wrote:
> 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.
>
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
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
