--- 1/draft-ietf-sip-digest-aka-01.txt 2006-02-05 01:43:01.000000000 +0100
+++ 2/draft-ietf-sip-digest-aka-02.txt 2006-02-05 01:43:01.000000000 +0100
@@ -1,20 +1,20 @@
Network Working Group A. Niemi
Internet-Draft Nokia
-Expires: October 24, 2002 J. Arkko
+Expires: November 13, 2002 J. Arkko
V. Torvinen
Ericsson
- April 25, 2002
+ May 15, 2002
HTTP Digest Authentication Using AKA
- draft-ietf-sip-digest-aka-01
+ draft-ietf-sip-digest-aka-02
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
@@ -23,21 +23,21 @@
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
- This Internet-Draft will expire on October 24, 2002.
+ This Internet-Draft will expire on November 13, 2002.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
The Hypertext Transfer Protocol (HTTP) Authentication Framework
includes two authentication schemes: Basic and Digest. Both schemes
employ a shared secret based mechanism for access authentication.
@@ -240,26 +240,26 @@
should be used instead. The default aka-version is "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.
Example:
algorithm=AKAv1-MD5
- As the entropy of RES can be quite limited (e.g., only 32 bits),
+ 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. The RES SHOULD be used as a one-time
- password only. 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 with Digest AKA.
+ 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
aka-nonce = LDQUOT aka-nonce-value RDQUOT
aka-nonce-value =
@@ -608,25 +608,25 @@
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.
5.6 Replay Protection
- Optionally, 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
+ 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.
@@ -634,22 +634,22 @@
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 using
- Digest AKA. This is not possible with plain AKA.
+ protected along with other parts of the message, by using Digest AKA.
+ This is not possible with plain AKA.
6. IANA Considerations
(This section is not applicable until this document is published as
an RFC.)
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).