draft-ietf-sip-digest-aka-01.txt   draft-ietf-sip-digest-aka-02.txt 
Network Working Group A. Niemi Network Working Group A. Niemi
Internet-Draft Nokia Internet-Draft Nokia
Expires: October 24, 2002 J. Arkko Expires: November 13, 2002 J. Arkko
V. Torvinen V. Torvinen
Ericsson Ericsson
April 25, 2002 May 15, 2002
HTTP Digest Authentication Using AKA HTTP Digest Authentication Using AKA
draft-ietf-sip-digest-aka-01 draft-ietf-sip-digest-aka-02
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. 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 Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) Authentication Framework The Hypertext Transfer Protocol (HTTP) Authentication Framework
includes two authentication schemes: Basic and Digest. Both schemes includes two authentication schemes: Basic and Digest. Both schemes
employ a shared secret based mechanism for access authentication. employ a shared secret based mechanism for access authentication.
skipping to change at page 6, line 31 skipping to change at page 6, line 31
should be used instead. The default aka-version is "AKAv1". should be used instead. The default aka-version is "AKAv1".
Further AKA versions can be specified, with version numbers Further AKA versions can be specified, with version numbers
assigned by IANA [7]. When the algorithm directive is not assigned by IANA [7]. When the algorithm directive is not
present, it is assumed to be "MD5". This indicates, that AKA is present, it is assumed to be "MD5". This indicates, that AKA is
not used to produce the Digest password. not used to produce the Digest password.
Example: Example:
algorithm=AKAv1-MD5 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 reuse of the same RES value in authenticating subsequent requests and
responses is NOT RECOMMENDED. The RES SHOULD be used as a one-time responses is NOT RECOMMENDED. Such a RES value SHOULD only be used
password only. Algorithms such as "MD5-sess", which limit the amount as a one-time password and algorithms such as "MD5-sess", which limit
of material hashed with a single key by producing a session key for the amount of material hashed with a single key by producing a
authentication, SHOULD NOT be used with Digest AKA. session key for authentication, SHOULD NOT be used.
3.2 Creating a Challenge 3.2 Creating a Challenge
In order to deliver the AKA authentication challenge to the client in In order to deliver the AKA authentication challenge to the client in
Digest AKA, the nonce directive defined in RFC 2617 is extended: Digest AKA, the nonce directive defined in RFC 2617 is extended:
nonce = "nonce" EQUAL aka-nonce nonce = "nonce" EQUAL aka-nonce
aka-nonce = LDQUOT aka-nonce-value RDQUOT aka-nonce = LDQUOT aka-nonce-value RDQUOT
aka-nonce-value = <base64 encoding of RAND, AUTN, and aka-nonce-value = <base64 encoding of RAND, AUTN, and
server specific data> server specific data>
skipping to change at page 14, line 45 skipping to change at page 14, line 45
5.5 Session Protection 5.5 Session Protection
Digest AKA is able to generate additional session keys for integrity Digest AKA is able to generate additional session keys for integrity
(IK) and confidentiality (CK) protection. Even though this document (IK) and confidentiality (CK) protection. Even though this document
does not specify the use of these additional keys, they may be used does not specify the use of these additional keys, they may be used
for creating additional security within HTTP authentication or some for creating additional security within HTTP authentication or some
other security mechanism. other security mechanism.
5.6 Replay Protection 5.6 Replay Protection
Optionally, AKA allows sequence numbers to be tracked for each AKA allows sequence numbers to be tracked for each authentication,
authentication, with the SQN parameter. This allows authentications with the SQN parameter. This allows authentications to be replay
to be replay protected even if the RAND parameter happened to be the protected even if the RAND parameter happened to be the same for two
same for two authentication requests. More importantly, this offers authentication requests. More importantly, this offers additional
additional protection for the case where an attacker replays an old protection for the case where an attacker replays an old
authentication request sent by the network. The client will be able authentication request sent by the network. The client will be able
to detect that the request is old, and refuse authentication. This to detect that the request is old, and refuse authentication. This
proves liveliness of the authentication request even in the case proves liveliness of the authentication request even in the case
where a MitM attacker tries to trick the client into providing an where a MitM attacker tries to trick the client into providing an
authentication response, and then replaces parts of the message with authentication response, and then replaces parts of the message with
something else. In other words, a client challenged by Digest AKA is something else. In other words, a client challenged by Digest AKA is
not vulnerable for chosen plain text attacks. Finally, frequent not vulnerable for chosen plain text attacks. Finally, frequent
sequence number errors would reveal an attack where the tamper- sequence number errors would reveal an attack where the tamper-
resistant card has been cloned and is being used in multiple devices. resistant card has been cloned and is being used in multiple devices.
skipping to change at page 15, line 23 skipping to change at page 15, line 23
more information for each user than just their long-term secret, more information for each user than just their long-term secret,
namely the current SQN value. However, this information is typically namely the current SQN value. However, this information is typically
not stored in the SIP nodes, but in dedicated authentication servers not stored in the SIP nodes, but in dedicated authentication servers
instead. instead.
5.7 Improvements to AKA Security 5.7 Improvements to AKA Security
Even though AKA is perceived as a secure mechanism, Digest AKA is Even though AKA is perceived as a secure mechanism, Digest AKA is
able to improve it. More specifically the AKA parameters carried able to improve it. More specifically the AKA parameters carried
between the client and the server during authentication may be between the client and the server during authentication may be
protected along with other parts of the message, by using using protected along with other parts of the message, by using Digest AKA.
Digest AKA. This is not possible with plain AKA. This is not possible with plain AKA.
6. IANA Considerations 6. IANA Considerations
(This section is not applicable until this document is published as (This section is not applicable until this document is published as
an RFC.) an RFC.)
This document specifies an aka-version namespace in Section 3.1 which This document specifies an aka-version namespace in Section 3.1 which
requires a central coordinating body. The body responsible for this requires a central coordinating body. The body responsible for this
coordination is the Internet Assigned Numbers Authority (IANA). coordination is the Internet Assigned Numbers Authority (IANA).
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/