rfc3310.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,012 行 · 第 1/3 页

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.

   AUTN
      Authentication Token.  A 128 bit value generated by the AuC, which
      together with the RAND parameter authenticates the server to the
      client.

   AUTS
      Authentication Token.  A 112 bit value generated by the client
      upon experiencing an SQN synchronization failure.

   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.

   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.

   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 resistant device.

   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.

   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.

   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.



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.

   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.

   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.

   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:

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


















Niemi, et. al.               Informational                      [Page 6]