RFC4739 日本語訳

Network Working Group                                          P. Eronen
Request for Comments: 4739                                         Nokia
Category: Experimental                                       J. Korhonen
                                                             TeliaSonera
                                                           November 2006

Eronenがコメントのために要求するワーキンググループP.をネットワークでつないでください: 4739年のノキアカテゴリ: 実験的なJ.Korhonen TeliaSonera2006年11月

                   Multiple Authentication Exchanges
             in the 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 IETF Trust (2006).

IETFが信じる著作権(C)(2006)。

Abstract

要約

   The Internet Key Exchange (IKEv2) protocol supports several
   mechanisms for authenticating the parties, including signatures with
   public-key certificates, shared secrets, and Extensible
   Authentication Protocol (EAP) methods.  Currently, each endpoint uses
   only one of these mechanisms to authenticate itself.  This document
   specifies an extension to IKEv2 that allows the use of multiple
   authentication exchanges, using either different mechanisms or the
   same mechanism.  This extension allows, for instance, performing
   certificate-based authentication of the client host followed by an
   EAP authentication of the user.  When backend authentication servers
   are used, they can belong to different administrative domains, such
   as the network access provider and the service provider.

インターネット・キー・エクスチェンジ(IKEv2)プロトコルはパーティーを認証するために数個のメカニズムをサポートします、公開鍵証明書、共有秘密キー、および拡張認証プロトコル(EAP)メソッドがある署名を含んでいて。 現在、各終点は、それ自体を認証するのにこれらのメカニズムの1つだけを使用します。 このドキュメントは複数の認証交換の使用を許すIKEv2に拡大を指定します、異なったメカニズムかメカニズムのどちらかを同じの使用して。 例えば、この拡大で、ユーザのEAP認証があとに続いたクライアントホストの証明書ベースの認証を実行します。 バックエンド認証サーバが使用されているとき、異なった管理ドメインに属すことができます、ネットワークアクセスプロバイダやサービスプロバイダーのように。

Eronen & Korhonen             Experimental                      [Page 1]

RFC 4739           Multiple Auth. Exchanges in IKEv2       November 2006

Eronen&Korhonenの実験的な[1ページ]RFC4739倍数Auth。 IKEv2 November 2006の交換

Table of Contents

目次

   1. Introduction ....................................................3
      1.1. Usage Scenarios ............................................4
      1.2. Terminology ................................................5
   2. Solution ........................................................5
      2.1. Solution Overview ..........................................5
      2.2. Example 1: Multiple EAP Authentications ....................6
      2.3. Example 2: Mixed EAP and Certificate Authentications .......7
      2.4. Example 3: Multiple Initiator Certificates .................8
      2.5. Example 4: Multiple Responder Certificates .................8
   3. Payload Formats .................................................9
      3.1. MULTIPLE_AUTH_SUPPORTED Notify Payload .....................9
      3.2. ANOTHER_AUTH_FOLLOWS Notify Payload ........................9
   4. IANA Considerations .............................................9
   5. Security Considerations .........................................9
   6. Acknowledgments ................................................10
   7. References .....................................................10
      7.1. Normative References ......................................10
      7.2. Informative References ....................................10

1. 序論…3 1.1. 用法シナリオ…4 1.2. 用語…5 2. ソリューション…5 2.1. ソリューション概要…5 2.2. 例1: 複数のEAP認証…6 2.3. 例2: Mixed EAPと証明書認証…7 2.4. 例3: 複数の創始者証明書…8 2.5. 例4: 複数の応答者証明書…8 3. 有効搭載量形式…9 3.1. _がサポートした倍数_AUTHは有効搭載量に通知します…9 3.2. AUTH_が続く別の_は有効搭載量に通知します…9 4. IANA問題…9 5. セキュリティ問題…9 6. 承認…10 7. 参照…10 7.1. 標準の参照…10 7.2. 有益な参照…10

Eronen & Korhonen             Experimental                      [Page 2]

RFC 4739           Multiple Auth. Exchanges in IKEv2       November 2006

Eronen&Korhonenの実験的な[2ページ]RFC4739倍数Auth。 IKEv2 November 2006の交換

1.  Introduction

1. 序論

   IKEv2 [IKEv2] supports several mechanisms for parties involved in the
   IKE_SA (IKE security association).  These include signatures with
   public-key certificates, shared secrets, and Extensible
   Authentication Protocol (EAP) methods.

