RFC4255 日本語訳

Network Working Group                                        J. Schlyter
Request for Comments: 4255                                       OpenSSH
Category: Standards Track                                     W. Griffin
                                                                  SPARTA
                                                            January 2006

Schlyterがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 4255年のOpenSSHカテゴリ: 標準化過程W.グリフィンスパルタ2006年1月

   Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints

しっかりとセキュア・シェルの(セキュアシェル (SSH))主要な指紋を発行するのにDNSを使用します。

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)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2006).

Copyright(C)インターネット協会(2006)。

Abstract

要約

   This document describes a method of verifying Secure Shell (SSH) host
   keys using Domain Name System Security (DNSSEC).  The document
   defines a new DNS resource record that contains a standard SSH key
   fingerprint.

このドキュメントはドメインネームシステムSecurity(DNSSEC)を使用することでSecureシェル(SSH)ホストキーについて確かめるメソッドを説明します。 ドキュメントは標準のSSH主要な指紋を含む新しいDNSリソース記録を定義します。

Table of Contents

目次

   1. Introduction ....................................................2
   2. SSH Host Key Verification .......................................2
      2.1. Method .....................................................2
      2.2. Implementation Notes .......................................2
      2.3. Fingerprint Matching .......................................3
      2.4. Authentication .............................................3
   3. The SSHFP Resource Record .......................................3
      3.1. The SSHFP RDATA Format .....................................4
           3.1.1. Algorithm Number Specification ......................4
           3.1.2. Fingerprint Type Specification ......................4
           3.1.3. Fingerprint .........................................5
      3.2. Presentation Format of the SSHFP RR ........................5
   4. Security Considerations .........................................5
   5. IANA Considerations .............................................6
   6. Normative References ............................................7
   7. Informational References ........................................7
   8. Acknowledgements ................................................8

1. 序論…2 2. セキュアシェル (SSH)ホストキー検証…2 2.1. メソッド…2 2.2. 実装注意…2 2.3. マッチングの指紋を採取してください…3 2.4. 認証…3 3. SSHFPリソース記録…3 3.1. SSHFP RDATA形式…4 3.1.1. アルゴリズム数の仕様…4 3.1.2. タイプに仕様の指紋を採取してください…4 3.1.3. 指紋を採取します。5 3.2. SSHFP RRのプレゼンテーション形式…5 4. セキュリティ問題…5 5. IANA問題…6 6. 標準の参照…7 7. 情報の参照…7 8. 承認…8

Schlyter & Griffin          Standards Track                     [Page 1]

RFC 4255                DNS and SSH Fingerprints            January 2006

Schlyterとグリフィン規格は2006年1月にRFC4255DNSとセキュアシェル (SSH)指紋の跡をつけます[1ページ]。

1.  Introduction

1. 序論

   The SSH [6] protocol provides secure remote login and other secure
   network services over an insecure network.  The security of the
   connection relies on the server authenticating itself to the client
   as well as the user authenticating itself to the server.

SSH[6]プロトコルは安全なリモート・ログインと他の安全なネットワーク・サービスを不安定なネットワークの上に提供します。 接続のセキュリティはサーバにそれ自体を認証するユーザと同様にクライアントにそれ自体を認証するサーバを当てにします。

   If a connection is established to a server whose public key is not
   already known to the client, a fingerprint of the key is presented to
   the user for verification.  If the user decides that the fingerprint
   is correct and accepts the key, the key is saved locally and used for
   verification for all following connections.  While some security-
   conscious users verify the fingerprint out-of-band before accepting
   the key, many users blindly accept the presented key.

公開鍵がクライアントにとって既に知られていないサーバに接続を確立するなら、検証のためにキーの指紋をユーザに贈ります。 ユーザが指紋が正しいと決めて、キーを受け入れるなら、キーは、すべての次の接続のための検証に局所的に取っておかれて、使用されます。 盲目的にキー、多くのユーザを受け入れる前にユーザがバンドの外で指紋について確かめるのを意識がある何らかのセキュリティが提示されたキーを受け入れますが。

   The method described here can provide out-of-band verification by
   looking up a fingerprint of the server public key in the DNS [1][2]
   and using DNSSEC [5] to verify the lookup.

ここで説明されたメソッドは、DNS[1][2]でサーバ公開鍵の指紋を見上げて、ルックアップについて確かめるのにDNSSEC[5]を使用することによって、バンドの外に検証を提供できます。

   In order to distribute the fingerprint using DNS, this document
   defines a new DNS resource record, "SSHFP", to carry the fingerprint.

