Network Working Group A. Niemi Request for Comments: 3310 Nokia Category: Informational J. Arkko V. Torvinen Ericsson September 2002 認証とキー合致(AKA）を使用したハイパーテキスト伝送プロトコル (HTTP)ダイジェスト認証 Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) 本文書の位置付け 本文書はインターネットコミュニティーに情報を提供するものである。いか なる種類のインターネット標準を規定するものでもない。本文書の配布に制 限はない。 Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. 要旨 本文書は、AKA（認証および鍵の合致、Authentication and Key Agreement） に基づく、HTTPダイジェストアクセス認証のためのワンタイムパスワード生 成メカニズムを規定する。HTTP認証フレームワークは、基本およびダイジェス トの2つの認証スキームを含む。双方のスキームは、アクセス認証のために、 共有秘密(shared secret)に基づくメカニズムを採用している。AKAメカニズ ムは、Universal Mobile Telecommunications System (UMTS)ネットワーク上 でユーザー認証とセッション鍵の配布を行う。AKAは、チャレンジ/応答に基 づく、対象暗号(symmetric cryptography)を使用するメカニズムである。 Niemi, et. al. Informational [Page 1] RFC 3310 HTTP Digest Authentication Using AKA September 2002 目次 1. イントロダクションおよびモチベーション . . . . . . . . . . . . 2 1.1 用語 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 述語規則 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. AKAメカニズム概要. . . . . . . . . . . . . . . . . . . . . . . 4 3. ダイジェストAKAの仕様 . . . . . . . . . . . . . . . . . . . . 5 3.1 Algorithm指示子 . . . . . . . . . . . . . . . . . . . . . . . 5 3.2 チャレンジの生成 . . . . . . . . . . . . . . . . . . . . . . . 6 3.3 クライアント認証 . . . . . . . . . . . . . . . . . . . . . . . 7 3.4 同期失敗 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.5 サーバー認証 . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. ダイジェストAKA操作の例. . . . . . . . . . . . . . . . . . . . 8 5. セキュリティの考慮 . . . . . . . . . . . . . . . . . . . . . . 12 5.1 ダイジェストAKAを使用したクライアント認証 . . . . . . . . . . 13 5.2 Nonce値の限定的用法 . . . . . . . . . . . . . . . . . . . . . 13 5.3 複数の認証スキームとアルゴリズム . . . . . . . . . . . . . . . 14 5.4 オンライン辞書攻撃 . . . . . . . . . . . . . . . . . . . . . . 14 5.5 セッション保護 . . . . . . . . . . . . . . . . . . . . . . . . 14 5.6 リプレイ防御 . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.7 AKAセキュリティの向上. . . . . . . . . . . . . . . . . . . . . 15 6. IANA条項 . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.1 登録テンプレート . . . . . . . . . . . . . . . . . . . . . . . 16 規範となる参考文献 . . . . . . . . . . . . . . . . . . . . . . 16 有益な参考文献 . . . . . . . . . . . . . . . . . . . . . . . . 16 A. 謝辞 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 著者の連絡先 . . . . . . . . . . . . . . . . . . . . . . . . . 17 完全な著作権表記 . . . . . . . . . . . . . . . . . . . . . . . 18 1. イントロダクションおよびモチベーション RFC2617(参考文献[2])で述べられているHTTP認証フレームワークは、基本お よびダイジェストの2つの認証スキームを含む。双方のスキームは、アクセス 認証のために、共有秘密(shared secret)に基づくメカニズムを採用している。 基本スキームは、ユーザーの信用証明書(credential)をプレーンテキストで 送信するので、本質的に安全ではない。ダイジェストスキームは、ユーザー の信用証明書を暗号ハッシュ(cryptographic hash)で隠蔽し、またそれに加 えて、限定的なメッセージの完全性(message integrity)を提供することによ り安全性を向上している。 AKA(参考文献[6])メカニズムは、Universal Mobile Telecommunications System (UMTS)ネットワーク上でユーザー認証とセッション鍵の配布を行う。AKAは、 チャレンジ/応答に基づく、対象暗号(symmetric cryptography)を使用するメ カニズムである。AKAは、UMTSのIM Services Identity Module (ISIM)内で動 作する。ISIMは、共有秘密の改竄耐性のあるストレージも提供する、スマー トカードに似たデバイス上に存在する。 Niemi, et. al. Informational [Page 2] RFC 3310 HTTP Digest Authentication Using AKA September 2002 本文書は、AKAパラメータのHTTPダイジェスト認証へのマッピングを規定する。 このマッピングは実質的に、ダイジェスト認証のためのワンタイムパスワー ド生成メカニズムとしてのAKAの利用を可能にする。 SIP(参考文献[3])認証フレームワークはHTTP認証フレームワークに厳密に従 うので、ダイジェストAKAは他のすべてのHTTPダイジェストの実例と同様にそ のまま適用可能である。 1.1 用語 この章では、本文書で使用する用語について説明する。 AKA 認証および鍵の合致(Authentication and Key Agreement)。 AuC 認証センター(Authentication Center)。GSMまたはUMTSネットワーク上で ユーザーを認可できる、モバイルネットワーク上のネットワークエレメン ト。 AUTN 認証トークン(Authentication Token)。AuCが生成する128ビット値。これ は、RANDパラメータと共に、クライアントのためにサーバーを認証する。 AUTS 認証トークン(Authentication Token)。SQN同期失敗が起こったときにク ライアントが生成する112ビット値。 CK 暗号鍵(Cipher Key)。暗号化のためのAKAセッション鍵。 IK 完全性鍵(Integrity Key)。完全性チェックのためのAKAセッション鍵。 ISIM IPマルチメディアサービス識別モジュール(IP Multimedia Services Identity Module)。 PIN 個人識別番号(Personal Identification Number)。ATMやスマートカード などで利用するために、一般的に割り当てられるパスコード。 RAND ランダムチャレンジ(Random Challenge)。SQNを使用してAuCが生成する。 RES 認証応答(Authentication Response)。ISIMが生成する。 Niemi, et. al. Informational [Page 3] RFC 3310 HTTP Digest Authentication Using AKA September 2002 SIM サブスクライバー識別モジュール(Subscriber Identity Module)。GSMに おけるISIM。 SQN シーケンス番号(Sequence Number)。AuCとISIMの双方がSQNの値を保持す る。 UMTS ユニバーサル モバイル テレコミュニケーション システム(Universal Mobile Telecommunication System)。 XRES 期待される認証応答(Expected Authentication Response)。成功する認証 において、これはRESに等しい。 1.2 述語規則 本文書では、次のキーワードはBCP14、RFC2119(参考文献[1])に記述されてい るとおりに解釈される。 「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、 「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」 2. AKAメカニズム概要 この章では、AKAの操作を詳述する。 1. ISIMと認証センター(AuC)のあいだで、事前に共有秘密 K が確立される。 この共有秘密はISIM内に保存される(ISIMはスマートカードに似た、改竄 耐性のあるデバイス上に存在する)。 2. ホームネットワークのAuCは、共有秘密 K とシーケンス番号 SQN に基づ いて、認証ベクター AV を生成する。認証ベクターは、ランダムチャレン ジ RAND、ネットワーク認証トークン AUTN、期待される認証結果 XRES、 完全性チェックのためのセッション鍵 IK、暗号化のためのセッション鍵 CK を含む。 3. 認証ベクターはサーバーにダウンロードされる。オプションで、サーバー は2つ以上の認証ベクターを含むAVのまとまりをダウンロードすることも できる。 4. サーバーは認証リクエストを生成する。このリクエストは、ランダムチャ レンジ RAND とネットワーク認証トークン AUTN を含む。 5. 認証リクエストはクライアントに配送される。 6. 共有秘密 K とシーケンス番号 SQN を使用して、クライアントはISIMでAUTN を検証する。検証が成功する場合、そのネットワークは認証されているこ とになる。それからクライアントは、共有秘密 K とランダムチャレンジ RAND を使用して、認証応答 RES を生成する。 Niemi, et. al. Informational [Page 4] RFC 3310 HTTP Digest Authentication Using AKA September 2002 7. 認証応答 RES はサーバーに配送される。 8. サーバーは認証応答 RES を期待される応答 XRES と比較する。2つが合致 する場合、ユーザーは正しく認証されたことになり、クライアントとサー バー間のこれ以降の通信を保護するために、セッション鍵 IK と CK を使 用できる。 AUTNを検証するとき、クライアントは、クライアントとサーバー間でシーケ ンス番号の同期が取れていないことを検知するかもしれない。この場合、ク ライアントは、共有秘密 K とクライアントのシーケンス番号 SQN を使用し て、同期パラメータAUTSを生成する。AUTSパラメータは認証応答中でネット ワークに配送され、同期されたシーケンス番号を用いて生成される認証ベク ターに基づいて、認証を再度試みることができる。 AKAメカニズムの仕様および暗号パラメータ AUTN、RES、IK、CK、AUTSについ ては、3GPP TS 33.102(参考文献[6])を参照のこと。 3. ダイジェストAKAの仕様 一般的に、ダイジェストAKAの操作はRFC2617(参考文献[2])のダイジェストの 操作と同じである。この章では、ダイジェストAKAがダイジェスト操作から拡 張されている部分について規定する。このセクション中の新規および変更さ れたシンタックスエレメントに対するAugmented BNF定義で使用される表記法 は、SIP(参考文献[3])で使用されているものと同じであり、このセクション で定義されていないすべてのエレメントは、SIPおよびそれが参照する文書で 定義されているとおりである。 3.1 Algorithm指示子 標準的なパスワードシステムではなくAKA認証を使用することをクライアント に指示するために、ダイジェストAKAでは、RFC2617で定義されているalgorithm 指示子を以下のように再定義する。 algorithm = "algorithm" EQUAL ( aka-namespace / algorithm-value ) aka-namespace = aka-version "-" algorithm-value aka-version = "AKAv" 1*DIGIT algorithm-value = ( "MD5" / "MD5-sess" / token ) algorithm ダイジェストおよびチェックサムを生成する際に使用されるアルゴリズム を示す文字列。この指示子が理解されない場合、nonceは無視されるべき [SHOULD]であり、代わりに別のチャレンジ(存在すれば)が使用されるべき である。デフォルトのaka-versionは「AKAv1」である。 Niemi, et. al. Informational [Page 5] RFC 3310 HTTP Digest Authentication Using AKA September 2002 IANAによって登録されたバージョン番号(参考文献[7])を用いることで、 更なるAKAバージョンを規定できる。algorithm指示子が存在しない場合、 それは「MD5」と仮定される。これは、ダイジェストパスワードを生成す るためにAKAが使用されないことを示す。 例： algorithm=AKAv1-MD5 使用されるRES値のエントロピーが制限されている(例：32ビットしかない) 場合、それ以降のリクエストと応答を認証するときに同じRES値を再使用 することは推奨されない[NOT RECOMMENDED]。そのようなRES値はワンタイ ムパスワードとしてのみ使用されるべき[SHOULD]であり、「MD5-sess」の ようなアルゴリズム(これは、認証のためのセッション鍵を生成すること によって、単一の鍵でハッシュされるマテリアルの量を制限する)は使用 されるべきではない[SHOULD NOT]。 3.2 チャレンジの生成 ダイジェストAKAにおいて、クライアントにAKA認証チャレンジを配送するた めに、RFC2617で定義されているnonce指示子が以下のように拡張される。 nonce = "nonce" EQUAL ( aka-nonce / nonce-value ) aka-nonce = LDQUOT aka-nonce-value RDQUOT aka-nonce-value = nonce 図1にあるように、AKA認証チャレンジ RAND、AKA AUTNトークン、および オプションでいくつかのサーバー固有データ、を結合したもののBase64 (参考文献[4])エンコーディングで埋められたパラメータ。 Niemi, et. al. Informational [Page 6] RFC 3310 HTTP Digest Authentication Using AKA September 2002 例： nonce="MzQ0a2xrbGtmbGtsZm9wb2tsc2tqaHJzZXNy9uQyMzMzMzQK=" 0 1 2 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | RAND | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | AUTN | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サーバーデータ... +-+-+-+-+-+-+-+-+-+-+-+ 図1:nonce値の生成 セクション3.4で定義されている「auts」パラメータ(有効なAKA AUTSパラメ ータを含む)を含むクライアント認証をサーバーが受信する場合、サーバーは クライアントへの新規チャレンジを生成するためにそれを使用しなければな らない[MUST]。AUTSが存在するとき、含まれている「response」パラメータ は、RESではなく空のパスワード(""というパスワード)を使用して計算される、 ということに注意すること。 3.3 クライアント認証 クライアントがダイジェストAKA認証チャレンジを受信するときは、「nonce 」パラメータからRANDおよびAUTNを抽出し、サーバーが提供したAUTNトーク ンを評価する。クライアントがAUTNでサーバーの認証に成功し、チャレンジ を生成する際に使用されたSQNが期待される範囲内にあると確定した場合、RAND チャレンジと共有秘密 K を用いてAKAアルゴリズムが開始される。 結果として得られるAKA RESパラメータは、RFC2617のresponse指示子を計算 するときに「password」として扱われる。 3.4 同期失敗 AKAシーケンス番号の同期失敗を示すため、およびAUTSトークンを使用してAuC でSQNを再同期するために、RFC2617で定義されている「Authorization」リク エストヘッダーの「digest-response」のために、以下の新しい指示子が定義 される。 Niemi, et. al. Informational [Page 7] RFC 3310 HTTP Digest Authentication Using AKA September 2002 auts = "auts" EQUAL auts-param auts-param = LDQUOT auts-value RDQUOT auts-value = auts base64エンコードされたAKA AUTSパラメータを運ぶ文字列。この指示子は、 サーバー側のSQNを再同期するために使用される。この指示子が存在する 場合、クライアントは信用証明書を計算するときにいかなるパスワードも 使用しない。その代わりにクライアントは、空のパスワード(""というパ スワード)を使用して信用証明書を計算しなければならない[MUST]。 例： auts="CjkyMzRfOiwg5CfkJ2UK=" 「auts」パラメータの受信時に、サーバーは共有秘密 K を使用してそのパラ メータ値の有効性を確認する。AuCのSQNを再同期するために、有効なAUTSパ ラメータが使用される。同期されたSQNは、それから、新鮮な認証ベクター AV を生成するために使用される。次に、これを用いてクライアントが再チャレ ンジされる。 3.5 サーバー認証 AKAがAKA AUTNトークンで固有の相互認証を提供するとはいえ、メッセージの 完全性を提供するために、ダイジェストで提供される相互認証メカニズムは 依然として有用であるかもしれない。 ダイジェストAKAにおいて、サーバーはAKA XRESパラメータを、RFC2617で定 義されている「Authentication-Info」ヘッダーの「response-auth」を計算 するときに「password」として使用する。 4. ダイジェストAKA操作の例 以下の図2は、SIPリクエスト(SIP REGISTERリクエスト)を認証する際のダイ ジェストAKAプロセスを説明するメッセージフローである。 Niemi, et. al. Informational [Page 8] RFC 3310 HTTP Digest Authentication Using AKA September 2002 クライアント サーバー | 1) REGISTER | |------------------------------------------------------>| | | | +-----------------------------+ | | サーバーはAKAアルゴリズムを | | | 開始し、RANDとAUTNを生成する| | +-----------------------------+ | | | 2) 401 Unauthorized | | WWW-Authenticate: Digest | | (RAND、AUTNが配送される) | |<------------------------------------------------------| | | +------------------------------------+ | | クライアントはISIM上でAKAアルゴリズ| | | ムを開始し、AUTNを検証し、RESとセッ| | | ション鍵を導き出す。 | | +------------------------------------+ | | | | 3) REGISTER | | Authorization: Digest (RESが使用される) | |------------------------------------------------------>| | | | +------------------------------+ | | サーバーは与えられたRESを確認| | | し、それが正しいとわかる。 | | +------------------------------+ | | | 4) 200 OK | | Authentication-Info: (XRESが使用される)| |<------------------------------------------------------| | | 図2:認証成功を示すメッセージフロー 1) 最初のリクエスト REGISTER sip:home.mobile.biz SIP/2.0 Niemi, et. al. Informational [Page 9] RFC 3310 HTTP Digest Authentication Using AKA September 2002 2) チャレンジを含む応答 SIP/2.0 401 Unauthorized WWW-Authenticate: Digest realm="RoamingUsers@mobile.biz", nonce="CjPk9mRqNuT25eRkajM09uTl9nM09uTl9nMz5OX25PZz==", qop="auth,auth-int", opaque="5ccc069c403ebaf9f0171e9517f40e41", algorithm=AKAv1-MD5 3) 信用証明書を含む応答 REGISTER sip:home.mobile.biz SIP/2.0 Authorization: Digest username="jon.dough@mobile.biz", realm="RoamingUsers@mobile.biz", nonce="CjPk9mRqNuT25eRkajM09uTl9nM09uTl9nMz5OX25PZz==", uri="sip:home.mobile.biz", qop=auth-int, nc=00000001, cnonce="0a4f113b", response="6629fae49393a05397450978507c4ef1", opaque="5ccc069c403ebaf9f0171e9517f40e41" 4) 成功応答 SIP/2.0 200 OK Authentication-Info: qop=auth-int, rspauth="6629fae49393a05397450978507c4ef1", cnonce="0a4f113b", nc=00000001 Niemi, et. al. Informational [Page 10] RFC 3310 HTTP Digest Authentication Using AKA September 2002 以下の図3は、同期失敗を含むダイジェストAKA認証プロセスを説明するメッ セージフローである。 クライアント サーバー | 1) REGISTER | |------------------------------------------------------>| | | | +-----------------------------+ | | サーバーはAKAアルゴリズムを | | | 開始し、RANDとAUTNを生成する| | +-----------------------------+ | | | 2) 401 Unauthorized | | WWW-Authenticate: Digest | | (RAND、AUTNが配送される) | |<------------------------------------------------------| | | +------------------------------------+ | | クライアントはISIM上でAKAアルゴリズ| | | ムを開始しAUTNを検証するが、それが | | | 無効なシーケンス番号を含むことを発 | | | 見する。クライアントはそれから、 | | | AUTSトークンを生成する。 | | +------------------------------------+ | | | | 3) REGISTER | | Authorization: Digest (AUTSが配送される) | |------------------------------------------------------>| | | | +-----------------------+ | | サーバーはAUTSとRAND | | | を使用して | | | 再同期を行う。 | | +-----------------------+ | | | 4) 401 Unauthorized | | WWW-Authenticate: Digest | | (再同期されたRANDと | | AUTNが配送される) | |<------------------------------------------------------| | | 図3:認証同期失敗を示すメッセージフロー Niemi, et. al. Informational [Page 11] RFC 3310 HTTP Digest Authentication Using AKA September 2002 1) 最初のリクエスト REGISTER sip:home.mobile.biz SIP/2.0 2) チャレンジを含む応答 SIP/2.0 401 Unauthorized WWW-Authenticate: Digest realm="RoamingUsers@mobile.biz", qop="auth", nonce="CjPk9mRqNuT25eRkajM09uTl9nM09uTl9nMz5OX25PZz==", opaque="5ccc069c403ebaf9f0171e9517f40e41", algorithm=AKAv1-MD5 3) 信用証明書を含む応答 REGISTER sip:home.mobile.biz SIP/2.0 Authorization: Digest username="jon.dough@mobile.biz", realm="RoamingUsers@mobile.biz", nonce="CjPk9mRqNuT25eRkajM09uTl9nM09uTl9nMz5OX25PZz==", uri="sip:home.mobile.biz", qop=auth, nc=00000001, cnonce="0a4f113b", response="4429ffe49393c02397450934607c4ef1", opaque="5ccc069c403ebaf9f0171e9517f40e41", auts="5PYxMuX2NOT2NeQ=" 4) 新しいチャレンジを含む応答 SIP/2.0 401 Unauthorized WWW-Authenticate: Digest realm="RoamingUsers@mobile.biz", qop="auth,auth-int", nonce="9uQzNPbk9jM05Pbl5Pbl5DIz9uTl9uTl9jM0NTHk9uXk==", opaque="dcd98b7102dd2f0e8b11d0f600bfb0c093", algorithm=AKAv1-MD5 5. セキュリティの考慮 一般的に、ダイジェストAKAは、HTTP認証(参考文献[2])と同じセキュリティ の脅威に対して脆弱である。この章では、関連する例外事項について議論す る。 Niemi, et. al. Informational [Page 12] RFC 3310 HTTP Digest Authentication Using AKA September 2002 5.1 ダイジェストAKAを使用したクライアント認証 AKAは一般に、(理論的な制限ではないが)通常は改竄耐性があるスマートカー ド内に存在するISIMアプリケーション上で実行される。カード上で認証が実 行されるのをホストデバイスが要求することを可能にする、ISIMへのインタ ーフェースが存在する。しかしながら、これらのインターフェースは、ISIM 外の長期秘密(long-term secret)へのアクセスを許可せず、ISIMにアクセス するデバイスがユーザーとISIMのあいだで共有されるPINコードを知っている ときに限り、認証を実行し得る。そのようなPINコードは、通常、ユーザー入 力から取得され、またそれは普通、デバイスの電源が入れられたときに要求 される。 安全なインターフェースを持つ改竄耐性のあるカードを使用することは、ホ ストデバイスを所有していたりソフトウェア中にトロイの木馬があっても、 長期秘密へのアクセスができないので、ダイジェストAKAが標準的なダイジェ ストの実装よりも通常は安全であることを意味する。PINスキームが使用され る場合、デバイスの電源が入れられたときに、ユーザーは認証もされる。し かしながら、最終的なダイジェストAKAの安全性には、従来のダイジェスト実 装と比べて違いがあるかもしれない(それらの実装が、ユーザーから受信した パスワードをキャッシュ/保存するかどうかに当然依存する)。 5.2 Nonce値の限定的用法 ダイジェストスキームは、request-digest値のジェネレータをシードするた めに、サーバーが指定するnonce値を使用する。特定のリソースのため、限ら れた期間あるいは限られた使用回数、あるいは他の何らかの制限で、特定の クライアントからだけ使用されるように、サーバーはnonceを自由に構築でき る。そうすることは、例えばリプレイ攻撃に対して提供される防御を強化す る。 ダイジェストAKAはnonce値の適用を特定のISIMに限定する。通常、ISIMは一 度に1つのクライアントデバイスにのみアクセス可能である。しかしながら、 特定のISIMに限定されているとはいえ、nonce値は強力で安全である。それに 加えて、これは、認証チャレンジが生成される前にサーバーがクライアント のアイデンティティを提供されることを必要とする。クライアントのアイデ ンティティが有効でない場合、アイデンティティを取得するために付加的な ラウンドトリップが必要になる。このようなケースは、AKAの同期失敗に似て いる。 サーバーは、すべての応答のAuthentication-Infoヘッダーフィールド中でnext-nonce 指示子を送信することにより、各nonce値が一度だけしか使用されないことを 可能にするかもしれない。しかしながら、他のアクセススキームに対して同 時に同じSQN空間が使用された場合、これは同期の失敗を引き起こすかもしれ ず、結果的にAKA中で何回か付加的なラウンドトリップをもたらす。 Niemi, et. al. Informational [Page 13] RFC 3310 HTTP Digest Authentication Using AKA September 2002 5.3 複数の認証スキームとアルゴリズム HTTP認証では、チャレンジに基づいて、ユーザーエージェントは自身が理解 できる最強の認証スキームを選択してユーザーに信用証明書を要求しなけれ ばならない[MUST]。 一般に、ダイジェストAKAが生成したパスワードを他のHTTP認証スキームで使 用することは、たとえrealm値または保護ドメインが一致したとしても、推奨 されない。これらの場合、パスワードは、代わりにエンドユーザーから要求 されるべきである。ダイジェストAKAのパスワードは、パスワードを平分で送 信するようなHTTP認証スキームで再使用してはならない[MUST NOT]。特に、AKA パスワードは、HTTP基本認証で再使用してはならない[MUST NOT]。 いくつかのアルゴリズムがサポートされている場合、1つのスキーム内ではこ れと同じ原則が適用されなければならない。いくつかの利用可能なアルゴリ ズムを持つHTTPダイジェストチャレンジを受信するクライアントは、それが 理解する最強のアルゴリズムを選択しなければならない[MUST]。例えば、 「AKAv1-MD5」のダイジェストは、「MD5」のダイジェストよりも強力である。 5.4 オンライン辞書攻撃 ユーザーが選択したパスワードは通常は非常に単純なので、辞書(参考文献[2]) に存在するHTTPダイジェストのパスワードをサーバーが受け入れるべきでな い、ということが提案されている。この潜在的な脅威は、HTTPダイジェストAKA には存在しない(アルゴリズムがISIMによって生成されたパスワードを使用す るので)。しかしながら、エンドユーザーはPINコードには依然として気をつ けなければならない。HTTPダイジェストAKAのパスワード要求がエンドユーザ ーに対して決して表示されないとはいえ、ユーザーはPINコードでISIMに対し て認証される。一般に知られている初期PINコードが、通常は製造段階でISIM に設定されるので、エンドユーザーがそれを変更しない場合は、認可されて いないユーザーがそのデバイスを使用できるかもしれないという危険性があ る。当然ながら、これには認可されていないユーザーがその物理デバイスに アクセスできること、およびエンドユーザーが初期PINコードを変更していな いことが必要になる。このため、エンドユーザーは、ISIMを受領したときにPIN コードを変更することが強く奨励される。 5.5 セッション保護 ダイジェストAKAは、完全性保護のためのセッション鍵(IK)および機密性保護 のためのセッション鍵(CK)を生成できる。本文書ではこれら追加の鍵の用法 を規定しないが、それらはHTTP認証または他の何らかのセキュリティメカニ ズム内で、付加的な安全性を生み出すために使用されるかもしれない。 Niemi, et. al. Informational [Page 14] RFC 3310 HTTP Digest Authentication Using AKA September 2002 5.6 リプレイ防御 AKAは、シーケンス番号がそれぞれの認証に対してトラックされることを、SQN パラメータで可能にする。これは、たとえRANDパラメータが2つの認証リクエ ストで偶然にも同じであったとしても、認証がリプレイから防御されること を可能にする。更に重要なことは、これが、ネットワークによって送信され た古い認証リクエストを攻撃者がリプレイする場合に対して、付加的な防御 を提供することである。クライアントは、リクエストが古いことを検知し、 認証を拒否できるだろう。中間一致(MitM)攻撃を行う者が、クライアントを だまして認証応答を提示させてからメッセージの一部を何か別のものに置き 換えようとする場合でも、これは、認証リクエストの活性(liveliness)を証 明する。言い換えると、ダイジェストAKAによってチャレンジされるクライア ントは、選択されたプレーンテキストによる攻撃に対して脆弱ではない。最 後に、頻繁なシーケンス番号のエラーは、改竄耐性のあるカードが複製され、 複数のデバイスで使用されている場合の攻撃を明らかにする。 シーケンス番号のトラッキングのマイナス面は、サーバーが、それの長期秘 密だけでなく、各ユーザーに対してより多くの情報を保持しなければならな い(すなわち、現在のSQN)ことである。しかしながら、この情報は一般的に、 SIPノードではなく専用の認証サーバーに保存される。 5.7 AKAセキュリティの向上 AKAは安全なメカニズムであると認知されているが、ダイジェストAKAはそれ を向上することができる。より明確に言うなら、認証中にクライアントとサ ーバー間で運ばれるAKAパラメータは、ダイジェストAKAを用いて、メッセー ジの他の部分と共に保護され得る。これはただのAKAでは不可能である。 6. IANA条項 本ドキュメントはセクション3.1で、aka-version名前空間を規定する。これ には、中心となる調整機関が必要とされる。この調整の任を負う機関は、IANA (Internet Assigned Numbers Authority)である。 本文書で定義されるデフォルトのaka-versionは「AKAv1」である。参考文献[5] で概説されているポリシーに従い、1より上のバージョンは専門家のレビュー によって割り当てられる。 IANAへの登録は、プレフィックス「AKAv」を含め、登録されるバージョン番 号を含まなければならない[MUST]。例えば、「AKAv2」の登録は有効であるか もしれないが、「F00v2」または「2」は無効である。更に登録は、その登録 を行うパーティの連絡先を含まなければならない[MUST]。 Niemi, et. al. Informational [Page 15] RFC 3310 HTTP Digest Authentication Using AKA September 2002 本文書はデフォルトのaka-versionを定義するので、aka-version値の最初のIANA 登録は「AKAv1」のエントリーを含む。 6.1 登録テンプレート To: ietf-digest-aka@iana.org Subject: Registration of a new AKA version Version identifier: (セクション3.1に述べられているような、有効なaka-version値を含 まなければならない。) Person & email address to contact for further: (登録を行う人(1人または複数)の連絡先を含まなければならない。) 規範となる参考文献 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. 有益な参考文献 [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [6] 3rd Generation Partnership Project, "Security Architecture (Release 4)", TS 33.102, December 2001. [7] http://www.iana.org, "Assigned Numbers". Niemi, et. al. Informational [Page 16] RFC 3310 HTTP Digest Authentication Using AKA September 2002 付録A 謝辞 Sanjoy Sen、Jonathan Rosenberg、Pete McCann、Tao Haukka、Ilkka Uusitalo、 Henry Haverinen、John Loughney、Allison Mankin、およびGreg Roseに感謝 したい。 著者の連絡先 Aki Niemi Nokia P.O. Box 301 NOKIA GROUP, FIN 00045 Finland Phone: +358 50 389 1644 EMail: aki.niemi@nokia.com Jari Arkko Ericsson Hirsalantie 1 Jorvas, FIN 02420 Finland Phone: +358 40 5079256 EMail: jari.arkko@ericsson.com Vesa Torvinen Ericsson Joukahaisenkatu 1 Turku, FIN 20520 Finland Phone: +358 40 7230822 EMail: vesa.torvinen@ericsson.fi Niemi, et. al. Informational [Page 17] RFC 3310 HTTP Digest Authentication Using AKA September 2002 完全な著作権表記 Copyright (C) The Internet Society (2002). All Rights Reserved. 本記述とその翻訳は複写し他に提供することができる。また論評を加えた派 生的製品や、この文書を説明したり、その実装を補助するもので、上記の著 作権表示およびこの節を付加するものはすべて、全体であってもその一部で あっても、いっさいの制約を課されること無く、準備、複製、発表、配布す ることができる。しかし、この文書自体にはいかなる方法にせよ、著作権表 示やインターネットソサエティもしくは他のインターネット関連団体への参 照を取り除くなどの変更を加えてはならない。 インターネット標準を開発す るために必要な場合は例外とされるが、その場合はインターネット標準化過 程で定義されている著作権のための手続きに従わなければならない。 またRFC を英語以外の言語に翻訳する必要がある場合も例外である。 以上に述べられた制限は永久的なものであり、インターネットソサエティも しくはその継承者および譲渡者によって破棄されることはない。 本文書とここに含まれた情報は「無保証(AS IS)」で提供され、インターネッ トソサエティおよびIETFは、この情報がいかなる権利も侵害していないとい う保証、商用利用および特定目的への適合性への保証を含め、また、これら だけに限らずすべての保証について、明示的もしくは暗黙的の保証は行われ ない。 謝辞 RFCエディターの活動のための資金は、現在インターネットソサエティによっ て提供されている。 --------------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただし、 この権利の設定は原文から新たな翻訳を作成し公開することを妨げるものではあり ません。本翻訳物は、本著作権表示を含めて改変しないことを条件に再配布を許可 します。翻訳の正確さについては一切保証しません。原文とあわせてご利用くだ さい。 2003年 --------------------------------------------------------------------------- Niemi, et. al. Informational [Page 18]