IKEv2[IKEv2]はIKE_SA(IKEセキュリティ協会)にかかわるパーティーのために数個のメカニズムをサポートします。 これらは公開鍵証明書、共有秘密キー、および拡張認証プロトコル(EAP)メソッドがある署名を含んでいます。

   Currently, each endpoint uses only one of these mechanisms to
   authenticate itself.  However, there are scenarios where making the
   authorization decision in IKEv2 (whether to allow access or not)
   requires using several of these methods.

現在、各終点は、それ自体を認証するのにこれらのメカニズムの1つだけを使用します。 しかしながら、シナリオがIKEv2での承認決定をするところにある、(アクセスを許すかどうか、)、数個を使用するのをこれらのメソッドを要求します。

   For instance, it may be necessary to authenticate both the host
   (machine) requesting access, and the user currently using the host.
   These two authentications would use two separate sets of credentials
   (such as certificates and associated private keys) and might even use
   different authentication mechanisms.

例えば、現在アクセスを要求するホスト(マシン)とユーザの両方を認証するのが、ホストを使用することで必要であるかもしれません。 これらの2つの認証が、別々の2セットの資格証明書(証明書や関連秘密鍵などの)を使用して、異なった認証機構を使用さえするかもしれません。

   To take another example, when an operator is hosting a Virtual
   Private Network (VPN) gateway service for a third party, it may be
   necessary to authenticate the client to both the operator (for
   billing purposes) and the third party's Authentication,
   Authorization, and Accounting (AAA) server (for authorizing access to
   the third party's internal network).

オペレータが第三者のためにVirtual兵士のNetwork(VPN)ゲートウェイサービスを接待しているとき、別の例を取るために、オペレータ(支払い目的のための)、第三者のAuthentication、Authorization、およびAccounting(AAA)サーバの両方(第三者の内部のネットワークへのアクセスを認可するための)にクライアントを認証するのが必要であるかもしれません。

   This document specifies an extension to IKEv2 that allows the use of
   multiple authentication exchanges, using either different mechanisms
   or the same mechanism.  This extension allows, for instance,
   performing certificate-based authentication of the client host
   followed by an EAP authentication of the user.

このドキュメントは複数の認証交換の使用を許すIKEv2に拡大を指定します、異なったメカニズムかメカニズムのどちらかを同じの使用して。 例えば、この拡大で、ユーザのEAP認証があとに続いたクライアントホストの証明書ベースの認証を実行します。

   Each authentication exchange requiring communication with backend AAA
   servers may be directed to different backend AAA servers, located
   even in different administrative domains.  However, details of the
   communication between the IKEv2 gateway and the backend
   authentication servers are beyond the scope of this document.  In
   particular, this document does not specify any changes to existing
   AAA protocols, and it does not require the use of any particular AAA
   protocol.

バックエンドAAAサーバとのコミュニケーションを必要とするそれぞれの認証交換は異なった管理ドメインにさえ位置する異なったバックエンドAAAサーバに向けられるかもしれません。 しかしながら、IKEv2ゲートウェイとバックエンド認証サーバとのコミュニケーションの詳細はこのドキュメントの範囲を超えています。 特に、このドキュメントは既存のAAAプロトコルへの少しの変化も指定しません、そして、それはどんな特定のAAAプロトコルの使用も必要としません。

   In case of several EAP authentications, it is important to notice
   that they are not a "sequence" (as described in Section 2.1 of
   [EAP]), but separate independent EAP conversations, which are usually
   also terminated in different EAP servers.  Multiple authentication
   methods within a single EAP conversation are still prohibited as
   described in Section 2.1 of [EAP].  Using multiple independent EAP
   conversations is similar to the separate Network Access Provider
   (NAP) and Internet Service Provider (ISP) authentication exchanges

いくつかのEAP認証の場合には、それらが「系列」([EAP]のセクション2.1で説明されるように)ではなく別々の独立しているEAPの会話であるのに気付くのは重要です。(また、通常、会話は異なったEAPサーバで終えられます)。 ただ一つのEAPの会話の中の複数の認証方法が[EAP]のセクション2.1で説明されるようにまだ禁止されています。 複数の独立しているEAPの会話を使用するのは別々のNetwork Access Provider(NAP)とインターネットサービスプロバイダ(ISP)認証交換と同様です。

Eronen & Korhonen             Experimental                      [Page 3]

RFC 4739           Multiple Auth. Exchanges in IKEv2       November 2006

Eronen&Korhonenの実験的な[3ページ]RFC4739倍数Auth。 IKEv2 November 2006の交換

   planned for [PANA].  The discovery of the appropriate EAP server for
   each EAP authentication conversation is based on AAA routing.

[パーナ]に計画されています。 それぞれのEAP認証の会話のための適切なEAPサーバの発見はAAAルーティングに基づいています。

1.1.  Usage Scenarios

1.1. 用法シナリオ

   Figure 1 shows an example architecture of an operator-hosted VPN
   scenario that could benefit from a two-phase authentication within
   the IKEv2 exchange.  First, the client authenticates towards the
   Network Access Provider (NAP) and gets access to the NAP-hosted VPN
   gateway.  The first-phase authentication involves the backend AAA
   server of the NAP.  After the first authentication, the client
   initiates the second authentication round that also involves the
   Third Party's backend AAA server.  If both authentications succeed,
   the required IPsec tunnels are set up and the client can access
   protected networks behind the Third Party.

図1はIKEv2交換の中で二相認証の利益を得ることができたオペレータによって接待されたVPNシナリオの例のアーキテクチャを示しています。 まず最初に、クライアントは、(NAP)をNetwork Access Providerに向かって認証して、NAPによって接待されたVPNゲートウェイに近づく手段を得ます。 第1段階認証はNAPのバックエンドAAAサーバにかかわります。 最初の認証の後に、クライアントはまた、ThirdパーティのバックエンドAAAサーバにかかわる2番目の認証ラウンドを開始します。両方の認証が成功するなら、必要なIPsecトンネルは設立されます、そして、クライアントはThirdパーティの後ろで保護されたネットワークにアクセスできます。

       Client                         *Network Access Provider*
     +---------+                    +---------+              +-----+
     |         |                    |  NAP's  |              | NAP |
     |Protected|     IPsec SAs      | Tunnel  | AAA Protocol | AAA |
     |Endpoint |<------------------>|Endpoint |<------------>|Serv/|
     |         |                    |         |              |Proxy|
     +---------+                    +---------+              +-----+
                                       ^                        ^
                            IPsec or  /                  AAA    |
                        Leased Line  /                 Protocol |
                                    /                           |
                                   v                            |
                           +---------+    *Third Party*         v
                           |3rd Party|                       +-----+
            Protected      | Tunnel  |                       | 3rd |
               Subnet <----|Endpoint |                       |Party|
                           |         |                       | AAA |
                           +---------+                       +-----+

クライアント*ネットワークアクセスプロバイダ*+---------+ +---------+ +-----+ | | | 仮眠のもの| | 仮眠| |保護されます。| IPsec SAs| トンネル| AAAプロトコル| AAA| |終点| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|終点| <、-、-、-、-、-、-、-、-、-、-、--、>|Serv/| | | | | |プロキシ| +---------+ +---------+ +-----+ ^ ^ IPsec or / AAA | 専用線/プロトコル| / | v| +---------+ 3番目の*パーティ*v|第3パーティ| +-----保護された+| トンネル| | 3番目| サブネット<。----|終点| |パーティ| | | | AAA| +---------+ +-----+

          Figure 1: Two-phase authentication used to gain access to
          the Third Party network via Network Access Provider.  AAA
          traffic goes through NAP's AAA server.

図1: 二相認証は以前はNetwork Access Providerを通してよくThirdパーティネットワークへのアクセスを得ていました。 AAAトラフィックはNAPのAAAサーバに直面しています。

   The NAP's AAA server can be used to proxy the AAA traffic to the
   Third Party's backend AAA server.  Alternatively, the AAA traffic
   from the NAP's tunnel endpoint could go directly to the Third Party's
   backend AAA servers.  However, this is more or less an AAA routing
   issue.

AAAが取引するプロキシに使用されて、ThirdパーティのバックエンドAAAサーバに. あるいはまた、NAPのトンネル終点からのAAAトラフィックは行くことができました。NAPのAAAサーバがそうであることができる、直接ThirdパーティのバックエンドAAAサーバに行ってください。 しかしながら、これはだいたいAAAルーティング問題です。

Eronen & Korhonen             Experimental                      [Page 4]

RFC 4739           Multiple Auth. Exchanges in IKEv2       November 2006

Eronen&Korhonenの実験的な[4ページ]RFC4739倍数Auth。 IKEv2 November 2006の交換

1.2.  Terminology

1.2. 用語

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [KEYWORDS].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[キーワード]で説明されるように本書では解釈されることであるべきですか?

   The terms and abbreviations "authenticator", "backend authentication
   server", "EAP server", and "peer" in this document are to be
   interpreted as described in [EAP].

用語と略語「固有識別文字」、「バックエンド認証サーバ」、「EAPサーバ」、およびこのドキュメントの「同輩」は[EAP]で説明されるように解釈されることになっています。

   When messages containing IKEv2 payloads are described, optional
   payloads are shown in brackets (for instance, "[FOO]"), and a plus
   sign indicates that a payload can be repeated one or more times (for
   instance, "FOO+").

IKEv2ペイロードを含むメッセージが説明されるとき、任意のペイロードは括弧(例えば、「[FOO]」)に示されます、そして、プラスサインは1回(例えば、「FOO+」)以上ペイロードを繰り返すことができるのを示します。

2.  Solution

2. ソリューション

2.1.  Solution Overview

2.1. ソリューション概要

   The peers announce support for this IKEv2 extension by including a
   MULTIPLE_AUTH_SUPPORTED notification in the IKE_SA_INIT response
   (responder) and the first IKE_AUTH request (initiator).

同輩は、イケ_SA_INIT応答(応答者)におけるMULTIPLE_AUTH_SUPPORTED通知と最初のイケ_AUTH要求(創始者)を含んでいることによって、このIKEv2拡張子のサポートを発表します。

   If both peers support this extension, either of them can announce
   that it wishes to have a second authentication by including an
   ANOTHER_AUTH_FOLLOWS notification in any IKE_AUTH message that
   contains an AUTH payload.  This indicates that the peer sending the
   ANOTHER_AUTH_FOLLOWS wishes to authenticate another set of
   credentials to the other peer.  The next IKE_AUTH message sent by
   this peer will contain a second identity payload (IDi or IDr) and
   starts another authentication exchange.  The IKE_AUTH phase is
   considered successful only if all the individual authentication
   exchanges complete successfully.

両方の同輩がこの拡大をサポートするなら、いずれか一方が、それには2番目の認証がAUTHペイロードを含むどんなイケ_AUTHメッセージにもANOTHER_AUTH_FOLLOWS通知を含んでいることによってありたいと発表できます。 これは、ANOTHER_AUTH_FOLLOWSを送る同輩がもう1セットの資格証明書をもう片方の同輩に認証したがっているのを示します。 この同輩によって送られた次のイケ_AUTHメッセージは、2番目のアイデンティティペイロード(IDiかIDr)を含んで、別の認証交換を始めます。 イケ_AUTHフェーズはすべての個々の認証交換である場合にだけうまくいくと考えられます。首尾よく、完成します。

   It is assumed that both peers know what credentials they want to
   present; there is no negotiation about, for instance, what type of
   authentication is to be done.  As in IKEv2, EAP-based authentication
   is always requested by the initiator (by omitting the AUTH payload).

両方の同輩が、それらがどんな資格証明書を提示したがっているかを知っていると思われます。 するかに関して例えば、どんなタイプの認証がことである交渉が全くありません。 IKEv2のように、EAPベースの認証はいつも創始者(AUTHペイロードを省略するのによる)によって要求されています。

   The AUTH payloads are calculated as specified in [IKEv2] Sections
   2.15 and 2.16, where IDi' refers to the latest IDi payload sent by
   the initiator, and IDr' refers to the latest IDr payload sent by the
   responder.  If EAP methods that do not generate shared keys are used,
   it is possible that several AUTH payloads with identical contents are
   sent.  When such EAP methods are used, the purpose of the AUTH
   payload is simply to delimit the authentication exchanges, and ensure
   that the IKE_SA_INIT request/response messages were not modified.

'AUTHペイロードはペイロードが応答者で送った最新のIDrが、IDiが'創始者、およびIDrによって送られた最新のIDiペイロードについて言及する'と言及するところで[IKEv2]セクション2.15と2.16で指定されるように計算されます。 共有されたキーを生成しないEAPメソッドが使用されているなら、同じコンテンツがある数個のAUTHペイロードを送るのは可能です。 そのようなEAPメソッドが使用されているとき、AUTHペイロードの目的は、単に認証交換を区切って、イケ_SA_INIT要求/応答メッセージが変更されなかったのを保証することです。

Eronen & Korhonen             Experimental                      [Page 5]

RFC 4739           Multiple Auth. Exchanges in IKEv2       November 2006

Eronen&Korhonenの実験的な[5ページ]RFC4739倍数Auth。 IKEv2 November 2006の交換

2.2.  Example 1: Multiple EAP Authentications

2.2. 例1: 複数のEAP認証

   This example shows certificate-based authentication of the responder
   followed by an EAP authentication exchange (messages 1-10).  When the
   first EAP exchange is ending (the initiator is sending its AUTH
   payload), the initiator announces that it wishes to have a second
   authentication exchange by including an ANOTHER_AUTH_FOLLOWS
   notification (message 9).

この例は、EAP認証交換(メッセージ1-10)で応答者の証明書ベースの認証が続いたのを示します。 最初のEAP交換が終わっているとき(創始者はAUTHペイロードを送ります)、創始者は、それには2番目の認証交換がANOTHER_AUTH_FOLLOWS通知(メッセージ9)を含んでいることによってありたいと発表します。

   After this, a second authentication exchange begins.  The initiator
   sends a new IDi payload but no AUTH payload (message 11), indicating
   that EAP will be used.  After that, another EAP authentication
   exchange follows (messages 12-18).

この後、2番目の認証交換は始まります。 新しいIDiペイロードを送りますが、EAPが使用されるのを示して、創始者はどんなAUTHペイロード(メッセージ11)も送りません。 その後に、別のEAP認証交換は(メッセージ12-18)に続いて起こります。

      Initiator                   Responder
     -----------                 -----------
      1. HDR, SA, KE, Ni -->
                             <--  2. HDR, SA, KE, Nr, [CERTREQ],
                                          N(MULTIPLE_AUTH_SUPPORTED)
      3. HDR, SK { IDi, [CERTREQ+], [IDr],
                   SA, TSi, TSr, N(MULTIPLE_AUTH_SUPPORTED) }  -->
                             <--  4. HDR, SK { IDr, [CERT+], AUTH,
                                               EAP(Request) }
      5. HDR, SK { EAP(Response) }  -->
                             <--  6. HDR, SK { EAP(Request) }
      7. HDR, SK { EAP(Response) }  -->
                             <--  8. HDR, SK { EAP(Success) }
      9. HDR, SK { AUTH,
                   N(ANOTHER_AUTH_FOLLOWS) }  -->
                             <--  10. HDR, SK { AUTH }
      11. HDR, SK { IDi }  -->
                             <--  12. HDR, SK { EAP(Request) }
      13. HDR, SK { EAP(Response) }  -->
                             <--  14. HDR, SK { EAP(Request) }
      15. HDR, SK { EAP(Response) }  -->
                             <--  16. HDR, SK { EAP(Success) }
      17. HDR, SK { AUTH }  -->
                             <--  18. HDR, SK { AUTH, SA, TSi, TSr }

創始者応答者----------- ----------- 1. Ni--><--HDR、SA、KE、2。 HDR、SA、KE、Nr、[CERTREQ]、N(AUTH_がサポートした複数の_)3。 HDR、SK、IDi、[CERTREQ+]、[IDr]、SA、TSi、TSr、N(AUTH_がサポートした複数の_)--><--4 HDR、SK、IDr、[本命+]、AUTH、EAP(要求する)、5 SK EAP(応答)--><--HDR、6。 HDR、SK EAP(要求する)7。 SK EAP(応答)--><--HDR、8。 HDR、SK EAP(成功)9。 HDR、SK、AUTH、N(AUTH_が続く別の_)--><--10 HDR、SK AUTH、11 SK IDi--><--HDR、12。 HDR、SK EAP(要求する)13。 SK EAP(応答)--><--HDR、14。 HDR、SK EAP(要求する)15。 SK EAP(応答)--><--HDR、16。 HDR、SK EAP(成功)17。 SK AUTH--><--HDR、18。 HDR、SKAUTH、SA、TSi、TSr

          Example 1: Certificate-based authentication of the
          responder, followed by two EAP authentication exchanges.

例1: 2回のEAP認証交換があとに続いた応答者の証明書ベースの認証。

Eronen & Korhonen             Experimental                      [Page 6]

RFC 4739           Multiple Auth. Exchanges in IKEv2       November 2006

Eronen&Korhonenの実験的な[6ページ]RFC4739倍数Auth。 IKEv2 November 2006の交換

2.3.  Example 2: Mixed EAP and Certificate Authentications

2.3. 例2: Mixed EAPと証明書認証

   Another example is shown below: here both the initiator and the
   responder are first authenticated using certificates (or shared
   secrets); this is followed by an EAP authentication exchange.

別の例は以下に示されます: ここで、創始者と応答者の両方が最初に、証明書(または、共有秘密キー)を使用することで認証されます。 EAP認証交換はこれのあとに続いています。

      Initiator                   Responder
     -----------                 -----------
      1. HDR, SA, KE, Ni -->
                             <--  2. HDR, SA, KE, Nr, [CERTREQ],
                                          N(MULTIPLE_AUTH_SUPPORTED)
      3. HDR, SK { IDi, [CERT+], [CERTREQ+], [IDr], AUTH,
                   SA, TSi, TSr, N(MULTIPLE_AUTH_SUPPORTED),
                   N(ANOTHER_AUTH_FOLLOWS) }  -->
                             <--  4. HDR, SK { IDr, [CERT+], AUTH }
      5. HDR, SK { IDi }  -->
                             <--  6. HDR, SK { EAP(Request) }
      7. HDR, SK { EAP(Response) }  -->
                             <--  8. HDR, SK { EAP(Request) }
      9. HDR, SK { EAP(Response) }  -->
                             <--  10. HDR, SK { EAP(Success) }
      11. HDR, SK { AUTH }  -->
                             <--  12. HDR, SK { AUTH, SA, TSi, TSr }

創始者応答者----------- ----------- 1. Ni--><--HDR、SA、KE、2。 HDR、SA、KE、Nr、[CERTREQ]、N(AUTH_がサポートした複数の_)3。 HDR、SK、IDi、[本命+]、[CERTREQ+]、[IDr]、AUTH、SA、TSi、TSr、N(AUTH_がサポートした複数の_)、N(AUTH_が続く別の_)--><--4 HDR、SK、IDr、[本命+]、AUTH、5 SK IDi--><--HDR、6。 HDR、SK EAP(要求する)7。 SK EAP(応答)--><--HDR、8。 HDR、SK EAP(要求する)9。 SK EAP(応答)--><--HDR、10。 HDR、SK EAP(成功)11。 SK AUTH--><--HDR、12。 HDR、SKAUTH、SA、TSi、TSr

             Example 2: Certificate-based (or shared-secret-based)
             authentication of the initiator and the responder,
             followed by an EAP authentication exchange.

例2: EAP認証交換があとに続いた創始者と応答者の証明書ベースの、そして、(共有された秘密ベース)の認証。

Eronen & Korhonen             Experimental                      [Page 7]

RFC 4739           Multiple Auth. Exchanges in IKEv2       November 2006

Eronen&Korhonenの実験的な[7ページ]RFC4739倍数Auth。 IKEv2 November 2006の交換

2.4.  Example 3: Multiple Initiator Certificates

2.4. 例3: 複数の創始者証明書

   This example shows yet another possibility: the initiator has two
   different certificates (and associated private keys), and
   authenticates both of them to the responder.

この例はさらに別の可能性を示しています: 創始者は、2通の異なった証明書(そして、関連秘密鍵)を持って、それらの両方を応答者に認証します。

      Initiator                   Responder
     -----------                 -----------
      1. HDR, SA, KE, Ni -->
                             <--  2. HDR, SA, KE, Nr, [CERTREQ],
                                          N(MULTIPLE_AUTH_SUPPORTED)
      3. HDR, SK { IDi, [CERT+], [CERTREQ+], [IDr], AUTH,
                   SA, TSi, TSr, N(MULTIPLE_AUTH_SUPPORTED),
                   N(ANOTHER_AUTH_FOLLOWS) }  -->
                             <--  4. HDR, SK { IDr, [CERT+], AUTH }
      5. HDR, SK { IDi, [CERT+], AUTH }  -->
                             <--  6. HDR, SK { SA, TSi, TSr }

創始者応答者----------- ----------- 1. Ni--><--HDR、SA、KE、2。 HDR、SA、KE、Nr、[CERTREQ]、N(AUTH_がサポートした複数の_)3。 HDR、SK、IDi、[本命+]、[CERTREQ+]、[IDr]、AUTH、SA、TSi、TSr、N(AUTH_がサポートした複数の_)、N(AUTH_が続く別の_)--><--4 HDR、SK、IDr、[本命+]、AUTH、5 HDR、SK、IDi、[本命+]、AUTH--><--6 HDR、SKSA、TSi、TSr

          Example 3: Two certificate-based authentications of the
          initiator, and one certificate-based authentication
          of the responder.

例3: 創始者の2つの証明書ベースの認証、および応答者の1つの証明書ベースの認証。

2.5.  Example 4: Multiple Responder Certificates

2.5. 例4: 複数の応答者証明書

   This example shows yet another possibility: the responder has two
   different certificates (and associated private keys), and
   authenticates both of them to the initiator.

この例はさらに別の可能性を示しています: 応答者は、2通の異なった証明書(そして、関連秘密鍵)を持って、それらの両方を創始者に認証します。

      Initiator                   Responder
     -----------                 -----------
      1. HDR, SA, KE, Ni -->
                             <--  2. HDR, SA, KE, Nr, [CERTREQ],
                                          N(MULTIPLE_AUTH_SUPPORTED)
      3. HDR, SK { IDi, [CERT+], [CERTREQ+], [IDr], AUTH,
                   SA, TSi, TSr, N(MULTIPLE_AUTH_SUPPORTED) }  -->
                             <--  4. HDR, SK { IDr, [CERT+], AUTH,
                                               N(ANOTHER_AUTH_FOLLOWS) }
      5. HDR, SK { }  -->
                             <--  6. HDR, SK { IDr, [CERT+], AUTH,
                                               SA, TSi, TSr }

創始者応答者----------- ----------- 1. Ni--><--HDR、SA、KE、2。 HDR、SA、KE、Nr、[CERTREQ]、N(AUTH_がサポートした複数の_)3。 HDR、SK、IDi、[本命+]、[CERTREQ+]、[IDr]、AUTH、SA、TSi、TSr、N(AUTH_がサポートした複数の_)--><--4 HDR、SK、IDr、[本命+]、AUTH、N(AUTH_が続く別の_)、5 HDR、SK、--><--6 HDR、SKIDr、[本命+]、AUTH、SA、TSi、TSr

          Example 4: Two certificate-based authentications of the
          responder, and one certificate-based authentication
          of the initiator.

例4: 応答者の2つの証明書ベースの認証、および創始者の1つの証明書ベースの認証。

Eronen & Korhonen             Experimental                      [Page 8]

RFC 4739           Multiple Auth. Exchanges in IKEv2       November 2006

Eronen&Korhonenの実験的な[8ページ]RFC4739倍数Auth。 IKEv2 November 2006の交換

3.  Payload Formats

3. 有効搭載量形式

3.1.  MULTIPLE_AUTH_SUPPORTED Notify Payload

3.1. _がサポートした倍数_AUTHは有効搭載量に通知します。

   The MULTIPLE_AUTH_SUPPORTED notification is included in the
   IKE_SA_INIT response or the first IKE_AUTH request to indicate that
   the peer supports this specification.  The Notify Message Type is
   MULTIPLE_AUTH_SUPPORTED (16404).  The Protocol ID and SPI Size fields
   MUST be set to zero, and there is no data associated with this Notify
   type.

MULTIPLE_AUTH_SUPPORTED通知はイケ_SA_INIT応答かAUTHが同輩がこの仕様をサポートするのを示すよう要求する最初のイケ_に含まれています。 Notify Message TypeはMULTIPLE_AUTH_SUPPORTED(16404)です。 Protocol IDとSPI Size分野をゼロに設定しなければなりません、そして、このNotifyタイプに関連しているどんなデータもありません。

3.2.  ANOTHER_AUTH_FOLLOWS Notify Payload

3.2. AUTH_が続く別の_は有効搭載量に通知します。

   The ANOTHER_AUTH_FOLLOWS notification payload is included in an
   IKE_AUTH message containing an AUTH payload to indicate that the peer
   wants to continue with another authentication exchange.  The Notify
   Message Type is ANOTHER_AUTH_FOLLOWS (16405).  The Protocol ID and
   SPI Size fields MUST be set to zero, and there is no data associated
   with this Notify type.

ANOTHER_AUTH_FOLLOWS通知ペイロードは、同輩が別の認証交換を続行したがっているのを示すためにAUTHペイロードを含むイケ_AUTHメッセージに含まれています。 Notify Message TypeはANOTHER_AUTH_FOLLOWS(16405)です。 Protocol IDとSPI Size分野をゼロに設定しなければなりません、そして、このNotifyタイプに関連しているどんなデータもありません。

4.  IANA Considerations

4. IANA問題

   This document defines two new IKEv2 notifications,
   MULTIPLE_AUTH_SUPPORTED and ANOTHER_AUTH_FOLLOWS, whose values are
   allocated from the "IKEv2 Notify Message Types" namespace defined in
   [IKEv2].

MULTIPLE_AUTH_SUPPORTEDとANOTHER_AUTH_FOLLOWS、このドキュメントは2つの新しいIKEv2通知を定義して、「IKEv2はメッセージタイプに通知する」という[IKEv2]で定義された名前空間からだれの値を割り当てますか?

   This document does not define any new namespaces to be managed by
   IANA.

IANAによって管理されるように、このドキュメントはどんな新しい名前空間も定義しません。

5.  Security Considerations

5. セキュリティ問題

   Security considerations for IKEv2 are discussed in [IKEv2].  The
   reader is encouraged to pay special attention to considerations
   relating to the use of EAP methods that do not generate shared keys.
   However, the use of multiple authentication exchanges results in at
   least one new security consideration.

[IKEv2]でIKEv2のためのセキュリティ問題について議論します。 読者が共有されたキーを生成しないEAPメソッドの使用に関連する問題に関する特別な注意を向けるよう奨励されます。 しかしながら、複数の認証交換の使用は少なくとも1つの新しい警備上の配慮をもたらします。

   In normal IKEv2, the responder authenticates the initiator before
   revealing its identity (except when EAP is used).  When multiple
   authentication exchanges are used to authenticate the initiator, the
   responder has to reveal its identity before all of the initiator
   authentication exchanges have been completed.

正常なIKEv2では、アイデンティティ(EAPが使用されている時を除いた)を明らかにする前に、応答者は創始者を認証します。 複数の認証交換が創始者を認証するのに使用されるとき、創始者認証交換のすべてが完成する前に応答者はアイデンティティを明らかにしなければなりません。

Eronen & Korhonen             Experimental                      [Page 9]

RFC 4739           Multiple Auth. Exchanges in IKEv2       November 2006

Eronen&Korhonenの実験的な[9ページ]RFC4739倍数Auth。 IKEv2 November 2006の交換

6.  Acknowledgments

6. 承認

   The authors would like to thank Bernard Aboba, Jari Arkko, Spencer
   Dawkins, Lakshminath Dondeti, Henry Haverinen, Russ Housley, Mika
   Joutsenvirta, Charlie Kaufman, Tero Kivinen, Yoav Nir, Magnus
   Nystrom, Mohan Parthasarathy, and Juha Savolainen for their valuable
   comments.

作者は彼らの貴重なコメントについてバーナードAboba、ヤリArkko、スペンサー・ダウキンズ、Lakshminath Dondeti、ヘンリーHaverinen、ラスHousley、ミカJoutsenvirta、チャーリー・カウフマン、Tero Kivinen、Yoavニール、マグヌス・ニストロム、モハンパルタサラティ、およびユハSavolainenに感謝したがっています。

7.  References

7. 参照

7.1.  Normative References

7.1. 引用規格

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

[IKEv2] コーフマン、C.、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、2005年12月。

   [KEYWORDS]  Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", RFC 2119, March 1997.

[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、RFC2119、1997年3月。

7.2.  Informative References

7.2. 有益な参照

   [EAP]       Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
               Levkowetz, "Extensible Authentication Protocol (EAP)",
               RFC 3748, June 2004.

[EAP]Aboba、B.、Blunk、L.、Vollbrecht、J.、カールソン、J.とH.Levkowetz、「拡張認証プロトコル(EAP)」RFC3748、2004年6月。

   [PANA]      Yegin, A., Ohba, Y., Penno, R., Tsirtsis, G., and C.
               Wang, "Protocol for Carrying Authentication for Network
               Access (PANA) Requirements", RFC 4058, May 2005.

[パーナ]Yegin(A.、オオバ、Y.、ペンノ、R.、Tsirtsis、G.、およびC.ワング)は「ネットワークアクセス(パーナ)要件のための認証を運ぶために議定書を作ります」、RFC4058、2005年5月。

Authors' Addresses

作者のアドレス

   Pasi Eronen
   Nokia Research Center
   P.O. Box 407
   FIN-00045 Nokia Group
   Finland

パシEronenノキアリサーチセンター私書箱407フィン-00045Nokia Groupフィンランド

   EMail: pasi.eronen@nokia.com

メール: pasi.eronen@nokia.com

   Jouni Korhonen
   TeliaSonera
   P.O. Box 970
   FIN-00051 Sonera
   Finland

Jouni Korhonen TeliaSonera私書箱970フィン-00051ソネラフィンランド

   EMail: jouni.korhonen@teliasonera.com

メール: jouni.korhonen@teliasonera.com

Eronen & Korhonen             Experimental                     [Page 10]

RFC 4739           Multiple Auth. Exchanges in IKEv2       November 2006

Eronen&Korhonenの実験的な[10ページ]RFC4739倍数Auth。 IKEv2 November 2006の交換

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2006).

IETFが信じる著作権(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, THE IETF TRUST,
   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.

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

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 currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Eronen & Korhonen             Experimental                     [Page 11]

Eronen&Korhonen実験的です。[11ページ]