12. Security Considerations

Since multiple line appearance features are implemented using semantics provided by SIP [RFC3261], the SIP Event Package for Dialog State [RFC4235], and the SIP Event Framework [RFC6665] and [RFC3903], security considerations in these documents apply to this document as well.

To provide confidentiality, NOTIFY or PUBLISH message bodies that provide the dialog state information and the dialog identifiers MAY be encrypted end-to-end using the standard mechanisms such as S/MIME described in [RFC3261]. Alternatively, sending the NOTIFY and PUBLISH requests over TLS also provides confidentiality, although on a hop-by-hop basis. All SUBSCRIBEs and PUBLISHes between the UAs and the Appearance Agent MUST be authenticated. Without proper authentication and confidentiality, a third party could learn information about dialogs associated with a AOR and could try to use this information to hijack or manipulate those dialogs using SIP call control primitives.

This feature relies on standard SIP call control primitives such as Replaces and Join. Proper access controls on their use MUST be used so that only members of the shared appearance group can use these mechanisms. All INVITEs with Replaces or Join header fields MUST only be accepted if the peer requesting dialog replacement or joining has been properly authenticated using a standard SIP mechanism (such as Digest or S/MIME), and authorized to request a replacement. Otherwise, a third party could disrupt or hijack existing dialogs in the shared appearance group.

For an emergency call, a UA MUST NOT wait for a confirmed seizure of an appearance before sending an INVITE. Waiting for confirmation could inadvertently delay or block the emergency call, which by its nature needs to be placed as expeditiously as possible. Instead, a emergency call MUST proceed regardless of the status of the PUBLISH transaction.