Authentisierung und Verteilung von Konfigurationsfiles

Einordnung

Das Konfigurationsmanagement und die damit im Zusammenhang stehenden Probleme der Verteilung von Konfigurationsfiles und Authentisierungsinformationen stellen einen wesentlichen Anteil an der täglichen Arbeit von Systemverwaltern in Netzen dar. Zunächst soll daher eine Einordnung der Probleme in aktuelle Entwicklungen auf dem Gebiet des Einsatzes von Rechnern an vernetzten Arbeitsplätzen und der damit im Zusammenhang stehenden Aufgaben im URZ erfolgen.

Aktuelle Entwicklungen

Bezüglich des Einsatzes von Rechnern an Büroarbeitsplätzen zeichnen sich in letzter Zeit zwei grundsätzliche Alternativen ab.

Nutzer arbeiten an

einer HTTP/Java-Maschine

Nutzerdaten/Applikationen liegen am HTTP-Server
HTTP-Server organisiert eigene Fileverwaltung (Zugriffsrechte, Gruppen, ..., Backup/Restore)
Authentisierung auf Basis von kryptografischen Verfahren durch Vertrauen in "dritte Instanz"
Möglichkeiten:

jeder Server hält alle Applikationen
Nutzer verteilt seine Daten auf mehrere Server

Hoffnungen:

Möglichkeiten von HTTP und Java reichen aus
Etablierung und Durchsetzung eines Authentisierungsstandards oder wenigstens einer Schnittstelle
einfache Administrierbarkeit (Zero Administration Client)

einem Universal-Computer

Nutzerdaten/Applikationen liegen in verteiltem Filesystem
Verteiltes Filesystem organisiert Fileverwaltung (Zugriffsrechte, Gruppen, ..., Backup/Restore)
Authentisierung auf Basis von kryptografischen Verfahren durch Vertrauen in "dritte Instanz"
Möglichkeiten:

Verteilung der Nutzerdaten/Applikationen ist für den Nutzer transparent
jeder Universal-Computer ist eine (HTTP/)Java-Maschine

Hoffnungen:

Etablierung und Durchsetzung eines Authentisierungsstandards oder wenigstens einer Schnittstelle
einfache Administrierbarkeit (Single System Image)

Die dabei entstehenden Anforderungen in Bezug auf Authentisierungs- und Konfigurationprobleme unterscheiden sich also kaum.

Arbeiten/Aufgaben im URZ

Die Aufgaben der Konfigurationsverwaltung sind ein Teilgebiet des Ressource-Managements.

Die eingesetzte Lösung ist eine in mehreren Jahren gewachsene Eigenentwicklung des URZ, welche im folgenden Bild grob charakterisiert ist:

weitgehend basierend auf db++
drei Schnittstellen (für Modifikationen)

interaktiv (menügetrieben im Nutzerservice)
batch (z.B. Übernahme von Daten des Studentenamts, Setzen von Gratislimits, ...)
RPC (Annahme und Ausführung von Druck- und CD-Brennerjobs)

zahlreiche (dienstbezogene) Ausgabedaten, z.B. Ausgangsfiles für NIS-Maps
beeinflußt durch

Nutzeraktivitäten (z.B. Änderung des Paßworts)
Eingriffe der Admins (z.B. Änderung in NIS-Maps)

unvollständig (z.B. fehlende Integration der DNS-Verwaltung, UNIX-Gruppen, Accounting, ...)

Obwohl das Bild lange nicht alle Zusammenhänge wiedergeben kann, wird bereits die Komplezität sichtbar.

Im folgenden soll auf die beiden Teilgebiete Authentisierung und Verwaltung von Konfigurationsfiles näher eingegangen werden.

Authentisierung

Unter dem Begriff Authentisierung versteht man eine Methode, mit deren Hilfe ein Identitätsnachweis erbracht wird. Im Ergebnis (also bei erfolgreichem Nachweis der Identität) führt das Verfahren zur Vergabe von credentials (Berechtigungsnachweis). Als Basis von Authentisierungsmethoden werden kryptografische Verfahren eingesetzt. Da es (bisher) keine breit akzeptierten Standards für Authentisierungsmethoden gibt, legt der Service Provider das Verfahren fest. Damit sind aber viele Gefahren verbunden, da scheinbar nur wenige Service Provider in der Lage sind, kryptografisch sichere und abhörsichere Verfahren zu entwickeln.

