12. Considerazioni sulla sicurezza (Security Considerations)

Poiché le funzionalità di apparenza a linee multiple sono implementate utilizzando la semantica fornita da SIP [RFC3261], il pacchetto di eventi SIP per lo stato del dialogo [RFC4235] e il framework di eventi SIP [RFC6665] e [RFC3903], le considerazioni sulla sicurezza in questi documenti si applicano anche a questo documento.

Per fornire riservatezza, i corpi dei messaggi NOTIFY o PUBLISH che forniscono le informazioni sullo stato del dialogo e gli identificatori del dialogo POSSONO (MAY) essere crittografati end-to-end utilizzando i meccanismi standard come S/MIME descritto in [RFC3261]. In alternativa, l'invio delle richieste NOTIFY e PUBLISH tramite TLS fornisce anche riservatezza, sebbene su base hop-by-hop. Tutti i SUBSCRIBE e i PUBLISH tra gli UA e l'agente di apparenza DEVONO (MUST) essere autenticati. Senza un'adeguata autenticazione e riservatezza, una terza parte potrebbe apprendere informazioni sui dialoghi associati a un AOR e potrebbe tentare di utilizzare queste informazioni per dirottare o manipolare tali dialoghi utilizzando primitive di controllo delle chiamate SIP.

Questa funzionalità si basa su primitive di controllo delle chiamate SIP standard come Replaces e Join. DEVONO (MUST) essere utilizzati controlli di accesso appropriati sul loro uso in modo che solo i membri del gruppo di apparenza condivisa possano utilizzare questi meccanismi. Tutti gli INVITE con campi di intestazione Replaces o Join DEVONO (MUST) essere accettati solo se il peer che richiede la sostituzione o l'unione del dialogo è stato correttamente autenticato utilizzando un meccanismo SIP standard (come Digest o S/MIME) e autorizzato a richiedere una sostituzione. Altrimenti, una terza parte potrebbe interrompere o dirottare dialoghi esistenti nel gruppo di apparenza condivisa.

Per una chiamata di emergenza, un UA NON DEVE (MUST NOT) attendere un'appropriazione confermata di un'apparenza prima di inviare un INVITE. Attendere la conferma potrebbe inavvertitamente ritardare o bloccare la chiamata di emergenza, che per sua natura deve essere effettuata il più rapidamente possibile. Invece, una chiamata di emergenza DEVE (MUST) procedere indipendentemente dallo stato della transazione PUBLISH.