93 docs getaggt mit "rfc"

Überblick über TLS-Autorisierungserweiterungen und deren Verwendungsszenarien.

1.1 Überblick und Begründung

Die Verwaltung verteilter serieller Leitungen und Modem-Pools (modem pools) für sehr viele Nutzer kann einen erheblichen administrativen Aufwand erzeugen. Modem-Pools sind definitionsgemäß eine Verbindung in die Außenwelt; sie erfordern daher sorgfältige Beachtung von Sicherheit (Security), Autorisierung (Authorization) und Accounting (Abrechnung). Am besten lässt sich dies erreichen, indem eine einzige „Datenbank" von Nutzern verwaltet wird, die sowohl Authentifizierung (Authentication) (Überprüfung von Benutzername und Passwort) als auch Konfigurationsinformationen bereitstellt, die die Art der dem Nutzer bereitzustellenden Dienste beschreiben (zum Beispiel SLIP, PPP, Telnet, rlogin).

1. Introduction (Einführung)

RADIUS und RADIUS Accounting wurden ursprünglich von Steve Willens von Livingston Enterprises für deren PortMaster-Serie von Network Access Servern entwickelt.

10.1 Overall Assessment

Die RADIUS-Arbeitsgruppe (RADIUS working group) kann über den derzeitigen Chair erreicht werden:

11.1 Normative Referenzen (Normative References)

Fragen zu diesem Memo können auch gerichtet werden an:

12.1 Algorithmusbeitrag (Algorithm Contribution)

13.1 Arnt Gulbrandsen

Copyright (C) The Internet Society (2000). Alle Rechte vorbehalten.

(Englischer Inhalt aus RFC-Quelle)

Spezifikation der client_authz- und server_authz-Erweiterungstypen und deren Verwendung im TLS-Handshake.

2.1 Grundformat

Wenn ein Client für die Verwendung von RADIUS Accounting konfiguriert ist, erzeugt er zu Beginn der Dienstbereitstellung ein Accounting-Start-Paket (Accounting Start packet), das die Art des bereitgestellten Dienstes und den Nutzer beschreibt, dem der Dienst bereitgestellt wird, und sendet es an den RADIUS-Accounting-Server, der eine Bestätigung zurücksendet, dass das Paket empfangen wurde. Am Ende der Dienstbereitstellung erzeugt der Client ein Accounting-Stop-Paket (Accounting Stop packet), das die Art des gelieferten Dienstes und optional Statistiken wie verstrichene Zeit, ein- und ausgehende Oktette oder ein- und ausgehende Pakete beschreibt. Er sendet es an den RADIUS-Accounting-Server, der eine Bestätigung zurücksendet, dass das Paket empfangen wurde.

Detaillierte Spezifikation von Autorisierungsdatenformaten einschließlich X.509-Attributzertifikaten und SAML-Assertions.

Genau ein RADIUS-Accounting-Paket wird im UDP-Datenfeld (UDP Data field) gekapselt [4], wobei das UDP-Zielfeld (UDP Destination Port field) den Wert 1813 (dezimal) angibt.

3.1 Kompatibilitätsüberlegungen

4.1 Entwurfsbeschränkungen

Fehlerwarncodes für Fehler bei der Verarbeitung von Autorisierungsinformationen.

Der RADIUS-Pakettyp wird durch das Code-Feld im ersten Oktett des Pakets bestimmt.

RADIUS-Attribute tragen die spezifischen Authentifizierungs-, Autorisierungs- und Accounting-Details für Anfrage und Antwort.

5.1 Traditionelle Port-Auflösung

IANA-Registrierungszuweisungen für TLS-Autorisierungserweiterungen und Datenformate.

Die in diesem Dokument definierten Packet Type Codes (Pakettyp-Codes), Attribute Types (Attributtypen) und Attribute Values (Attributwerte) werden von der Internet Assigned Numbers Authority (IANA, Internet-Adressverwaltung) aus den RADIUS-Namensräumen registriert, wie im Abschnitt „IANA Considerations" von RFC 2865 [2] beschrieben, in Übereinstimmung mit BCP 26 [8].

6.1 Client-Verarbeitungsverfahren

Sicherheitsüberlegungen für TLS-Autorisierungserweiterungen einschließlich Double-Handshake-Technik und Bearer-Assertion-Schutz.

Danksagung an die Mitwirkenden von RFC 5878.

7.1 Beispielbeschreibung

Sicherheitsaspekte werden in den Abschnitten zum Authenticator in Accounting-Anfragen und -antworten erörtert, unter Verwendung eines Shared Secret, das niemals über das Netzwerk gesendet wird.

- US-ASCII wurde durch UTF-8 ersetzt.

8.1 RR-Typ-Zuweisung

Normative und informative Referenzen für RFC 5878.

9.1 Dokumentstatus

1. Rigney, C., „RADIUS Accounting", RFC 2139, April 1997.

Kontaktinformationen der Autoren von RFC 5878.

RFC 1157 definiert das Simple Network Management Protocol (SNMP) Version 1, das zur Überwachung und Verwaltung von Netzwerkgeräten verwendet wird. Es bietet Get-, Set- und Trap-Operationen zum Abfragen und Ändern des Gerätestatus. Es ist das grundlegende Protokoll für das Netzwerkmanagement und wird weithin in Routern, Switches, Servern und anderen Geräten eingesetzt.

Spezifikation, Implementierung und Analyse

- Status: Best Current Practice

