Last Call Review of draft-mraihi-mutual-oath-hotp-variants-
review-mraihi-mutual-oath-hotp-variants-secdir-lc-perlman-2011-02-26-00

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

I found the document quite difficult to understand, even though it was
relatively short.  Part of what makes it hard to read is due to
terminology, like using "signature" to mean, (I think), simply a
response to a challenge, rather than (how I would use the term) an
integrity check on a message.  This was especially confusing because
in section 3, requirement R2 claims that OCRA will generate a
symmetric key digital signature on a message, whereas the "signature
variant" in section 7.3 seems to be just the same as
challenge/response, other than omitting the input that I'd call
"channel binding", (but they call "S".)

Personally I don't like the term OTP to mean the general type of thing
generated by one of these crypto token cards, since I think of it as
the specific OTP protocol (RFC 2289), but apparently wikipedia defines
OTP as based on a token display value, so it must be correct, and I'll
adapt.  :-)

I also don't like the term "random questions" to mean a challenge.  To
me, "random questions" is when a verifier knows a bunch of
human-rememberable questions, and asks a random subset of them to the
human. It's particularly hard to understand a document when the same
quantity is sometimes referred to as a "challenge" and sometimes as a
"question".

To their credit, code is included, which helped in some cases for me
to clarify what was going on when I was having trouble understanding
the prose.

There also seems to be unnecessary complexity, like including a hash
of the PIN rather than simply the PIN, into the inputs of the
function, and the truncation function that, rather than simply taking
the first n bits or the last n bits, uses the last 4 bits of the hash
to determine where in the hash to take the 32 bits.

With 32 bits of the hash to compute as a digital value, the algorithm
supports up to 10 decimal digits.  That would mean that if you use 10
digits, given that 32 bits is just 4 billion, the first digit will
never be more than 4.

I do understand why it would be nice to have an open standard for
these sort of token devices, so that people can build interoperable
tokens and verifiers.  But I don't understand the need for all the
variations in OCRA, especially when imagining the user having to type
in a lot of values.  It's hard enough to type in a PIN, but then also
typing in channel bindings, challenges to the server, etc., make it
hard for me to imagine a human putting up with this.

Mysteriously to me, requirement R7 says that the challenge might have
integrity checking, so that the device can notice and inform the user
if the user mistypes the challenge.  But what about the PIN and the
channel bindings?  Wouldn't that be just as important to catch an
honest user mistake?

The document does not explain how to verify a response, and I think if
it did, it would be clear that the mutual authentication will not work
if it included a counter and/or timestamp.  These values are not
necessarily synchronized at client and server, so the server would
have to test several plausible inputs, and if both are used, if there
are k plausible counter values, and n plausible timestamps, it would
be k*n possible values to test.  The spec assumes that the token card
will display the (single) value that the server transmits, and the
user will compare it against the display.

I also find it a bit mysterious that the PIN is an input into what the
client sends, but not in what the server responds.  The server needs
to know the PIN in order to verify what the client sends, so I can't
quite see the reason for the asymmetry.

What does the sentence "The server SHOULD also provide whenever
possible a mean for the client (if able) to verify the validity of the
signature challenge." mean?


Radia