Network Working Group M. Bellare Request for Comments: 4344 T. Kohno Category: Standards Track UC San Diego C. Namprempre Thammasat University January 2006 セキュア シェル (SSH) トランスポート層暗号モード このメモの位置づけ この文書は, インターネットコミュニティに対するインターネットの標準トラックプロトコルを定義している. また, 改善のための議論と示唆を求めている. このプロトコルの標準化の状態と状況は "Internet Official Protocol Standards" (STD 1) の現在の版を参照してほしい. このメモの配布は制限しない. 著作権情報 Copyright (C) The Internet Society (2006). 訳者: 春山 征吾 . 概要 現在のSSHトランスポートプロトコルの認証された暗号化部分がいくつかの攻撃に脆弱であることを研究者が発見した. この文書では, セキュアシェル (SSH) トランスポートプロトコルのための新しい対称暗号法を記述する. また, SSHの実装がどのくらいの頻度で鍵の再発行(rekey)すべきかの具体的な推奨を提供する. 目次 1イントロダクション ..........................................2 2. この文書で用いる表記 ...............................2 3. 鍵の再生成 ........................................................2 3.1. 鍵の再生成についての1番目の推奨 ..............................3 3.2. 鍵の再生成についての2番目の推奨 .............................3 4. 暗号モード ................................................3 5. IANA の考慮 .............................................6 6. セキュリティの考察 .........................................6 6.1. 鍵の再発行の考察 ....................................7 6.2. 暗号モードの考察 ...........................8 Normative References ...............................................9 Informative References ............................................10 Bellare, et al. Standards Track [Page 1] RFC 4344 SSH Transport Layer Encryption Modes January 2006 1イントロダクション SSH トランスポートプロトコルの対称部分は, カプセル化されたデータの秘匿と完全性を提供するために設計されている. しかし, 研究者 ([DAI,BKN1,BKN2]) が, [RFC4253]で記述されたSSH トランスポートプロトコルの対称部分にいくつかのセキュリティの問題を確認した. たとえば, [RFC4253]で定義された暗号モードは, 選択平文プライバシー攻撃に脆弱だ. また, 十分に鍵の再発行が行なわれないと, SSH トランスポートプロトコルは ペイロードデータの情報を漏らしてしまうかもしれない. 後者の性質は, 利用暗号モードに関係なく存在する. [BKN1,BKN2]で, Bellare と Kohno, Namprempre は, 選択平文, 選択暗号文, 反応攻撃(reaction attack) に対して秘匿と完全性を保持するために, SSH トランスポートプロトコルの対称部分をどう変更すればいいか示している. この文書は, [BKN1,BKN2] に記述された推奨を具体的に記述している. 2. この文書で用いる表記 この文書でのキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" は, [RFC-2119] で記述されているように解釈される. 利用しているデータのタイプと用語は, アーキテクチャ文書 [RFC4251] で定義されている. SSHトランスポートプロトコルは, トランスポート文書 [RFC4253] で定義されている. 3. 鍵の再生成 [RFC4253] の 9節は, 転送データ1GBごとにSSHの実装が鍵を再生成するよう示唆している. しかし, [RFC4253] は SSHの実装が十分頻繁に鍵を再生成しない場合におきうるすべての問題については議論していない. この節では, 鍵の再生成の間に許容できる暗号化の回数の上限をしっかりと与えることによって, [RFC4253]の示唆を強化する. 6節では, これらの再発行の推奨の動機にういてより詳しく議論する. この節は, 2つの推奨からなる. 簡単に言うと, 1番目の推奨はMAGタグからの情報の漏洩を防ぐため, 2番目はブロック暗号からの情報の漏洩を防ぐためのものだ. Bellare, et al. Standards Track [Page 2] RFC 4344 SSH Transport Layer Encryption Modes January 2006 注意: 基底にあるブロック暗号のブロックサイズと暗号化されたパケットの長さに依存して, 1番目の推奨が2番目の推奨を上書きするかもしれない. また逆もある. 3.1. 鍵の再生成についての1番目の推奨 MACタグから情報漏洩する可能性があるため, 少なくとも 2**32 のパケット発信ごとにSSHの実装は鍵の再生成をする必要がある. より明確に言うと, 鍵の交換の後で再び再生成をする前に 2**32個以上のパケットをSSHの実装は送らないほうがよい. また, 最後の鍵の再生成の操作をしてから2**32個以上のパケットを受信する前にSSHの実装は再生成を試みる必要がある. これを行なうために好ましい方法は, 最後の再生成操作の後に2**31個以上のパケットを受け取ったら鍵の再生成をすることだ. 3.2. 鍵の再生成についての2番目の推奨 ブロック暗号の誕生日の特性と暗号モードがいくつか存在するために, 実装は同じ暗号化鍵で多すぎるブロックを暗号化しないよう注意しなければならない. L をSSHの暗号法でのブロック暗号の(ビットでの)ブロック長とする (たとえばAESでは128). L が128以上の場合, 鍵の再発行の後でもう一度再発行するまでの間にSSHの実装は 2**(L/4)ブロック以上の暗号化をしないほうがよい. また, L が128 以上の場合, SSHの実装は 2**(L/4) ブロック以上を受信する前に鍵の再生成を強制的に行なわなければならない. Lが128未満の場合(3DES, Blowfish, CAST-128, IDEAなどの古い暗号の場合), 2**(L/4)ブロックごとの鍵の再生成は非常にコストが高い場合がある. この場合は, [RFC4253] の元々の推奨 (転送データ1GBバイトごとにすくなくとも1回鍵の再生成をする)に従うのがSSHの実装に取って望ましい. 注意: L が128次の場合, この節の推奨は 3.1節の推奨よりを上書きする. SSHの実装が より大きなブロックサイズのブロック暗号(たとえば 256-bitブロックのRijndael) を利用する場合, 3.1節の推奨がこの節の推奨を上書きするかもしれない(パケットの長さに依存する). 4. 暗号モード この文書は, SSHトランスポートプロトコルで利用する新しい暗号法を記述する. これらの暗号法は [RFC4253]の6.3節で記述されている暗号法に追加される. Bellare, et al. Standards Track [Page 3] RFC 4344 SSH Transport Layer Encryption Modes January 2006 [RFC4253] を思い出してください: SSH接続のそれぞれの方向の暗号法はそれぞれ独立に働く. また, 暗号化が行なわれている場合, パケットの packet length, padding length, payload, padding のフィールドは, 取り決められた暗号アリゴリズムによって暗号化されなければならない. さらに思い出してください: 暗号のブロックサイズが8byte以上の場合(次の方法のすべてに当てはまる), packet length, padding length, payload, padding を連結した全体の長さが, 暗号のブロックサイズの倍数でなければならない. この文書は, 次の新しい方法を定義する: aes128-ctr RECOMMENDED AES (Rijndael) in SDCTR mode, with 128-bit key aes192-ctr RECOMMENDED AES with 192-bit key aes256-ctr RECOMMENDED AES with 256-bit key 3des-ctr RECOMMENDED Three-key 3DES in SDCTR mode blowfish-ctr OPTIONAL Blowfish in SDCTR mode twofish128-ctr OPTIONAL Twofish in SDCTR mode, with 128-bit key twofish192-ctr OPTIONAL Twofish with 192-bit key twofish256-ctr OPTIONAL Twofish with 256-bit key serpent128-ctr OPTIONAL Serpent in SDCTR mode, with 128-bit key serpent192-ctr OPTIONAL Serpent with 192-bit key serpent256-ctr OPTIONAL Serpent with 256-bit key idea-ctr OPTIONAL IDEA in SDCTR mode cast128-ctr OPTIONAL CAST-128 in SDCTR mode, with 128-bit key ラベル -ctr は, ブロック暗号 を "stateful-decryption counter" (SDCTR) モードで利用することを示している. L を のビットでのブロック長とするstateful-decryption counter モードでは, 送信側と受信側の両方が内部のL-bitなカウンタ X を保持する. Xの初期値は([RFC4253]の7.2節で計算される) 初期IV である必要がある. 初期IVは L-bitのネットワークバイトオーダー符号無し整数として解釈される. X=(2**L)-1 のとき, "increment X" は "set X to 0" という伝統的な意味を持つ. 表記 を "XをL-bitのネットワークバイトオーダー文字列に変換する" という意味で用いる. 当然, 実装は, 内部的な値であるXを保持する方法で別の表現をしてもよい. たとえば, 実装は複数の符号なし32-bitカウンタとしてXを保持してよい. パケット P=P1||P2||...||Pn (P1, P2, ..., Pn はそれぞれ長さ L のブロック) を暗号化するため, 暗号化器は まず を で暗号化しブロック B1を得る. 次にブロック B1 を P1 と XORし 暗号文ブロック C1 を生成する.rtext block C1. そして カウンタ X をインクリメントする. パケット P に対応する全暗号文 C=C1||C2||...||Cn を生成するために, 後続のブロックに対してこのプロセスが繰替えされる. Bellare, et al. Standards Track [Page 4] RFC 4344 SSH Transport Layer Encryption Modes January 2006 注意: カウンタ X は暗号文に含まれない. さらに注意: 鍵ストリームは前処理でき, 暗号化は並列化できる. 暗号文 C=C1||C2||...||Cn を復号するには, (やはりXのコピーを自身で管理している)復号器が のコピーを で暗号化し ブロック B1 を生成し, B1 と C1 を XOR して P1を得る. 復号器はカウンタ X のコピーをインクリメントする. 以上のプロセスをそれぞれのブロックに繰り返して 平文パケットP=P1||P2||...||Pn を得る. 同様に, 鍵ストリームは前処理でき, 復号は並列化できる. "aes128-ctr" は, 128-bit 鍵を用いる AES (Advanced Encryption Standard, 以前は Rijndael) を使う [AES]. ブロックサイズは 16 byte だ. この時点で, 将来の仕様では aes128-ctr を要求されている(必須である)に格付けするようだ. このアルゴリズムの実装は非常に強く推奨されている. "aes192-ctr" は 192-bit の鍵を用いる AES を使う. "aes256-ctr" は 256-bit の鍵を用いる AES を使う. "3des-ctr" は 3つの鍵を用いる トリプルDES (encrypt-decrypt-encrypt) を使う. 鍵の最初の8byteを最初の暗号化に, 次の8byteを復号に, 続く8byteを最後の暗号化に用いる. 24byteの鍵データを必要とする(このうち 168 bit が実際に用いられる). ブロックサイズは 8 byte だ. このアルゴリズムは, [DES]で定義されている. "blowfish-ctr" は 256-bitの鍵を用いる Blowfish を使う [SCHNEIER]. ブロックサイズは 8 byte だ. (注意: [RFC4253]の "blowfish-cbc" は 128-bit鍵を用いる.) "twofish128-ctr" は 128-bit 鍵を用いる Twofish を使う [TWOFISH]. ブロックサイズは 16 byte だ. "twofish192-ctr" は 192-bit 鍵を用いる Twofish を使う. "twofish256-ctr" は 256-bit 鍵を用いる Twofish を使う. "serpent128-ctr" は 128-bit 鍵を用いる Serpent ブロック暗号 [SERPENT] を使う,ブロックサイズは 16 byte だ. "serpent192-ctr" は 192-bit 鍵を用いる Serpent を使う. Bellare, et al. Standards Track [Page 5] RFC 4344 SSH Transport Layer Encryption Modes January 2006 "serpent256-ctr" は 256-bit 鍵を用いる Serpent を使う. "idea-ctr" は IDEA 暗号を用いる [SCHNEIER]. ブロックサイズは 8byte だ. "cast128-ctr" は 128-bit 鍵を用いる CAST-128 暗号を使う [RFC2144]. ブロックサイズは 8 byte だ. 5. IANA の考慮 4節で定義された13の暗号アルゴリズムモードは, [RFC4250] の 4.11.1 節で確立された Secure Shell Encryption Algorithm Name registry に追加されている. 6. セキュリティの考察 この文書は, SSH トランスポートプロトコル [RFC4253] への新しい暗号法と推薦を記述している. [BKN1,BKN2] は以下を示している. SSHアプリケーションがこの文書で記述された方法と推薦を組み込めば, アプリケーションの対称暗号の部分は, 秘匿と完全性への攻撃の大部分に抵抗できる. この節は, この文書で記述された方法と推薦に対するセキュリティに関する動機と方法や推薦を採用しない場合に起こりえる結果についての実装者の理解を支援するさらなる動機と議論, セキュリティの証明は, 研究論文 [BKN1,BKN2] にある. 注意: [BKN1, BKN2]の文脈での"証明"の概念は, 実践指向の還元主義者のセキュリティの概念だ. 攻撃者がSSHトランスポートプロトコルの対称部分をなんらかの方法(たとえば選択暗号文攻撃)で破れる場合に 攻撃者はトランスポートプロトコルの基底となっている部分の対称部分(たとえば基底のブロック暗号やMAC)も破れるということだ. 基底の部分(AESやHMAC-SHA1のような)が安全だという合理的な仮定ができる場合, SSHプロトコルの対称部分への攻撃はほぼ成功しないだろう(さもなければ矛盾となる). 詳細は [BKN1,BKN2] を参照せよ. 特に, (AESのようにブロックの作成が安全でない場合でなければ) 攻撃はほとんど不可能で, まったく起こりえない. 注意: アプリケーション全体のセキュリティでは, 暗号はしばしば小さい(しかし重大な)役割のみを果している. SSH トランスポートプロトコルの場合, アプリケーションがSSHプロトコルの対称部分をこの文書の記述に正確に実装したとしても, アプリケーションはプロトコルに依存しない攻撃に脆弱かもしれない.(ひどい例を挙げると, アプリケーションが暗号鍵を保護されていないファイルに平文で保存する可能性がある) Bellare, et al. Standards Track [Page 6] RFC 4344 SSH Transport Layer Encryption Modes January 2006 結果として, この文書で記述した方法にセキュリティの証明があっても, これらの方法を実装したアプリケーションを開発する際には開発者は慎重に実行しなければならない. 6.1. 鍵の再発行の考察 この文書の3節で, 2つの鍵の再発行の推奨を示した: (1) 少なくとも 2**32 パケットごとの再発行, (2) 暗号化されたブロックが特定の数(たとえば, ブロック暗号のブロック長 L が少なくとも128 bitなら, 2**(L/4) ブロック) に逹したら再発行. 推奨(1)と(2)の動機は異なるので, それぞれの推奨について順番に考察する. 簡潔に言うと, (1) は SSHプロトコルの基底にあるMACからの情報漏洩を防ぐために設計されている. そして (2) はSSHプロトコルの基底にある暗号方式からの情報漏洩を防ぐために設計されている. 注意: 暗号法のブロック長 L と パケットごとの暗号化されたブロックの数によって, 推奨(1)が(2)を上書きするかもしれないし, また逆もある. 推奨 (1) は SSHの実装は少なくとも 2**32パケットごとに1度鍵の再生成をする必要があると主張している. 再生成の間にSSHトランスポートプロトコルによって2**32 パケット以上暗号化とMACが行なわれると, SSHトランスポートプロトコルは 再生攻撃や再順序攻撃(re-ordering attack)に脆弱となるかもしれない. 同じメッセージを1回より多く受け取ったり順番がおかしいメッセージを受け取るのを受信者に納得させることが攻撃者ができる, ということを意味する. さらに, 基底のMACがプロトコルのペイロードのデータについての情報を漏らしはじめる. より詳細には, 同じ 32-bitシーケンス番号([RFC 4253] の 4.4節) でMACされた2つのパケットのMACの衝突を探す. 衝突が見付かったら, それらの2つの暗号文のペイロードデータは, おそらく同一だ. 注意; 基底の暗号法の安全性に関係なくこの問題はおこる. さらに注意: 暗号化とMACの前の圧縮やランダムなパディングの利用は基底のMACからの情報漏洩のリスクを軽減するが, 圧縮やランダムなパディングの利用は情報漏洩を防ぐわけではない. 2**32パケットごとに少なくとも1度の鍵の再発行をしないと決める実装者は, この問題を理解する必要がある. この問題については, [BKN1,BKN2]でより詳しく議論されている. 推薦 (1) の代替手段の1つに, SSHトランスポートプロトコルのシーケンス番号を 32bitよりも長くすることがある. この文書では, シーケンス番号の長さを増やすことを示唆しない. こうすると, 古いバージョンのSSHプロトコルとの相互運用性を妨げるかもしれないからだ. 推薦(1)の別の代替手段に, 基本的なHMACから, 自身の内部カウンタを持つMACのような, 別のMACに切り替えることがある. Bellare, et al. Standards Track [Page 7] RFC 4344 SSH Transport Layer Encryption Modes January 2006 32-bitカウンタがプロトコルですでにあるので, このようなカウンタは, 2**32 パケットごとに一度インクリメントするだけでよいだろう. 推奨 (2) は, (ブロック暗号のブロックサイズ L が少なくとも128bitの場合に) 同じ鍵で 2**(L/4) より多くの暗号化をする前にSSHの実装が鍵を再生成すべきと述べている. この推奨は, 暗号法の基底のブロック暗号に対する誕生日攻撃のリスクを最小限にするために設計されている. たとえば, 同じ鍵でおおよそ 2**(L/2)のメッセージを暗号化すると, ステートフル復号カウンターモードに対する理論的な秘匿性への攻撃ができる. これらの誕生日攻撃のために, 実装者は長いブロック長の安全なブロック暗号を使うことが推奨される. また, 推奨 (2) は 同じ鍵で 2**L ブロックより多く暗号化する暗号者を保護するために設計されている. ここでの動機は次のとおり. 暗号者が SDCTRモードにで同じ鍵で 2**L より多い暗号化して鍵ストリームを再利用すると, 鍵ストリームの再利用が深刻な秘匿性への攻撃を導くことがある [SCHNEIER]. 6.2. 暗号モードの考察 [RFC4253] の元々のCBCモードベースの暗号法は, 選択平文攻撃に対して脆弱だと研究者は示した.[DAI, BKN1, BKN2]. この文書の4節で記述した新しいステートフル-復号 カウンターモード暗号法は, [RFC4253]で記述された元々の暗号法の安全な代替法として設計された. 多くの人がカウンターモードベースの暗号方式を避けている. 正しく利用しないと(鍵ストリームの繰り返しが許可されている場合など), カウンターモードは非常に危険となりうるからだ. 幸いにも, カウンターモードについての一般的な懸念はSSHには適用されない. 鍵の再生成の推奨とトランスポートプロトコルのMACで提供される追加の保護のおがけだ. この議論は, [BKN1,BKN2}のセキュリティの照明で定式化されている. 追加の注意として, (4節の)ステートフル復号カウンターモード暗号法の1つを使う場合, ([RFC4253]の4節)のSSHのパケットに含まれるpaddingはランダムでなくてもよい(ただしランダムのままでもよい). パケットごとに暗号学的に安全な疑似乱数バイト列を生成する必要がなくなる. カウンターモード暗号化の特徴の1つは, ブロック暗号のブロック長の倍数にメッセージをパディングする必要がないことだ. パディングしないメッセージがプロトコルのネットワークの消費を抑えうるにもかかわらず, この文書はブロック暗号のブロック長の倍数のパディングを要求する. Bellare, et al. Standards Track [Page 8] RFC 4344 SSH Transport Layer Encryption Modes January 2006 理由は(1) [RFC4253]のパケットの記述を変更しないため, (2) パケットのペイロードデータの長さの正確な情報を漏らさないため, だ. (16-byteブロックのブロック暗号の場合でさえパディングから8byteのネットワークの節約しかないので, (1) より ここでパディングの節約の推奨はしない.) ステートフル-復号カウンターモードに加えて, [BKN1,BNK2]は, SSHトランスポートプロトコルで利用するためのおそらく安全と思われる別の暗号法を記述している. しかし, 4節のステートフル-復号 カウンターモード法が[RFC4253]の危険な方法の好ましい代替だ. ステートフル-復号カウンターモードが(ネットワーク消費とパケットごとに必要な暗号操作の数の両方で)もっとも効率的だからだ. Normative References [AES] National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", Federal Information Processing Standards Publication 197, November 2001. [DES] National Institute of Standards and Technology, "Data Encryption Standard (DES)", Federal Information Processing Standards Publication 46-3, October 1999. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144, May 1997. [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, January 2006. [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006. [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006. [SCHNEIER] Schneier, B., "Applied Cryptography Second Edition: Protocols algorithms and source in code in C", Wiley, 1996. [SERPENT] Anderson, R., Biham, E., and Knudsen, L., "Serpent: A proposal for the Advanced Encryption Standard", NIST AES Proposal, 1998. Bellare, et al. Standards Track [Page 9] RFC 4344 SSH Transport Layer Encryption Modes January 2006 [TWOFISH] Schneier, B., et al., "The Twofish Encryptions Algorithm: A 128-bit block cipher, 1st Edition", Wiley, 1999. Informative References [BKN1] Bellare, M., Kohno, T., and Namprempre, C., "Authenticated Encryption in SSH: Provably Fixing the SSH Binary Packet Protocol", Ninth ACM Conference on Computer and Communications Security, 2002. [BKN2] Bellare, M., Kohno, T., and Namprempre, C., "Breaking and Provably Repairing the SSH Authenticated Encryption Scheme: A Case Study of the Encode-then-Encrypt-and-MAC Paradigm", ACM Transactions on Information and System Security, 7(2), May 2004. [DAI] Dai, W., "An Attack Against SSH2 Protocol", Email to the ietf-ssh@netbsd.org email list, 2002. Bellare, et al. Standards Track [Page 10] RFC 4344 SSH Transport Layer Encryption Modes January 2006 Authors' Addresses Mihir Bellare Department of Computer Science and Engineering University of California at San Diego 9500 Gilman Drive, MC 0404 La Jolla, CA 92093-0404 Phone: +1 858-534-8833 EMail: mihir@cs.ucsd.edu Tadayoshi Kohno Department of Computer Science and Engineering University of California at San Diego 9500 Gilman Drive, MC 0404 La Jolla, CA 92093-0404 Phone: +1 858-534-8833 EMail: tkohno@cs.ucsd.edu Chanathip Namprempre Thammasat University Faculty of Engineering Electrical Engineering Department Rangsit Campus, Klong Luang Pathumthani, Thailand 12121 EMail: meaw@alum.mit.edu Bellare, et al. Standards Track [Page 11] RFC 4344 SSH Transport Layer Encryption Modes January 2006 Full Copyright Statement 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. 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. 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. 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. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Bellare, et al. Standards Track [Page 12]