SCRAM - standard

このメカニズムには重大なセキュリティ上の懸念事項がいくつか存在しますが、TLSで保護されたチャレンジ・レスポンス認証機構を用いることで対処可能です。しかしながら、現在標準化が進められているチャレンジ・レスポンス認証機構は、いずれも広範な導入に必要な要件を満たしておらず、限られた用途でしか成功していません。

本仕様では、ソルト化チャレンジレスポンス認証機構（Salted Challenge Response Authentication Mechanism: SCRAM）と呼ばれる、SASL（Simple Authentication and Security Layer; RFC 4422）認証機構のファミリーについて説明します。SCRAMは、セキュリティ上の懸念事項に対処し、導入可能性の要件を満たしています。TLSまたは同等のセキュリティ層と組み合わせて使用することで、このファミリーのメカニズムは、アプリケーションプロトコル認証の現状を改善し、将来のアプリケーションプロトコル標準において実装必須のメカニズムとして適切な選択肢となる可能性があります。

1. はじめに

本仕様は、Salted Challenge Response Authentication Mechanism (SCRAM) と呼ばれる認証機構ファミリーについて記述するものです。SCRAMは、チャレンジレスポンス機構を従来の試みよりも広く導入するために必要な要件に対応しています（付録Aおよび付録Bを参照）。トランスポート層セキュリティ（TLS、RFC 5246を参照）または同等のセキュリティ層と組み合わせて使用することで、このファミリーのメカニズムはアプリケーションプロトコル認証の現状を改善し、将来のアプリケーションプロトコル標準において実装が必須となるメカニズムとして適切な選択肢となる可能性があります。

簡潔にするため、このファミリーのメカニズムには、現時点ではセキュリティ層のネゴシエーションは含まれていません RFC 4422。これは、TLSやSSHなどの外部セキュリティ層と併用することを想定しており、オプションで外部セキュリティ層へのチャネルバインディング RFC 5056 も備えています。

SCRAMは、本書では純粋なSASL（Simple Authentication and Security Layer）RFC4422メカニズムとして規定されていますが、SASLとGSS-API（Generic Security Service Application Program Interface）間の新しいブリッジである「GS2」RFC 5801に準拠しています。つまり、この文書ではSASLメカニズムとGSS-APIメカニズムの両方を定義しています。

SCRAMは以下のプロトコル機能を提供します。

認証データベースに保存されている認証情報だけでは、クライアントになりすますには不十分です。データベースが盗まれた場合でも、事前に保存された辞書攻撃を防ぐため、認証情報にはソルトが付与されています。

サーバーは、他のサーバーに対してクライアントになりすますことはできません（サーバーが承認したプロキシは例外です）。

このメカニズムにより、サーバーが承認したプロキシは、バックエンドサーバーに対するスーパーユーザー権限を必要とせずに使用できます。

相互認証はサポートされていますが、名前はクライアントのみに付与されます（つまり、サーバーには名前がありません）。

SASLメカニズムとして使用する場合、SCRAMはクライアントからサーバーへ認可ID（authentication identities RFC 4422、セクション2を参照）を転送できます。

SCRAM認証情報をLDAPに保存するための標準LDAPv3 RFC 4510属性は、別の文書で定義されています。RFC 5803を参照してください。

他のチャレンジ・レスポンス方式が十分ではないと考えられる理由の詳細については、付録Aを参照してください。この方式の設計の背後にある動機の詳細については、付録Bを参照してください。

2. この文書で使用される表記規則

この文書におけるキーワード「MUST（しなければならない）」、「MUST NOT（してはならない）」、「REQUIRED（必須）」、「SHALL（するべき）」、「SHALL NOT（するべきではない）」、「SHOULD（すべきである）」、「SHOULD NOT（すべきではない）」、「RECOMMENDED（推奨される）」、「MAY（してもよい）」、「OPTIONAL（選択できる）」は、RFC 2119 に記述されているとおりに解釈されます。

正式な構文は、RFC 5234 で定義されており、そのコアルールは RFC 5234 の付録 B で定義されています。

「C:」で始まる行はクライアントから送信され、「S:」で始まる行はサーバーから送信されます。1 つの「C:」または「S:」ラベルが複数の行に適用される場合は、行間の改行は編集上の明確化のみを目的としており、実際のプロトコル交換の一部ではありません。

2.1. 用語

本文書では、RFC4949（「インターネットセキュリティ用語集」）で定義されている用語を使用します。具体的には、認証、認証交換、認証情報、ブルートフォース、チャレンジレスポンス、暗号ハッシュ関数、辞書攻撃、盗聴、ハッシュ結果、鍵付きハッシュ、中間者攻撃、ノンス、一方向暗号化関数、パスワード、リプレイ攻撃、ソルトなどです。これらの用語に馴染みのない読者は、同用語集を参照してください。

以下に、いくつかの説明と追加の定義を示します。

認証情報 (Authentication information): SCRAMクライアントが主張するIDを検証するために使用される情報。SCRAM IDの認証情報は、サポートされている各暗号ハッシュ関数のソルト、反復回数、「StoredKey」、および「ServerKey」（アルゴリズムの概要で定義）で構成されます。

認証データベース(Authentication database): 特定のIDに関連付けられた認証情報を検索するために用いられるデータベース。アプリケーションプロトコルの場合、認証データベースとしてLDAPv3（RFC4510参照）が頻繁に用いられる。PPPや802.11xなどのネットワークレベルプロトコルの場合、RADIUS RFC2865がより一般的に用いられる。

Base64: RFC4648で定義されているエンコード機構。オクテット文字列の入力を、人間が容易に表示できるテキスト出力文字列に変換します。SCRAMにおけるBase64の使用は、空白を含まない標準形式に制限されます。

オクテット (Octet): 8ビットのバイト。

オクテット文字列(Octet string): 8 ビットのバイトのシーケンス。

ソルト (Salt): 一方向暗号化関数を適用する前にパスワードと組み合わせるランダムなオクテット文字列。この値は、認証データベースに保存されるパスワードを保護するために使用されます。