Weiterhin hat sich die Erkenntnis durchgesetzt, daß gegenseitige Authentisierung (mutual authentication) erforderlich ist. Schließlich soll nicht nur der Service Provider über die Identität des Benutzers Klarheit besitzen, sondern auch der Benutzer möchte sicher sein, daß er es mit dem echten Service Provider zu tun hat.

Verfahren

Im folgenden werden einige der heute üblichen Verfahren kurz umrissen.

UNIX/NIS

Speicherung der Authentisierungsinformationen in lokalen Files (/etc/passwd bzw. shadow-File) und/oder NIS-Map passwd
Ablauf

getpwnam() yp_match() getpass() crypt() strcmp() [ setuid(); setgid()]

credentials: reale UID/GID's eines Prozesses
Vorteile:

langjähriger Standard
Übergang nach NIS pro System definierbar

Nachteile:

beliebig unsicher (NIS, root, ...)
Rechte werden nicht aufgrund der credentials vergeben (setuid-Probleme)
Authentisierung gegenüber einer Maschine (aufgeweicht durch rsh/rlogin, NFS, ...)
Verfügbarkeit der NIS-Server erforderlich

AFS/Kerberos

Speicherung der Authentisierungsinformationen in replizierter Datenbank (kadb)
Ablauf

[ getpwnam()
     yp_match() ]
ka_UserReadPassword()
ka_UserAuthenticateGeneral()
   ka_StringToKey()
   [ setpag() ]
   ka_GetAuthToken()  /* kaserver: TGT            */
   ka_GetServerToken()/* kaserver: Service Ticket */
   pr_SNameToId()     /* ptserver                 */
   ktc_SetToken()     /* afsd                     */

credentials: Token
Authentisierung auf Basis von "dritter Instanz" - kaserver
Vorteile:

langjähriger Standard
gegenseitige Authentisierung (mutual authentication)
abhörsicher: keine Übertragung sensibler Informationen
Grundlage: replizierte Datenbasis (ubik)
Authentisierung gegenüber einem Dienst (z.B. AFS)

Nachteile:

Integration in Software erfordert (geringen) Aufwand
Hoffnung: Erleichterung durch PAM's (Plugable Authentication Modules)
Verfügbarkeit der AFS-DB-Server erforderlich

Windows/NT

Speicherung der Authentisierungsinformationen in SAM-Database:
des_encrypt(md4(unicode(password)), well_known_des_key)
Challenge-Response:

Server: challenge: 8 Byte random data
Client: md4(unicode(password)) = 16 Byte + 5 Byte (null) = 21 Byte == 168 Bit == 3 * 56 Bit (3 DES-Keys) response= des_encrypt(challenge, key1) + des_encrypt(challenge, key2) + des_encrypt(challenge, key3)
Server:
des_decrypt(SAM-Database-Entry)= md4(unicode(password)) + 5 Byte (null) = ... == 3 * 56 Bit (3 DES-Keys) (response1, response2, response3) = split(response) challenge1 = des_decrypt(response1, key1) challenge2 = des_decrypt(response2, key2) challenge3 = des_decrypt(response3, key3) if (challenge == (challenge1 & challenge2 & challenge3)) client_is_authenticated

credentials: Sicherheits-IDs in Zugriffstoken
Vorteile:

abhörsicher: keine Übertragung sensibler Daten
Authentisierung gegenüber einem Dienst (innerhalb einer Domäne, jedoch nicht auf andere Clients übertragbar)
Grundlage: teilreplizierte Datenbasis

Nachteile:

keine gegenseitige Authentisierung
Verfügbarkeit der NT-Domain-Server erforderlich

HTTP

Speicherung der Authentisierungsinformationen in lokalem File (implementationsabhängig: apache: AuthUserFile/AuthDBMUserFile)
Randbedingung: zustandsloses Protokoll
bei jedem Request müssen Nutzerkennzeichen/Paßwort übertragen und geprüft werden
beim Zugriff auf ein geschütztes Dokument liefert der Server den Statuscode 401
Unauthorized to access the documentund die Aufforderung zur Authentisierung WWW-Authenticate
Basic Authentication (RFC1945, RFC2068)

Challenge-Response:

