RFC4478 日本語訳

Network Working Group                                             Y. Nir
Request for Comments: 4478                                   Check Point
Category: Experimental                                        April 2006

コメントを求めるワーキンググループY.ニールの要求をネットワークでつないでください: 4478年の検査点カテゴリ: 実験的な2006年4月

   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).

Copyright(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同輩と、特に遠隔アクセスのシナリオでは、定期的に互いの認証を繰り返すのは望ましいです。 この目的はIPsec同輩のコントロールを獲得した第三者がセキュリティ協会(SAs)を使用できる時間を制限することです。 このドキュメントは、この機能を実行するためにメカニズムについて説明します。

1.  Introduction

1. 序論

   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.

遠隔アクセスのシナリオなどのいくつかの場合では、方針は、互いの認証が、定期的に繰り返される必要であると決めます。 通常、より厳しい方針を持っているどの側のそばで単にInitial交換を繰り返すかによって、繰り返された認証を達成できます。

   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が秒数と共にオリジナルのInitiatorに発信できるという新しい通知について説明します。 その時が満期になる前にInitiator SHOULDはInitial交換を繰り返します。 Initiatorがそうしないなら、ResponderはすべてのSecurity Associationsを閉じるかもしれません。

Nir                           Experimental                      [Page 1]

RFC 4478            Repeated Authentication in IKEv2          April 2006

ニール実験的な[1ページ]RFC4478は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].

繰り返された認証は、IKE SA rekeyingと同じでなく、それに結ばれる必要はありません。 キーワード“MUST"、「必須NOT」“SHOULD"、「」 「5月」は中[RFC2119]で説明されるように本書では解釈されることになっているべきです。

2.  Authentication Lifetime

2. 認証生涯

   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 SAsが使用されるかもしれない時間を制限するために構成されるかもしれません、新しい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.

Responderはイケ_AUTH交換に関する最後のメッセージ、またはいつでも送られるかもしれないINFORMATIONAL要求におけるAUTH_LIFETIME通知におけるInitiatorにこの情報を送らなければなりません。

   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)}

創始者応答者------------------------------- ----------------------------- Ni--><--HDR、SAi1、KEi、HDR、SAr1、KEr、Nr、[CERTREQ]HDR、SK、IDi、AUTH、SAi2、TSi、[本命][CERTREQ][IDr]TSr--><--HDR、SKIDr、AUTH、SAr2、TSi、TSr、[本命]N(AUTH_生涯)

   The separate Informational exchange is formed as follows:

別々のInformational交換は以下の通り形成されます:

                                      <--  HDR, SK {N(AUTH_LIFETIME)}
      HDR  SK {}                      -->

<--、HDR、SK N(AUTH_生涯)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通知SHOULDを送るオリジナルのResponderは生涯の期間の終わりのすぐ後にDELETE通知を送ります、生涯の期間が経過する前に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.

時中にInitial交換が通知で示したAUTH_LIFETIME通知SHOULD反復を受けたInitiator。 時間はオリジナルのInitiatorが通知を受け取る時間から測定されます。

Nir                           Experimental                      [Page 2]

RFC 4478            Repeated Authentication in IKEv2          April 2006

ニール実験的な[2ページ]RFC4478は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.

特別なケースは通知がInformational交換で送られるところです、そして、寿命はゼロです。 その場合、オリジナルの応答者SHOULDは繰り返された認証が起こる妥当な時間を許容します。

   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によって送られるかもしれません。 方針が変化するなら、オリジナルのResponderは再び新しい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.

新しいInitial交換は変更されません。 創始者SHOULDは新しいAuth交換の妥当な時以内に古いIKE SAを削除します。

3.  AUTH_LIFETIME Notification

3. AUTH_生涯通知

   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                            !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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、+++++++++++++++++++++++++++++++++! 次の有効搭載量!C! 予約されました!

      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 有効搭載量Lengthはo SPIサイズが0(SPIがメッセージヘッダーにある)であるということです。12 ○ Protocol ID(1つの八重奏)は0であるに違いありません。o Notify MessageタイプはIANAによる16403です。同輩がInitial交換を繰り返すべき前にo Lifetimeが時間(秒の)であることは残っています。 ゼロは、Initial交換がすぐに始まるべきであるのを意味するのを評価します。 ユーザには、それが厄介過ぎるので、通常、300(5分)未満にこの値を設定するのは妥当ではありません。 それは認証を繰り返すセキュリティ利益を否定するでしょう、また、したがって、通常、86400(1日)以上にこの値を設定するのも妥当ではありません。

4.  Interoperability with Non-Supporting IKEv2 Implementations

4. 非サポートIKEv2実現がある相互運用性

   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実現が、それを無視して、認証を繰り返さないでしょう。 その場合、オリジナルのResponderはInformational交換でIKE SAのためのDelete通知を送るでしょう。 そのような実現は、定期的に認証を繰り返すために手動で構成されるかもしれません。

Nir                           Experimental                      [Page 3]

RFC 4478            Repeated Authentication in IKEv2          April 2006

ニール実験的な[3ページ]RFC4478は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.

彼らがこれらの通知を絶対に送らないので、非サポートRespondersは問題ではありません。 その場合、オリジナルのInitiatorが再認証する要件が全くありません。

5.  Security Considerations

5. セキュリティ問題

   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通知はInitiatorの上のどんな安全保障政策もくつがえしません。 より頻繁な再認証を必要として、Initiatorには特に、再認証に関する異なった方針があるかもしれません。 そのようなInitiatorはその時、より早く認証を繰り返すことができます。通知で、必要です。

   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.

InitiatorはAUTH_LIFETIME通知に時間における妥当な限界を設定するかもしれません。 例えば、SA開始から300秒未満の認証寿命は無理であると考えられるかもしれません。

6.  IANA Considerations

6. IANA問題

   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_LIFETIME通知のための通知ペイロードタイプを選任しました。

7.  Normative References

7. 引用規格

   [IKEv2]    Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
              4306, December 2005.

[IKEv2] コーフマン、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] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

Author's Address

作者のアドレス

   Yoav Nir
   Check Point Software Technologies

Yoavニール検査点ソフトウェア技術

   EMail: ynir@checkpoint.com

メール: ynir@checkpoint.com

Nir                           Experimental                      [Page 4]

RFC 4478            Repeated Authentication in IKEv2          April 2006

ニール実験的な[4ページ]RFC4478はIKEv2 April 2006で認証を繰り返しました。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2006).

Copyright(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。

Nir                           Experimental                      [Page 5]

ニールExperimentalです。[5ページ]