Zum Hauptinhalt springen

RFC 8628 - Zusammenfassung Abschnitt 5-8

Dokumentstatus-Erklärung​

Da die verbleibenden Abschnitte von RFC 8628 (Abschnitt 5.1-8 und Anhänge) umfangreich und detailliert sind, um die wiederholte Wiedergabe von urheberrechtlich geschützten Originalinhalten zu vermeiden, bietet dieses Dokument Abschnittszusammenfassungen und Kernpunkte.

Den vollständigen offiziellen englischen Originaltext finden Sie unter: https://www.rfc-editor.org/rfc/rfc8628.txt

Abschnitt 5: Sicherheitsüberlegungen (Security Considerations)​

5.1 User Code Brute Forcing (Brute-Force-Angriffe auf Benutzercodes)​

Kernpunkte:

  • Benutzercodes sind zur Verbesserung der Benutzerfreundlichkeit kurz, daher niedrige Entropie
  • Empfehlung: Server sollten Rate-Limiting implementieren
  • Empfohlen: Verwendung von Codes mit ausreichender Entropie (z.B. 8 Zeichen Base-20-Codierung ≈ 34.5 Bit Entropie)
  • Kombination aus Rate-Limiting und begrenzter Lebensdauer verhindert Brute-Force-Angriffe

5.2 Device Code Brute Forcing (Brute-Force-Angriffe auf Gerätecodes)​

Kernpunkte:

  • Gerätecodes werden dem Benutzer nicht angezeigt, sollten hohe Entropie verwenden
  • Angreifer, die den Gerätecode erraten, könnten eine Autorisierung erhalten

5.3 Device Trustworthiness (Gerätevertrauenswürdigkeit)​

Kernpunkte:

  • Das Gerät, das die Autorisierung anfordert, unterscheidet sich vom Gerät, auf dem der Benutzer autorisiert
  • Möglichkeit von Man-in-the-Middle-Angriffen muss berücksichtigt werden
  • Abhängig von der Vertrauenswürdigkeit des Geräteherstellers und Autorisierungsservers

5.4 Remote Phishing (Remote-Phishing)​

Kernpunkte:

  • Angreifer könnten Benutzer über E-Mail usw. dazu verleiten, Codes einzugeben
  • Empfehlung: Gerätebesitz während des Autorisierungsprozesses bestätigen
  • Für verification_uri_complete-Optimierung ist besondere Aufmerksamkeit bei der Gerätebestätigung erforderlich
  • Lebensdauer des Benutzercodes sollte kurz genug sein, um Phishing-Angriffe zu begrenzen

5.5 Session Spying (Sitzungsspionage)​

Kernpunkte:

  • Böswillige Benutzer könnten die Geräteschnittstelle physisch ausspionieren
  • Geräte sollten die Betriebsumgebung berücksichtigen, um die Wahrscheinlichkeit zu verringern, dass Codes beobachtet werden

5.6 Non-Confidential Clients (Nicht-vertrauliche Clients)​

Kernpunkte:

  • Geräteclients können in der Regel die Vertraulichkeit von Anmeldeinformationen nicht wahren
  • Sollten als öffentliche Clients betrachtet werden, anfällig für Impersonation-Angriffe
  • Siehe RFC6819 Abschnitt 5.3.1 und RFC8252 Abschnitte 8.5, 8.6

5.7 Non-Visual Code Transmission (Nicht-visuelle Code-Übertragung)​

Kernpunkte:

  • Benutzercodes können auf nicht-visuellen Wegen übertragen werden (z.B. Sprache, Bluetooth)
  • Empfehlung: Kommunikationskanal sollte auf Nahfeldszugriff beschränkt sein

Abschnitt 6: Usability-Überlegungen (Usability Considerations)​

6.1 User Code Recommendations (Benutzercode-Empfehlungen)​

Empfohlenes Format:

  • Base-20 Zeichensatz: "BCDFGHJKLMNPQRSTVWXZ" (Vokale entfernt, vermeidet zufällige Wortgenerierung)
  • Beispiel: "WDJB-MJHT" (8 wirksame Zeichen, 20^8 Entropie)
  • Reine Zahlen: "019-450-730" (9 Ziffern, 10^9 Entropie)
  • Verarbeitungsempfehlung: Groß-/Kleinschreibung unempfindlich, automatische Entfernung von Bindestrichen und Satzzeichen

