RFC 4478

RFC 4478 💖 Repeated Authentication in Internet Key Exchange (IKEv2) Protocol 🎀

okay bestie, let's get into this one 🦋 It's an Experimental RFC (so it's an Experimental Protocol, NOT a standard, no cap 🧪), written by Y. Nir from Check Point, and it came out in April 2006. It doesn't obsolete anything and it doesn't update anything, so it just sits there being its own iconic self ✨. It extends the IKEv2 spec ([IKEv2]), which is RFC 4306.

Network Working Group: Y. Nir, Check Point. Request for Comments: 4478. Category: Experimental. April 2006.

---

Status of This Memo

This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. 📣

Copyright Notice

Copyright (C) The Internet Society (2006). ©️

1. Abstract 🌸

Okay so this doc extends IKEv2 ([IKEv2]). With some IPsec peers, especially in remote access setups, it's giving "repeat the mutual authentication periodically" 🔁. Why? To limit how long security associations (SAs) can be used by a third party who has taken control of the IPsec peer. This RFC describes a mechanism to make that happen 🔐.

2. Introduction 🧚

In several cases, like remote access, policy says the mutual authentication has to be repeated periodically 💅. Usually you can just repeat the Initial exchange, done by whichever side has the stricter policy.

BUT in remote access it's usually a human typing in their credentials 🙈, and EAP is often the auth method, which makes it unreasonable or impossible for the remote access gateway to start the IKEv2 exchange. Not it! 🙅‍♀️

So this document defines a new notification that the original Responder can send to the original Initiator, containing the number of seconds before authentication needs to be repeated ⏳. The Initiator SHOULD repeat the Initial exchange before that time expires. If the Initiator fails to do so, the Responder may close all Security Associations.

Repeated authentication is NOT the same thing as IKE SA rekeying, and it doesn't need to be tied to it 🙅‍♀️. The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in [RFC2119] 📖.

3. Authentication Lifetime 🕰️

The Responder in an IKEv2 negotiation MAY be configured to limit how long an IKE SA and its associated IPsec SAs can be used before the peer has to repeat the authentication through a new Initial Exchange. Lowkey a power move 👑.

The Responder MUST send this info to the Initiator in an AUTH_LIFETIME notification, either in the last message of an IKE_AUTH exchange, or in an INFORMATIONAL request, which may be sent at any time 📬.

When it's sent as part of the IKE SA setup, the AUTH_LIFETIME notification goes like this:

   Initiator                            Responder
   -------------------------------      -----------------------------
   HDR, SAi1, KEi, Ni              -->
                                   <--  HDR, SAr1, KEr, Nr, [CERTREQ]
   HDR, SK {IDi, [CERT,] [CERTREQ,]
      [IDr,] AUTH, SAi2, TSi, TSr} -->
                                   <--  HDR, SK {IDr, [CERT,] AUTH,
                                                 SAr2, TSi, TSr,
                                                  N(AUTH_LIFETIME)}

The separate Informational exchange looks like this:

                                   <--  HDR, SK {N(AUTH_LIFETIME)}
   HDR  SK {}                      -->

The AUTH_LIFETIME notification is described in Section 3.

Wait, the bit below is where it gets spicy 🌶️. The original Responder that sends AUTH_LIFETIME SHOULD send a DELETE notification soon after the lifetime period ends, UNLESS the IKE SA gets deleted before then 💀. If the IKE SA is rekeyed, the time limit applies to the new SA 🔄.

An Initiator that got an AUTH_LIFETIME notification SHOULD repeat the Initial exchange within the time the notification indicated ⏰. That time is measured from when the original Initiator receives the notification.

There's a special case: when the notification is sent in an Informational exchange AND the lifetime is zero. In that situation the original Responder SHOULD allow a reasonable amount of time for the repeated authentication to happen 🫶.

The AUTH_LIFETIME notification MUST be protected, and the original Responder MAY send it at any time 🔒. If the policy changes, the original Responder MAY send it again in a new Informational 🔁.

The new Initial exchange is not altered 💅. The initiator SHOULD delete the old IKE SA within a reasonable time of the new Auth exchange 🗑️.

4. AUTH_LIFETIME Notification 📦

The AUTH_LIFETIME message is a notification payload, laid out like this:

                       1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  ! Next Payload  !C!  RESERVED   !         Payload Length        !
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  !  Protocol ID  !   SPI Size    !      Notify Message Type      !
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  !                           Lifetime                            !
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Here's the breakdown 🔍:

• Payload Length is 12.
• Protocol ID (1 octet) MUST be 0.
• SPI size is 0 (SPI is in message header).
• Notify Message type is 16403 by IANA.
• Lifetime is the amount of time (in seconds) left before the peer should repeat the Initial exchange. A zero value signifies that the Initial exchange should begin immediately. It is usually not reasonable to set this value to less than 300 (5 minutes), since that is too cumbersome for a user. It is also usually not reasonable to set this value to more than 86400 (1 day), as that would negate the security benefit of repeating the authentication 🥺.

5. Interoperability with Non-Supporting IKEv2 Implementations 🤝

IKEv2 implementations that don't support the AUTH_LIFETIME notification will ignore it and will NOT repeat the authentication. In that case the original Responder will send a Delete notification for the IKE SA in an Informational exchange. Those implementations may be configured manually to repeat the authentication periodically.

Non-supporting Responders aren't a problem, because they'll just not send these notifications. In that case, there is no requirement that the original Initiator re-authenticate 🌈.

6. Security Considerations 🚨

⚠️ Read this part carefully, bestie, it's serious business 💀

The AUTH_LIFETIME notification sent by the Responder does NOT override any security policy on the Initiator. In particular, the Initiator may have a different policy about re-authentication, requiring it more often. Such an Initiator can repeat the authentication earlier than the notification requires.

An Initiator MAY set reasonable limits on the amount of time in the AUTH_LIFETIME notification. For example, an authentication lifetime of less than 300 seconds from SA initiation may be considered unreasonable 🙅‍♀️.

7. IANA Considerations 📋

IANA has assigned a notification payload type for the AUTH_LIFETIME notifications from the IKEv2 Notify Message Types registry 🦋.

8. Normative References 📚

[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

Author's Address 💌

Yoav Nir Check Point Software Technologies

EMail: ynir@checkpoint.com

Full Copyright Statement ©️

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🧠

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Acknowledgement 🌷

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).