draft-ietf-sip-digest-aka-03.txt   rfc3310.txt 
Network Working Group A. Niemi Network Working Group A. Niemi
Internet-Draft Nokia Request for Comments: 3310 Nokia
Expires: November 18, 2002 J. Arkko Category: Informational J. Arkko
V. Torvinen V. Torvinen
Ericsson Ericsson
May 20, 2002 September 2002
HTTP Digest Authentication Using AKA Hypertext Transfer Protocol (HTTP) Digest Authentication
draft-ietf-sip-digest-aka-03 Using Authentication and Key Agreement (AKA)
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This memo provides information for the Internet community. It does
all provisions of Section 10 of RFC2026. not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
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.
Internet-Drafts are draft documents valid for a maximum of six months
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 November 18, 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 This memo specifies an Authentication and Key Agreement (AKA) based
includes two authentication schemes: Basic and Digest. Both schemes one-time password generation mechanism for Hypertext Transfer
employ a shared secret based mechanism for access authentication. Protocol (HTTP) Digest access authentication. The HTTP
The Authentication and Key Agreement (AKA) mechanism performs user 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 authentication and session key distribution in Universal Mobile
Telecommunications System (UMTS) networks. AKA is a challenge- Telecommunications System (UMTS) networks. AKA is a challenge-
response based mechanism that uses symmetric cryptography. This memo response based mechanism that uses symmetric cryptography.
specifies an AKA based one-time password generation mechanism for
HTTP Digest access authentication.
Table of Contents Table of Contents
1. Introduction and Motivation . . . . . . . . . . . . . . . . . 3 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 2
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 . . . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . . 8 3.4 Synchronization Failure . . . . . . . . . . . . . . . . . . . 7
3.5 Server Authentication . . . . . . . . . . . . . . . . . . . . 8 3.5 Server Authentication . . . . . . . . . . . . . . . . . . . . 8
4. Example Digest AKA Operation . . . . . . . . . . . . . . . . . 9 4. Example Digest AKA Operation . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . 13
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 . . . . . . . . 14
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 . . . . . . . . . . . . . . . . . . . . . . 15
5.7 Improvements to AKA Security . . . . . . . . . . . . . . . . . 15 5.7 Improvements to AKA Security . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6.1 Registration Template . . . . . . . . . . . . . . . . . . . . 16 6.1 Registration Template . . . . . . . . . . . . . . . . . . . . 16
Normative References . . . . . . . . . . . . . . . . . . . . . 16 Normative References . . . . . . . . . . . . . . . . . . . . . 16
Informative References . . . . . . . . . . . . . . . . . . . . 16 Informative References . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18 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.
The Authentication and Key Agreement (AKA) [6] mechanism performs The Authentication and Key Agreement (AKA) [6] mechanism performs
authentication and session key distribution in Universal Mobile authentication and session key distribution in Universal Mobile
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
skipping to change at page 4, line 39 skipping to change at page 4, line 22
Universal Mobile Telecommunications System. Universal Mobile Telecommunications System.
XRES XRES
Expected Authentication Response. In a successful authentication Expected Authentication Response. In a successful authentication
this is equal to RES. this is equal to RES.
1.2 Conventions 1.2 Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. document are to be interpreted as described in BCP 14, RFC 2119 [1].
2. AKA Mechanism Overview 2. AKA Mechanism Overview
This chapter describes the AKA operation in detail: This chapter describes the AKA operation in detail:
1. A shared secret K is established beforehand between the ISIM and 1. A shared secret K is established beforehand between the ISIM and
the Authentication Center (AuC). The secret is stored in the the Authentication Center (AuC). The secret is stored in the
ISIM, which resides on a smart card like, tamper resistant ISIM, which resides on a smart card like, tamper resistant device.
device.
2. The AuC of the home network produces an authentication vector AV 2. The AuC of the home network produces an authentication vector AV,
based on the shared secret K and a sequence number SQN. The based on the shared secret K and a sequence number SQN. The
authentication vector contains a random challenge RAND, network authentication vector contains a random challenge RAND, network
authentication token AUTN, expected authentication result XRES, a authentication token AUTN, expected authentication result XRES, a
session key for integrity check IK, and a session key for session key for integrity check IK, and a session key for
encryption CK. encryption CK.
3. The authentication vector is downloaded to a server. Optionally, 3. The authentication vector is downloaded to a server. Optionally,
the server can also download a batch of AVs, containing more than the server can also download a batch of AVs, containing more than
one authentication vector. one authentication vector.
4. The server creates an authentication request, which contains the 4. The server creates an authentication request, which contains the
random challenge RAND, and the network authenticator token AUTN. random challenge RAND, and the network authenticator token AUTN.
5. The authentication request is delivered to the client. 5. The authentication request is delivered to the client.
6. Using the shared secret K and the sequence number SQN, 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 verifies the AUTN with the ISIM. If the verification is
successful, the network has been authenticated. The client then successful, the network has been authenticated. The client then
produces an authentication response RES, using the shared secret produces an authentication response RES, using the shared secret K
K and the random challenge RAND. and the random challenge RAND.
7. The authentication response RES is delivered to the server. 7. The authentication response, RES, is delivered to the server.
8. The server compares the authentication response RES with the 8. The server compares the authentication response RES with the
expected response XRES. If the two match, the user has been expected response, XRES. If the two match, the user has been
successfully authenticated, and the session keys IK and CK can be successfully authenticated, and the session keys, IK and CK, can
used for protecting further communications between the client and be used for protecting further communications between the client
the server. and the server.
When verifying the AUTN, the client may detect, that the sequence When verifying the AUTN, the client may detect that the sequence
numbers between the client and the server have fallen out of sync. numbers between the client and the server have fallen out of sync.
In this case, the client produces a synchronization parameter AUTS, In this case, the client produces a synchronization parameter AUTS,
using the shared secret K and the client sequence number SQN. The using the shared secret K and the client sequence number SQN. The
AUTS parameter is delivered to the network in the authentication AUTS parameter is delivered to the network in the authentication
response, and the authentication can be tried again based on response, and the authentication can be tried again based on
authentication vectors generated with the synchronized sequence authentication vectors generated with the synchronized sequence
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, the Digest AKA operation is identical to the Digest
RFC 2617 [2]. This chapter specifies the parts, in which Digest AKA operation in RFC 2617 [2]. This chapter specifies the parts in which
extends the Digest operation. The notation used in the Augmented BNF Digest AKA extends the Digest operation. The notation used in the
definitions for the new and modified syntax elements in this section Augmented BNF definitions for the new and modified syntax elements in
is as used in SIP [3], and any elements not defined in this section this section is as used in SIP [3], and any elements not defined in
are as defined in SIP and the documents to which it refers. 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
/ algorithm-value )
aka-namespace = aka-version "-" algorithm-value aka-namespace = aka-version "-" algorithm-value
aka-version = "AKAv" 1*DIGIT aka-version = "AKAv" 1*DIGIT
algorithm-value = ( "MD5" / "MD5-sess" / token ) algorithm-value = ( "MD5" / "MD5-sess" / token )
algorithm algorithm
A string indicating the algorithm used in producing the digest and A string indicating the algorithm used in producing the digest and
the checksum. If the directive is not understood, the nonce the checksum. If the directive is not understood, the nonce
SHOULD be ignored, and another challenge (if one is present) SHOULD be ignored, and another challenge (if one is present)
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
If the entropy of the used RES value is limited (e.g., only 32 bits), If the entropy of the used RES value is limited (e.g., only 32
reuse of the same RES value in authenticating subsequent requests and bits), reuse of the same RES value in authenticating subsequent
responses is NOT RECOMMENDED. Such a RES value SHOULD only be used requests and responses is NOT RECOMMENDED. Such a RES value
as a one-time password and algorithms such as "MD5-sess", which limit SHOULD only be used as a one-time password, and algorithms such as
the amount of material hashed with a single key by producing a "MD5-sess", which limit the amount of material hashed with a
session key for authentication, SHOULD NOT be used. single key, by producing a 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
/ nonce-value )
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 [4] 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.
skipping to change at page 7, line 39 skipping to change at page 7, line 28
| AUTN | | AUTN |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Server Data... | Server Data...
+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Generating the nonce value. Figure 1: Generating the nonce value.
If the server receives a client authentication containing the "auts" If the server receives a client authentication containing the "auts"
parameter defined in Section 3.4 that includes a valid AKA 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 parameter, the server MUST use it to generate a new challenge to the
client. Note that when the AUTS is present, the included "response" client. Note that when the AUTS is present, the included "response"
parameter is calculated using an empty password (password of ""), parameter is calculated using an empty password (password of ""),
instead of a RES. instead of a RES.
3.3 Client Authentication 3.3 Client Authentication
When a client receives a Digest AKA authentication challenge, it When a client receives a Digest AKA authentication challenge, it
extracts the RAND and AUTN from the "nonce" parameter, and assesses extracts the RAND and AUTN from the "nonce" parameter, and assesses
the AUTN token provided by the server. If the client successfully the AUTN token provided by the server. If the client successfully
authenticates the server with the AUTN, and determines that the SQN authenticates the server with the AUTN, and determines that the SQN
used in generating the challenge is within expected range, the AKA used in generating the challenge is within expected range, the AKA
algorithms are run with the RAND challenge and shared secret K. algorithms are run with the RAND challenge and shared secret K.
The resulting AKA RES parameter is treated as "password" when The resulting AKA RES parameter is treated as a "password" when
calculating the response directive of RFC 2617. calculating the response directive of RFC 2617.
3.4 Synchronization Failure 3.4 Synchronization Failure
For indicating an AKA sequence number synchronization failure, and to For indicating an AKA sequence number synchronization failure, and to
re-synchronize the SQN in the AuC using the AUTS token, a new re-synchronize the SQN in the AuC using the AUTS token, a new
directive is defined for the "digest-response" of the "Authorization" directive is defined for the "digest-response" of the "Authorization"
request header defined in RFC 2617: request header defined in RFC 2617:
auts = "auts" EQUAL auts-param auts = "auts" EQUAL auts-param
skipping to change at page 13, line 50 skipping to change at page 14, line 9
A server may allow each nonce value to be used only once by sending a 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 next-nonce directive in the Authentication-Info header field of every
response. However, this may cause a synchronization failure, and response. However, this may cause a synchronization failure, and
consequently some additional round trips in AKA, if the same SQN consequently some additional round trips in AKA, if the same SQN
space is also used for other access schemes at the same time. space is also used for other access schemes at the same time.
5.3 Multiple Authentication Schemes and Algorithms 5.3 Multiple Authentication Schemes and Algorithms
In HTTP authentication, a user agent MUST choose the strongest In HTTP authentication, a user agent MUST choose the strongest
authentication scheme it understands and request credentials from the authentication scheme it understands and request credentials from the
user based upon that challenge. user, based upon that challenge.
In general, using passwords generated by Digest AKA with other HTTP In general, using passwords generated by Digest AKA with other HTTP
authentication schemes is not recommended even though the realm authentication schemes is not recommended even though the realm
values or protection domains would coincide. In these cases, a values or protection domains would coincide. In these cases, a
password should be requested from the end-user instead. Digest AKA password should be requested from the end-user instead. Digest AKA
passwords MUST NOT be re-used with such HTTP authentication schemes, passwords MUST NOT be re-used with such HTTP authentication schemes,
which send the password in clear. In particular, AKA passwords MUST which send the password in clear. In particular, AKA passwords MUST
NOT be re-used with HTTP Basic. NOT be re-used with HTTP Basic.
The same principle must be applied within a scheme if several The same principle must be applied within a scheme if several
skipping to change at page 14, line 31 skipping to change at page 14, line 39
which are in the dictionary [2]. This potential threat does not which are in the dictionary [2]. This potential threat does not
exist in HTTP Digest AKA because the algorithm will use ISIM exist in HTTP Digest AKA because the algorithm will use ISIM
originated passwords. However, the end-user must still be careful originated passwords. However, the end-user must still be careful
with PIN codes. Even though HTTP Digest AKA password requests are with PIN codes. Even though HTTP Digest AKA password requests are
never displayed to the end-user, she will be authenticated to the never displayed to the end-user, she will be authenticated to the
ISIM via a PIN code. Commonly known initial PIN codes are typically ISIM via a PIN code. Commonly known initial PIN codes are typically
installed to the ISIM during manufacturing and if the end-users do 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 not change them, there is a danger that an unauthorized user may be
able to use the device. Naturally this requires that the able to use the device. Naturally this requires that the
unauthorized user has access to the physical device, and 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- end-user has not changed the initial PIN code. For this reason,
users are strongly encouraged to change their PIN codes when they end-users are strongly encouraged to change their PIN codes when they
receive an ISIM. receive an ISIM.
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.
skipping to change at page 15, line 21 skipping to change at page 15, line 31
The downside of sequence number tracking is that servers must hold The downside of sequence number tracking is that servers must hold
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 Digest AKA. protected along with other parts of the message by using 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
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).
The default aka-version defined in this document is "AKAv1". The default aka-version defined in this document is "AKAv1".
Following the policies outlined in [5], versions above 1 are Following the policies outlined in [5], versions above 1 are
allocated as Expert Review. allocated as Expert Review.
Registrations with the IANA MUST include the version number being Registrations with the IANA MUST include the version number being
registered, including the "AKAv" prefix. For example, a registration registered, including the "AKAv" prefix. For example, a registration
skipping to change at page 16, line 29 skipping to change at page 16, line 33
Normative References 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] Rosenberg, J. and H. Schulzrinne, "SIP: Session Initiation [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Protocol", draft-ietf-sip-rfc2543bis-09 (work in progress), Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
February 2002. Session Initiation Protocol", RFC 3261, June 2002.
[4] 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 Informative References
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 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".
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 Authors' Addresses
Aki Niemi Aki Niemi
Nokia Nokia
P.O. Box 301 P.O. Box 301
NOKIA GROUP, FIN 00045 NOKIA GROUP, FIN 00045
Finland Finland
Phone: +358 50 389 1644 Phone: +358 50 389 1644
skipping to change at page 17, line 34 skipping to change at page 18, line 5
Vesa Torvinen Vesa Torvinen
Ericsson Ericsson
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
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.
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
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
 End of changes. 

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