RFC5178 日本語訳

Network Working Group                                        N. Williams
Request for Comments: 5178                                           Sun
Category: Standards Track                                    A. Melnikov
                                                              Isode Ltd.
                                                                May 2008

コメントを求めるワーキンググループN.ウィリアムズ要求をネットワークでつないでください: 5178年のSunカテゴリ: 標準化過程A.メリニコフIsode株式会社2008年5月

    Generic Security Service Application Program Interface (GSS-API)
   Internationalization and Domain-Based Service Names and Name Type

ジェネリックセキュリティー・サービス適用業務プログラム・インタフェース(GSS-API)国際化、ドメインベースのサービス名、および名前タイプ

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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Abstract

要約

   This document describes domain-name-based service principal names and
   the corresponding name type for the Generic Security Service
   Application Programming Interface (GSS-API).  Internationalization of
   the GSS-API is also covered.

このドキュメントは主要な名前と対応する名前がGeneric Security Service Application Programming Interface(GSS-API)のためにタイプするドメイン名のベースのサービスについて説明します。 また、GSS-APIの国際化はカバーされています。

   Domain-based service names are similar to host-based service names,
   but using a domain name (not necessarily an Internet domain name) in
   addition to a hostname.  The primary purpose of domain-based names is
   to provide a measure of protection to applications that utilize
   insecure service discovery protocols.  This is achieved by providing
   a way to name clustered services after the "domain" which they
   service, thereby allowing their clients to authorize the service's
   servers based on authentication of their service names.

ドメインベースのサービス名は、ホストベースのサービス名と同様ですが、ホスト名に加えてドメイン名(必ずインターネットドメイン名であるというわけではない)を使用します。 ドメインベースの名前のプライマリ目的は不安定なサービス発見プロトコルを利用するアプリケーションに保護の手段を提供することです。 これはクラスタリングしているサービスをそれらが修理する「ドメイン」にちなんで名付ける方法を提供することによって、達成されます、その結果、彼らのクライアントがそれらのサービス名の認証に基づくサービスのサーバを認可するのを許容します。

Williams & Melnikov         Standards Track                     [Page 1]

RFC 5178                 GSS Domain-Based Names                 May 2008

ウィリアムズとメリニコフStandardsは2008年5月にRFC5178のGSSのドメインベースの名を追跡します[1ページ]。

Table of Contents

目次

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Conventions Used in This Document . . . . . . . . . . . . . . . 4
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
     3.1.  Name Type OID . . . . . . . . . . . . . . . . . . . . . . . 4
     3.2.  Name Type OID and Symbolic Name . . . . . . . . . . . . . . 4
   4.  Query and Display Syntaxes  . . . . . . . . . . . . . . . . . . 4
     4.1.  Examples of Domain-Based Names  . . . . . . . . . . . . . . 5
   5.  Internationalization (I18N) Considerations  . . . . . . . . . . 5
     5.1.  Importing Internationalized Names . . . . . . . . . . . . . 5
     5.2.  Displaying Internationalized Names  . . . . . . . . . . . . 5
   6.  Application Protocol Examples . . . . . . . . . . . . . . . . . 6
     6.1.  NFSv4 Domain-Wide Namespace Root Server Discovery . . . . . 6
     6.2.  LDAP Server Discovery . . . . . . . . . . . . . . . . . . . 6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 8

