AKA简单翻译 认证与密钥协商

 希望大家与我完善他

 

 

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.

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.

 

 

 

 

 

 

 

 

 

Niemi, et. al.               Informational                      [Page 1]

RFC 3310          HTTP Digest Authentication Using AKA    September 2002

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

   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.

   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.

 

 

Niemi, et. al.               Informational                      [Page 2]

RFC 3310          HTTP Digest Authentication Using AKA    September 2002

   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.

   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.

1.1 Terminology

   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.
      认证中心，在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.
      网络认证令牌。由认证中心产生的128位数值，并从服务器传输给客户的；认证令牌携带着RAND.

   AUTS
      Authentication Token.  A 112 bit value generated by the client
      upon experiencing an SQN synchronization failure.
      认证令牌。由客户生成的112位数值。

   CK
      Cipher Key.  An AKA session key for encryption.
      密钥。

   IK
      Integrity Key.  An AKA session key for integrity check.
      完整性校验密钥。

   ISIM
      IP Multimedia Services Identity Module.

   PIN
      Personal Identification Number.  Commonly assigned passcodes for
      use with automatic cash machines, smart cards, etc.
      个人识别号。

   RAND
      Random Challenge.  Generated by the AuC using the SQN.
      随机口令。认证中心根据SQN产生。

   RES
      Authentication Response.  Generated by the ISIM.
      认证响应。客户端产生的。

Niemi, et. al.               Informational                      [Page 3]

RFC 3310          HTTP Digest Authentication Using AKA    September 2002

   SIM
      Subscriber Identity Module.  GSM counter part for ISIM.
      用户ID
   SQN
      Sequence Number.  Both AuC and ISIM maintain the value of the SQN.
     
   UMTS
      Universal Mobile Telecommunications System.
      通用移动电信系统

   XRES
      Expected Authentication Response.  In a successful authentication
      this is equal to RES.
      期望认证响应。期望认证响应是保存在服务其端的。如果期望认证响应等于认证响应，则成功认证。

1.2 Conventions

   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].

2. AKA Mechanism Overview

   This chapter describes the AKA operation in detail:

   1. A shared secret K is established beforehand between the ISIM and
      the Authentication Center (AuC).  The secret is stored in the
      ISIM, which resides on a smart card like, tamper resista
13653
nt device.
      共享密钥K是根据ISIM和AUC预先定义的。他存储于ISIM中，ISIM保存在智能卡中。
     
   2. The AuC of the home network produces an authentication vector AV,
      based on the shared secret K and a sequence number SQN.  The
      authentication vector contains a random challenge RAND, network
      authentication token AUTN, expected authentication result XRES, a
      session key for integrity check IK, and a session key for
      encryption CK.
      认证中心根据共享密钥K和序列号产生认证矢量(AV)。认证矢量包含一下信息：
      随机口令(RAND)、网络认证令牌(AUTN)、期望认证响应(XRES)、密钥(CK)和完整性密钥(IK)。

   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.
      服务器从认证中心下载认证矢量。另外服务器也可以成批的下载认证矢量。     

   4. The server creates an authentication request, which contains the
      random challenge RAND, and the network authenticator token AUTN.
      服务器创建认证请求，认证请求中包含了随机口令RAND和网络认证令牌AUTN。

   5. The authentication request is delivered to the client.
      服务器产生的认证请求发送到客户端。

   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.
      客户端用公共密钥K和序列号(SQN)校验AUTN；校验成功，则证明接入的网络是合法的。
      客户端校验网络成功之后，用共享密钥K和随机口令(RAND)产生认证响应(RES)。

Niemi, et. al.               Informational                      [Page 4]

