doc: Add RFC documents

1 files changed, 1011 insertions, 0 deletions

diff --git a/doc/rfc/rfc3310.txt b/doc/rfc/rfc3310.txt
new file mode 100644
index 0000000..edd2aff
--- /dev/null
+++ b/doc/rfc/rfc3310.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+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]
+
+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.
+
+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.
+
+   The resulting AKA RES parameter is treated as a "password" when
+   calculating the response directive of RFC 2617.
+
+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:
+
+
+
+
+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 "").
+
+      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.
+
+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.
+
+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.
+
+
+
+
+
+
+
+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]
+