1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 コンベンションは本書では.4 3を使用しました。 IANA問題. . . . . . . . . . . . . . . . . . . . . . 4 3.1。 OID. . . . . . . . . . . . . . . . . . . . . . . 4 3.2とタイプを命名してください。 タイプOIDと英字名. . . . . . . . . . . . . . 4 4を命名してください。 構文. . . . . . . . . . . . . . . . . . 4 4.1を質問して、表示してください。 ドメインベースの名前. . . . . . . . . . . . . . 5 5に関する例。 国際化(I18N)問題. . . . . . . . . . 5 5.1。 インポートするのは名前. . . . . . . . . . . . . 5 5.2を国際的にしました。 表示は名前. . . . . . . . . . . . 5 6を国際的にしました。 アプリケーション・プロトコルの例. . . . . . . . . . . . . . . . . 6 6.1。 NFSv4のドメイン全体の名前空間ルートサーバー発見. . . . . 6 6.2。 LDAPサーバ発見. . . . . . . . . . . . . . . . . . . 6 7。 セキュリティ問題. . . . . . . . . . . . . . . . . . . . 7 8。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1。 引用規格. . . . . . . . . . . . . . . . . . . 7 8.2。 有益な参照. . . . . . . . . . . . . . . . . . 8

Williams & Melnikov         Standards Track                     [Page 2]

RFC 5178                 GSS Domain-Based Names                 May 2008

ウィリアムズとメリニコフStandardsは2008年5月にRFC5178のGSSのドメインベースの名を追跡します[2ページ]。

1.  Introduction

1. 序論

   Some applications need to discover the names of servers for a
   specific resource.  Some common methods for server discovery are
   insecure, e.g., queries for DNS [RFC1035] SRV resource records
   [RFC2782] without using DNSSEC [RFC4033], and are subject to attacks
   whereby a client can be re-directed to incorrect and possibly
   malicious servers.  A client may even be re-directed to a server that
   has credentials for itself and thus may authenticate itself to the
   client, and yet it could be incorrect or malicious (because it has
   been compromised, say).

いくつかのアプリケーションが、特定のリソースに関してサーバの名前を発見する必要があります。 サーバ発見のためのいくつかの共通方法が、不安定です、例えば、DNS[RFC1035]SRVリソースのための質問がDNSSEC[RFC4033]を使用しないで[RFC2782]を記録するということであり、不正確でことによると悪意があるサーバにクライアントを向け直すことができる攻撃を受けることがあります。 クライアントは、それ自体のための資格証明書を持っているサーバに向け直されさえして、その結果、クライアントにそれ自体を認証するかもしれませんが、それは、不正確であるか、または悪意があるかもしれません(それが感染されたので、言ってください)。

   Domain-based names allow for GSS-API [RFC2743] initiator applications
   (clients) to authorize acceptor principals (servers) to serve the
   resource for which the client used insecure server discovery without
   either securing the server discovery method or requiring an
   additional protocol for server authorization.  That is, either a
   discovered server has credentials for authenticating the domain-based
   service names that it is intended to respond to, or it does not.
   Availability of valid credentials for authenticating domain-based
   names embodies the authorization of a given server to a domain-wide
   service.

ドメインベースの名前は、GSS-API[RFC2743]創始者アプリケーション(クライアント)が、アクセプタ校長(サーバ)がクライアントがサーバ発見がメソッドであることを保証するか、またはサーバ承認のために追加議定書を必要としないで不安定なサーバ発見を使用したリソースに勤めるのを認可するのを許容します。 すなわち、発見されたサーバにはそれが応じることを意図するドメインベースのサービス名を認証するための資格証明書があるか、またはそれは持っていません。 ドメインベースの名前を認証するための正当な証明書の有用性は与えられたサーバの承認をドメイン全体のサービスに具体化します。

   A domain-based name consists of three required elements:

ドメインベースの名前は3つの必要な要素から成ります:

   o  a service name

o サービス名

   o  a domain name

o ドメイン名

   o  a hostname

o ホスト名

   The domain name and the hostname should be Domain Name System (DNS)
   names, though domain-based names could be used in non-DNS
   environments.  Because of the use of DNS names we must also provide
   for internationalization of the GSS-API.

ドメイン名とホスト名はドメインネームシステム(DNS)名であるべきです、非DNS環境でドメインベースの名前を使用できましたが。 DNS名の使用のために、また、私たちはGSS-APIの国際化に備えなければなりません。

   Note that domain-based naming isn't new.  According to a report to
   the KITTEN WG mailing list, there exists at least one implementation
   of LDAP which uses domain-based service naming, and the DIGEST-MD5
   HTTP / Simple Authentication and Security Layer (SASL) mechanism
   [RFC2831] describes a similar notion.  (See section 2.1.2 of
   [RFC2831] for a description of the "serv-name" field of the digest-
   response.)

