SIP Authentication

Beachten Sie auch die OCS Logon

Wenn ein Endgerät von einem anderen Endgerät eine Leistung erhalten will, dann ist das kontaktierte System gut beraten, seine Leistung nicht anonym bereit zu stellen. Bei öffentlichen Webservern wie z.B. der www.msxfaq.net ist dies natürlich eher anders aber schon das firmeninterne Intranet oder OWA werden sicher nicht ohne Authentifizierung genutzt. Und eine SIP-Infrastruktur ist noch weniger eine "öffentliche" Angelegenheit. Selbst Dienste wie Skype, die einen Teil der Funktionen kostenfrei anbieten, erfordern eine Authentifizierung. Hier ist aber mehr die Sicherung der Identität denn eine Weiterberechnung von Kosten das Ziel.

Wie erfolgt die Authentifizierung ?

Das SIP-Protokoll unterstützt schon immer die Authentifizierung und die Registrierung von Clients. Beides ist aber keine Voraussetzungen. Es gibt viele Beispiele, bei denen Sprachverbindungen durch einen "INVITE" vom Anrufer zum Ziel ohne vorherige Authentifizierung gestartet werden. Allerdings muss der Anrufer natürlich das "Ziel" z.B. per DNS (Stichwort ENUM) erreichen können. Wenn Sie mich aber als "sip:frank.carius@netatwork.de" anrufen wollen, dann sprechen Sie ja mit meinem Server an dem ich mich wieder registriert (Mit Anmeldung) hatte.

Ein "INVITE" zu einem anderen Endgerät ohne Authentifizierung ist aber z.B.: zwischen bekannten "Peers" heute durchaus üblich. Wenn Provider und Kunde oder Provider untereinander sich per SIP Trunking / DirectSIP verbinden, dann passiert das in den seltensten Fällen mit "Benutzername und Kennwort.

Damit haben wir also drei Kriterien einer SIP-Authentifizierung, die auch kombiniert werden können

  • IP-Adressen
    Die Steuerung über IP-Adressen kann durch eine Firewall oder auch auf dem SIP-Stack erfolgen. Dies ist eine relativ einfache Methode, um eine Kommunikation auf erwünschte Partner zu beschränken und so sichere ich z.B. meine Gateways ab, zu denen der Lync Mediation Server seine "INVITE" sendet. Das Gateway nimmt einfach nur SIP-Pakete von Lync und bekannten anderen Gateways an
  • Zertifikate (bei SIP/TLS)
    Dazu müssen die Endpunkte aber erst einmal SIP/TLS können und dann ist es immer noch erforderlich, dass das vorgezeigte Zertifikat auch auf eine Identität abgebildet werden kann. CRL-Prüfungen, RootCAs etc. sind hier zu berücksichtigen. Lync setzt stark auf Zertifikate. So "erkennen" und verschlüsseln Server einer Lync-Umgebung untereinander die SIP-Pakete und selbst der Lync Client bekommt vom Server ein "Zertifikat". So bleiben die Kommunikationswege verschlüsselt aber funktionieren auch, wenn der Anmeldedienst des Active Directory nicht zur Verfügung steht. Ein Client kann sich dennoch am Server anmelden.
  • Username/Kennwort
    Der einfachste und sicher im Endgerätebereich häufigste Weg ist die Anmeldung mit Benutzername/Kennwort. Werden hier die Daten aber über "unsichere Netze" im Klartext übertragen, ist ein Identitätsdiebstahl einfach. Daher ist die Sicherung der Anmeldedaten mit einem besseren Authentifizierungsprotokoll dringend anzuraten. Leider "sieht" der Anwender nicht, welches Protokoll Client und Server aushandeln. Das sieht er übrigens bei HTTP auch nicht. Sicher ist man daher nur, wenn man SIP/TLS verwendet.

Hoffen wir also, dass ihr System immer gut gesichert ist.

"Einbrecher" suchen heute schon lange nicht mehr nur nach "offenen" FTP-Servern, Telnet-Zugängen oder ungesicherten Mailservern, die als Relay missbraucht werden können. Fast alle Scanner suchen heute auch aktiv nach Diensten auf Port 5060. Stellen Sie einfach mal einen SIP-Registrar mit einem Bein ins Internet.
Das sollte natürlich ein eigenes System ohne weitere Verbindungen sein.

