Secure Shell Working Group J. Schlyter Internet-Draft OpenSSH Expires: March 5, 2004 W. Griffin SPARTA September 5, 2003 # 訳者 春山征吾 haruyama@unixuser.org # 首藤さん shudo@shudo.net から ご示唆などを頂きました. Using DNS to Securely Publish SSH Key Fingerprints draft-ietf-secsh-dns-05.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 5, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract 概要 This document describes a method to verify SSH host keys using DNSSEC. The document defines a new DNS resource record that contains a standard SSH key fingerprint. この文書は, DNSSEC を利用して SSH ホスト鍵を検証する方法について 記述している. この文書は 標準 SSH 鍵 指紋を含む 新しい DNS のリソ-スレコ-ド を定義する. Schlyter & Griffin Expires March 5, 2004 [Page 1] Internet-Draft DNS and SSH Fingerprints September 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. SSH Host Key Verification . . . . . . . . . . . . . . . . . 3 2.1 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2 Implementation Notes . . . . . . . . . . . . . . . . . . . . 3 2.3 Fingerprint Matching . . . . . . . . . . . . . . . . . . . . 4 2.4 Authentication . . . . . . . . . . . . . . . . . . . . . . . 4 3. The SSHFP Resource Record . . . . . . . . . . . . . . . . . 4 3.1 The SSHFP RDATA Format . . . . . . . . . . . . . . . . . . . 5 3.1.1 Algorithm Number Specification . . . . . . . . . . . . . . . 5 3.1.2 Fingerprint Type Specification . . . . . . . . . . . . . . . 5 3.1.3 Fingerprint . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2 Presentation Format of the SSHFP RR . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 Normative References . . . . . . . . . . . . . . . . . . . . 8 Informational References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 9 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . 10 Schlyter & Griffin Expires March 5, 2004 [Page 2] Internet-Draft DNS and SSH Fingerprints September 2003 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 セキュリティ拡張についての基本的な理解を この文書では仮定される. 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", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "MAY" といった キ-ワ-ドは [RFC2119] に記述されているように解釈される. 2. SSH Host Key Verification 2. SSH ホスト鍵検証 2.1 Method 2.1 方法 Upon connection to a 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 Schlyter & Griffin Expires March 5, 2004 [Page 3] Internet-Draft DNS and SSH Fingerprints September 2003 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. クライアントの実装者はホスト鍵を検査するために使われる方法の 順序を選択するために使われる設定可能なポリシ-を提供する必要がある. この文書は 1 つの方法を定義する. DNS の指紋ストレ-ジ. SSH ア-キテクチャ [6] で定義されてる別の方法では, 鍵を保存したロ-カルファイル群を比較に使う. 将来定義されるだろう 他の方法は, LDAP や別のデ-タベ-スに指紋を格納することだろう. 設定可能なポリシ-は, どの方法を使いたいかと, どういう順序で 方法が優先されるべきかを管理者が決定することを許すだろう. 異なる方法をそれぞれどれくらい信用するかを決定することも許すだろう. 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 つの固有のシナリオに, クライアントがサ-バへの接続に FQDN を使わない場合がある. このシナリオでは, 実装者は, 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 署名そのもので検証を行なうクライアントは, 標準 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 a 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 TBA. SSHFP の RR タイプコ-ドは未定だ. Schlyter & Griffin Expires March 5, 2004 [Page 4] Internet-Draft DNS and SSH Fingerprints September 2003 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 / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 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 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. 相互運用のために, 可能な限りわずかな指紋の種類が予約されるべきだ. 追加の種類を予約する唯一の理由は セキュリティを増すことだ. 3.1.3 Fingerprint 3.1.3 指紋 Schlyter & Griffin Expires March 5, 2004 [Page 5] Internet-Draft DNS and SSH Fingerprints September 2003 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 つの番号 (アルゴリズムと 指紋の種類) に 16 進で表わされた指紋そのものが続くものからなる. 例えば: host.example. SSHFP 2 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. SSH ホスト鍵検証が SSHFP を必要とするように設定されたなら, SSH ホスト鍵の廃止は DNS の対応する SSHFP を除去することで 実行されるだろう. 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 Schlyter & Griffin Expires March 5, 2004 [Page 6] Internet-Draft DNS and SSH Fingerprints September 2003 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 検索パス, すなわち, 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 RR は 信頼された SIG RR によって認証されることを を委任する. 上で述べたように 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. DNSSEC は, DNS ゾ-ン管理者が署名した後でホスト鍵指紋の完全性を 保護するだけなので, 指紋は SSH のホスト管理者から DNS ゾ-ン管理者に完全に 転送されなければならない. これは, 管理者間で手動で行なわれてもいいし SSH サ-バとネ-ムサ-バの間での 安全な DNS 動的アップデ-ト [11] を使って自動的に行なわれてもよい. これは別の鍵が登録される状況と 異なることはない (例えば, 署名のための認証局へ証明書のリクエストを送るクライアントのように) ことを注記しておく. 5. IANA Considerations 5. IANA に関する考察 IANA needs to allocate a RR type code for SSHFP from the standard RR type space (type 44 requested). IANA は 標準 RR タイプ空間から SSHFP のための RR タイプコ-ドを 割当てる必要がある (タイプ 44 が要求されている) IANA needs to open a new registry for the SSHFP RR type for public key algorithms. Defined types are: IANA は公開鍵アルゴリズムのために SSHFP RR タイプのための新しいレジストリを 作る必要がある. 定義されたタイプは以下の通りだ: 0 is reserved 1 is RSA 2 is DSA Adding new reservations requires IETF consensus [4]. 新しい予約を追加するには IETF の同意が必要だ [4]. IANA needs to open a new registry for the SSHFP RR type for fingerprint types. Defined types are: IANA は指紋の種類のために SSHFP RR タイプのための新しいレジストリを 作る必要がある. 定義されたタイプは以下の通りだ: 0 is reserved 1 is SHA-1 Adding new reservations requires IETF consensus [4]. 新しい予約を追加するには IETF の同意が必要だ [4]. Schlyter & Griffin Expires March 5, 2004 [Page 7] Internet-Draft DNS and SSH Fingerprints September 2003 Normative References [1] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [2] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [5] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [6] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S. Lehtinen, "SSH Protocol Architecture", draft-ietf-secsh-architecture-14 (work in progress), July 2003. [7] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S. Lehtinen, "SSH Transport Layer Protocol", draft-ietf-secsh-transport-16 (work in progress), July 2003. Informational References [8] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998. [9] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000. [10] Eastlake, D., "DNS Request and Transaction Signatures ( SIG (0) s)", RFC 2931, September 2000. [11] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000. Schlyter & Griffin Expires March 5, 2004 [Page 8] Internet-Draft DNS and SSH Fingerprints September 2003 Authors' Addresses Jakob Schlyter OpenSSH 812 23rd Avenue SE Calgary, Alberta T2G 1N8 Canada EMail: jakob@openssh.com URI: http://www.openssh.com/ Wesley Griffin SPARTA 7075 Samuel Morse Drive Columbia, MD 21046 USA EMail: wgriffin@sparta.com URI: http://www.sparta.com/ Appendix A. Acknowledgements The authors gratefully acknowledge, in no particular order, the contributions of the following persons: Martin Fredriksson Olafur Gudmundsson Edward Lewis Bill Sommerfeld Schlyter & Griffin Expires March 5, 2004 [Page 9] Internet-Draft DNS and SSH Fingerprints September 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Schlyter & Griffin Expires March 5, 2004 [Page 10] Internet-Draft DNS and SSH Fingerprints September 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Schlyter & Griffin Expires March 5, 2004 [Page 11]