ドメインベースの命名が新しくないことに注意してください。 KITTEN WGメーリングリストへのレポートによると、ドメインベースのサービス命名を使用するLDAPの少なくとも1つの実装が存在しています、そして、DIGEST-MD5 HTTP/簡単なAuthenticationとSecurity Layer(SASL)メカニズム[RFC2831]は同様の概念について説明します。 (ダイジェスト応答の「serv-名前」分野の記述に関して.2セクション2.1[RFC2831]を見てください。)

Williams & Melnikov         Standards Track                     [Page 3]

RFC 5178                 GSS Domain-Based Names                 May 2008

ウィリアムズとメリニコフStandardsは2008年5月にRFC5178のGSSのドメインベースの名を追跡します[3ページ]。

2.  Conventions Used in This Document

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 [RFC2119].

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

3.  IANA Considerations

3. IANA問題

3.1.  Name Type OID

3.1. 名前タイプOID

   The IANA has recorded the following new name-type OID in IANA's "SMI
   Security for Name System Designators Codes (nametypes)" registry:

IANAはIANAの「名前システム指示子コードのためのSMIセキュリティ(nametypes)」登録に以下の新しい名前タイプOIDを記録しました:

   5 gss-domain-based-services [RFC5178]

5 gssのドメインベースのサービス[RFC5178]

3.2.  Name Type OID and Symbolic Name

3.2. 名前タイプOIDと英字名

   This document creates a new GSS-API name-type, with a symbolic name
   of "GSS_C_NT_DOMAINBASED_SERVICE" and this OID:

このドキュメントは「GSS_C_NT_DOMAINBASED_サービス」とこのOIDの英字名で新しいGSS-API名前タイプを創造します:

   {iso(1) org(3) dod(6) internet(1) security(5) nametypes(6) gss-
   domain-based(5)}

iso(1) org(3) dod(6)、インターネット(1)セキュリティの(5)のnametypes(6) gssのドメインベースの(5)

4.  Query and Display Syntaxes

4. 構文を質問して、表示してください。

   There is a single name syntax for domain-based names.  It is
   expressed using the ABNF [RFC5234].

ドメインベースの名前のためのただ一つの名前構文があります。 それは、ABNF[RFC5234]を使用することで言い表されます。

   The syntax is:

構文は以下の通りです。

         domain-based-name = service "@" domain "@" hostname

ドメインベースの名前=サービス"@"ドメイン"@"ホスト名

         hostname          = domain

ホスト名=ドメイン

         domain            = sub-domain 1*("." sub-domain)

ドメイン=サブドメイン1*(「. 」 サブドメイン、)

         sub-domain        = Let-dig [Ldh-str]

サブドメイン、= -貸されて、掘ってください。[Ldh-str]

         Let-dig           = ALPHA / DIGIT

皮肉をさせている=アルファー/ケタ

         Ldh-str           = *( ALPHA / DIGIT / "-" ) Let-dig

Ldh-strは*(アルファ/ケタ/「-」)と皮肉をさせて等しいです。

   Where <service> is defined in Section 4.1 of [RFC2743].  Other rules
   not defined above are defined in Appendix B.1 of [RFC5234].

<サービス>が[RFC2743]のセクション4.1で定義されるところ。 上で定義されなかった他の規則は[RFC5234]のAppendix B.1で定義されます。

Williams & Melnikov         Standards Track                     [Page 4]

RFC 5178                 GSS Domain-Based Names                 May 2008

ウィリアムズとメリニコフStandardsは2008年5月にRFC5178のGSSのドメインベースの名を追跡します[4ページ]。

4.1.  Examples of Domain-Based Names

4.1. ドメインベースの名前に関する例

   These examples are not normative:

