5. Writing Security Considerations Sections (Verfassen von Security-Considerations-Abschnitten)
5. Writing Security Considerations Sections (Verfassen von Security-Considerations-Abschnitten)
Es ist keine Anforderung, dass ein Protokoll oder System gegen alle Angriffsformen immun ist; dennoch müssen Autoren so viele Formen wie möglich bedenken. Ein Teil des Zwecks des Abschnitts Security Considerations ist zu erklären, welche Angriffe außerhalb des Geltungsbereichs liegen und welche Gegenmaßnahmen zum Schutz greifen. Außerdem soll eine klare Beschreibung der Bedrohungen für das beschriebene Protokoll oder die Technologie stehen. Das sollte als „Sorgfaltspflicht“ verstanden werden, alle bekannten oder vorhersehbaren Risiken und Bedrohungen für potenzielle Implementierer und Nutzer zu beschreiben.
Autoren MÜSSEN beschreiben:
- welche Angriffe außerhalb des Geltungsbereichs liegen (und warum!)
- welche Angriffe im Geltungsbereich liegen
- 2.1 und das Protokoll ist anfällig dafür
- 2.2 und das Protokoll schützt davor
Mindestens die folgenden Angriffsformen MÜSSEN bedacht werden: Abhören, Wiedergabe (Replay), Einfügen, Löschen und Modifizieren von Nachrichten sowie Man-in-the-Middle. Potenzielle Denial-of-Service-Angriffe MÜSSEN ebenfalls genannt werden. Nutzt das Protokoll kryptographische Schutzmechanismen, soll klar angegeben sein, welche Teile der Daten geschützt sind und welche Schutzarten (nur Integrität, Vertraulichkeit und/oder Endpunktauthentifizierung usw.). Es soll auch angedeutet werden, gegen welche Angriffe der kryptographische Schutz anfällig ist. Daten, die geheim zu halten sind (Schlüsselmaterial, Zufallskeime usw.), sollten klar gekennzeichnet sein.
Beteiligt die Technologie Authentifizierung, insbesondere Nutzer-Host-Authentifizierung, MUSS die Sicherheit der Authentifizierungsmethode klar angegeben werden. Das heißt, Autoren MÜSSEN die Annahmen dokumentieren, auf denen die Sicherheit dieser Methode beruht. Beim UNIX-Login mit Benutzername/Passwort etwa eine Formulierung wie:
Die Authentifizierung im System ist nur so sicher, wie es schwer ist, ein ASCII-Passwort mit maximal 8 Zeichen zu erraten oder zu erlangen. Diese Passwörter können durch Abhören von Telnet-Sitzungen oder durch Ausführen von ‚crack‘ mit dem Inhalt der Datei /etc/passwd gewonnen werden. Schutz vor Online-Passwort-Raten durch (1) Trennen der Verbindung nach mehreren fehlgeschlagenen Anmeldeversuchen und (2) Warten zwischen aufeinanderfolgenden Passwortabfragen wirkt nur insoweit, wie Angreifer ungeduldig sind.
Weil die Datei /etc/passwd Benutzernamen auf Benutzer-IDs, Gruppen usw. abbildet, muss sie weltlesbar sein. Um diese Nutzung zu erlauben und ‚crack‘ zu erschweren, wird die Datei oft in /etc/passwd und eine ‚shadow‘-Passwortdatei aufgeteilt. Die Shadow-Datei ist nicht weltlesbar und enthält das verschlüsselte Passwort. Die reguläre /etc/passwd enthält an ihrer Stelle ein Dummy-Passwort.
Es reicht nicht, nur zu sagen, man solle das Protokoll über ein Sicherheitsprotokoll einer unteren Schicht betreiben. Baut ein System auf Sicherheitsdiensten unterer Schichten auf, MÜSSEN die von diesen Diensten erwarteten Schutzleistungen klar angegeben werden. Außerdem müssen die resultierenden Eigenschaften des kombinierten Systems beschrieben werden.
Hinweis: Im Allgemeinen wird die IESG Standards-Track-Protokolle nicht genehmigen, die keine starke Authentifizierung im Protokoll selbst oder durch enge Bindung an ein Sicherheitsprotokoll einer unteren Schicht vorsehen.
Die Bedrohungsumgebung, die der Abschnitt Security Considerations mindestens abdeckt, MUSS die Bereitstellung im globalen Internet über mehrere Verwaltungsgrenzen hinweg umfassen, ohne anzunehmen, dass Firewalls vorhanden sind — selbst wenn nur die Begründung geliefert wird, warum eine solche Betrachtung für das Protokoll außerhalb des Geltungsbereichs liegt. Es ist nicht akzeptabel, nur Bedrohungen für LANs zu diskutieren und die breitere Bedrohungsumgebung zu ignorieren. Alle IETF-Standards-Track-Protokolle gelten als wahrscheinlich im globalen Internet einsetzbar. In manchen Fällen gibt es eine Applicability Statement, die von der Nutzung in bestimmten Umgebungen abrät. Dennoch sollten die Sicherheitsaspekte einer breiteren Bereitstellung im Dokument erörtert werden.
Es soll eine klare Beschreibung des Restrisikos für Nutzer oder Betreiber nach eingesetzter Bedrohungsminderung stehen. Solche Risiken können aus Kompromittierung eines verwandten Protokolls entstehen (z. B. IPsec nutzt wenig, wenn das Schlüsselmanagement kompromittiert ist), aus fehlerhafter Implementierung, aus Kompromittierung der eingesetzten Sicherheitstechnologie (z. B. eine Chiffre mit 40-Bit-Schlüssel) oder aus Risiken, die die Protokollspezifikation nicht adressiert (z. B. DoS auf ein darunterliegendes Verbindungsprotokoll). Besondere Vorsicht ist geboten, wenn die Kompromittierung eines einzelnen Systems ein ganzes Protokoll gefährdet. Protokollentwerfer nehmen oft an, Endsysteme seien unverletzbar und ignorieren physische Angriffe. In Fällen (wie einer Zertifizierungsstelle), in denen die Kompromittierung eines Systems weitreichende Folgen hätte, ist es angemessen, auch System- und physische Sicherheit zu bedenken.
Es soll auch eine Diskussion potenzieller Sicherheitsrisiken durch Fehlanwendung des in der RFC beschriebenen Protokolls oder der Technologie stehen. Das kann mit einer Applicability Statement für diese RFC verbunden werden.