DNSを使用することで指紋を分配して、このドキュメントは、指紋を運ぶために新しいDNSリソース記録、"SSHFP"を定義します。

   Basic understanding of the DNS system [1][2] and the DNS security
   extensions [5] is assumed by this document.

DNSシステム[1][2]とDNSセキュリティ拡大[5]の基本的了解事項はこのドキュメントによって想定されます。

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

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

2.  SSH Host Key Verification

2. セキュアシェル (SSH)ホストキー検証

2.1.  Method

2.1. メソッド

   Upon connection to an SSH server, the SSH client MAY look up the
   SSHFP resource record(s) for the host it is connecting to.  If the
   algorithm and fingerprint of the key received from the SSH server
   match the algorithm and fingerprint of one of the SSHFP resource
   record(s) returned from DNS, the client MAY accept the identity of
   the server.

SSHサーバとの接続のときに、SSHクライアントはそれが接しているホストのためにSSHFPリソース記録を調べるかもしれません。 SSHサーバから受け取られたキーのアルゴリズムと指紋がDNSから返されたSSHFPリソース記録の1つのアルゴリズムと指紋に合っているなら、クライアントはサーバのアイデンティティを受け入れるかもしれません。

2.2.  Implementation Notes

2.2. 実装注意

   Client implementors SHOULD provide a configurable policy used to
   select the order of methods used to verify a host key.  This document
   defines one method: Fingerprint storage in DNS.  Another method
   defined in the SSH Architecture [6] uses local files to store keys
   for comparison.  Other methods that could be defined in the future
   might include storing fingerprints in LDAP or other databases.  A

クライアント作成者SHOULDはホストキーについて確かめるのに使用されるメソッドの注文を選択するのに使用される構成可能な方針を提供します。 このドキュメントは1つのメソッドを定義します: DNSでストレージの指紋を採取してください。 SSH Architecture[6]で定義された別のメソッドは、比較のためのキーを保存するのにローカルファイルを使用します。 将来定義できた他のメソッドは、LDAPか他のデータベースに指紋を保存するのを含むかもしれません。 A

Schlyter & Griffin          Standards Track                     [Page 2]

RFC 4255                DNS and SSH Fingerprints            January 2006

Schlyterとグリフィン規格は2006年1月にRFC4255DNSとセキュアシェル (SSH)指紋の跡をつけます[2ページ]。

   configurable policy will allow administrators to determine which
   methods they want to use and in what order the methods should be
   prioritized.  This will allow administrators to determine how much
   trust they want to place in the different methods.

構成可能な方針で、管理者はどのメソッドを使用したがっているか、そして、メソッドがどんなオーダーで最優先するべきであるかを決心できるでしょう。 これで、管理者は、いくらが、彼らが異なったメソッドで入賞したがっていると信じるかを決心できるでしょう。

   One specific scenario for having a configurable policy is where
   clients do not use fully qualified host names to connect to servers.
   In this scenario, the implementation SHOULD verify the host key
   against a local database before verifying the key via the fingerprint
   returned from DNS.  This would help prevent an attacker from
   injecting a DNS search path into the local resolver and forcing the
   client to connect to a different host.

構成可能な方針を持つための1つの特定のシナリオがクライアントがサーバに接続するのに完全に適切なホスト名を使用しないところです。 このシナリオでは、実装SHOULDはDNSから返された指紋を通してキーについて確かめる前にローカルのデータベースに対して主要なホストについて確かめます。 これは、攻撃者がDNS検索経路を地元のレゾルバに注いで、クライアントに異なったホストに強制的に接させるのを防ぐのを助けるでしょう。

2.3.  Fingerprint Matching

2.3. 指紋マッチング

   The public key and the SSHFP resource record are matched together by
   comparing algorithm number and fingerprint.

アルゴリズム番号と指紋を比較することによって、公開鍵とSSHFPリソース記録は一緒に合われています。

      The public key algorithm and the SSHFP algorithm number MUST
      match.

公開鍵アルゴリズムとSSHFPアルゴリズム番号は合わなければなりません。

      A message digest of the public key, using the message digest
      algorithm specified in the SSHFP fingerprint type, MUST match the
      SSHFP fingerprint.

SSHFP指紋タイプで指定されたメッセージダイジェストアルゴリズムを使用して、公開鍵のメッセージダイジェストはSSHFP指紋に合わなければなりません。

