]>
Commit | Line | Data |
---|---|---|
f91513e3 MW |
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 |