RFC 7619

The NULL Authentication Method in the Internet Key Exchange Protocol Version 2 (IKEv2) 🎀

okay bestie, so this is RFC 7619 💖 It's a Standards Track doc from the IETF, dated August 2015, ISSN 2070-1721. The authors are V. Smyslov of ELVIS-PLUS and P. Wouters of Red Hat 🧚 It updates RFC 4301 (that's the one about IPsec architecture 🦋). It doesn't list anything it obsoletes, so that's a no-show. Let's get into it 💅

Abstract 📝

okay so this doc specifies the NULL Authentication method and the ID_NULL Identification Payload ID Type for Internet Key Exchange Protocol version 2 (IKEv2) ✨ It lets two IKE peers set up single-side authenticated or mutual unauthenticated IKE sessions for those use cases where a peer is unwilling or unable to authenticate or identify itself 🙈 That means IKEv2 can be used for Opportunistic Security (aka Opportunistic Encryption) to defend against Pervasive Monitoring attacks without having to sacrifice anonymity 🫶

Status of This Memo 🧾

this is an Internet Standards Track document 🔥

this document is a product of the Internet Engineering Task Force (IETF) 💅 It represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication. More info on Internet Standards is in Section 2 of RFC 5741 📚

info about the current status of this doc, any errata, and how to give feedback on it lives at http://www.rfc-editor.org/info/rfc7619 🌸

Copyright Notice ©️

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

this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. Please review those docs carefully, bestie, because they describe your rights and restrictions with respect to this document ⚠️ Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License 🎀

Table of Contents 🗂️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
  1.1.  Conventions Used in This Document . . . . . . . . . . . .   4
2.  Using the NULL Authentication Method  . . . . . . . . . . . .   4
  2.1.  Authentication Payload  . . . . . . . . . . . . . . . . .   4
  2.2.  Identification Payload  . . . . . . . . . . . . . . . . .   4
  2.3.  INITIAL_CONTACT Notification  . . . . . . . . . . . . . .   5
  2.4.  Interaction with the Peer Authorization Database (PAD)  .   5
  2.5.  Traffic Selectors . . . . . . . . . . . . . . . . . . . .   6
3.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
  3.1.  Audit Trail and Peer Identification . . . . . . . . . . .   7
  3.2.  Resource Management and Robustness  . . . . . . . . . . .   8
  3.3.  IKE Configuration Selection . . . . . . . . . . . . . . .   8
  3.4.  Networking Topology Changes . . . . . . . . . . . . . . .   8
4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
  5.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
  5.2.  Informative References  . . . . . . . . . . . . . . . . .   9
Appendix A.  Update of PAD processing in RFC 4301 . . . . . . . .  11
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  12
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1. Introduction ✨

okay so IKEv2, which is specified in [RFC7296], gives two parties a way to do an authenticated key exchange 🔐 The peers can use different authentication methods, but there's no method for one or both parties to stay unauthenticated and anonymous 😭 This doc extends the authentication methods so IKE sessions can be unauthenticated and anonymous 💜

sometimes mutual authentication is undesirable, superfluous, or impossible 🙈 Here are three examples of these unauthenticated use cases:

• a user wants to set up an anonymous secure connection to a server 🦋 The user should be able to authenticate the server without presenting or authenticating to the server with their own identity. This case uses a single-sided authentication of the responder.
• a sensor that periodically wakes up from a suspended state wants to send a measurement (e.g., temperature) to a collecting server 🌡️ The sensor must be authenticated by the server to ensure authenticity of the measurement, but the sensor doesn't need to authenticate the server. This case uses a single-sided authentication of the initiator.
• two peers without any trust relationship want to defend against widespread pervasive monitoring attacks as described in [RFC7258] 👀 Without a trust relationship, the peers can't authenticate each other. Opportunistic Security [RFC7435] says unauthenticated encrypted communication is preferred over cleartext communication 🌈 The peers want to use IKE to set up an unauthenticated encrypted connection that protects them against pervasive monitoring attacks. An attacker that is able and willing to send packets can still launch a man-in-the-middle (MITM) attack to get a copy of the unencrypted communication 💀 This case uses a fully unauthenticated key exchange.

to meet these needs, this doc introduces the NULL Authentication method and the ID_NULL ID type ✨ This lets an IKE peer explicitly indicate that it's unwilling or unable to certify its identity 🫶

1.1. Conventions Used in This Document 📖

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🎀

2. Using the NULL Authentication Method 💅