Technische Details

Der direkte Blick auf die technischen Aspekte erhalten wir mit einem Netzwerktrace. Allerdings nur mir deaktivierte SSL-Verschlüsselung. Ich habe hier als Beispiel eine Anmeldung an einer Audiocodes SPS über 5060/TCP protokolliert. Die Anmeldung eines "REGISTER" kann man in vier Paketen nachverfolgen

Die Software "PhonerLite" ist kostenfrei, (noch) nicht mit Werbung gespickt wie z.B. X-Lite und erlaubt viel mehr Einstellungen in den SIP-Parametern. Sie ist damit ideal für Versuche und Analysen. Bei meinen Versuchen zur Anbindung eines Grandstream ATA-Router 502 SIP an eine Audiocodes SPS hatte ich einige Probleme, bis ich die Anmeldedaten korrekt hatte. Und da hat mir Phoner Lite geholfen, bestimmte Werte an die Audiocodes SPS (nutzt eine FreeSwitch) zu senden und die Antworten zu analysieren.

Ich habe dazu folgende Parameter eingestellt:

Natürlich funktionieren diese Anmeldedaten so nicht und das können Sie auch gleich im ersten Versuch sehen:

Eine erfolgreiche Anmeldung unterscheidet sich aber nur in der letzten Zeile:

Die vier Pakete bedeuten:

  1. Erster REGISTER ohne Anmeldedaten
  2. 401 unautorized des Server aber mit wichtigen Informationen zur Anmeldung
  3. Zweite Anmeldung mit den eingegebenen Daten
  4. 403 Forbidden, weil die Daten natürlich falsch waren
    ich wollte ja nur sehen, in welchen Feldern was auftaucht.

Eine SIP-Anmeldung funktioniert eben ähnlich einer HTTP-Authentifizierung, bei der auch erst mal "anonym" gearbeitet wird um mit der ersten "401 unautorized" zu wissen, welche Anmeldeverfahren der Server denn unterstützt. Niemand sendet einfach mal so ein Kennwort los.

Erstes Register (anonym)

Der erste anonyme REGISTER enthält zumindest schon mal die From und To-Zeile und den "Contact"

- SIP: Request: REGISTER sip:Username SIP/2.0
  - SipParser: Request: REGISTER sip:Username SIP/2.0
   + RequestLine: REGISTER sip:Username SIP/2.0
   - RequestHeaders: 
    + Via: SIP/2.0/TCP 192.168.102.36:55692;branch=z9hG4bK80a7a7690cd7e111a4bfd872ff73f7e1
    + From: "Analog694" <sip:694@Username>;tag=2249764972
    + To: "Analog694" <sip:694@Username>
      CallID: 00301963-0CD7-E111-A4BE-D872FF73F7E1@192.168.102.36
    + CSeq: 1 REGISTER
    + Contact: <sip:694@Username;transport=tcp>;+sip.instance="<urn:uuid:800F695B-64D2-E111-95E4-BA2E95687A58>"
      Allow: INVITE, OPTIONS, ACK, BYE, CANCEL, INFO, NOTIFY, MESSAGE, uPDATE
      Max-Forwards: 70 User-Agent: SIPPER für PhonerLite
      Expires: 900
      ContentLength: 0
      HeaderEnd: CRLF

Aber sollte hier ihre Gegenstelle schon einen "SIP 2.0 200 OK" senden, dann sollten Sie schleunigst ihre Anmeldeeinstellungen auf dem Registrar prüfen.

401 von FreeSwitch

Keine sicherer Registrar erlaubt einen anonymen Zugriff und so lehnt auch die Freeswitch erst mal die Registrierung ab:

