Re: [saag] saag Digest, Vol 178, Issue 2

[Derrell Piper <[e-mail]>]

> 
> From: Paul Wouters <[e-mail]>
> Subject: [saag] errata dilemma for HOTP: An HMAC-Based One-Time Password Algorithm
> Date: August 2, 2023 at 7:26:35 PM PDT
> To: IETF SAAG <[e-mail]>
> 
> 
> 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
> 
> 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>].
> 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? 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.
> 
> 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?
> 

I would, and I’d probably add a section 5.3 to explain, given the large number of already deployed implementations.
> Paul
> 
> From: Peter Gutmann <[e-mail]>
> Subject: Re: [saag] errata dilemma for HOTP: An HMAC-Based One-Time Password Algorithm
> Date: August 2, 2023 at 9:16:13 PM PDT
> To: Paul Wouters <paul.wouters=[e-mail]>, IETF SAAG <[e-mail]>
> 
> 
> Paul Wouters <paul.wouters=[e-mail]> writes:
> 
>> 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?
> 
> I haven't, but if I did the logical way to do it would be to take the last 
> byte, not a byte from some arbitrary position inside the hash.  I would 
> accept the erratum but then also write an RFC to cover SHA-2 use rather than
> rely on a sort of COME FROM suggestion in a random different RFC, 6238, to 
> control what's going on in 4226.
> 
> Having said that, there are, probably several billion deployed 
> implementations of HMAC-SHA1 based TOTP and no good reason to use SHA-2
> instead, so it seems like a moot problem.  If anything I'd say "don't use
> HMAC-SHA2 unless you really enjoy trying to boil the ocean".
> 
> Peter.