One document matched: draft-khartabil-sip-auth-analysis-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 09:26:53 |