in IKEv2, each peer independently picks the method it uses to authenticate itself to the other side 🧚 A peer may choose to skip authentication by using the NULL Authentication method 🙈 If a host's local policy requires that the identity of its peer be (non-null) authenticated, and that host gets an AUTH payload containing the NULL Authentication method type, it MUST return an AUTHENTICATION_FAILED notification ❌ If an initiator uses the Extensible Authentication Protocol (EAP), the responder MUST NOT use the NULL Authentication method (this is in line with Section 2.16 of [RFC7296]) 🔥

NULL authentication changes how the Authentication and the Identification payloads get formed in the IKE_AUTH exchange 🌸

2.1. Authentication Payload 🔐

NULL authentication still needs a properly formed AUTH payload in the IKE_AUTH exchange messages 💜 The AUTH payload cryptographically links the IKE_SA_INIT exchange messages with the other messages sent over this IKE Security Association (SA), so it's not optional vibes, it's load-bearing ✨

when you use NULL authentication, the content of the AUTH payload is computed using the syntax of pre-shared secret authentication, described in Section 2.15 of [RFC7296] 🦋 The value of SK_pi for the initiator and SK_pr for the responder is used as the shared secret for the content of the AUTH payload. Implementers should note that this means the authentication keys used by the two peers are different in each direction 👑 This is identical to how the contents of the two last AUTH payloads are generated for the non-key-generating EAP methods (see Section 2.16 of [RFC7296] for details) 🍓

The IKEv2 Authentication Method value for NULL Authentication is 13 🎀

2.2. Identification Payload 🪪

when a remote peer isn't authenticated, any ID presented in the Identification Data field of the ID payload can't be validated 😭 To avoid having to send a bogus ID Type with placeholder data, this spec defines a new ID Type, ID_NULL. The Identification Data field of the ID payload for this ID Type MUST be empty 🫶

if NULL authentication is in use and anonymity is a concern, then ID_NULL SHOULD be used in the Identification payload 🙈 Some examples of cases where a non-null identity type and value with NULL authentication can be used are logging, troubleshooting, and scenarios where authentication happens out of band after the IKE SA is created (like in [AUTOVPN]) 🧚 The content of the Identification payload MUST NOT be used for any trust and policy checking in the IKE_AUTH exchange when NULL authentication is employed (see Section 2.4 for details) ⚠️

ID_NULL is mainly meant to be used with NULL authentication, but it could be used in other situations where the content of the Identification payload isn't used 🌈 For example, ID_NULL could be used when authentication is done via raw public keys and the identities are the keys themselves 🔑 These alternative uses of ID_NULL should be described in their own respective documents 📚

The IKEv2 Identification Payload ID Type for ID_NULL is 13 🎀

2.3. INITIAL_CONTACT Notification 🔔

the identity of a peer using NULL authentication can't be used to find existing IKE SAs created by that same peer, since the peer identity isn't authenticated 🙈 For that reason, the INITIAL_CONTACT notifications MUST NOT be used to delete any other IKE SAs based on the same peer identity without additional verification that the existing IKE SAs with matching identity are actually stale ⚠️

the standard IKE Liveness Check procedure, described in Section 2.4 of [RFC7296], can be used to detect stale IKE SAs created by peers using NULL authentication 💅 Inactive, unauthenticated IKE SAs should be checked periodically. Also, creating a new unauthenticated IKE SA can trigger an out-of-order check on existing unauthenticated IKE SAs, possibly limited to identical or close-by IP addresses or to identical identities of the just created IKE SA 🌸

implementations should weigh the resource consumption of sending Liveness Checks against the memory usage of possible orphaned IKE SAs 🧠 Implementations may choose to handle situations with thousands of unauthenticated IKE SAs differently from situations with very few such SAs ✨

to be continued, part 2 coming up next 🫶🦋

2.4. Interaction with the Peer Authorization Database (PAD) 🗂️

Okay so Section 4.4.3 of [RFC4301] is where the Peer Authorization Database (PAD) lives, and it's basically the bridge between the Security Policy Database (SPD) and IKEv2 🌉. The PAD holds an ordered list of records with peers' identities, plus the matching authentication data and Child SA authorization data 💖. So when an IKE SA is getting set up, the PAD is checked to figure out how the peer should be authenticated and which Child SAs they're allowed to create ✨

When you're using NULL authentication, the peer identity is not authenticated and can't be trusted 🙈. And if ID_NULL is used with NULL authentication, there's literally no ID at all 💀. The PAD processing from Section 4.4.3 of [RFC4301] gets updated for NULL authentication like this:

NULL authentication is added as one of the supported authentication methods 🎀. This method doesn't have any authentication data. ID_NULL gets added to the list of allowed ID types too. The matching rule for ID_NULL is just whether that type is used, because there's no actual ID matching to do when ID_NULL has no identity data 🫶

