Ansichtsmodus

Administrator-Ansicht

Kontakt

Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.

Mediasec (Manuelle Konfiguration von Verschlüsselung)

Für die erfolgreiche Nutzung einer verschlüsselten VoIP-Verbindung sind neben einer TLS Verbindung für die SIP-Signalisierung und SRTP für die Verschlüsselung der Sprache noch weitere zusätzliche SIP Header und SDP Attribute notwendig.

Bei der Registrierung (SIP REGISTER) wird durch die zusätzlichen SIP Header der Plattform die Nutzung der Verschlüsselungsart mitgeteilt. Beim Gesprächsaufbau (SIP INVITE) und bei der Annahme von Gesprächen (SIP Response) muss die Verschlüsselungsart und die Reichweite der Verschlüsselung (Edge zu Access-Edge, Verschlüsselung zwischen TK-Anlage und Registrierungsserver) enthalten sein.

Die SIP Header orientieren sich an einem IETF Draft (https://tools.ietf.org/html/draft-dawes-sipcore-mediasec-parameter-11), sind aber als statische Ergänzung der SIP Signalisierung zu sehen.


SIP REGISTER

1) Beim initialen REGISTER ohne Authentication Challenge sind die SIP Header

  • Security-Client: sdes-srtp;mediasec
  • Proxy-Require: mediasec
  • Require: mediasec

erforderlich.


2) Die Plattform antwortet mit 401 UNAUTHORIZED. In dieser SIP Response sind die SIP Header

  • Security-Server: msrp-tls;mediasec
  • Security-Server: sdes-srtp;mediasec
  • Security-Server: dtls-srtp;mediasec

enthalten, welche die möglichen Verschlüsselungsarten wiedergeben.


3) Beim anschließenden REGISTER mit Authentication Challenge müssen neben den ursprünglich im initialen REGISTER geschickten SIP Headern

  • Security-Client: sdes-srtp;mediasec
  • Proxy-Require: mediasec
  • Require: mediasec

zusätzlich die SIP Header

  • Security-Verify: msrp-tls;mediasec
  • Security-Verify: sdes-srtp;mediasec
  • Security-Verify: dtls-srtp;mediasec

ergänzt werden.

Nach RFC 3261 können die Security-Verify Header auch zusammengefasst werden und als

  • Security-Verify: msrp-tls;mediasec,sdes-srtp;mediasec,dtls-srtp;mediasec

im REGISTER mit Authentication Challenge geschickt werden.


Beispiel:

Download als Textdatei

Wichtiger Hinweis

Wird bei der Registrierung über eine TLS-Verbindung auf die Übertragung der beschriebenen SIP Header verzichtet, verläuft diese zunächst erfolgreich. Es ist aber nicht möglich diese Registrierung erfolgreich zu nutzen, d. h. eingehende oder ausgehende Verbindungsanfragen werden abgewiesen.


INVITE/UPDATE

1) Im initialen INVITE müssen erneut die SIP Header

  • Proxy-Require: mediasec
  • Require: mediasec
  • Security-Server: msrp-tls;mediasec
  • Security-Server: sdes-srtp;mediasec
  • Security-Server: dtls-srtp;mediasec

enthalten sein.

Damit wird die Nutzung der Verschlüsselung und die Verschlüsselungsart kommuniziert. Zusätzlich ist im SDP das Attribut

  • a=3ge2ae:requested

erforderlich.

Dies legt die Reichweite der Verschlüsselung fest, in diesem Fall zwischen IP-PBX und Registrierungsserver.


2) Wird ein RE-INVITE oder UPDATE vom SIP Client initiiert, müssen die oben genannten SIP Header und auch das SDP Attribut erneut enthalten sein.


Beispiel:

Download als Textdatei


RESPONSE

1) Beim eingehenden INVITE von der Plattform ist im SDP das Attribut

  • a=3ge2ae:applied

enthalten.


2) In allen Responses mit SDP (z. B. 18x oder 200) muss das Attribut

  • a=3ge2ae:requested

enthalten sein.


Beispiel:

Download der Textdatei