[要約] RFC 3310は、HTTP Digest認証を使用してAuthentication and Key Agreement（AKA）を実装するための仕様です。このRFCの目的は、セキュアな認証メカニズムを提供し、ユーザーの身元確認と通信の機密性を確保することです。
Network Working Group A. Niemi
Request for Comments: 3310 Nokia
Category: Informational J. Arkko
V. Torvinen
Ericsson
September 2002
Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA)
HyperText Transfer Protocol（HTTP）認証とキー契約（別名）を使用して認証を消化する
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
Abstract
概要
This memo specifies an Authentication and Key Agreement (AKA) based one-time password generation mechanism for Hypertext Transfer Protocol (HTTP) Digest access authentication. The HTTP Authentication Framework includes two authentication schemes: Basic and Digest. Both schemes employ a shared secret based mechanism for access authentication. The AKA mechanism performs user authentication and session key distribution in Universal Mobile Telecommunications System (UMTS) networks. AKA is a challenge-response based mechanism that uses symmetric cryptography.
このメモは、HyperText Transfer Protocol（HTTP）Digest Access認証の認証とキー契約（別名）ベースの1回限りのパスワード生成メカニズムを指定します。HTTP認証フレームワークには、基本とダイジェストの2つの認証スキームが含まれています。どちらのスキームも、アクセス認証のための共有秘密ベースのメカニズムを採用しています。AKAメカニズムは、Universal Mobile Telecommunications System（UMTS）ネットワークでユーザー認証とセッションキーディストリビューションを実行します。AKAは、対称的な暗号化を使用するチャレンジ応答ベースのメカニズムです。
Table of Contents
目次
1. Introduction and Motivation . . . . . . . . . . . . . . . . . 2
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. AKA Mechanism Overview . . . . . . . . . . . . . . . . . . . . 4
3. Specification of Digest AKA . . . . . . . . . . . . . . . . . 5
3.1 Algorithm Directive . . . . . . . . . . . . . . . . . . . . . 5
3.2 Creating a Challenge . . . . . . . . . . . . . . . . . . . . . 6
3.3 Client Authentication . . . . . . . . . . . . . . . . . . . . 7
3.4 Synchronization Failure . . . . . . . . . . . . . . . . . . . 7
3.5 Server Authentication . . . . . . . . . . . . . . . . . . . . 8
4. Example Digest AKA Operation . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5.1 Authentication of Clients using Digest AKA . . . . . . . . . . 13
5.2 Limited Use of Nonce Values . . . . . . . . . . . . . . . . . 13
5.3 Multiple Authentication Schemes and Algorithms . . . . . . . . 14
5.4 Online Dictionary Attacks . . . . . . . . . . . . . . . . . . 14
5.5 Session Protection . . . . . . . . . . . . . . . . . . . . . . 14
5.6 Replay Protection . . . . . . . . . . . . . . . . . . . . . . 15
5.7 Improvements to AKA Security . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6.1 Registration Template . . . . . . . . . . . . . . . . . . . . 16
Normative References . . . . . . . . . . . . . . . . . . . . . 16
Informative References . . . . . . . . . . . . . . . . . . . . 16
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18
The Hypertext Transfer Protocol (HTTP) Authentication Framework, described in RFC 2617 [2], includes two authentication schemes: Basic and Digest. Both schemes employ a shared secret based mechanism for access authentication. The Basic scheme is inherently insecure in that it transmits user credentials in plain text. The Digest scheme improves security by hiding user credentials with cryptographic hashes, and additionally by providing limited message integrity.
RFC 2617 [2]に記載されているHyperText転送プロトコル（HTTP）認証フレームワークには、基本とダイジェストの2つの認証スキームが含まれています。どちらのスキームも、アクセス認証のための共有秘密ベースのメカニズムを採用しています。基本的なスキームは、ユーザーの資格情報をプレーンテキストで送信するという点で、本質的に安全ではありません。Digestスキームは、暗号化されたハッシュでユーザーの資格情報を隠し、さらに限られたメッセージの整合性を提供することにより、セキュリティを改善します。
The Authentication and Key Agreement (AKA) [6] mechanism performs authentication and session key distribution in Universal Mobile Telecommunications System (UMTS) networks. AKA is a challenge-response based mechanism that uses symmetric cryptography. AKA is typically run in a UMTS IM Services Identity Module (ISIM), which resides on a smart card like device that also provides tamper resistant storage of shared secrets.
認証とキー契約（別名）[6]メカニズムは、ユニバーサルモバイルテレコミュニケーションシステム（UMTS）ネットワークで認証とセッションの重要な分布を実行します。AKAは、対称的な暗号化を使用するチャレンジ応答ベースのメカニズムです。AKAは通常、UMTS IM Services Identity Module（ISIM）で実行されます。これは、共有された秘密の抵抗を改ざんするストレージも提供するスマートカードのようなデバイスに存在します。
This document specifies a mapping of AKA parameters onto HTTP Digest authentication. In essence, this mapping enables the usage of AKA as a one-time password generation mechanism for Digest authentication.
このドキュメントは、HTTPダイジェスト認証への別名パラメーターのマッピングを指定します。本質的に、このマッピングにより、Digest認証のための1回限りのパスワード生成メカニズムとしてのAKAの使用が可能になります。
As the Session Initiation Protocol (SIP) [3] Authentication Framework closely follows the HTTP Authentication Framework, Digest AKA is directly applicable to SIP as well as any other embodiment of HTTP Digest.
セッション開始プロトコル（SIP）[3]認証フレームワークがHTTP認証フレームワークに密接に従うと、Digest AKAはSIPおよびHTTPダイジェストのその他の具体化に直接適用できます。
This chapter explains the terminology used in this document.
この章では、このドキュメントで使用されている用語について説明します。
AKA Authentication and Key Agreement.
AKA認証と重要な契約。
AuC Authentication Center. The network element in mobile networks that can authorize users either in GSM or in UMTS networks.
AUC認証センター。GSMまたはUMTSネットワークのいずれかでユーザーを承認できるモバイルネットワークのネットワーク要素。
AUTN Authentication Token. A 128 bit value generated by the AuC, which together with the RAND parameter authenticates the server to the client.
Autn認証トークン。AUCによって生成された128ビット値は、RANDパラメーターとともにサーバーをクライアントに認証します。
AUTS Authentication Token. A 112 bit value generated by the client upon experiencing an SQN synchronization failure.
Auts認証トークン。SQN同期障害が発生したときにクライアントが生成する112ビット値。
CK Cipher Key. An AKA session key for encryption.
CK暗号キー。暗号化のための別名セッションキー。
IK Integrity Key. An AKA session key for integrity check.
IKインテグリティキー。整合性チェックのための別名セッションキー。
ISIM IP Multimedia Services Identity Module.
ISIM IPマルチメディアサービスIDモジュール。
PIN Personal Identification Number. Commonly assigned passcodes for use with automatic cash machines, smart cards, etc.
個人識別番号をピン留めます。自動キャッシュマシン、スマートカードなどで使用するために一般的に割り当てられたパスコード。
RAND Random Challenge. Generated by the AuC using the SQN.
ランドランダムチャレンジ。SQNを使用してAUCによって生成されます。
RES Authentication Response. Generated by the ISIM.
Res認証応答。ISIMによって生成されます。
SIM Subscriber Identity Module. GSM counter part for ISIM.
SIMサブスクライバーIDモジュール。ISIMのGSMカウンターパーツ。
SQN Sequence Number. Both AuC and ISIM maintain the value of the SQN.
SQNシーケンス番号。AUCとISIMの両方がSQNの値を維持しています。
UMTS Universal Mobile Telecommunications System.
UMTSユニバーサルモバイル通信システム。
XRES Expected Authentication Response. In a successful authentication this is equal to RES.
XRESが予想される認証応答。成功した認証では、これはresに等しくなります。
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 BCP 14, RFC 2119 [1].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、BCP 14、RFC 2119 [1]に記載されているように解釈される。
This chapter describes the AKA operation in detail:
この章では、別名操作について詳しく説明します。
1. A shared secret K is established beforehand between the ISIM and the Authentication Center (AuC). The secret is stored in the ISIM, which resides on a smart card like, tamper resistant device.
1. 共有秘密Kは、ISIMと認証センター（AUC）の間に事前に確立されています。秘密はISIMに保管されており、ISIMは抵抗力のあるデバイスを改ざんするスマートカードに存在します。
2. The AuC of the home network produces an authentication vector AV, based on the shared secret K and a sequence number SQN. The authentication vector contains a random challenge RAND, network authentication token AUTN, expected authentication result XRES, a session key for integrity check IK, and a session key for encryption CK.
2. ホームネットワークのAUCは、共有されたシークレットKとAシーケンス番号SQNに基づいて、認証ベクトルAVを生成します。認証ベクトルには、ランダムチャレンジRAND、ネットワーク認証トークンAUTN、予想される認証結果XRES、整合性チェックIKのセッションキー、および暗号化CKのセッションキーが含まれています。
3. The authentication vector is downloaded to a server. Optionally, the server can also download a batch of AVs, containing more than one authentication vector.
3. 認証ベクトルはサーバーにダウンロードされます。オプションで、サーバーは、複数の認証ベクトルを含むAVSのバッチをダウンロードすることもできます。
4. The server creates an authentication request, which contains the random challenge RAND, and the network authenticator token AUTN.
4. サーバーは、ランダムチャレンジRANDとネットワーク認証機トークンAutnを含む認証要求を作成します。
5. The authentication request is delivered to the client.
5. 認証要求はクライアントに配信されます。
6. Using the shared secret K and the sequence number SQN, the client verifies the AUTN with the ISIM. If the verification is successful, the network has been authenticated. The client then produces an authentication response RES, using the shared secret K and the random challenge RAND.
6. 共有Secret Kとシーケンス番号SQNを使用して、クライアントはAUTNをISIMで検証します。検証が成功した場合、ネットワークは認証されています。その後、クライアントは、共有Secret KとランダムチャレンジRANDを使用して、認証応答RESを作成します。
7. The authentication response, RES, is delivered to the server.
7. 認証応答resはサーバーに配信されます。
8. The server compares the authentication response RES with the expected response, XRES. If the two match, the user has been successfully authenticated, and the session keys, IK and CK, can be used for protecting further communications between the client and the server.
8. サーバーは、認証応答RESを予想される応答XRESと比較します。2つの一致した場合、ユーザーは正常に認証されており、セッションキーであるIKとCKを使用して、クライアントとサーバー間のさらなる通信を保護できます。
When verifying the AUTN, the client may detect that the sequence numbers between the client and the server have fallen out of sync. In this case, the client produces a synchronization parameter AUTS, using the shared secret K and the client sequence number SQN. The AUTS parameter is delivered to the network in the authentication response, and the authentication can be tried again based on authentication vectors generated with the synchronized sequence number.
Autnを検証すると、クライアントはクライアントとサーバーの間のシーケンス番号が同期から落ちていることを検出する場合があります。この場合、クライアントは共有秘密Kとクライアントシーケンス番号SQNを使用して、同期パラメーターAUTSを生成します。Autsパラメーターは認証応答でネットワークに配信され、同期されたシーケンス番号で生成された認証ベクトルに基づいて認証を再試行できます。
For a specification of the AKA mechanism and the generation of the cryptographic parameters AUTN, RES, IK, CK, and AUTS, see reference 3GPP TS 33.102 [6].
AKAメカニズムの指定と暗号化パラメーターの生成Autn、Res、IK、CK、およびAutsについては、参照3GPP TS 33.102 [6]を参照してください。
In general, the Digest AKA operation is identical to the Digest operation in RFC 2617 [2]. This chapter specifies the parts in which Digest AKA extends the Digest operation. The notation used in the Augmented BNF definitions for the new and modified syntax elements in this section is as used in SIP [3], and any elements not defined in this section are as defined in SIP and the documents to which it refers.
一般に、Digest aka操作は、RFC 2617のダイジェスト操作と同じです[2]。この章では、Digest AKAがDigest操作を拡張する部品を指定します。このセクションの新しい修正された構文要素の拡張BNF定義で使用される表記は、SIP [3]で使用されているとおりであり、このセクションで定義されていない要素は、SIPおよびそれが参照するドキュメントで定義されているとおりです。
In order to direct the client into using AKA for authentication instead of the standard password system, the RFC 2617 defined algorithm directive is overloaded in Digest AKA:
クライアントに標準のパスワードシステムの代わりに認証用のAKAを使用するように指示するために、RFC 2617定義されたアルゴリズムディレクティブがダイジェストで過負荷になります。
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 A string indicating the algorithm used in producing the digest and the checksum. If the directive is not understood, the nonce SHOULD be ignored, and another challenge (if one is present) should be used instead. The default aka-version is "AKAv1".
アルゴリズムダイジェストとチェックサムの生成に使用されるアルゴリズムを示す文字列。指令が理解されていない場合、非CEは無視され、代わりに別の課題（存在する場合）を使用する必要があります。デフォルトの別名バージョンは「AKAV1」です。
Further AKA versions can be specified, with version numbers assigned by IANA [7]. When the algorithm directive is not present, it is assumed to be "MD5". This indicates, that AKA is not used to produce the Digest password.
さらに別名バージョンを指定でき、バージョン番号はIANA [7]によって割り当てられています。アルゴリズム指令が存在しない場合、「MD5」であると想定されます。これは、別名がダイジェストパスワードの作成に使用されていないことを示しています。
Example:
例：
algorithm=AKAv1-MD5
アルゴリズム= akav1-md5
If the entropy of the used RES value is limited (e.g., only 32 bits), reuse of the same RES value in authenticating subsequent requests and responses is NOT RECOMMENDED. Such a RES value SHOULD only be used as a one-time password, and algorithms such as "MD5-sess", which limit the amount of material hashed with a single key, by producing a session key for authentication, SHOULD NOT be used.
使用済みのRES値のエントロピーが制限されている場合（たとえば、32ビットのみ）、後続のリクエストと応答を認証する際に同じRES値を再利用することは推奨されません。このようなRES値は、1回限りのパスワードとしてのみ使用する必要があります。「MD5-SESS」などのアルゴリズムは、認証用のセッションキーを生成することにより、単一のキーでハッシュした材料の量を制限しますが、使用しないでください。
In order to deliver the AKA authentication challenge to the client in Digest AKA, the nonce directive defined in RFC 2617 is extended:
Digest AKAでクライアントにAKA認証チャレンジを提供するために、RFC 2617で定義されているNonCEディレクティブが拡張されます。
nonce = "nonce" EQUAL ( aka-nonce
/ nonce-value )
aka-nonce = LDQUOT aka-nonce-value RDQUOT
aka-nonce-value = <base64 encoding of RAND, AUTN, and
server specific data>
nonce A parameter, which is populated with the Base64 [4] encoding of the concatenation of the AKA authentication challenge RAND, the AKA AUTN token, and optionally some server specific data, as in Figure 1.
Nonceパラメーター。これは、図1のように、AKA Authentication Challenge Rand、AKA Autn Token、およびオプションでいくつかのサーバー固有のデータの連結をbase64 [4]エンコードします。
Example:
例：
nonce="MzQ0a2xrbGtmbGtsZm9wb2tsc2tqaHJzZXNy9uQyMzMzMzQK="
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 |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Server Data...
+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Generating the nonce value.
図1：NonCe値の生成。
If the server receives a client authentication containing the "auts" parameter defined in Section 3.4, that includes a valid AKA AUTS parameter, the server MUST use it to generate a new challenge to the client. Note that when the AUTS is present, the included "response" parameter is calculated using an empty password (password of ""), instead of a RES.
セクション3.4で定義されている「AUTS」パラメーターを含むクライアント認証をサーバーが受信した場合、有効なAUTSパラメーターを含む、サーバーはそれを使用してクライアントに新しい課題を生成する必要があります。Autsが存在する場合、sresの代わりに空のパスワード（ ""）を使用して「応答」パラメーターが計算されることに注意してください。
When a client receives a Digest AKA authentication challenge, it extracts the RAND and AUTN from the "nonce" parameter, and assesses the AUTN token provided by the server. If the client successfully authenticates the server with the AUTN, and determines that the SQN used in generating the challenge is within expected range, the AKA algorithms are run with the RAND challenge and shared secret K.
クライアントがDigest AKA Authentication Challengeを受信すると、「NonCe」パラメーターからRANDとAUTNを抽出し、サーバーが提供するAUTNトークンを評価します。クライアントがAUTNでサーバーを正常に認証し、チャレンジの生成に使用されるSQNが予想範囲内であると判断した場合、別名アルゴリズムはRANDチャレンジと共有Secret Kで実行されます。
The resulting AKA RES parameter is treated as a "password" when calculating the response directive of RFC 2617.
結果の別名RESパラメーターは、RFC 2617の応答指令を計算する際に「パスワード」として扱われます。
For indicating an AKA sequence number synchronization failure, and to re-synchronize the SQN in the AuC using the AUTS token, a new directive is defined for the "digest-response" of the "Authorization" request header defined in RFC 2617:
AKAシーケンス番号の同期障害を示すため、およびAutsトークンを使用してAUCのSQNを再同期させるために、RFC 2617：で定義された「認証」要求ヘッダーの「消化」リクエストヘッダーの「ダイジェスト応答」に対して新しい指令が定義されています。
auts = "auts" EQUAL auts-param
auts-param = LDQUOT auts-value RDQUOT
auts-value = <base64 encoding of AUTS>
auts A string carrying a base64 encoded AKA AUTS parameter. This directive is used to re-synchronize the server side SQN. If the directive is present, the client doesn't use any password when calculating its credentials. Instead, the client MUST calculate its credentials using an empty password (password of "").
auts base64エンコードされたautsパラメーターを運ぶ文字列。この指令は、サーバー側のSQNを再同期するために使用されます。指令が存在する場合、クライアントは資格情報を計算するときにパスワードを使用しません。代わりに、クライアントは空のパスワード（ ""のパスワード）を使用して資格情報を計算する必要があります。
Example:
例：
auts="CjkyMzRfOiwg5CfkJ2UK="
auts = "cjkymzrfoiwg5cfkj2uk ="
Upon receiving the "auts" parameter, the server will check the validity of the parameter value using the shared secret K. A valid AUTS parameter is used to re-synchronize the SQN in the AuC. The synchronized SQN is then used to generate a fresh authentication vector AV, with which the client is then re-challenged.
「Auts」パラメーターを受信すると、サーバーは共有Secret Kを使用してパラメーター値の有効性を確認します。有効なAutsパラメーターを使用して、AUCのSQNを再同期させます。次に、同期されたSQNを使用して、新鮮な認証ベクトルAVを生成し、クライアントが再挑戦します。
Even though AKA provides inherent mutual authentication with the AKA AUTN token, mutual authentication mechanisms provided by Digest may still be useful in order to provide message integrity.
AKAは、別名Autn Tokenに固有の相互認証を提供しますが、Digestによって提供される相互認証メカニズムは、メッセージの整合性を提供するために依然として役立つ場合があります。
In Digest AKA, the server uses the AKA XRES parameter as "password" when calculating the "response-auth" of the "Authentication-Info" header defined in RFC 2617.
DIGEST別名では、サーバーは、RFC 2617で定義された「認証INFO」ヘッダーの「応答auth」を計算するときに、「パスワード」としてxresパラメーターを「パスワード」として使用します。
Figure 2 below describes a message flow describing a Digest AKA process of authenticating a SIP request, namely the SIP REGISTER request.
以下の図2は、SIPリクエストを認証するDigest、つまりSIPレジスタリクエストを認証するプロセスを説明するメッセージフローを説明しています。
Client Server
クライアントサーバー
| 1) REGISTER |
|------------------------------------------------------>|
| |
| +-----------------------------+
| | Server runs AKA algorithms, |
| | generates RAND and AUTN. |
| +-----------------------------+
| |
| 2) 401 Unauthorized |
| WWW-Authenticate: Digest |
| (RAND, AUTN delivered) |
|<------------------------------------------------------|
| |
+------------------------------------+ |
| Client runs AKA algorithms on ISIM,| |
| verifies AUTN, derives RES | |
| and session keys. | |
+------------------------------------+ |
| |
| 3) REGISTER |
| Authorization: Digest (RES is used) |
|------------------------------------------------------>|
| |
| +------------------------------+
| | Server checks the given RES, |
| | and finds it correct. |
| +------------------------------+
| |
| 4) 200 OK |
| Authentication-Info: (XRES is used) |
|<------------------------------------------------------|
| |
Figure 2: Message flow representing a successful authentication.
図2：成功した認証を表すメッセージフロー。
1) Initial request
1) 初期リクエスト
REGISTER sip:home.mobile.biz SIP/2.0
登録SIP：home.mobile.biz sip/2.0
2) Response containing a challenge
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) Request containing credentials
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) Successful response
4) 成功した応答
SIP/2.0 200 OK Authentication-Info: qop=auth-int, rspauth="6629fae49393a05397450978507c4ef1", cnonce="0a4f113b", nc=00000001
sip/2.0 200 ok authentication-info：qop = auth-int、rspauth = "6629393a05397450978507c4ef1"、cnonce = "0a4f113b"、nc = 00000001
Figure 3 below describes a message flow describing a Digest AKA authentication process, in which there is a synchronization failure.
以下の図3は、同期の障害があるダイジェストAKA認証プロセスを説明するメッセージフローを示しています。
Client Server
クライアントサーバー
| 1) REGISTER |
|------------------------------------------------------>|
| |
| +-----------------------------+
| | Server runs AKA algorithms, |
| | generates RAND and AUTN. |
| +-----------------------------+
| |
| 2) 401 Unauthorized |
| WWW-Authenticate: Digest |
| (RAND, AUTN delivered) |
|<------------------------------------------------------|
| |
+------------------------------------+ |
| Client runs AKA algorithms on ISIM,| |
| verifies the AUTN, but discovers | |
| that it contains an invalid | |
| sequence number. The client then | |
| generates an AUTS token. | |
+------------------------------------+ |
| |
| 3) REGISTER |
| Authorization: Digest (AUTS is delivered) |
|------------------------------------------------------>|
| |
| +-----------------------+
| | Server performs |
| | re-synchronization |
| | using AUTS and RAND. |
| +-----------------------+
| |
| 4) 401 Unauthorized |
| WWW-Authenticate: Digest |
| (re-synchronized RAND, |
| AUTN delivered) |
|<------------------------------------------------------|
| |
Figure 3: Message flow representing an authentication synchronization failure.
図3：認証同期障害を表すメッセージフロー。
1) Initial request
1) 初期リクエスト
REGISTER sip:home.mobile.biz SIP/2.0
登録SIP：home.mobile.biz sip/2.0
2) Response containing a challenge
2) チャレンジを含む応答
SIP/2.0 401 Unauthorized
WWW-Authenticate: Digest
realm="RoamingUsers@mobile.biz",
qop="auth",
nonce="CjPk9mRqNuT25eRkajM09uTl9nM09uTl9nMz5OX25PZz==",
opaque="5ccc069c403ebaf9f0171e9517f40e41",
algorithm=AKAv1-MD5
3) Request containing credentials
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) Response containing a new challenge
4) 新しい課題を含む応答
SIP/2.0 401 Unauthorized
WWW-Authenticate: Digest
realm="RoamingUsers@mobile.biz",
qop="auth,auth-int",
nonce="9uQzNPbk9jM05Pbl5Pbl5DIz9uTl9uTl9jM0NTHk9uXk==",
opaque="dcd98b7102dd2f0e8b11d0f600bfb0c093",
algorithm=AKAv1-MD5
In general, Digest AKA is vulnerable to the same security threats as HTTP authentication [2]. This chapter discusses the relevant exceptions.
一般に、Digest AKAはHTTP認証と同じセキュリティの脅威に対して脆弱です[2]。この章では、関連する例外について説明します。
AKA is typically -- though this isn't a theoretical limitation -- run on an ISIM application that usually resides in a tamper resistant smart card. Interfaces to the ISIM exist, which enable the host device to request authentication to be performed on the card. However, these interfaces do not allow access to the long-term secret outside the ISIM, and the authentication can only be performed if the device accessing the ISIM has knowledge of a PIN code, shared between the user and the ISIM. Such PIN codes are typically obtained from user input, and are usually required when the device is powered on.
AKAは通常、これは理論的な制限ではありませんが、通常は耐性のあるスマートカードに留まるISIMアプリケーションで実行されます。ISIMへのインターフェイスが存在します。これにより、ホストデバイスはカードで認証を実行することを要求できます。ただし、これらのインターフェイスでは、ISIM以外の長期的な秘密へのアクセスは許可されておらず、ISIMにアクセスするデバイスにユーザーとISIMの間で共有されたPINコードの知識がある場合にのみ、認証を実行できます。このようなピンコードは通常、ユーザー入力から取得され、通常、デバイスの電源を入れているときに必要です。
The use of tamper resistant cards with secure interfaces implies that Digest AKA is typically more secure than regular Digest implementations, as neither possession of the host device nor Trojan Horses in the software give access to the long term secret. Where a PIN scheme is used, the user is also authenticated when the device is powered on. However, there may be a difference in the resulting security of Digest AKA, compared to traditional Digest implementations, depending of course on whether those implementations cache/store passwords that are received from the user.
安全なインターフェイスを備えたタンパー抵抗カードの使用は、Digest AKAが通常、通常のダイジェストの実装よりも安全であることを意味します。ソフトウェア内のホストデバイスの所有もトロイの木馬も長期的な秘密にアクセスできないためです。ピンスキームが使用される場合、デバイスの電源を入れたときにユーザーも認証されます。ただし、ユーザーから受信されたパスワードをキャッシュ/ストアでキャッシュ/ストアするかどうかに応じて、従来のダイジェストの実装と比較して、Digest AKAの結果として生じるセキュリティに違いがある場合があります。
The Digest scheme uses server-specified nonce values to seed the generation of the request-digest value. The server is free to construct the nonce in such a way, that it may only be used from a particular client, for a particular resource, for a limited period of time or number of uses, or any other restrictions. Doing so strengthens the protection provided against, for example, replay attacks.
Digestスキームは、サーバー指定のNonCE値を使用して、リクエストダイジスト値の生成をシードします。サーバーは、特定のクライアント、特定のリソース、限られた期間または使用数、またはその他の制限のためにのみ使用されるように、そのような方法でNonCEを自由に構築できます。そうすることで、たとえばリプレイ攻撃から提供される保護が強化されます。
Digest AKA limits the applicability of a nonce value to a particular ISIM. Typically, the ISIM is accessible only to one client device at a time. However, the nonce values are strong and secure even though limited to a particular ISIM. Additionally, this requires that the server is provided with the client identity before an authentication challenge can be generated. If a client identity is not available, an additional round trip is needed to acquire it. Such a case is analogous to an AKA synchronization failure.
Digest別名は、NonCe値の適用性を特定のISIMに制限します。通常、ISIMは、一度に1つのクライアントデバイスにのみアクセスできます。ただし、特定のISIMに限定されていても、NonCE値は強く、安全です。さらに、これには、認証チャレンジを生成する前に、サーバーにクライアントIDが提供される必要があります。クライアントのIDが利用できない場合は、それを取得するために追加の往復が必要です。このような場合は、別名同期障害に類似しています。
A server may allow each nonce value to be used only once by sending a next-nonce directive in the Authentication-Info header field of every response. However, this may cause a synchronization failure, and consequently some additional round trips in AKA, if the same SQN space is also used for other access schemes at the same time.
サーバーは、すべての応答の認証INFOヘッダーフィールドに次のノンスディレクティブを送信することにより、各NonCE値を1回だけ使用できるようにする場合があります。ただし、これにより同期障害が発生する可能性があり、その結果、同じSQNスペースが同時に他のアクセススキームにも使用されている場合、別名での追加のラウンドトリップが発生する可能性があります。
In HTTP authentication, a user agent MUST choose the strongest authentication scheme it understands and request credentials from the user, based upon that challenge.
HTTP認証では、ユーザーエージェントは、その課題に基づいて、理解している最強の認証スキームを選択し、ユーザーから資格情報を要求する必要があります。
In general, using passwords generated by Digest AKA with other HTTP authentication schemes is not recommended even though the realm values or protection domains would coincide. In these cases, a password should be requested from the end-user instead. Digest AKA passwords MUST NOT be re-used with such HTTP authentication schemes, which send the password in clear. In particular, AKA passwords MUST NOT be re-used with HTTP Basic.
一般に、他のHTTP認証スキームを使用してDigestによって生成されたパスワードを使用することは、レルム値または保護ドメインが一致しても推奨されません。これらの場合、代わりにエンドユーザーからパスワードを要求する必要があります。Digest AKAパスワードは、そのようなHTTP認証スキームで再利用してはなりません。これにより、パスワードをクリアに送信します。特に、別名パスワードをHTTP Basicで再利用してはなりません。
The same principle must be applied within a scheme if several algorithms are supported. A client receiving an HTTP Digest challenge with several available algorithms MUST choose the strongest algorithm it understands. For example, Digest with "AKAv1-MD5" would be stronger than Digest with "MD5".
いくつかのアルゴリズムがサポートされている場合、同じ原則をスキーム内に適用する必要があります。いくつかの利用可能なアルゴリズムを使用してHTTPダイジェストチャレンジを受けるクライアントは、理解している最も強力なアルゴリズムを選択する必要があります。たとえば、「AKAV1-MD5」を使用したダイジェストは、「MD5」でダイジェストよりも強くなります。
Since user-selected passwords are typically quite simple, it has been proposed that servers should not accept passwords for HTTP Digest, which are in the dictionary [2]. This potential threat does not exist in HTTP Digest AKA because the algorithm will use ISIM originated passwords. However, the end-user must still be careful with PIN codes. Even though HTTP Digest AKA password requests are never displayed to the end-user, she will be authenticated to the ISIM via a PIN code. Commonly known initial PIN codes are typically installed to the ISIM during manufacturing and if the end-users do not change them, there is a danger that an unauthorized user may be able to use the device. Naturally this requires that the unauthorized user has access to the physical device, and that the end-user has not changed the initial PIN code. For this reason, end-users are strongly encouraged to change their PIN codes when they receive an ISIM.
ユーザーが選択したパスワードは通常非常に簡単であるため、サーバーは辞書[2]にあるHTTPダイジェストのパスワードを受け入れるべきではないことが提案されています。この潜在的な脅威は、アルゴリズムがISIM起源のパスワードを使用するため、HTTPダイジェストAKAには存在しません。ただし、エンドユーザーはまだピンコードに注意する必要があります。HTTP Digest別名パスワード要求はエンドユーザーに表示されることはありませんが、PINコードを介してISIMに認証されます。一般に既知の初期ピンコードは、通常、製造中にISIMにインストールされ、エンドユーザーがそれらを変更しない場合、不正なユーザーがデバイスを使用できる危険性があります。当然のことながら、不正なユーザーが物理デバイスにアクセスできること、およびエンドユーザーが初期ピンコードを変更していないことが必要です。このため、エンドユーザーは、ISIMを受け取ったときにピンコードを変更することを強くお勧めします。
Digest AKA is able to generate additional session keys for integrity (IK) and confidentiality (CK) protection. Even though this document does not specify the use of these additional keys, they may be used for creating additional security within HTTP authentication or some other security mechanism.
Digest AKAは、整合性（IK）と機密性（CK）保護のための追加のセッションキーを生成できます。このドキュメントでは、これらの追加キーの使用を指定していませんが、HTTP認証または他のセキュリティメカニズム内で追加のセキュリティを作成するために使用される場合があります。
AKA allows sequence numbers to be tracked for each authentication, with the SQN parameter. This allows authentications to be replay protected even if the RAND parameter happened to be the same for two authentication requests. More importantly, this offers additional protection for the case where an attacker replays an old authentication request sent by the network. The client will be able to detect that the request is old, and refuse authentication. This proves liveliness of the authentication request even in the case where a MitM attacker tries to trick the client into providing an authentication response, and then replaces parts of the message with something else. In other words, a client challenged by Digest AKA is not vulnerable for chosen plain text attacks. Finally, frequent sequence number errors would reveal an attack where the tamper resistant card has been cloned and is being used in multiple devices.
AKAでは、SQNパラメーターを使用して、各認証に対してシーケンス番号を追跡できます。これにより、RANDパラメーターがたとえ2つの認証要求で同じであった場合でも、認証を再生することができます。さらに重要なことに、これは、攻撃者がネットワークから送信された古い認証要求を再生する場合に追加の保護を提供します。クライアントは、リクエストが古いことを検出し、認証を拒否することができます。これにより、MITM攻撃者がクライアントをだまして認証応答を提供しようとする場合でも、認証要求の活気があり、メッセージの一部を他のものに置き換えます。言い換えれば、Digest AKAに挑戦したクライアントは、選択されたプレーンテキスト攻撃に対して脆弱ではありません。最後に、頻繁なシーケンス番号エラーは、改ざん抵抗カードがクローン化され、複数のデバイスで使用されている攻撃を明らかにします。
The downside of sequence number tracking is that servers must hold more information for each user than just their long-term secret, namely the current SQN value. However, this information is typically not stored in the SIP nodes, but in dedicated authentication servers instead.
シーケンス番号追跡のマイナス面は、サーバーが各ユーザーの長期的な秘密、つまり現在のSQN値よりも多くの情報を保持する必要があることです。ただし、この情報は通常、SIPノードにはなく、代わりに専用の認証サーバーに保存されます。
Even though AKA is perceived as a secure mechanism, Digest AKA is able to improve it. More specifically, the AKA parameters carried between the client and the server during authentication may be protected along with other parts of the message by using Digest AKA. This is not possible with plain AKA.
AKAは安全なメカニズムとして認識されていますが、Digest AKAはそれを改善することができます。より具体的には、認証中にクライアントとサーバーの間に携帯される別名パラメーターは、Digest AKAを使用してメッセージの他の部分とともに保護できます。これは、平易な別名では不可能です。
This document specifies an aka-version namespace in Section 3.1 which requires a central coordinating body. The body responsible for this coordination is the Internet Assigned Numbers Authority (IANA).
このドキュメントは、セクション3.1の別名バージョン名空間を指定します。これには、中央の調整本体が必要です。この調整の原因は、インターネットに割り当てられた数字当局（IANA）です。
The default aka-version defined in this document is "AKAv1". Following the policies outlined in [5], versions above 1 are allocated as Expert Review.
このドキュメントで定義されているデフォルトの別名バージョンは「AKAV1」です。[5]で概説されているポリシーに続いて、上記のバージョンは専門家のレビューとして割り当てられます。
Registrations with the IANA MUST include the version number being registered, including the "AKAv" prefix. For example, a registration for "AKAv2" would potentially be a valid one, whereas a registration for "FOOv2" or "2" would not be valid. Further, the registration MUST include contact information for the party responsible for the registration.
IANAへの登録には、「AKAV」プレフィックスを含む登録されているバージョン番号を含める必要があります。たとえば、「AKAV2」の登録は有効なものになる可能性がありますが、「FOOV2」または「2」の登録は有効ではありません。さらに、登録には、登録を担当する当事者の連絡先情報を含める必要があります。
As this document defines the default aka-version, the initial IANA registration for aka-version values will contain an entry for "AKAv1".
このドキュメントがデフォルトの別名バージョンを定義すると、AKA-version値の最初のIANA登録には「AKAV1」のエントリが含まれます。
To: ietf-digest-aka@iana.org Subject: Registration of a new AKA version
宛先：ietf-digest-aka@iana.org件名：新しい別名バージョンの登録
Version identifier:
バージョン識別子：
(Must contain a valid aka-version value, as described in section 3.1.)
（セクション3.1で説明されているように、有効なバージョン値を含める必要があります。）
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
(Must contain contact information for the person(s) responsible for the registration.)
（登録の責任者の連絡先情報を含める必要があります。）
Normative References
引用文献
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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.
[2] Franks、J.、Hallam-Baker、P.、Hostetler、J.、Lawrence、S.、Leach、P.、Luotonen、A。and L. Stewart、「HTTP認証：基本および消化アクセス認証」、RFC 2617、1999年6月。
[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.
[3] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M.、E。Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
[4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[4] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
Informative References
参考引用
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[5] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[6] 3rd Generation Partnership Project, "Security Architecture (Release 4)", TS 33.102, December 2001.
[6] 第3世代パートナーシッププロジェクト、「セキュリティアーキテクチャ（リリース4）」、TS 33.102、2001年12月。
[7] http://www.iana.org, "Assigned Numbers".
[7] http://www.iana.org、「割り当てられた番号」。
The authors would like to thank Sanjoy Sen, Jonathan Rosenberg, Pete McCann, Tao Haukka, Ilkka Uusitalo, Henry Haverinen, John Loughney, Allison Mankin and Greg Rose.
著者は、サンジョイ・セン、ジョナサン・ローゼンバーグ、ピート・マッキャン、タオ・ハッカ、イルッカ・ウシタロ、ヘンリー・ヘイヴェリネン、ジョン・ラフニー、アリソン・マンキン、グレッグ・ローズに感謝したいと思います。
Authors' Addresses
著者のアドレス
Aki Niemi Nokia P.O. Box 301 NOKIA GROUP, FIN 00045 Finland
Aki niemi nokia P.O.ボックス301ノキアグループ、フィン00045フィンランド
Phone: +358 50 389 1644
EMail: aki.niemi@nokia.com
Jari Arkko Ericsson Hirsalantie 1 Jorvas, FIN 02420 Finland
Jari Arkko Ericsson Hirsalantie 1 Jorvas、Fin 02420フィンランド
Phone: +358 40 5079256
EMail: jari.arkko@ericsson.com
Vesa Torvinen Ericsson Joukahaisenkatu 1 Turku, FIN 20520 Finland
Vesa Torvinen Ericsson Joukahaisenkatu 1 Turku、Fin 20520 Finland
Phone: +358 40 7230822
EMail: vesa.torvinen@ericsson.fi
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
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 assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
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 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.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。