When you're using the NULL Authentication method, those matching rules MUST include matching of a new flag in the SPD entry. That flag says whether unauthenticated users are allowed to use that entry. So every SPD entry needs to be augmented with a flag saying whether it can be used with NULL authentication or not, and only the rules that explicitly have that flag turned on can be used with unauthenticated connections 🔥

The specific text updates to Section 4.4.3 of [RFC4301] are listed in Appendix A ✨

2.5. Traffic Selectors 🦋

Traffic Selectors and narrowing let two IKE peers mutually agree on a traffic range for an IPsec SA. The thing is, an unauthenticated peer must not be allowed to use this mechanism to steal traffic that an IKE peer meant for another host 😭. This gets especially messy when you're supporting anonymous IKE peers behind NAT, because those peers build an IPsec SA using their pre-NAT IP address, which is different from the source IP of their IKE packets 🌀

A rogue IKE peer could use sketchy Traffic Selectors to trick a remote host into handing over IP traffic that the remote host never meant to send to remote IKE peers 👀. For example, if the remote host uses 192.0.2.1 as its DNS server, a rogue IKE peer could set its Traffic Selector to 192.0.2.1 and try to receive the remote peer's DNS traffic. Not it! 💅 Implementations SHOULD restrict and isolate all anonymous IKE peers from each other and from itself, and only allow them access to itself and possibly their intended network ranges.

One way to pull this off is to always assign internal IP addresses to unauthenticated IKE clients, as described in Section 2.19 of [RFC7296] 🧚. Implementations may also use other techniques, like internal NAT and connection tracking.

Implementations MAY force unauthenticated IKE peers into single host-to-host IPsec SAs. Here's the catch: when you're using IPv6, that's not always possible 🙃. So implementations MUST be able to assign a full /64 address block to the peer, as described in [RFC5739], even if it isn't authenticated.

3. Security Considerations 🚨

Okay, this section is serious, bestie, so read it carefully 🥺. If authenticated IKE sessions are possible for a certain Traffic Selector range between the peers, then unauthenticated IKE SHOULD NOT be allowed for that Traffic Selector range. When you mix authenticated and unauthenticated IKE with the same peer, your policy rules should make sure the highest level of security gets used to protect the communication between the two peers. See [RFC7435] for details 🔐

⚠️ If both peers use NULL authentication, the entire key exchange becomes unauthenticated. That makes the IKE session vulnerable to active MITM attacks. Scary, right? 😱

Using an ID Type other than ID_NULL with the NULL Authentication method may compromise the client's anonymity in case of an active MITM attack 🙈

IKE implementations without NULL authentication have always performed mutual authentication, and they were never designed for unauthenticated IKE peers 🙃. They might have made assumptions that remote peers are identified. With NULL authentication, those assumptions are no longer valid. On top of that, the host itself might have made trust assumptions, or it might not be aware of the network topology changes that came from IPsec SAs created by unauthenticated IKE peers 🌪️

3.1. Audit Trail and Peer Identification 📜

With NULL authentication, an established IKE session is no longer guaranteed to give you a verifiable (authenticated) entity that the system or network knows about 🕵️. Any logging of unproven ID payloads that weren't authenticated should be clearly marked and treated as "untrusted". It's also a good idea to possibly log the remote IP address of the IKE session alongside it. Rate limiting of logging might be required, so logging doesn't eat up so many resources that it damages the system 💀

3.2. Resource Management and Robustness 🛡️

Section 2.6 of [RFC7296] gives guidance on mitigating denial-of-service (DoS) attacks by issuing COOKIES in response to resource consumption from half-open IKE SAs 🍪. On top of that, [DDOS-PROTECTION] offers extra countermeasures that try to tell attacking IKE packets apart from legitimate IKE peers.

These defense mechanisms don't take IKE systems that allow unauthenticated IKE peers into account 😤. An attacker using NULL authentication is a fully legitimate IKE peer. The only thing that sets them apart from authenticated IKE peers is that they used NULL authentication.

Implementers who implement NULL authentication should make sure their implementation doesn't make any assumptions that depend on IKE peers being "friendly", "trusted", or "identifiable" 🥹. Implementations should have been written to handle abusive authenticated clients, but any omission or error in handling abusive clients may have gone unnoticed, because abusive clients have been a rare or nonexistent problem. When you add support for unauthenticated IKE peers, those omissions and errors will get found and abused by attackers 👾. For example, an unauthenticated IKE peer could send an abusive amount of Liveness probes or Delete requests.

