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)
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.
著作権（C）インターネット協会（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.
このメモはハイパーテキスト転送プロトコル（HTTP）ダイジェストアクセス認証用ワンタイムパスワード生成メカニズムをベース認証と鍵合意（AKA）を指定します。基本とダイジェスト：HTTP認証フレームワークは、2つの認証スキームを含んでいます。どちらの方式では、アクセス認証のための共有シークレットベースの機構を採用しています。 AKA機構は、ユニバーサル・モバイル・テレコミュニケーション・システム（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.
Basicおよびダイジェスト：RFC 2617に記載のハイパーテキスト転送プロトコル（HTTP）認証フレームワークは、[2]は、2つの認証方式を含みます。どちらの方式では、アクセス認証のための共有シークレットベースの機構を採用しています。基本的なスキームは、それはプレーンテキストでユーザーの資格情報を送信していることで本質的に安全です。ダイジェスト方式は、暗号化ハッシュと、さらに限定されたメッセージの整合性を提供することにより、ユーザーの資格情報を隠すことによって、セキュリティを向上させます。
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.
認証および鍵合意（AKA）[6]メカニズムは、ユニバーサル・モバイル・テレコミュニケーション・システム（UMTS）ネットワークにおける認証およびセッション鍵の配布を行います。 AKAは対称暗号を使用してチャレンジ・レスポンスベースのメカニズムです。 AKAはまた、典型的には、共有秘密の耐熱保存タンパ提供するデバイスなどのスマートカード上に存在するUMTS IMサービス識別モジュール（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ダイジェスト認証にAKAパラメータのマッピングを指定します。本質的には、このマッピングは、ダイジェスト認証用ワンタイムパスワード生成メカニズムとして、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認証フレームワークを以下、ダイジェスト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認証トークン。一緒にRANDパラメータを使用してクライアントにサーバを認証AuCは、によって生成された128ビット値。
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暗号鍵。暗号化のためのAKAセッションキー。
IK Integrity Key. An AKA session key for integrity check.
IK完全鍵。整合性チェックのためのAKAセッションキー。
ISIM IP Multimedia Services Identity Module.
ISIM IPマルチメディアサービス識別モジュール。
PIN Personal Identification Number. Commonly assigned passcodes for use with automatic cash machines, smart cards, etc.
PIN個人識別番号。などの現金自動機、スマートカード、で使用するために一般的に割り当てられたパスコード
RAND Random Challenge. Generated by the AuC using the SQN.
RANDランダムチャレンジ。 SQNを使用してのAuCによって生成されます。
RES Authentication Response. Generated by the ISIM.
RES認証レスポンス。 ISIMによって生成されます。
SIM Subscriber Identity Module. GSM counter part for ISIM.
SIM加入者識別モジュール。 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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119に記載されるように解釈される[1]。
This chapter describes the AKA operation in detail:
この章では、詳細なAKAの操作について説明します。
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. Aは、秘密KがISIMと認証センター（AUC）との間で事前に確立された共有しました。秘密は、耐タンパデバイス、スマートカードなどの上に置かれ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.
前記ホームネットワークのAUCが、共有秘密Kとシーケンス番号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.認証ベクトルは、サーバにダウンロードされます。必要に応じて、サーバーは、複数の認証ベクトルを含む、視聴覚資料のバッチをダウンロードすることができます。
4. The server creates an authentication request, which contains the random challenge RAND, and the network authenticator token AUTN.
4.サーバーは、ランダムチャレンジRAND、およびネットワーク認証トークンAUTNが含まれている認証要求を作成します。
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.共有秘密Kとシーケンス番号SQNを使用して、クライアントがISIMとAUTNを検証します。検証に成功した場合、ネットワークが認証されています。次に、クライアントは、共有秘密KとランダムチャレンジRANDを使用して認証応答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.サーバが予想される応答、XRESと認証応答RESを比較します。 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.
一般的には、ダイジェストAKA動作は、RFC 2617でダイジェスト動作と同一である[2]。この章では、ダイジェストAKAダイジェスト操作を拡張した部分を指定します。このセクションの新規および変更構文要素の増大している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に定義アルゴリズムディレクティブは、ダイジェストAKAでオーバーロードされます。
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".
ダイジェストとチェックサムを製造する際に使用されるアルゴリズムを示す文字列アルゴリズムディレクティブが理解されていない場合は、ナンスは無視されるべきである、と別の課題は、（1つが存在する場合）の代わりに使用する必要があります。別名・バージョンのデフォルトは「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.
さらにAKAバージョンはIANA [7]によって割り当てられたバージョン番号と、指定することができます。アルゴリズムのディレクティブが存在しない場合は、「MD5」であると想定されます。これは、AKAダイジェスト・パスワードを生成するために使用されていないこと、を示しています。
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値は、ワンタイムパスワードとして使用されるべきであり、単一の鍵でハッシュされる材料の量を制限するような「MD5-のSES」などのアルゴリズムは、認証のためのセッションキーを生成することによって、使用されるべきではありません。
In order to deliver the AKA authentication challenge to the client in Digest AKA, the nonce directive defined in RFC 2617 is extended:
ダイジェストAKAでクライアントにAKA認証チャレンジを実現するためには、RFC 2617で定義されたナンスディレクティブが拡張されます。
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.
ナンス、図1のように、AKA認証チャレンジRAND、AUTN AKAトークンの連結のBase64で[4]符号化、および必要に応じていくつかのサーバー固有のデータが移入されたパラメータ、。
Example:
例：
nonce="MzQ0a2xrbGtmbGtsZm9wb2tsc2tqaHJzZXNy9uQyMzMzMzQK="
ナンス= "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.
サーバーが有効なAKA AUTSパラメータを含んでいるセクション3.4で定義された「AUTS」パラメータを含むクライアント認証を受信した場合、サーバーはクライアントへの新たな挑戦を生成するためにそれを使用しなければなりません。 AUTSが存在する場合、含まれる「応答」パラメータが代わりRESの、空のパスワード（「」のパスワード）を用いて算出されることに留意されたいです。
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.
クライアントは、ダイジェストAKA認証チャレンジを受信すると、それは「ナンス」パラメータからRANDとAUTNを抽出して、サーバが提供するAUTNトークンを評価します。クライアントが正常にAUTNを使用してサーバーを認証し、SQNがチャレンジを生成する際に使用されると判断した場合に予想される範囲内であり、AKAアルゴリズムは、RANDチャレンジを実行して、秘密Kを共有しています
The resulting AKA RES parameter is treated as a "password" when calculating the response directive of RFC 2617.
RFC 2617の応答ディレクティブを計算するときに結果AKA RESパラメータは、「パスワード」として扱われます。
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 "").
base64でエンコードされたAKA AUTSパラメータを持つ文字列をAUTS。このディレクティブは、サーバー側のSQNを再同期するために使用されます。ディレクティブが存在する場合はその資格情報を計算するとき、クライアントは任意のパスワードを使用していません。代わりに、クライアントは空のパスワード（「」のパスワード）を使用して、その資格情報を計算する必要があります。
Example:
例：
auts="CjkyMzRfOiwg5CfkJ2UK="
痛い= "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」パラメータを受信すると、サーバは、AUCの再同期SQNに使用される共有秘密K. A有効AUTSパラメータを使用して、パラメータ値の妥当性をチェックします。同期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はAKA AUTNトークンに固有の相互認証を提供するにもかかわらず、ダイジェストが提供する相互認証メカニズムは、まだメッセージの完全性を提供するために有用であり得ます。
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.
RFC 2617で定義された「認証-INFO」ヘッダの「応答-AUTH」を算出する際に、ダイジェストAKAにおいて、サーバは、「パスワード」としてAKA 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要求、すなわちSIP REGISTER要求の認証ダイジェスト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 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
一口に登録：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
SIP / 2.0 401不正WWW認証：ダイジェストレルム= "RoamingUsers@mobile.biz"、ノンス= "CjPk9mRqNuT25eRkajM09uTl9nM09uTl9nMz5OX25PZz =="、QOP = "AUTH、AUTH-INT"、不透明= "5ccc069c403ebaf9f0171e9517f40e41"、アルゴリズム= 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"
home.mobile.biz SIP / 2.0認証：ダイジェストユーザ名= "jon.dough@mobile.biz"、領域= "RoamingUsers@mobile.biz"、ナンス= "CjPk9mRqNuT25eRkajM09uTl9nM09uTl9nMz5OX25PZz =="、URI =「SIP：SIP家を登録します.mobile.biz」、QOP =のauth-int型、NC = 00000001、cnonce = "0a4f113b"、レスポンス= "6629fae49393a05397450978507c4ef1"、不透明= "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認証-情報：QOP =のauth-int型、rspauth = "6629fae49393a05397450978507c4ef1"、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
一口に登録：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
SIP / 2.0 401不正WWW認証は：レルム= "RoamingUsers@mobile.biz"、QOP = "認証"、ノンス= "CjPk9mRqNuT25eRkajM09uTl9nM09uTl9nMz5OX25PZz =="、不透明= "5ccc069c403ebaf9f0171e9517f40e41"、アルゴリズム= 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="
home.mobile.biz SIP / 2.0認証：ダイジェストユーザ名= "jon.dough@mobile.biz"、領域= "RoamingUsers@mobile.biz"、ナンス= "CjPk9mRqNuT25eRkajM09uTl9nM09uTl9nMz5OX25PZz =="、URI =「SIP：SIP家を登録します.mobile.biz」、QOP = AUTH、NC = 00000001、cnonce = "0a4f113b"、応答= "4429ffe49393c02397450934607c4ef1"、不透明= "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
SIP / 2.0 401不正WWW認証は：レルム= "RoamingUsers@mobile.biz"、QOP = "AUTH、AUTH-INT" = "9uQzNPbk9jM05Pbl5Pbl5DIz9uTl9uTl9jM0NTHk9uXk ==" ナンス、不透明= "dcd98b7102dd2f0e8b11d0f600bfb0c093を" ダイジェストアルゴリズム= AKAv1-MD5
In general, Digest AKA is vulnerable to the same security threats as HTTP authentication [2]. This chapter discusses the relevant exceptions.
一般的には、ダイジェストAKA [2] HTTP認証と同じセキュリティ上の脅威に対して脆弱です。この章では、関連する例外について説明します。
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コードの知識を持っている場合、認証にのみ行うことができます。そのような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.
セキュアなインターフェイスに耐性のカードを改ざんの使用は、ソフトウェアのホスト機器やトロイの木馬のどちらも所持は、長期的な秘密へのアクセス権を与えるようダイジェストAKAは、通常、定期的なダイジェストの実装よりも安全であることを意味します。 PIN方式を使用する場合、デバイスに電源が投入されると、ユーザはまた、認証されます。しかしながら、これらの実装は、ユーザから受信された/ストア・パスワードをキャッシュするかどうかに当然依存し、従来のダイジェスト実装に比べダイジェスト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 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.
ダイジェストAKAは、特定のISIMにノンス値の適用性を制限します。通常、ISIMは、一度に1つのクライアントデバイスにアクセス可能です。しかし、一回だけの値が強く、特定のISIMに制限されていても固定します。また、これは認証チャレンジを生成する前に、サーバがクライアントの身元を備えていることが必要です。クライアントIDが使用できない場合は、追加の往復は、それを取得するために必要とされます。このような場合には、AKA同期障害に類似しています。
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ヘッダフィールドに次ノンスディレクティブを送信することにより、一度だけ使用することを可能にすることができます。同じSQNスペースも同時に他のアクセス方式のために使用されている場合ただし、これは、同期失敗、およびAKAで、その結果、いくつかの追加のラウンドトリップが発生することがあります。
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認証スキームでダイジェストAKAによって生成されたパスワードを使用すると、レルム値または保護ドメインが一致するだろうにもかかわらず、推奨されません。これらのケースでは、パスワードではなく、エンドユーザから要求されなければなりません。ダイジェストAKAパスワードが平文でパスワードを送信し、そのようなHTTP認証方式、で再使用してはいけません。具体的には、AKAのパスワードは、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.
ユーザーが選択したパスワードは、通常、非常に簡単なので、サーバが辞書にあるHTTPダイジェストのパスワード、[2]を受け入れるべきではないことが提案されています。 ISIMを使用するアルゴリズムは、パスワードを発したので、この潜在的な脅威は、HTTPダイジェストAKAには存在しません。しかし、エンドユーザはまだPINコードと注意する必要があります。 HTTPダイジェストAKAパスワード要求はエンドユーザーに表示されることはありませんにもかかわらず、彼女は、PINコードを経由してISIMに認証されます。一般的に知られている最初のPINコードは、典型的には、製造時ISIMにインストールされ、エンドユーザがそれらを変更しない場合、不正なユーザが装置を使用することができるかもしれないという危険があるれています。当然これは、不正なユーザは、物理デバイスへのアクセスを有すること、及びエンドユーザが初期PINコードが変更されていないことが必要です。このため、エンドユーザーが強く、彼らがISIMを受信したとき、そのPINコードを変更することをお勧めします。
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.
ダイジェスト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攻撃者が認証応答を提供するにクライアントをだまししようとすると、その後、何か他のものとのメッセージの一部を置き換えた場合の認証要求の活気を証明しています。言い換えれば、ダイジェスト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は安全なメカニズムとして認識されていても、ダイジェストAKAはそれを改善することができます。より具体的には、認証時にクライアントとサーバとの間で行わAKAパラメータは、ダイジェストAKAを使用してメッセージの他の部分と一緒に保護されていてもよいです。これは、プレーン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節で別名バージョンの名前空間を指定します。この調整を担当するボディは、Internet Assigned Numbers Authority（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]に概説された方針に続いて、1以上のバージョンは、専門家レビューとして割り当てられています。
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」プレフィックスを含む登録されているバージョン番号を含まなければなりません。 「FOOv2」または「2」の登録が有効ではありません一方、例えば、「AKAv2」の登録は、潜在的に、有効なものであろう。さらに、登録は、登録のための責任者の連絡先情報を含まなければなりません。
As this document defines the default aka-version, the initial IANA registration for aka-version values will contain an entry for "AKAv1".
この文書は別名・バージョンのデフォルトを定義すると、別名バージョン値の初期IANA登録は「AKAv1」のエントリが含まれています。
To: ietf-digest-aka@iana.org
Subject: Registration of a new AKA version
Version identifier:
バージョンは識別します。
(Must contain a valid aka-version value,
as described in section 3.1.)
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス：
(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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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]フランクス、J.、ハラム・ベイカー、P.、Hostetler、J.、ローレンス、S.、リーチ、P.、Luotonen、A.およびL.スチュワート、 "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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル"、 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]フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、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、 "番号を付し"。
Appendix A. Acknowledgements
付録A.謝辞
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.
著者はサンジョイセン、ジョナサン・ローゼンバーグ、ピートマッキャン、鷹タオ、イルッカUusitalo、ヘンリーHaverinen、ジョンLoughney、アリソンマンキンとグレッグ・ローズに感謝したいと思います。
Authors' Addresses
著者のアドレス
Aki Niemi Nokia P.O. Box 301 NOKIA GROUP, FIN 00045 Finland
安芸ニエミNokiaの私書箱ボックス301 NOKIA GROUP、FIN-00045フィンランド
Phone: +358 50 389 1644 EMail: aki.niemi@nokia.com
電話番号：+358 50 389 1644 Eメール：aki.niemi@nokia.com
Jari Arkko Ericsson Hirsalantie 1 Jorvas, FIN 02420 Finland
ヤリArkkoエリクソンHirsalantie 1 Jorvas、FIN 02420フィンランド
Phone: +358 40 5079256 EMail: jari.arkko@ericsson.com
電話番号：+358 40 5079256 Eメール：jari.arkko@ericsson.com
Vesa Torvinen Ericsson Joukahaisenkatu 1 Turku, FIN 20520 Finland
VESA TorvinenエリクソンJoukahaisenkatu 1トゥルク、FIN 20520フィンランド
Phone: +358 40 7230822 EMail: vesa.torvinen@ericsson.fi
電話番号：+358 40 7230822 Eメール：vesa.torvinen@ericsson.fi
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。