RFC 2616 ist die klassische HTTP/1.1-Spezifikation von 1999, die das Web über ein Jahrzehnt dominierte. Obwohl durch die RFC 7230-7235-Serie ersetzt, bleibt es das klassischste Dokument zum Verständnis von HTTP.

- Status: Informational

Nachrichtenverarbeitung und -verteilung für das Simple Network Management Protocol (SNMP)

View-based Access Control Model (VACM) für SNMP

RFC 3629 definiert die UTF-8-Zeichenkodierung, ein Transformationsformat von ISO 10646. Sie beschreibt Kodierungsregeln, Byte-Sequenz-Syntax, Sicherheitsüberlegungen usw. Es ist ein grundlegender Standard für die moderne Internet-Textverarbeitung.

- Status: Proposed Standard

- Status: Proposed Standard

- Status: Proposed Standard

- Status: Proposed Standard

RFC 4648 definiert drei häufig verwendete Kodierungsschemata - Base16, Base32 und Base64. Es bietet detaillierte Spezifikationen der Kodierungsalgorithmen, Zeichensätze, Auffüllregeln und Sicherheitserwägungen. Wesentliche Grundlage zum Verständnis von JWT, MIME, URL-Kodierung und anderen Technologien.

Definiert einen Mechanismus, der es TLS-Servern ermöglicht, Sitzungen ohne Aufrechterhaltung von Client-spezifischen Zuständen durch verschlüsselte Sitzungstickets wieder aufzunehmen.

- Status: Draft Standard

Definiert die vier miteinander verbundenen TCP-Staukontrollalgorithmen - Slow Start, Congestion Avoidance, Fast Retransmit und Fast Recovery

- Status: Proposed Standard

Spezifiziert Autorisierungserweiterungen für das Transport Layer Security (TLS) Handshake-Protokoll zum Austausch von Autorisierungsinformationen wie Attributzertifikaten oder SAML-Assertions.

- Status: Proposed Standard

- Status: Internet Standard

- Status: Proposed Standard

Transport Layer Security (TLS) und Datagram Transport Layer Security (DTLS) Heartbeat-Erweiterung

Best Current Practice zur Abschaffung der X--Präfix-Konvention bei Anwendungsprotokollparametern

- Status: Proposed Standard

RFC 6749 definiert die vollständige Spezifikation des OAuth 2.0 Autorisierungs-Frameworks, einschließlich vier Autorisierungs-Grant-Typen - Autorisierungscode, implizit, Ressourcenbesitzer-Passwort-Anmeldeinformationen und Client-Anmeldeinformationen. Dies ist der grundlegende Standard für moderne API-Sicherheit und Authentifizierung.

- Status: Proposed Standard

- Status: Informational

- Status: Proposed Standard

- Status: Proposed Standard

RFC 7231 definiert die Semantik von HTTP/1.1-Nachrichten, wie sie durch Anfragemethoden, Anfrage-Header-Felder, Antwortstatuscodes und Antwort-Header-Felder ausgedrückt wird, zusammen mit der Nutzdaten der Nachrichten (Metadaten und Body-Inhalt) und Mechanismen zur Inhaltsverhandlung.

- Status: Proposed Standard

Dieser Abschnitt definiert die Syntax und Semantik der HTTP/1.1-Header-Felder im Zusammenhang mit der Zwischenspeicherung (Caching).

- Status: Proposed Standard

- Status: Proposed Standard

RFC 7540 definiert HTTP/2 und führt Binary Framing, Multiplexing, Server Push und Header-Kompression ein, um die Web-Performance erheblich zu verbessern.

- Status: Proposed Standard

- Status: Proposed Standard

Umfassende Definitionen von DNS-Begriffen für Implementierer, Entwickler und Betreiber

RFC 8259 definiert den maßgeblichen Syntaxstandard für das JavaScript Object Notation (JSON) Datenaustauschformat. Es ist das am weitesten verbreitete leichtgewichtige Datenformat für REST-APIs, Konfigurationsdateien und Datenspeicherung.

- Status: Proposed Standard

RFC 8555 definiert das ACME-Protokoll (Automatic Certificate Management Environment) zur Automatisierung der Beantragung, Validierung und Ausstellung von SSL/TLS-Zertifikaten. Let's Encrypt verwendet dieses Protokoll weitgehend, um kostenlose HTTPS-Zertifikate automatisch zu verwalten und die Web-Verschlüsselung erheblich zu fördern.

The OAuth 2.0 device authorization grant for Internet-connected devices that lack a browser or are input constrained

- Status: Proposed Standard

- Status: Proposed Standard

RFC 8820 bietet einen Best-Practice-Leitfaden für das URI-Design, normalisiert das URI-Strukturdesign, das Namespace-Management, Pfaddesignprinzipien usw. und ist ein wichtiges Referenzdokument für Autoren von Standardspezifikationen.

- Status: Proposed Standard

- Status: Proposed Standard

Grundlegende Informationen

- Status: Proposed Standard

- Status: Proposed Standard

RFC 8110 beschreibt die opportunistische drahtlose Verschlüsselung (OWE), einen Modus, der nicht authentifizierten Clients ermöglicht, sich mit verschlüsseltem Datenverkehr mit einem Netzwerk zu verbinden. Dieses Dokument überträgt die laufende Wartung und Weiterentwicklung des Protokolls an die IEEE 802.11-Arbeitsgruppe.

- Status: Experimental

- Status: Proposed Standard

- Status: Proposed Standard

- Status: Proposed Standard

- Status: Proposed Standard