12. Sicherheitsüberlegungen (Security Considerations)

Da Funktionen für mehrere Leitungserscheinungen unter Verwendung der von SIP [RFC3261], dem SIP-Ereignispaket für Dialogstatus [RFC4235] und dem SIP-Ereignis-Framework [RFC6665] und [RFC3903] bereitgestellten Semantik implementiert werden, gelten die Sicherheitsüberlegungen in diesen Dokumenten auch für dieses Dokument.

Um Vertraulichkeit zu gewährleisten, KÖNNEN (MAY) NOTIFY- oder PUBLISH-Nachrichtenkörper, die die Dialogstatusinformationen und die Dialogidentifikatoren bereitstellen, Ende-zu-Ende mit den Standardmechanismen wie S/MIME, die in [RFC3261] beschrieben sind, verschlüsselt werden. Alternativ bietet das Senden der NOTIFY- und PUBLISH-Anforderungen über TLS ebenfalls Vertraulichkeit, allerdings auf Hop-by-Hop-Basis. Alle SUBSCRIBEs und PUBLISHes zwischen den UAs und dem Erscheinungsagenten MÜSSEN (MUST) authentifiziert werden. Ohne ordnungsgemäße Authentifizierung und Vertraulichkeit könnte ein Dritter Informationen über Dialoge erfahren, die mit einem AOR verbunden sind, und könnte versuchen, diese Informationen zu verwenden, um diese Dialoge mit SIP-Anrufsteuerungsprimitiven zu kapern oder zu manipulieren.

Diese Funktion stützt sich auf Standard-SIP-Anrufsteuerungsprimitive wie Replaces und Join. Ordnungsgemäße Zugriffskont rollen auf ihre Verwendung MÜSSEN (MUST) verwendet werden, damit nur Mitglieder der gemeinsam genutzten Erscheinungsgruppe diese Mechanismen verwenden können. Alle INVITEs mit Replaces- oder Join-Header-Feldern DÜRFEN (MUST) nur akzeptiert werden, wenn der Peer, der den Dialogersatz oder die Verbindung anfordert, ordnungsgemäß mit einem Standard-SIP-Mechanismus (wie Digest oder S/MIME) authentifiziert und autorisiert wurde, einen Ersatz anzufordern. Andernfalls könnte ein Dritter bestehende Dialoge in der gemeinsam genutzten Erscheinungsgruppe stören oder kapern.

Für einen Notruf DARF (MUST NOT) ein UA NICHT auf eine bestätigte Belegung einer Erscheinung warten, bevor er ein INVITE sendet. Das Warten auf eine Bestätigung könnte den Notruf versehentlich verzögern oder blockieren, der aufgrund seiner Natur so schnell wie möglich getätigt werden muss. Stattdessen MUSS (MUST) ein Notruf unabhängig vom Status der PUBLISH-Transaktion fortfahren.