2.4.  Authentication

2.4. 認証

   A public key verified using this method MUST NOT be trusted if the
   SSHFP resource record (RR) used for verification was not
   authenticated by a trusted SIG RR.

検証に使用されるSSHFPリソース記録(RR)が信じられたSIG RRによって認証されなかったなら、このメソッドを使用することで確かめられた公開鍵を信じてはいけません。

   Clients that do validate the DNSSEC signatures themselves SHOULD use
   standard DNSSEC validation procedures.

するクライアントがDNSSEC署名自体を有効にします。SHOULD使用標準のDNSSEC合法化手順。

   Clients that do not validate the DNSSEC signatures themselves MUST
   use a secure transport (e.g., TSIG [9], SIG(0) [10], or IPsec [8])
   between themselves and the entity performing the signature
   validation.

DNSSEC署名自体を有効にしないクライアントは安全な輸送を使用しなければなりません。(署名合法化を実行する自分たちと実体の間の例えば、TSIG[9]、SIG(0)[10]、またはIPsec[8])。

3.  The SSHFP Resource Record

3. SSHFPリソース記録

   The SSHFP resource record (RR) is used to store a fingerprint of an
   SSH public host key that is associated with a Domain Name System
   (DNS) name.

SSHFPリソース記録(RR)は、ドメインネームシステム(DNS)名に関連しているSSH公共のホストキーの指紋を保存するのに使用されます。

   The RR type code for the SSHFP RR is 44.

SSHFP RRのためのRRタイプコードは44です。

Schlyter & Griffin          Standards Track                     [Page 3]

RFC 4255                DNS and SSH Fingerprints            January 2006

Schlyterとグリフィン規格は2006年1月にRFC4255DNSとセキュアシェル (SSH)指紋の跡をつけます[3ページ]。

3.1.  The SSHFP RDATA Format

3.1. SSHFP RDATA形式

   The RDATA for a SSHFP RR consists of an algorithm number, fingerprint
   type and the fingerprint of the public host key.

SSHFP RRのためのRDATAは公共のホストキーのアルゴリズム番号、指紋タイプ、および指紋から成ります。

       1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   algorithm   |    fp type    |                               /
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               /
       /                                                               /
       /                          fingerprint                          /
       /                                                               /
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | アルゴリズム| fpタイプ| /+++++++++++++++++////指紋///+++++++++++++++++++++++++++++++++

3.1.1.  Algorithm Number Specification

3.1.1. アルゴリズム数の仕様

   This algorithm number octet describes the algorithm of the public
   key.  The following values are assigned:

このアルゴリズム数の八重奏は公開鍵のアルゴリズムを説明します。 以下の値は割り当てられます:

          Value    Algorithm name
          -----    --------------
          0        reserved
          1        RSA
          2        DSS

値のAlgorithm名----- -------------- 0 予約された1RSA2のDSS

   Reserving other types requires IETF consensus [4].

他のタイプを予約するのはIETFコンセンサス[4]を必要とします。

3.1.2.  Fingerprint Type Specification

3.1.2. 指紋タイプ仕様

   The fingerprint type octet describes the message-digest algorithm
   used to calculate the fingerprint of the public key.  The following
   values are assigned:

指紋タイプ八重奏は公開鍵の指紋について計算するのに使用されるメッセージダイジェストアルゴリズムを説明します。 以下の値は割り当てられます:

          Value    Fingerprint type
          -----    ----------------
          0        reserved
          1        SHA-1

値のFingerprintはタイプします。----- ---------------- 0 予約された1SHA-1

   Reserving other types requires IETF consensus [4].

他のタイプを予約するのはIETFコンセンサス[4]を必要とします。

   For interoperability reasons, as few fingerprint types as possible
   should be reserved.  The only reason to reserve additional types is
   to increase security.

相互運用性理由で、できるだけわずかな指紋タイプしか予約されるべきではありません。 追加タイプを予約する唯一の理由はセキュリティを増強することです。

Schlyter & Griffin          Standards Track                     [Page 4]

RFC 4255                DNS and SSH Fingerprints            January 2006

Schlyterとグリフィン規格は2006年1月にRFC4255DNSとセキュアシェル (SSH)指紋の跡をつけます[4ページ]。

3.1.3.  Fingerprint

3.1.3. 指紋

   The fingerprint is calculated over the public key blob as described
   in [7].

