\section{Security Considerations}
\label{sec:security}

Any resource priority mechanism can be abused to obtain resources and
thus deny service to other users.  An adversary may be able to take over
a particular gateway, cause additional congestion during PSTN during
emergencies or deny service to legitimate users.

While the indication itself does not have to provide separate
authentication, any SIP request carrying such information has higher
authentication requirements than regular requests.  Below, we describe
authentication and authorization aspects, confidentiality and privacy
requirements, protection against denial of service attacks and anonymity
requirements.  Naturally, the general discussion in RFC 3261
\cite{rfc3261} applies.

\subsection{Authentication and Authorization}

Prioritized access to network and end system resources imposes
particularly stringent requirements on authentication and authorization
mechanisms since access to prioritized resources may impact overall
system stability and performance, not just result in theft of, say, a
single phone call.
   
Under certain emergency conditions, the network infrastructure,
including its authentication and authorization mechanism, may be under
attack.

Given the urgency during emergency events, normal statistical fraud
detection may be less effective, thus placing a premium on reliable
authentication.

Common requirements for authentication mechanisms apply, such as
resistance to replay, cut-and-paste and bid-down attacks.

Authentication {\MAY} be SIP-based or use other mechanisms.  Use of
Digest authentication and/or S/MIME is {\RECOMMENDED} for UAS
authentication, but it requires that the parties share a common secret. 
SIP systems employing resource priority {\MUST} implement S/MIME at
least for integrity, as described in Section 23 of \citenorm{rfc3261}. 
Section~\ref{sec:thirdparty} describes third-party authentication. 

Role-based authorization \citeinform{draft-peterson-sipping-role-authz}
``entails an assertion by a authorization service of attributes
associated with an identity'' and may be appropriate for this
application as it avoids that all network elements need to maintain or
consult a mapping from user identifiers to authorizations.

Authorization may be based on factors beyond the identity of the caller,
such as the requested destination. Namespaces {\MAY} also impose particular authentication or authorization
consideration that are stricter than the baseline described here. 

\subsection{Confidentiality and Integrity}
   
Calls which use elevated resource priority levels provided by the \header{Resource-Priority} header field 
are likely to
be sensitive and often need to be protected from intercept and alteration.  In
particular, requirements for protecting the confidentiality of
communications relationships may be higher than for normal commercial
service.  For SIP, the \header{To}, \header{From},
\header{Organization}, \header{Subject} and \header{Via} header fields
are examples of particularly sensitive information.  Systems {\MUST}
provide for encryption at the transport level using TLS and {\MAY}
implement other transport-layer or network-layer security mechanisms. 
UACs {\SHOULD} use the ``sips'' URI to request a secure transport
association to the destination.

The \header{Resource-Priority} header field can be carried in the SIP
message header or can be encapsulated in a message fragment carried in
the SIP message body \citenorm{rfc3420}.  Encapsulation allows to
protect this header field against inspection or modification by proxies,
using S/MIME.  However, in many cases, proxies will need to authenticate
and authorize the request, so that encapsulation is undesirable. 

\subsection{Anonymity}
   
Some users may wish to remain anonymous to the request destination. 
Anonymity for requests with resource priority is no different than for
any other authenticated SIP request.  For the reasons noted earlier,
users have to authenticate themselves towards the SIP elements carrying
the request where they desire resource priority treatment.  The
authentication may be based on capabilities and noms, not necessarily
their civil name.  Clearly, they may remain anonymous towards the
request destination, using the network-asserted identity and general
privacy mechanisms \citeinform{rfc3323,rfc3325}.

\subsection{Denial-of-Service Attacks}
   
As noted, systems described here are likely to be subject to deliberate denial-
of-service attacks during certain types of emergencies.  DOS attacks may
be launched on the network itself as well as its authentication and
authorization mechanism.  As noted, systems should minimize the amount
of state, computation and network resources that an unauthorized user
can command.  The system must not amplify attacks by causing the
transmission of more than one packet to a network address whose
reachability has not been verified.
