[要約] RFC 4681は、TLS (Transport Layer Security) プロトコルにおけるユーザーマッピング拡張機能に関するものです。この拡張機能の主な目的は、TLSセッションの確立時にクライアントの身元をより正確に識別し、マッピングすることにあります。これは特に、複数のユーザーが同一の証明書を使用して認証を行う環境で有用です。利用場面としては、企業や組織内でのアクセス制御が挙げられ、セキュリティを強化しつつ、ユーザー管理の柔軟性を高めることができます。関連するRFCとしては、TLSプロトコルを定義するRFC 5246や、その他のTLS拡張に関するRFCがあります。
Network Working Group S. Santesson
Request for Comments: 4681 A. Medvinsky
Updates: 4346 J. Ball
Category: Standards Track Microsoft
October 2006
TLS User Mapping Extension
TLSユーザーマッピング拡張機能
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This document specifies a TLS extension that enables clients to send generic user mapping hints in a supplemental data handshake message defined in RFC 4680. One such mapping hint is defined in an informative section, the UpnDomainHint, which may be used by a server to locate a user in a directory database. Other mapping hints may be defined in other documents in the future.
このドキュメントは、クライアントがRFC 4680で定義された補足データハンドシェイクメッセージにジェネリックユーザーマッピングヒントを送信できるようにするTLS拡張機能を指定します。ディレクトリデータベースのユーザー。他のマッピングヒントは、将来の他のドキュメントで定義される場合があります。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Terminology ................................................2
1.2. Design Considerations ......................................2
2. User Mapping Extension ..........................................3
3. User Mapping Handshake Exchange .................................3
4. Message Flow ....................................................5
5. Security Considerations .........................................6
6. UPN Domain Hint (Informative) ...................................7
7. IANA Considerations .............................................8
8. Normative References ............................................9
9. Acknowledgements ................................................9
This document has a normative part and an informative part. Sections 2-5 are normative. Section 6 is informative.
このドキュメントには、規範的な部分と有益な部分があります。セクション2〜5は規範的です。セクション6は有益です。
This specification defines a TLS extension and a payload for the SupplementalData handshake message, defined in RFC 4680 [N6], to accommodate mapping of users to their user accounts when using TLS client authentication as the authentication method.
この仕様は、TLSクライアント認証を認証方法として使用する際にユーザーのマッピングに対応するために、RFC 4680 [N6]で定義されているTLS拡張機能と補足乳房ハンドシェイクメッセージのペイロードを定義します。
The new TLS extension (user_mapping) is sent in the client hello message. Per convention defined in RFC 4366 [N4], the server places the same extension (user_mapping) in the server hello message, to inform the client that the server understands this extension. If the server does not understand the extension, it will respond with a server hello omitting this extension, and the client will proceed as normal, ignoring the extension, and not include the UserMappingDataList data in the TLS handshake.
新しいTLS拡張機能（user_mapping）は、クライアントのhelloメッセージに送信されます。RFC 4366 [N4]で定義されている条約ごとに、サーバーはサーバーのhelloメッセージに同じ拡張機能（user_mapping）を配置して、サーバーがこの拡張子を理解していることをクライアントに通知します。サーバーが拡張機能を理解していない場合、サーバーはこの拡張機能を省略して回答し、クライアントは拡張機能を無視して通常どおり続行し、TLSハンドシェイクにUserMappingDatalistデータを含めません。
If the new extension is understood, the client will inject UserMappingDataList data in the SupplementalData handshake message prior to the Client's Certificate message. The server will then parse this message, extracting the client's domain, and store it in the context for use when mapping the certificate to the user's directory account.
新しい拡張機能が理解されている場合、クライアントは、クライアントの証明書メッセージの前に、補足乳房ハンドシェイクメッセージにUsermappingDatalistデータを挿入します。その後、サーバーはこのメッセージを解析し、クライアントのドメインを抽出し、ユーザーのディレクトリアカウントに証明書をマッピングするときに使用するためにコンテキストに保存します。
No other modifications to the protocol are required. The messages are detailed in the following sections.
プロトコルの他の変更は必要ありません。メッセージの詳細については、次のセクションで詳しく説明しています。
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 RFC 2119 [N1].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC 2119 [N1]に記載されているように解釈される。
The syntax for the TLS User Mapping extension is defined using the TLS Presentation Language, which is specified in Section 4 of [N2].
TLSユーザーマッピング拡張機能の構文は、[N2]のセクション4で指定されているTLSプレゼンテーション言語を使用して定義されます。
The reason the mapping data itself is not placed in the extension portion of the client hello is to prevent broadcasting this information to servers that don't understand the extension.
マッピングデータ自体がクライアントの拡張部分に配置されていない理由は、この情報を拡張機能を理解していないサーバーに放送するのを防ぐためです。
A new extension type (user_mapping(6)) is added to the Extension used in both the client hello and server hello messages. The extension type is specified as follows.
新しい拡張機能タイプ（user_mapping（6））が、クライアントのhelloとserver helloメッセージの両方で使用される拡張機能に追加されます。拡張タイプは次のように指定されています。
enum {
user_mapping(6), (65535)
} ExtensionType;
The "extension_data" field of this extension SHALL contain "UserMappingTypeList" with a list of supported hint types where:
この拡張機能の「拡張機能_DATA」フィールドには、サポートされているヒントタイプのリストがある「USERMAPPINGTYPELIST」を含むものとします。
struct {
UserMappingType user_mapping_types<1..2^8-1>;
} UserMappingTypeList;
Enumeration of hint types (user_mapping_types) defined in this document is provided in Section 3.
このドキュメントで定義されているヒント型（user_mapping_types）の列挙は、セクション3に記載されています。
The list of user_mapping_types included in a client hello SHALL signal the hint types supported by the client. The list of user_mapping_types included in the server hello SHALL signal the hint types preferred by the server.
クライアントに含まれるuser_mapping_typesのリストは、クライアントがサポートするヒントタイプを信号するものとします。サーバーに含まれるuser_mapping_typesのリストhelloは、サーバーが好むヒントタイプを信号するものとします。
If none of the hint types listed by the client is supported by the server, the server SHALL omit the user_mapping extension in the server hello.
クライアントによってリストされているヒントタイプのいずれもサーバーによってサポートされていない場合、サーバーはサーバーのuser_mapping拡張機能を省略しなければなりません。
When the user_mapping extension is included in the server hello, the list of hint types in "UserMappingTypeList" SHALL be either equal to, or a subset of, the list provided by the client.
user_mapping拡張機能がサーバーのhelloに含まれる場合、「usermappingtypelist」のヒントタイプのリストは、クライアントが提供するリストの等またはサブセットのいずれかとしてください。
The underlying structure of the SupplementalData handshake message, used to carry information defined in this section, is defined in RFC 4680 [N6].
このセクションで定義されている情報を伝達するために使用される補足乳酸ハンドシェイクメッセージの根底にある構造は、RFC 4680 [N6]で定義されています。
A new SupplementalDataType [N6] is defined to accommodate communication of generic user mapping data. See RFC 2246 (TLS 1.0) [N2] and RFC 4346 (TLS 1.1) [N3] for other handshake types.
一般的なユーザーマッピングデータの通信に対応するために、新しいサプリメントアルダタタイプ[N6]が定義されています。他のハンドシェイクタイプについては、RFC 2246（TLS 1.0）[N2]およびRFC 4346（TLS 1.1）[N3]を参照してください。
The information in this data type carries one or more unauthenticated hints, UserMappingDataList, inserted by the client side. Upon receipt and successful completion of the TLS handshake, the server MAY use this hint to locate the user's account from which user information and credentials MAY be retrieved to support authentication based on the client certificate.
このデータ型の情報には、クライアント側によって挿入されたUsermappingDatalistの1つまたは複数の無認定ヒントが含まれています。TLSハンドシェイクが受領され、正常に完了すると、サーバーはこのヒントを使用して、ユーザー情報と資格情報を取得してクライアント証明書に基づいて認証をサポートできるユーザーのアカウントを見つけることができます。
struct {
SupplementalDataType supp_data_type;
uint16 supp_data_length;
select(SupplementalDataType) {
case user_mapping_data: UserMappingDataList;
}
} SupplementalDataEntry;
enum {
user_mapping_data(0), (65535)
} SupplementalDataType;
The user_mapping_data(0) enumeration results in a new supplemental data type UserMappingDataList with the following structure:
user_mapping_data（0）列挙は、次の構造を持つ新しい補足データ型UsermappingDatalistをもたらします。
enum {
(255)
} UserMappingType;
struct {
UserMappingType user_mapping_version;
uint16 user_mapping_length;
select(UserMappingType) { }
} UserMappingData;
struct{
UserMappingData user_mapping_data_list<1..2^16-1>;
}UserMappingDataList;
user_mapping_length This field is the length (in bytes) of the data selected by UserMappingType.
user_mapping_lengthこのフィールドは、usermappingtypeで選択されたデータの長さ（バイト単位）です。
The UserMappingData structure contains a single mapping of type UserMappingType. This structure can be leveraged to define new types of user mapping hints in the future. The UserMappingDataList MAY carry multiple hints; it is defined as a vector of UserMappingData structures.
UserMappingData構造には、型UserMappingTypeの単一のマッピングが含まれています。この構造を活用して、将来の新しいタイプのユーザーマッピングヒントを定義できます。UsermappingDatalistは、複数のヒントを運ぶ場合があります。UsermappingData構造のベクトルとして定義されます。
No preference is given to the order in which hints are specified in this vector. If the client sends more than one hint, then the Server SHOULD use the applicable mapping supported by the server.
このベクトルでヒントが指定されている順序は優先されません。クライアントが複数のヒントを送信する場合、サーバーはサーバーによってサポートされている該当するマッピングを使用する必要があります。
Implementations MAY support the UPN domain hint as specified in Section 6 of this document. Implementations MAY also support other user mapping types as they are defined. Definitions of standards-track user mapping types must include a discussion of internationalization considerations.
実装は、このドキュメントのセクション6で指定されているUPNドメインヒントをサポートする場合があります。実装は、定義されている他のユーザーマッピングタイプをサポートする場合があります。標準トラックユーザーマッピングタイプの定義には、国際化に関する考慮事項の議論を含める必要があります。
In order to negotiate sending user mapping data to a server in accordance with this specification, clients MUST include an extension of type "user_mapping" in the (extended) client hello, which SHALL contain a list of supported hint types.
この仕様に従ってユーザーマッピングデータをサーバーに送信することをネゴシエートするには、クライアントが（拡張）クライアントのhelloにタイプ「user_mapping」の拡張機能を含める必要があります。
Servers that receive an extended client hello containing a "user_mapping" extension MAY indicate that they are willing to accept user mapping data by including an extension of type "user_mapping" in the (extended) server hello, which SHALL contain a list of preferred hint types.
「user_mapping」拡張機能を含む拡張クライアントのhelloを受信するサーバーは、（拡張）サーバーに「user_mapping」の拡張機能を含めることにより、ユーザーマッピングデータを受け入れることを望んでいることを示している場合があります。。
After negotiation of the use of user mapping has been successfully completed (by exchanging hello messages including "user_mapping" extensions), clients MAY send a "SupplementalData" message containing the "UserMappingDataList" before the "Certificate" message. The message flow is illustrated in Figure 1 below.
ユーザーマッピングの使用の交渉が正常に完了した後（「user_mapping」拡張子を含むハローメッセージを交換することにより）、クライアントは「証明書」メッセージの前に「usermappingdatalist」を含む「補足乳房」メッセージを送信する場合があります。メッセージフローを以下の図1に示します。
Client Server
クライアントサーバー
ClientHello
/* with user_mapping ext */ -------->
ServerHello
/* with user-mapping ext */
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
SupplementalData
/* with UserMappingDataList */
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
* Indicates optional or situation-dependent messages that are not always sent according to RFC 2246 [N2] and RFC 4346 [N3].
* RFC 2246 [N2]およびRFC 4346 [N3]に従って常に送信されるとは限らないオプションまたは状況依存のメッセージを示します。
Figure 1. Message Flow with User Mapping Data
図1.ユーザーマッピングデータを使用したメッセージフロー
The server MUST expect and gracefully handle the case where the client chooses not to send any supplementalData handshake message even after successful negotiation of extensions. The client MAY at its own discretion decide that the user mapping hint it initially intended to send no longer is relevant for this session. One such reason could be that the server certificate fails to meet certain requirements.
サーバーは、クライアントが拡張の交渉が成功した後でも、クライアントが補足乳房の握手メッセージを送信しないことを選択するケースを期待し、優雅に処理する必要があります。クライアントは、独自の裁量により、最初に送信することを意図していたユーザーマッピングのヒントが、このセッションに関連することを決定する場合があります。そのような理由の1つは、サーバー証明書が特定の要件を満たしていないことです。
The user mapping hint sent in the UserMappingDataList is unauthenticated data that MUST NOT be treated as a trusted identifier. Authentication of the user represented by that user mapping hint MUST rely solely on validation of the client certificate. One way to do this is to use the user mapping hint to locate and extract a certificate of the claimed user from the trusted directory and subsequently match this certificate against the validated client certificate from the TLS handshake.
UsermappingDatalistで送信されたユーザーマッピングヒントは、信頼できる識別子として扱われてはならない認証されていないデータです。そのユーザーマッピングヒントによって表されるユーザーの認証は、クライアント証明書の検証のみに依存する必要があります。これを行う1つの方法は、ユーザーマッピングヒントを使用して、信頼できるディレクトリから請求されたユーザーの証明書を見つけて抽出し、その後、この証明書をTLSハンドシェイクから検証済みのクライアント証明書と一致させることです。
As the client is the initiator of this TLS extension, it needs to determine when it is appropriate to send the User Mapping Information. It may not be prudent to broadcast a user mapping hint to just any server at any time.
クライアントはこのTLS拡張機能の開始者であるため、ユーザーマッピング情報を送信することがいつ適切であるかを判断する必要があります。ユーザーマッピングのヒントをいつでもサーバーのみにブロードキャストすることは賢明ではないかもしれません。
To avoid superfluously sending user mapping hints, clients SHOULD only send this information if it recognizes the server as a legitimate recipient. Recognition of the server can be done in many ways. One way to do this could be to recognize the name and address of the server.
ユーザーマッピングのヒントを不必要に送信することを避けるために、クライアントは、サーバーを正当な受信者として認識している場合にのみこの情報を送信する必要があります。サーバーの認識は多くの方法で実行できます。これを行う1つの方法は、サーバーの名前とアドレスを認識することです。
In some cases, the user mapping hint may itself be regarded as sensitive. In such cases, the double handshake technique described in [N6] can be used to provide protection for the user mapping hint information.
場合によっては、ユーザーマッピングヒント自体が敏感であると見なされる場合があります。このような場合、[N6]で説明されている二重の握手手法を使用して、ユーザーマッピングのヒント情報を保護できます。
This specification provides an informative description of one user mapping hint type for Domain Name hints and User Principal Name hints. Other hint types may be defined in other documents in the future.
この仕様は、ドメイン名のヒントとユーザープリンシパル名のヒントのヒントタイプの1つのユーザーマッピングの有益な説明を提供します。他のヒントタイプは、将来の他のドキュメントで定義される場合があります。
The User Principal Name (UPN) in this hint type represents a name that specifies a user's entry in a directory in the form userName@domainName. Traditionally, Microsoft has relied on the presence of such a name form to be present in the client certificate when logging on to a domain account. However, this has several drawbacks since it prevents the use of certificates with an absent UPN and also requires re-issuance of certificates or issuance of multiple certificates to reflect account changes or creation of new accounts. The TLS extension, in combination with the defined hint type, provides a significant improvement to this situation as it allows a single certificate to be mapped to one or more accounts of the user and does not require the certificate to contain a proprietary UPN.
このヒントタイプのユーザープリンシパル名（UPN）は、フォームのユーザー名@domainnameのディレクトリ内のユーザーのエントリを指定する名前を表します。従来、Microsoftは、ドメインアカウントにログオンするときに、クライアント証明書に存在するような名前のフォームの存在に依存してきました。ただし、これには、UPNが不在で証明書の使用を防ぎ、証明書の再発行またはアカウントの変更または新しいアカウントの作成を反映するために複数の証明書の発行を必要とするため、これにはいくつかの欠点があります。TLS拡張は、定義されたヒントタイプと組み合わせて、ユーザーの1つ以上のアカウントに単一の証明書をマッピングできるため、この状況に大幅な改善を提供し、証明書に独自のUPNを封じ込めることを要求しません。
The domain_name field MAY be used when only domain information is needed, e.g., where a user have accounts in multiple domains using the same username name, where that user name is known from another source (e.g., from the client certificate). When the user name is also needed, the user_principal_name field MAY be used to indicate both username and domain name. If both fields are present, then the server can make use of whichever one it chooses.
Domain_Nameフィールドは、ドメイン情報のみが必要な場合に使用できます。たとえば、ユーザーが同じユーザー名名を使用して複数のドメインにアカウントを持っている場合、そのユーザー名は別のソース（例：クライアント証明書から）から既知です。ユーザー名も必要な場合、user_principal_nameフィールドを使用して、ユーザー名とドメイン名の両方を示すことができます。両方のフィールドが存在する場合、サーバーは選択したものを使用できます。
enum {
upn_domain_hint(64), (255)
} UserMappingType;
struct {
opaque user_principal_name<0..2^16-1>;
opaque domain_name<0..2^16-1>;
} UpnDomainHint;
struct {
UserMappingType user_mapping_version;
uint16 user_mapping_length;
select(UserMappingType) {
case upn_domain_hint: UpnDomainHint;
}
} UserMappingData;
The user_principal_name field, when specified, SHALL be of the form "user@domain", where "user" is a UTF-8 encoded Unicode string that does not contain the "@" character, and "domain" is a domain name meeting the requirements in the following paragraph.
user_principal_nameフィールドは、指定された場合、「user@domain」という形式でなければなりません。「user」は、「@」文字を含むUTF-8エンコードされたユニコード文字列であり、「ドメイン」はドメイン名です。次の段落の要件。
The domain_name field, when specified, SHALL contain a domain name [N5] in the usual text form; in other words, a sequence of one or more domain labels separated by ".", each domain label starting and ending with an alphanumeric character and possibly also containing "-" characters. This field is an "IDN-unaware domain name slot" as defined in RFC 3490 [N7], and therefore, domain names containing non-ASCII characters have to be processed as described in RFC 3490 before being stored in this field.
domain_nameフィールドは、指定された場合、通常のテキスト形式にドメイン名[n5]を含めるものとします。言い換えれば、「」で区切られた1つまたは複数のドメインラベルのシーケンス、各ドメインラベルは、英数字の文字で始まり、場合によっては「 - 」文字を含む可能性があります。このフィールドは、RFC 3490 [N7]で定義されている「IDN-UnaWareドメイン名スロット」であるため、このフィールドに保存する前にRFC 3490で説明されているように、非ASCII文字を含むドメイン名を処理する必要があります。
The UpnDomainHint MUST at least contain a non-empty user_principal_name or a non-empty domain_name. The UpnDomainHint MAY contain both user_principal_name and domain_name.
upndomainhintには、少なくとも非空白のuser_principal_nameまたは空白のdomain_nameを含める必要があります。upndomainhintには、user_principal_nameとdomain_nameの両方が含まれている場合があります。
IANA has taken the following actions:
IANAは次のアクションをとっています。
1) Created an entry, user_mapping(6), in the existing registry for ExtensionType (defined in RFC 4366 [N4]).
1) ExtensionTypeの既存のレジストリ（RFC 4366 [N4]で定義）にエントリ、user_mapping（6）を作成しました。
2) Created an entry, user_mapping_data(0), in the new registry for SupplementalDataType (defined in RFC 4680).
2)
3) Established a registry for TLS UserMappingType values. The first entry in the registry is upn_domain_hint(64). TLS UserMappingType values in the inclusive range 0-63 (decimal) are assigned via RFC 2434 [N8] Standards Action. Values from the inclusive range 64-223 (decimal) are assigned via RFC 2434 Specification Required. Values from the inclusive range 224-255 (decimal) are reserved for RFC 2434 Private Use.
3) TLS USERMAPPINGTYPE値のレジストリを確立しました。レジストリの最初のエントリはUPN_DOMAIN_HINT（64）です。包括的範囲0-63（小数）のTLS USERMAPPINGTYPE値は、RFC 2434 [N8]標準アクションを介して割り当てられます。包括的範囲64-223（小数）の値は、必要なRFC 2434仕様を介して割り当てられます。包括的範囲224-255（小数）の値は、RFC 2434の私的使用に予約されています。
[N1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[N1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[N2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[N2] Dierks、T。およびC. Allen、「TLSプロトコルバージョン1.0」、RFC 2246、1999年1月。
[N3] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[N3] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.1」、RFC 4346、2006年4月。
[N4] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006.
[N4] Blake-Wilson、S.、Nystrom、M.、Hopwood、D.、Mikkelsen、J。、およびT. Wright、「Transport Layer Security（TLS）Extensions」、RFC 4366、2006年4月。
[N5] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[N5] Mockapetris、P。、「ドメイン名 - 概念と施設」、STD 13、RFC 1034、1987年11月。
[N6] Santesson, S., "TLS Handshake Message for Supplemental Data", RFC 4680, October 2006.
[N6] Santesson、S。、「補足データのTLSハンドシェイクメッセージ」、RFC 4680、2006年10月。
[N7] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[N7] Faltstrom、P.、Hoffman、P.、およびA. Costello、「アプリケーションの国際化ドメイン名（IDNA）」、RFC 3490、2003年3月。
[N8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[N8] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
The authors extend a special thanks to Russ Housley, Eric Resocorla, and Paul Leach for their substantial contributions.
著者は、Russ Housley、Eric Resocorla、およびPaul Leachに多大な貢献に感謝します。
Authors' Addresses
著者のアドレス
Stefan Santesson Microsoft Finlandsgatan 30 164 93 KISTA Sweden
Stefan Santesson Microsoft Finlandsgatan 30 164 93 Kista Sweden
EMail: stefans@microsoft.com
Ari Medvinsky Microsoft One Microsoft Way Redmond, WA 98052-6399 USA
Ari Medvinsky Microsoft One Microsoft Way Redmond、WA 98052-6399 USA
EMail: arimed@microsoft.com
Joshua Ball Microsoft One Microsoft Way Redmond, WA 98052-6399 USA
Joshua Ball Microsoft One Microsoft Way Redmond、WA 98052-6399 USA
EMail: joshball@microsoft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。