draft-ietf-sip-digest-aka-00.txt   draft-ietf-sip-digest-aka-01.txt 
SIP Working Group A. Niemi Network Working Group A. Niemi
Internet-Draft Nokia Internet-Draft Nokia
Expires: October 16, 2002 J. Arkko Expires: October 24, 2002 J. Arkko
V. Torvinen V. Torvinen
Ericsson Ericsson
April 17, 2002 April 25, 2002
HTTP Digest Authentication Using AKA HTTP Digest Authentication Using AKA
draft-ietf-sip-digest-aka-00 draft-ietf-sip-digest-aka-01
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 16, 2002. This Internet-Draft will expire on October 24, 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 2, line 15 skipping to change at page 2, line 15
Table of Contents Table of Contents
1. Introduction and Motivation . . . . . . . . . . . . . . . . . 3 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. AKA Mechanism Overview . . . . . . . . . . . . . . . . . . . . 4 2. AKA Mechanism Overview . . . . . . . . . . . . . . . . . . . . 4
3. Specification of Digest AKA . . . . . . . . . . . . . . . . . 5 3. Specification of Digest AKA . . . . . . . . . . . . . . . . . 5
3.1 Algorithm Directive . . . . . . . . . . . . . . . . . . . . . 6 3.1 Algorithm Directive . . . . . . . . . . . . . . . . . . . . . 6
3.2 Creating a Challenge . . . . . . . . . . . . . . . . . . . . . 6 3.2 Creating a Challenge . . . . . . . . . . . . . . . . . . . . . 6
3.3 Client Authentication . . . . . . . . . . . . . . . . . . . . 7 3.3 Client Authentication . . . . . . . . . . . . . . . . . . . . 7
3.4 Synchronization Failure . . . . . . . . . . . . . . . . . . . 7 3.4 Synchronization Failure . . . . . . . . . . . . . . . . . . . 8
3.5 Server Authentication . . . . . . . . . . . . . . . . . . . . 8 3.5 Server Authentication . . . . . . . . . . . . . . . . . . . . 8
4. Example Digest AKA Operation . . . . . . . . . . . . . . . . . 8 4. Example Digest AKA Operation . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5.1 Authentication of Clients using Digest AKA . . . . . . . . . . 12 5.1 Authentication of Clients using Digest AKA . . . . . . . . . . 12
5.2 Limited Use of Nonce Values . . . . . . . . . . . . . . . . . 13 5.2 Limited Use of Nonce Values . . . . . . . . . . . . . . . . . 13
5.3 Multiple Authentication Schemes and Algorithms . . . . . . . . 13 5.3 Multiple Authentication Schemes and Algorithms . . . . . . . . 13
5.4 Online Dictionary Attacks . . . . . . . . . . . . . . . . . . 14 5.4 Online Dictionary Attacks . . . . . . . . . . . . . . . . . . 14
5.5 Session Protection . . . . . . . . . . . . . . . . . . . . . . 14 5.5 Session Protection . . . . . . . . . . . . . . . . . . . . . . 14
5.6 Replay Protection . . . . . . . . . . . . . . . . . . . . . . 14 5.6 Replay Protection . . . . . . . . . . . . . . . . . . . . . . 14
5.7 Improvements to AKA Security . . . . . . . . . . . . . . . . . 15 5.7 Improvements to AKA Security . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.1 Registration Template . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 Normative References . . . . . . . . . . . . . . . . . . . . . 16
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 Informative References . . . . . . . . . . . . . . . . . . . . 16
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18
1. Introduction and Motivation 1. Introduction and Motivation
The Hypertext Transfer Protocol (HTTP) Authentication Framework The Hypertext Transfer Protocol (HTTP) Authentication Framework
described in RFC 2617 [2] includes two authentication schemes: Basic described in RFC 2617 [2] includes two authentication schemes: Basic
and Digest. Both schemes employ a shared secret based mechanism for and Digest. Both schemes employ a shared secret based mechanism for
access authentication. The Basic scheme is inherently insecure in access authentication. The Basic scheme is inherently insecure in
that it transmits user credentials in plain text. The Digest scheme that it transmits user credentials in plain text. The Digest scheme
improves security by hiding user credentials with cryptographic improves security by hiding user credentials with cryptographic
hashes, and additionally by providing limited message integrity. hashes, and additionally by providing limited message integrity.
skipping to change at page 3, line 27 skipping to change at page 3, line 27
Telecommunications System (UMTS) networks. AKA is a challenge- Telecommunications System (UMTS) networks. AKA is a challenge-
response based mechanism that uses symmetric cryptography. AKA is response based mechanism that uses symmetric cryptography. AKA is
typically run in a UMTS IM Services Identity Module (ISIM), which typically run in a UMTS IM Services Identity Module (ISIM), which
resides on a smart card like device that also provides tamper proof resides on a smart card like device that also provides tamper proof
storage of shared secrets. storage of shared secrets.
This document specifies a mapping of AKA parameters onto HTTP Digest This document specifies a mapping of AKA parameters onto HTTP Digest
authentication. In essence, this mapping enables the usage of AKA as authentication. In essence, this mapping enables the usage of AKA as
a one-time password generation mechanism for Digest authentication. a one-time password generation mechanism for Digest authentication.
As the Session Initiation Protocol (SIP) [4] Authentication Framework As the Session Initiation Protocol (SIP) [3] Authentication Framework
closely follows the HTTP Authentication Framework, Digest AKA is closely follows the HTTP Authentication Framework, Digest AKA is
directly applicable to SIP as well as any other embodiment of HTTP directly applicable to SIP as well as any other embodiment of HTTP
Digest. Digest.
1.1 Terminology 1.1 Terminology
This chapter explains the terminology used in this document. This chapter explains the terminology used in this document.
AKA AKA
Authentication and Key Agreement. Authentication and Key Agreement.
skipping to change at page 5, line 49 skipping to change at page 5, line 49
number. number.
For a specification of the AKA mechanism and the generation of the For a specification of the AKA mechanism and the generation of the
cryptographic parameters AUTN, RES, IK, CK, and AUTS, see reference cryptographic parameters AUTN, RES, IK, CK, and AUTS, see reference
3GPP TS 33.102 [6]. 3GPP TS 33.102 [6].
3. Specification of Digest AKA 3. Specification of Digest AKA
In general, Digest AKA operation is identical to Digest operation in In general, Digest AKA operation is identical to Digest operation in
RFC 2617 [2]. This chapter specifies the parts, in which Digest AKA RFC 2617 [2]. This chapter specifies the parts, in which Digest AKA
extends the Digest operation. 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 3.1 Algorithm Directive
In order to direct the client into using AKA for authentication In order to direct the client into using AKA for authentication
instead of the standard password system, the RFC 2617 defined instead of the standard password system, the RFC 2617 defined
algorithm directive is overloaded in Digest AKA: algorithm directive is overloaded in Digest AKA:
algorithm = "algorithm" EQUAL aka-namespace algorithm = "algorithm" EQUAL aka-namespace
aka-namespace = aka-version "-" algorithm-value aka-namespace = aka-version "-" algorithm-value
aka-version = "AKAv" 1*DIGIT aka-version = "AKAv" 1*DIGIT
skipping to change at page 6, line 30 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),
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.
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>
nonce nonce
A parameter, which is populated with the Base64 [5] encoding of A parameter, which is populated with the Base64 [4] encoding of
the concatenation of the AKA authentication challenge RAND, the the concatenation of the AKA authentication challenge RAND, the
AKA AUTN token, and optionally some server specific data, as in AKA AUTN token, and optionally some server specific data, as in
Figure 1. Figure 1.
Example: Example:
nonce="MzQ0a2xrbGtmbGtsZm9wb2tsc2tqaHJzZXNy9uQyMzMzMzQK=" nonce="MzQ0a2xrbGtmbGtsZm9wb2tsc2tqaHJzZXNy9uQyMzMzMzQK="
0 1 2 3 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 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
skipping to change at page 15, line 18 skipping to change at page 15, line 28
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 using
Digest AKA. This is not possible with plain AKA. Digest AKA. This is not possible with plain AKA.
6. IANA Considerations 6. IANA Considerations
This document specifies a namespace for the AKA versions in Section (This section is not applicable until this document is published as
3.1, with the default version being "AKAv1". Following the policies an RFC.)
outlined in [3], versions above 1 are allocated as Expert Review.
References 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.
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 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., [2] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication:
Basic and Digest Access Authentication", RFC 2617, June 1999. Basic and Digest Access Authentication", RFC 2617, June 1999.
[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [3] Rosenberg, J. and H. Schulzrinne, "SIP: Session Initiation
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[4] Rosenberg, J. and H. Schulzrinne, "SIP: Session Initiation
Protocol", draft-ietf-sip-rfc2543bis-09 (work in progress), Protocol", draft-ietf-sip-rfc2543bis-09 (work in progress),
February 2002. February 2002.
[5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies", Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996. 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 [6] 3rd Generation Partnership Project, "Security Architecture
(Release 4)", TS 33.102, December 2001. (Release 4)", TS 33.102, December 2001.
[7] http://www.iana.org, "Assigned Numbers", February 2002. [7] http://www.iana.org, "Assigned Numbers", February 2002.
Authors' Addresses Authors' Addresses
Aki Niemi Aki Niemi
Nokia Nokia
P.O. Box 301 P.O. Box 301
skipping to change at page 16, line 37 skipping to change at page 17, line 37
Joukahaisenkatu 1 Joukahaisenkatu 1
Turku, FIN 20520 Turku, FIN 20520
Finland Finland
Phone: +358 40 7230822 Phone: +358 40 7230822
EMail: vesa.torvinen@ericsson.fi EMail: vesa.torvinen@ericsson.fi
Appendix A. Acknowledgements Appendix A. Acknowledgements
The authors would like to thank Sanjoy Sen, Jonathan Rosenberg, Pete The authors would like to thank Sanjoy Sen, Jonathan Rosenberg, Pete
McCann, Tao Haukka, Ilkka Uusitalo, Henry Haverinen, John Loughney McCann, Tao Haukka, Ilkka Uusitalo, Henry Haverinen, John Loughney,
and Allison Mankin. Allison Mankin and Greg Rose.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
 End of changes. 

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