Server: challenge:
WWW-Authenticate: Basic realm = protection_space_identifier
Client: response:
Authorization: Basic base64(username:password)
Server: Vergleich der gelieferten Daten (eigene Nutzerverwaltung, Verfahren UNIX-like)

Vorteile:

simple Methode
keine Abhängigkeit von anderen Servern

Nachteile:

beliebig unsicher (abhöranfällig)
keine gegenseitige Authentisierung

Digest Access Authentication (RFC2069)

Challenge-Response:

Server: challenge:
WWW-Authenticate: Digest : challenge
challenge enthält mindestens:

realm = protection_space_identifier
nonce = base64(client-IP:time-stamp:private-data)dieser Wert ist für den Client bedeutungslos

Client: response:
Authorization: Digest : digest
digest enthält mindestens:

username = username
realm = protection_space_identifier
uri = request-uri
response = lhex(md5(md5(username:realm:password):nonce:md5(http-request-method:request-uri)))

Server: bildet response selbst, da in eigener Datenbasis md5(username:realm:password)gespeichert ist, und vergleicht mit response des Clients

Vorteile:

keine Übertragung sensibler Informationen

keine Abhängigkeit von anderen Servern
frei von Patent- und Exportrestriktionen
bisher keine Implementationen?

Nachteile:

keine gegenseitige Authentisierung
Datenbasis muß geheim gehalten werden

SSL (Secure Socket Layer)

Internet Draft: draft-ietf-tls-ssl-version3-00
Basisprotokoll zur Sicherung höherer Protokolle, z.B. HTTP
integriert in HTTP-Implementationen, weit verbreitet (Netscape, Microsoft, ...)
realisiert (gegenseitige) Authentisierung, verschlüsselte Datenübertragung, ...
aktuelle Implementationen benutzen Public-Key Verfahren (RSA) und Secret-Key-Verfahren (RC2, RC4)
Authentisierung auf Basis von "dritter Instanz" - CA's ( VeriSign (USA), Thawte (Republik Südafrika) - deutscher Repräsentant Easterngraphics GmbH Ilmenau)
Vorteile:

universeller Mechanismus
basierend auf Public-Key-Verfahren
keine Abhängigkeit von anderen Servern

Nachteile:

