RFC 8420

Using the Edwards-Curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange Protocol Version 2 (IKEv2) 🎀

okay bestie, this one is a Standards Track doc from August 2018 (ISSN 2070-1721), written by Y. Nir at Dell EMC 💼✨. It's all about getting EdDSA signatures working inside IKEv2, which is the protocol that sets up encrypted VPN tunnels and stuff 🔐. The header doesn't have any "Obsoletes" or "Updates" line, so it doesn't replace or change any other RFCs 🙌.

---

Abstract ✨

This doc describes how to use the Edwards-curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange Protocol Version 2 (IKEv2). That's the whole pitch, periodt 💅.

Status of This Memo 📜

This is an Internet Standards Track document, meaning it's an actual official standard and not just an idea someone had in the shower 🚿.

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on what Internet Standards are, check Section 2 of RFC 7841 🌸.

You can find the current status, any errata, and a place to send feedback at https://www.rfc-editor.org/info/rfc8420 🦋.

Copyright Notice ⚖️

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved 💜.

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they were on the publication date. Please actually read those, because they spell out your rights and restrictions for this doc, no cap 🙈. Code Components pulled out of this doc have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 🍓.

Table of Contents 🗂️

1. Introduction ....................................................2
   1.1. Conventions Used in This Document ..........................3
2. The "Identity" Hash Identifier ..................................3
3. Security Considerations .........................................3
4. IANA Considerations .............................................3
5. Normative References ............................................3
Appendix A.  ASN.1 Objects .........................................4
  A.1.  ASN.1 Object for Ed25519 ...................................4
  A.2.  ASN.1 Object for Ed448 .....................................4
Author's Address ...................................................5

1. Introduction ✨

Okay so IKEv2 [RFC7296] can use all kinds of signature algorithms, as long as they're described in [RFC7427] 🔑. [RFC7427] added the SIGNATURE_HASH_ALGORITHMS notification, where each side lists the hash algorithms it supports 📝. The assumption baked into all that is that every signature scheme hashes the message first and then signs the hash. That made sense back then, because most signature algorithms either can't sign messages bigger than their key or they chop off messages bigger than their key 🤷‍♀️.

EdDSA [RFC8032] is different, though! Its signature methods don't require prehashing the message. They take messages of any size, so no prehashing is needed at all 🌈. These are called Ed25519 and Ed448, and they use the Edwards 25519 and Edwards 448 ("Goldilocks") curves, respectively 💎. That same document also defines prehashed versions of these algorithms, but those aren't recommended for protocols where it's easy to buffer the whole message and make two passes over it. IKEv2 is one of those protocols. Section 8.5 of [RFC8032] has the recommendation 👑.

EdDSA defines the binary format of the signatures that should be used in the "Signature Value" field of the Authentication Data Format in Section 3 of RFC 8032 🧚. [RFC8410] defines the object identifiers (OIDs) for these signature methods, and we copy them into Appendix A so you don't have to go hunting 🫶.

So to tell IKE "hey, no hashing needed here," we define a new value in the SIGNATURE_HASH_ALGORITHMS notification that means no hashing is performed 🔥.

1.1. Conventions Used in This Document 📖

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 💅.

2. The "Identity" Hash Identifier 🪪

This doc creates a brand new value called "Identity" (5) in the "IKEv2 Hash Algorithms" registry, for use in the SIGNATURE_HASH_ALGORITHMS notification 🆕. Putting this value in the notification tells the other side that you support at least one signature algorithm that takes messages of any size, like Ed25519 and Ed448 🦋.

Ed25519 and Ed448 are only defined with the "Identity" hash, so they MUST NOT be sent to a receiver that hasn't indicated support for the "Identity" hash 🚫. Main character rule, no exceptions 👑.

The prehashed versions of Ed25519 and Ed448 (Ed25519ph and Ed448ph, respectively) MUST NOT be used in IKE 🙅‍♀️.

3. Security Considerations 🚨

This section is serious business, bestie. Read it carefully 💀.

The new "Identity" value is only needed for signature algorithms that accept input of arbitrary size. It MUST NOT be used if none of the supported and configured algorithms have that property 🛑. On the flip side, there's no good reason to prehash the inputs when the signature algorithm already has that property 🙃. So implementations MUST have the "Identity" value in the SIGNATURE_HASH_ALGORITHMS notification whenever EdDSA is supported and configured 🔒. And implementations SHOULD NOT include other hash algorithms in the notification if all of their supported and configured signature algorithms have that property 🧹.

4. IANA Considerations 📋

IANA has assigned the value 5 to the algorithm named "Identity" in the "IKEv2 Hash Algorithms" registry, with this document as the reference 🎉.

5. Normative References 📚

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, https://www.rfc-editor.org/info/rfc2119.

[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, https://www.rfc-editor.org/info/rfc7296.

[RFC7427] Kivinen, T. and J. Snyder, "Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)", RFC 7427, DOI 10.17487/RFC7427, January 2015, https://www.rfc-editor.org/info/rfc7427.

[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, https://www.rfc-editor.org/info/rfc8032.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, https://www.rfc-editor.org/info/rfc8174.

[RFC8410] Josefsson, S. and J. Schaad, "Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure", RFC 8410, DOI 10.17487/RFC8410, August 2018, https://www.rfc-editor.org/info/rfc8410.

Appendix A. ASN.1 Objects 🧩

[RFC8410] is the normative reference for the ASN.1 objects for Ed25519 and Ed448. We repeat them down here for convenience 💖.

A.1. ASN.1 Object for Ed25519 💎

id-Ed25519 OBJECT IDENTIFIER ::= { 1.3.101.112 }

Parameters are absent. Length is 7 bytes.

Binary encoding: 3005 0603 2B65 70

A.2. ASN.1 Object for Ed448 🌙

id-Ed448 OBJECT IDENTIFIER ::= { 1.3.101.113 }

Parameters are absent. Length is 7 bytes.

Binary encoding: 3005 0603 2B65 71

Author's Address 💌

Yoav Nir Dell EMC 9 Andrei Sakharov St Haifa 3190500 Israel

Email: ynir.ietf@gmail.com 🧚‍♀️