RFC 3310          HTTP Digest Authentication Using AKA    September 2002

   7. The authentication response, RES, is delivered to the server.
      客户端发送认证响应(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.
      服务器比较认证响应(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和获得的序列号来
   产生同步认证令牌（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].

3. Specification of Digest AKA

   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.

3.1 Algorithm Directive

   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取代了通常的密码认证算法；

           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".

 

Niemi, et. al.               Informational                      [Page 5]

RFC 3310          HTTP Digest Authentication Using AKA    September 2002

      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.

      Example:

            algorithm=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.

3.2 Creating a Challenge

   In order to deliver the AKA authentication challenge to the client in
   Digest AKA, the nonce directive defined in RFC 2617 is extended:
   nonce目的是发送AKA认证命令到客户端，一下是在RFC2617上扩展的none定义：

           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是个参数。他是由RAND、AUTN和服务器的特殊的数据串联，再用Base64编码。（如图1）

 

 

 

 

 

 

 

 

Niemi, et. al.               Informational                      [Page 6]

RFC 3310          HTTP Digest Authentication Using AKA    September 2002

      Example:

          nonce="MzQ0a2xrbGtmbGtsZm9wb2tsc2tqaHJzZXNy9uQyMzMzMzQK="

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                            RAND                               |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                            AUTN                               |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Server Data...
      +-+-+-+-+-+-+-+-+-+-+-+

                    Figure 1: Generating the nonce value.

   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.
   如果服务器收到的客户认证中包含auts参数，并且是有效的AUTS，这时服务器必须用AUTS生成新的客户端口令。
   注意：当AUTS存在时，包括的"response"参数用空密码代替RES来计算。

3.3 Client Authentication

   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是在期望的范围内，这时客户端使用RAND和共享密钥K进行AKA运算。

   The resulting AKA RES parameter is treated as a "password" when
   calculating the response directive of RFC 2617.
   运算结果RES被视为计算response时的密码。

3.4 Synchronization Failure（同步失败）

   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:
   AUTS是用于代表AKA序号同步失败和需要重新同步，因此对
   头字段Authorization的digest-response参数增加了一个新的描述信息AUTS。

 

Niemi, et. al.               Informational                      [Page 7]

RFC 3310          HTTP Digest Authentication Using AKA    September 2002

           auts                =  "auts" EQUAL auts-param
           auts-param          =  LDQUOT auts-value RDQUOT
           auts-value          =  <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编码。指示服务器重新同步SQN。如果AUTS存在，则客户端
      不需要使用密码（password）计算证书，计算时密码（password）置为空字符串。

      Example:

            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.
   服务器用共享密钥K检查接收的AUTS值的有效性。有效的AUTS用于重新同步AuC的SQN。
   用新同步的序列号生成新的认证矢量（AU）。

3.5 Server Authentication

   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.
  

   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摘要中，服务器在计算头字段Authentication-Info的response-auth参数时，用XRES代替密码（password）。
  
4. Example Digest AKA Operation

   Figure 2 below describes a message flow describing a Digest AKA
   process of authenticating a SIP request, namely the SIP REGISTER
   request.

 

 

 

 

 

 

Niemi, et. al.               Informational                      [Page 8]

RFC 3310          HTTP Digest Authentication Using AKA    September 2002

      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.

   1) Initial request

      REGISTER sip:home.mobile.biz SIP/2.0

 

 

 

 

 

Niemi, et. al.               Informational                      [Page 9]

RFC 3310          HTTP Digest Authentication Using AKA    September 2002

   2) Response containing a challenge

      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

      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

      SIP/2.0 200 OK
      Authentication-Info:
              qop=auth-int,
              rspauth="6629fae49393a05397450978507c4ef1",
              cnonce="0a4f113b",
              nc=00000001

 

 

 

 

 

 

 

 

 

Niemi, et. al.               Informational                     [Page 10]

RFC 3310          HTTP Digest Authentication Using AKA    September 2002

   Figure 3 below describes a message flow describing a Digest AKA
   authentication process, in which there is a synchronization failure.

      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.

 

 

Niemi, et. al.               Informational                     [Page 11]

