Network Working Group A. Niemi
Request for Comments: 3310 Nokia
Category: Informational J. Arkko
V. Torvinen
Ericsson
September 2002
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)
使用身份验证和密钥协议（AKA）的超文本传输协议（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.
版权所有（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.
此备忘录指定了一种基于身份验证和密钥协议（AKA）的一次性密码生成机制，用于超文本传输协议（HTTP）摘要访问身份验证。HTTP身份验证框架包括两种身份验证方案：Basic和Digest。这两个方案都采用基于共享秘密的访问认证机制。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
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]中描述的超文本传输协议（HTTP）认证框架包括两种认证方案：基本和摘要。这两个方案都采用基于共享秘密的访问认证机制。基本方案本质上是不安全的，因为它以纯文本传输用户凭证。摘要方案通过使用加密散列隐藏用户凭据以及提供有限的消息完整性来提高安全性。
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.
本文档指定AKA参数到HTTP摘要身份验证的映射。本质上，此映射支持将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身份验证令牌。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密码密钥。用于加密的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.
个人识别码。用于自动提款机、智能卡等的常用指定密码。
RAND Random Challenge. Generated by the AuC using the SQN.
随机挑战。由AuC使用SQN生成。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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. 在ISIM和认证中心（AuC）之间预先建立共享秘密K。秘密存储在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和序列号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. 身份验证向量将下载到服务器。或者，服务器还可以下载一批包含多个身份验证向量的AV。
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. 使用共享密钥K和序列号SQN，客户机使用ISIM验证AUTN。如果验证成功，则网络已通过身份验证。然后，客户端使用共享密钥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进行比较。如果两者匹配，则用户已成功通过身份验证，会话密钥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 = "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".
算法一个字符串，指示生成摘要和校验和时使用的算法。如果不理解该指令，则应忽略nonce，而应使用另一个质询（如果存在）。默认aka版本为“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 sess”之类的算法，该算法通过生成用于身份验证的会话密钥来限制使用单个密钥散列的内容量。
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 = "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 = "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是一个参数，由AKA身份验证质询RAND、AKA AUTN令牌和一些可选的服务器特定数据的串联的Base64[4]编码填充，如图1所示。
Example:
例子：
nonce="MzQ0a2xrbGtmbGtsZm9wb2tsc2tqaHJzZXNy9uQyMzMzMzQK="
nonce=“mzq0a2xrbgtmbgtszm9wb2tsc2tqahjzzxny9uqymzmzqk=”
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| 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”参数的客户端身份验证，该参数包括有效的AKA 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身份验证质询时，它从“nonce”参数中提取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 = "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编码的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检查参数值的有效性。有效的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使用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.
在摘要AKA中，服务器在计算RFC 2617中定义的“身份验证信息”报头的“响应身份验证”时使用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注册请求）的过程。
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) 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
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"
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正常身份验证信息：qop=auth int，rspauth=“6629fae4993a053997450978507c4ef1”，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) |
|<------------------------------------------------------|
| |
| 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
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="
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
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码时，才能执行认证。此类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实现更安全，因为拥有主机设备或软件中的特洛伊木马都无法访问长期机密。在使用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.
摘要方案使用服务器指定的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.
摘要AKA限制了nonce值对特定ISIM的适用性。通常，ISIM一次只能由一个客户端设备访问。然而，nonce值是强大且安全的，即使仅限于特定的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.
通过在每个响应的身份验证信息头字段中发送下一个nonce指令，服务器可以允许每个nonce值只使用一次。然而，如果相同的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.
通常，不建议将摘要AKA生成的密码与其他HTTP身份验证方案一起使用，即使域值或保护域是一致的。在这些情况下，应该向最终用户请求密码。摘要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.
由于用户选择的密码通常非常简单，因此建议服务器不接受字典[2]中的HTTP摘要密码。HTTP摘要AKA中不存在这种潜在威胁，因为该算法将使用源自ISIM的密码。但是，最终用户仍必须小心使用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参数恰好相同。更重要的是，这为攻击者重放网络发送的旧身份验证请求提供了额外的保护。客户端将能够检测到请求是旧的，并拒绝身份验证。这证明了身份验证请求的活跃性，即使在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被认为是一种安全机制，但它能够改进它。更具体地说，认证期间客户端和服务器之间携带的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节中指定了需要中央协调机构的aka版本名称空间。负责协调的机构是互联网分配号码管理局（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.
本文档中定义的默认aka版本为“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”前缀。例如，“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版本，aka版本值的初始IANA注册将包含一个“AKAv1”条目。
To: ietf-digest-aka@iana.org Subject: Registration of a new AKA version
致：ietf文摘-aka@iana.org主题：注册新的AKA版本
Version identifier:
版本标识符：
(Must contain a valid aka-version value, as described in section 3.1.)
（必须包含有效的aka版本值，如第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.，Lootonen，A.和L.Stewart，“HTTP认证：基本和摘要访问认证”，RFC 26171999年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：会话启动协议”，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）第一部分：互联网邮件正文格式”，RFC 20451996年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] 第三代合作项目，“安全体系结构（版本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诺基亚邮政信箱301
Phone: +358 50 389 1644
EMail: aki.niemi@nokia.com
Phone: +358 50 389 1644
EMail: aki.niemi@nokia.com
Jari Arkko Ericsson Hirsalantie 1 Jorvas, FIN 02420 Finland
芬兰芬兰若尔瓦斯雅丽阿尔科爱立信Hirsalantie 1号邮编02420
Phone: +358 40 5079256
EMail: jari.arkko@ericsson.com
Phone: +358 40 5079256
EMail: jari.arkko@ericsson.com
Vesa Torvinen Ericsson Joukahaisenkatu 1 Turku, FIN 20520 Finland
芬兰芬兰图尔库1号爱立信酒店20520
Phone: +358 40 7230822
EMail: vesa.torvinen@ericsson.fi
Phone: +358 40 7230822
EMail: 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编辑功能的资金目前由互联网协会提供。