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
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).
著作権（C）IETFトラスト（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）メソッドを持つ署名を含む関係者を認証するためのいくつかのメカニズムをサポートしています。現在、各エンドポイントは自身を認証するために一つだけこれらのメカニズムのを使用しています。この文書は、異なる機構または同様のメカニズムのいずれかを使用して、複数の認証交換の使用を可能にするの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セキュリティアソシエーション）当事者のためのいくつかのメカニズムをサポートしています。これらは、公開鍵証明書、共有秘密、および拡張認証プロトコル（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.
現在、各エンドポイントは自身を認証するために一つだけこれらのメカニズムのを使用しています。しかし、（アクセスを許可するかどうか）が必要です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つの別々のセットを使用することになり、さらにはさまざまな認証メカニズムを使用する場合があります。
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サーバで終端されている「配列」（[EAP]のセクション2.1に記載されているように）が、別個の独立した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交換内二相認証から利益を得ることができるオペレータがホストするVPNシナリオの例示的なアーキテクチャを示しています。まず、クライアントがネットワークアクセスプロバイダ（NAP）に向けて認証し、NAP-ホストされているVPNゲートウェイへのアクセス権を取得します。第一段階認証は、NAPのバックエンドAAAサーバを必要とします。最初の認証後、クライアントはまた、サードパーティのバックエンドAAAサーバを必要とする第二の認証ラウンドを開始します。両方の認証が成功した場合、必要な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.
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[キーワード]に記載されているように解釈されます。
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は]」）、およびプラス記号（「FOO +」、例えば）ペイロードを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).
ピアは、IKE_SA_INIT応答（レスポンダ）内MULTIPLE_AUTH_SUPPORTED通知と第IKE_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.
両方のピアは、この拡張機能をサポートしている場合、それらのいずれかは、それがAUTHペイロードを含むすべてのIKE_AUTHメッセージにおけるANOTHER_AUTH_FOLLOWS通知を含むことにより、第2の認証を持ってしたいことを発表することができます。これはANOTHER_AUTH_FOLLOWSを送信するピアが他のピアに別の資格情報のセットを認証するために望んでいることを示しています。このピアによって送信された次IKE_AUTHメッセージは第二識別ペイロード（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ベースの認証は、常に（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.
セクション2.15および2.16、IDI「はイニシエータによって送信された最新のIDIペイロードを指し、そしてIDR」がレスポンダによって送信された最新のIDRペイロードを指す【のIKEv2]で指定されるようにAUTHペイロードを算出します。共有鍵を生成しないEAPメソッドが使用されている場合は、同じ内容のいくつかのAUTHペイロードが送信されることも可能です。そのようなEAPメソッドが使用される場合、AUTHペイロードの目的は、認証交換を画定し、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).
この例では、EAP認証交換（メッセージ1-10）続いてレスポンダの証明書ベースの認証を示しています。最初のEAP交換が（イニシエータはそのAUTHペイロードを送信して）終了された場合、イニシエータは、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).
この後、第二認証情報の交換を開始します。イニシエータは、EAPが使用されることを示す、新規のIDIペイロードが、無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 }
Example 1: Certificate-based authentication of the
responder, followed by two EAP authentication exchanges.
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.
This example shows yet another possibility: the initiator has two different certificates (and associated private keys), and authenticates both of them to the responder.
イニシエータは、二つの異なる証明書（および関連する秘密鍵）を有し、そして応答にそれらの両方を認証：この例では、さらに別の可能性を示します。
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.
This example shows yet another possibility: the responder has two different certificates (and associated private keys), and authenticates both of them to the initiator.
レスポンダは、二つの異なる証明書（および関連する秘密鍵）を有し、イニシエータにそれらの両方を認証：この例では、さらに別の可能性を示します。
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.
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通知はIKE_SA_INIT応答またはピアがこの仕様をサポートすることを示す最初のIKE_AUTH要求に含まれています。通知メッセージタイプはMULTIPLE_AUTH_SUPPORTED（16404）です。プロトコルID及びSPIサイズフィールドがゼロに設定されなければならない、この通知タイプに関連付けられたデータが存在しません。
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メッセージに含まれています。通知メッセージタイプはANOTHER_AUTH_FOLLOWS（16405）です。プロトコルID及びSPIサイズフィールドがゼロに設定されなければならない、この通知タイプに関連付けられたデータが存在しません。
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].
この文書では、二つの新しいIKEv2の通知を定義し、その値から割り当てられMULTIPLE_AUTH_SUPPORTEDとANOTHER_AUTH_FOLLOWS、[IKEv2の]で定義された名前空間「のIKEv2は、メッセージタイプを通知します」。
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.
通常のIKEv2において、レスポンダは（EAPを使用する場合を除く）、そのアイデンティティを明らかにする前に、イニシエータを認証します。複数の認証交換がイニシエータを認証するために使用されている場合は、レスポンダはイニシエータの認証交換がすべて完了している前に、その身元を明らかにしています。
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、ヨアフニール、マグナスNystrom、モハンパルタサラティ、およびユハSavolainenのを感謝したいと思います。
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKEv2の]カウフマン、C.、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、「要件レベルを示すためにRFCsにおける使用のためのキーワード」、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.、ブルンク、L.、Vollbrecht、J.、カールソン、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.、オオバ、Y.、Penno、R.、Tsirtsis、G.、及びC.王、 "ネットワークアクセスの認証を搬送するプロトコル（PANA）要件"、RFC 4058、2005年5月。
Authors' Addresses
著者のアドレス
Pasi Eronen Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland
ノキア・リサーチセンター私書箱のパシEronenボックス407 FIN-00045 Nokiaのグループフィンランド
EMail: pasi.eronen@nokia.com
メールアドレス：pasi.eronen@nokia.com
Jouni Korhonen TeliaSonera P.O. Box 970 FIN-00051 Sonera Finland
Jouni Korhonenテリアソネラの私書箱ボックス970 FIN-00051テリアソネラフィンランド
EMail: jouni.korhonen@teliasonera.com
メールアドレス：jouni.korhonen@teliasonera.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
著作権（C）IETFトラスト（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.
この文書およびここに含まれる情報は、上に提供される基礎とCONTRIBUTOR、ORGANIZATION彼/彼女が表すOR（もしあれば）後援が「そのまま」、インターネット学会、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.
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 currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。