Zum Inhalt springen

„Simple Authentication and Security Layer“ – Versionsunterschied

aus Wikipedia, der freien Enzyklopädie
[gesichtete Version][gesichtete Version]
Inhalt gelöscht Inhalt hinzugefügt
KKeine Bearbeitungszusammenfassung
K typo, form
 
(8 dazwischenliegende Versionen von 7 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
'''Simple Authentication and Security Layer''' ('''SASL''') ist ein [[Framework]], das von verschiedenen [[Netzwerkprotokoll|Protokollen]] zur [[Authentifizierung]] im [[Internet]] verwendet wird. Es wurde im Oktober 1997 als [[Request for Comments|RFC]] 2222 definiert, der im Juni 2006 durch RFC 4422 ersetzt wurde.
'''Simple Authentication and Security Layer'''&nbsp;('''SASL''') ist ein [[Framework]], das von verschiedenen [[Netzwerkprotokoll|Protokollen]] zur [[Authentifizierung]] im [[Internet]] verwendet wird. Es wurde im Oktober&nbsp;1997 als <nowiki>RFC&nbsp;2222</nowiki><ref>{{RFC-Internet |RFC=2222 |Titel=Simple Authentication and Security Layer (SASL) |Datum=1997-10 |Updated=4422}}</ref> definiert, der im Juni&nbsp;2006 durch <nowiki>RFC&nbsp;4422</nowiki><ref>{{RFC-Internet |RFC=4422 |Titel=Simple Authentication and Security Layer (SASL) |Datum=2006-10 |Obsoletes=2222}}</ref> ersetzt wurde.


SASL bietet dem Applikationsprotokoll damit eine standardisierte Möglichkeit der Aushandlung von Kommunikationsparametern. Im Regelfall wird nur eine Authentifizierungsmethode ausgehandelt, es kann aber auch vereinbart werden, dass zuerst auf ein verschlüsseltes Transportprotokoll, wie beispielsweise [[Transport Layer Security|TLS]], gewechselt wird. Die SASL-Implementierungen auf Client- und Server-Seite einigen sich auf ein Verfahren, und dieses kann dann von der Applikation transparent benutzt werden. Durch diesen Standard wird die Entwicklung sicherer Applikationsprotokolle wesentlich vereinfacht. Der Entwickler muss lediglich eine bestehende SASL-Implementierung nutzen, anstatt ein komplettes Verfahren zur Authentifizierung und Datenverschlüsselung selbst zu implementieren.
SASL bietet dem [[Anwendungssoftware|Applikations]]<nowiki></nowiki>protokoll damit eine standardisierte Möglichkeit der Aushandlung von Kommunikationsparametern. Im Regelfall wird nur eine Authentifizierungsmethode ausgehandelt, es kann aber auch vereinbart werden, dass zuerst auf ein [[verschlüsselt]]es [[Transportprotokoll]], z.&nbsp;B. auf [[Transport Layer Security|TLS]], gewechselt wird. Die SASL-[[Implementierung]]en auf [[Client]]- und [[Server]]-Seite einigen sich auf ein Verfahren, dieses kann dann von der Applikation transparent benutzt werden.


Durch diesen Standard wird die Entwicklung sicherer Applikationsprotokolle wesentlich vereinfacht: der Entwickler muss lediglich eine bestehende SASL-Implementierung nutzen, anstatt ein komplettes Verfahren zur Authentifizierung und Datenverschlüsselung selbst zu implementieren.
SASL wird unter anderem bei [[Simple Mail Transfer Protocol|SMTP]], [[Internet Message Access Protocol|IMAP]], [[Post Office Protocol|POP]]3, [[Lightweight Directory Access Protocol|LDAP]] und [[Extensible Messaging and Presence Protocol|XMPP]] benutzt.


SASL wird u.&nbsp;a. bei [[Simple Mail Transfer Protocol|SMTP]], [[Internet Message Access Protocol|IMAP]], [[Post Office Protocol|POP]]3, [[Lightweight Directory Access Protocol|LDAP]] und [[Extensible Messaging and Presence Protocol|XMPP]] benutzt.
== SASL Authentifizierungsmechanismen ==
Die standardisierten Mechanismen sind bei der [[IANA]] (siehe Weblinks) aufgelistet. Es folgt eine Aufstellung der bekanntesten Mechanismen:


== Authentifizierungsmechanismen ==
* PLAIN, alle Daten werden im Klartext ausgetauscht (hier bietet meistens [[Transport Layer Security|TLS]] die nötigen Sicherheitsmechanismen)
Unter anderem folgende standardisierte Mechanismen sind bei der [[Internet Assigned Numbers Authority|IANA]] aufgelistet (siehe Weblinks):
* [[GSSAPI]], ist selbst ein Framework, das beispielsweise [[Kerberos (Informatik)|Kerberos]] v5 anbietet
* PLAIN, alle Daten werden im [[Klartext (Kryptographie)|Klartext]] ausgetauscht (hier bietet meistens [[Transport Layer Security|TLS]] die nötigen Sicherheitsmechanismen)
* [[GSSAPI]], ist selbst ein Framework, das beispielsweise [[Kerberos (Informatik)|Kerberos]]&nbsp;v5 anbietet
* [[CRAM-MD5]], vermeidet die Übertragung des Passworts im Klartext
* [[CRAM-MD5]], vermeidet die Übertragung des Passworts im Klartext
* DIGEST-MD5, ähnlich wie CRAM-MD5, jedoch mit der Möglichkeit, zusätzliche Parameter wie Integritätssicherung auszuhandeln
* DIGEST-MD5, ähnlich wie&nbsp;CRAM-MD5, jedoch mit der Möglichkeit, zusätzliche Parameter wie [[Integrität (Informationssicherheit)|Integritäts]]<nowiki></nowiki>sicherung auszuhandeln
* [[Salted Challenge Response Authentication Mechanism|SCRAM]] (RFC 5802), ein auf modernem challenge-response-Verfahren basierender Mechanismus
* [[Salted Challenge Response Authentication Mechanism|SCRAM]] (<nowiki>RFC&nbsp;5802</nowiki><ref>{{RFC-Internet |RFC=5802 |Titel=Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms |Datum=2010-07}}</ref>), auf einer [[Challenge-Response-Authentifizierung]] basierender Mechanismus
* [[Einmalkennwort|OTP]], bietet Passwortverifizierung, ohne dass der Server das Passwort kennt
* [[Einmalkennwort]]&nbsp;(OTP), bietet Passwortverifizierung, ohne dass der Server das Passwort kennt
* ANONYMOUS, der Nutzer kann den Dienst ohne Authentifizierung nutzen
* ANONYMOUS, der Nutzer kann den Dienst [[anonym|ohne Authentifizierung]] nutzen
* EXTERNAL, die Authentifizierung erfolgt außerhalb von SASL
* EXTERNAL, die Authentifizierung erfolgt außerhalb von&nbsp;SASL.


== Literatur ==
== Literatur ==
* Roland Bless et al.: ''Sichere Netzwerkkommunikation'', Springer Verlag, 2005, ISBN 3-540-21845-9.
* Roland Bless et al.: ''Sichere Netzwerkkommunikation''. Springer Verlag, 2005, ISBN 3-540-21845-9.


== Weblinks ==
== Weblinks ==
* RFCs
* RFCs
** {{RFC-Internet |RFC=2222 |Titel=Simple Authentication and Security Layer (SASL) |Datum=1997-10 |Updated=4422}}
** RFC 2222 – Obsoleter RFC
** {{RFC-Internet |RFC=4422 |Titel=Simple Authentication and Security Layer (SASL) |Datum=2006-10 |Obsoletes=2222}}
** RFC 4422 – Aktueller RFC
* [http://www.ietf.org/html.charters/sasl-charter.html SASL Working Group]
* [https://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml SASL-Mechanismen.] iana.org
* Freie Bibliotheken
* [http://www.iana.org/assignments/sasl-mechanisms SASL-Mechanismen]
** [https://www.cyrusimap.org/ Cyrus SASL]
* Bibliotheken
** [http://www.cyrusimap.org/ Cyrus SASL] ist eine freie SASL-Bibliothek
** [https://josefsson.org/gsasl GNU SASL]
** [http://josefsson.org/gsasl GNU SASL] ist eine freie SASL-Bibliothek
** [https://doc.dovecot.org/admin_manual/sasl/ Dovecot SASL]

** [http://wiki.dovecot.org/Sasl Dovecot SASL] ist eine freie SASL-Bibliothek
== Einzelnachweise ==
<references />


[[Kategorie:Internet-Anwendungsprotokoll]]
[[Kategorie:Internet-Anwendungsprotokoll]]

Aktuelle Version vom 14. September 2024, 17:22 Uhr

Simple Authentication and Security Layer (SASL) ist ein Framework, das von verschiedenen Protokollen zur Authentifizierung im Internet verwendet wird. Es wurde im Oktober 1997 als RFC 2222[1] definiert, der im Juni 2006 durch RFC 4422[2] ersetzt wurde.

SASL bietet dem Applikationsprotokoll damit eine standardisierte Möglichkeit der Aushandlung von Kommunikationsparametern. Im Regelfall wird nur eine Authentifizierungsmethode ausgehandelt, es kann aber auch vereinbart werden, dass zuerst auf ein verschlüsseltes Transportprotokoll, z. B. auf TLS, gewechselt wird. Die SASL-Implementierungen auf Client- und Server-Seite einigen sich auf ein Verfahren, dieses kann dann von der Applikation transparent benutzt werden.

Durch diesen Standard wird die Entwicklung sicherer Applikationsprotokolle wesentlich vereinfacht: der Entwickler muss lediglich eine bestehende SASL-Implementierung nutzen, anstatt ein komplettes Verfahren zur Authentifizierung und Datenverschlüsselung selbst zu implementieren.

SASL wird u. a. bei SMTP, IMAP, POP3, LDAP und XMPP benutzt.

Authentifizierungsmechanismen

[Bearbeiten | Quelltext bearbeiten]

Unter anderem folgende standardisierte Mechanismen sind bei der IANA aufgelistet (siehe Weblinks):

  • PLAIN, alle Daten werden im Klartext ausgetauscht (hier bietet meistens TLS die nötigen Sicherheitsmechanismen)
  • GSSAPI, ist selbst ein Framework, das beispielsweise Kerberos v5 anbietet
  • CRAM-MD5, vermeidet die Übertragung des Passworts im Klartext
  • DIGEST-MD5, ähnlich wie CRAM-MD5, jedoch mit der Möglichkeit, zusätzliche Parameter wie Integritätssicherung auszuhandeln
  • SCRAM (RFC 5802[3]), auf einer Challenge-Response-Authentifizierung basierender Mechanismus
  • Einmalkennwort (OTP), bietet Passwortverifizierung, ohne dass der Server das Passwort kennt
  • ANONYMOUS, der Nutzer kann den Dienst ohne Authentifizierung nutzen
  • EXTERNAL, die Authentifizierung erfolgt außerhalb von SASL.
  • Roland Bless et al.: Sichere Netzwerkkommunikation. Springer Verlag, 2005, ISBN 3-540-21845-9.
  • RFCs
    • RFC: 2222 – Simple Authentication and Security Layer (SASL). Oktober 1997 (aktualisiert durch RFC 4422, englisch).
    • RFC: 4422 – Simple Authentication and Security Layer (SASL). Oktober 2006 (löst RFC 2222 ab, englisch).
  • SASL-Mechanismen. iana.org
  • Freie Bibliotheken

Einzelnachweise

[Bearbeiten | Quelltext bearbeiten]
  1. RFC: 2222 – Simple Authentication and Security Layer (SASL). Oktober 1997 (aktualisiert durch RFC 4422, englisch).
  2. RFC: 4422 – Simple Authentication and Security Layer (SASL). Oktober 2006 (löst RFC 2222 ab, englisch).
  3. RFC: 5802 – Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms. Juli 2010 (englisch).