メインコンテンツまでスキップ

5.1. Specific Compatibility Notes on ASN.1 (ASN.1に関する特定の互換性注意事項)

5.1. Specific Compatibility Notes on ASN.1 (ASN.1に関する特定の互換性注意事項)​

互換性の目的で, 実装者はKerberosにおけるASN.1の使用に関する以下の特定の注意事項に留意すべきです。これらの注意事項は, ASN.1の標準的な使用法からの逸脱を説明するものではありません。これらの注意事項の目的は, むしろ, いくつかの歴史的な癖と様々な実装の非準拠, および歴史的な曖昧さを説明することです。これらは有効なASN.1ですが, 実装中に混乱を招く可能性があります。

5.1.1. ASN.1 Distinguished Encoding Rules (ASN.1識別符号化規則)​

Kerberosプロトコルメッセージのエンコーディングは, X690で説明されているASN.1のDistinguished Encoding Rules (DER, 識別符号化規則) に従わなければなりません (SHALL)。一部の実装 (主にDCE 1.1以前に由来すると考えられる) は, より一般的なBasic Encoding Rules (BER, 基本符号化規則) を使用することが知られています。特に, これらの実装は長さの不定符号化を送信します。実装は, 後方互換性のためにそのような符号化を受け入れてもよいですが (MAY), 実装者は完全に一般的なBERのデコードは危険に満ちていることを警告されます。

5.1.2. Optional Integer Fields (オプション整数フィールド)​

一部の実装は, 省略されたオプション整数値と送信されたゼロ値を内部的に区別しません。プロトコルでこれが関連する場所には, 様々なマイクロ秒フィールド, nonce, およびシーケンス番号が含まれます。実装は, アプリケーションがこれを期待している場合, 省略されたオプション整数値をゼロ値で送信されたものとして扱うべきです (SHOULD)。

5.1.3. Empty SEQUENCE OF Types (空のSEQUENCE OF型)​

プロトコルには, メッセージがオプションメンバーとしてSEQUENCE OF型を含む場所があります。これにより, 空のSEQUENCE OF符号化を含む符号化が生成される可能性があります。Kerberosプロトコルは, 存在しないオプションのSEQUENCE OF型と存在するが空のオプションのSEQUENCE OF型を意味的に区別しません。実装は, OPTIONALとマークされた空のSEQUENCE OF符号化を送信すべきではありません (SHOULD NOT) が, それらを省略されたOPTIONAL型と同等のものとして受け入れるべきです (SHOULD)。Kerberosメッセージを説明するASN.1構文では, これらの問題のあるオプションのSEQUENCE OF型のインスタンスはコメントで示されています。

5.1.4. Unrecognized Tag Numbers (認識されないタグ番号)​

このプロトコルの将来の改訂には, 異なるAPPLICATIONクラスタグ番号を持つ新しいメッセージタイプが含まれる可能性があります。そのような改訂は, それらを理解することが知られているパーティにのみメッセージタイプを送信することによって, 古い実装を保護すべきです。例えば, 受信者が先行する要求で設定したフラグビットによる方法です。堅牢なエラー処理の観点から, 実装は, とにかく認識されないタグを持つメッセージを受信することを適切に処理し, 適切な場合はエラーメッセージを返すべきです (SHOULD)。

特に, KDCは, 不正なタグがTCPトランスポートを介して送信された場合, KRB_AP_ERR_MSG_TYPEを返すべきです (SHOULD)。KDCは, サービス拒否攻撃を回避するために, UDPトランスポートを介して未知のタグで受信されたメッセージに応答すべきではありません (SHOULD NOT)。非KDCアプリケーションの場合, Kerberos実装は通常, アプリケーションにエラーを示し, アプリケーションはアプリケーションプロトコルに基づいて適切な手順を実行します。

5.1.5. Tag Numbers Greater Than 30 (30より大きいタグ番号)​

DER ASN.1デコーダーの単純な実装は, 30より大きいASN.1タグ番号で問題が発生する可能性があります。これは, そのようなタグ番号が複数のバイトを使用してエンコードされるためです。このプロトコルの将来の改訂は, 30より大きいタグ番号を利用する可能性があり, 実装は, タグを認識しない場合, 適切な場合はエラーを適切に返す準備ができているべきです (SHOULD)。