- SIP: Response: SIP/2.0 401 unauthorized
  - SipParser: Response: SIP/2.0 401 unauthorized
   - StatusLine: SIP/2.0 401 unauthorized
      SIPVersion: SIP/2.0
      StatusCode: 401 - Client Error(Unauthorized)
      ReasonPhrase: unauthorized
   - ResponseHeaders: 
    + Via: SIP/2.0/TCP 192.168.102.36:55692;branch=z9hG4bK80a7a7690cd7e111a4bfd872ff73f7e1
    + From: "Analog694" <sip:694@Username>;tag=2249764972
    + To: "Analog694" <sip:694@Username>;tag=5t3BcNvFH3tDH
      CallID: 00301963-0CD7-E111-A4BE-D872FF73F7E1@192.168.102.36
    + CSeq: 1 REGISTER User-Agent: FreeSWITCH-mod_sofia/1.1.beta1-git-
      Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, uPDATE, INFO, REGISTER, REFER, PRACK, NOTIFY, PUBLISH, SUBSCRIBE
      Supported: 100rel, timer, precondition, path, replaces
    - Authorization: Digest realm="Username", nonce="858bfee3-ec77-40ff-b156-eade946532ae", algorithm=MD5, qop="auth"
       scheme: Digest
       Realm: "Username"
       nonce: "858bfee3-ec77-40ff-b156-eade946532ae"
       Algorithm: MD5
       QualityOfProtection: "auth"
      ContentLength: 0
      HeaderEnd: CRLF

Wichtig ist hier zu sehen, dass ein "Authorization"-Header enthalten ist. Die FreeSwitch unterstützt als DIGEST als Authentication und sendet gleich einen "nonce" mit. Zudem enthält die Antwort auch den "realm", den hier die FreeSwitch aber aus dem ersten REGISTER generiert. Wenn Sie sich an einer Webseite mit ihrem Browser anmelden müssen, dann ist der REALM das, was im Fester als Name angezeigt wird. Bei SIP gibt es natürlich keine "Interaktion" aber das Feld ist natürlich wichtig für das nächste Paket.

Zweiter Register zur Anmeldung

Mit diesen Daten kann der Client nun zum REGISTER mit Anmeldung schreiten. Hier ist nun auch ein Autorization-Header enthalten, der den Benutzernamen enthält. Da wir "DIGEST" als Verfahren verwenden, ist das Kennwort nicht im Klartext vorhanden, sondern wurde über eine nicht reversible Hashfunktion

- SIP: Request: REGISTER sip:Username SIP/2.0
  - SipParser: Request: REGISTER sip:Username SIP/2.0
   + RequestLine: REGISTER sip:Username SIP/2.0
   - RequestHeaders: 
    + Via: SIP/2.0/TCP 192.168.102.36:55692;branch=z9hG4bK0098a26c0cd7e111a4bfd872ff73f7e1
    + From: "Analog694" <sip:694@Username>;tag=2249764972
    + To: "Analog694" <sip:694@Username>
      CallID: 00301963-0CD7-E111-A4BE-D872FF73F7E1@192.168.102.36
    + CSeq: 2 REGISTER
    + Contact: <sip:694@Username;transport=tcp>
    - Authorization: 
       scheme: Digest UserName: "694@authname"
       Realm: "Username"
       nonce: "858bfee3-ec77-40ff-b156-eade946532ae" uri: "sip:Username"
       Response: "7ebf79ba2c152926e8aa8afc136b9635"
       Algorithm: MD5
       cnonce: "003e406a0cd7e111a4bfd872ff73f7e1"
       QualityOfProtection: auth
       nc: 00000001
      Allow: INVITE, OPTIONS, ACK, BYE, CANCEL, INFO, NOTIFY, MESSAGE, uPDATE
      Max-Forwards: 70 User-Agent: SIPPER für PhonerLite
      Expires: 900
      ContentLength: 0
      HeaderEnd: CRLF

 Hier ist dann gut zu sehen, wo die verschiedenen Werte der Konfiguration erscheinen.

  • UserName: "694@authname"
  • Realm: "Username"
  • Uri: "sip:Username"

403 Forbidden wegen falscher Daten

Ich habe in dem Muster absichtlich falsche Daten eingetragen, um diese in dem Trace einfach wieder zu finden. Entsprechend bekomme ich natürlich einen 403 zurück.

