Network Working Group Y. Nir
Request for Comments: 4478 Check Point
Category: Experimental April 2006
Network Working Group Y. Nir
Request for Comments: 4478 Check Point
Category: Experimental April 2006
Repeated Authentication in Internet Key Exchange (IKEv2) Protocol
Internet密钥交换（IKEv2）协议中的重复认证
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).
版权所有（C）互联网协会（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.
本文档扩展了Internet密钥交换（IKEv2）协议文档[IKEv2]。对于某些IPsec对等点，特别是在远程访问场景中，希望定期重复相互身份验证。这样做的目的是限制获得IPsec对等方控制权的第三方可以使用安全关联（SA）的时间。本文档描述了执行此功能的机制。
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.
然而，在远程访问场景中，通常由人类用户提供身份验证凭据，并且通常使用可扩展身份验证协议（EAP）进行身份验证，这使得远程访问网关不合理或不可能启动IKEv2交换。
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.
本文档描述了原始响应者可以向原始启动器发送的新通知，通知的秒数为需要重复验证之前的秒数。发起方应在该时间到期之前重复初始交换。如果发起方未能这样做，响应方可能会关闭所有安全关联。
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].
重复身份验证与IKE SA密钥更新不同，不需要与之绑定。本文件中的关键词“必须”、“不得”、“应该”、“不应该”和“可能”应按照[RFC2119]中所述进行解释。
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.
IKEv2协商中的响应者可被配置为在对等方被要求通过新的初始交换重复认证之前限制IKE SA和相关联的IPsec SA可被使用的时间。
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.
响应者必须在IKE_身份验证交换的最后一条消息中，或在可能随时发送的信息请求中，以身份验证生存期通知的形式将此信息发送给启动器。
When sent as part of the IKE SA setup, the AUTH_LIFETIME notification is used as follows:
当作为IKE SA设置的一部分发送时，将按如下方式使用AUTH_生存期通知：
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)}
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 {} -->
<-- HDR, SK {N(AUTH_LIFETIME)}
HDR SK {} -->
The AUTH_LIFETIME notification is described in Section 3.
AUTH_生存期通知在第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.
发送AUTH_生存期通知的原始响应程序应在生存期结束后立即发送删除通知，除非IKE SA在生存期结束前被删除。如果IKE SA被重新设置密钥，则时间限制适用于新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.
收到AUTH_生存期通知的启动器应在通知中指示的时间内重复初始交换。时间从原始启动器收到通知的时间开始计算。
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.
新的初始交换没有改变。发起方应在新身份验证交换的合理时间内删除旧的IKE SA。
The AUTH_LIFETIME message is a notification payload formatted as follows:
AUTH_生存期消息是一个通知有效负载，其格式如下：
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
o 有效载荷长度为12。o协议ID（1个八位字节）必须为0。o SPI大小为0（SPI位于消息头中）。o IANA的通知消息类型为16403。o Lifetime是对等方重复初始交换之前剩余的时间量（以秒为单位）。零值表示初始交换应立即开始。将该值设置为小于300（5分钟）通常是不合理的，因为这对用户来说太麻烦了。将该值设置为86400（1天）以上通常也是不合理的，因为这将否定重复身份验证的安全好处。
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.
不支持AUTH_生存期通知的IKEv2实现将忽略它，并且不会重复身份验证。在这种情况下，原始响应程序将在信息交换中为IKE SA发送删除通知。可以手动配置这些实现以周期性地重复认证。
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.
不支持响应者不是问题，因为他们根本不会发送这些通知。在这种情况下，不需要原始启动器重新进行身份验证。
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.
响应程序发送的AUTH_生存期通知不会覆盖启动器上的任何安全策略。具体而言，发起方可能具有关于重新认证的不同策略，需要更频繁的重新认证。这样的启动器可以在通知要求之前重复身份验证。
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.
发起者可以对身份验证生存期通知中的时间量设置合理的限制。例如，从SA启动开始小于300秒的认证生存期可能被认为是不合理的。
The IANA has assigned a notification payload type for the AUTH_LIFETIME notifications from the IKEv2 Notify Message Types registry.
IANA已从IKEv2 Notify Message Types注册表为AUTH_生存期通知分配了通知有效负载类型。
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKEv2]Kaufman，C.，“互联网密钥交换（IKEv2）协议”，RFC4306，2005年12月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
Author's Address
作者地址
Yoav Nir Check Point Software Technologies
Yoav Nir检查点软件技术
EMail: ynir@checkpoint.com
EMail: ynir@checkpoint.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。