RFC3310 日本語訳
3310 Hypertext Transfer Protocol (HTTP) Digest Authentication UsingAuthentication and Key Agreement (AKA). A. Niemi, J. Arkko, V.Torvinen. September 2002. (Format: TXT=36985 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Niemi
Request for Comments: 3310 Nokia
Category: Informational J. Arkko
V. Torvinen
Ericsson
September 2002
Niemiがコメントのために要求するワーキンググループA.をネットワークでつないでください: 3310年のノキアカテゴリ: 情報のJ.Arkko V.Torvinenエリクソン2002年9月
Hypertext Transfer Protocol (HTTP) Digest Authentication
Using Authentication and Key Agreement (AKA)
認証と主要な協定を使用するハイパーテキスト転送プロトコル(HTTP)ダイジェスト認証(別名)
Status of this Memo
この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)インターネット協会(2002)。 All rights reserved。
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.
このメモはハイパーテキストTransferプロトコル(HTTP)ダイジェストアクセス認証にAuthenticationとKey Agreement(AKA)ベースのワンタイムパスワード世代メカニズムを指定します。 HTTP Authentication Frameworkは2つの認証体系を含んでいます: 基礎とダイジェスト。 両方の体系はアクセス認証に共有された秘密のベースのメカニズムを使います。 AKAメカニズムはUniversalのモバイルTelecommunications System(UMTS)ネットワークでユーザー認証とセッションの主要な分配を実行します。 AKAは左右対称の暗号を使用する応答が基礎づけた挑戦メカニズムです。
Niemi, et. al. Informational [Page 1] RFC 3310 HTTP Digest Authentication Using AKA September 2002
et Niemi、アル。 別名2002年9月を使用する情報[1ページ]のRFC3310HTTPダイジェスト認証
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
1. 序論と動機. . . . . . . . . . . . . . . . . 2 1.1用語. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2コンベンション. . . . . . . . . . . . . . . . . . . . . . . . . 4 2。 別名メカニズム概要. . . . . . . . . . . . . . . . . . . . 4 3。 挑戦. . . . . . . . . . . . . . . . . . . . . 6 3.3クライアント認証. . . . . . . . . . . . . . . . . . . . 7 3.4同期失敗. . . . . . . . . . . . . . . . . . . 7 3.5サーバー証明. . . . . . . . . . . . . . . . . . . . 8 4を作成するダイジェスト別名. . . . . . . . . . . . . . . . . 5 3.1アルゴリズム指示. . . . . . . . . . . . . . . . . . . . . 5 3.2の仕様。 例のダイジェスト別名操作. . . . . . . . . . . . . . . . . 8 5。 クライアント使用の.125.1認証が通称.135.2に読みこなすセキュリティ問題は一回だけの値. . . . . . . . . . . . . . . . . 13 5.3の使用を制限しました。複数の認証体系とアルゴリズム. . . . . . . . 14 5; 4 オンライン辞書攻撃. . . . . . . . . . . . . . . . . . 14 5.5セッション保護. . . . . . . . . . . . . . . . . . . . . . 14 5.6は別名セキュリティ. . . . . . . . . . . . . . . . . 15 6への保護.155.7の改良を再演します。 IANA問題. . . . . . . . . . . . . . . . . . . . . 15 6.1登録テンプレート. . . . . . . . . . . . . . . . . . . . 16引用規格. . . . . . . . . . . . . . . . . . . . . 16の有益な参照. . . . . . . . . . . . . . . . . . . . 16A.承認. . . . . . . . . . . . . . . . . . . . . . . 17作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 17の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 18
1. Introduction and Motivation
1. 序論と動機
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.
RFC2617[2]で説明されたハイパーテキストTransferプロトコル(HTTP)認証Frameworkは2つの認証体系を含んでいます: 基礎とダイジェスト。 両方の体系はアクセス認証に共有された秘密のベースのメカニズムを使います。 プレーンテキストのユーザ資格証明書を伝えるので、Basic体系は本来不安定です。 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.
AuthenticationとKey Agreement(AKA)[6]メカニズムはUniversalのモバイルTelecommunications System(UMTS)ネットワークで認証とセッションの主要な分配を実行します。 AKAは左右対称の暗号を使用する応答が基礎づけた挑戦メカニズムです。 AKAはUMTS IM Services Identity Module(ISIM)に通常立候補することです。(UMTS IM Services Identity Moduleはまた、共有秘密キーの耐タンパー性ストレージを提供するデバイスのようなスマートカードに住んでいます)。
Niemi, et. al. Informational [Page 2] RFC 3310 HTTP Digest Authentication Using AKA September 2002
et Niemi、アル。 別名2002年9月を使用する情報[2ページ]のRFC3310HTTPダイジェスト認証
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認証にAKAパラメタに関するマッピングを指定します。 本質では、このマッピングはDigest認証のためのワンタイムパスワード世代メカニズムとして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.
Session Initiationプロトコル(SIP)[3]認証Frameworkが密接にHTTP Authentication Frameworkに続くとき、Digest AKAは直接HTTP Digestのいかなる他の具体化と同様にSIPに適切です。
1.1 Terminology
1.1 用語
This chapter explains the terminology used in this document.
本章で、本書では使用される用語がわかります。
AKA
Authentication and Key Agreement.
別名認証と主要な協定。
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.
個人の識別番号をピンで止めてください。 自動現金マシン、スマートカードなどがある使用のための一般的に割り当てられたpasscodes
RAND
Random Challenge. Generated by the AuC using the SQN.
底ならし革の無作為の挑戦。 SQNを使用することでAuCによって生成されます。
RES
Authentication Response. Generated by the ISIM.
RES認証応答。 ISIMによって生成されます。
Niemi, et. al. Informational [Page 3] RFC 3310 HTTP Digest Authentication Using AKA September 2002
et Niemi、アル。 別名2002年9月を使用する情報[3ページ]のRFC3310HTTPダイジェスト認証
SIM
Subscriber Identity Module. GSM counter part for ISIM.
SIM加入者アイデンティティモジュール。 GSMはISIMのために部分を打ち返します。
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と等しいです。
1.2 Conventions
1.2 コンベンション
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[1])で説明されるように本書では解釈されることであるべきです。
2. AKA Mechanism Overview
2. 別名メカニズム概要
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. 共有秘密キーKはあらかじめ、ISIMとAuthenticationセンター(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.
2. ホームネットワークのAuCは認証ベクトルAVを生産します、共有秘密キーKと一連番号SQNに基づいて。 認証ベクトルは無作為の挑戦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のバッチをダウンロードできます、1つ以上の認証ベクトルを含んでいて。
4. The server creates an authentication request, which contains the
random challenge RAND, and the network authenticator token AUTN.
4. サーバは認証要求とネットワーク固有識別文字トークンAUTNを作成します。(要求は無作為の挑戦RANDを含みます)。
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. 共有秘密キーKと一連番号SQNを使用して、クライアントはISIMとAUTNについて確かめます。 検証がうまくいくなら、ネットワークは認証されました。 共有秘密キーKと無作為の挑戦RANDを使用して、そしてクライアントは認証応答RESを生産します。
Niemi, et. al. Informational [Page 4] RFC 3310 HTTP Digest Authentication Using AKA September 2002
et Niemi、アル。 別名2002年9月を使用する情報[4ページ]のRFC3310HTTPダイジェスト認証
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. XRES、サーバは認証応答RESを予想された応答と比べます。 セッションキー(IKとCK)を2が合っているなら、首尾よくユーザを認証して、クライアントとサーバとのさらなるコミュニケーションを保護するのに、使用できます。
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について確かめるクライアントがそれを検出するとき、クライアントとサーバの間の一連番号は同期していなく下がりました。 この場合、クライアントは同期パラメタAUTSを生産します、共有秘密キーKとクライアント一連番号SQNを使用して。 認証応答で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 TS33.102[6]を見ます。
3. Specification of Digest AKA
3. ダイジェスト別名の仕様
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操作はRFC2617[2]でのDigest操作と同じです。 本章はDigest AKAがDigest操作を広げる部品を指定します。 このセクションの新しくて変更された構文要素にAugmented BNF定義に使用される記法はSIP[3]で使用されています、そして、このセクションで定義されなかったどんな要素もそれが参照されるSIPとドキュメントで定義されるようにあります。
3.1 Algorithm Directive
3.1 アルゴリズム指示
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を使用するのにクライアントを向けるために、RFC2617の定義されたアルゴリズム指示はDigest 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 )
アルゴリズム=「アルゴリズム」EQUAL(アルゴリズム別名名前空間/値)別名名前空間=別名バージョン「-」アルゴリズム価値の別名バージョン="AKAv"1*ケタアルゴリズム価値=(「MD5"/「MD5-sess」/トークン)」
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".
アルゴリズムがダイジェストとチェックサムを製作する際に使用したアルゴリズム五弦表示。 指示は理解されていません、無視されて、一回だけのSHOULD。別の挑戦(1つが存在しているなら)は代わりに使用されるべきです。 デフォルト別名バージョンは"AKAv1""です。
Niemi, et. al. Informational [Page 5] RFC 3310 HTTP Digest Authentication Using AKA September 2002
et Niemi、アル。 別名2002年9月を使用する情報[5ページ]のRFC3310HTTPダイジェスト認証
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]によって割り当てられている状態で、さらなるAKAバージョンを指定できます。 アルゴリズム指示が存在していないとき、それは"MD5""であると思われます。 これは、そのAKAがDigestパスワードを作り出すのに使用されないのを示します。
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価値の再利用はNOT RECOMMENDEDです。 そのようなRES値のSHOULDがワンタイムパスワード、および単一のキーで論じ尽くされた材料の量を制限する「MD5-sess」などのアルゴリズムとして使用されるだけであって、認証、SHOULD NOTに、主要なセッションを起こすことによって、使用されてください。
3.2 Creating a Challenge
3.2 挑戦を作成すること。
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認証挑戦を提供するために、RFC2617で定義された一回だけの指示は拡張されています:
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>
一回だけの=「一回だけ」EQUAL(一回だけの別名一回だけ/値)別名一回だけ=LDQUOT別名一回だけ価値RDQUOT別名一回だけ価値はRAND、AUTN、およびサーバの特定のデータ>の<base64コード化と等しいです。
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.
どれが居住されるか。一回だけのAパラメタ、図1のようなBase64[4]が任意にAKA認証挑戦RAND、AKA AUTNトークンの連結をコード化しているいくつかのサーバの特定のデータ。
Niemi, et. al. Informational [Page 6] RFC 3310 HTTP Digest Authentication Using AKA September 2002
et Niemi、アル。 別名2002年9月を使用する情報[6ページ]のRFC3310HTTPダイジェスト認証
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...
+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 底ならし革| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | AUTN| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サーバデータ… +-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Generating the nonce value.
図1: 一回だけの値を生成します。
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"パラメタを含むクライアント認証を受けるなら、それは有効なAKA AUTSパラメタを含んで、サーバは、クライアントへの新しい挑戦を生成するのにそれを使用しなければなりません。 AUTSが存在しているとき、含まれている「応答」パラメタが空のパスワードを使用することで計算されることに注意してください、(パスワード、「「)、RESの代わりに」
3.3 Client Authentication
3.3 クライアント認証
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認証挑戦を受けるとき、それは、「一回だけ」のパラメタから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.
RFC2617の応答指示について計算するとき、結果として起こるAKA RESパラメタは「パスワード」として扱われます。
3.4 Synchronization Failure
3.4 同期失敗
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一連番号同期の故障を示して、AuCでAUTSトークンを使用することでSQNを再連動させるように、新しい指示はRFC2617で定義された「承認」要求ヘッダーの「ダイジェスト応答」のために定義されます:
Niemi, et. al. Informational [Page 7] RFC 3310 HTTP Digest Authentication Using AKA September 2002
et Niemi、アル。 別名2002年9月を使用する情報[7ページ]のRFC3310HTTPダイジェスト認証
auts = "auts" EQUAL auts-param
auts-param = LDQUOT auts-value RDQUOT
auts-value = <base64 encoding of AUTS>
"auts"auts=EQUAL auts-param auts-paramはAUTS>の<base64LDQUOT auts-値のRDQUOT 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を運ぶauts五弦がAKA 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"パラメタを受け取ると、サーバは、K.のA有効なAUTSパラメタがAuCでSQNを再連動させるのに使用されるという共有秘密キーを使用することでパラメタ価値の正当性をチェックするでしょう。 そして、連動しているSQNは、新鮮な認証ベクトルがAVであると生成するのに使用されます。(次に、クライアントはAVと共に再挑戦されます)。
3.5 Server Authentication
3.5 サーバー証明
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トークンを提供しますが、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.
RFC2617で定義された「認証インフォメーション」ヘッダーの「応答-auth」について計算するとき、Digest AKAでは、サーバは「パスワード」としてAKA XRESパラメタを使用します。
4. Example Digest AKA Operation
4. 例のダイジェスト別名操作
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要求を認証するDigest AKAプロセスについて説明するメッセージ流動について説明します。
Niemi, et. al. Informational [Page 8] RFC 3310 HTTP Digest Authentication Using AKA September 2002
et Niemi、アル。 別名2002年9月を使用する情報[8ページ]のRFC3310HTTPダイジェスト認証
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) |
|<------------------------------------------------------|
| |
| 1) レジスタ| |------------------------------------------------------>| | | | +-----------------------------+ | | サーバはAKAアルゴリズムを実行します。| | | RANDとAUTNを生成します。 | | +-----------------------------+ | | | 2) 401、権限のなさ| | 以下をWWW認証してください。 ダイジェスト| | (RAND、提供されたAUTN) | |<------------------------------------------------------| | | +------------------------------------+ | | クライアントはAKAアルゴリズムをISIMに実行します。| | | AUTNについて確かめて、RESを引き出します。| | | そして、セッションキー。 | | +------------------------------------+ | | | | 3) レジスタ| | 承認: 読みこなしてください(RESは使用されています)。 | |------------------------------------------------------>| | | | +------------------------------+ | | サーバは与えられたRESをチェックします。| | | そして、それが修正する掘り出し物。 | | +------------------------------+ | | | 4) 200 OK| | 認証インフォメーション: (XRESは使用されています) | |<------------------------------------------------------| | |
Figure 2: Message flow representing a successful authentication.
図2: うまくいっている認証を表すメッセージ流動。
1) Initial request
1) 初期の要求
REGISTER sip:home.mobile.biz SIP/2.0
REGISTER一口: home.mobile.biz SIP/2.0
Niemi, et. al. Informational [Page 9] RFC 3310 HTTP Digest Authentication Using AKA September 2002
et Niemi、アル。 別名2002年9月を使用する情報[9ページ]のRFC3310HTTPダイジェスト認証
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
一口/2.0 401権限のない、以下をWWW認証してください。 「auth、auth-int」が不透明にするダイジェスト分野=" RoamingUsers@mobile.biz "、一回だけ=「CjPk9mRqNuT25eRkajM09uTl9nM09uTl9nMz5OX25PZz=」qop==「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"
REGISTER一口: home.mobile.biz SIP/2.0Authorization: ユーザ名=" jon.dough@mobile.biz "、分野=" RoamingUsers@mobile.biz "一回だけの=「CjPk9mRqNuT25eRkajM09uTl9nM09uTl9nMz5OX25PZz=」、uri=「一口: home.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
一口/2.0 200OK認証インフォメーション: qop=auth-int、rspauth=「6629fae49393a05397450978507c4ef1"、cnonce="0a4f113b"nc=00000001」
Niemi, et. al. Informational [Page 10] RFC 3310 HTTP Digest Authentication Using AKA September 2002
et Niemi、アル。 別名2002年9月を使用する情報[10ページ]のRFC3310HTTPダイジェスト認証
Figure 3 below describes a message flow describing a Digest AKA authentication process, in which there is a synchronization failure.
以下の図3はDigest 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) |
|<------------------------------------------------------|
| |
| 1) レジスタ| |------------------------------------------------------>| | | | +-----------------------------+ | | サーバはAKAアルゴリズムを実行します。| | | RANDとAUTNを生成します。 | | +-----------------------------+ | | | 2) 401、権限のなさ| | 以下をWWW認証してください。 ダイジェスト| | (RAND、提供されたAUTN) | |<------------------------------------------------------| | | +------------------------------------+ | | クライアントはAKAアルゴリズムをISIMに実行します。| | | しかし、AUTNが確かめる、発見| | | それは病人を含みます。| | | 一連番号。 そしてクライアント| | | AUTSトークンを生成します。 | | +------------------------------------+ | | | | 3) レジスタ| | 承認: 読みこなしてください(AUTSは提供されます)。 | |------------------------------------------------------>| | | | +-----------------------+ | | サーバは働きます。| | | 再同期| | | AUTSと底ならし革を使用します。 | | +-----------------------+ | | | 4) 401、権限のなさ| | 以下をWWW認証してください。 ダイジェスト| | (| | 再連動しているRAND、提供されたAUTN) | |<------------------------------------------------------| | |
Figure 3: Message flow representing an authentication synchronization failure.
図3: 認証同期失敗を表すメッセージ流動。
Niemi, et. al. Informational [Page 11] RFC 3310 HTTP Digest Authentication Using AKA September 2002
et Niemi、アル。 別名2002年9月を使用する情報[11ページ]のRFC3310HTTPダイジェスト認証
1) Initial request
1) 初期の要求
REGISTER sip:home.mobile.biz SIP/2.0
REGISTER一口: 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
一口/2.0 401権限のない、以下をWWW認証してください。 分野=" RoamingUsers@mobile.biz "を読みこなしてください、そして、="auth"、一回だけ=「CjPk9mRqNuT25eRkajM09uTl9nM09uTl9nMz5OX25PZz=」が不透明にするqopは「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="
REGISTER一口: home.mobile.biz SIP/2.0Authorization: ユーザ名=" jon.dough@mobile.biz "、分野=" RoamingUsers@mobile.biz "一回だけの=「CjPk9mRqNuT25eRkajM09uTl9nM09uTl9nMz5OX25PZz=」、uri=「一口: home.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
一口/2.0 401権限のない、以下をWWW認証してください。 分野=" RoamingUsers@mobile.biz "、qop=「auth、auth-int」一回だけ=「9uQzNPbk9jM05Pbl5Pbl5DIz9uTl9uTl9jM0NTHk9uXk=」を読みこなしてください、そして、不透明なものは「dcd98b7102dd2f0e8b11d0f600bfb0c093"、アルゴリズム=AKAv1-MD5」と等しいです。
5. Security Considerations
5. セキュリティ問題
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]と同じ軍事的脅威に被害を受け易いです。 本章は関連例外について議論します。
Niemi, et. al. Informational [Page 12] RFC 3310 HTTP Digest Authentication Using AKA September 2002
et Niemi、アル。 別名2002年9月を使用する情報[12ページ]のRFC3310HTTPダイジェスト認証
5.1 Authentication of Clients using Digest AKA
5.1 ダイジェスト別名を使用しているクライアントの認証
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の間で共有された暗証番号コードに関する知識を持っている場合にだけ、認証は実行できます。 そのような暗証番号コードが、ユーザ入力から通常得られて、デバイスが電源を入れられているとき、通常、必要です。
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実装より通常安全であることを含意します、ホストデバイスの所持もソフトウェアのトロイの木馬も長期へのアクセスを秘密に与えないとき。 また、暗証番号体系が使用されているところでは、デバイスが電源を入れられているとき、ユーザは認証されます。 しかしながら、Digest AKAの結果として起こるセキュリティの違いがあるかもしれません、伝統的なDigest実装と比べて、もちろんそれらの実装がユーザから受け取られるパスワードをキャッシュするか、または保存するかどうかによって。
5.2 Limited Use of Nonce Values
5.2 一回だけの値の株式会社使用
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体系は、要求ダイジェスト価値の世代をシードするのにサーバで指定された一回だけの値を使用します。 サーバは無料でそのような方法で一回だけを組み立てることができて、それはそれです。特定のクライアントから使用されるだけであるかもしれません、特定のリソースのために、限定期間の時間か数の用途、またはいかなる他の制限のためにも。 そうするのは例えば、反射攻撃に対して提供された保護を強化します。
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に制限されますが、安全です。 さらに、これは、認証挑戦を生成することができる前にクライアントのアイデンティティがサーバに提供されるのを必要とします。 クライアントのアイデンティティが利用可能でないなら、追加周遊旅行が、それを取得するのに必要です。 そのような場合は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.
サーバは、それぞれの一回だけの値があらゆる応答のAuthentication-インフォメーションヘッダーフィールドに次の一回だけ指示を送ることによって一度だけ使用されるのを許容するかもしれません。 しかしながら、これはAKAで同期失敗、およびその結果いくつかの追加周遊旅行を引き起こすかもしれません、また、同じSQNスペースが同時に他のアクセス体系に使用されるなら。
Niemi, et. al. Informational [Page 13] RFC 3310 HTTP Digest Authentication Using AKA September 2002
et Niemi、アル。 別名2002年9月を使用する情報[13ページ]のRFC3310HTTPダイジェスト認証
5.3 Multiple Authentication Schemes and Algorithms
5.3 複数の認証体系とアルゴリズム
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 AKAによって生成されたパスワードを使用するのは推薦されません。 これらの場合では、パスワードは代わりにエンドユーザから要求されるべきです。 そのようなHTTP認証体系と共にダイジェストAKAパスワードを再使用してはいけません。(体系ははっきりとパスワードを送ります)。 特に、HTTP Basicと共にAKAパスワードを再使用してはいけません。
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 Digest挑戦を受けるクライアントは理解している中で最も強いアルゴリズムを選ばなければなりません。 例えば、Digest、「AKAv1-MD5"は"MD5""があるダイジェストより強いでしょう。
5.4 Online Dictionary Attacks
5.4 オンライン辞書攻撃
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 Digestのためのパスワードを受け入れるべきでないよう提案されました。 脅威が存在しないこの可能性に、アルゴリズムがISIMを使用するので、HTTP Digest AKAはパスワードを溯源しました。 しかしながら、エンドユーザはまだ暗証番号コードに慎重でなければなりません。 HTTP Digest AKAパスワード要求をエンドユーザに決して表示しませんが、暗証番号コードでISIMに彼女を認証するでしょう。 一般的に知られている初期の暗証番号コードは製造の間、ISIMに通常インストールされます、そして、エンドユーザが彼らを変えないなら、権限のないユーザがデバイスを使用できるかもしれないという危険があります。 当然、これは、権限のないユーザがフィジカル・デバイスに近づく手段を持って、エンドユーザが初期の暗証番号コードを変えていないのを必要とします。 この理由で、彼らがISIMを受けるとき、エンドユーザが彼らの暗証番号コードを変えるよう強く奨励されます。
5.5 Session Protection
5.5 セッション保護
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認証かある他のセキュリティー対策の中で追加担保を作成するのに使用されるかもしれません。
Niemi, et. al. Informational [Page 14] RFC 3310 HTTP Digest Authentication Using AKA September 2002
et Niemi、アル。 別名2002年9月を使用する情報[14ページ]のRFC3310HTTPダイジェスト認証
5.6 Replay Protection
5.6 反復操作による保護
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ノードに通常保存されるのではなく、代わりにひたむきな認証サーバで保存されています。
5.7 Improvements to AKA Security
5.7 別名セキュリティへの改良
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はそれを改良できます。 より明確に、認証の間にクライアントとサーバの間まで運ばれたAKAパラメタは、メッセージの他の部分と共にDigest AKAを使用することによって、保護されるかもしれません。 これは明瞭なAKAで可能ではありません。
6. IANA Considerations
6. IANA問題
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で別名バージョン名前空間を指定します。 このコーディネートに原因となるボディーはインターネットAssigned民数記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]に概説された方針に従って、Expert Reviewとして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 MUSTとの登録証明書は"AKAv"接頭語を含んでいて、示されるバージョン番号を含んでいます。 例えば、登録、「AKAv2"が潜在的に有効なものでしょうが、aが登録である、「FOOv2"か「2インチは有効でないでしょう」。 さらに、登録は登録に責任があるパーティーへの問い合わせ先を含まなければなりません。
Niemi, et. al. Informational [Page 15] RFC 3310 HTTP Digest Authentication Using AKA September 2002
et Niemi、アル。 別名2002年9月を使用する情報[15ページ]のRFC3310HTTPダイジェスト認証
As this document defines the default aka-version, the initial IANA registration for aka-version values will contain an entry for "AKAv1".
このドキュメントがデフォルト別名バージョンを定義するとき、別名バージョン値のための初期のIANA登録は"AKAv1""のためのエントリーを含むでしょう。
6.1 Registration Template
6.1 登録テンプレート
To: ietf-digest-aka@iana.org
Subject: Registration of a new AKA version
To: ietf-digest-aka@iana.org Subject: 新しいAKAバージョンの登録
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:
詳細のために連絡する人と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.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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] フランクス、J.、ハラム-ベイカー、P.、Hostetler、J.、ローレンス、S.、リーチ、P.、Luotonen、A.、およびL.スチュワート、「HTTP認証:」 「基本的、そして、ダイジェストアクセス認証」、RFC2617、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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、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)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、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問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[6] 3rd Generation Partnership Project, "Security Architecture
(Release 4)", TS 33.102, December 2001.
[6] 第3世代パートナーシッププロジェクト、「セキュリティー体系(リリース4)」、t33.102、2001年12月。
[7] http://www.iana.org, "Assigned Numbers".
[7] http://www.iana.org 、「規定番号。」
Niemi, et. al. Informational [Page 16] RFC 3310 HTTP Digest Authentication Using AKA September 2002
et Niemi、アル。 別名2002年9月を使用する情報[16ページ]のRFC3310HTTPダイジェスト認証
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.
作者はSanjoy Sen、ジョナサン・ローゼンバーグ、ピートマッキャン、タオHaukka、Ilkka Uusitalo、ヘンリーHaverinen、ジョンLoughney、アリソン・マンキン、およびグレッグ・ローズに感謝したがっています。
Authors' Addresses
作者のアドレス
Aki Niemi Nokia P.O. Box 301 NOKIA GROUP, FIN 00045 Finland
アキNiemiノキア私書箱301Nokia Group、FIN00045フィンランド
Phone: +358 50 389 1644 EMail: aki.niemi@nokia.com
以下に電話をしてください。 +358 50 389 1644はメールされます: aki.niemi@nokia.com
Jari Arkko Ericsson Hirsalantie 1 Jorvas, FIN 02420 Finland
ヤリArkkoエリクソンHirsalantie1Jorvas、FIN02420フィンランド
Phone: +358 40 5079256 EMail: jari.arkko@ericsson.com
以下に電話をしてください。 +358 40 5079256はメールされます: jari.arkko@ericsson.com
Vesa Torvinen Ericsson Joukahaisenkatu 1 Turku, FIN 20520 Finland
Vesa TorvinenエリクソンJoukahaisenkatu1FIN20520トゥルク(フィンランド)
Phone: +358 40 7230822 EMail: vesa.torvinen@ericsson.fi
以下に電話をしてください。 +358 40 7230822はメールされます: vesa.torvinen@ericsson.fi
Niemi, et. al. Informational [Page 17] RFC 3310 HTTP Digest Authentication Using AKA September 2002
et Niemi、アル。 別名2002年9月を使用する情報[17ページ]のRFC3310HTTPダイジェスト認証
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Niemi, et. al. Informational [Page 18]
et Niemi、アル。 情報[18ページ]
一覧
スポンサーリンク
