idnits 2.17.00 (12 Aug 2021) /tmp/idnits51485/draft-nir-ikev2-auth-lt-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 195. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** There is 1 instance of lines with control characters in the document. ** The abstract seems to contain references ([IKEv2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 9, 2006) is 5969 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'CERTREQ' is mentioned on line 80, but not defined ** Obsolete normative reference: RFC 4306 (ref. 'IKEv2') (Obsoleted by RFC 5996) Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Yoav Nir 2 draft-nir-ikev2-auth-lt-05.txt Check Point 3 Expires: July 2006 4 Intended status: Informational January 9, 2006 6 Repeated Authentication in IKEv2 8 Status of this Memo 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware have 12 been or will be disclosed, and any of which he or she becomes aware 13 will be disclosed, in accordance with Section 6 of BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/1id-abstracts.html 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 Abstract 32 This document extends the IKEv2 document [IKEv2]. With some IPsec 33 peers, particularly in the remote access scenario, it is desirable to 34 repeat the mutual authentication periodically. The purpose of this is 35 to limit the time that SAs can be used by a third party who has gained 36 control of the IPsec peer. This document describes a mechanism 37 to perform this function. 39 1. Introduction 41 In several cases, such as the remote access scenario, policy dictates 42 that the mututal authentication needs to be repeated periodically. 43 Repeated authentication can usually be achieved by simply repeating 44 the Initial exchange by whichever side has a stricter policy. 46 However, in the remote access scenario it is usually up to a human 47 user to supply the authentication credentials, and often EAP is used 48 for authentication, which makes it unreasonable or impossible for the 49 remote access gateway to initiate the IKEv2 exchange. 51 This document describes a new notification that the original Responder 52 can send to the original Initiator with the number of seconds before 53 the authentication needs to be repeated. The Initiator SHOULD repeat 54 the Initial exchange before that time is expired. If the Initiator 55 fails to do so, the Responder may close all Security Associations. 57 Repeated authentication is not the same as IKE SA rekeying, and need 58 not be tied to it.The key words "MUST", "MUST NOT", "SHOULD", 59 "SHOULD NOT", and "MAY" in this document are to be interpreted as 60 described in [RFC2119]. 62 2. Authentication Lifetime 64 The Responder in an IKEv2 negotiation MAY be configured to limit the 65 time that an IKE SA and the associated IPsec SAs may be used before 66 the peer is required to repeat the authentication, through a new 67 Initial Exchange. 69 The Responder MUST send this information to the Initiator in an 70 AUTH_LIFETIME notification either in the last message of an IKE_AUTH 71 exchange, or in an INFORMATIONAL request, which may be sent at any 72 time. 74 When sent as part of the IKE SA setup, the AUTH_LIFETIME notification 75 is used as follows: 77 Initiator Responder 78 ------------------------------- ----------------------------- 79 HDR, SAi1, KEi, Ni --> 80 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 81 HDR, SK {IDi, [CERT,] [CERTREQ,] 82 [IDr,] AUTH, SAi2, TSi, TSr} --> 83 <-- HDR, SK {IDr, [CERT,] AUTH, 84 SAr2, TSi, TSr, 85 N(AUTH_LIFETIME)} 87 The separate Informational exchange is formed as follows: 89 <-- HDR, SK {N(AUTH_LIFETIME)} 90 HDR SK {} --> 92 The AUTH_LIFETIME notification is described in section 3. 94 The original Responder that sends the AUTH_LIFETIME notification SHOULD 95 send a DELETE notification soon after the end of the lifetime period, 96 unless the IKE SA is deleted before the lifetime period elapses. If 97 the IKE SA is rekeyed, then the time limit applies to the new SA. 99 An Initiator that received an AUTH_LIFETIME notification SHOULD repeat 100 the Initial exchange within the time indicated in the notification. The 101 time is measured from the time that the original Initiator receives the 102 notification. 104 A special case is where the notification is sent in an Informational 105 exchange, and the lifetime is zero. In that case the original responder 106 SHOULD allow a reasonable time for the repeated authentication to occur. 108 The AUTH_LIFETIME notification MUST be protected and MAY be 109 sent by the original Responder at any time. If the policy changes, the 110 original Responder MAY send it again in a new Informational. 112 The new Initial exchange is not altered. The initiator SHOULD delete 113 the old IKE SA within a reasonable time of the new Auth exchange. 115 3. AUTH_LIFETIME Notification 117 The AUTH_LIFETIME message is a notification payload formatted as follows: 119 1 2 3 120 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 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 ! Next Payload !C! RESERVED ! Payload Length ! 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 ! Protocol ID ! SPI Size ! Notify Message Type ! 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 ! Lifetime ! 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 o Payload Length is 12. 130 o Protocol ID (1 octet) MUST be 0. 131 o SPI size is 0 (SPI is in message header). 132 o Notify Message type is TBA by IANA 133 o Lifetime is the amount of time in seconds left before the peer 134 should repeat the Initial exchange. A zero value signifies 135 that the Initial exchange should begin immediately. 136 It is usually not reasonable to set this value to less than 300 137 (5 minutes) since that is too cumbersome for a user. 138 It is also usually not reasonable to set this value to more than 139 86400 (1 day) as that would negate the security benefit of 140 repeating the authentication. 142 4. Interoperability with non-supporting IKEv2 implementations 144 IKEv2 implementations that do not support the AUTH_LIFETIME 145 notification will ignore it and will not repeat the authentication. In 146 that case the original Responder will send a Delete notification for 147 the IKE SA in an Informational exchange. Such implementations may 148 be configured manually to repeat the authentication periodically. 150 Non-supporting Responders are not a problem, because they will simply 151 not send these notifications. In that case, there is no requirement 152 that the original Initiator re-authenticate. 154 5. Security Considerations 156 The AUTH_LIFETIME notification sent by the Responder does not override 157 any security policy on the Initiator. In particular, the Initiator may 158 have a different policy regarding re-authentication, requiring more 159 frequent re-authentication. Such an Initiator can repeat the 160 authentication earlier then is required by the notification. 162 An Initiator MAY set reasonable limits on the amount of time in the 163 AUTH_LIFETIME notification. For example, an authentication lifetime of 164 less than 300 seconds from SA initiation may be considered unreasonable. 166 6. Normative References 168 [IKEv2] C. Kaufman, "Internet Key Exchange (IKEv2) Protocol", 169 RFC 4306, 2005. 170 [RFC2119] S. Bradner, "RFC2119 Key words for use in RFCs to Indicate 171 Requirement Levels.", RFC2119, 1997 173 7. IANA Considerations 175 IANA is asked to assign a notification payload type for the 176 AUTH_LIFETIME notifications from the IKEv2 Notify Message Types 177 registry. This should be from the STATUS TYPES range. 179 8. Author's address 181 Yoav Nir 182 Check Point Software Technologies 183 ynir@checkpoint.com 185 Copyright (C) The Internet Society (2006). This document is subject 186 to the rights, licenses and restrictions contained in BCP 78, and 187 except as set forth therein, the authors retain all their rights. 189 This document and the information contained herein are provided on an 190 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 191 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 192 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 193 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 194 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 195 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.