[要約] RFC 4478は、IKEv2プロトコルにおける繰り返し認証の問題を解決するための仕様です。目的は、IKEv2セッションのセキュリティを向上させ、認証の効率を改善することです。
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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
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.
このドキュメントは、インターネットキーエクスチェンジ（IKEV2）プロトコルドキュメント[IKEV2]を拡張します。一部のIPSECピア、特にリモートアクセスシナリオでは、定期的に相互認証を繰り返すことが望ましいです。これの目的は、セキュリティ協会（SAS）が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.
このドキュメントでは、元のレスポンダーが認証を繰り返す必要がある秒数で元のイニシエーターに送信できるという新しい通知について説明します。イニシエーターは、その時間が切れる前に最初の交換を繰り返す必要があります。イニシエーターがそうしなかった場合、レスポンダーはすべてのセキュリティ協会を閉鎖する可能性があります。
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 Rekeyingと同じではなく、それに結び付けられる必要はありません。このドキュメントの「必須」、「そうでない」、「そうでなければならない」、「すべきではない」、「そうでない」、「必要はない」は、[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 SASが使用される時間を制限するように構成される場合があります。
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.
Responderは、IKE_AUTH Exchangeの最後のメッセージ、またはいつでも送信される可能性のある情報リクエストのいずれかにおいて、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 {} -->
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.
auth_lifetime通知を送信する元のレスポンダーは、生涯の期間が経過する前に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_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通知は保護する必要があり、いつでも元のレスポンダーが送信することができます。ポリシーが変更された場合、元のレスポンダーは新しい情報に再び送信する場合があります。
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オクテット）は0でなければなりません。OSPIサイズは0（SPIはメッセージヘッダーにあります）。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.
Responderによって送信された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] Kaufman、C。、「Internet Key Exchange（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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
Author's Address
著者の連絡先
Yoav Nir Check Point Software Technologies
YoAV NIRチェックポイントソフトウェアテクノロジー
EMail: ynir@checkpoint.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
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.
この文書は、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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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）によって提供されます。