\section{SIP Authentication using HTTP Basic and Digest Schemes}
\label{sec:httpauth}

SIP implementations {\MAY} use HTTP's basic and digest authentication
mechanisms (RFC 2617 \cite{rfc2617}) to provide a rudimentary form of
security.  This section overviews usage of these mechanisms in SIP.  The
basic operation is almost completely identical to that for HTTP
\cite{rfc2617}.  This section outlines this operation, pointing to RFC
2617 \cite{rfc2617} for details, and noting the differences when used in
SIP. Since RFC 2543 is based on HTTP basic and digest as defined in
RFC 2069 \cite{rfc2069}, SIP servers supporting RFC 2617 {\MUST}
ensure they are backwards compatible with RFC 2069. Procedures for
this backwards compatibility are specified in RFC 2617.

\subsection{Framework}

The framework for SIP authentication parallels that for HTTP (RFC 2617
\cite{rfc2617}).  In particular, the BNF for \header{auth-scheme},
\header{auth-param}, \header{challenge}, \header{realm},
\header{realm-value}, and \header{credentials} is identical.  The 401
response is used by user agent servers in SIP to challenge the
authorization of a user agent client.  Additionally, registrars and
redirect servers {\MAY} make use of 401 responses for authorization, but
proxies {\MUSTNOT}, and instead {\MAY} use the 407 response.  The
requirements for inclusion of the \header{Proxy-Authenticate},
\header{Proxy-Authorization}, \header{WWW-Authenticate}, and
\header{Authorization} in the various messages is identical to
RFC 2617 \cite{rfc2617}.

Since SIP does not have the concept of a canonical root URL, the notion
of protections spaces are interpreted differently for SIP.  The realm is
a protection domain for all SIP URIs with the same value for the
\header{userinfo}, \header{host} and \header{port} part of the SIP
\header{Request-URI}.  For example:

\begin{verbatim}
   INVITE sip:alice.wonderland@example.com SIP/2.0
   WWW-Authenticate:  Basic realm="business"
\end{verbatim}

and

\begin{verbatim}
   INVITE sip:aw@example.com SIP/2.0
   WWW-Authenticate: Basic realm="business"
\end{verbatim}

define different protection realms according to this rule.

When a UAC resubmits a request with its credentials after receiving a
401 or 407 response, it {\MUST} increment the \header{CSeq} header field
as it would normally do when sending an updated request.

\subsection{Basic Authentication}

The rules for basic authentication follow those defined in
\cite[Section~2]{rfc2617} but with the words ``origin server'' replaced
with ``user agent server, redirect server , or registrar''. 

Since SIP URIs are not hierarchical, the paragraph in
\cite[Section~2]{rfc2617} that states that ``all paths at or deeper than
the depth of the last symbolic element in the path field of the
Request-URI also are within the protection space specified by the Basic
realm value of the current challenge'' does not apply for SIP.  SIP
clients {\MAY} preemptively send the corresponding
\header{Authorization} header with requests for SIP URIs within the same
protection realm (as defined above) without receipt of another challenge
from the server.

Due to its weak security, the usage of basic authentication is
{\NOTRECOMMENDED}. However, servers {\SHOULD} support it to handle
older RFC 2543 clients that might still use it.

\subsection{Digest Authentication}
\label{sec:digest}

The rules for digest authentication follow those defined in
\cite[Section~3]{rfc2617}, with ``HTTP 1.1'' replaced by ``SIP/2.0'' in
addition to the following differences:

\begin{enumerate}
\item The URI included in the challenge has the following BNF:
\begin{syntax}
URI & = & SIP-URL
\end{syntax}

\item The BNF in RFC 2617 has an error in that the URI is not enclosed
in quotation marks. (The example in Section 3.5 is correct.) For SIP,
the URI {\MUST} be enclosed in quotation marks.

\item The BNF for \header{digest-uri-value} is:
\begin{syntax}
digest-uri-value & = & Request-URI ; \textrm{as defined in Section
\ref{sec:requri}}
\end{syntax}

\item The example procedure for choosing a nonce based on \header{Etag}
does not work for SIP. 

\item The text in RFC 2617 \cite{rfc2617} regarding cache operation does
not apply to SIP.

\item RFC 2617 \cite{rfc2617} requires that a server check that the URI
in the request line, and the URI included in the \header{Authorization}
header, point to the same resource.  In a SIP context, these two URI's
may actually refer to different users, due to forwarding at some proxy. 
Therefore, in SIP, a server {\MAY} check that the request-uri in the
\header{Authorization} header corresponds to a user that the server is
willing to accept forwarded or direct calls for. 

\end{enumerate}

RFC2543 did not allow usage of the
\header{Authentication-Info} header (it effectively used RFC
2069). However, we now allow usage of 
this header, since it provides integrity checks over the bodies and
provides mutual authentication. RFC2617 \cite{rfc2617} defines
mechanisms for backwards compatibility using the qop attribute in the
request. These mechanisms {\MUST} be used by a server to determine if
the client supports the new mechanisms in RFC 2617 that were not
specified in RFC 2069.

\subsection{Proxy-Authentication}

The use of the \header{Proxy-Authentication} and
\header{Proxy-Authorization} parallel that as described in
\cite[Section~3.6]{rfc2617}, with one difference.  Proxies {\MUSTNOT}
add the \header{Proxy-Authorization} header.  407 (Proxy Authentication
Required) responses {\MUST} be forwarded upstream towards the client
following the procedures for any other response.  It is the client's
responsibility to add the \header{Proxy-Authorization} header containing
credentials for the proxy which has asked for authentication.

\motivation{If a proxy were to resubmit a request with a
\header{Proxy-Authorization} header field, it would need to increment
the \header{CSeq} in the new request.  However, this would mean that the
UAC which submitted the original request would discard a response from
the UAS, as the \header{CSeq} value would be different.}

See sections \ref{sec:Proxy-Authenticate} and
\ref{sec:Proxy-Authorization} for additional information on usage of
these fields as they apply to SIP.

It is also possible that a 401 (Unauthorized) response contains several
challenges, from a mixture of proxies and user agent servers, if the
request was forked.