これらの例は規範的ではありません:

   o  ldap@somecompany.example@ds1.somecompany.example

o ldap@somecompany.example@ds1.somecompany.example

   o  nfs@somecompany.example@nfsroot1.somecompany.example

o nfs@somecompany.example@nfsroot1.somecompany.example

   The .example top-level domain is used here in accordance with
   [RFC2606].

[RFC2606]に従って、.example最上位のドメインはここで使用されます。

5.  Internationalization (I18N) Considerations

5. 国際化(I18N)問題

   We introduce new versions of GSS_Import_name() and GSS_Display_name()
   to better support Unicode.  Additionally, we provide for the use of
   ASCII Compatible Encoding (ACE)-encoded DNS in the non-
   internationalized interfaces [RFC3490].

私たちは、ユニコードをよりよくサポートするためにGSS_Import_名()とGSS_Display_名()の新しいバージョンを紹介します。 さらに、私たちは非国際化しているインタフェース[RFC3490]でのASCII Compatible Encoding(ACE)のコード化されたDNSの使用に備えます。

5.1.  Importing Internationalized Names

5.1. インポートするのは名前を国際的にしました。

   When the input_name_type parameter is the
   GSS_C_NT_DOMAINBASED_SERVICE OID, then GSS_Import_name()
   implementations and GSS-API mechanisms MUST accept ACE-encoded
   internationalized domain names in the hostname and domain name slots
   of the given domain-based name string.

そして、入力_名前_型引数がGSS_C_NT_DOMAINBASED_SERVICE OIDであるときに、GSS_Import_名前()実装とGSS-APIメカニズムはストリングという与えられたドメインベースの名前のホスト名とドメイン名スロットでACEでコード化された国際化ドメイン名を受け入れなければなりません。

   Support for non-ASCII internationalized domain names SHOULD also be
   provided through a new function, GSS_Import_name_utf8(), that
   operates exactly like GSS_Import_name() (with the same input and
   output parameters and behavior), except that it MUST accept
   internationalized domain names both as UTF-8 strings and as ACE-
   encoded strings via its input_name_string argument.

GSS_Import_名前_utf8()、それはちょうどGSS_Import_名()(同じ入出力パラメタと振舞いがある)のように作動します、また、新しい機能を通して非ASCII国際化ドメイン名SHOULDのサポートを提供してともにUTF-8ストリングとして国際化ドメイン名を認めなければならなくて、ACEが入力_名前_ストリング引数でストリングをコード化したので。

5.2.  Displaying Internationalized Names

