5.1. Specific Compatibility Notes on ASN.1 (Spezifische Kompatibilitätshinweise zu ASN.1)

Zu Kompatibilitätszwecken sollten Implementierer die folgenden spezifischen Hinweise zur Verwendung von ASN.1 in Kerberos beachten. Diese Hinweise beschreiben keine Abweichungen von der Standardverwendung von ASN.1. Ihr Zweck ist vielmehr, einige historische Besonderheiten und Nichtkonformitäten verschiedener Implementierungen sowie historische Mehrdeutigkeiten zu beschreiben, die zwar gültiges ASN.1 darstellen, bei der Implementierung aber zu Verwirrung führen können.

5.1.1. ASN.1 Distinguished Encoding Rules (ASN.1 Distinguished Encoding Rules, DER)

Die Kodierung von Kerberos-Protokollnachrichten muss den Distinguished Encoding Rules (DER) von ASN.1 gemäß [X690] genügen. Einige Implementierungen (vermutlich vor allem solche, die von DCE 1.1 und früher abstammen) verwenden bekanntlich die allgemeineren Basic Encoding Rules (BER); insbesondere senden diese Implementierungen unbestimmte (indefinite) Längenkodierungen. Implementierungen DÜRFEN solche Kodierungen im Interesse der Abwärtskompatibilität akzeptieren, wobei Implementierern jedoch gewarnt wird, dass die vollständige Dekodierung allgemeinen BER mit erheblichen Risiken verbunden ist.

5.1.2. Optional Integer Fields (Optionale Integer-Felder)

Einige Implementierungen unterscheiden intern nicht zwischen einem weggelassenen optionalen Integer-Wert und einem übertragenen Wert null. Die Stellen im Protokoll, an denen dies relevant ist, umfassen verschiedene Mikrosekundenfelder, Nonces und Sequenznummern. Implementierungen SOLLTEN weggelassene optionale Integer-Werte so behandeln, als wären sie mit dem Wert null übertragen worden, wenn die Anwendung dies erwartet.

5.1.3. Empty SEQUENCE OF Types (Leere SEQUENCE-OF-Typen)

An manchen Stellen des Protokolls enthält eine Nachricht einen Typ SEQUENCE OF als optionales Mitglied. Das kann zu einer Kodierung führen, die eine leere SEQUENCE OF-Kodierung enthält. Das Kerberos-Protokoll unterscheidet semantisch nicht zwischen einem fehlenden optionalen SEQUENCE OF-Typ und einem vorhandenen optionalen, aber leeren SEQUENCE OF-Typ. Implementierungen SOLLTEN keine leeren SEQUENCE OF-Kodierungen senden, die als OPTIONAL markiert sind, SOLLTEN sie aber als gleichbedeutend mit einem weggelassenen OPTIONAL-Typ akzeptieren. In der ASN.1-Syntax, die Kerberos-Nachrichten beschreibt, sind Vorkommen dieser problematischen optionalen SEQUENCE OF-Typen mit einem Kommentar gekennzeichnet.

5.1.4. Unrecognized Tag Numbers (Nicht erkannte Tag-Nummern)

Künftige Überarbeitungen dieses Protokolls können neue Nachrichtentypen mit anderen Tag-Nummern der APPLICATION-Klasse enthalten. Solche Überarbeitungen sollten ältere Implementierungen schützen, indem sie Nachrichtentypen nur an Parteien senden, von denen bekannt ist, dass sie sie verstehen; z. B. mittels eines Flag-Bits, das der Empfänger in einer vorangehenden Anfrage setzt. Im Interesse robuster Fehlerbehandlung SOLLTEN Implementierungen den Empfang einer Nachricht mit einem nicht erkannten Tag dennoch kontrolliert behandeln und gegebenenfalls eine Fehlernachricht zurückgeben.

Insbesondere SOLLTEN KDCs KRB_AP_ERR_MSG_TYPE zurückgeben, wenn der falsche Tag über einen TCP-Transport gesendet wird. KDCs SOLLTEN nicht auf über UDP empfangene Nachrichten mit unbekanntem Tag antworten, um Denial-of-Service-Angriffe zu vermeiden. Für Nicht-KDC-Anwendungen meldet die Kerberos-Implementierung typischerweise einen Fehler an die Anwendung, die je nach Anwendungsprotokoll geeignete Schritte unternimmt.

5.1.5. Tag Numbers Greater Than 30 (Tag-Nummern größer als 30)

Eine naive Implementierung eines DER-ASN.1-Dekoders kann Probleme mit ASN.1-Tag-Nummern größer als 30 haben, weil solche Tag-Nummern mit mehr als einem Byte kodiert werden. Künftige Überarbeitungen dieses Protokolls können Tag-Nummern größer als 30 verwenden, und Implementierungen SOLLTEN vorbereitet sein, gegebenenfalls kontrolliert einen Fehler zurückzugeben, wenn sie den Tag nicht erkennen.