child-sa: Don't update outbound policies if they are not installed
[strongswan.git] / doc / standards / rfc4478.txt
1
2
3
4
5
6
7 Network Working Group                                             Y. Nir
8 Request for Comments: 4478                                   Check Point
9 Category: Experimental                                        April 2006
10
11
12    Repeated Authentication in Internet Key Exchange (IKEv2) Protocol
13
14 Status of This Memo
15
16    This memo defines an Experimental Protocol for the Internet
17    community.  It does not specify an Internet standard of any kind.
18    Discussion and suggestions for improvement are requested.
19    Distribution of this memo is unlimited.
20
21 Copyright Notice
22
23    Copyright (C) The Internet Society (2006).
24
25 Abstract
26
27    This document extends the Internet Key Exchange (IKEv2) Protocol
28    document [IKEv2].  With some IPsec peers, particularly in the remote
29    access scenario, it is desirable to repeat the mutual authentication
30    periodically.  The purpose of this is to limit the time that security
31    associations (SAs) can be used by a third party who has gained
32    control of the IPsec peer.  This document describes a mechanism to
33    perform this function.
34
35 1.  Introduction
36
37    In several cases, such as the remote access scenario, policy dictates
38    that the mutual authentication needs to be repeated periodically.
39    Repeated authentication can usually be achieved by simply repeating
40    the Initial exchange by whichever side has a stricter policy.
41
42    However, in the remote access scenario it is usually up to a human
43    user to supply the authentication credentials, and often Extensible
44    Authentication Protocol (EAP) is used for authentication, which makes
45    it unreasonable or impossible for the remote access gateway to
46    initiate the IKEv2 exchange.
47
48    This document describes a new notification that the original
49    Responder can send to the original Initiator with the number of
50    seconds before the authentication needs to be repeated.  The
51    Initiator SHOULD repeat the Initial exchange before that time is
52    expired.  If the Initiator fails to do so, the Responder may close
53    all Security Associations.
54
55
56
57
58 Nir                           Experimental                      [Page 1]
59 \f
60 RFC 4478            Repeated Authentication in IKEv2          April 2006
61
62
63    Repeated authentication is not the same as IKE SA rekeying, and need
64    not be tied to it.  The key words "MUST", "MUST NOT", "SHOULD",
65    "SHOULD NOT", and "MAY" in this document are to be interpreted as
66    described in [RFC2119].
67
68 2.  Authentication Lifetime
69
70    The Responder in an IKEv2 negotiation MAY be configured to limit the
71    time that an IKE SA and the associated IPsec SAs may be used before
72    the peer is required to repeat the authentication, through a new
73    Initial Exchange.
74
75    The Responder MUST send this information to the Initiator in an
76    AUTH_LIFETIME notification either in the last message of an IKE_AUTH
77    exchange, or in an INFORMATIONAL request, which may be sent at any
78    time.
79
80    When sent as part of the IKE SA setup, the AUTH_LIFETIME notification
81    is used as follows:
82
83       Initiator                            Responder
84       -------------------------------      -----------------------------
85       HDR, SAi1, KEi, Ni              -->
86                                       <--  HDR, SAr1, KEr, Nr, [CERTREQ]
87       HDR, SK {IDi, [CERT,] [CERTREQ,]
88          [IDr,] AUTH, SAi2, TSi, TSr} -->
89                                       <--  HDR, SK {IDr, [CERT,] AUTH,
90                                                     SAr2, TSi, TSr,
91                                                      N(AUTH_LIFETIME)}
92
93    The separate Informational exchange is formed as follows:
94
95                                       <--  HDR, SK {N(AUTH_LIFETIME)}
96       HDR  SK {}                      -->
97
98    The AUTH_LIFETIME notification is described in Section 3.
99
100    The original Responder that sends the AUTH_LIFETIME notification
101    SHOULD send a DELETE notification soon after the end of the lifetime
102    period, unless the IKE SA is deleted before the lifetime period
103    elapses.  If the IKE SA is rekeyed, then the time limit applies to
104    the new SA.
105
106    An Initiator that received an AUTH_LIFETIME notification SHOULD
107    repeat the Initial exchange within the time indicated in the
108    notification.  The time is measured from the time that the original
109    Initiator receives the notification.
110
111
112
113
114 Nir                           Experimental                      [Page 2]
115 \f
116 RFC 4478            Repeated Authentication in IKEv2          April 2006
117
118
119    A special case is where the notification is sent in an Informational
120    exchange, and the lifetime is zero.  In that case, the original
121    responder SHOULD allow a reasonable time for the repeated
122    authentication to occur.
123
124    The AUTH_LIFETIME notification MUST be protected and MAY be sent by
125    the original Responder at any time.  If the policy changes, the
126    original Responder MAY send it again in a new Informational.
127
128    The new Initial exchange is not altered.  The initiator SHOULD delete
129    the old IKE SA within a reasonable time of the new Auth exchange.
130
131 3.  AUTH_LIFETIME Notification
132
133    The AUTH_LIFETIME message is a notification payload formatted as
134    follows:
135
136                            1                   2                   3
137        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
138       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
139       ! Next Payload  !C!  RESERVED   !         Payload Length        !
140       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
141       !  Protocol ID  !   SPI Size    !      Notify Message Type      !
142       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
143       !                           Lifetime                            !
144       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
145
146       o  Payload Length is 12.
147       o  Protocol ID (1 octet) MUST be 0.
148       o  SPI size is 0 (SPI is in message header).
149       o  Notify Message type is 16403 by IANA.
150       o  Lifetime is the amount of time (in seconds) left before the
151          peer should repeat the Initial exchange.  A zero value
152          signifies that the Initial exchange should begin immediately.
153          It is usually not reasonable to set this value to less than 300
154          (5 minutes) since that is too cumbersome for a user.
155          It is also usually not reasonable to set this value to more
156          than 86400 (1 day) as that would negate the security benefit of
157          repeating the authentication.
158
159 4.  Interoperability with Non-Supporting IKEv2 Implementations
160
161    IKEv2 implementations that do not support the AUTH_LIFETIME
162    notification will ignore it and will not repeat the authentication.
163    In that case the original Responder will send a Delete notification
164    for the IKE SA in an Informational exchange.  Such implementations
165    may be configured manually to repeat the authentication periodically.
166
167
168
169
170 Nir                           Experimental                      [Page 3]
171 \f
172 RFC 4478            Repeated Authentication in IKEv2          April 2006
173
174
175    Non-supporting Responders are not a problem because they will simply
176    not send these notifications.  In that case, there is no requirement
177    that the original Initiator re-authenticate.
178
179 5.  Security Considerations
180
181    The AUTH_LIFETIME notification sent by the Responder does not
182    override any security policy on the Initiator.  In particular, the
183    Initiator may have a different policy regarding re-authentication,
184    requiring more frequent re-authentication.  Such an Initiator can
185    repeat the authentication earlier then is required by the
186    notification.
187
188    An Initiator MAY set reasonable limits on the amount of time in the
189    AUTH_LIFETIME notification.  For example, an authentication lifetime
190    of less than 300 seconds from SA initiation may be considered
191    unreasonable.
192
193 6.  IANA Considerations
194
195    The IANA has assigned a notification payload type for the
196    AUTH_LIFETIME notifications from the IKEv2 Notify Message Types
197    registry.
198
199 7.  Normative References
200
201    [IKEv2]    Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
202               4306, December 2005.
203
204    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
205               Requirement Levels", BCP 14, RFC 2119, March 1997.
206
207 Author's Address
208
209    Yoav Nir
210    Check Point Software Technologies
211
212    EMail: ynir@checkpoint.com
213
214
215
216
217
218
219
220
221
222
223
224
225
226 Nir                           Experimental                      [Page 4]
227 \f
228 RFC 4478            Repeated Authentication in IKEv2          April 2006
229
230
231 Full Copyright Statement
232
233    Copyright (C) The Internet Society (2006).
234
235    This document is subject to the rights, licenses and restrictions
236    contained in BCP 78, and except as set forth therein, the authors
237    retain all their rights.
238
239    This document and the information contained herein are provided on an
240    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
241    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
242    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
243    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
244    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
245    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
246
247 Intellectual Property
248
249    The IETF takes no position regarding the validity or scope of any
250    Intellectual Property Rights or other rights that might be claimed to
251    pertain to the implementation or use of the technology described in
252    this document or the extent to which any license under such rights
253    might or might not be available; nor does it represent that it has
254    made any independent effort to identify any such rights.  Information
255    on the procedures with respect to rights in RFC documents can be
256    found in BCP 78 and BCP 79.
257
258    Copies of IPR disclosures made to the IETF Secretariat and any
259    assurances of licenses to be made available, or the result of an
260    attempt made to obtain a general license or permission for the use of
261    such proprietary rights by implementers or users of this
262    specification can be obtained from the IETF on-line IPR repository at
263    http://www.ietf.org/ipr.
264
265    The IETF invites any interested party to bring to its attention any
266    copyrights, patents or patent applications, or other proprietary
267    rights that may cover technology that may be required to implement
268    this standard.  Please address the information to the IETF at
269    ietf-ipr@ietf.org.
270
271 Acknowledgement
272
273    Funding for the RFC Editor function is provided by the IETF
274    Administrative Support Activity (IASA).
275
276
277
278
279
280
281
282 Nir                           Experimental                      [Page 5]
283 \f