5.2. 表示は名前を国際的にしました。

   Implementations of GSS_Display_name() MUST only output US-ASCII or
   ACE-encoded internationalized domain names in the hostname and domain
   name slots of domain-based names (or mechanism names (MN) that
   conform to the mechanism's form for domain-based names).

GSS_Display_名()の実装はドメインベースの名前のホスト名とドメイン名スロットで米国-ASCIIかACEでコード化された国際化ドメイン名を出力するだけでよいです(または、ドメインベースの名前のためのメカニズムのフォームに従うメカニズム名(ミネソタ))。

   Support for non-ASCII internationalized domain names SHOULD also be
   provided through a new function, GSS_Display_name_utf8(), that
   operates exactly like GSS_Display_name() (with the same input and
   output parameters and behavior), except that it outputs UTF-8 strings
   via its name_string output argument.  GSS_Display_name_utf8() MUST
   NOT output ACE-encoded internationalized domain names.

GSS_Display_名前_utf8()、それはちょうどGSS_Display_名()(同じ入出力パラメタと振舞いがある)のように作動します、また、新しい機能を通して非ASCII国際化ドメイン名SHOULDのサポートを提供して名前_ストリング出力議論でUTF-8ストリングを出力するのを除いて。 GSS_Display_名前_utf8()はACEでコード化された国際化ドメイン名を出力してはいけません。

Williams & Melnikov         Standards Track                     [Page 5]

RFC 5178                 GSS Domain-Based Names                 May 2008

ウィリアムズとメリニコフStandardsは2008年5月にRFC5178のGSSのドメインベースの名を追跡します[5ページ]。

6.  Application Protocol Examples

6. アプリケーション・プロトコルの例

   The following examples are not normative.  They describe how the
   authors envision two applications' use of domain-based names.

以下の例は規範的ではありません。 彼らは作者がどうドメインベースの名前の2つのアプリケーションの使用を思い描くかを説明します。

6.1.  NFSv4 Domain-Wide Namespace Root Server Discovery

6.1. NFSv4のドメイン全体の名前空間ルートサーバー発見

   Work is ongoing to provide a method for constructing domain-wide
   NFSv4 [RFC3530] filesystem namespaces where there is a single "root"
   with one or more servers (replicas) and multiple filesystems glued
   into the namespace through use of "referrals".  Clients could then
   construct a "global" namespace through use of the DNS domain
   hierarchy.

仕事は1つ以上のサーバ(レプリカ)と複数のファイルシステムが「紹介」の使用で名前空間ににかわで接がれている状態でドメイン全体のNFSv4[RFC3530]ファイルシステム名前空間を構成するためのメソッドを単一の「根」があるところに提供することにおいて進行中です。 そして、クライアントはDNSドメイン階層構造の使用で「グローバルな」名前空間を構成できるでしょう。

   Here, clients would always know, from context, when they need to find
   the root servers for a given DNS domain.  Root server discovery would
   be performed using DNS SRV RR lookups, without using DNSSEC where
   DNSSEC has not been deployed.

ここで、クライアントは、文脈からいつも彼らが、いつ与えられたDNSドメインにルートサーバーを見つける必要であるかを知っているでしょう。 ルートサーバー発見は、DNSSECが配布されていないDNSSECを使用しないでDNS SRV RRルックアップを使用することで実行されるでしょう。

   When using RPCSEC_GSS [RFC2203] for security, NFSv4 clients would use
   domain-based names to ensure that the servers named in the SRV RRs
   are in fact authorized to be the NFSv4 root servers for the target
   domain.

セキュリティに、RPCSEC_GSS[RFC2203]を使用するとき、NFSv4クライアントは、事実上、SRV RRsで指定されたサーバがターゲット・ドメインへのNFSv4ルートサーバーであることが認可されるのを保証するのにドメインベースの名前を使用するでしょう。

6.2.  LDAP Server Discovery

6.2. LDAPサーバ発見

   LDAP clients using the GSS-API through SASL would also benefit from
   use of domain-based names to protect server discovery through
   insecure DNS SRV RR lookups, much as described above.

また、SASLを通してGSS-APIを使用しているLDAPクライアントは不安定なDNS SRV RRルックアップを通したサーバ発見を保護するためにドメインベースの名前の使用の利益を得るでしょう、上で説明されるように。

   Unlike NFSv4 clients, not all LDAP clients always know from context
   when they should use domain-based names.  That's because existing
   clients may use host-based naming to authenticate servers discovered
   through SRV RR lookups.  Changing such clients to use domain-based
   naming when domain-based acceptor credentials have not been deployed
   to LDAP servers, or when LDAP servers have not been modified to allow
   use of domain-based naming, would break interoperability.  That is,
   there is a legacy server interoperability issue here.  Therefore,
   LDAP clients may require additional configuration at deployment time
   to enable (or disable) use of domain-based naming.

NFSv4クライアントと異なって、すべてのLDAPクライアントが、文脈からいつも彼らがいつドメインベースの名前を使用するべきであるかを知っているというわけではありません。 それは既存のクライアントがSRV RRルックアップを通して発見されたサーバを認証するのにホストベースの命名を使用するかもしれないからです。 ドメインベースのアクセプタ資格証明書がLDAPサーバに配布されていないか、またはLDAPサーバがドメインベースの命名の使用を許すように変更されていないとき、ドメインベースの命名を使用するためにそのようなクライアントを変えると、相互運用性は壊れるでしょう。 すなわち、レガシーサーバ相互運用性問題がここにあります。 したがって、LDAPクライアントが可能にする展開時に追加構成を必要とするかもしれない、(無効にする、)、ドメインベースの命名の使用。

   Note: whether SASL [RFC4422] or its GSS-API bridges [RFC4752] [GS2]
   require updates in order allow use of domain-based names is not
   relevant to the theory of how domain-based naming would protect LDAP
   clients' server discovery.

以下に注意してください。 SASL[RFC4422]かそのGSS-APIブリッジ[RFC4752][GS2]がドメインベースの名前の使用を許すためにアップデートを必要とするかどうかは、ドメインベースの命名がどうLDAPクライアントのサーバ発見を保護するだろうかに関する理論に関連していません。

Williams & Melnikov         Standards Track                     [Page 6]

RFC 5178                 GSS Domain-Based Names                 May 2008

ウィリアムズとメリニコフStandardsは2008年5月にRFC5178のGSSのドメインベースの名を追跡します[6ページ]。

7.  Security Considerations

7. セキュリティ問題

   Use of GSS-API domain-based names may not be negotiable by some GSS-
   API mechanisms, and some acceptors may not support GSS-API domain-
   based names.  In such cases, the initiators are left to fall back on
   the use of host-based names, so the initiators MUST also verify that
   the acceptor's host-based name is authorized to provide the given
   service for the domain that the initiator had wanted.

GSS-APIのドメインベースの名の使用はいくつかのGSS APIメカニズムで交渉可能でないかもしれません、そして、いくつかのアクセプタはGSS-APIドメインがベースの名前であるとサポートしないかもしれません。 そのような場合、創始者がホストベースの名前の使用のときに後ろへ下がるのが残されるので、また、創始者は、アクセプタのホストベースの名前が創始者が欲しかったドメインのための与えられたサービスを提供するのが認可されることを確かめなければなりません。

   The above security consideration also applies to all GSS-API
   initiators who lack support for domain-based service names.

また、上の警備上の配慮はドメインベースのサービス名のサポートを欠いているすべてのGSS-API創始者に適用されます。

   Note that, as with all service names, the mere existence of a domain-
   based service name conveys meaningful information that may be used by
   initiators for making authorization decisions; therefore,
   administrators of distributed authentication services should be aware
   of the significance of the service names for which they create
   acceptor credentials.

ドメインの単なる存在がすべてのサービス名のようにサービス名を基礎づけたというメモは承認決定をするのに創始者によって使用されるかもしれない有意義な情報を伝えます。 したがって、分配された認証サービスの管理者はそれらがアクセプタ資格証明書を作成するサービス名の意味を意識しているべきです。

8.  References

8. 参照

8.1.  Normative References

8.1. 引用規格

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

[RFC1035]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、11月1987日

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

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

   [RFC2743]  Linn, J., "Generic Security Service Application Program
              Interface Version 2, Update 1", RFC 2743, January 2000.

[RFC2743] リン、J.、「ジェネリックセキュリティー・サービス適用業務プログラム・インタフェースバージョン2、アップデート1インチ、RFC2743、2000年1月。」

   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,
              February 2000.

[RFC2782] Gulbrandsen、A.、Vixie、P.、およびL.Esibov、「サービスの位置を指定するためのDNS RR(DNS SRV)」、RFC2782(2000年2月)。

   [RFC2831]  Leach, P. and C. Newman, "Using Digest Authentication as a
              SASL Mechanism", RFC 2831, May 2000.

[RFC2831] リーチ、P.、およびC.ニューマン(「SASLメカニズムとしてダイジェスト認証を使用します」、RFC2831)は2000がそうするかもしれません。

   [RFC3490]  Faltstrom, P., Hoffman, P., and A. Costello,
              "Internationalizing Domain Names in Applications (IDNA)",
              RFC 3490, March 2003.

[RFC3490] Faltstrom、P.、ホフマン、P.、およびA.コステロ、「アプリケーション(IDNA)におけるドメイン名を国際的にします」、RFC3490、2003年3月。

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

[RFC5234] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、STD68、RFC5234、2008年1月。

Williams & Melnikov         Standards Track                     [Page 7]

RFC 5178                 GSS Domain-Based Names                 May 2008

ウィリアムズとメリニコフStandardsは2008年5月にRFC5178のGSSのドメインベースの名を追跡します[7ページ]。

8.2.  Informative References

8.2. 有益な参照

   [GS2]      Josefsson, S., "Using GSS-API Mechanisms in SASL: The GS2
              Mechanism Family", Work in Progress, October 2007.

[GS2]Josefsson、S.、「SASLのGSS-APIメカニズムを使用します:」 「GS2メカニズムファミリー」は進歩、2007年10月に働いています。

   [RFC2203]  Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
              Specification", RFC 2203, September 1997.

[RFC2203] アイスラーとM.とチウ、A.とL.の御柳もどき、「RPCSEC_GSSプロトコル仕様」、RFC2203、1997年9月。

   [RFC2606]  Eastlake, D. and A. Panitz, "Reserved Top Level DNS
              Names", BCP 32, RFC 2606, June 1999.

[RFC2606] イーストレークとD.とA.パニツ、「予約された最高平らなDNS名」、BCP32、RFC2606、1999年6月。

   [RFC3530]  Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
              Beame, C., Eisler, M., and D. Noveck, "Network File System
              (NFS) version 4 Protocol", RFC 3530, April 2003.

[RFC3530]Shepler(S.、キャラハン、B.、ロビンソン、D.、サーロウ、R.、Beame、C.、アイスラー、M.、およびD.Noveck)は「File System(NFS)バージョン4プロトコルをネットワークでつなぎます」、RFC3530、2003年4月。

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, March 2005.

[RFC4033] Arends、R.Austein、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、「DNSセキュリティ序論と要件」(RFC4033)は2005を行進させます。

   [RFC4422]  Melnikov, A. and K. Zeilenga, "Simple Authentication and
              Security Layer (SASL)", RFC 4422, June 2006.

[RFC4422] メリニコフとA.とK.Zeilenga、「簡易認証とセキュリティは(SASL)を層にする」RFC4422、2006年6月。

   [RFC4752]  Melnikov, A., "The Kerberos V5 ("GSSAPI") Simple
              Authentication and Security Layer (SASL) Mechanism",
              RFC 4752, November 2006.

[RFC4752]メリニコフ、A.、「ケルベロスV5("GSSAPI")簡易認証とセキュリティ層(SASL)のメカニズム」、RFC4752、2006年11月。

Authors' Addresses

作者のアドレス

   Nicolas Williams
   Sun Microsystems
   5300 Riata Trace Ct.
   Austin, TX  78727
   US

ニコラスウィリアムズサン・マイクロシステムズ5300Riataはctをたどります。 オースチン、テキサス78727米国

   EMail: Nicolas.Williams@sun.com

メール: Nicolas.Williams@sun.com

   Alexey Melnikov
   Isode Ltd.
   5 Castle Business Village,
   36 Station Road
   Hampton, Middlesex  TW12 2BX
   United Kingdom

AlexeyメリニコフIsode Ltd.5城のビジネス村、36駅のRoadハンプトン、ミドルセックスTW12 2BXイギリス

   EMail: Alexey.Melnikov@isode.com

メール: Alexey.Melnikov@isode.com

Williams & Melnikov         Standards Track                     [Page 8]

RFC 5178                 GSS Domain-Based Names                 May 2008

ウィリアムズとメリニコフStandardsは2008年5月にRFC5178のGSSのドメインベースの名を追跡します[8ページ]。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2008).

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

   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に情報を記述してください。

Williams & Melnikov         Standards Track                     [Page 9]

ウィリアムズとメリニコフ標準化過程[9ページ]