指紋は[7]で説明されるように公開鍵一滴に関して計算されます。

   The message-digest algorithm is presumed to produce an opaque octet
   string output, which is placed as-is in the RDATA fingerprint field.

不透明な八重奏ストリング出力はあえてメッセージダイジェストアルゴリズムが起こされます。(それは、そのままでRDATA指紋分野に置かれます)。

3.2.  Presentation Format of the SSHFP RR

3.2. SSHFP RRのプレゼンテーション形式

   The RDATA of the presentation format of the SSHFP resource record
   consists of two numbers (algorithm and fingerprint type) followed by
   the fingerprint itself, presented in hex, e.g.:

SSHFPリソース記録のプレゼンテーション形式のRDATAは指紋自体が支えた2つの番号(アルゴリズムと指紋タイプ)から成ります、例えば十六進法で提示されて:

       host.example.  SSHFP 2 1 123456789abcdef67890123456789abcdef67890

host.example。 SSHFP2 1 123456789abcdef67890123456789abcdef67890

   The use of mnemonics instead of numbers is not allowed.

数の代わりにニーモニックの使用は許されていません。

4.  Security Considerations

4. セキュリティ問題

   Currently, the amount of trust a user can realistically place in a
   server key is proportional to the amount of attention paid to
   verifying that the public key presented actually corresponds to the
   private key of the server.  If a user accepts a key without verifying
   the fingerprint with something learned through a secured channel, the
   connection is vulnerable to a man-in-the-middle attack.

現在、ユーザが現実的にサーバキーに置くことができる信頼の量は実際に提示された公開鍵がサーバの秘密鍵に対応することを確かめるのに向けられた注意の量に比例しています。何かが学習されている状態でユーザが指紋について確かめないでキーを受け入れるなら、機密保護しているチャンネル、接続で、中央の男性に対する被害を受け易い攻撃があります。

   The overall security of using SSHFP for SSH host key verification is
   dependent on the security policies of the SSH host administrator and
   DNS zone administrator (in transferring the fingerprint), detailed
   aspects of how verification is done in the SSH implementation, and in
   the client's diligence in accessing the DNS in a secure manner.

SSHホストキー検証にSSHFPを使用する総合的なセキュリティはSSHホスト管理者とDNSゾーンの管理者(指紋を移すことにおける)の安全保障政策(SSH実装、および安全な方法でDNSにアクセスすることにおけるクライアントの勤勉さでどう確かめるかに関する詳細な局面)に依存しています。

   One such aspect is in which order fingerprints are looked up (e.g.,
   first checking local file and then SSHFP).  We note that, in addition
   to protecting the first-time transfer of host keys, SSHFP can
   optionally be used for stronger host key protection.

そのような局面の1つがどのオーダー指紋が見上げられるかで(例えば、最初の照合ローカルファイルと次に、SSHFP)あります。 私たちは、ホストキーの初めての転送を保護することに加えて、より強いホストキー保護に任意にSSHFPを使用できることに注意します。

      If SSHFP is checked first, new SSH host keys may be distributed by
      replacing the corresponding SSHFP in DNS.

SSHFPが最初にチェックされるなら、新しいSSHホストキーは、DNSで対応するSSHFPを取り替えることによって、分配されるかもしれません。

      If SSH host key verification can be configured to require SSHFP,
      SSH host key revocation can be implemented by removing the
      corresponding SSHFP from DNS.

SSHFPを必要とするようにSSHホストキー検証を構成できるなら、DNSから対応するSSHFPを取り外すことによって、SSHホストキー取消しを実装することができます。

Schlyter & Griffin          Standards Track                     [Page 5]

RFC 4255                DNS and SSH Fingerprints            January 2006

Schlyterとグリフィン規格は2006年1月にRFC4255DNSとセキュアシェル (SSH)指紋の跡をつけます[5ページ]。

   As stated in Section 2.2, we recommend that SSH implementors provide
   a policy mechanism to control the order of methods used for host key
   verification.  One specific scenario for having a configurable policy
   is where clients use unqualified host names to connect to servers.
   In this case, we recommend that SSH implementations check the host
   key against a local database before verifying the key via the
   fingerprint returned from DNS.  This would help prevent an attacker
   from injecting a DNS search path into the local resolver and forcing
   the client to connect to a different host.

