Document: draft-mraihi-totp-timebased-07
Reviewer: Ben Campbell
Review Date: 2011-02-14
IETF LC End Date:
IESG Telechat date: 2011-02-17

Summary: This draft is almost ready for publication as an informational RFC. I
have a few questions and comments that should probably be considered prior to
publication.

Note: I apologize for not getting these in during IETF last call. I was
assigned the Gen-ART review for last call, but was on vacation at the time,
and missed the assignment upon my return.

Major issues:

None

Minor issues:

-- general:

There are some implied assumptions about the platform/APIs on which this
algorithm may be implemented, such as "Unix Time" and the "default floor
function". Is that intentional?

-- 5.2:

Is there a requirement that the proover must not make a second attempt inside
a given time window? If so, that was not clear from the text.

If there is not such a requirement, are their security implications if the
proover does send multiple messages inside the same tick? It's not really a
one time pad if that happens is it? (I gather later on that there is an
assumption the user can only make one attempt per time slot--it would be good
to explicitly state that early in the document)



Nits/editorial comments:

-- IDNits reports some issues. Please check.

-- 1.1 and 1.2:

Please expand HOTP and TOTP on first mention in the main body of the draft
(I.e. even if you already did so in the abstract, since people often skip the
abstract.)

-- 1.2: 

Please defined K and C

-- 1.2, last paragraph: "... HMAC-SHA-1 function could be replaced by
HMAC-SHA-256 ..."

What do you mean by "could be" in this context? An implementation could
replace it? A future update to this document?

-- 3, general:

The requirements seem to be a mix of requirements on the design of the
algorithm, and requirements on implementations/users of the algorithm. Is that
the intent?

-- 3, R2: 

Is there an expectation that the time be in sync? You mention later that it is
in section 6--it might be worth mentioning in the requrements.

-- 5.2, last paragraph, last sentence: "The default Time-step size 30 seconds
is recommended."

Redundant with previous paragraph

-- 6, general:

Any reason this comes after the security considerations section?

-6,  1st paragraph: "before being not validated/rejected."

That's ambiguous. Not validated? Not rejected?

-- 6, paragraph 4: "In such cases, the default synchronization may not be
proper when the drift exceeds beyond allowed threshold."

I don't understand this sentence.

-- 7:

It's not clear if you are saying that the referenced document does register
this algorithm, or that it could register this algorithm.