Framework and Security Considerations for Session Initiation Protocol (SIP) URI-List Services
Extracted elements (25)
The interpretation of the URI list is left service-specific (GEN 2) because different services assign different semantics to list entries—conference servers treat URIs as participants, messaging servers treat them as message recipients.
The opt-in list requirement exists because even authorized users could exploit URI-list services to flood third-party destinations; requiring prior consent from each destination prevents this abuse.
URI-list services are introduced to reduce access-network traffic when a UA needs to send similar requests to many recipients, especially over low-bandwidth links where completing all transactions independently would be unacceptably slow.
Behavior of application servers receiving SIP requests with URI lists SHOULD be specified on a per-service basis; examples are RFC 5366 for INVITE, RFC 5365 for MESSAGE, and RFC 5367 for SUBSCRIBE.
Section 19.1.5 of RFC 3261 provides recommendations for forming a request from a URI, and those recommendations apply to all SIP URI-list services when generating fan-out requests.
A UA server receiving a recipient-list URI list that contains a URI more than once MUST behave as if that URI appeared in the URI list only once, using URI-scheme-specific comparison rules.
A UA server receiving a request with more than one recipient-list body part MUST behave as if it had received a single URI list containing all URIs present in the different body parts.
Application servers MUST use authentication and authorization mechanisms with equivalent security properties when dealing with stored and request-contained URI lists.
Clients SHOULD integrity protect URI lists using end-to-end mechanisms such as S/MIME or, if not available, hop-by-hop mechanisms such as TLS.
Clients SHOULD NOT include any particular URI more than once in a given URI list.
GEN 4 requires that URI-list services MUST NOT send requests to any destination without authenticating the invoker.
REQ 2 states that the URI-list service invocation mechanism SHOULD NOT require more than one transaction.
Specifications dealing with individual SIP methods MUST describe the security issues that relate to each particular method when used with URI-list services.
URI-list service specifications MUST specify a default format for recipient-list bodies used within a particular service.
URI-list services MUST implement and SHOULD use the Framework for Consent-Based Communications in SIP (RFC 5360) to satisfy opt-in list requirements.
URI-list services MUST NOT perform any request explosion for an unauthorized user. URI-list services MUST authenticate users and check whether they are authorized to request the service before performing any request fan-out.
URI-list services MUST NOT send a request to a destination that has not agreed to receive requests from the URI-list service beforehand, effectively requiring opt-in lists.
A new Content-Disposition header field disposition type 'recipient-list' is defined. Bodies with this disposition type carry a list of URIs identifying the final recipients of requests to be generated by a URI-list service.
A URI-list service receives a request containing or referencing a URI list and sends similar requests to the listed destinations, behaving as a B2BUA (Back-to-Back-User-Agent).
Users MUST be able to describe the requests they are willing to receive; for example, a user may only want to receive requests from a specific URI-list service on behalf of a particular user.
This document registers the 'recipient-list' disposition type in the IANA registry for Mail Content Disposition Values and Parameters. Its description: 'The body includes a list of URIs to which URI-list services are to be applied.'
Attackers may attempt to modify URI lists in transit, causing requests to be sent to unintended recipients. Clients should use S/MIME (end-to-end) or TLS (hop-by-hop) to provide integrity protection and optionally confidentiality.
Attackers may use URI-list services as traffic amplifiers for DoS attacks by submitting URI lists whose host parts route to victims. Mitigation requires authentication, authorization, and opt-in consent from destinations before any fan-out occurs.
The mechanism used to obtain permissions (consent) must not itself create DoS amplification opportunities; RFC 5360 avoids this by requiring the client to generate roughly the same amount of traffic toward the service as the service generates toward destinations.
URI-list services MAY limit the number of URIs in accepted lists, as excessively long lists can be used in DoS attacks to burden the service with generating a large number of SIP requests.