| |
| |
| |
| |
| |
| |
| 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. |
| |
| 3. AUTH_LIFETIME Notification |
| |
| The AUTH_LIFETIME message is a notification payload formatted as |
| follows: |
| |
| 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 ! |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| o Payload Length is 12. |
| o Protocol ID (1 octet) MUST be 0. |
| o SPI size is 0 (SPI is in message header). |
| o Notify Message type is 16403 by IANA. |
| o 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. |
| |
| 4. Interoperability with Non-Supporting IKEv2 Implementations |
| |
| IKEv2 implementations that do not 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. Such implementations |
| may be configured manually to repeat the authentication periodically. |
| |
| |
| |
| |
| Nir Experimental [Page 3] |
| |
| RFC 4478 Repeated Authentication in IKEv2 April 2006 |
| |
| |
| Non-supporting Responders are not a problem because they will simply |
| not send these notifications. In that case, there is no requirement |
| that the original Initiator re-authenticate. |
| |
| 5. Security Considerations |
| |
| 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 regarding re-authentication, |
| requiring more frequent re-authentication. Such an Initiator can |
| repeat the authentication earlier then is required by the |
| notification. |
| |
| 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. |
| |
| 6. IANA Considerations |
| |
| The IANA has assigned a notification payload type for the |
| AUTH_LIFETIME notifications from the IKEv2 Notify Message Types |
| registry. |
| |
| 7. 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 |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Nir Experimental [Page 4] |
| |
| RFC 4478 Repeated Authentication in IKEv2 April 2006 |
| |
| |
| 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). |
| |
| |
| |
| |
| |
| |
| |
| Nir Experimental [Page 5] |
| |