セクション2.2に述べられているように、私たちは、SSH作成者がホストキー検証に使用されるメソッドの注文を制御するために方針メカニズムを提供することを勧めます。 構成可能な方針を持つための1つの特定のシナリオがクライアントがサーバに接続するのに資格のないホスト名を使用するところです。 この場合、私たちは、SSH実装がDNSから返された指紋を通してキーについて確かめる前にローカルのデータベースに対して主要なホストをチェックすることを勧めます。 これは、攻撃者がDNS検索経路を地元のレゾルバに注いで、クライアントに異なったホストに強制的に接させるのを防ぐのを助けるでしょう。

   A different approach to solve the DNS search path issue would be for
   clients to use a trusted DNS search path, i.e., one not acquired
   through DHCP or other autoconfiguration mechanisms.  Since there is
   no way with current DNS lookup APIs to tell whether a search path is
   from a trusted source, the entire client system would need to be
   configured with this trusted DNS search path.

DNS検索経路問題を解決する異なるアプローチはクライアントが信じられたDNS検索経路を使用するだろうことです、すなわち、1つがDHCPか他の自動構成を通してメカニズムを入手しませんでした。検索経路が信頼できるソースからあるかを言うために現在のDNSルックアップAPIがある道が全くないので、全体のクライアントシステムは、この信じられたDNS検索経路によって構成される必要があるでしょう。

   Another dependency is on the implementation of DNSSEC itself.  As
   stated in Section 2.4, we mandate the use of secure methods for
   lookup and that SSHFP RRs are authenticated by trusted SIG RRs.  This
   is especially important if SSHFP is to be used as a basis for host
   key rollover and/or revocation, as described above.

別の依存はDNSSEC自身の実装にあります。 セクション2.4に述べられているように、私たちは、安全なメソッドのルックアップの使用とそのSSHFP RRsが信じられたSIG RRsによって認証されるのを強制します。 SSHFPがホストキーロールオーバー、そして/または、取消しの基礎として使用されるつもりであるなら、これは特に重要です、上で説明されるように。

   Since DNSSEC only protects the integrity of the host key fingerprint
   after it is signed by the DNS zone administrator, the fingerprint
   must be transferred securely from the SSH host administrator to the
   DNS zone administrator.  This could be done manually between the
   administrators or automatically using secure DNS dynamic update [11]
   between the SSH server and the nameserver.  We note that this is no
   different from other key enrollment situations, e.g., a client
   sending a certificate request to a certificate authority for signing.

それがDNSゾーンの管理者によって署名された後にDNSSECがホストキー指紋の保全を保護するだけであるので、SSHホスト管理者からDNSゾーンの管理者までしっかりと指紋を移さなければなりません。 これは、SSHサーバとネームサーバの間で管理者の間か自動的に安全なDNSダイナミックなアップデート[11]を使用することで手動で終わることができるでしょう。私たちは、これが他の主要な登録状況、例えば、署名のために証明書要求を認証局に送るクライアントと異なっていないことに注意します。

5.  IANA Considerations

5. IANA問題

   IANA has allocated the RR type code 44 for SSHFP from the standard RR
   type space.

IANAはSSHFPのために標準のRRタイプスペースからRRタイプコード44を割り当てました。

   IANA has opened a new registry for the SSHFP RR type for public key
   algorithms.  The defined types are:

IANAは公開鍵アルゴリズムのためのSSHFP RRタイプのために新しい登録を開きました。定義されたタイプは以下の通りです。

      0 is reserved
      1 is RSA
      2 is DSA

0は予約された1がRSA2がDSAであるということであるということです。

   Adding new reservations requires IETF consensus [4].

新しい予約を加えるのはIETFコンセンサス[4]を必要とします。

Schlyter & Griffin          Standards Track                     [Page 6]

RFC 4255                DNS and SSH Fingerprints            January 2006

Schlyterとグリフィン規格は2006年1月にRFC4255DNSとセキュアシェル (SSH)指紋の跡をつけます[6ページ]。

   IANA has opened a new registry for the SSHFP RR type for fingerprint
   types.  The defined types are:

IANAは指紋タイプのためのSSHFP RRタイプのために新しい登録を開きました。 定義されたタイプは以下の通りです。

      0 is reserved
      1 is SHA-1

0は予約された1がSHA-1であるということです。

   Adding new reservations requires IETF consensus [4].

新しい予約を加えるのはIETFコンセンサス[4]を必要とします。

6.  Normative References

6. 引用規格

   [1]   Mockapetris, P., "Domain names - concepts and facilities", STD
         13, RFC 1034, November 1987.

