Internet Engineering Task Force J. Undery Internet Draft Ubiquity Document: draft-undery-sip-auth-00.txt Category: Standards Track Sanjoy Sen Nortel Networks Vesa Torvinen Ericsson January 2002 SIP Digest Authentication: Extensions to HTTP Digest Authentication Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. 1. Abstract The Session Initiation Protocol [2] currently uses the HTTP digest authentication algorithm [3] for simple authentication of SIP requests. This scheme does not allow for the inclusion of headers important to the integrity of a SIP request including To, From, Call-ID, CSeq, Contact and Expires headers. This document attempts to address this issue. Examples of possible attacks involve capturing authenticated messages on the wire, modifying headers and resending the message. This makes it possible to modify registration details and initiate sessions with entities requiring authentication. HTTP Digest [3] has also other shortcomings if applied for SIP. Firstly, SIP UA has serious difficulties to distinguish the source of Authentication-Info headers in SIP forking situations. Secondly, Undery, et al. Standards Track - Expires July 2002 1 draft-undery-sip-auth-00.txt January 2002 HTTP Digest [3] cannot be utilized for proxy to UAS authentication because the existing headers do not provide the target of the challange. This document introduces extensions to HTTP Digest to solve these problems. 2. Introduction RFC 2617 [3] defines two methods for a HTTP client to authenticate itself to a server, Basic and Digest. Digest authentication as used by SIP uses a cryptographic hash of a number of elements including the request method, URI and optionally the body of the message. Unfortunately Digest authentication fails to provide authentication of a number of headers critical to the integrity of a SIP request. This enables a number of attacks against servers, by attackers pretending to be the client and modifying authenticated messages. There are also other known problems related to the use of HTTP authentication headers in SIP environment. These problems are related to the lack of source and target parameters in different authentication headers. To fix these problems it is necessary to extend the digest authentication scheme. This document attempts to 'patch' digest authentication in RFC 2617 to provide a better solution for SIP. Existing headers are supplemented with new parameters and parameter values. Defining new authentication headers will enable proxy-to-UAS authentication and enable the UAS to target specific proxies. Existing headers could not be re-used because of backward compatibility and efficiency reasons. 3. Perceived Threats In this section we will describe the threats to security that we attempt to address and those that will be ignored. This section will not discuss the complexity of exploiting these threats because according to [4], "A threat is, by definition, a vulnerability available to a motivated and capable adversary". The fact it exists is enough. 3.1. Addressed Threats Replay attacks: this is really an issue of how the server creates and expires its nonces, section 4.2.1 describes a mechanism that can be used to help by including a timestamp in the nonces, that combined with the protecting headers can prevent replay attacks. Man in the Middle: attacks, this is where messages are altered by the attacker. One of the objectives of this draft is to allow a server to decide which headers it requires to be included in the credentials. Any header not chosen by the server will be vulnerable, Undery, et al. Standards Track - Expires July 2002 2 draft-undery-sip-auth-00.txt January 2002 and known to a potential attacker. It should be impossible for an attacker to alter any of the headers the server deems relevant to protect. The weakness here is that a server may decide the Subject header is irrelevant, yet the recipient of the message might not appreciate an INVITE with an offensive subject injected by an intermediate proxy. One important type of man in the middle attack is a bidding down attack. This is where the attacker removes stronger schemes, algorithms or quality of protection from a challenge. This attack then allows the attacker an increased ability to interfere with the session. Masquerade attacks: this is where an attacker inserts itself into the signaling path and attempts to fool the client into providing credentials the attacker can use to create a false message. The last two issues are addressed by both the client and server using the same set of headers for inclusion in the credentials and checking them. Any change to these headers will result in the credentials being invalid for the request. Reliability of results is covered by the inclusion of the Authentication-Info header, which can provide authentication in the response to any authenticated request. 3.2. Unaddressed Threats Privacy will be totally out of scope; both data and system usage are unprotected by RFC 2617 and will be ignored by this draft too. In order to protect privacy, encryption is required. Denial of service this is also out of scope. Authentication inherently requires some level of additional work on behalf of the server and client. This additional load makes it easier to overwhelm the resources of the victim. That said stateless rejection of unauthenticated messages help prevent state loading denial of service attacks. 4. Syntax RFC 2617 describes the Digest authentication scheme. This scheme is subject to the operation and limitations as described in RFC 2617. Namely, it relies on a shared secret between the client and server and provides no mechanism for distributing those secrets; it provides no 'hiding' of the payload or headers. The change is purely to provide the same semantic integrity to SIP, as provided to HTTP by including the Method and URI in the credentials. 4.1. Specification of Generic Authentication Headers Undery, et al. Standards Track - Expires July 2002 3 draft-undery-sip-auth-00.txt January 2002 4.1.1. WWW-Authenticate and Proxy-Authenticate Response Headers These headers are defined in [3]. 4.1.2. Authorization and Proxy-Authorization Request Headers These headers are defined in [3]. 4.1.3. Authentication-Info Response Header UAS insert this header in responses to successfully authenticated requests in order to provide mutual authentication and the nonce to use in future requests in this dialog. AuthenticationInfo = "Authentication-Info" HCOLON auth-info auth-info = scheme info-credentials 4.1.4. Proxy-Authentication-Info Response Header Proxies place this header in the response in order to authenticate themselves with the UAC and the nonce to use in future requests in this dialogs. ProxyAuthenticationInfo = "Proxy-Authentication-Info" HCOLON proxy-auth-info proxy-auth-info = scheme info-credentials 4.1.5. UAS-Authenticate Header The use of this header is described in Section 7. UAS-Authenticate = "UAS-Authenticate" HCOLON 1#uas-challenge uas-challenge = scheme target-param challenge target-param = target-realm-param | target-route-param target-realm-param = "target" EQUAL target target = host target-route-param = "route" EQUAL target-route target-route = Request-URI target The target is a hostname or IP address indicating the domain or machine the authentication is targeted for. target-route The target-route is uri indicating that any entity sending a request with this uri as the Request-URI is targeted for authentication. Undery, et al. Standards Track - Expires July 2002 4 draft-undery-sip-auth-00.txt January 2002 4.1.6. UAS-Authorization Request Header UAS-Authorization = "UAS-Authorization" HCOLON 1#uas-credentials uas-credentials = scheme target-ids credentials target-ids = target-param responder-param responder-param = "responder" EQUAL responder responder = sent-by responder The responder is hostname or network address optionally the port that matches the value which the proxy inserted in the Via. 4.1.7. UAS-Authentication-Info This header is used by the UAS to authenticate itself to the proxy in the response. A response can contain multiple UAS-Authentication- Info headers targeted towards multiple proxies that have successfully authenticated themselves with the UAS. UASAuthenticationInfo = "UAS-Authentication-Info" HCOLON 1#uas-reverse-credentials uas-reverse-credentials = scheme target-param info-credentials 4.2. New Response Codes 4.2.1. 492 Proxies Unauthorized The request requires proxies to authenticate with the user agent server. This response is issued by user agent servers and registrars. 4.3. Specification of SIP Digest Headers 4.3.1. Challenge Construction The following BNF is used in the same context as RFC 2617 challenge = "Digest" digest-challenge digest-challenge = 1#(realm | domain | nonce | opaque | stale | algorithm | qop-options | auth-params | header-options | generic-param) realm = "realm" EQUAL realm-value realm-value = quoted-string ; See Appendix C of [2] domain = "domain" EQUAL domain-value domain-value = LDQUOT SIP-URL RDQUOT nonce = "nonce" EQUAL nonce-value Undery, et al. Standards Track - Expires July 2002 5 draft-undery-sip-auth-00.txt January 2002 nonce-value = quoted-string opaque = "opaque" EQUAL quoted-string stale = "stale" EQUAL ("true" | "false") algorithm = "algorithm" EQUAL ("MD5" | token ) qop-options = "qop" EQUAL LDQUOT 1#qop-value RDQUOT qop-value = "auth" | "auth-int" | "auth-extd-int" | "auth-hdr-int" | token auth-params = token EQUAL quoted-string header-options = "header" EQUAL LDQUOT 1#header-value RDQUOT header-value = "To" | "From" | "Contact" | "Expires" | "CSeq" | "CallID" | extension-header extension-header = token generic-param = token EQUAL (token | quoted-string) realm A string that can be rendered for the end user to provide the context with which to authenticate itself. domain A quoted SIP URL that corresponds to the request uri of the request as it arrives at the server. For registration in the domain example.com this would be sip:example.com. nonce A server-specified data string ideally uniquely generated for each 401/407/492 response. Care should be taken generating this value to ensure it is unique and other parties should not be able to predict its value. (See Section 6.) opaque A string of data specified by the server, which should be returned by the client unchanged in any credentials generated in response to this challenge. stale A flag indicating if the previous request from the client was rejected because the nonce was stale and the client should retry with the new nonce. If this value is anything other than "true", or is not present, the username and/or password are invalid. algorithm A string containing the hashing algorithm used for the authentication. Currently this is only MD5 and should be assumed to be so by default. [5] qop-options A quoted string containing the "quality of protection" options supported by the server. The value "auth" indicates authentication; the value "auth-int" indicates authentication with message body integrity protection; the value "auth-extd-int" indicates authentication with complete message integrity protection; the value "auth-hdr-int" indicates authentication and integrity protection of the message body and various headers. Undery, et al. Standards Track - Expires July 2002 6 draft-undery-sip-auth-00.txt January 2002 auth-params This is included for future extensions unknown values should be ignored. header-options This directive specifies which header the server requires the client to include in its credentials. It is a quoted comma separated list of headers. Unknown values mentioned should be assumed to be the names of headers in a SIP request that will be included in the credentials the same way as known values, using the capitalisation in the header-value. This directive MUST be present if qop-options contains the value "auth-hdr-int". generic-param This is included to specifically allow extensibility, unknown parameters SHOULD be ignored. 4.3.2. Credentials Construction credentials = "Digest" digest-response digest-response = 1# ( username | realm | nonce | digest-uri | response | algorithm | cnonce | opaque | message-qop | nonce-count | auth-param | header-options | generic-param) username = "username" EQUAL username-value username-value = quoted-string digest-uri = "uri" EQUAL DQUOT SIP-URL DQUOT response = "response" EQUAL request-digest request-digest = LDQUOT 32LHEX RDQUOT cnonce = "cnonce" EQUAL cnonce-value cnonce-value = quoted-string message-qop = "qop" EQUAL qop-value nonce-count = "nc" EQUAL nc-value nc-value = 8LHEX username The user's name in the realm in which it is trying to authenticate itself. digest-uri This is the Request-URI the client is using to send the request. This may have changed in transit so is included here. sip-response This is a string of 32 hex digits computed as defined below, which proves the user knows a password and the headers covered in header-options have not been altered. cnonce This is a compulsory value returned by the client to the server for prevention of chosen plaintext attacks. Undery, et al. Standards Track - Expires July 2002 7 draft-undery-sip-auth-00.txt January 2002 message-qop This value contains the qop value chosen from the list in the challenge that was used to create the credentials. nonce-count The nc-value is a hexadecimal count of the number of requests that the client has sent using this nonce. header-options This is a quoted comma separated list of the headers that the client encoded into the header-list used to calculate S2. Its value MUST be a superset of the values in the WWW-Authenticate header. i.e. The client can add but not remove headers from the list, this can be used by the client to negotiate up the protection it provides to the integrity of messages. 4.3.3. Info Credentials construction The implications of changing the nonce do not generally apply to SIP and one-time nonces are useful, without hindering performance. However, there are some environments in which more static security contexts are needed, and consequently the implications of changing the nonce should be considered. info-credentials = 1#(nextnonce | message-qop | response-auth | cnonce | nonce-count | realm | [opaque] | [generic-param]) nextnonce = "nextnonce" EQUAL nonce-value response-auth = "rspauth" EQUAL response-digest response-digest = LDQUOT *LHEX RDQUOT nextnonce This is the nonce that should be used to generate the next credentials corresponding to this info-credentials. message-qop Indicates the "quality of protection" options applied to the response by the server. The values here correspond directly to their equivalents in credentials. The server SHOULD use the same value for the message-qop directive in the response as was sent in the credentials of the corresponding request. response-auth This value computed as defined below and provides authentication in the responses. cnonce This value is copied from the credentials into the corresponding info-credentials. Undery, et al. Standards Track - Expires July 2002 8 draft-undery-sip-auth-00.txt January 2002 opaque This value if present MUST be copied into any credentials using the nextnonce value specified in these info-credentials. 5. Digest Calculation The method of calculating the request-digest and response-digest are as follows, if the qop-value is present request-digest = LDQUOT < KD( H(A1), unq(nonce-value) ":" nc-value ":" unq(cnonce-value) ":" unq(qop-value) ":" H(A2) ) RDQUOT is used, otherwise, request-digest = LDQUOT < KD( H(A1), unq(nonce-value) ":" H(A2)) > RDQUOT response-digest = request-digest is used where KD, H, A1 and unq are as defined in [3]. 5.1. Computing A2 If the qop-value is unspecified, "auth" or "auth-int" the value from [3] is used. If the qop-value is "auth-extd-int", then A2 is: A2 = H(<entire message excluding the credential>) If the qop-value is "auth-hdr-int", then A2 is: A2 = (Method | Status-Code)":" digest-uri-value ":" entity-body ":" header-list header-list = *headers headers = (to-addr | from-addr | contact-value | cseq-value | callid-value |expires-value | other-value) to-addr = To eol-marker from-addr = From eol-marker contact-value = Contact eol-marker cseq-value = CSeq eol-marker callid-value = Call-ID eol-marker expires-value = Expires eol-marker other-value = field-name ":" [field-value] eol-marker eol-marker = <CR> <LF> headers These are the relevant headers converted to canonical form [2] Undery, et al. Standards Track - Expires July 2002 9 draft-undery-sip-auth-00.txt January 2002 with the addition that Contact headers always include the < and > delimiters even if the display name is empty. i.e. 1 No short form header fields. 2 Header field names are capitalised as shown in [2]. 3 No white space between the header name and the colon. 4 A single white space after the colon. 5 Line termination with a CRLF. 6 No line folding. 7 No comma separated lists of header values, each must appear as a separate header. 8 Only a single white space between tokens, between tokens and quoted strings, and between quoted strings. No space after the last token. 9 No LWS between tokens and separators, except as described above. 10 The To, From and Contact header fields always include < and > delimiters even if the display-name is empty. The other-value is left in for the inclusion of headers the author omitted (only long form headers should be used). It should also be noted Authentication-Info, Authorization, Max-Forwards, Proxy- Authorization, Proxy-Authentication-Info, Record-Route, Route, UAS-Authorization and Via headers MUST NOT appear in this list, as they are altered or added/removed in the course of normal signaling. 6. Nonce Generation Traditionally nonces have contained no meaning for the client, however, in order to prevent bid-down attacks this draft will recommend a format. This format is designed to allow a server to encode the type of protection required. This means 6.1. Syntax The following definition will replace nonce-value nonce-value = LDQUOT "(" 1#auth-type ")" trad-nonce-value RDQUOT auth-type = auth-algorithms | digest-auth-type | token auth-algorithms = "MD5" | "AKA" "SHA1" digest-auth-type = "dauth" | "dauth-int" | "dauth-extd-int" | "dauth-hdr-int" trad-nonce-value = *(qdtext |quoted-pair) auth-algorithm These are the algorithms used by the Digest scheme to produce the digest. Undery, et al. Standards Track - Expires July 2002 10 draft-undery-sip-auth-00.txt January 2002 digest-auth-type These are the protection encodings for Digest authentication. Each value corresponds to a qop-value prefixed with the letter d. A possible implementation of trad-nonce-value is; trad-nonce-value = time-stamp "-" H(time-stamp ":" request-uri ":" private-key) where, the time-stamp is a non repeating value or time stamp, the request-uri is the Request URI from the request and the private-key is to ensure the nonce was generated by an entity that knows the private-key. 7. Authenticating Proxies with the UAS 7.1. User Agent Server Behaviour When a UAS receives a request via a number of proxies, the UAS MAY authenticate some of the proxies before the request is processed. If no matching credentials (in the UAS-Authorization header field) are provided in the request, the UAS can challenge the proxies to provide credentials by rejecting the request with a 492 (Proxies Unauthorized) status code containing one or more UAS-Authenticate headers. The UAS-Authenticate response-header field MUST be included in 492 (Proxies Unauthorized) response messages. If one or more proxies fail to authenticate themselves in a request containing relevant UAS-Authenticate headers the UAS MUST respond with 403 Forbidden. Once the UAC is successfully authenticated, the UAS can do mutual authentication using the Authentication-Info header in the response. Similarly, once the proxies are successfully authenticated, the UAS can do mutual authentication using UAS-Authentication-Info header in the response. 7.2. User Agent Client Behaviour When a UAC receives an unauthorised response (i.e. 401, 407 or 492) containing UAS-Authenticate headers it MUST, if it is able, re- originate the request with copies of the UAS-Authenticate headers. If a UAC receives a response containing UAS-Authenticate headers within a dialog it MUST, if it is able, include a copy of the UAS- Authenticate headers within the next request it sends within that dialog. 7.3 Proxy Behaviour Undery, et al. Standards Track - Expires July 2002 11 draft-undery-sip-auth-00.txt January 2002 When a proxy receives a request containing a UAS-Authenticate header it SHOULD check the headers to see if it matches. Matches are possible in two ways; firstly the proxy may be responsible for a domain mentioned within a "target" parameter; secondly it may be proxying the request with a Request-URI that matches a "route" parameter. Proxies MUST, if able to do so, include a UAS- Authorization header with credentials for all matching UAS- Authenticate headers. If a stateful proxy receives a 492 and determines that it contains a single UAS-Authenticate header targeted solely at itself, it MAY resubmit the request to the UAS with a UAS-Authorization header containing the credential as a separate branch. After the UAC is authenticated by the proxy, the proxy may use the Proxy-Authentication-Info header in the response to perform mutual authentication with the UAC. 8. Examples 8.1. UAC to UAS mutual authentication User Registrar | | | REGISTER | |------------------------------------------------------------->| | | | 401 + WWW-Authenticate | |<-------------------------------------------------------------| | | | REGISTER + Authorization | |------------------------------------------------------------->| | | | 200 + Authentication-Info | |<-------------------------------------------------------------| | | The following example shows the how a client should respond to a request to authenticate its REGISTER request. SIP/2.0 401 Unauthorised WWW-Authenticate: Digest realm="Vacuity Proxy", nonce="(dauth-hdr-int)9912345-0123456789abcdef0123456789abcdef", algorithm=MD5, qop="auth-hdr-int" header="To, From, Expires, Made-Up-Header" ... The UA then decides that for REGISTER requests it should protect the Contact header so adds it to the list of header-options. It is Undery, et al. Standards Track - Expires July 2002 12 draft-undery-sip-auth-00.txt January 2002 assumed the UA will prompt the client for the username and password for the realm "Vacuity Proxy" before responding with, REGISTER sip:example.com SIP/2.0 Via: SIP/2.0/UDP 10.0.0.10 Authorization: Digest username="auser", realm="Vacuity Proxy", nonce="(dauth-hdr-int)9912345-0123456789abcdef0123456789abcdef", uri="sip:example.com", response=fedcba9876543210fedcba9876543210, algorithm=MD5, cnonce="9912390-12345678123456781234567812345678", qop=auth-hdr-int, nc=00000001, header="To, From, Expires, Contact, Made-Up-Header" To: A User <sip:auser@example.com> From: A User <sip:auser@example.com;user=ip>;tag=1234 Call-ID: 12321@a.example.com CSeq: 2 REGISTER Contact: sip:10.0.0.10:5061, sip:10.0.0.37 m: sip:auser@home.example.com;example=madeup In the above example the header-list used will be "To: A User <sip:auser@example.com> From: A User <sip:auser@example.com;user=ip>;tag=1234 Expires: Contact: <sip:10.0.0.10:5061> Contact: <sip:10.0.0.37> Contact: <sip:auser@home.example.com>;example=madeup Made-Up-Header: " The headers inserted in the same order as the appear in the header- option, empty or missing headers are represented as empty headers, as shown by Expires in this example all lines are terminated with a carriage return line feed. An empty header consists of the long header name followed by a colon and a CRLF pair, without any space. Note that the Contact values appear in the list in the same order as they appear in the message, and that the client added them to the list of headers to protect. Also noteworthy is the positioning of the Authorization header before all the headers we are encoding. In the 200 response to the REGISTER the registrar includes. Authentication-Info: nextnonce="(dauth-int-hdr)12345-q1w2e3r4", qop=auth-hdr-int, rspauth="deadbeefdeadbeefdeadbeefdeadbeef", nc=00000001 This header provides the next nonce for the UAC to use and authenticates the response. It may be worth noting that once a user has been authenticated it is possible to provide nonces statefully although the nonce best practice rules should still be applied. Undery, et al. Standards Track - Expires July 2002 13 draft-undery-sip-auth-00.txt January 2002 8.2. Proxy to UAC mutual authentication UAC Proxy UAS | | | | INVITE | | |----------------------------->| | | | | | 407 + Proxy-Authenticate | | |<-----------------------------| | | | | | INVITE + Proxy-Authorization | | |----------------------------->| | | | | | | INVITE | | |----------------------------->| | | | | | 200 | | |<-----------------------------| | | | | 200 + | | | Proxy-Authentication-Info | | |<-----------------------------| | | | | The above diagram shows shows a call flow where the proxy challenges a caller and then authenticates itself in the response to the authenticated request. In this instance as a single hop is involved the qop value of auth-extd-int used so the entire message was integrity protected. 8.3. Proxy to UAS mutual authentication The following diagram shows how the UAS-Authenticate header is used to provide proxy to UAS authentication. When the UAS receives the request it returns a 492 which is propagated back to the UAC. If the UAC is aware of the 492 response it then copies the UAC-Authenticate headers into the resubmitted request. When the request with the UAS- Authenticate headers arrive at the proxy it adds UAS-Authorization headers for all the challenges targeted at it. When the UAS receives request it ensures it has received all the UAS-Authorization headers it was expecting. (Note a UAS-Authenticate header may produce more than one UAS-Authorization header if more than one proxy match.) The UAS then populates UAS-Authentication-Info headers for all the proxies it wishes to mutually authenticate with. Proxies can the check for UAS-Authentication-Info headers in the response. Undery, et al. Standards Track - Expires July 2002 14 draft-undery-sip-auth-00.txt January 2002 UAC Proxy UAS | | | | INVITE | | |----------------------------->| | | | | | | INVITE | | |----------------------------->| | | | | | 492 + UAS-Authenticate | | |<-----------------------------| | | | | 492 + UAS-Authenticate | | |<-----------------------------| | | | | | INVITE + UAS-Authenticate | | |----------------------------->| | | | | | | INVITE + UAS-Authenticate + | | | UAS-Authorization | | |----------------------------->| | | | | | 200 + UAS-Authentication-Info| | | + UAS-Authenticate | | |<-----------------------------| | | | | 200 + UAS-Authentication-Info| | | + UAS-Authenticate | | |<-----------------------------| | | | | 9. Security Considerations The purpose of this draft is security. Items ruled out side of the scope of this document are privacy, resistance to denial of service, trustworthiness of results. The rationale for these is included in section 4 The security of this draft relies mainly on the headers chosen by the server for inclusion in the digest. If this selection is poor a false sense of security obtained; although if a client wishes the set can be increased to cover all the relevant headers. 9.1. Security Considerations Missing From RFC 2617 RFC 2617 [3] has a remarkably thorough security considerations section, however, in the author's opinion an important consideration is missed. In the WWW-Authenticate header the qop directive can contain a list of schemes supported. It is possible for an attacker to downgrade the security on offer by removing auth-int if present so the body of the message isn't included in the protection, or simply remove the qop parameter entirely. Undery, et al. Standards Track - Expires July 2002 15 draft-undery-sip-auth-00.txt January 2002 10. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Handley, M., Schulzrinne, H, Schooler, E. and Rosenberg, J., "SIP: Session Initiation Protocol", work in progress, currently, draft-ietf-sip-rfc2543bis-03.txt, May 2001. 3 Franks, J. et al, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. 4 Bellovin, S., "Report of the IAB Security Architecture Workshop", RFC 2316, April 1998. 5 Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. 11. Acknowledgments **** TODO **** 12. Author's Addresses James Undery Ubiquity Software Corporation Ltd. Ubiquity House Langstone Park Newport, UK Email: jundery@ubiquity.net Sanjoy Sen Nortel Networks Email: sanjoy@nortelnetworks.com Vesa Torvinen Oy LM Ericsson Ab Email: vesa.torvinen@ericsson.fi Undery, et al. Standards Track - Expires July 2002 16 draft-undery-sip-auth-00.txt January 2002 Full Copyright Statement "Copyright (C) The Internet Society (2001). 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 ENINEERING TASK FORCE DICLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRENTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRENTIES OF MERCAHNTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Undery, et al. Standards Track - Expires July 2002 17