RFC 3310          HTTP Digest Authentication Using AKA    September 2002

   1) Initial request

      REGISTER sip:home.mobile.biz SIP/2.0

   2) Response containing a challenge

      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

      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

      SIP/2.0 401 Unauthorized
      WWW-Authenticate: Digest
            realm="RoamingUsers@mobile.biz",
            qop="auth,auth-int",
            nonce="9uQzNPbk9jM05Pbl5Pbl5DIz9uTl9uTl9jM0NTHk9uXk==",
            opaque="dcd98b7102dd2f0e8b11d0f600bfb0c093",
            algorithm=AKAv1-MD5

5. Security Considerations

   In general, Digest AKA is vulnerable to the same security threats as
   HTTP authentication [2].  This chapter discusses the relevant
   exceptions.
   一般来说，AKA摘要作为HTTP认证方式是易受完全攻击的。本节讨论相关的异常。

 

 

Niemi, et. al.               Informational                     [Page 12]

RFC 3310          HTTP Digest Authentication Using AKA    September 2002

5.1 Authentication of Clients using Digest AKA

   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.

   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.

5.2 Limited Use of Nonce Values

   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.

   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.

 

 

Niemi, et. al.               Informational                     [Page 13]

RFC 3310          HTTP Digest Authentication Using AKA    September 2002

5.3 Multiple Authentication Schemes and Algorithms

   In HTTP authentication, a user agent MUST choose the strongest
   authentication scheme it understands and request credentials from the
   user, based upon that challenge.

   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.

   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".

5.4 Online Dictionary Attacks

   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.

5.5 Session Protection

   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.

 

 

Niemi, et. al.               Informational                     [Page 14]

RFC 3310          HTTP Digest Authentication Using AKA    September 2002

5.6 Replay Protection

   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.

   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.

5.7 Improvements to AKA Security

   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.

6. IANA Considerations

   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).

   The default aka-version defined in this document is "AKAv1".
   Following the policies outlined in [5], versions above 1 are
   allocated as Expert Review.

   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.

 

Niemi, et. al.               Informational                     [Page 15]

RFC 3310          HTTP Digest Authentication Using AKA    September 2002

   As this document defines the default aka-version, the initial IANA
   registration for aka-version values will contain an entry for
   "AKAv1".

6.1 Registration Template

      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:

          (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.

   [2]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
        Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication:
        Basic and Digest Access Authentication", RFC 2617, June 1999.

   [3]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
        Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
        Session Initiation Protocol", RFC 3261, June 2002.

   [4]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
        Extensions (MIME) Part One: Format of Internet Message Bodies",
        RFC 2045, November 1996.

Informative References

   [5]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

   [6]  3rd Generation Partnership Project, "Security Architecture
        (Release 4)", TS 33.102, December 2001.

   [7]  http://www.iana.org, "Assigned Numbers".

 

 

Niemi, et. al.               Informational                     [Page 16]

RFC 3310          HTTP Digest Authentication Using AKA    September 2002

Appendix A. Acknowledgements

   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

   Phone: +358 50 389 1644
   EMail: aki.niemi@nokia.com

   Jari Arkko
   Ericsson
   Hirsalantie 1
   Jorvas, FIN  02420
   Finland

   Phone: +358 40 5079256
   EMail: jari.arkko@ericsson.com

   Vesa Torvinen
   Ericsson
   Joukahaisenkatu 1
   Turku, FIN  20520
   Finland

   Phone: +358 40 7230822
   EMail: vesa.torvinen@ericsson.fi

 

 

 

 

 

 

 

Niemi, et. al.               Informational                     [Page 17]

RFC 3310          HTTP Digest Authentication Using AKA    September 2002

Full Copyright Statement

   Copyright (C) The Internet Society (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.

   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.

 

 

 

 

 

 

 

 

 

Niemi, et. al.               Informational                     [Page 18]