9. AUTHENTISIERUNGSProtokolle

Wie vorher angegeben, Authentisierungsparameter sind undurchlässig offen, aber zum Rest des RPC-Protokolls. Dieser Abschnitt definiert zwei Standard"Aromen" der Authentisierung. Implementors sind frei, neue Authentisierungsarten, mit den gleichen Richtlinien der Aromazahlanweisung zu erfinden, die dort für Programmzahlanweisung ist. Des "Aroma" einer Bescheinigung oder des Verifier bezieht sich den auf Wert "Aroma" Feldes in der opaque_authstruktur. Würzen Sie Zahlen, wie RPC-Programmzahlen, werden ausgeübt auch zentral, und Entwickler können neue Aromazahlen zuweisen, indem sie durch elektronische Post auf "rpc@sun.com" zutreffen.

Bescheinigungen und Verifiers werden als undurchlässige Daten der variablen Länge dargestellt (das "Körper" Feld in der opaque_authstruktur). In diesem Dokument werden zwei Aromen der Authentisierung beschrieben. Von diesen ist die ungültige Authentisierung (beschrieben im folgenden Unterabschnitt) vorgeschrieben - sie muß in allen Implementierungen vorhanden sein. Systemauthentisierung wird im Anhang A. It wird empfohlen stark beschrieben, daß implementors Systemauthentisierung in ihren Implementierungen umfassen.

Viele Anwendungen verwenden diese Art der Authentisierung, und Verwendbarkeit dieses Aromas in einer Implementierung erhöht Interoperabilität. 9,1 Ungültige Anrufe der Authentisierung häufig müssen gebildet werden, wo der Klient sich nicht für seine Identität interessiert, oder der Bediener sich nicht interessiert, wem der Klient ist. In diesem Fall ist das Aroma der der Bescheinigung RPC-Anzeige, des Verifier und des Antwortverifier "AUTH_NONE". Die undurchlässigen Daten, die mit "AUTH_NONE" dazugehörig sind, sind unbestimmt. Es wird empfohlen, daß die Länge der undurchlässigen Daten null ist.

10. SATZ MARKIERUNGSCStandard

Wenn RPC-Anzeigen auf ein Bytestrom-Transportprotokoll geführt werden (wie TCP), ist es notwendig, eine Anzeige von anderen abzugrenzen, um von Protokollstörungen zu ermitteln und vielleicht zu erholen. Dieses wird Rekordmarkierung (RM) genannt. Passen mit einen RPC-Anzeigen in eine RM-Aufzeichnung. Eine Aufzeichnung besteht aus einer oder mehr Aufzeichnungsfragmente.

Ein Rekordfragment ist eine four-byte Überschrift, die von 0 zu gefolgt wird (2**31) - Bytes 1 von Fragmentdaten. Die Bytes kodieren eine nicht unterzeichnete Binärzahl; wie mit XDR-Ganzzahlen, ist der Byteauftrag von stark nach am niedrigsten. Die Zahl kodiert zwei Werte -- ein Boolesches, das anzeigt, ob das Fragment das letzte Fragment der Aufzeichnung (Spitzenwert 1 deutet das Fragment ist das letzte Fragment) an und des nicht unterzeichneten binären Wertes 31-bit ist, der die Länge in den Bytes der Daten des Fragments ist. Der Boolesche Wert ist die höchste Bitstelle der Überschrift; die Länge ist die 31 niederwertigen Spitzen. (Anmerkung, daß diese Rekordspezifikation NICHT in der XDR-Standardform! ist),

11. DIE RPC-SPRACHE

gerade da es eine Notwendigkeit gab, die XDR-Daten-Arten in einer formalen Sprache zu beschreiben, dort ist auch Notwendigkeit, die Verfahren zu beschreiben, die an diese XDR-Daten-Arten in einer formalen Sprache außerdem laufen lassen. Die RPC-Sprache ist eine Verlängerung zur XDR-Sprache, mit der Hinzufügung "Programm", "Verfahren der" und "Versions" Erklärungen. Das folgende Beispiel wird verwendet, um das Wesentliche der Sprache zu beschreiben.

11,1 Ein Beispielservice

