The following errata report has been held for document update for RFC8031, "Curve25519 and Curve448 for the Internet Key Exchange Protocol Version 2 (IKEv2) Key Agreement".
-------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6931 -------------------------------------- Status: Held for Document Update Type: Technical Reported by: Christian Tschudin <[email protected]> Date Reported: 2020-11-17 Held by: Paul Wouters (IESG) Section: Global Original Text ------------- Corrected Text -------------- Notes ----- A discrepancy came to my attention when testing the Yubikey 5 hardware and comparing it with the NaCl library and RFC8031. While the NaCl library works as expected, it is disturbing to see that the Yubikey can only be made to produce the desired (above and corrected) shared secret if you let it compute X25519(fixed_i,pub_r). That is, the secret must be presented to the Yubikey in big-endian format which could be "inspired" by the (not very detailed) Smartcard spec 3.4.1 that refers to ANSI X9.62 where curve parameters, prefixed with 0x04, are encoded in big-endian order - clearly the ANSI encoding is not useful here as we only need one parameter u. I wonder whether RFC8031 should spell out that input parameters (d_X and pub_X) SHOULD be presented in encoded form (and thus little-endian), hence putting manufacturers in charge of documenting any deviation. -------------------------------------- RFC8031 (draft-ietf-ipsecme-safecurves-05) -------------------------------------- Title : Curve25519 and Curve448 for the Internet Key Exchange Protocol Version 2 (IKEv2) Key Agreement Publication Date : December 2016 Author(s) : Y. Nir, S. Josefsson Category : PROPOSED STANDARD Source : IP Security Maintenance and Extensions Area : Security Stream : IETF Verifying Party : IESG _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