- SIP: Response: SIP/2.0 403 Forbiden
  - SipParser: Response: SIP/2.0 200 OK
   - ResponseHeaders: 
    + Via: SIP/2.0/TCP 192.168.100.67:5060;branch=z9hG4bK0098a26c0cd7e111a4bfd872ff73f7e1
    + From: "Analog694" <sip:694@Username>;tag=2249764972
    + To: "Analog694" <sip:694@Username>
      CallID: 00301963-0CD7-E111-A4BE-D872FF73F7E1@192.168.102.36
    + CSeq: 2 REGISTER
    + Contact: <sip:694@Username;transport=tcp> User-Agent: FreeSWITCH-mod_sofia/1.1.beta1-git-
      Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, uPDATE, INFO, REGISTER, 
               REFER, PRACK, NOTIFY, PUBLISH, SUBSCRIBE
      Supported: 100rel, timer, precondition, path, replaces

Authentication beim INVITE

ähnlich wie bei einer Websession können auch bei SIP mehrere Sessions parallel aufgebaut werden. Damit ist klar, dass ein INVITE eine eigene Session sein kann und ebenfalls einer Authentifizierungspflicht unterliegt. Hier ein Mitschnitt

Der INVITE wird vom SIP-Proxy erst mit einem 100 zwischenbestätigt und dann mit "407 Proxy Authentication required" quittiert. Diese Paket enthält wieder die Information, wie die Anmeldung erfolgen kann.

- SIP: Response: SIP/2.0 407 Proxy Authentication Required
  - SipParser: Response: SIP/2.0 407 Proxy Authentication Required
   + StatusLine: SIP/2.0 407 Proxy Authentication Required
   - ResponseHeaders: 
    + Via: SIP/2.0/TCP 192.168.103.35:3288;branch=z9hG4bK001f2a805dd7e111b1974887489110ba
    + From: "FC (Phoner)" <sip:frank.carius@netatwork.de>;tag=863331280
    + To: <sip:05246700971@192.168.100.64;transport=tcp>;tag=BrtH43ytr4ySS
      CallID: 001F2A80-5DD7-E111-B196-4887489110BA@192.168.103.35
    + CSeq: 3 INVITE User-Agent: FreeSWITCH-mod_sofia/1.1.beta1-git-
      Accept: application/sdp
      Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, uPDATE, INFO, 
            REGISTER, REFER, PRACK, NOTIFY, PUBLISH, SUBSCRIBE
      Supported: 100rel, timer, precondition, path, replaces
    - Authorization:
       scheme: Digest
       Realm: "netatwork.de"
       nonce: "62d622d6-f9e8-4938-b1ed-f56401213863"
       Algorithm: MD5
       QualityOfProtection: "auth"
      ContentLength: 0
      HeaderEnd: CRLF

Dann sendet der Client erneut ein INVITE in einer eigenen SIP-Transaktion (Der Wert für CSeq wurde erhöht)

- SIP: Request: INVITE sip:05246700971@192.168.100.64;transport=tcp SIP/2.0
  - SipParser: Request: INVITE sip:05246700971@192.168.100.64;transport=tcp SIP/2.0
   + RequestLine: INVITE sip:05246700971@192.168.100.64;transport=tcp SIP/2.0
   - RequestHeaders: 
    + Via: SIP/2.0/TCP 192.168.103.35:3288;branch=z9hG4bK004c5b815dd7e111b1984887489110ba;rport
    + From: "FC (Phoner)" <sip:frank.carius@netatwork.de>;tag=863331280
    + To: <sip:05246700971@192.168.100.64;transport=tcp>
      CallID: 001F2A80-5DD7-E111-B196-4887489110BA@192.168.103.35
    + CSeq: 4 INVITE
    + Contact: <sip:frank.carius@netatwork.de>
    - Authorization:
       scheme: Digest UserName: "frank.carius"
       Realm: "netatwork.de"
       nonce: "62d622d6-f9e8-4938-b1ed-f56401213863" uri: "sip:05246700971@192.168.100.64;transport=tcp"
       Response: "5ad9edccd3e32af857015bb6ffd3f03b"
       Algorithm: MD5
       cnonce: "004c5b815dd7e111b1974887489110ba"
       QualityOfProtection: auth

Diese Anfrage wird dann, bei korrekten Anmeldedaten, verarbeitet.

Weitere Links