Der in der RPC-Sprache hier beschrieben wird, ist ein Beispiel der Spezifikation eines einfachen Pingprogramms. Programm PING_PROG {/* * neuestes und größtes Versions*/Version PING_VERS_PINGBACK { leeres PINGPROC_NULL(void) = 0; * Ping der Klient, zurückbringen die Rundreisezeit * (in den Mikrosekunden). Bringt -1 wenn Zeit Betrieb zurück *, der heraus festgesetzt wird. */internes PINGPROC_PINGBACK(void) = 1; } = 2; * ursprüngliches Versions*/Version PING_VERS_ORIG { leeres PINGPROC_NULL(void) = 0; } = 1; } = 1; const PING_VERS = 2; neueste Version */die erste beschriebene Version ist PING_VERS_PINGBACK mit zwei Verfahren, PINGPROC_NULL und PINGPROC_PINGBACK. PINGPROC_NULL nimmt keine Argumente und bringt keine Resultate zurück, aber es ist für von Rundreisezeiten vom Klienten wieder berechnen zum Bediener und zur Rückseite nützlich.

Durch Versammlung sollte Verfahren 0 jedes möglichen RPC-Protokolls die gleiche Semantik haben und erfordert nie irgendeine Art Authentisierung. Das zweite Verfahren wird für den Klienten verwendet, um den Bediener zu haben tun einen Rückpingbetrieb zurück zu dem Klienten, und es bringt die Zeitmenge zurück (in den Mikrosekunden) die der Betrieb verwendete. Die folgende Version, PING_VERS_ORIG, ist die ursprüngliche Version des Protokolls und sie enthält nicht PINGPROC_PINGBACK-Verfahren. Es ist für Kompatibilität mit alten Klientenprogrammen nützlich, und da dieses Programm reift, kann sie vom Protokoll völlig fallengelassen werden.

11,2 Die RPC-Sprachspezifikation

Welche die RPC-Sprache zur XDR-Sprache identisch ist-, definierte in RFC 1014, außer der zusätzlichen Definition eines "unten beschriebenen Programms-def". Programm-def: "programmieren Sie" Bezeichner "{" Versions-defversion-def * "}" "=" Konstante ";", Version-def: "Versions" Bezeichner" { "Verfahrens-defverfahren-def *" } "" =" Konstante ";", Verfahren-def: Art-Spezifikationselementbezeichner "("Art-Spezifikationselement ("," Art-Spezifikationselement) *") "" =" Konstante ";",

11,3 Syntax

Merkt

(1) die folgenden Schlüsselwörter werden hinzugefügt und können nicht als Bezeichner verwendet werden: "Programm" und "Version";

(2) kann ein Versionsname nicht mehr innerhalb des Bereichs einer Programmdefinition als einmal auftreten. Noch kann eine Versionsnummer mehr innerhalb des Bereichs einer Programmdefinition als einmal auftreten.

(3) kann ein Verfahrensname nicht mehr innerhalb des Bereichs einer Versionsdefinition als einmal auftreten. Noch kann eine Verfahrenszahl mehr innerhalb des Bereichs der Versionsdefinition als einmal auftreten.

(4) sind Programmbezeichner im gleichen Namensraum wie konstant und schreiben Bezeichner.

(5) nur nicht unterzeichnete Konstanten können Programmen, Versionen und Verfahren zugewiesen werden.

ANHANG A:

SYSTEMCAuthentisierung, die der Klient möchte sich kennzeichnen kann z.B. wie es auf einem System UNIX(tm) gekennzeichnet wird. Das Aroma der Klientenbescheinigung ist "AUTH_SYS". Die undurchlässigen Daten, welche die Bescheinigung festsetzen, kodieren die folgende Struktur: structauthsys_parms { nicht unterzeichneter interner Stempel; Zeichenkette machinename<255 >; nicht unterzeichnetes internes uid; nicht unterzeichnetes internes gid; nicht unterzeichnetes internes gids<16 >; }; Der "Stempel" ist eine willkürliche Identifikation, die die Anrufermaschine erzeugen kann. Das "machinename" ist der Name der Maschine des Anrufers (wie "Krypton").

Das "uid" ist der effektive Benutzer Identifikation des Anrufers. Das "gid" ist die wirkungsvolle Gruppe Identifikation des Anrufers. Die "gids" ist eine gezählte Reihe Gruppen, die den Anrufer als Mitglied enthalten. Der Verifier, der die Bescheinigung begleitet, sollte "den AUTH_NONE-" Aromawert haben (oben definiert). Merken Sie diese Bescheinigung ist nur einzigartig innerhalb eines bestimmten Gebietes der Maschinennamen, -uids und -gids. Der Aromawert des Verifier, der in der Antwortanzeige vom Bediener empfangen wird, kann "AUTH_NONE" oder "AUTH_SHORT" sein. Im Fall von "AUTH_SHORT", kodieren die Bytes der Zeichenkette des Antwortverifiers eine undurchlässige Struktur. Diese neue undurchlässige Struktur kann zum Bediener anstelle von der ursprünglichen "AUTH_SYS-" Aromabescheinigung jetzt geführt werden.

