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

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 05

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

   Repeated Authentication in Internet Key Exchange (IKEv2) Protocol

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

Abstract

   This document extends the Internet Key Exchange (IKEv2) Protocol
   document [IKEv2].  With some IPsec peers, particularly in the remote
   access scenario, it is desirable to repeat the mutual authentication
   periodically.  The purpose of this is to limit the time that security
   associations (SAs) can be used by a third party who has gained
   control of the IPsec peer.  This document describes a mechanism to
   perform this function.

1.  Introduction

   In several cases, such as the remote access scenario, policy dictates
   that the mutual authentication needs to be repeated periodically.
   Repeated authentication can usually be achieved by simply repeating
   the Initial exchange by whichever side has a stricter policy.

   However, in the remote access scenario it is usually up to a human
   user to supply the authentication credentials, and often Extensible
   Authentication Protocol (EAP) is used for authentication, which makes
   it unreasonable or impossible for the remote access gateway to
   initiate the IKEv2 exchange.

   This document describes a new notification that the original
   Responder can send to the original Initiator with the number of
   seconds before the authentication needs to be repeated.  The
   Initiator SHOULD repeat the Initial exchange before that time is
   expired.  If the Initiator fails to do so, the Responder may close
   all Security Associations.

Nir                           Experimental                      [Page 1]
RFC 4478            Repeated Authentication in IKEv2          April 2006

   Repeated authentication is not the same as IKE SA rekeying, and need
   not 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].

2.  Authentication Lifetime

   The Responder in an IKEv2 negotiation MAY be configured to limit the
   time that an IKE SA and the associated IPsec SAs may be used before
   the peer is required to repeat the authentication, through a new
   Initial Exchange.

   The Responder MUST send this information 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 sent as part of the IKE SA setup, the AUTH_LIFETIME notification
   is used as follows:

      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 is formed as follows:

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

   The AUTH_LIFETIME notification is described in Section 3.

   The original Responder that sends the AUTH_LIFETIME notification
   SHOULD send a DELETE notification soon after the end of the lifetime
   period, unless the IKE SA is deleted before the lifetime period
   elapses.  If the IKE SA is rekeyed, then the time limit applies to
   the new SA.

   An Initiator that received an AUTH_LIFETIME notification SHOULD
   repeat the Initial exchange within the time indicated in the
   notification.  The time is measured from the time that the original
   Initiator receives the notification.

Nir                           Experimental                      [Page 2]
RFC 4478            Repeated Authentication in IKEv2          April 2006

   A special case is where the notification is sent in an Informational
   exchange, and the lifetime is zero.  In that case, the original
   responder SHOULD allow a reasonable time for the repeated
   authentication to occur.

   The AUTH_LIFETIME notification MUST be protected and MAY be sent by
   the original Responder 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.