Re: [saag] errata dilemma for HOTP: An HMAC-Based One-Time Password Algorithm

[Paul Wouters <[e-mail]>]

Simon,

I think your proposal is the right fix, especially since you have interop
cases that work, and we have no one speaking up about having used the other
interpretation. I'll give it a few more days for people to respond, and if
I hear no other views, will proceed with that.

Thanks!

Paul

On Thu, Aug 3, 2023 at 6:07 PM Simon Josefsson <simon=
[e-mail]> wrote:

> Paul Wouters <paul.wouters=[e-mail]> writes:
>
> > I looked at some erratas (to do my part of reducing our list) and noticed
> > this interesting errata:
> >
> > https://www.rfc-editor.org/errata/eid6756
> >
> > It talks about the HOTP algorithm and the errata proposal points out:
> >
> > Section 5.3 says:
> >
> > Let OffsetBits be the low-order 4 bits of String[19]
> >
> > It should say:
> >
> > Let OffsetBits be the low-order 4 bits of the last byte of String
>
> I disagree -- this wording in the HOTP RFC is not the source of the
> problem.  HOTP is not specified for non-SHA1.
>
> > For the HMAC-SHA1 case, the last byte is string[19], but for the newer
> > SHMAC-SHA2 cases this is not true.
> > These are specified in RFC 6238 where it states:
> >
> >    TOTP implementations MAY use HMAC-SHA-256 or HMAC-SHA-512 functions,
> >    based on SHA-256 or SHA-512 [SHA2
> > <https://datatracker.ietf.org/doc/html/rfc6238#ref-SHA2>] hash
> > functions, instead of the
> >    HMAC-SHA-1 function that has been specified for the HOTP computation
> >    in [RFC4226 <https://datatracker.ietf.org/doc/html/rfc4226>].
>
> This part of the TOTP RFC is the problem.  That is not a sufficiently
> precise specification of how to use HOTP with SHA-256 or SHA-512.
>
> > The main issue now is if anyone has implemented the 6238 TOTP with the
> SHA2
> > variant, did they interpret the reference to RFC 4226 as to be using the
> > 19th byte of the HMAC-SHA2 string or the last byte?
>
> OATH Toolkit uses the last byte:
>
>
> https://gitlab.com/oath-toolkit/oath-toolkit/-/blob/7ba54a8e08ceb1b958d66cee0dd42b187a7a69c3/liboath/hotp.c#L120
>
> TOTP with SHA256/512 is not as widely used as SHA1 but I think we have
> interop with several implementations.
>
> > This might have already caused interoperability issues. But issuing an
> > errata (whether for 4226 or 6238) might cause people to again write
> > non-interoperable implementations.
>
> I think we should add an errata for 6238, after the paragraph you quote
> above:
>
>   In section 5.1 of HOTP, we intend String[19] to be interpreted as
>   String[HashSize - 1] where Hashsize is 32 for HMAC-SHA-256 and 64 for
>   HMAC-SHA-512.
>
> > That is, I honestly don't know if rejecting or accepting an errata on
> this
> > topic might make things better or worse.
> >
> > Does anyone know some implementers of this? If so, which flavour did they
> > use? Or do they try both to work around this issue?
> >
> > Should we do a short Update: for 6238 that tells people to "try both" to
> > resolve this issue?
>
> If we don't have evidence of wide-spread deployment of both approaches,
> please let's not encourage the "try both" approach.  It may sound like a
> simple protocol change but results in awful increase in complexity for
> implementaters.
>
> /Simon
>