Network Working Group Y. Nir
Request for Comments: 4478 Check Point
Category: Experimental April 2006
Repeated Authentication in Internet Key Exchange (IKEv2) Protocol
インターネットキーエクスチェンジ（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.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
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.
この文書は、インターネット鍵交換（IKEv2の）プロトコルドキュメント[IKEv2の]を拡張します。いくつかのIPsecピアでは、特にリモートアクセスのシナリオでは、定期的に相互認証を繰り返すことが望ましいです。この目的は、セキュリティアソシエーション（SA）がIPsecピアのコントロールを得ている第三者が使用することができる時間を制限することです。この文書では、この機能を実行するためのメカニズムを説明しています。
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.
この文書では、認証が繰り返される必要がある前に、元Responderは秒数を元イニシエータに送信することができ、新たな通知を説明しています。その時間が満了する前に、イニシエータは、初期交換を繰り返す必要があります。イニシエータがそうしなかった場合、Responderは、すべてのセキュリティアソシエーションを閉じることができます。
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]に記載されているようにキーワード "MUST" は、 "MUST NOT"、 "SHOULD NOT"、および本書で解釈されるべきである、 "MAY"、 "SHOULD"。
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の交渉でResponderは、ピアが新しい初期交換により、認証を繰り返す必要になる前に、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_AUTH交換の最後のメッセージで、または任意の時点で送信されてもよいINFORMATIONAL要求、のいずれかAUTH_LIFETIME通知にイニシエータにこの情報を送信しなければなりません。
When sent as part of the IKE SA setup, the AUTH_LIFETIME notification is used as follows:
IKE SAのセットアップの一部として送信すると、以下のように、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_LIFETIME通知はセクション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.
IKE SAが経過寿命期間前に削除されない限りAUTH_LIFETIME通知を送信元Responderは、まもなく寿命期間の終了後にDELETE通知を送信すべきです。 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_LIFETIME通知を受信したイニシエータは、通知に示された時間内の初期交換を繰り返す必要があります。時間は、元のイニシエータが通知を受信した時点から測定されます。
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.
AUTH_LIFETIME通知は保護されなければならない、いつでも元レスポンダによって送信されるかもしれません。ポリシーが変更された場合、オリジナルのResponderは新しい情報で再びそれを送るかもしれません。
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_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つのオクテット）（SPIがメッセージヘッダにある）0 O SPIサイズが0でなければなりません。 OメッセージタイプがIANAによって16403で通知します。 O寿命は初期交換を繰り返す必要があり、ピアまでの残り時間（秒単位）です。ゼロ値は、初期の交換がすぐに開始すべきであることを意味します。それがユーザにとってあまりにも煩雑であるので、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_LIFETIME通知をサポートしていないの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_LIFETIME通知は、イニシエータ上の任意のセキュリティポリシーを上書きしません。具体的には、イニシエータは、より頻繁な再認証を必要とする、再認証に関して異なるポリシーを有することができます。このようなイニシエータは、以前、通知によって必要とされる認証を繰り返すことができます。
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.
イニシエータはAUTH_LIFETIME通知の時間の量に合理的な制限を設定することができます。例えば、SA開始から300秒未満の認証寿命は不合理と考えることができます。
The IANA has assigned a notification payload type for the AUTH_LIFETIME notifications from the IKEv2 Notify Message Types registry.
IANAは、メッセージタイプレジストリに通知のIKEv2からAUTH_LIFETIME通知の通知ペイロードタイプが割り当てられています。
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKEv2の]カウフマン、C.、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
Author's Address
著者のアドレス
Yoav Nir Check Point Software Technologies
ヨアフニールチェック・ポイント・ソフトウェア・テクノロジーズ
EMail: ynir@checkpoint.com
メールアドレス：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。