Der Bediener kann einen Pufferspeicher halten, der die undurchlässigen Strukturen der Stenographie (zurück geführt über einen "AUTH_SHORT-" Art-Antwortverifier) zu den ursprünglichen Bescheinigungen des Anrufers abbildet. Der Anrufer kann Netzbandbreiten- und -bediener-CPU-Zyklen speichern, indem er die Stenographiebescheinigung verwendet. Der Bediener kann die undurchlässige Struktur der Stenographie jederzeit spülen. Wenn dieses geschieht, liegt die Remote Procedure Callanzeige an einer Authentisierungsstörung zurückgewiesenes. Der Grund für den Ausfall ist "AUTH_REJECTEDCRED".

An diesem Punkt kann der Klient möchte die ursprüngliche "AUTH_SYS-" Art der Bescheinigung versuchen. Es sollte, daß Gebrauch von diesem Aroma der Authentisierung keiner Sicherheit für die Benutzer oder die Versorger eines Services garantiert, in sich gemerkt werden. Die Authentisierung, die durch diesen Entwurf bereitgestellt wird, kann als gesetzmaßig gelten, nur wenn Anwendungen mit diesem Entwurf und dem Netz außen gesichert werden können, und privilegierte Teilnehmeradressen werden für die In Verbindung stehen End-points verwendet (ein Beispiel von diesem ist der Gebrauch der privilegierten TCP-/udptore in den Unixsystemen - merken Sie, daß nicht alle Systeme privilegierte Teilnehmeradresseeinheiten erzwingen).

HINWEISE

[ 1 ] Birrell, A. D. U. Nelson, B. J., ", RemotecVerfahren Einführend, Benennt ", XEROX Csl-83-7, Oktober 1983.

[ 2 ] Cheriton, D., "VMTP: Vielseitiges begabt AnzeigencVerhandlungcProtokoll ", Einleitende Version 0,3, StanfordcUniversität, Januar 1987.

[ 3 ] Diffie u. Hellman, "neue Richtungen in Cryptography", IEEEVERHANDLUNGEN auf Informationstheorie It-22, November 1976.

[ 4 ] Mühlen, D., "Network Time Protocol", RFC 1305, UDEL, März 1992.

[ 5 ] Nationales Büro von Standards, "Datenverschlüsselungstandard", Bundesinformationsverarbeitung-Standardpublikation 46, Januar 1977.

[ 6 ] Postel, J., "Transmission Control Protocol - DARPACInternet-ProgrammcProtokollcSpezifikation", Std 7, RFC 793, USC-/InformationcWissenschaften Institut, September 1981.

[ 7 ] Postel, J., "User Datagram Protocol", Std 6, RFC 768, USC-/InformationcWissenschaften Institut, August 1980.

[ 8 ] Reynolds, J. und Postel, J., "wiesen Zahlen", STD 2, RFC 1700, USC-/Informationwissenschaften Institut, Oktober 1994 zu.

[ 9 ] Srinivasan, R., "XDR: Externer InformationsdarstellungscStandard ", RFC 1832, Sun Microsystems, Inc., August 1995.

[ 10 ] Miller, S., Neuman, C., Schiller, J. und J. Saltzer, "Abschnitt E.2.1: Kerberos-Authentisierung und Ermächtigungssystem ", M.I.T. Projekt Athena, Cambridge, Massachusetts, Dezember 21, 1987.

[ 11 ] Steiner, J., Neuman, C. und J. Schiller, "Kerberos: Ein Authentisierungsservice für geöffnete Netzsysteme ", pp. 191-202 in den Konferenzverfahren Usenix, Dallas, Texas, Februar 1988.

[ 12 ] Kohl, J. und C. Neuman, "der Kerberos-Netz-Authentisierungsservice (V5)", RFC 1510, Digital Equipment Corporation, USC-/Informationwissenschaften Institut, September 1993. Sicherheitsbetrachtungs-Wertpapieremissionen werden nicht in diesem Protokoll besprochen. AdressenRaj Srinivasan Des Autors Sonne Microsystems, Inc.. Mountain View, CA Der Allee M/S Mtv-5-40 Garcia der ONC-Technologien 2550 94043 USA Telefon: 415-336-2478 Telefax: 415-336-6015 email: raj@eng.sun.com