Art der Zertifizierung (Vertrauen in CA's in Browser integriert, kommerziell)
wurde/wird aufgrund der Marktbeherrschung verbreitet
Verschlüsselung des Datenstroms außerhalb der USA/Kanada nur mit 40 Bit Schlüsseln zu haben: trügerische Sicherheit

bisher ignoriert HTTP vorhandene Verfahren und die Möglichkeit, auf Authentisierungsverfahren des Server-Hosts zurückzugreifen

Es existieren zahlreiche weitere Authentisierungsverfahren (S/Key, DCE Security Service, SMB User Level Security (LanManager), Netware, PGP, SSH, ...), die aus Nutzersicht aus Kennzeichen/Paßwort-Kombinationen (der Identitätsnachweis erfolgt durch Kenntnis eines Geheimnisses) bestehen und eine Reihe von Verfahren, die sich zusätzlich auf den Besitz von Hardware (meist Chipkarte) stützen.

Fazit und Entwicklungen

Die kurze Darstellung der offensichtlich grundverschiedenen Verfahren macht es weder den Benutzern noch den Administratoren oder Entwicklern leicht. Man kann sich des Eindrucks "Viele Köche: verdorbener Brei" ... oder ... "Unsere Lösung, Ihr Problem" nicht erwehren.

Nutzersicht:

viele verschiedene Paßworte vs. ein Paßwort für alle Zwecke (wann welches Paßwort, ...)
Bewertung der Verfahren?
Lernaufwand

Administrator-Sicht:

großer Aufwand der Account-Verwaltung und Systemadministration
Vereinfachung für Benutzer schaffen durch Synchronisation der Verfahren? (z.B. ein Mechanismus zum Ändern aller Paßworte als Voraussetzung zum versteckten Authentisieren gegenüber verschiedenen Diensten)
da verschiedene Dienste eigene Authentisierung erfordern, werden Paßworte von abhörsicheren Verfahren doch im Klartext übers Netz übertragen (häufiges Mißverständnis: AFS-Authentisierung an entferntem Rechner)
neue Anforderungen: z.B. Applix AnyWare erfordert Authentisierung des Benutzers am HTTP-Server gegenüber dem Filesystem mit den Nutzerdaten

Entwickler-Sicht:

welche Verfahren in welche Vorgänge integrieren?
Umgang mit neuen Verfahren

Aber es gibt Hoffnung, die insbesondere in den Entwicklungen GSSAPI und PAM zum Ausdruck kommt.

GSSAPI (Generic Security Service Application Program Interface)

RFC1508, RFC1509
Schnittstelle für Security Funktionen
Intention: Kommunikations-Protokolle nutzen GSSAPI-Operationen, um Security-Funktionen zu integrieren (Authentisierung, Integrität, Vertraulichkeit) und erreichen so die Unabhängigkeit von Security-Mechanismen
wenige Implementationen, z.B. SESAME

PAM (Plugable Authentication Modules)

Entwicklung von SunSoft
wurde 1995 von der CDE Security Group ausgewählt als generisches Authentication Interface
OSF-RFC 86.0
Implementationen in Linux (Linux-PAM), HP-UX 10.x, Solaris 2.5 (rudimentär, unsupported), ab Solaris 2.6 verfügbar

Authentication

Authentisierungsverfahren, Erzeugen von credentials

Account Management

Erlaubnis zum Nutzen eines Dienstes
Einschränkungen, z.B. in Abhängigkeit der Uhrzeit, Anzahl bereits angemeldeter Nutzer, ...

Password Management

Ändern von Paßworten

Session Management

Beginn und Ende einer Session
Erzeugen entsprechender Log-Einträge

Realisierung:

PAM-Moduln sind Shared Libraries
Config-File legt fest, welche Applikation für welches Problem welche Module verwenden soll

Verwendung:
Beispiel: login

pam_start("login", username, &login_conv, &pam_handle);
for(retry = 0; !authenticated && retry < 3; retry++)
        pam_authenticate(pam_handle, flags);
error = pam_acct_mgmt(pam_handle, flags);
if (error == PAM_AUTHTOK_EXPIRED)
        pam_chauthtok(pam_handle, flags);
pam_open_session(pam_handle, flags);
pam_setcred(pam_handle, flags);
pam_end(pam_handle);

Vorteile:

Trennung Authentisierungsverfahren / Dienste
verminderter Aufwand für Entwickler
small is beautiful

Nachteile

geringe Verbreitung
Akzeptanz?

Zugriff auf und Verteilung von Konfigurations- / Authentisierungsinformationen

Lokale Files

Die einfachste Methode des Zugriffs auf Konfigurations- und Authentisierungsinformationen besteht sicher darin, diese Daten in lokalen Files der entsprechenden Maschinen zu halten. Das ist aber dann fragwürdig, wenn ausgehend von diesen Informationen credentials vergeben werden, welche dann von Service Providern im Netz als Identitätsnachweis akzeptiert werden sollen.

Vorteile:

schnell
netzunabhängig?

Nachteile:

aufwendiger Mechanismus zur Konsistenzhaltung erforderlich
beliebig unsicher: root

Client-Server

Sowohl für den Zugriff als auch für die Verteilung von Konfigurations- und Authentisierungsinformationen können Client-Server-Verfahren eingesetzt werden. Diese sind entweder optional zu installieren (z.B. NIS) oder zwingend erforderlich (z.B. AFS). Gemeinsam sind diesen Verfahren:

Vorteile:

konsistente Sicht aller Clients
reduzierter Management-Aufwand an Clients
potentiell sicher

Nachteile:

Abhängigkeit vom Netz, Server, ...
potentiell unsicher

NIS

Funktion: Verteilung von UNIX-Konfigurationsfiles
zweistufiges Server-Konzept

AFS

Replizierte Datenbanken enthalten Konfigurationsinformationen (kadb, ptsdb, vldb)

Alternative Ansätze zu NIS

Insbesondere NIS ist aufgrund seiner Design-Schwächen und der Tatsache mangelnder Skalierbarkeit auf Dauer nicht ausreichend. Es lohnt sich daher, über Alternativen nachzudenken.

Solche Alternativen sollten natürlich nicht nur besser skalieren und zuverlässiger funktionieren, sondern auch die Sicherheit im Netz erhöhen. Daher kommt wahrscheinlich eine Kombination aus einem Verfahren des Zugriffs auf Konfigurations- und Authentisierungsdaten mit Hilfe lokaler Files und einem Client-Server-Verfahren zur Verteilung dieser Daten in Frage.

rdist

traditioneller BSD-Mechanismus
basiert auf rsh (rdistd wird von rshd- /.rhosts-Einträge
polling-Verfahren
Übertragung der Daten im Klartext

rsync

Ersatz für rdist
ermittelt File-Differenzen und überträgt nur diese

cfengine

erfordert verteiltes Filesystem
sehr flexibel, effizient
polling-Verfahren

ssh-basierte Verfahren

Manager/Agent
rdist/rsync über ssh

Gemeinsame Probleme:

wie erfolgen Änderungen

Anschluß an Ressource-Management vs. Files

Signalisierungsverfahren - wann muß eine neue Kopie verteilt werden

pushing vs. polling
Kombination

Konsistenzsicherung bei unterbrochenen Kopiervorgängen (z.B. durch Netzprobleme, lokale Platte ist voll, ...)

Zusammenfassung/Thesen

Authentisierung

PAM-Ansatz verfolgen
Verwaltung der Authentisierungs- und Konfigurationsinformationen trennen

/etc/passwd enthält beides (verschlüsseltes Paßwort muß raus)

wenn möglich: UNIX-Authentisierung abschalten

erfordert genauere Untersuchung (wo wird sie überall benutzt, lassen sich Quellen jeweils auf PAM-API umstellen, ...)

Dieses Thema erfordert weitere Arbeiten, die sich ggf. auch in Projekt- oder Diplomarbeiten genauer untersetzen lassen.

Verteilung von Authentisierungs- und Konfigurationsinformationen

State of the Art: cfengine
Authentisierungsinformationen nicht breitstreuen, sondern in Nähe des Service Providers aufbewahren

Authentisierungsvorgänge finden selten statt
Änderungen finden relativ häufig statt und müssen sofort wirksam sein
reduziert Aufwand zur Absicherung dieser Informationen
erfordert sichere Übertragung und dabei selbst gegenseitige Authentisierung
einfacher Umgang mit Änderungen (z.B. Java/CGI-Programm, erfordert SSL-fähigen HTTP-Server)

Konfigurationsinformationen breitstreuen

Änderungen finden selten statt und müssen nicht sofort wirksam sein
werden oft benötigt (gelesen), schneller Zugriff ist wichtig
erfordert sichere Übertragung und dabei selbst gegenseitige Authentisierung

Das Problem der Verteilung von Konfigurationsinformationen wird zur Zeit in einer Diplomarbeit untersucht.

Literatur/Verweise

Windows/NT

AFS und Kerberos

AFS in Chemnitz
Müller, T.: Kerberos
Kohl, J.; Neuman, C.: The Kerberos Network Authentication Service (V5) (RFC1510)

HTTP

Berners-Lee, T.; Fielding, R.; Frystyk, H.: Hypertext Transfer Protocol -- HTTP/1.0 (RFC1945)
Fielding, R.; Gettys, J.; Mogul, J.; Frystyk, H.;Berners-Lee, T.;: Hypertext Transfer Protocol -- HTTP/1.1 (RFC2068) - auch per ftp
Franks, J.; Hallam-Baker, P.; Hostetler, J.; Leach, P.; Luotonen, A.; Sink, E.; Stewart, L.: An Extension to HTTP: Digest Access Authentication (RFC2069) - auch per ftp

Netscape: The SSL Protocol
Freier, A.O.; Karlton, P.; Kocher,P.C.: The SSL Protocol Version 3.0 - auch per ftp

GSSAPI

Linn, J.: Generic Security Service Application Program Interface (RFC1508) ftp
Wray, J.: Generic Security Service API - C bindings (RFC1509)
SESAME (Secure European System for Applications in a Multi-vendor Environment

Samar, V.; Schemers, R.: Unified Login with Plugable Authentication Modules (OSF-RFC86.0)
Linux-PAM (Plugable Authentication Modules for Linux)
Lai, C.: Making Login Services Independent of Authentication Technologies

Müller, T.: Einsatz von NIS im URZ

NIS-Alternativen

Tridgell, A.; Macherras, P.: The rsync algorithm
Burgess, M.: cfengine
Hübner, U.: Gibt es Alternativen zu NIS?

Thomas Müller, April/Mai 1997