要約

  • RFC 3722はUnicodeのマッピング、NFKC正規化、禁止文字の検査を順に適用し、準備済みのUTF-8名をiSCSI実装がバイト単位で比較できるようにした。
  • 人の転記と簡素な機器の実装という両立しにくい要請への答えだが、なりすまし対策ではない。見た目の似た文字は別のままで、対象範囲はUnicode 3.2に固定されている。

ストレージ管理画面では同じに見える二つの名前が、ターゲットにとっては異なる文字列であることがある。ラベルや手順書から名前を入力する管理者と、受け取ったバイト列が設定済みターゲットに一致するかを判定する小型イニシエーターの間で、この差が問題になる。2004年4月に公開されたRFC 3722は、Internet Small Computer Systems Interface（iSCSI）の名前について、この境界を扱った。

設計上の期待は二つあった。国際化された名前を入力する人には、大文字小文字や文字の変種が予測可能に扱われることが望ましい。他方、簡素な機器や組み込み実装には、文字列を準備し、UTF-8に符号化して、そのオクテットを比較するという明確な規則が向く。実装ごとに独自の同値判定を許せば、同じに見える入力が異なるプロトコル値になりうる。言語や地域に依存する柔軟な照合を求めれば、実装は複雑になり、結果も予測しにくくなる。

RFC 3722が選んだのは、自由な文字列修正ではなく範囲の明確なプロファイルだ。文字レパートリーをUnicode 3.2に固定し、Stringprepの表B.1とB.2によるマッピングを行い、NFKC正規化を適用する。続いてC.1.1からC.9の禁止出力を検査し、双方向テキストの条件を確認する。この順序によって、入力を見た後で実装が都合のよい同値関係を作る余地を抑えている。

消える違いもあれば、残す違いもある。ユーザーインターフェースから入力されたASCII大文字は小文字に変換しなければならない。許可されるASCIIは小文字、数字、ハイフン、ピリオド、コロンで、空白は認められない。たとえば表意句点U+3002は禁止されている。ドメイン名入力の一部ではASCIIピリオドU+002Eと同等に扱われることがあっても、iSCSIプロファイルはその置換を引き継がない。

これは「Unicodeをすべて安全に整える」処理ではない。明示されたレパートリーと表に従って得る、特定の比較表現である。UTF-8の符号化規則は別の仕様にあり、iSCSI名の文法や命名権限に関する規則も別途確認が要る。RFC 3721は名前や探索の全体像を扱い、RFC 3722は文字列の準備を定める。準備に成功しても、アクセス権、現在の名前管理者、あるいはターゲットのネットワーク到達性が証明されるわけではない。

特に見落としやすいのは、RFC 3722が視覚的に似た文字を同一化しない点だ。ラテン文字と形の近いギリシャ文字やキリル文字、あるいはフォント上で似て見える字形は、人が取り違えても同じバイト列にはならない。セキュリティ節は、運用者やシステムの解釈が食い違えば、意図しないターゲットに接続したり、正当なターゲットに接続できなかったりする可能性を指摘する。これは想定される失敗の分析であり、実証済み攻撃の報告ではない。

このプロファイルで定義された変種を一つの表現へ寄せ、禁止文字を排除し、双方向文字列を検査することはできる。しかし、誰が命名権限を持つのか、画面に表示されたラベルが信用できるのか、紛らわしい名前を人が受け入れるべきかは決めない。そこには別の運用上・組織上の制御が必要だ。

RFC 3491のNameprepは、国際化ドメイン名用の別のStringprepプロファイルとして関連するが、iSCSI用プロファイルと同じではない。RFC 3454が枠組みを与え、RFC 3722がiSCSI向けの規則を選んだ。2014年のRFC 7143によるプロトコル統合も、RFC 3722のUnicode 3.2という歴史的前提を、あらゆる新しい識別子に適用すべき現在の勧告へ変えるものではない。

この標準が優先したのは、解釈の自由より再現性だった。実装者は明確な手順を得て、運用者は二つの入力がなぜ一致または拒否されるのかを説明できる。ただし、再現可能な比較は入力された文字列に対してのみ有効で、視覚的な偽装までは解決しない。残る教訓は「Unicodeならストレージ名も安全」ということではない。プロトコルは、どの違いを消し、何を拒否し、何を人と周辺の管理策に委ねるのかを明示すべきだということだ。

出典