|
Page 1 of 4 Usage of HTTP Authentication in SIP SIP provides a stateless, challenge-based mechanism for
authentication that is based on authentication in HTTP. Any time
that a proxy server or UA receives a request (with the exceptions
given in Section 22.1), it MAY challenge the initiator of the request
to provide assurance of its identity. Once the originator has been
identified, the recipient of the request SHOULD ascertain whether or
not this user is authorized to make the request in question. No
authorization systems are recommended or discussed in this document.
The "Digest" authentication mechanism described in this section
provides message authentication and replay protection only, without
message integrity or confidentiality. Protective measures above and
beyond those provided by Digest need to be taken to prevent active
attackers from modifying SIP requests and responses.
Note that due to its weak security, the usage of "Basic"
authentication has been deprecated. Servers MUST NOT accept
credentials using the "Basic" authorization scheme, and servers also
MUST NOT challenge with "Basic". This is a change from RFC 2543.
22.1 Framework
The framework for SIP authentication closely parallels that of HTTP
(RFC 2617 [17]). In particular, the BNF for auth-scheme, auth-param,
challenge, realm, realm-value, and credentials is identical (although
the usage of "Basic" as a scheme is not permitted). 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 requirements for inclusion of the Proxy-Authenticate,
Proxy-Authorization, WWW-Authenticate, and Authorization in the
various messages are identical to those described in RFC 2617 [17].
Since SIP does not have the concept of a canonical root URL, the
notion of protection spaces is interpreted differently in SIP. The
realm string alone defines the protection domain. This is a change
from RFC 2543, in which the Request-URI and the realm together
defined the protection domain.
This previous definition of protection domain caused some amount
of confusion since the Request-URI sent by the UAC and the
Request-URI received by the challenging server might be different,
and indeed the final form of the Request-URI might not be known to
the UAC. Also, the previous definition depended on the presence
of a SIP URI in the Request-URI and seemed to rule out alternative
URI schemes (for example, the tel URL).
Operators of user agents or proxy servers that will authenticate
received requests MUST adhere to the following guidelines for
creation of a realm string for their server:
o Realm strings MUST be globally unique. It is RECOMMENDED that
a realm string contain a hostname or domain name, following the
recommendation in Section 3.2.1 of RFC 2617 [17].
o Realm strings SHOULD present a human-readable identifier that
can be rendered to a user.
For example:
INVITE sip:
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
SIP/2.0
Authorization: Digest realm="biloxi.com", <...>
Generally, SIP authentication is meaningful for a specific realm, a
protection domain. Thus, for Digest authentication, each such
protection domain has its own set of usernames and passwords. If a
server does not require authentication for a particular request, it
MAY accept a default username, "anonymous", which has no password
(password of ""). Similarly, UACs representing many users, such as
PSTN gateways, MAY have their own device-specific username and
password, rather than accounts for particular users, for their realm.
While a server can legitimately challenge most SIP requests, there
are two requests defined by this document that require special
handling for authentication: ACK and CANCEL.
Under an authentication scheme that uses responses to carry values
used to compute nonces (such as Digest), some problems come up for
any requests that take no response, including ACK. For this reason,
any credentials in the INVITE that were accepted by a server MUST be
accepted by that server for the ACK. UACs creating an ACK message
will duplicate all of the Authorization and Proxy-Authorization
header field values that appeared in the INVITE to which the ACK
corresponds. Servers MUST NOT attempt to challenge an ACK.
Although the CANCEL method does take a response (a 2xx), servers MUST
NOT attempt to challenge CANCEL requests since these requests cannot
be resubmitted. Generally, a CANCEL request SHOULD be accepted by a
server if it comes from the same hop that sent the request being
canceled (provided that some sort of transport or network layer
security association, as described in Section 26.2.1, is in place).
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. 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.
Finally, note that even if a UAC can locate credentials that are
associated with the proper realm, the potential exists that these
credentials may no longer be valid or that the challenging server
will not accept these credentials for whatever reason (especially
when "anonymous" with no password is submitted). In this instance a
server may repeat its challenge, or it may respond with a 403
Forbidden. 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).
|
