[Gen-art] Gen-ART LC and Telechat review of draft-mraihi-totp-timebased-07

[Ben Campbell <[e-mail]>]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

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.