[1]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日

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

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

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

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

   [4]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
         Considerations Section in RFCs", BCP 26, RFC 2434, October
         1998.

[4]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。

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

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

         Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
         "Resource Records for the DNS Security Extensions", RFC 4034,
         March 2005.

Arends、R.、Austein、R.、ラーソン、M.、マッシー、D.、およびS.が上昇したと「リソースはDNSセキュリティ拡張子のために記録します」、RFC4034、2005年3月。

         Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
         "Protocol Modifications for the DNS Security Extensions", RFC
         4035, March 2005.

Arends(R.、Austein、R.、ラーソン、M.、マッシー、D.、およびS.ローズ)は「DNSセキュリティ拡張子のための変更について議定書の中で述べます」、RFC4035、2005年3月。

   [6]   Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
         Protocol Architecture", RFC 4251, January 2006.

[6]YlonenとT.とC.Lonvick、エド、「セキュア・シェル(セキュアシェル (SSH))プロトコルアーキテクチャ」、RFC4251、1月2006日

   [7]   Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
         Transport Layer Protocol", RFC 4253, January 2006.

[7]YlonenとT.とC.Lonvick、エド、「セキュア・シェル(セキュアシェル (SSH))トランスポート層プロトコル」、RFC4253、1月2006日

7.  Informational References

7. 情報の参照

   [8]   Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document
         Roadmap", RFC 2411, November 1998.

[8] セイヤーとR.とDoraswamy、N.とR.グレン、「IPセキュリティドキュメント道路地図」、RFC2411、1998年11月。

Schlyter & Griffin          Standards Track                     [Page 7]

RFC 4255                DNS and SSH Fingerprints            January 2006

Schlyterとグリフィン規格は2006年1月にRFC4255DNSとセキュアシェル (SSH)指紋の跡をつけます[7ページ]。

   [9]   Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
         Wellington, "Secret Key Transaction Authentication for DNS
         (TSIG)", RFC 2845, May 2000.

[9] Vixie(P.、グドムンソン、O.、イーストレーク3番目、D.、およびB.ウェリントン、「DNS(TSIG)のための秘密鍵トランザクション認証」、RFC2845)は2000がそうするかもしれません。

   [10]  Eastlake 3rd, D., "DNS Request and Transaction Signatures
         ( SIG(0)s )", RFC 2931, September 2000.

[10] 2000年のイーストレークD.、「DNS要求とトランザクション署名(SIG(0)s)」、RFC2931 9月3日。

   [11]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
         Update", RFC 3007, November 2000.

[11] ウェリントン、2000年11月、B.、「安全なドメインネームシステム(DNS)ダイナミック・アップデート」RFC3007。

8.  Acknowledgements

8. 承認

   The authors gratefully acknowledge, in no particular order, the
   contributions of the following persons:

作者はどんな特定のオーダーでも感謝して以下の人々の貢献を承諾しません:

      Martin Fredriksson

マーチンFredriksson

      Olafur Gudmundsson

Olafurグドムンソン

      Edward Lewis

エドワード・ルイス

      Bill Sommerfeld

ビル・ゾンマーフェルト

Authors' Addresses

作者のアドレス

   Jakob Schlyter
   OpenSSH
   812 23rd Avenue SE
   Calgary, Alberta  T2G 1N8
   Canada

ジェイコブSchlyter OpenSSH812第23アベニューSEアルバータT2G 1N8カルガリー(カナダ)

   EMail: jakob@openssh.com
   URI:   http://www.openssh.com/

メール: jakob@openssh.com ユリ: http://www.openssh.com/

   Wesley Griffin
   SPARTA
   7075 Samuel Morse Drive
   Columbia, MD  21046
   USA

ウエスリーグリフィンスパルタ7075サミュエル・モースDrive MD21046コロンビア(米国)

   EMail: wgriffin@sparta.com
   URI:   http://www.sparta.com/

メール: wgriffin@sparta.com ユリ: http://www.sparta.com/

Schlyter & Griffin          Standards Track                     [Page 8]

RFC 4255                DNS and SSH Fingerprints            January 2006

Schlyterとグリフィン規格は2006年1月にRFC4255DNSとセキュアシェル (SSH)指紋の跡をつけます[8ページ]。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2006).

Copyright(C)インターネット協会(2006)。

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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.

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

Intellectual Property

知的所有権

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。

Acknowledgement

承認

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。

Schlyter & Griffin          Standards Track                     [Page 9]

Schlyterとグリフィン標準化過程[9ページ]