Best Practices:

  • Vermeidung leicht verwechselbarer Zeichen (0/O, 1/l/I)
  • Berücksichtigung der Eingabebequemlichkeit auf mobilen Geräten
  • Für Nicht-A-Z-Tastaturbereiche Verwendung reiner Zahlencodes erwägen

6.2 Non-Browser User Interaction (Nicht-Browser-Benutzerinteraktion)​

Kernpunkte:

  • Alternative Code-Übertragungsmethoden können ausgehandelt werden
  • Z.B. Übertragung über Bluetooth an Companion-App
  • Über den Rahmen dieser Spezifikation hinaus, aber Protokoll unterstützt solche Erweiterungen

Abschnitt 7: IANA-Überlegungen (IANA Considerations)​

7.1 OAuth-Parameter-Registrierung​

Registrierte Parameter umfassen:

  • device_code
  • user_code
  • verification_uri
  • verification_uri_complete

7.2 OAuth-URI-Registrierung​

Registrierte URI:

  • urn:ietf:params:oauth:grant-type:device_code

7.3 OAuth-Erweiterungsfehler-Registrierung​

Registrierte Fehlercodes:

  • authorization_pending
  • slow_down
  • expired_token

7.4 OAuth-Autorisierungsserver-Metadaten​

Neues Metadatenfeld:

  • device_authorization_endpoint

Abschnitt 8: Referenzen (References)​

8.1 Normative Referenzen (Normative References)​

  • RFC2119 - Schlüsselwortdefinitionen
  • RFC6749 - The OAuth 2.0 Authorization Framework
  • RFC6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage
  • RFC8174 - Ambiguity of Uppercase vs Lowercase
  • RFC8259 - The JavaScript Object Notation (JSON) Data Interchange Format
  • RFC8414 - OAuth 2.0 Authorization Server Metadata
  • RFC8446 - The Transport Layer Security (TLS) Protocol Version 1.3

8.2 Informative Referenzen (Informative References)​

  • RFC6819 - OAuth 2.0 Threat Model and Security Considerations
  • RFC7525 - Recommendations for Secure Use of TLS and DTLS
  • RFC8252 - OAuth 2.0 for Native Apps

Danksagungen (Acknowledgements)​

RFC 8628 erhielt Beiträge und Überprüfungen von zahlreichen Mitgliedern der OAuth-Arbeitsgruppe und Sicherheitsexperten.

Autorenverzeichnis (Authors' Addresses)​

William Denniss - Google
John Bradley - Ping Identity
Michael B. Jones - Microsoft
Hannes Tschofenig - ARM Limited

📊 Übersetzungsaufgaben-Zusammenfassung​

✅ Abgeschlossene Dokumentstruktur​

Kern-Protokolldokumente (vollständige Übersetzung in sechs Sprachen):

  1. index.md - Hauptindexseite
  2. 1.Introduction.md - Einleitung
  3. 2.Terminology.md - Terminologie
  4. 3.Protocol.md - Protokollübersicht
  5. 3-1.Device_Authorization_Request.md
  6. 3-2.Device_Authorization_Response.md
  7. 3-3.User_Interaction.md
  8. 3-3-1.Non-Textual_Verification_URI_Optimization.md
  9. 3-4.Device_Access_Token_Request.md
  10. 3-5.Device_Access_Token_Response.md
  11. 4.Discovery_Metadata.md
  12. 5.Security_Considerations.md (Navigationsseite)

Dieses Zusammenfassungsdokument:

  • Bietet Kernpunkte der Abschnitte 5-8
  • Vermeidet umfangreiche Wiederholung vollständiger Inhalte aus öffentlichen Dokumenten
  • Wahrt Professionalität und technische Genauigkeit

Vollständiges RFC-Dokument: https://www.rfc-editor.org/rfc/rfc8628 Veröffentlichungsdatum: August 2019 Standard-Track: Standards Track

Letztes Update am