[IPsec] [Technical Errata Reported] RFC8031 (6339)

[RFC Errata System <[e-mail]>]

The following errata report has been submitted 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/eid6339

--------------------------------------
Type: Technical
Reported by: Christian Tschudin <[e-mail]>

Section: Appendix A

Original Text
-------------
The public keys are generated from this using the formula in
Section 2:

pub_i = X25519(d_i, G) =
             48 d5 dd d4 06 12 57 ba 16 6f a3 f9 bb db 74 f1
             a4 e8 1c 08 93 84 fa 77 f7 90 70 9f 0d fb c7 66

pub_r = X25519(d_r, G) =
             0b e7 c1 f5 aa d8 7d 7e 44 86 62 67 32 98 a4 43
             47 8b 85 97 45 17 9e af 56 4c 79 c0 ef 6e ee 25

And this is the value of the Key Exchange Data field in the Key
Exchange payload described in Section 3.1.  The shared value is
calculated as in Section 2:

SHARED_SECRET = X25519(d_i, pub_r) = X25519(d_r, pub_i) =
             c7 49 50 60 7a 12 32 7f-32 04 d9 4b 68 25 bf b0
             68 b7 f8 31 9a 9e 37 08-ed 3d 43 ce 81 30 c9 50


Corrected Text
--------------
The public keys are generated from this using the formula in
Section 2:

pub_i = X25519(d_i, G) =
             a7 07 b3 bc 0f 37 56 fc 0a cf 33 55 85 c5 f7 7b
             9f 29 ff a4 24 70 14 af 84 70 5b eb 50 46 26 29

pub_r = X25519(d_r, G) =
             0e 57 7e 11 5d 6c 08 59 b8 51 36 d2 1b 1c fd 74
             67 9f 91 14 61 1d 79 c6 81 ba d0 8a 7e 1f 0a 04

And this is the value of the Key Exchange Data field in the Key
Exchange payload described in Section 3.1.  The shared value is
calculated as in Section 2:

SHARED_SECRET = X25519(d_i, pub_r) = X25519(d_r, pub_i) =
             d6 8d 8c ea fd 2c d3 ce 25 34 43 33 c8 9e 35 54
             9e 0f c6 1a 98 87 39 34 b1 8a 18 70 f0 3a 17 0c


Notes
-----
The test vector values given both for the public keys and for the shared secret are wrong. It turns out that they were derived from the unchanged random input, instead of d_X. An explanation could be that a first text version did not include the fixing of the random bits and that after inserting the respective paragraph (introducing fixed_X and d_X), it was forgotten to update pub_X and SHARED_SECRET.

This 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.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
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