3.3. IKE Configuration Selection 🎛️

Combining authenticated and unauthenticated IKE peers on a single host can be dangerous, especially if the authenticated IKE peer gets more or different access than unauthenticated peers. (Otherwise, why not only allow unauthenticated peers? 🤷‍♀️) An unauthenticated IKE peer MUST NOT be able to reach resources that are only meant for authenticated IKE peers, and it MUST NOT be able to replace the Child SAs of an authenticated IKE peer 🚫

3.4. Networking Topology Changes 🗺️

When a host relies on packet filters or firewall software to protect itself, setting up an IKE SA and installing an IPsec SA might accidentally get around those packet filters and firewall restrictions. That's because the Encapsulating Security Payload (ESP, protocol 50) or ESPinUDP (UDP port 4500) packets of the encrypted traffic don't match the packet filters defined for unencrypted traffic 😬. So IKE peers that support unauthenticated IKE MUST pass all decrypted traffic through the same packet filters and security mechanisms as incoming plaintext traffic 🔒

4. IANA Considerations 📋

Okay, IANA got some new entries from this document 🎉. Here's the new one in the "IKEv2 Authentication Method" registry:

  13       NULL Authentication

And here's the new one in the "IKEv2 Identification Payload ID Types" registry:

  13       ID_NULL

5. References 📚

5.1. 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,
           <http://www.rfc-editor.org/info/rfc2119>.

[RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
           Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
           December 2005, <http://www.rfc-editor.org/info/rfc4301>.

[RFC5739]  Eronen, P., Laganier, J., and C. Madson, "IPv6
           Configuration in Internet Key Exchange Protocol Version 2
           (IKEv2)", RFC 5739, DOI 10.17487/RFC5739, February 2010,
           <http://www.rfc-editor.org/info/rfc5739>.

[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, <http://www.rfc-editor.org/info/rfc7296>.

5.2. Informative References 🌷

[RFC7258]  Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
           Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
           2014, <http://www.rfc-editor.org/info/rfc7258>.

[RFC7435]  Dukhovni, V., "Opportunistic Security: Some Protection
           Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
           December 2014, <http://www.rfc-editor.org/info/rfc7435>.

[AUTOVPN]  Sheffer, Y. and Y. Nir, "The AutoVPN Architecture", Work
           in Progress, draft-sheffer-autovpn-00, February 2014.

[DDOS-PROTECTION]
           Nir, Y. and V. Smyslov, "Protecting Internet Key Exchange
           (IKE) Implementations from Distributed Denial of Service
           Attacks", Work in Progress, draft-ietf-ipsecme-ddos-
           protection-02, July 2015.

Appendix A. Update of PAD processing in RFC 4301 🧩

Okay, this appendix lists the exact text updates to Section 4.4.3 of [RFC4301] that you should follow when you implement NULL authentication 💖

A new item gets added to the list of supported ID types in Section 4.4.3.1 of [RFC4301]:

o  NULL ID (matches ID type only)

And this text gets added at the end of that section:

Added text:
   The NULL ID type is defined as having no data.  For this name
   type, the matching function is defined as comparing the ID type
   only.

A new item also gets added to the list of authentication data types in Section 4.4.3.2 of [RFC4301]:

- NULL authentication

And the next paragraph gets updated like this:

Old:
   For authentication based on an X.509 certificate [...] For
   authentication based on a pre-shared secret, the PAD contains the
   pre-shared secret to be used by IKE.

New:
   For authentication based on an X.509 certificate [...] For
   authentication based on a pre-shared secret, the PAD contains the
   pre-shared secret to be used by IKE.  For NULL authentication the
   PAD contains no data.

Finally, this text gets added at the end of Section 4.4.3.4 of [RFC4301]:

Added text:
   When using the NULL Authentication method, implementations MUST
   make sure that they do not mix authenticated and unauthenticated
   SPD rules, i.e., implementations need to keep them separately; for
   example, by adding a flag in the SPD to tell whether NULL
   authentication can be used or not for the entry.  That is, each
   SPD entry needs to be augmented to have a flag specifying whether
   it can be used with NULL authentication or not, and only those
   rules that explicitly have that flag set can be used with
   unauthenticated connections.

Acknowledgments 🫶

The authors would like to thank Yaron Sheffer and Tero Kivinen for their reviews, valuable comments, and contributed text 💜

Authors' Addresses 📬

Valery Smyslov
ELVIS-PLUS
PO Box 81
Moscow (Zelenograd)  124460
Russian Federation

Phone: +7 495 276 0211
Email: svan@elvis.ru


Paul Wouters
Red Hat

Email: pwouters@redhat.com