[要約] RFC 4739は、IKEv2プロトコルにおける複数の認証交換に関する仕様であり、IKEv2セッションのセキュリティを向上させるための目的を持つ。
Network Working Group P. Eronen
Request for Comments: 4739 Nokia
Category: Experimental J. Korhonen
TeliaSonera
November 2006
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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2006).
Copyright（c）The IETF Trust（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.
Internet Key Exchange（IKEV2）プロトコルは、パブリックキー証明書、共有秘密、拡張可能な認証プロトコル（EAP）メソッドを含む署名など、当事者を認証するためのいくつかのメカニズムをサポートしています。現在、各エンドポイントは、これらのメカニズムの1つのみを使用して、それ自体を認証しています。このドキュメントは、異なるメカニズムまたは同じメカニズムを使用して、複数の認証交換を使用できるIKEV2の拡張機能を指定します。この拡張機能により、たとえば、クライアントホストの証明書ベースの認証に続いてユーザーのEAP認証を実行できます。バックエンド認証サーバーを使用すると、ネットワークアクセスプロバイダーやサービスプロバイダーなど、さまざまな管理ドメインに属します。
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
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 Security Association）に関与する当事者のためのいくつかのメカニズムをサポートしています。これらには、パブリックキー証明書、共有秘密、および拡張可能な認証プロトコル（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).
別の例を挙げると、オペレーターがサードパーティの仮想プライベートネットワーク（VPN）ゲートウェイサービスをホストしている場合、クライアントをオペレーター（請求目的で）とサードパーティの認証、承認、および認証、および認証する必要がある場合があります。会計（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 planned for [PANA]. The discovery of the appropriate EAP server for each EAP authentication conversation is based on AAA routing.
いくつかのEAP認証の場合、それらは「シーケンス」ではないことに注意することが重要です（[EAP]のセクション2.1で説明されている）が、通常は異なるEAPサーバーで終了する独立した独立したEAP会話です。[EAP]のセクション2.1で説明されているように、単一のEAP会話内の複数の認証方法がまだ禁止されています。複数の独立したEAP会話を使用することは、[PANA]のために計画されている個別のネットワークアクセスプロバイダー（NAP）およびインターネットサービスプロバイダー（ISP）認証交換に似ています。EAP認証会話ごとに適切なEAPサーバーの発見は、AAAルーティングに基づいています。
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エクスチェンジ内の2フェーズ認証の恩恵を受ける可能性のあるオペレーターホストVPNシナリオのアーキテクチャの例を示しています。まず、クライアントはネットワークアクセスプロバイダー（NAP）に対して認証され、NAPホストのVPNゲートウェイにアクセスします。第1フェーズ認証には、NAPのバックエンドAAAサーバーが含まれます。最初の認証の後、クライアントは、サードパーティのバックエンドAAAサーバーも含まれる2番目の認証ラウンドを開始します。両方の認証が成功した場合、必要なIPSECトンネルがセットアップされ、クライアントはサードパーティの背後にある保護されたネットワークにアクセスできます。
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 |
+---------+ +-----+
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：ネットワークアクセスプロバイダーを介してサードパーティネットワークへのアクセスを得るために使用される2フェーズ認証。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.
NAPのAAAサーバーを使用して、AAAトラフィックをサードパーティのバックエンドAAAサーバーにプロキシできます。あるいは、NAPのトンネルエンドポイントからのAAAトラフィックは、サードパーティのバックエンドAAAサーバーに直接移動する可能性があります。ただし、これは多かれ少なかれAAAルーティングの問題です。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[キーワード]で説明されていると解釈されます。
The terms and abbreviations "authenticator", "backend authentication server", "EAP server", and "peer" in this document are to be interpreted as described in [EAP].
このドキュメントの「Authenticator」、「BackEnd Authentication Server」、「EAP Server」、および「Peer」という用語と略語は、[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」）。
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).
ピアは、IKE_SA_INIT応答（Responder）と最初のIKE_AUTHリクエスト（Initiator）に倍数_AUTH_SUPPORTED通知を含めることにより、この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.
両方のピアがこの拡張機能をサポートしている場合、どちらかがAuthペイロードを含むIKE_AUTHメッセージに別の_Auth_Follows通知を含めることにより、2番目の認証を希望することを発表できます。これは、ピアがAnother_Auth_Followsを送信するピアが、他のピアに別の資格情報を認証することを希望することを示しています。このピアが送信した次のIKE_AUTHメッセージには、2番目のIDペイロード（IDIまたはIDR）が含まれ、別の認証交換を開始します。IKE_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ベースの認証は、イニシエーターによって常に要求されます（認証ペイロードを省略します）。
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.
認証ペイロードは、[IKEV2]セクション2.15および2.16で指定されているように計算されます。IDIは、イニシエーターが送信した最新のIDIペイロードを指し、IDR 'はレスポンダーが送信した最新のIDRペイロードを指します。共有キーを生成しないEAPメソッドが使用される場合、同一の内容を持ついくつかの認証ペイロードが送信される可能性があります。このようなEAPメソッドが使用される場合、認証ペイロードの目的は、単に認証交換を区切り、IKE_SA_INITリクエスト/応答メッセージが変更されないようにすることです。
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).
この例は、Responderの証明書ベースの認証に続いてEAP認証交換を示しています（メッセージ1-10）。最初のEAP交換が終了している場合（イニシエーターはAUTHペイロードを送信しています）、イニシエーターは、別の_Auth_Follows通知（メッセージ9）を含めることにより、2回目の認証交換を希望することを発表します。
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ペイロードを送信しますが、認証ペイロードはありません（メッセージ11）。EAPが使用されることを示しています。その後、別の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 }
Example 1: Certificate-based authentication of the responder, followed by two EAP authentication exchanges.
例1：レスポンダーの証明書ベースの認証に続いて、2つの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 }
Example 2: Certificate-based (or shared-secret-based) authentication of the initiator and the responder, followed by an EAP authentication exchange.
例2：イニシエーターとレスポンダーの証明書ベースの（または共有分泌ベースの）認証に続いて、EAP認証交換が続きます。
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 }
Example 3: Two certificate-based authentications of the initiator, and one certificate-based authentication of the responder.
例3：イニシエーターの2つの証明書ベースの認証と、レスポンダーの1つの証明書ベースの認証。
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 }
Example 4: Two certificate-based authentications of the responder, and one certificate-based authentication of the initiator.
例4：レスポンダーの2つの証明書ベースの認証と、イニシエーターの1つの証明書ベースの認証。
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.
Multis_Auth_Supported通知は、IKE_SA_INIT応答または最初のIKE_AUTH要求に含まれており、ピアがこの仕様をサポートしていることを示します。Notifyメッセージタイプは、倍数_AUTH_SUPPORTED（16404）です。プロトコルIDおよびSPIサイズのフィールドはゼロに設定する必要があり、このNotifyタイプに関連するデータはありません。
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ペイロードを含むIKE_AUTHメッセージに含まれており、ピアが別の認証交換を続けたいことを示します。NotifyメッセージタイプはAnother_Auth_Follows（16405）です。プロトコルIDおよびSPIサイズのフィールドはゼロに設定する必要があり、このNotifyタイプに関連するデータはありません。
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].
このドキュメントでは、2つの新しいIKEV2通知、倍数_AUTH_SUPPORTEDとAnother_Auth_Followsを定義します。
This document does not define any new namespaces to be managed by IANA.
このドキュメントでは、IANAが管理する新しい名前空間を定義しません。
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.
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.
著者は、バーナード・アボバ、ジャリ・アークコ、スペンサー・ドーキンス、ラクシュミナス・ドンデティ、ヘンリー・ヘイヴェリネン、ラシュ・ハウズリー、ミカ・ジュッテンヴィルタ、チャーリー・カウフマン、テロ・キビネン、ヨーヴ・ニル、マグナス・ニセトロム、モハン・パルタサル派のコメント、ジャン・パルハ・サヴォーランのために感謝したいと思います。
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKEV2] Kaufman、C。、「Internet Key Exchange（IKEV2）プロトコル」、RFC 4306、2005年12月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、RFC 2119、1997年3月。
[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.、Carlson、J。、およびH. Levkowetz、「拡張可能な認証プロトコル（EAP）」、RFC 3748、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.
[Pana] Yegin、A.、Ohba、Y.、Penno、R.、Tsirtsis、G。、およびC. Wang、「ネットワークアクセス（PANA）要件のための認証を運ぶためのプロトコル」、RFC 4058、2005年5月。
Authors' Addresses
著者のアドレス
Pasi Eronen Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland
Pasi Eronen Nokia Research Center P.O.Box 407 Fin-00045 Nokia Group Finland
EMail: pasi.eronen@nokia.com
Jouni Korhonen TeliaSonera P.O. Box 970 FIN-00051 Sonera Finland
Jouni Korhonen Teliasonera P.O.ボックス970 FIN-00051ソネラフィンランド
EMail: jouni.korhonen@teliasonera.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
Copyright（c）The IETF Trust（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, 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は、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。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 currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。