SIP WG H. Khartabil Internet-Draft Nokia Expires: August 4, 2004 February 4, 2004 Analysis: HTTP Authentication for SIP draft-khartabil-sip-auth-analysis-00 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. 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 August 4, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract The Session Initiation Protocol (SIP) provides a stateless, challenge-based mechanism for authentication that is based on authentication in HTTP. RFC 3261 fails to indicate the behaviour of SIP intermediaries and User Agents in certain scenarios. This documents presents such scenarios, analysis the currently available text, and where possible, offers a solution. Khartabil Expires August 4, 2004 [Page 1] Internet-Draft sip-auth Analysis February 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Use of 401 and 407 Responses, www-authenticate and proxy-authenticate headers . . . . . . . . . . . . . . . . . . 3 3. Rendering to user . . . . . . . . . . . . . . . . . . . . . . 3 4. Rejected or not . . . . . . . . . . . . . . . . . . . . . . . 4 5. Use of To-header vs. Remote URI (Request-URI) . . . . . . . . 4 6. Caching of User-to-User Authentication Credentials . . . . . . 4 7. Caching outbound proxy credentials . . . . . . . . . . . . . . 4 8. User Cancelling when challenged . . . . . . . . . . . . . . . 5 9. The realm Issue . . . . . . . . . . . . . . . . . . . . . . . 5 10. Authentication-Info . . . . . . . . . . . . . . . . . . . . . 6 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . 8 Khartabil Expires August 4, 2004 [Page 2] Internet-Draft sip-auth Analysis February 2004 1. Introduction The Session Initiation Protocol (SIP) [1] provides a stateless, challenge-based mechanism for authentication that is based on authentication in HTTP. RFC 3261 fails to indicate the behaviour of SIP intermediaries and User Agents in certain scenarios. This documents presents such scenarios, analysis the currently available text, and where possible, offers a solution. One of the main issues presented is proxies with the same realm appearing in a chain. 2. Use of 401 and 407 Responses, www-authenticate and proxy-authenticate headers Section 22.1 of RFC 3261 says "In SIP, a UAS uses the 401 (Unauthorized) response to challenge the identity of a UAC. Additionally, registrars and redirect servers MAY make use of 401 (Unauthorized) responses for authentication, but proxies MUST NOT, and instead MAY use the 407 (Proxy Authentication Required) response". The use of 401 and 407 must be more normative. Text should read: A UAS that require authentication MUST use 401 in a response and MUST challenge with a www-authenticate header. Registrars and redirect servers MUST use 401 and www-authenticate header. Proxies MUST use 407 and proxy-authenticate header. 3. Rendering to user Section 22.1 of RFC 3261 says: "When a UAC receives a challenge, it SHOULD render to the user the contents of the "realm" parameter in the challenge (which appears in either a WWW-Authenticate header field or Proxy-Authenticate header field) if the UAC device does not already know of a credential for the realm in question". This is talking about a terminal being pre-configured with credentials. Some implementation may choose to render to the user the challenge if a previously sent response to a challenge failed due to incorrect credentials, regardless if the credentials were pre configured or not. The text following the quote above gives the impression that this is not possible. "A service provider that pre-configures UAs with credentials for its realm should be aware that users will not have the opportunity to present their own credentials for this realm when challenged at a pre-configured device". Khartabil Expires August 4, 2004 [Page 3] Internet-Draft sip-auth Analysis February 2004 4. Rejected or not Section 22.1 of RFC 3261 says: "A UAC MUST NOT re-attempt requests with the credentials that have just been rejected (though the request may be retried if the nonce was stale)". The problem with this is that how do you know if the request has been rejected or it is just the next hop proxy challenging with the same realm? 5. Use of To-header vs. Remote URI (Request-URI) Section 22.2 of RFC 3261 says: "The UAC may require input from the originating user before proceeding. Once authentication credentials have been supplied (either directly by the user, or discovered in an internal key-ring), UAs SHOULD cache the credentials for a given value of the To header field and "realm" and attempt to re-use these values on the next request for that destination". It is more appropriate to cache request-URI, and not rely on what is in the To-header. 6. Caching of User-to-User Authentication Credentials Section 22.2 of RFC 3261 says: "UAs MAY cache credentials in any way they would like". This means within dialogs as well as across dialogs. This is talking about www-authenticate challenges. 7. Caching outbound proxy credentials Section 22.3 of RFC 3261 says: "if a UA is configured with the realm of its local outbound proxy, when one exists, then the UA MAY cache credentials for that realm across dialogs". It cannot be assumed that the domain name of a configured outbound proxy is its realm. Therefore a terminal configured with only the outbound proxy URI cannot and MUST NOT cache credentials or any proxy challenge across dialogs. This introduces the problem of multiple proxies in a chain challenging with the same realm. How does a UAC know that the challenge was from the outbound proxy and not from a downstream proxy with the same realm as the outbound proxy? Can we mandate that the outbound proxy must have a unique realm? Khartabil Expires August 4, 2004 [Page 4] Internet-Draft sip-auth Analysis February 2004 8. User Cancelling when challenged Section 22.3 of RFC 3261 says: "If a request is forked (as described in Section 16.7), various proxy servers and/or UAs may wish to challenge the UAC ... .If the UAC does not provide credentials for each challenge, the proxy servers that issued the challenges will not forward requests to the UA". It is probably worth noting here that if the user enters his credentials for at least one of the challenges and not the rest (cancels the rest), the UAC must re-issue a new SIP request with a response to the challenges that have not been cancelled. If all challenges have not been responded to by the user or terminal, then the UAC does not re-issue the SIP request and simply return a 403 to the user. 9. The realm Issue Section 22.3 of RFC 3261 says: "When multiple proxies are used in a chain, a Proxy-Authorization header field value MUST NOT be consumed by any proxy whose realm does not match the "realm" parameter specified in that value". Section 22.3 of RFC 3261 also says: "It is possible for multiple challenges associated with the same realm to appear in the same 401 (Unauthorized) or 407 (Proxy Authentication Required). This can occur, for example, when multiple proxies within the same administrative domain, which use a common realm, are reached by a forking request." The problem here is with forking: A proxy will fork the second request with the credentials. How does a proxy that the request has been forked to (or a UAS) know, by just examining the realm, that this is a digest response to a challenge it issued? The solution here needs to specify that a proxy examines all digest response matching the realm as well as the nonce. Another question: Is it possible that multiple proxies with the same realm are placed in a chain? I.e. the first proxy challenges, user provide correct authentication. That proxy authenticates and forwards the request to a down stream proxy. That down stream proxy has the same realm as first proxy. There are a few issues here: o A proxy MUST consume a proxy-authorization header intended for it. A proxy knows that by examining the realm, as quoted above. But, if proxies with the same realm are placed in a chain, a Proxy needs to examine the nonce and make sure it created it before it consumes the header. Khartabil Expires August 4, 2004 [Page 5] Internet-Draft sip-auth Analysis February 2004 o If a proxy MAY (in comparison to MUST) consume the header, how does the second proxy know that the credentials in the request are not for it? It needs to examine the nonce and find out it is not from it. Is that ok? Consuming the header does not solve the forking problem. Therefore examining the nonce is the only solution. Another issue is at the UAC side. If 2 proxies are in a chain and share a realm, how does the UAC know, when the second proxy challenges, that it is not the first proxy re-challenging because the credentials provided to it were wrong? There are a couple of things that can be done here: o mandate that the proxy places stale=false when it is re-challenging due to wrong credentials. This means stale=false is different that stale not present at all. The UAC replaces the provided proxy-authorization header with a new one. o mandate that the proxy does not change the nonce when it is re-challenging due to wrong credentials. The UAC replaces the provided proxy-authorization header with a new one. o Note: a UAS does not need to do the above since the UAC knows that if a re-challenge occurs and stale is not true, then new credentials need to be provided. This works also for a proxy forking to multiple UASs with the same realm. 10. Authentication-Info RFC 3261 allows the usage of Authentication-Info header. The BNF in RFC 3261 allows multiple authentication-info headers where RFC 2617 allows only one. Is it only the terminating UAS that is allowed to insert this header. If so, why allow multiples to be present. If not, how does the UAC know which proxy added this header? It cannot know since there is no parameter indicating so, not even nonce. 11. Acknowledgements The author would like to thank Pekka Pessi for his feedback. References [1] Rosenberg, J., Shulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "The Session Initiation Protocol (SIP)", RFC 3261, June 2002. Khartabil Expires August 4, 2004 [Page 6] Internet-Draft sip-auth Analysis February 2004 Author's Address Hisham Khartabil Nokia P.O. Box 321 Helsinki Finland Phone: +358 7180 76161 EMail: hisham.khartabil@nokia.com Khartabil Expires August 4, 2004 [Page 7] Internet-Draft sip-auth Analysis February 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). 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 assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Khartabil Expires August 4, 2004 [Page 8] Internet-Draft sip-auth Analysis February 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Khartabil Expires August 4, 2004 [Page 9]