RFC1510 日本語訳
1510 The Kerberos Network Authentication Service (V5). J. Kohl, C.Neuman. September 1993. (Format: TXT=275395 bytes) (Obsoleted by RFC4120) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Kohl
Request for Comments: 1510 Digital Equipment Corporation
C. Neuman
ISI
September 1993
コメントを求めるワーキンググループJ.コール要求をネットワークでつないでください: 1510 DEC C.ヌーマンISI1993年9月
The Kerberos Network Authentication Service (V5)
ケルベロスネットワーク認証サービス(V5)
Status of this Memo
このMemoの状態
This RFC specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このRFCはインターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This document gives an overview and specification of Version 5 of the protocol for the Kerberos network authentication system. Version 4, described elsewhere [1,2], is presently in production use at MIT's Project Athena, and at other Internet sites.
このドキュメントはケルベロスネットワーク認証システムのためにプロトコルのバージョン5の概要と仕様を与えます。 MITのProjectアティナにおいて他のインターネット・サイトにほかの場所[1、2]で説明されたバージョン4が現在、生産使用であります。
Overview
概要
Project Athena, Athena, Athena MUSE, Discuss, Hesiod, Kerberos, Moira, and Zephyr are trademarks of the Massachusetts Institute of Technology (MIT). No commercial use of these trademarks may be made without prior written permission of MIT.
プロジェクトアティナ、アテーナー、アティナミューズ、Discuss、ヘシオドス、ケルベロス、モイラ、およびZephyrはマサチューセッツ工科大学(MIT)の商標です。 MITの書面による事前の許可なしでこれらの商標の商業用途を全くしないかもしれません。
This RFC describes the concepts and model upon which the Kerberos network authentication system is based. It also specifies Version 5 of the Kerberos protocol.
このRFCはケルベロスネットワーク認証システムが基づいている概念とモデルについて説明します。 また、それはケルベロスプロトコルのバージョン5を指定します。
The motivations, goals, assumptions, and rationale behind most design decisions are treated cursorily; for Version 4 they are fully described in the Kerberos portion of the Athena Technical Plan [1]. The protocols are under review, and are not being submitted for consideration as an Internet standard at this time. Comments are encouraged. Requests for addition to an electronic mailing list for discussion of Kerberos, kerberos@MIT.EDU, may be addressed to kerberos-request@MIT.EDU. This mailing list is gatewayed onto the Usenet as the group comp.protocols.kerberos. Requests for further information, including documents and code availability, may be sent to info-kerberos@MIT.EDU.
ほとんどのデザイン決定の後ろの動機、目標、仮定、および原理は粗略に扱われます。 バージョン4において、それらはアテーナーTechnical Plan[1]のケルベロス一部で完全に説明されます。 プロトコルはレビューであって、このとき、考慮のためにインターネット標準として提出していません。 コメントは奨励されます。 ケルベロスの議論のためのメーリング・リストへの追加を求める要求( kerberos@MIT.EDU )は kerberos-request@MIT.EDU に扱われるかもしれません。 このメーリングリストはグループcomp.protocols.kerberosとしてUsenetにgatewayedされます。 ドキュメントとコードの有用性を含む詳細に関する要求を info-kerberos@MIT.EDU に送るかもしれません。
Kohl & Neuman [Page 1] RFC 1510 Kerberos September 1993
コールとヌーマン[1ページ]のRFCの1510のケルベロスの1993年9月
Background
バックグラウンド
The Kerberos model is based in part on Needham and Schroeder's trusted third-party authentication protocol [3] and on modifications suggested by Denning and Sacco [4]. The original design and implementation of Kerberos Versions 1 through 4 was the work of two former Project Athena staff members, Steve Miller of Digital Equipment Corporation and Clifford Neuman (now at the Information Sciences Institute of the University of Southern California), along with Jerome Saltzer, Technical Director of Project Athena, and Jeffrey Schiller, MIT Campus Network Manager. Many other members of Project Athena have also contributed to the work on Kerberos. Version 4 is publicly available, and has seen wide use across the Internet.
ケルベロスモデルがニーダムに一部基づいていて、シュローダーは、第三者認証プロトコル[3]を信じて、変更のときにデニングとサッコ[4]のそばに示しました。 ケルベロスバージョン1〜4のオリジナルの設計と実装は2人の元Projectアティナ職員とDECのスティーブ・ミラーとジェロームSaltzer、Projectアテーナーの技術部長に伴うクリフォード・ヌーマン(現在、南カリフォルニア大学の情報Sciences Instituteの)とジェフリー・シラー(MITのCampus Networkマネージャ)の仕事でした。 また、Projectアテーナーの多くの他のメンバーがケルベロスに対する仕事に貢献しました。 バージョン4は、公的に利用可能であり、インターネットの向こう側に広い使用を見ました。
Version 5 (described in this document) has evolved from Version 4 based on new requirements and desires for features not available in Version 4. Details on the differences between Kerberos Versions 4 and 5 can be found in [5].
バージョン5(本書では説明されます)はバージョン4で利用可能でない特徴に関する新しい要件と願望に基づくバージョン4から発展しました。 [5]でケルベロスバージョン4と5の違いに関する詳細を見つけることができます。
Table of Contents
目次
1. Introduction ....................................... 5 1.1. Cross-Realm Operation ............................ 7 1.2. Environmental assumptions ........................ 8 1.3. Glossary of terms ................................ 9 2. Ticket flag uses and requests ...................... 12 2.1. Initial and pre-authenticated tickets ............ 12 2.2. Invalid tickets .................................. 12 2.3. Renewable tickets ................................ 12 2.4. Postdated tickets ................................ 13 2.5. Proxiable and proxy tickets ...................... 14 2.6. Forwardable tickets .............................. 15 2.7. Other KDC options ................................ 15 3. Message Exchanges .................................. 16 3.1. The Authentication Service Exchange .............. 16 3.1.1. Generation of KRB_AS_REQ message ............... 17 3.1.2. Receipt of KRB_AS_REQ message .................. 17 3.1.3. Generation of KRB_AS_REP message ............... 17 3.1.4. Generation of KRB_ERROR message ................ 19 3.1.5. Receipt of KRB_AS_REP message .................. 19 3.1.6. Receipt of KRB_ERROR message ................... 20 3.2. The Client/Server Authentication Exchange ........ 20 3.2.1. The KRB_AP_REQ message ......................... 20 3.2.2. Generation of a KRB_AP_REQ message ............. 20 3.2.3. Receipt of KRB_AP_REQ message .................. 21 3.2.4. Generation of a KRB_AP_REP message ............. 23 3.2.5. Receipt of KRB_AP_REP message .................. 23
1. 序論… 5 1.1. 交差している分野操作… 7 1.2. 環境仮定… 8 1.3. 用語の用語集… 9 2. チケット旗の用途と要求… 12 2.1. 初期の、そして、あらかじめ認証されたチケット… 12 2.2. 無効のチケット… 12 2.3. 再生可能なものチケット… 12 2.4. チケットに先日付を書きます… 13 2.5. Proxiableとプロキシチケット… 14 2.6. Forwardableチケット… 15 2.7. 他のKDCオプション… 15 3. 交換処理… 16 3.1. 認証サービス交換… 16 3.1.1. KRB_AS_REQメッセージの世代… 17 3.1.2. KRB_AS_REQメッセージの領収書… 17 3.1.3. KRB_AS_REPメッセージの世代… 17 3.1.4. KRB_ERRORメッセージの世代… 19 3.1.5. KRB_AS_REPメッセージの領収書… 19 3.1.6. KRB_ERRORメッセージの領収書… 20 3.2. クライアント/サーバー証明交換… 20 3.2.1. KRB_AP_REQメッセージ… 20 3.2.2. KRB_AP_REQメッセージの世代… 20 3.2.3. KRB_AP_REQメッセージの領収書… 21 3.2.4. KRB_AP_REPメッセージの世代… 23 3.2.5. KRB_AP_REPメッセージの領収書… 23
Kohl & Neuman [Page 2] RFC 1510 Kerberos September 1993
コールとヌーマン[2ページ]のRFCの1510のケルベロスの1993年9月
3.2.6. Using the encryption key ....................... 24 3.3. The Ticket-Granting Service (TGS) Exchange ....... 24 3.3.1. Generation of KRB_TGS_REQ message .............. 25 3.3.2. Receipt of KRB_TGS_REQ message ................. 26 3.3.3. Generation of KRB_TGS_REP message .............. 27 3.3.3.1. Encoding the transited field ................. 29 3.3.4. Receipt of KRB_TGS_REP message ................. 31 3.4. The KRB_SAFE Exchange ............................ 31 3.4.1. Generation of a KRB_SAFE message ............... 31 3.4.2. Receipt of KRB_SAFE message .................... 32 3.5. The KRB_PRIV Exchange ............................ 33 3.5.1. Generation of a KRB_PRIV message ............... 33 3.5.2. Receipt of KRB_PRIV message .................... 33 3.6. The KRB_CRED Exchange ............................ 34 3.6.1. Generation of a KRB_CRED message ............... 34 3.6.2. Receipt of KRB_CRED message .................... 34 4. The Kerberos Database .............................. 35 4.1. Database contents ................................ 35 4.2. Additional fields ................................ 36 4.3. Frequently Changing Fields ....................... 37 4.4. Site Constants ................................... 37 5. Message Specifications ............................. 38 5.1. ASN.1 Distinguished Encoding Representation ...... 38 5.2. ASN.1 Base Definitions ........................... 38 5.3. Tickets and Authenticators ....................... 42 5.3.1. Tickets ........................................ 42 5.3.2. Authenticators ................................. 47 5.4. Specifications for the AS and TGS exchanges ...... 49 5.4.1. KRB_KDC_REQ definition ......................... 49 5.4.2. KRB_KDC_REP definition ......................... 56 5.5. Client/Server (CS) message specifications ........ 58 5.5.1. KRB_AP_REQ definition .......................... 58 5.5.2. KRB_AP_REP definition .......................... 60 5.5.3. Error message reply ............................ 61 5.6. KRB_SAFE message specification ................... 61 5.6.1. KRB_SAFE definition ............................ 61 5.7. KRB_PRIV message specification ................... 62 5.7.1. KRB_PRIV definition ............................ 62 5.8. KRB_CRED message specification ................... 63 5.8.1. KRB_CRED definition ............................ 63 5.9. Error message specification ...................... 65 5.9.1. KRB_ERROR definition ........................... 66 6. Encryption and Checksum Specifications ............. 67 6.1. Encryption Specifications ........................ 68 6.2. Encryption Keys .................................. 71 6.3. Encryption Systems ............................... 71 6.3.1. The NULL Encryption System (null) .............. 71 6.3.2. DES in CBC mode with a CRC-32 checksum (descbc-crc)71
3.2.6. 暗号化キーを使用します… 24 3.3. チケットを与えるサービス(TGS)交換… 24 3.3.1. KRB_TGS_REQメッセージの世代… 25 3.3.2. KRB_TGS_REQメッセージの領収書… 26 3.3.3. KRB_TGS_REPメッセージの世代… 27 3.3.3.1. 通過している分野をコード化します… 29 3.3.4. KRB_TGS_REPメッセージの領収書… 31 3.4. KRBの_の安全な交換… 31 3.4.1. KRB_SAFEメッセージの世代… 31 3.4.2. KRB_SAFEメッセージの領収書… 32 3.5. KRB_PRIV交換… 33 3.5.1. KRB_PRIVメッセージの世代… 33 3.5.2. KRB_PRIVメッセージの領収書… 33 3.6. KRB_信用交換… 34 3.6.1. KRB_CREDメッセージの世代… 34 3.6.2. KRB_CREDメッセージの領収書… 34 4. ケルベロスデータベース… 35 4.1. データベースコンテンツ… 35 4.2. 追加分野… 36 4.3. 頻繁に職業を替えます… 37 4.4. サイト定数… 37 5. メッセージ仕様… 38 5.1. ASN.1は表現をコード化しながら、区別しました… 38 5.2. ASN.1は定義を基礎づけます… 38 5.3. チケットと固有識別文字… 42 5.3.1. チケット… 42 5.3.2. 固有識別文字… 47 5.4. ASのための仕様とTGS交換… 49 5.4.1. KRB_KDC_REQ定義… 49 5.4.2. KRB_KDC_REP定義… 56 5.5. クライアント/サーバ(CS)メッセージ仕様… 58 5.5.1. KRB_AP_REQ定義… 58 5.5.2. KRB_AP_REP定義… 60 5.5.3. エラーメッセージ回答… 61 5.6. KRB_SAFEメッセージ仕様… 61 5.6.1. KRB_SAFE定義… 61 5.7. KRB_PRIVメッセージ仕様… 62 5.7.1. KRB_PRIV定義… 62 5.8. KRB_CREDメッセージ仕様… 63 5.8.1. KRB_CRED定義… 63 5.9. エラーメッセージ仕様… 65 5.9.1. KRB_ERROR定義… 66 6. 暗号化とチェックサム仕様… 67 6.1. 暗号化仕様… 68 6.2. 暗号化キー… 71 6.3. 暗号化システム… 71 6.3.1. ヌル暗号化システム(ヌル)… 71 6.3.2. CRC-32チェックサム(descbc-crc)71があるCBCモードによるDES
Kohl & Neuman [Page 3] RFC 1510 Kerberos September 1993
コールとヌーマン[3ページ]のRFCの1510のケルベロスの1993年9月
6.3.3. DES in CBC mode with an MD4 checksum (descbc-md4) 72 6.3.4. DES in CBC mode with an MD5 checksum (descbc-md5) 72 6.4. Checksums ........................................ 74 6.4.1. The CRC-32 Checksum (crc32) .................... 74 6.4.2. The RSA MD4 Checksum (rsa-md4) ................. 75 6.4.3. RSA MD4 Cryptographic Checksum Using DES (rsa-md4-des) ......................................... 75 6.4.4. The RSA MD5 Checksum (rsa-md5) ................. 76 6.4.5. RSA MD5 Cryptographic Checksum Using DES (rsa-md5-des) ......................................... 76 6.4.6. DES cipher-block chained checksum (des-mac) 6.4.7. RSA MD4 Cryptographic Checksum Using DES alternative (rsa-md4-des-k) ........................... 77 6.4.8. DES cipher-block chained checksum alternative (des-mac-k) ........................................... 77 7. Naming Constraints ................................. 78 7.1. Realm Names ...................................... 77 7.2. Principal Names .................................. 79 7.2.1. Name of server principals ...................... 80 8. Constants and other defined values ................. 80 8.1. Host address types ............................... 80 8.2. KDC messages ..................................... 81 8.2.1. IP transport ................................... 81 8.2.2. OSI transport .................................. 82 8.2.3. Name of the TGS ................................ 82 8.3. Protocol constants and associated values ......... 82 9. Interoperability requirements ...................... 86 9.1. Specification 1 .................................. 86 9.2. Recommended KDC values ........................... 88 10. Acknowledgments ................................... 88 11. References ........................................ 89 12. Security Considerations ........................... 90 13. Authors' Addresses ................................ 90 A. Pseudo-code for protocol processing ................ 91 A.1. KRB_AS_REQ generation ............................ 91 A.2. KRB_AS_REQ verification and KRB_AS_REP generation 92 A.3. KRB_AS_REP verification .......................... 95 A.4. KRB_AS_REP and KRB_TGS_REP common checks ......... 96 A.5. KRB_TGS_REQ generation ........................... 97 A.6. KRB_TGS_REQ verification and KRB_TGS_REP generation 98 A.7. KRB_TGS_REP verification ......................... 104 A.8. Authenticator generation ......................... 104 A.9. KRB_AP_REQ generation ............................ 105 A.10. KRB_AP_REQ verification ......................... 105 A.11. KRB_AP_REP generation ........................... 106 A.12. KRB_AP_REP verification ......................... 107 A.13. KRB_SAFE generation ............................. 107 A.14. KRB_SAFE verification ........................... 108
6.3.3. MD4チェックサム(descbc-md4)72 6.3.4があるCBCモードによるDES。 MD5チェックサム(descbc-md5)72 6.4があるCBCモードによるDES。 チェックサム… 74 6.4.1. CRC-32チェックサム(crc32)… 74 6.4.2. RSA MD4チェックサム(rsa-md4)… 75 6.4.3. DES(rsa-md4-des)を使用するRSA MD4の暗号のチェックサム… 75 6.4.4. RSA MD5チェックサム(rsa-md5)… 76 6.4.5. DES(rsa-md5-des)を使用するRSA MD5の暗号のチェックサム… 76 6.4.6. DES暗号ブロックはチェックサム(des-mac)6.4.7をチェーニングしました。 RSA MD4 Cryptographic Checksum Using DES代替手段(rsa-md4-des-k)… 77 6.4.8. DES暗号ブロックはチェックサム代替手段(des-mac-k)をチェーニングしました… 77 7. 規制を命名します… 78 7.1. 分野名… 77 7.2. 主要な名前… 79 7.2.1. サーバ主体の名前… 80 8. 定数と他の定義された値… 80 8.1. アドレスタイプをホスティングしてください… 80 8.2. KDCメッセージ… 81 8.2.1. IP輸送… 81 8.2.2. OSI輸送… 82 8.2.3. TGSという名前… 82 8.3. 定数と関連値について議定書の中で述べてください… 82 9. 相互運用性要件… 86 9.1. 仕様1… 86 9.2. お勧めのKDC値… 88 10. 承認… 88 11. 参照… 89 12. セキュリティ問題… 90 13. 作者のアドレス… プロトコル処理のための90A.中間コード… 91 A.1。 _REQ世代としてのKRB_… 91 A.2。 KRB_AS_REQ検証とKRB_AS_REP世代92A.3。 KRB_AS_REP検証… 95 A.4。 KRB_AS_REPと_のREPの一般的なKRB_TGSチェック… 96 A.5。 KRB_TGS_REQ世代… 97 A.6。 KRB_TGS_REQ検証とKRB_TGS_REP世代98A.7。 KRB_TGS_REP検証… 104 A.8。 固有識別文字世代… 104 A.9。 KRB_AP_REQ世代… 105 A.10。 KRB_AP_REQ検証… 105 A.11。 KRB_AP_レップ世代… 106 A.12。 KRB_AP_REP検証… 107 A.13。 KRBの_の安全な世代… 107 A.14。 KRB_SAFE検証… 108
Kohl & Neuman [Page 4] RFC 1510 Kerberos September 1993
コールとヌーマン[4ページ]のRFCの1510のケルベロスの1993年9月
A.15. KRB_SAFE and KRB_PRIV common checks ............. 108 A.16. KRB_PRIV generation ............................. 109 A.17. KRB_PRIV verification ........................... 110 A.18. KRB_CRED generation ............................. 110 A.19. KRB_CRED verification ........................... 111 A.20. KRB_ERROR generation ............................ 112
A.15。 KRB_SAFEとKRB_PRIVの一般的なチェック… 108 A.16。 KRB_PRIV世代… 109 A.17。 KRB_PRIV検証… 110 A.18。 KRB_信用世代… 110 A.19。 KRB_CRED検証… 111 A.20。 KRB_エラー生成… 112
1. Introduction
1. 序論
Kerberos provides a means of verifying the identities of principals, (e.g., a workstation user or a network server) on an open (unprotected) network. This is accomplished without relying on authentication by the host operating system, without basing trust on host addresses, without requiring physical security of all the hosts on the network, and under the assumption that packets traveling along the network can be read, modified, and inserted at will. (Note, however, that many applications use Kerberos' functions only upon the initiation of a stream-based network connection, and assume the absence of any "hijackers" who might subvert such a connection. Such use implicitly trusts the host addresses involved.) Kerberos performs authentication under these conditions as a trusted third- party authentication service by using conventional cryptography, i.e., shared secret key. (shared secret key - Secret and private are often used interchangeably in the literature. In our usage, it takes two (or more) to share a secret, thus a shared DES key is a secret key. Something is only private when no one but its owner knows it. Thus, in public key cryptosystems, one has a public and a private key.)
ケルベロスは開いている(保護のない)ネットワークで主体のアイデンティティについて確かめる手段か、(例えば、ワークステーションユーザかネットワークサーバ)を提供します。 ホスト・オペレーティング・システムで認証に依存しないで、これは達成されます、信頼をホスト・アドレスに基礎づけないで、ネットワーク、およびネットワークに沿って移動するパケットは読んで、変更されて、自由自在に挿入できるという仮定ですべてのホストの物理的なセキュリティを必要としないで。 (しかしながら、多くのアプリケーションが単にストリームベースのネットワーク接続の開始のときにケルベロスの機能を使用することに注意してください、そして、そのような接続を打倒するかもしれないどんな「ハイジャック犯」の不在も仮定してください。 そのような使用はそれとなくアドレスがかかわったホストを信じます。) これらの条件ですなわち、従来の暗号を使用するのによる3番目の信じられたパーティー認証サービスが秘密鍵を共有したようにケルベロスは認証を実行します。 (共有された秘密鍵--秘密と兵卒は文学でしばしば互換性を持って使用されます。 私たちの用法で、秘密を共有するのに、2(さらに)を要します、その結果、共有されたDESキーは秘密鍵です。 所有者以外のだれもそれを知らないときだけ、何かが個人的です。 したがって、公開鍵暗号方式では、1つは公衆と秘密鍵を持っています。)
The authentication process proceeds as follows: A client sends a request to the authentication server (AS) requesting "credentials" for a given server. The AS responds with these credentials, encrypted in the client's key. The credentials consist of 1) a "ticket" for the server and 2) a temporary encryption key (often called a "session key"). The client transmits the ticket (which contains the client's identity and a copy of the session key, all encrypted in the server's key) to the server. The session key (now shared by the client and server) is used to authenticate the client, and may optionally be used to authenticate the server. It may also be used to encrypt further communication between the two parties or to exchange a separate sub-session key to be used to encrypt further communication.
認証過程は以下の通り続きます: クライアントは与えられたサーバのために「資格証明書」を要求する認証サーバ(AS)に要求を送ります。ASはクライアントのキーで暗号化されたこれらの資格証明書で応じます。 資格証明書はサーバと2つのものの「チケット」) 一時的な暗号化キー(しばしば「セッションキー」と呼ばれる)あたり1から)成ります。 クライアントはチケット(主要で、サーバのキーですべて暗号化されたセッションのクライアントのアイデンティティとコピーを含む)をサーバに伝えます。セッションキー(現在、クライアントとサーバによって共有される)は、クライアントを認証するのに使用されて、サーバを認証するのに任意に使用されるかもしれません。また、それは、2回のパーティーのさらなるコミュニケーションを暗号化するか、またはさらなるコミュニケーションを暗号化するのに使用されるために別々のサブセッションキーを交換するのに使用されるかもしれません。
The implementation consists of one or more authentication servers running on physically secure hosts. The authentication servers maintain a database of principals (i.e., users and servers) and their secret keys. Code libraries provide encryption and implement the Kerberos protocol. In order to add authentication to its
実装は肉体的に安全なホストで走る1つ以上の認証サーバから成ります。 認証サーバは主体(すなわち、ユーザとサーバ)とそれらの秘密鍵に関するデータベースを維持します。 コードライブラリは、暗号化を提供して、ケルベロスプロトコルを実装します。 認証を加える、それ
Kohl & Neuman [Page 5] RFC 1510 Kerberos September 1993
コールとヌーマン[5ページ]のRFCの1510のケルベロスの1993年9月
transactions, a typical network application adds one or two calls to the Kerberos library, which results in the transmission of the necessary messages to achieve authentication.
トランザクション、典型的なネットワーク応用は1か2つの呼び出しをケルベロスライブラリに追加します。(それは、認証を達成する必要なメッセージの伝達をもたらします)。
The Kerberos protocol consists of several sub-protocols (or exchanges). There are two methods by which a client can ask a Kerberos server for credentials. In the first approach, the client sends a cleartext request for a ticket for the desired server to the AS. The reply is sent encrypted in the client's secret key. Usually this request is for a ticket-granting ticket (TGT) which can later be used with the ticket-granting server (TGS). In the second method, the client sends a request to the TGS. The client sends the TGT to the TGS in the same manner as if it were contacting any other application server which requires Kerberos credentials. The reply is encrypted in the session key from the TGT.
ケルベロスプロトコルはいくつかのサブプロトコル(または、交換)から成ります。 クライアントがケルベロスサーバに資格証明書を求めることができる2つのメソッドがあります。 最初のアプローチでは、クライアントは必要なサーバのチケットを求めるcleartext要求をASに送ります。 クライアントの秘密鍵で暗号化されていた状態で回答を送ります。 通常、この要求は後でチケットを与えるサーバ(TGS)と共に使用できるチケットを与えるチケット(TGT)のためのものです。 2番目のメソッドで、クライアントは要求をTGSに送ります。 まるでそれがケルベロス資格証明書を必要とするいかなる他のアプリケーション・サーバーにも連絡しているかのようにクライアントは同じ方法でTGTをTGSに送ります。 回答はTGTから主要なセッションのときに暗号化されます。
Once obtained, credentials may be used to verify the identity of the principals in a transaction, to ensure the integrity of messages exchanged between them, or to preserve privacy of the messages. The application is free to choose whatever protection may be necessary.
一度得ます、資格証明書は、トランザクションにおける、主体のアイデンティティについて確かめるか、それらの間で交換されたメッセージの保全を確実にするか、またはメッセージのプライバシーを保存するのに使用されるかもしれません。 アプリケーションは無料でどんな必要であるかもしれない保護も選ぶことができます。
To verify the identities of the principals in a transaction, the client transmits the ticket to the server. Since the ticket is sent "in the clear" (parts of it are encrypted, but this encryption doesn't thwart replay) and might be intercepted and reused by an attacker, additional information is sent to prove that the message was originated by the principal to whom the ticket was issued. This information (called the authenticator) is encrypted in the session key, and includes a timestamp. The timestamp proves that the message was recently generated and is not a replay. Encrypting the authenticator in the session key proves that it was generated by a party possessing the session key. Since no one except the requesting principal and the server know the session key (it is never sent over the network in the clear) this guarantees the identity of the client.
トランザクションにおける、主体のアイデンティティについて確かめるために、クライアントはチケットをサーバに伝えます。チケットが攻撃者によって「明確」で送られて(それの部品は暗号化されていますが、この暗号化は再生を阻みません)、妨害されて、再利用されるかもしれないので、メッセージがチケットが発行された主体によって溯源されたと立証するために追加情報を送ります。 この情報(固有識別文字と呼ばれる)は、セッションキーで暗号化されて、タイムスタンプを含んでいます。 タイムスタンプは、メッセージが最近生成されたと立証して、再生ではありません。 セッションキーで固有識別文字を暗号化するのは、それがセッションキーを所有しているパーティーによって生成されたと立証します。 要求主体以外のだれともサーバがセッションキーを知っているので(明確のネットワークの上にそれを決して送りません)、これはクライアントのアイデンティティを保証します。
The integrity of the messages exchanged between principals can also be guaranteed using the session key (passed in the ticket and contained in the credentials). This approach provides detection of both replay attacks and message stream modification attacks. It is accomplished by generating and transmitting a collision-proof checksum (elsewhere called a hash or digest function) of the client's message, keyed with the session key. Privacy and integrity of the messages exchanged between principals can be secured by encrypting the data to be passed using the session key passed in the ticket, and contained in the credentials.
また、セッションキー(チケットの中に通過されて、資格証明書に含まれている)を使用することで主体の間で交換されたメッセージの保全を保証できます。 このアプローチは反射攻撃とメッセージストリーム変更攻撃の両方の検出を提供します。 それは、セッションキーで合わせられたクライアントのメッセージの耐衝突のチェックサム(ほかの場所では、ハッシュかダイジェスト機能と呼ばれる)を生成して、伝えることによって、達成されます。 チケットの中に渡されて、資格証明書に含まれたセッションキーを使用することで通過されるためにデータを暗号化することによって、主体の間で交換されたメッセージのプライバシーと保全を保証できます。
The authentication exchanges mentioned above require read-only access to the Kerberos database. Sometimes, however, the entries in the
前記のように認証交換はケルベロスデータベースへのリード・オンリー・アクセスを必要とします。 しかしながら、時々、中のエントリー
Kohl & Neuman [Page 6] RFC 1510 Kerberos September 1993
コールとヌーマン[6ページ]のRFCの1510のケルベロスの1993年9月
database must be modified, such as when adding new principals or changing a principal's key. This is done using a protocol between a client and a third Kerberos server, the Kerberos Administration Server (KADM). The administration protocol is not described in this document. There is also a protocol for maintaining multiple copies of the Kerberos database, but this can be considered an implementation detail and may vary to support different database technologies.
変更されていて、データベースは新しい主体を加えるか、または主体を変えるのが主要である時のようにそうしなければなりません。 これはクライアントと3番目のケルベロスサーバ、ケルベロス政権Server(KADM)の間のプロトコルを使用し終わっています。 管理プロトコルは本書では説明されません。 また、ケルベロスデータベースの複本を維持するためのプロトコルがありますが、これは、実装の詳細であると考えることができて、異なったデータベース技術をサポートするために異なるかもしれません。
1.1. Cross-Realm Operation
1.1. 交差している分野操作
The Kerberos protocol is designed to operate across organizational boundaries. A client in one organization can be authenticated to a server in another. Each organization wishing to run a Kerberos server establishes its own "realm". The name of the realm in which a client is registered is part of the client's name, and can be used by the end-service to decide whether to honor a request.
ケルベロスプロトコルは、組織境界の向こう側に作動するように設計されています。 別のもののサーバに1つの組織のクライアントを認証できます。 ケルベロスサーバを実行したがっている各組織がそれ自身の「分野」を設立します。 クライアントが登録されている分野の名前は、クライアントの名前の一部であり、要求を光栄に思うかどうか決めるのに終わりサービスで使用できます。
By establishing "inter-realm" keys, the administrators of two realms can allow a client authenticated in the local realm to use its authentication remotely (Of course, with appropriate permission the client could arrange registration of a separately-named principal in a remote realm, and engage in normal exchanges with that realm's services. However, for even small numbers of clients this becomes cumbersome, and more automatic methods as described here are necessary). The exchange of inter-realm keys (a separate key may be used for each direction) registers the ticket-granting service of each realm as a principal in the other realm. A client is then able to obtain a ticket-granting ticket for the remote realm's ticket- granting service from its local realm. When that ticket-granting ticket is used, the remote ticket-granting service uses the inter- realm key (which usually differs from its own normal TGS key) to decrypt the ticket-granting ticket, and is thus certain that it was issued by the client's own TGS. Tickets issued by the remote ticket- granting service will indicate to the end-service that the client was authenticated from another realm.
「相互分野」キーを設立することによって、2つの分野の管理者は地方の分野で認証されたクライアントに認証を離れて使用させることができます。(もちろん、適切な許可で、クライアントはリモート分野での別々に命名された元本の登録をアレンジして、その分野のサービスによる通常の交換に従事できました。 しかしながら、少ない数のクライアントに関してさえ、これは厄介になります、そして、ここで説明されるより自動であるメソッドが必要です。). 相互分野キー(別々のキーは各方向に使用されるかもしれない)の交換は元本としてもう片方の分野にそれぞれの分野のチケットを与えるサービスを登録します。 クライアントは、その時、地方の分野からサービスを承諾しながら、リモート分野のチケットのチケットを与えるチケットを得ることができます。 そのチケットを与えるチケットが使用されているとき、リモートチケットを与えるサービスは、チケットを与えるチケットを解読するのに、相互分野キー(通常、それ自身の正常なTGSキーと異なっている)を使用して、その結果、それがクライアントの自身のTGSによって発行されたのを確信しています。 サービスを承諾しながらリモートチケットによって発行されたチケットは、クライアントが別の分野から認証されたのを終わりサービスに示すでしょう。
A realm is said to communicate with another realm if the two realms share an inter-realm key, or if the local realm shares an inter-realm key with an intermediate realm that communicates with the remote realm. An authentication path is the sequence of intermediate realms that are transited in communicating from one realm to another.
2つの分野が相互分野キーを共有するか、または地方の分野がリモート分野とコミュニケートする中間的分野のために主要な相互分野を共有するなら、分野は別の分野とコミュニケートすると言われます。 認証経路は1つの分野から別の分野まで交信する際に通過される中間的分野の系列です。
Realms are typically organized hierarchically. Each realm shares a key with its parent and a different key with each child. If an inter-realm key is not directly shared by two realms, the hierarchical organization allows an authentication path to be easily constructed. If a hierarchical organization is not used, it may be necessary to consult some database in order to construct an
分野は階層的で通常組織化されます。 各分野は各子供と共に親と異なったキーとキーを共有します。 相互分野キーが2つの分野によって直接共有されないなら、階層的な組織は、認証経路が容易に構成されるのを許容します。 階層的な組織が使用されていないなら、何らかのデータベースに相談するのが必要であるかもしれない、構造物
Kohl & Neuman [Page 7] RFC 1510 Kerberos September 1993
コールとヌーマン[7ページ]のRFCの1510のケルベロスの1993年9月
authentication path between realms.
分野の間の認証経路。
Although realms are typically hierarchical, intermediate realms may be bypassed to achieve cross-realm authentication through alternate authentication paths (these might be established to make communication between two realms more efficient). It is important for the end-service to know which realms were transited when deciding how much faith to place in the authentication process. To facilitate this decision, a field in each ticket contains the names of the realms that were involved in authenticating the client.
分野が通常階層的ですが、中間的分野が代替の認証経路を通した交差している分野認証を達成するために迂回するかもしれない、(これらがそうするかもしれない、設立されて、2つの分野のコミュニケーションをより効率的にしてください、) 終わりサービスに、どのくらいの信頼を認証過程に置くかを決めるとき、どの分野が通過されたかを知るのは重要です。 この決定を容易にするために、各チケットの分野はクライアントを認証するのにかかわった分野の名前を含んでいます。
1.2. Environmental assumptions
1.2. 環境仮定
Kerberos imposes a few assumptions on the environment in which it can properly function:
ケルベロスはそれが適切に機能できる環境にいくつかの仮定を課します:
+ "Denial of service" attacks are not solved with Kerberos. There
are places in these protocols where an intruder intruder can
prevent an application from participating in the proper
authentication steps. Detection and solution of such attacks
(some of which can appear to be not-uncommon "normal" failure
modes for the system) is usually best left to the human
administrators and users.
+ 「サービスの否定」攻撃はケルベロスで解決されていません。 これらのプロトコルには場所が侵入者侵入者が、アプリケーションが適切な認証ステップに参加するのを防ぐことができるところにあります。 通常、そのような攻撃(それの或るものはシステムのための珍しくない「正常な」故障モードであるように見えることができる)の検出と解答を人間の管理者とユーザに任せるのは最も良いです。
+ Principals must keep their secret keys secret. If an intruder
somehow steals a principal's key, it will be able to masquerade
as that principal or impersonate any server to the legitimate
principal.
+ 校長はそれらの秘密鍵を秘密にしなければなりません。 侵入者がどうにか主体のキーを横取りすると、その主体のふりをするか、または正統の主体にどんなサーバもまねることができるでしょう。
+ "Password guessing" attacks are not solved by Kerberos. If a
user chooses a poor password, it is possible for an attacker to
successfully mount an offline dictionary attack by repeatedly
attempting to decrypt, with successive entries from a
dictionary, messages obtained which are encrypted under a key
derived from the user's password.
+ 「パスワード推測」攻撃はケルベロスで解決されていません。 ユーザが不十分なパスワードを選ぶなら、辞書からの連続したエントリーでユーザのパスワードから得られたキーの下で暗号化される得られたメッセージを解読するのを繰り返して試みることによって攻撃者がオフライン辞書攻撃を首尾よく仕掛けるのは、可能です。
+ Each host on the network must have a clock which is "loosely
synchronized" to the time of the other hosts; this
synchronization is used to reduce the bookkeeping needs of
application servers when they do replay detection. The degree
of "looseness" can be configured on a per-server basis. If the
clocks are synchronized over the network, the clock
synchronization protocol must itself be secured from network
attackers.
+ ネットワークの各ホストは他のホストの時間まで「緩く連動する」時計を持たなければなりません。 この同期は、検出を再演するとき、アプリケーション・サーバーの簿記の必要性を減少させるのに使用されます。 1サーバあたり1個のベースで「ゆるみ」の度合いを構成できます。 時計はネットワークの上で連動して、時計同期プロトコルは必須自体です。ネットワーク攻撃者から、機密保護されます。
+ Principal identifiers are not recycled on a short-term basis. A
typical mode of access control will use access control lists
(ACLs) to grant permissions to particular principals. If a
+ 主要な識別子は短期的ベースで再生されません。 アクセスコントロールの典型的な方法は、特定の主体に許可を与えるのに、アクセスコントロールリスト(ACLs)を使用するでしょう。 aです。
Kohl & Neuman [Page 8] RFC 1510 Kerberos September 1993
コールとヌーマン[8ページ]のRFCの1510のケルベロスの1993年9月
stale ACL entry remains for a deleted principal and the
principal identifier is reused, the new principal will inherit
rights specified in the stale ACL entry. By not re-using
principal identifiers, the danger of inadvertent access is
removed.
聞き古したACLエントリーは削除された元本のために残っています、そして、主要な識別子は再利用されます、そして、新しい主体は聞き古したACLエントリーで指定された権利を引き継ぐでしょう。 主要な識別子を再使用しないことによって、不注意なアクセスという危険を取り除きます。
1.3. Glossary of terms
1.3. 用語の用語集
Below is a list of terms used throughout this document.
以下に、このドキュメント中で使用される用語のリストがあります。
Authentication Verifying the claimed identity of a
principal.
認証Verifying、元本の要求されたアイデンティティ。
Authentication header A record containing a Ticket and an
Authenticator to be presented to a
server as part of the authentication
process.
認証過程の一部としてサーバに提示されるべきTicketとAuthenticatorを含む認証ヘッダーA記録。
Authentication path A sequence of intermediate realms transited
in the authentication process when
communicating from one realm to another.
1つの分野から別の分野まで交信するとき、中間的分野の認証経路A系列は認証過程で通過しました。
Authenticator A record containing information that can
be shown to have been recently generated
using the session key known only by the
client and server.
最近単にクライアントとサーバによって知られていたセッションキーを使用することで生成されたために示すことができる情報を含む固有識別文字A記録。
Authorization The process of determining whether a
client may use a service, which objects
the client is allowed to access, and the
type of access allowed for each.
クライアントがサービスを利用するかもしれないかどうか決定するプロセス、クライアントがどのオブジェクトにアクセスできるか、そして、およびアクセスのタイプがそれぞれ考慮した承認。
Capability A token that grants the bearer permission
to access an object or service. In
Kerberos, this might be a ticket whose
use is restricted by the contents of the
authorization data field, but which
lists no network addresses, together
with the session key necessary to use
the ticket.
オブジェクトかサービスにアクセスする運搬人許可を与える能力Aトークン。 ケルベロスで、これは使用が承認データ・フィールドのコンテンツによって制限されますが、ネットワーク・アドレスを全く記載しないチケットであるかもしれません、チケットを使用するのに必要なセッションキーと共に。
Kohl & Neuman [Page 9] RFC 1510 Kerberos September 1993
コールとヌーマン[9ページ]のRFCの1510のケルベロスの1993年9月
Ciphertext The output of an encryption function.
Encryption transforms plaintext into
ciphertext.
暗号文、暗号化機能の出力。 暗号化は平文を暗号文に変えます。
Client A process that makes use of a network
service on behalf of a user. Note that
in some cases a Server may itself be a
client of some other server (e.g., a
print server may be a client of a file
server).
ユーザを代表してネットワーク・サービスを利用するクライアントAプロセス。 aがある他のサーバのクライアントであったならいくつかの場合Serverがそうするかもしれないことにそれ自体で注意してください(例えば、プリント・サーバはファイルサーバーのクライアントであるかもしれません)。
Credentials A ticket plus the secret session key
necessary to successfully use that
ticket in an authentication exchange.
認証交換にそのチケットを首尾よく使用するのに必要な資格証明書Aチケットと非公開会議キー。
KDC Key Distribution Center, a network service
that supplies tickets and temporary
session keys; or an instance of that
service or the host on which it runs.
The KDC services both initial ticket and
ticket-granting ticket requests. The
initial ticket portion is sometimes
referred to as the Authentication Server
(or service). The ticket-granting
ticket portion is sometimes referred to
as the ticket-granting server (or service).
KDC Key Distributionセンター、チケットを供給するネットワーク・サービス、および一時的なセッションキー。 または、それが稼働するそのサービスかホストのインスタンス。 KDCサービスはともにチケットとチケットを与えるチケット要求に頭文字をつけます。 初期のチケット部分は時々Authentication Server(または、サービス)と呼ばれます。 チケットを与えるチケット部分は時々チケットを与えるサーバ(または、サービス)と呼ばれます。
Kerberos Aside from the 3-headed dog guarding
Hades, the name given to Project
Athena's authentication service, the
protocol used by that service, or the
code used to implement the authentication
service.
ハーデスを警備する3頭の犬、Projectアテーナーの認証サービスに与えられた名前、そのサービスで使用されるプロトコル、またはコードからのケルベロスAsideは以前はよく認証サービスを実装していました。
Plaintext The input to an encryption function or
the output of a decryption function.
Decryption transforms ciphertext into
plaintext.
平文、暗号化機能への入力か復号化機能の出力。 復号化は暗号文を平文に変えます。
Principal A uniquely named client or server
instance that participates in a network
communication.
主体Aは唯一ネットワークに参加するクライアントかサーバインスタンスをコミュニケーションと命名しました。
Kohl & Neuman [Page 10] RFC 1510 Kerberos September 1993
コールとヌーマン[10ページ]のRFCの1510のケルベロスの1993年9月
Principal identifier The name used to uniquely identify each
different principal.
名前が唯一それぞれの異なった主体を特定するのに使用した主要な識別子。
Seal To encipher a record containing several
fields in such a way that the fields
cannot be individually replaced without
either knowledge of the encryption key
or leaving evidence of tampering.
シールToは暗号化キーに関する知識も改ざんに関する退出証拠のどちらかなしで野原を個別に取り替えることができないような方法でいくつかの分野を含む記録を暗号化します。
Secret key An encryption key shared by a principal
and the KDC, distributed outside the
bounds of the system, with a long lifetime.
In the case of a human user's
principal, the secret key is derived
from a password.
秘密鍵An暗号化キーはシステムの領域の外で分配された元本とKDCによって長い生涯と共有されました。 人間のユーザの主体の場合では、パスワードから秘密鍵を得ます。
Server A particular Principal which provides a
resource to network clients.
ネットワーククライアントにリソースを提供するサーバAの特定のプリンシパル。
Service A resource provided to network clients;
often provided by more than one server
(for example, remote file service).
サービスAリソースはネットワーククライアントに提供されました。 1つ以上のサーバ(例えば、リモートファイルサービス)でしばしば提供しています。
Session key A temporary encryption key used between
two principals, with a lifetime limited
to the duration of a single login "session".
2つの主体の間で単一のログイン「セッション」の持続時間に制限される生涯で使用されるセッションの主要なA一時的な暗号化キー。
Sub-session key A temporary encryption key used between
two principals, selected and exchanged
by the principals using the session key,
and with a lifetime limited to the duration
of a single association.
生涯と共に主体によってセッションキーを使用することで選択されて、交換された2つの主体の間と、そして、単一の協会の持続時間に制限される使用されるサブセッションの主要なA一時的な暗号化キー。
Ticket A record that helps a client authenticate
itself to a server; it contains the
client's identity, a session key, a
timestamp, and other information, all
sealed using the server's secret key.
It only serves to authenticate a client
when presented along with a fresh
Authenticator.
クライアントがサーバにそれ自体を認証するのを助けるチケットA記録。 それはクライアントのアイデンティティ、セッションキー、タイムスタンプ、および他の情報、サーバの秘密鍵を使用することで堅く閉じられていたすべてを含んでいます。 新鮮なAuthenticatorと共に提示されると、それは、クライアントを認証するのに役立つだけです。
Kohl & Neuman [Page 11] RFC 1510 Kerberos September 1993
コールとヌーマン[11ページ]のRFCの1510のケルベロスの1993年9月
2. Ticket flag uses and requests
2. チケット旗の用途と要求
Each Kerberos ticket contains a set of flags which are used to indicate various attributes of that ticket. Most flags may be requested by a client when the ticket is obtained; some are automatically turned on and off by a Kerberos server as required. The following sections explain what the various flags mean, and gives examples of reasons to use such a flag.
それぞれのケルベロスチケットはそのチケットの様々な属性を示すのに使用される1セットの旗を含んでいます。 チケットを得るとき、クライアントはほとんどの旗を要求するかもしれません。 或るものは必要に応じて断続的にケルベロスサーバによって自動的にターンされます。 以下のセクションは、様々な旗が意味することについて説明して、そのような旗を使用する理由に関する例を出します。
2.1. Initial and pre-authenticated tickets
2.1. 初期の、そして、あらかじめ認証されたチケット
The INITIAL flag indicates that a ticket was issued using the AS protocol and not issued based on a ticket-granting ticket. Application servers that want to require the knowledge of a client's secret key (e.g., a passwordchanging program) can insist that this flag be set in any tickets they accept, and thus be assured that the client's key was recently presented to the application client.
INITIAL旗は、チケットはASプロトコルを使用することで発行されて、チケットを与えるチケットに基づいて発行されなかったのを示します。 クライアントの秘密鍵(例えば、passwordchangingプログラム)に関する知識を必要としたがっているアプリケーション・サーバーは、この旗がそれらが受け入れるどんなチケットの中にも設定されて、その結果、クライアントのキーが最近アプリケーションクライアントに贈られたことが保証されると主張できます。
The PRE-AUTHENT and HW-AUTHENT flags provide addition information about the initial authentication, regardless of whether the current ticket was issued directly (in which case INITIAL will also be set) or issued on the basis of a ticket-granting ticket (in which case the INITIAL flag is clear, but the PRE-AUTHENT and HW-AUTHENT flags are carried forward from the ticket-granting ticket).
PRE-AUTHENTとHW-AUTHENT旗は初期の認証の追加情報を提供します、当日券が直接(その場合、また、INITIALは用意ができる)産出されたか、またはチケットを与えるチケットに基づいて産出されたこと(その場合、INITIAL旗が明確ですが、PRE-AUTHENTとHW-AUTHENT旗はチケットを与えるチケットから進展します)にかかわらず。
2.2. Invalid tickets
2.2. 無効のチケット
The INVALID flag indicates that a ticket is invalid. Application servers must reject tickets which have this flag set. A postdated ticket will usually be issued in this form. Invalid tickets must be validated by the KDC before use, by presenting them to the KDC in a TGS request with the VALIDATE option specified. The KDC will only validate tickets after their starttime has passed. The validation is required so that postdated tickets which have been stolen before their starttime can be rendered permanently invalid (through a hot- list mechanism).
INVALID旗は、チケットが無効であることを示します。 アプリケーション・サーバーはこの旗を設定するチケットを拒絶しなければなりません。 通常、先日付を書かれたチケットはこのフォームで発行されるでしょう。 KDCは使用の前に無効のチケットを有効にしなければなりません、VALIDATEオプションが指定されている状態でTGS要求におけるKDCにそれらを提示することによって。 それらのstarttimeが通った後にKDCはチケットを有効にするだけでしょう。 合法化が必要であるので、それは永久にそれらのstarttimeを無効に(熱いリストメカニズムを通した)することができる前に盗まれたチケットに先日付を書きました。
2.3. Renewable tickets
2.3. 再生可能なものチケット
Applications may desire to hold tickets which can be valid for long periods of time. However, this can expose their credentials to potential theft for equally long periods, and those stolen credentials would be valid until the expiration time of the ticket(s). Simply using shortlived tickets and obtaining new ones periodically would require the client to have long-term access to its secret key, an even greater risk. Renewable tickets can be used to mitigate the consequences of theft. Renewable tickets have two "expiration times": the first is when the current instance of the
アプリケーションは、長期間の間有効である場合があるチケットを保つことを望むかもしれません。 しかしながら、これは等しく長い期間、潜在的窃盗にそれらの資格証明書を暴露することができます、そして、それらの盗まれた資格証明書はチケットの満了時間まで有効でしょう。 単にshortlivedチケットを使用して、定期的に新しいものを得るのは、クライアントが秘密鍵(同等の、より高いリスク)に長期のアクセスを持っているのを必要とするでしょう。 窃盗の結果を緩和するのに再生可能なものチケットを使用できます。 再生可能なものチケットには、2「満了時間」があります: 現在のインスタンスであるときに、最初に、あります。
Kohl & Neuman [Page 12] RFC 1510 Kerberos September 1993
コールとヌーマン[12ページ]のRFCの1510のケルベロスの1993年9月
ticket expires, and the second is the latest permissible value for an individual expiration time. An application client must periodically (i.e., before it expires) present a renewable ticket to the KDC, with the RENEW option set in the KDC request. The KDC will issue a new ticket with a new session key and a later expiration time. All other fields of the ticket are left unmodified by the renewal process. When the latest permissible expiration time arrives, the ticket expires permanently. At each renewal, the KDC may consult a hot-list to determine if the ticket had been reported stolen since its last renewal; it will refuse to renew such stolen tickets, and thus the usable lifetime of stolen tickets is reduced.
チケットは期限が切れます、そして、2番目は個々の満了時間最新の許容値です。 アプリケーションクライアントは定期的に再生可能なものチケットをKDCに贈らなければなりません(すなわち、期限が切れる前に)、KDC要求に設定されたRENEWオプションで。 KDCは新しいセッションキーと満了時間より後半がある新しいチケットを発行するでしょう。 チケットの他のすべての野原が更新プロセスによって変更されていないままにされます。 最も遅い許されている満了時間が永久に来るとき、チケットは期限が切れます。 各更新のときに、KDCはチケットが最後の更新以来盗まれた状態で報告されていたかどうか決定するためにホットリストに相談するかもしれません。 それは、そのような盗まれたチケットを取り替えるのを拒否するでしょう、そして、その結果、盗まれたチケットの使用可能な寿命は短縮されます。
The RENEWABLE flag in a ticket is normally only interpreted by the ticket-granting service (discussed below in section 3.3). It can usually be ignored by application servers. However, some particularly careful application servers may wish to disallow renewable tickets.
チケットを与えるサービス(以下では、セクション3.3で、議論する)で通常、チケットの中のRENEWABLE旗は解釈されるだけです。 通常、アプリケーション・サーバーはそれを無視できます。 しかしながら、いくつかの特に慎重なアプリケーション・サーバーが再生可能なものチケットを禁じたがっているかもしれません。
If a renewable ticket is not renewed by its expiration time, the KDC will not renew the ticket. The RENEWABLE flag is reset by default, but a client may request it be set by setting the RENEWABLE option in the KRB_AS_REQ message. If it is set, then the renew-till field in the ticket contains the time after which the ticket may not be renewed.
再生可能なものチケットが満了時間までに取り替えられないと、KDCはチケットを取り替えないでしょう。 RENEWABLE旗はデフォルトでリセットされますが、クライアントは、それがKRB_AS_REQメッセージにRENEWABLEオプションをはめ込むことによって設定されるよう要求するかもしれません。 それが設定されるなら、チケットの現金箱を取り替えている分野はチケットが取り替えられないかもしれない時を含んでいます。
2.4. Postdated tickets
2.4. 先日付を書かれたチケット
Applications may occasionally need to obtain tickets for use much later, e.g., a batch submission system would need tickets to be valid at the time the batch job is serviced. However, it is dangerous to hold valid tickets in a batch queue, since they will be on-line longer and more prone to theft. Postdated tickets provide a way to obtain these tickets from the KDC at job submission time, but to leave them "dormant" until they are activated and validated by a further request of the KDC. If a ticket theft were reported in the interim, the KDC would refuse to validate the ticket, and the thief would be foiled.
アプリケーションは、時折後で使用のチケットをたくさん得る必要があるかもしれません、例えば、バッチ・ジョブが修理されるとき、バッチ服従システムがチケットが有効である必要があるでしょう。 しかしながら、オンラインになって以来のバッチ待ち行列における有効なチケットを窃盗により長くより傾向があるように保つのは危険です。 先日付を書かれたチケットは、それらがKDCのさらなる要求で動かされて、有効にされるまでそれらを「眠っていた」状態でおくためにしかしジョブ依頼時にKDCからこれらのチケットを得る方法を提供します。 チケット窃盗がその間報告されるなら、KDCは、チケットを有効にするのを拒否するでしょうに、そして、泥棒はくじかれるでしょう。
The MAY-POSTDATE flag in a ticket is normally only interpreted by the ticket-granting service. It can be ignored by application servers. This flag must be set in a ticket-granting ticket in order to issue a postdated ticket based on the presented ticket. It is reset by default; it may be requested by a client by setting the ALLOW- POSTDATE option in the KRB_AS_REQ message. This flag does not allow a client to obtain a postdated ticket-granting ticket; postdated ticket-granting tickets can only by obtained by requesting the postdating in the KRB_AS_REQ message. The life (endtime-starttime) of a postdated ticket will be the remaining life of the ticket-
通常、チケットの中の5月-POSTDATE旗はチケットを与えるサービスで解釈されるだけです。 アプリケーション・サーバーはそれを無視できます。 提示されたチケットに基づく先日付を書かれたチケットを発行するためにチケットを与えるチケットの中にこの旗を設定しなければなりません。 それはデフォルトでリセットされます。 それは、KRB_AS_REQメッセージにALLOW- POSTDATEオプションをはめ込むことによって、クライアントによって要求されているかもしれません。 この旗で、クライアントは先日付を書かれたチケットを与えるチケットを得ることができません。 先日付を書かれたチケットを与えるチケットはKRB_AS_REQメッセージにおける得られるだけの要求するのによる先日付を書くことをそうすることができます。 先日付を書かれたチケットの寿命(endtime-starttime)はチケットの残っている寿命になるでしょう。
Kohl & Neuman [Page 13] RFC 1510 Kerberos September 1993
コールとヌーマン[13ページ]のRFCの1510のケルベロスの1993年9月
granting ticket at the time of the request, unless the RENEWABLE option is also set, in which case it can be the full life (endtime- starttime) of the ticket-granting ticket. The KDC may limit how far in the future a ticket may be postdated.
また、RENEWABLEオプションが設定されない場合要求時点でチケットを与えて、その場合、それはチケットを与えるチケットの充実した生活であるかもしれません(endtime- starttime)。 KDCは遠くに未来にチケットがどう先日付を書かれるかもしれないかを制限するかもしれません。
The POSTDATED flag indicates that a ticket has been postdated. The application server can check the authtime field in the ticket to see when the original authentication occurred. Some services may choose to reject postdated tickets, or they may only accept them within a certain period after the original authentication. When the KDC issues a POSTDATED ticket, it will also be marked as INVALID, so that the application client must present the ticket to the KDC to be validated before use.
POSTDATED旗は、チケットが先日付を書かれたのを示します。 アプリケーション・サーバーは、オリジナルの認証がいつ起こったかを確認するためにチケットのauthtime分野をチェックできます。 いくつかのサービスが、先日付を書かれたチケットを拒絶するのを選ぶかもしれませんか、またはそれらはオリジナルの認証の後に、ある期間以内にそれらを受け入れるだけであるかもしれません。 また、KDCがPOSTDATEDチケットを発行するとき、それはINVALIDとしてマークされるでしょう、アプリケーションクライアントが使用の前に有効にされるためにチケットをKDCに贈らなければならないように。
2.5. Proxiable and proxy tickets
2.5. Proxiableとプロキシチケット
At times it may be necessary for a principal to allow a service to perform an operation on its behalf. The service must be able to take on the identity of the client, but only for a particular purpose. A principal can allow a service to take on the principal's identity for a particular purpose by granting it a proxy.
時には、元本がサービスに利益に操作を実行させるのが必要であるかもしれません。 サービスはクライアントのアイデンティティ、しかし、単に特定の目的に取ることができなければなりません。 元本は、サービスに特定の目的のためにプロキシをそれに与えることによって、主体のアイデンティティを呈させることができます。
The PROXIABLE flag in a ticket is normally only interpreted by the ticket-granting service. It can be ignored by application servers. When set, this flag tells the ticket-granting server that it is OK to issue a new ticket (but not a ticket-granting ticket) with a different network address based on this ticket. This flag is set by default.
通常、チケットの中のPROXIABLE旗はチケットを与えるサービスで解釈されるだけです。 アプリケーション・サーバーはそれを無視できます。 設定されると、この旗は、このチケットに基づく異なったネットワーク・アドレスで新しいチケット(しかし、チケットを与えるチケットでない)を発行するのがOKであるとチケットを与えるサーバに言います。 この旗はデフォルトで設定されます。
This flag allows a client to pass a proxy to a server to perform a remote request on its behalf, e.g., a print service client can give the print server a proxy to access the client's files on a particular file server in order to satisfy a print request.
クライアントは利益にリモート要求を実行するためにこの旗でプロキシをサーバに通過できます、例えば、印刷サービスクライアントが印刷要求を満たすために特定のファイルサーバーのクライアントのファイルにアクセスするためにプロキシをプリント・サーバに与えることができます。
In order to complicate the use of stolen credentials, Kerberos tickets are usually valid from only those network addresses specifically included in the ticket (It is permissible to request or issue tickets with no network addresses specified, but we do not recommend it). For this reason, a client wishing to grant a proxy must request a new ticket valid for the network address of the service to be granted the proxy.
盗まれた資格証明書の使用を複雑にするために、通常、ケルベロスチケットはチケットに明確に含まれていたそれらのネットワーク・アドレスだけから有効です(それが要求するのにおいて許されているか、ネットワーク・アドレスのない問題チケットが指定しましたが、または私たちはそれを推薦しません)。 この理由で、プロキシを与えたがっているクライアントは、プロキシに与えられるようサービスのネットワーク・アドレスに、有効な新しいチケットに要求しなければなりません。
The PROXY flag is set in a ticket by the TGS when it issues a proxy ticket. Application servers may check this flag and require additional authentication from the agent presenting the proxy in order to provide an audit trail.
それがプロキシチケットを発行するとき、PROXY旗はチケットの中にTGSによって設定されます。 アプリケーション・サーバーは、監査証跡を提供するためにプロキシを紹介するエージェントから、この旗をチェックして、追加認証を必要とするかもしれません。
Kohl & Neuman [Page 14] RFC 1510 Kerberos September 1993
コールとヌーマン[14ページ]のRFCの1510のケルベロスの1993年9月
2.6. Forwardable tickets
2.6. Forwardableチケット
Authentication forwarding is an instance of the proxy case where the service is granted complete use of the client's identity. An example where it might be used is when a user logs in to a remote system and wants authentication to work from that system as if the login were local.
認証推進はクライアントのアイデンティティの完全な使用がサービスに承諾されるプロキシ事件のインスタンスです。 それが使用されるかもしれない例はユーザがリモートシステムにログインして、まるでログインが地方であるかのように認証がそのシステムから働いて欲しい時です。
The FORWARDABLE flag in a ticket is normally only interpreted by the ticket-granting service. It can be ignored by application servers. The FORWARDABLE flag has an interpretation similar to that of the PROXIABLE flag, except ticket-granting tickets may also be issued with different network addresses. This flag is reset by default, but users may request that it be set by setting the FORWARDABLE option in the AS request when they request their initial ticket-granting ticket.
通常、チケットの中のFORWARDABLE旗はチケットを与えるサービスで解釈されるだけです。 アプリケーション・サーバーはそれを無視できます。 FORWARDABLE旗は、PROXIABLE旗のものと同様の解釈を持って、また、チケットを与えるチケットを除いて、異なったネットワーク・アドレスで支給されるかもしれません。 この旗はデフォルトでリセットされますが、ユーザは、それが彼らが自分達の初期のチケットを与えるチケットを要求するときAS要求にFORWARDABLEオプションをはめ込むことによって設定されるよう要求するかもしれません。
This flag allows for authentication forwarding without requiring the user to enter a password again. If the flag is not set, then authentication forwarding is not permitted, but the same end result can still be achieved if the user engages in the AS exchange with the requested network addresses and supplies a password.
この旗は、ユーザが入る必要でない再びパスワードを転送しながら、認証を考慮します。 旗が設定されないなら、認証推進は受入れられませんが、ユーザが要求されたネットワーク・アドレスでAS交換に従事して、パスワードを提供するなら、まだ同じ結末を獲得できます。
The FORWARDED flag is set by the TGS when a client presents a ticket with the FORWARDABLE flag set and requests it be set by specifying the FORWARDED KDC option and supplying a set of addresses for the new ticket. It is also set in all tickets issued based on tickets with the FORWARDED flag set. Application servers may wish to process FORWARDED tickets differently than non-FORWARDED tickets.
FORWARDED旗は、クライアントがFORWARDABLE旗のセットでチケットを贈るとTGSによって設定されて、FORWARDED KDCオプションを指定することによって設定されて、1セットのアドレスを新しいチケットに供給しながら、それを要求します。 また、それはチケットに基づいてFORWARDED旗のセットで発行されたすべてのチケットの中に設定されます。 アプリケーション・サーバーは非FORWARDEDチケットと異なってFORWARDEDチケットを処理したがっているかもしれません。
2.7. Other KDC options
2.7. 他のKDCオプション
There are two additional options which may be set in a client's request of the KDC. The RENEWABLE-OK option indicates that the client will accept a renewable ticket if a ticket with the requested life cannot otherwise be provided. If a ticket with the requested life cannot be provided, then the KDC may issue a renewable ticket with a renew-till equal to the the requested endtime. The value of the renew-till field may still be adjusted by site-determined limits or limits imposed by the individual principal or server.
クライアントのKDCの要求に設定されるかもしれない2つの追加オプションがあります。 RENEWABLE-OKオプションは、別の方法で要求された寿命があるチケットを供給できないとクライアントが再生可能なものチケットを受け入れるのを示します。 要求された寿命があるチケットを供給できないなら、KDCは現金箱を取り替えている同輩と共に要求されたendtimeに再生可能なものチケットを発行するかもしれません。 現金箱を取り替えている分野の値はサイトで決定している限界か個々の主体かサーバによって課された限界でまだ調整されているかもしれません。
The ENC-TKT-IN-SKEY option is honored only by the ticket-granting service. It indicates that the to-be-issued ticket for the end server is to be encrypted in the session key from the additional ticket-granting ticket provided with the request. See section 3.3.3 for specific details.
ENC-TKT IN SKEYオプションは単にチケットを与えるサービスで光栄に思われます。 それは、エンドサーバの発行されたチケットが要求が提供された追加チケットを与えるチケットから主要なセッションのときに暗号化されることになっているのを示します。 特定の詳細に関してセクション3.3.3を見てください。
Kohl & Neuman [Page 15] RFC 1510 Kerberos September 1993
コールとヌーマン[15ページ]のRFCの1510のケルベロスの1993年9月
3. Message Exchanges
3. 交換処理
The following sections describe the interactions between network clients and servers and the messages involved in those exchanges.
以下のセクションはそれらの交換にかかわるネットワーククライアントの間の相互作用、サーバ、およびメッセージについて説明します。
3.1. The Authentication Service Exchange
3.1. 認証サービス交換
Summary
概要
Message direction Message type Section
1. Client to Kerberos KRB_AS_REQ 5.4.1
2. Kerberos to client KRB_AS_REP or 5.4.2
KRB_ERROR 5.9.1
メッセージ方向Messageはセクション1をタイプします。 _REQ5.4.1 2としてのケルベロスKRB_へのクライアント。 クライアントKRB_AS_REPへのケルベロスか5.4.2KRB_ERROR5.9.1
The Authentication Service (AS) Exchange between the client and the Kerberos Authentication Server is usually initiated by a client when it wishes to obtain authentication credentials for a given server but currently holds no credentials. The client's secret key is used for encryption and decryption. This exchange is typically used at the initiation of a login session, to obtain credentials for a Ticket- Granting Server, which will subsequently be used to obtain credentials for other servers (see section 3.3) without requiring further use of the client's secret key. This exchange is also used to request credentials for services which must not be mediated through the Ticket-Granting Service, but rather require a principal's secret key, such as the password-changing service. (The password- changing request must not be honored unless the requester can provide the old password (the user's current secret key). Otherwise, it would be possible for someone to walk up to an unattended session and change another user's password.) This exchange does not by itself provide any assurance of the the identity of the user. (To authenticate a user logging on to a local system, the credentials obtained in the AS exchange may first be used in a TGS exchange to obtain credentials for a local server. Those credentials must then be verified by the local server through successful completion of the Client/Server exchange.)
クライアントとケルベロスAuthentication Serverの間のAuthentication Service(AS)交換は、認証資格証明書を与えられたサーバに得たがっているとき、クライアントによって通常開始されますが、現在、資格証明書を全く開催しません。 クライアントの秘密鍵は暗号化と復号化に使用されます。 この交換は、ログインセッションの手引きで次にクライアントの秘密鍵のさらなる使用を必要としないで他のサーバ(セクション3.3を見る)に資格証明書を得るのに使用されるServerを与えながら資格証明書をTicketに得るのに通常使用されます。 また、この交換はTicketを与えているServiceを通して調停してはいけないサービスのために資格証明書を要求するのに使用されますが、むしろ主体の秘密鍵を必要としてください、パスワードを変えるサービスなどのように。 リクエスタが古いパスワード(ユーザの現在の秘密鍵)を提供できないなら、パスワード変化要求は光栄に思っているはずがありません。(さもなければ、だれかが無人のセッションまで歩いて、別のユーザのパスワードを変えるのは、可能でしょう。) この交換自体はユーザのアイデンティティのどんな保証も提供しません。 ユーザ伐採をローカルシステムに認証するなら、AS交換で得られた資格証明書は、最初に、資格証明書をローカルサーバに得るのにTGS交換に使用されるかもしれません。(次に、ローカルサーバはClient/サーバ交換の無事終了でそれらの資格証明書について確かめなければなりません。)
The exchange consists of two messages: KRB_AS_REQ from the client to Kerberos, and KRB_AS_REP or KRB_ERROR in reply. The formats for these messages are described in sections 5.4.1, 5.4.2, and 5.9.1.
交換は2つのメッセージから成ります: KRB、_回答におけるクライアントからケルベロスまでのAS_REQと、KRB_AS_REPかKRB_ERROR。 説明されたコネセクション5.4.1、5.4は、.2と、5.9です。これらのメッセージのための形式、.1。
In the request, the client sends (in cleartext) its own identity and the identity of the server for which it is requesting credentials. The response, KRB_AS_REP, contains a ticket for the client to present to the server, and a session key that will be shared by the client and the server. The session key and additional information are encrypted in the client's secret key. The KRB_AS_REP message contains information which can be used to detect replays, and to
要求では、クライアントはそれ自身のアイデンティティとそれが資格証明書を要求しているサーバのアイデンティティを送ります(cleartextで)。 応答(KRB_AS_REP)はクライアントがサーバ、およびクライアントとサーバによって共有されるセッションキーに贈るチケットを含んでいます。セッションの主要で追加している情報はクライアントの秘密鍵で暗号化されます。 そしてKRB_AS_REPメッセージが再生を検出するのに使用できる情報を含んでいる。
Kohl & Neuman [Page 16] RFC 1510 Kerberos September 1993
コールとヌーマン[16ページ]のRFCの1510のケルベロスの1993年9月
associate it with the message to which it replies. Various errors can occur; these are indicated by an error response (KRB_ERROR) instead of the KRB_AS_REP response. The error message is not encrypted. The KRB_ERROR message also contains information which can be used to associate it with the message to which it replies. The lack of encryption in the KRB_ERROR message precludes the ability to detect replays or fabrications of such messages.
それが返答するメッセージにそれを関連づけてください。 様々な誤りは発生できます。 KRB_AS_REP応答の代わりに誤り応答(KRB_ERROR)でこれらは示されます。 エラーメッセージは暗号化されていません。 また、KRB_ERRORメッセージはそれが返答するメッセージにそれを関連づけるのに使用できる情報を含んでいます。 KRB_ERRORメッセージにおける、暗号化の不足はそのようなメッセージの再生か製作を検出する能力を排除します。
In the normal case the authentication server does not know whether the client is actually the principal named in the request. It simply sends a reply without knowing or caring whether they are the same. This is acceptable because nobody but the principal whose identity was given in the request will be able to use the reply. Its critical information is encrypted in that principal's key. The initial request supports an optional field that can be used to pass additional information that might be needed for the initial exchange. This field may be used for preauthentication if desired, but the mechanism is not currently specified.
正常な場合では、認証サーバは、クライアントが実際に要求で指定された主体であるかどうかを知りません。 知っているか、またはそれらが同じであるかどうか気にかけない、それは単に返信します。 アイデンティティが要求で与えられた主体以外のだれも回答を使用できないので、これは許容できます。 重要情報はその主体のキーで暗号化されます。 初期の要求は初期の交換に必要であるかもしれない追加情報を通過するのに使用できる任意の分野をサポートします。 望まれているなら、この分野は前認証に使用されるかもしれませんが、メカニズムは現在、指定されません。
3.1.1. Generation of KRB_AS_REQ message
3.1.1. KRB_AS_REQメッセージの世代
The client may specify a number of options in the initial request. Among these options are whether preauthentication is to be performed; whether the requested ticket is to be renewable, proxiable, or forwardable; whether it should be postdated or allow postdating of derivative tickets; and whether a renewable ticket will be accepted in lieu of a non-renewable ticket if the requested ticket expiration date cannot be satisfied by a nonrenewable ticket (due to configuration constraints; see section 4). See section A.1 for pseudocode.
クライアントは初期の要求における多くのオプションを指定するかもしれません。 このうち、オプションは前認証が実行されることになっているかどうかということです。 要求されたチケットによる再生可能なものであることになっているか、そして、proxiable、または前進可能。 先日付を書かれるべきであるか、または派生しているチケットについて先日付を書くのを許容するべきであることにかかわらず。 そして、「非-再生可能なもの」チケットで要求されたチケット有効期限を満たすことができないと(構成規制のため; セクション4を見てください)、非再生可能なものチケットの代わりに再生可能なものチケットを受け入れるのであるかどうか 擬似コードに関してセクションA.1を見てください。
The client prepares the KRB_AS_REQ message and sends it to the KDC.
クライアントは、KRB_AS_REQメッセージを準備して、それをKDCに送ります。
3.1.2. Receipt of KRB_AS_REQ message
3.1.2. KRB_AS_REQメッセージの領収書
If all goes well, processing the KRB_AS_REQ message will result in the creation of a ticket for the client to present to the server. The format for the ticket is described in section 5.3.1. The contents of the ticket are determined as follows.
すべてがうまく行くと、KRB_AS_REQメッセージを処理すると、クライアントがサーバに贈るチケットの作成はもたらされるでしょう。チケットのための形式はセクション5.3.1で説明されます。 チケットの内容は以下の通り決定しています。
3.1.3. Generation of KRB_AS_REP message
3.1.3. KRB_AS_REPメッセージの世代
The authentication server looks up the client and server principals named in the KRB_AS_REQ in its database, extracting their respective keys. If required, the server pre-authenticates the request, and if the pre-authentication check fails, an error message with the code KDC_ERR_PREAUTH_FAILED is returned. If the server cannot accommodate the requested encryption type, an error message with code
クライアントとサーバ主体への認証サーバ一見はデータベースでKRBでAS_REQと_を命名しました、彼らのそれぞれのキーを抽出して。 必要なら、サーバは要求をあらかじめ認証します、そして、プレ認証チェックが失敗するなら、コードKDC_ERR_PREAUTH_FAILEDがあるエラーメッセージを返します。 サーバが要求された暗号化タイプ、コードがあるエラーメッセージに対応できないなら
Kohl & Neuman [Page 17] RFC 1510 Kerberos September 1993
コールとヌーマン[17ページ]のRFCの1510のケルベロスの1993年9月
KDC_ERR_ETYPE_NOSUPP is returned. Otherwise it generates a "random"
session key ("Random" means that, among other things, it should be
impossible to guess the next session key based on knowledge of past
session keys. This can only be achieved in a pseudo-random number
generator if it is based on cryptographic principles. It would be
more desirable to use a truly random number generator, such as one
based on measurements of random physical phenomena.).
KDC_ERR_ETYPE_NOSUPPを返します。 さもなければ、それは「無作為」のセッションキーを生成します。(「無作為」は、過去のセッションキーに関する知識に基づいて主要な次のセッションを推測するのが特に、不可能であるべきであることを意味します。 暗号の原則に基づいている場合にだけ、疑似乱数生成器でこれを達成できます。 本当に乱数発生器を使用するのは、より望ましいでしょう、無作為の物理的な現象の測定値に基づいた1などのように。).
If the requested start time is absent or indicates a time in the past, then the start time of the ticket is set to the authentication server's current time. If it indicates a time in the future, but the POSTDATED option has not been specified, then the error KDC_ERR_CANNOT_POSTDATE is returned. Otherwise the requested start time is checked against the policy of the local realm (the administrator might decide to prohibit certain types or ranges of postdated tickets), and if acceptable, the ticket's start time is set as requested and the INVALID flag is set in the new ticket. The postdated ticket must be validated before use by presenting it to the KDC after the start time has been reached.
要求された開始時刻が休むか、または過去に時間を示すなら、チケットの開始時刻は認証サーバの現在の時間に決められます。 _POSTDATEが将来POSTDATEDオプションだけが指定されていなくて、また次に、誤りKDC_ERR_がそうしない時代に返されるのを示すなら。 さもなければ、要求された開始時刻は地方の分野の方針に対してチェックされます、そして、(管理者は、あるタイプか範囲の先日付を書かれたチケットを禁止すると決めるかもしれません)許容できるなら、チケットの開始時刻は要求された通り決められます、そして、INVALID旗は新しいチケットの中に設定されます。 開始時刻の後にKDCにそれを提示するのによる使用に達する前に先日付を書かれたチケットを有効にしなければなりません。
The expiration time of the ticket will be set to the minimum of the following:
チケットの満了時間は以下の最小限に設定されるでしょう:
+The expiration time (endtime) requested in the KRB_AS_REQ
message.
+KRB_AS_REQメッセージで要求された満了時間(endtime)。
+The ticket's start time plus the maximum allowable lifetime
associated with the client principal (the authentication
server's database includes a maximum ticket lifetime field
in each principal's record; see section 4).
+ クライアント主体(認証サーバのデータベースは各主体の記録に最大のチケット生涯分野を含んでいます; セクション4を見る)に関連しているチケットの開始時刻と最大の許容できる生涯。
+The ticket's start time plus the maximum allowable lifetime
associated with the server principal.
+ サーバ主体に関連しているチケットの開始時刻と最大の許容できる生涯。
+The ticket's start time plus the maximum lifetime set by
the policy of the local realm.
+ チケットの開始時刻と最大の寿命は地方の分野の方針でセットしました。
If the requested expiration time minus the start time (as determined above) is less than a site-determined minimum lifetime, an error message with code KDC_ERR_NEVER_VALID is returned. If the requested expiration time for the ticket exceeds what was determined as above, and if the "RENEWABLE-OK" option was requested, then the "RENEWABLE" flag is set in the new ticket, and the renew-till value is set as if the "RENEWABLE" option were requested (the field and option names are described fully in section 5.4.1). If the RENEWABLE option has been requested or if the RENEWABLE-OK option has been set and a renewable ticket is to be issued, then the renew-till field is set to the minimum of:
開始時刻(上で決定するように)を引いた要求された満了時間がサイトで決定している最小の生涯以下であるなら、まさか、_VALIDが返されるコードKDC_ERR_があるエラーメッセージです。 チケットのための要求された満了時間が同じくらい上で決定したことを超えて、「RENEWABLE OK」オプションが要求されたなら、「再生可能なもの」旗は新しいチケットの中に設定されます、そして、まるで「再生可能なもの」オプションが要求されているかのように(分野とオプション名はセクション5.4.1で完全に説明されます)現金箱を取り替えている値は設定されます。 RENEWABLEオプションが要求されているか、RENEWABLE-OKオプションが設定されて、または再生可能なものチケットが発行されるつもりであるなら、現金箱を取り替えている分野は以下の最小限に設定されます。
Kohl & Neuman [Page 18] RFC 1510 Kerberos September 1993
コールとヌーマン[18ページ]のRFCの1510のケルベロスの1993年9月
+Its requested value.
+ 要求された値。
+The start time of the ticket plus the minimum of the two
maximum renewable lifetimes associated with the principals'
database entries.
+ チケットの開始時刻と主体のデータベースエントリーに関連している2つの最大の再生可能なもの生涯の最小限。
+The start time of the ticket plus the maximum renewable
lifetime set by the policy of the local realm.
+ チケットの開始時刻と地方の分野の方針で決められた最大の再生可能なもの生涯。
The flags field of the new ticket will have the following options set if they have been requested and if the policy of the local realm allows: FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE. If the new ticket is postdated (the start time is in the future), its INVALID flag will also be set.
要求されていて、地方の分野の方針が以下を許容するなら、以下のオプションがそれらであるなら新しいチケットの分野で設定する旗がありました。 FORWARDABLE、先日付を書かれて、PROXIABLE、再生可能なものに5月先日付を書いてください。 また、新しいチケットが先日付を書かれると(未来に、開始時刻があります)、INVALID旗は設定されるでしょう。
If all of the above succeed, the server formats a KRB_AS_REP message (see section 5.4.2), copying the addresses in the request into the caddr of the response, placing any required pre-authentication data into the padata of the response, and encrypts the ciphertext part in the client's key using the requested encryption method, and sends it to the client. See section A.2 for pseudocode.
上記のすべてが成功するなら、サーバは、どんな必要なプレ認証データも応答のpadataに置いて、応答のcaddrに要求におけるアドレスをコピーして、KRB_AS_REPメッセージ(セクション5.4.2を見る)をフォーマットして、クライアントのキーで要求された暗号化メソッドを使用することで暗号文部分を暗号化して、それをクライアントに送ります。 擬似コードに関してセクションA.2を見てください。
3.1.4. Generation of KRB_ERROR message
3.1.4. KRB_ERRORメッセージの世代
Several errors can occur, and the Authentication Server responds by returning an error message, KRB_ERROR, to the client, with the error-code and e-text fields set to appropriate values. The error message contents and details are described in Section 5.9.1.
いくつかの誤りが発生できます、そして、Authentication Serverはエラーメッセージを返すことによって、応じます、KRB_ERROR、クライアントに、値を当てるように設定されたエラーコードと電子テキストフィールドで。 エラーメッセージコンテンツと詳細はセクション5.9.1で説明されます。
3.1.5. Receipt of KRB_AS_REP message
3.1.5. KRB_AS_REPメッセージの領収書
If the reply message type is KRB_AS_REP, then the client verifies that the cname and crealm fields in the cleartext portion of the reply match what it requested. If any padata fields are present, they may be used to derive the proper secret key to decrypt the message. The client decrypts the encrypted part of the response using its secret key, verifies that the nonce in the encrypted part matches the nonce it supplied in its request (to detect replays). It also verifies that the sname and srealm in the response match those in the request, and that the host address field is also correct. It then stores the ticket, session key, start and expiration times, and other information for later use. The key-expiration field from the encrypted part of the response may be checked to notify the user of impending key expiration (the client program could then suggest remedial action, such as a password change). See section A.3 for pseudocode.
応答メッセージタイプがKRB_AS_REPであるなら、クライアントは、回答のcleartext部分のcnameとcrealm分野がそれが要求したことに合っていることを確かめます。 何かpadata分野が存在しているなら、それらは、メッセージを解読するために適切な秘密鍵を引き出すのに使用されるかもしれません。 クライアントは、秘密鍵を使用することで応答の暗号化された部分を解読して、暗号化された部分の一回だけがそれが要求(再生を検出する)で供給した一回だけに合っていることを確かめます。 また、それは応答におけるsnameとsrealmが要求におけるそれらに合って、また、ホストアドレス・フィールドも正しいことを確かめます。 そして、それは後の使用のためのチケット、セッションキー、始め、満了時間、および他の情報を保存します。 応答の暗号化された部分からの主要な満了分野は、主要な満了を迫らせるのについてユーザに通知するためにチェックされるかもしれません(次に、クライアントプログラムが改善措置を示すかもしれません、パスワード変化のように)。 擬似コードに関してセクションA.3を見てください。
Proper decryption of the KRB_AS_REP message is not sufficient to
REPメッセージが十分でないKRB_AS_の適切な復号化
Kohl & Neuman [Page 19] RFC 1510 Kerberos September 1993
コールとヌーマン[19ページ]のRFCの1510のケルベロスの1993年9月
verify the identity of the user; the user and an attacker could cooperate to generate a KRB_AS_REP format message which decrypts properly but is not from the proper KDC. If the host wishes to verify the identity of the user, it must require the user to present application credentials which can be verified using a securely-stored secret key. If those credentials can be verified, then the identity of the user can be assured.
ユーザのアイデンティティについて確かめてください。 ユーザと攻撃者が協力して、KRB_AS_REP形式メッセージを生成することができた、どれ、しかし、適切に解読するか、適切なKDCから、ありません。 ホストがユーザのアイデンティティについて確かめたいなら、それは、ユーザがしっかりと保存された秘密鍵を使用することで確かめることができるアプリケーション資格証明書を提示するのを必要としなければなりません。 それらの資格証明書について確かめることができるなら、ユーザのアイデンティティを保証できます。
3.1.6. Receipt of KRB_ERROR message
3.1.6. KRB_ERRORメッセージの領収書
If the reply message type is KRB_ERROR, then the client interprets it as an error and performs whatever application-specific tasks are necessary to recover.
応答メッセージタイプがKRB_ERRORであるなら、クライアントは、回復するために誤りとしてそれを解釈して、どんな必要なアプリケーション特有のタスクも実行します。
3.2. The Client/Server Authentication Exchange
3.2. クライアント/サーバー証明交換
Summary
概要
Message direction Message type Section
Client to Application server KRB_AP_REQ 5.5.1
[optional] Application server to client KRB_AP_REP or 5.5.2
KRB_ERROR 5.9.1
クライアントKRB_AP_REPへのApplicationサーバKRB_AP_REQ5.5.1の[任意]のアプリケーション・サーバーか5.5.2KRB_ERROR5.9.1へのメッセージ方向MessageタイプセクションClient
The client/server authentication (CS) exchange is used by network applications to authenticate the client to the server and vice versa. The client must have already acquired credentials for the server using the AS or TGS exchange.
クライアント/サーバ証明(CS)交換は、逆もまた同様にサーバにクライアントを認証するのにネットワーク応用で使用されます。 クライアントは、サーバのためにASかTGS交換を使用することで既に資格証明書を取得したに違いありません。
3.2.1. The KRB_AP_REQ message
3.2.1. KRB_AP_REQメッセージ
The KRB_AP_REQ contains authentication information which should be part of the first message in an authenticated transaction. It contains a ticket, an authenticator, and some additional bookkeeping information (see section 5.5.1 for the exact format). The ticket by itself is insufficient to authenticate a client, since tickets are passed across the network in cleartext(Tickets contain both an encrypted and unencrypted portion, so cleartext here refers to the entire unit, which can be copied from one message and replayed in another without any cryptographic skill.), so the authenticator is used to prevent invalid replay of tickets by proving to the server that the client knows the session key of the ticket and thus is entitled to use it. The KRB_AP_REQ message is referred to elsewhere as the "authentication header."
KRB_AP_REQは認証されたトランザクションにおける最初のメッセージの一部であるべきである認証情報を含んでいます。 それはチケット、固有識別文字、および何らかの追加簿記情報を含んでいます(正確な形式に関してセクション5.5.1を見てください)。 それ自体でチケットはクライアントを認証するためには不十分です、チケットがcleartextのネットワークの向こう側に渡されるので(チケットが暗号化されて非暗号化された部分を含んでいるので、ここのcleartextは全体の単位に言及します。)、固有識別文字は、クライアントがチケットのセッションキーを知っているとサーバに立証することによってチケットの無効の再生を防ぐのに使用されて、その結果、それを使用する権利を与えられます。単位を1つのメッセージからコピーして、別のもので少しも暗号の技能なしで再演できます。 KRB_AP_REQメッセージは「認証ヘッダー」としてほかの場所と呼ばれます。
3.2.2. Generation of a KRB_AP_REQ message
3.2.2. KRB_AP_REQメッセージの世代
When a client wishes to initiate authentication to a server, it obtains (either through a credentials cache, the AS exchange, or the
またはクライアントがそうしたがっているとき、サーバに認証を開始してください、それ、入手、(資格証明書キャッシュ、AS交換を通どちらかだって。
Kohl & Neuman [Page 20] RFC 1510 Kerberos September 1993
コールとヌーマン[20ページ]のRFCの1510のケルベロスの1993年9月
TGS exchange) a ticket and session key for the desired service. The client may re-use any tickets it holds until they expire. The client then constructs a new Authenticator from the the system time, its name, and optionally an application specific checksum, an initial sequence number to be used in KRB_SAFE or KRB_PRIV messages, and/or a session subkey to be used in negotiations for a session key unique to this particular session. Authenticators may not be re-used and will be rejected if replayed to a server (Note that this can make applications based on unreliable transports difficult to code correctly, if the transport might deliver duplicated messages. In such cases, a new authenticator must be generated for each retry.). If a sequence number is to be included, it should be randomly chosen so that even after many messages have been exchanged it is not likely to collide with other sequence numbers in use.
TGS交換) 必要なサービスに、主要なチケットとセッション。 クライアントは期限が切れるまでそれが保つどんなチケットも再使用するかもしれません。 そしてクライアントはシステム時間、名前から新しいAuthenticatorを任意に組み立てます。アプリケーションの特定のチェックサム(この特定のセッションにユニークなセッションキーに交渉に使用されるのにKRB_SAFEかKRB_PRIVメッセージ、そして/または、セッションサブキーで使用されるべき初期シーケンス番号)。 固有識別文字は、再使用されないかもしれなくて、サーバに再演されると、拒絶されるでしょう。(これが、正しく頼り無い輸送に基づくアプリケーションをコード化するのを難しくすることができることに注意してください、輸送がコピーされたメッセージを提供するかもしれないなら。 そのようなものがケースに入れるコネ、各再試行のために新しい固有識別文字を生成しなければならないa)。 一連番号が含まれることであるなら、手当たりしだいに選ばれるべきであるので、多くのメッセージを交換した後にさえ、それは使用中の他の一連番号と衝突しそうにはありません。
The client may indicate a requirement of mutual authentication or the use of a session-key based ticket by setting the appropriate flag(s) in the ap-options field of the message.
クライアントは、メッセージのap-オプション分野に適切なフラグをはめ込むことによって、互いの認証の要件かセッション主要なベースのチケットの使用を示すかもしれません。
The Authenticator is encrypted in the session key and combined with the ticket to form the KRB_AP_REQ message which is then sent to the end server along with any additional application-specific information. See section A.9 for pseudocode.
Authenticatorは、次にどんな追加アプリケーション特有の情報に伴うエンドサーバにも送られるKRB_AP_REQメッセージを形成するためにセッションキーで暗号化されて、チケットに合成されます。 擬似コードに関してセクションA.9を見てください。
3.2.3. Receipt of KRB_AP_REQ message
3.2.3. KRB_AP_REQメッセージの領収書
Authentication is based on the server's current time of day (clocks must be loosely synchronized), the authenticator, and the ticket. Several errors are possible. If an error occurs, the server is expected to reply to the client with a KRB_ERROR message. This message may be encapsulated in the application protocol if its "raw" form is not acceptable to the protocol. The format of error messages is described in section 5.9.1.
認証はサーバの現在の時刻(時計は緩く連動しなければならない)、固有識別文字、およびチケットに基づいています。 いくつかの誤りが可能です。 誤りが発生するなら、サーバがKRB_ERRORメッセージでクライアントに答えると予想されます。 「生」のフォームがプロトコルに許容していないなら、このメッセージはアプリケーション・プロトコルでカプセル化されるかもしれません。 エラーメッセージの形式はセクション5.9.1で説明されます。
The algorithm for verifying authentication information is as follows. If the message type is not KRB_AP_REQ, the server returns the KRB_AP_ERR_MSG_TYPE error. If the key version indicated by the Ticket in the KRB_AP_REQ is not one the server can use (e.g., it indicates an old key, and the server no longer possesses a copy of the old key), the KRB_AP_ERR_BADKEYVER error is returned. If the USE- SESSION-KEY flag is set in the ap-options field, it indicates to the server that the ticket is encrypted in the session key from the server's ticket-granting ticket rather than its secret key (This is used for user-to-user authentication as described in [6]). Since it is possible for the server to be registered in multiple realms, with different keys in each, the srealm field in the unencrypted portion of the ticket in the KRB_AP_REQ is used to specify which secret key the server should use to decrypt that ticket. The KRB_AP_ERR_NOKEY
認証情報について確かめるためのアルゴリズムは以下の通りです。 メッセージタイプがKRB_AP_REQでないなら、サーバは_ERR_エムエスジー_TYPE誤りをKRB_APに返します。 主要なバージョンが、KRBのTicketで_AP_REQがサーバが使用できる1つ(古いキーを示します、そして、サーバには、古いキーのコピーがもうない)でないことを示したなら、KRB_AP_ERR_BADKEYVER誤りは返されます。 USE- SESSION-KEY旗がap-オプション分野に設定されるなら、それは、チケットが秘密鍵よりむしろサーバのチケットを与えるチケットから主要なセッションのときに暗号化されるのをサーバに示します。(これはユーザからユーザー認証に[6])で説明されるように使用されます。 サーバが複数の分野にそれぞれの異なったキーに登録されるのが、可能であるので、KRB_AP_REQのチケットの非暗号化された部分のsrealm分野はサーバがそのチケットを解読するのにどの秘密鍵を使用するべきであるかを指定するのに使用されます。 KRB_AP_が間違える、_NOKEY
Kohl & Neuman [Page 21] RFC 1510 Kerberos September 1993
コールとヌーマン[21ページ]のRFCの1510のケルベロスの1993年9月
error code is returned if the server doesn't have the proper key to decipher the ticket.
サーバにチケットを解読する適切なキーがないなら、エラーコードは返されます。
The ticket is decrypted using the version of the server's key specified by the ticket. If the decryption routines detect a modification of the ticket (each encryption system must provide safeguards to detect modified ciphertext; see section 6), the KRB_AP_ERR_BAD_INTEGRITY error is returned (chances are good that different keys were used to encrypt and decrypt).
チケットは、チケットによって指定されたサーバのキーのバージョンを使用することで解読されます。 復号化ルーチンがチケットの変更を検出するなら(それぞれの暗号化システムは変更された暗号文を検出するために安全装置を提供しなければなりません; セクション6を見てください)、KRB_AP_ERR_BAD_INTEGRITY誤りは返されます(異なったキーが暗号化して、解読するのにおいて使用されていたという可能性は十分です)。
The authenticator is decrypted using the session key extracted from the decrypted ticket. If decryption shows it to have been modified, the KRB_AP_ERR_BAD_INTEGRITY error is returned. The name and realm of the client from the ticket are compared against the same fields in the authenticator. If they don't match, the KRB_AP_ERR_BADMATCH error is returned (they might not match, for example, if the wrong session key was used to encrypt the authenticator). The addresses in the ticket (if any) are then searched for an address matching the operating-system reported address of the client. If no match is found or the server insists on ticket addresses but none are present in the ticket, the KRB_AP_ERR_BADADDR error is returned.
固有識別文字は、解読されたチケットから抽出されたセッションキーを使用することで解読されます。 復号化が変更されたためにそれを示しているなら、KRB_AP_ERR_BAD_INTEGRITY誤りは返されます。 チケットからのクライアントの名前と分野は固有識別文字の同じ分野に対してたとえられます。 彼らが合っていないなら、KRB_AP_ERR_BADMATCH誤りは返されます(例えば、間違ったセッションキーが固有識別文字を暗号化するのに使用されるなら、彼らは合っていないでしょうに)。 そして、チケット(もしあれば)の中のアドレスはクライアントのオペレーティングシステムの報告されたアドレスに合っているアドレスを捜されます。 マッチが全く見つけられないか、サーバがチケットアドレスを主張しますが、またはなにもチケットの中に存在していないなら、KRB_AP_ERR_BADADDR誤りは返されます。
If the local (server) time and the client time in the authenticator differ by more than the allowable clock skew (e.g., 5 minutes), the KRB_AP_ERR_SKEW error is returned. If the server name, along with the client name, time and microsecond fields from the Authenticator match any recently-seen such tuples, the KRB_AP_ERR_REPEAT error is returned (Note that the rejection here is restricted to authenticators from the same principal to the same server. Other client principals communicating with the same server principal should not be have their authenticators rejected if the time and microsecond fields happen to match some other client's authenticator.). The server must remember any authenticator presented within the allowable clock skew, so that a replay attempt is guaranteed to fail. If a server loses track of any authenticator presented within the allowable clock skew, it must reject all requests until the clock skew interval has passed. This assures that any lost or re-played authenticators will fall outside the allowable clock skew and can no longer be successfully replayed (If this is not done, an attacker could conceivably record the ticket and authenticator sent over the network to a server, then disable the client's host, pose as the disabled host, and replay the ticket and authenticator to subvert the authentication.). If a sequence number is provided in the authenticator, the server saves it for later use in processing KRB_SAFE and/or KRB_PRIV messages. If a subkey is present, the server either saves it for later use or uses it to help generate its own choice for a subkey to be returned in a KRB_AP_REP message.
地方の(サーバ)時間と固有識別文字のクライアント時間が許容できる時計斜行(例えば、5分)以上で異なるなら、KRB_AP_ERR_SKEW誤りは返されます。 ここでの拒絶が同じ主体から同じサーバまで固有識別文字に制限されることに注意してください。時間とマイクロセカンドがクライアント名と共にAuthenticatorからさばくサーバー名が最近見られた状態でいずれかにも合っているなら、そのようなtuples、KRB_AP_ERR_REPEAT誤りは返されます(同じサーバ主体で交信する他のクライアント主体は時間とマイクロセカンド分野がたまたまある他のクライアントの固有識別文字に合っているならそれらの固有識別文字を拒絶させることであるべきではありません。)。 サーバは許容できる時計斜行の中に提示されたどんな固有識別文字も覚えていなければなりません、再生試みが失敗するように保証されるように。 サーバが何か許容できる時計斜行の中に提示された固有識別文字を見失うなら、時計斜行間隔が過ぎるまで、それはすべての要求を拒絶しなければなりません。 これはどんな無くなっているか再演された固有識別文字も許容できる時計斜行をそらせて、もう首尾よく再演できないことを保証します(これが完了していないなら、攻撃者は、認証を打倒するために多分ネットワークの上に送られたチケットと固有識別文字をサーバに記録して、次に、クライアントのホストを無効にして、障害があるホストのふりをして、チケットと固有識別文字を再演するかもしれません。)。 一連番号を固有識別文字に提供するなら、サーバは処理KRB_SAFE、そして/または、KRB_PRIVメッセージにおける後の使用のためにそれを貯蓄します。 サブキーが存在しているなら、サーバは、後の使用のためにそれを貯蓄するか、またはサブキーがKRB_AP_REPメッセージで返されるそれ自身の選択を生成するのを助けるのにそれを使用します。
Kohl & Neuman [Page 22] RFC 1510 Kerberos September 1993
コールとヌーマン[22ページ]のRFCの1510のケルベロスの1993年9月
The server computes the age of the ticket: local (server) time minus the start time inside the Ticket. If the start time is later than the current time by more than the allowable clock skew or if the INVALID flag is set in the ticket, the KRB_AP_ERR_TKT_NYV error is returned. Otherwise, if the current time is later than end time by more than the allowable clock skew, the KRB_AP_ERR_TKT_EXPIRED error is returned.
サーバはチケットの時代を計算します: Ticketの中の開始時刻を引いた地方の(サーバ)時間。 開始時刻が許容できる時計斜行かそれともINVALIDが弛むかどうか以上による現在の時間がチケットの中に設定されるより遅いなら、KRB_AP_ERR_TKT_NYV誤りは返されます。 さもなければ、現在の時間が終わりの時間より遅く許容できる時計斜行以上であるなら、KRB_AP_ERR_TKT_EXPIRED誤りは返されます。
If all these checks succeed without an error, the server is assured that the client possesses the credentials of the principal named in the ticket and thus, the client has been authenticated to the server. See section A.10 for pseudocode.
これらのすべてのチェックが誤りなしで成功するなら、サーバはクライアントにはチケットの中に指定された主体の資格証明書があることが保証されます、そして、その結果、クライアントはサーバに認証されました。擬似コードに関してセクションA.10を見てください。
3.2.4. Generation of a KRB_AP_REP message
3.2.4. KRB_AP_REPメッセージの世代
Typically, a client's request will include both the authentication information and its initial request in the same message, and the server need not explicitly reply to the KRB_AP_REQ. However, if mutual authentication (not only authenticating the client to the server, but also the server to the client) is being performed, the KRB_AP_REQ message will have MUTUAL-REQUIRED set in its ap-options field, and a KRB_AP_REP message is required in response. As with the error message, this message may be encapsulated in the application protocol if its "raw" form is not acceptable to the application's protocol. The timestamp and microsecond field used in the reply must be the client's timestamp and microsecond field (as provided in the authenticator). [Note: In the Kerberos version 4 protocol, the timestamp in the reply was the client's timestamp plus one. This is not necessary in version 5 because version 5 messages are formatted in such a way that it is not possible to create the reply by judicious message surgery (even in encrypted form) without knowledge of the appropriate encryption keys.] If a sequence number is to be included, it should be randomly chosen as described above for the authenticator. A subkey may be included if the server desires to negotiate a different subkey. The KRB_AP_REP message is encrypted in the session key extracted from the ticket. See section A.11 for pseudocode.
通常、クライアントの要求は同じメッセージに認証情報とその初期の要求の両方を含むでしょう、そして、サーバは明らかにKRB_AP_REQに答える必要はありません。 しかしながら、互いの認証(サーバにクライアントを認証するだけの、クライアントへのサーバ)が実行されていると、KRB_AP_REQメッセージで、ap-オプション分野でMUTUAL-REQUIREDを用意ができさせるでしょう、そして、KRB_AP_REPメッセージが応答で必要です。 エラーメッセージ、「生」のフォームがアプリケーションのプロトコルに許容していないなら、このメッセージはアプリケーション・プロトコルでカプセル化されるかもしれません。 回答に使用されるタイムスタンプとマイクロセカンド分野は、クライアントのタイムスタンプとマイクロセカンド分野であるに違いありません(固有識別文字に提供するように)。 [以下に注意してください。 ケルベロスバージョン4プロトコルでは、回答におけるタイムスタンプは、クライアントのタイムスタンプと1でした。 バージョン5メッセージが賢明なメッセージ外科(暗号化されたフォームさえでの)で適切な暗号化キーに関する知識なしで回答を作成するのが可能でないような方法でフォーマットされるので、これはバージョン5で必要ではありません。] 一連番号が含まれることであるなら、それは固有識別文字のために上で説明されるように手当たりしだいに選ばれるべきです。 サーバが、異なったサブキーを交渉することを望んでいるなら、サブキーは含まれるかもしれません。 KRB_AP_REPメッセージはチケットから抽出されたセッションキーで暗号化されます。 擬似コードに関してセクションA.11を見てください。
3.2.5. Receipt of KRB_AP_REP message
3.2.5. KRB_AP_REPメッセージの領収書
If a KRB_AP_REP message is returned, the client uses the session key from the credentials obtained for the server (Note that for encrypting the KRB_AP_REP message, the sub-session key is not used, even if present in the Authenticator.) to decrypt the message, and verifies that the timestamp and microsecond fields match those in the Authenticator it sent to the server. If they match, then the client is assured that the server is genuine. The sequence number and subkey (if present) are retained for later use. See section A.12 for
KRB_AP_REPメッセージを返すなら、クライアントは、サーバ(KRB_AP_REPメッセージを暗号化するのにおいて、サブセッションキーが使用されていないことに注意してください、Authenticatorに存在していても。)がメッセージを解読するように得られた資格証明書から主要なセッションを使用して、タイムスタンプとマイクロセカンド分野がそれがサーバに送ったAuthenticatorでそれらに合っていることを確かめます。合っているなら、クライアントはサーバが本物であると確信しています。 一連番号とサブキー(存在しているなら)は後の使用のために保有されます。 セクションA.12を見ます。
Kohl & Neuman [Page 23] RFC 1510 Kerberos September 1993
コールとヌーマン[23ページ]のRFCの1510のケルベロスの1993年9月
pseudocode.
擬似コード。
3.2.6. Using the encryption key
3.2.6. 暗号化キーを使用します。
After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, the client and server share an encryption key which can be used by the application. The "true session key" to be used for KRB_PRIV, KRB_SAFE, or other application-specific uses may be chosen by the application based on the subkeys in the KRB_AP_REP message and the authenticator (Implementations of the protocol may wish to provide routines to choose subkeys based on session keys and random numbers and to orchestrate a negotiated key to be returned in the KRB_AP_REP message.). In some cases, the use of this session key will be implicit in the protocol; in others the method of use must be chosen from a several alternatives. We leave the protocol negotiations of how to use the key (e.g., selecting an encryption or checksum type) to the application programmer; the Kerberos protocol does not constrain the implementation options.
KRB_AP_REQ/KRB_AP_REP交換が起こった後に、クライアントとサーバはアプリケーションで使用できる暗号化キーを共有します。 KRB_PRIV、KRB_SAFE、または他のアプリケーション特有の用途に使用されるべき「本当のセッションキー」はKRB_AP_REPメッセージと固有識別文字でサブキーに基づくアプリケーションで選ばれるかもしれません(プロトコルの実装はセッションキーと乱数に基づくサブキーを選んで、KRB_AP_REPメッセージで返される交渉されたキーを調整するためにルーチンを提供したがっているかもしれません。)。 いくつかの場合、このセッションキーの使用はプロトコルで暗黙になるでしょう。 他のものでは、いくつかの選択肢から使用のメソッドを選ばなければなりません。 私たちはどう、キー(例えば、暗号化を選択するか、チェックサムタイプ)を使用するかに関する議定書交渉をアプリケーション・プログラマーに任せます。 ケルベロスプロトコルは実装オプションを抑制しません。
With both the one-way and mutual authentication exchanges, the peers should take care not to send sensitive information to each other without proper assurances. In particular, applications that require privacy or integrity should use the KRB_AP_REP or KRB_ERROR responses from the server to client to assure both client and server of their peer's identity. If an application protocol requires privacy of its messages, it can use the KRB_PRIV message (section 3.5). The KRB_SAFE message (section 3.4) can be used to assure integrity.
両方の一方向の、そして、互いの認証交換で、同輩は、適切な保証なしで機密情報を互いに送らないように注意するべきです。 特に、プライバシーか保全を必要とするアプリケーションは、クライアントと彼らの同輩のアイデンティティのサーバの両方を保証するのにサーバからクライアントにKRB_AP_REPかKRB_ERROR応答を使用するべきです。 アプリケーション・プロトコルがメッセージのプライバシーを必要とするなら、それはKRB_PRIVメッセージ(セクション3.5)を使用できます。 保全を保証するのに、KRB_SAFEメッセージ(セクション3.4)を使用できます。
3.3. The Ticket-Granting Service (TGS) Exchange
3.3. チケットを与えるサービス(TGS)交換
Summary
概要
Message direction Message type Section
1. Client to Kerberos KRB_TGS_REQ 5.4.1
2. Kerberos to client KRB_TGS_REP or 5.4.2
KRB_ERROR 5.9.1
メッセージ方向Messageはセクション1をタイプします。 ケルベロスKRB_TGS_REQ5.4.1 2へのクライアント。 クライアントKRB_TGS_REPへのケルベロスか5.4.2KRB_ERROR5.9.1
The TGS exchange between a client and the Kerberos Ticket-Granting Server is initiated by a client when it wishes to obtain authentication credentials for a given server (which might be registered in a remote realm), when it wishes to renew or validate an existing ticket, or when it wishes to obtain a proxy ticket. In the first case, the client must already have acquired a ticket for the Ticket-Granting Service using the AS exchange (the ticket-granting ticket is usually obtained when a client initially authenticates to the system, such as when a user logs in). The message format for the TGS exchange is almost identical to that for the AS exchange. The primary difference is that encryption and decryption in the TGS
与えられたサーバ(リモート分野に登録されるかもしれない)に認証資格証明書を得たがっているとき、クライアントとTicketを与えているケルベロスServerの間のTGS交換はクライアントによって起こされます、既存のチケットを更新したいか、有効にしたがっている、またはプロキシチケットを得たがっているとき。 前者の場合、クライアントがAS交換を使用することで既にTicketを与えているServiceのチケットを入手したに違いない、(クライアントが初めはいつとしてそのようなシステムにユーザを認証するかと通常、チケットを与えるチケットを得る、中のログ) AS交換に、TGS交換のためのメッセージ・フォーマットはそれとほとんど同じです。 プライマリ違いは、TGSのその暗号化と復号化です。
Kohl & Neuman [Page 24] RFC 1510 Kerberos September 1993
コールとヌーマン[24ページ]のRFCの1510のケルベロスの1993年9月
exchange does not take place under the client's key. Instead, the session key from the ticket-granting ticket or renewable ticket, or sub-session key from an Authenticator is used. As is the case for all application servers, expired tickets are not accepted by the TGS, so once a renewable or ticket-granting ticket expires, the client must use a separate exchange to obtain valid tickets.
交換はクライアントのキーの下に起こりません。 代わりに、Authenticatorからのセッションのチケットを与えるチケットか再生可能なものチケットから主要であるか、またはサブセッションのキーは使用されています。 すべてのアプリケーション・サーバーのためのケースのように、有効期限の切れた切符がTGSによって受け入れられないので、再生可能なものかチケットを与えるチケットがいったん期限が切れると、クライアントは有効なチケットを得るのに別々の交換を使用しなければなりません。
The TGS exchange consists of two messages: A request (KRB_TGS_REQ) from the client to the Kerberos Ticket-Granting Server, and a reply (KRB_TGS_REP or KRB_ERROR). The KRB_TGS_REQ message includes information authenticating the client plus a request for credentials. The authentication information consists of the authentication header (KRB_AP_REQ) which includes the client's previously obtained ticket- granting, renewable, or invalid ticket. In the ticket-granting ticket and proxy cases, the request may include one or more of: a list of network addresses, a collection of typed authorization data to be sealed in the ticket for authorization use by the application server, or additional tickets (the use of which are described later). The TGS reply (KRB_TGS_REP) contains the requested credentials, encrypted in the session key from the ticket-granting ticket or renewable ticket, or if present, in the subsession key from the Authenticator (part of the authentication header). The KRB_ERROR message contains an error code and text explaining what went wrong. The KRB_ERROR message is not encrypted. The KRB_TGS_REP message contains information which can be used to detect replays, and to associate it with the message to which it replies. The KRB_ERROR message also contains information which can be used to associate it with the message to which it replies, but the lack of encryption in the KRB_ERROR message precludes the ability to detect replays or fabrications of such messages.
TGS交換は2つのメッセージから成ります: クライアントからTicketを与えているケルベロスServerまでの要求(KRB_TGS_REQ)、および回答(KRB_TGS_REPかKRB_ERROR)。 KRB_TGS_REQメッセージはクライアントを認証する情報と資格証明書を求める要求を含んでいます。 どれがクライアントの以前に得られたチケットの与える、再生可能なもの、または無効のチケットを含んでいるかという認証情報は認証ヘッダー(KRB_AP_REQ)から成ります。 チケットを与えるチケットとプロキシ事件では、要求は以下について1つ以上を含むかもしれません。 ネットワーク・アドレスのリスト、承認使用のチケットの中にアプリケーション・サーバーによって封ををされるべきタイプされた承認データ、または追加チケット(それの使用は後で説明される)の収集。 TGS回答(KRB_TGS_REP)はチケットを与えるチケットか再生可能なものチケットから主要なセッション、または存在しているなら暗号化された要求された資格証明書を含んでいます、Authenticator(認証ヘッダーの一部)から主要な「副-セッション」で。 KRB_ERRORメッセージは何が支障をきたしたかがわかるエラーコードとテキストを含んでいます。 KRB_ERRORメッセージは暗号化されていません。 KRB_TGS_REPメッセージは再生を検出して、それが返答するメッセージにそれを関連づけるのに使用できる情報を含んでいます。 また、KRB_ERRORメッセージはそれが返答するメッセージにそれを関連づけるのに使用できる情報を含んでいますが、KRB_ERRORメッセージにおける、暗号化の不足はそのようなメッセージの再生か製作を検出する能力を排除します。
3.3.1. Generation of KRB_TGS_REQ message
3.3.1. KRB_TGS_REQメッセージの世代
Before sending a request to the ticket-granting service, the client must determine in which realm the application server is registered [Note: This can be accomplished in several ways. It might be known beforehand (since the realm is part of the principal identifier), or it might be stored in a nameserver. Presently, however, this information is obtained from a configuration file. If the realm to be used is obtained from a nameserver, there is a danger of being spoofed if the nameservice providing the realm name is not authenticated. This might result in the use of a realm which has been compromised, and would result in an attacker's ability to compromise the authentication of the application server to the client.]. If the client does not already possess a ticket-granting ticket for the appropriate realm, then one must be obtained. This is first attempted by requesting a ticket-granting ticket for the destination realm from the local Kerberos server (using the
チケットを与えるサービスに要求を送る前に、クライアントは、アプリケーション・サーバーがどの分野で登録されているかを決心しなければなりません。[以下に注意してください。 いくつかの方法でこれを達成できます。 あらかじめ、それを知っているかもしれませんか(分野が主要な識別子の一部であるので)、またはネームサーバでそれを保存するかもしれません。しかしながら、現在、構成ファイルからこの情報を得ます。 ネームサーバから使用されるべき分野を得るなら、分野名を提供するnameserviceが認証されないなら偽造されるという危険があります。 これは、感染された分野の使用をもたらすかもしれなくて、アプリケーション・サーバーの認証にクライアントに感染する攻撃者の能力をもたらすでしょう。]. クライアントが既に適切な分野のチケットを与えるチケットを所有しないなら、得なければなりません。 これが最初にローカルのケルベロスサーバから目的地分野のチケットを与えるチケットを要求することによって試みられる、(使用
Kohl & Neuman [Page 25] RFC 1510 Kerberos September 1993
コールとヌーマン[25ページ]のRFCの1510のケルベロスの1993年9月
KRB_TGS_REQ message recursively). The Kerberos server may return a TGT for the desired realm in which case one can proceed. Alternatively, the Kerberos server may return a TGT for a realm which is "closer" to the desired realm (further along the standard hierarchical path), in which case this step must be repeated with a Kerberos server in the realm specified in the returned TGT. If neither are returned, then the request must be retried with a Kerberos server for a realm higher in the hierarchy. This request will itself require a ticket-granting ticket for the higher realm which must be obtained by recursively applying these directions.
REQが再帰的に通信させるKRB_TGS_) ケルベロスサーバはケース1が続くことができる必要な分野にTGTを返すかもしれません。 あるいはまた、ケルベロスサーバは「より近いところに必要な分野の」(標準の階層的な経路に沿って、より遠くに)ある分野にTGTを返すかもしれません、その場合、返されたTGTで指定された分野でケルベロスサーバでこのステップを繰り返さなければなりません。 どちらも返さないなら、ケルベロスサーバで分野に要求を階層構造で、より高く再試行しなければなりません。 この要求はこれらの方向を再帰的に適用することによって得なければならないより高い分野のチケットを与えるチケットを必要とするためにそれ自体で望んでいます。
Once the client obtains a ticket-granting ticket for the appropriate realm, it determines which Kerberos servers serve that realm, and contacts one. The list might be obtained through a configuration file or network service; as long as the secret keys exchanged by realms are kept secret, only denial of service results from a false Kerberos server.
クライアントがいったん適切な分野のチケットを与えるチケットを得ると、それは、どのケルベロスサーバがその分野に役立つかを決定して、1つに連絡します。 構成ファイルかネットワーク・サービスでリストを得るかもしれません。 分野によって交換された秘密鍵が秘密にされる限り、サービスの否定だけが誤ったケルベロスサーバから生じます。
As in the AS exchange, the client may specify a number of options in the KRB_TGS_REQ message. The client prepares the KRB_TGS_REQ message, providing an authentication header as an element of the padata field, and including the same fields as used in the KRB_AS_REQ message along with several optional fields: the enc-authorization- data field for application server use and additional tickets required by some options.
AS交換のように、クライアントはKRB_TGS_REQメッセージにおける多くのオプションを指定するかもしれません。 クライアントはKRB_TGS_REQメッセージを準備します、padata分野の要素として認証ヘッダーを提供して、いくつかの任意の分野に伴うKRB_AS_REQメッセージで使用されるのと同じ分野を含んでいて: アプリケーション・サーバー使用と追加チケットのためのenc-承認データ・フィールドがいくつかのオプションで必要です。
In preparing the authentication header, the client can select a sub- session key under which the response from the Kerberos server will be encrypted (If the client selects a sub-session key, care must be taken to ensure the randomness of the selected subsession key. One approach would be to generate a random number and XOR it with the session key from the ticket-granting ticket.). If the sub-session key is not specified, the session key from the ticket-granting ticket will be used. If the enc-authorization-data is present, it must be encrypted in the sub-session key, if present, from the authenticator portion of the authentication header, or if not present in the session key from the ticket-granting ticket.
認証ヘッダーに準備させる際に、クライアントはケルベロスサーバからの応答が暗号化されるサブセッションキーを選択できます。(クライアントがサブセッションキーを選択するなら、選択された「副-セッション」キーの偶発性を確実にするために注意しなければなりません。 1つのアプローチは乱数を生成するだろうことであり、XORはそれです。チケットを与えるチケットから主要なセッションで。). サブセッションキーが指定されないと、チケットを与えるチケットから主要なセッションは使用されるでしょう。 enc承認データが存在しているなら、認証ヘッダーの固有識別文字一部、またはまして、チケットを与えるチケットから主要なセッションにおけるプレゼントから主要で、現在のサブセッションのときにそれを暗号化しなければなりません。
Once prepared, the message is sent to a Kerberos server for the destination realm. See section A.5 for pseudocode.
いったん準備すると、目的地分野のためにケルベロスサーバにメッセージを送ります。 擬似コードに関してセクションA.5を見てください。
3.3.2. Receipt of KRB_TGS_REQ message
3.3.2. KRB_TGS_REQメッセージの領収書
The KRB_TGS_REQ message is processed in a manner similar to the KRB_AS_REQ message, but there are many additional checks to be performed. First, the Kerberos server must determine which server the accompanying ticket is for and it must select the appropriate key to decrypt it. For a normal KRB_TGS_REQ message, it will be for the
KRB_TGS_REQメッセージはKRB_AS_REQメッセージと同様の方法で処理されますが、実行されるために、多くの追加チェックがあります。 まず最初に、ケルベロスサーバは、付随のチケットがどのサーバのためにあるかを決定しなければなりません、そして、それはそれを解読するために適切なキーを選択しなければなりません。 正常なKRB_TGS_REQメッセージに関しては、それはそうでしょう。
Kohl & Neuman [Page 26] RFC 1510 Kerberos September 1993
コールとヌーマン[26ページ]のRFCの1510のケルベロスの1993年9月
ticket granting service, and the TGS's key will be used. If the TGT was issued by another realm, then the appropriate inter-realm key must be used. If the accompanying ticket is not a ticket granting ticket for the current realm, but is for an application server in the current realm, the RENEW, VALIDATE, or PROXY options are specified in the request, and the server for which a ticket is requested is the server named in the accompanying ticket, then the KDC will decrypt the ticket in the authentication header using the key of the server for which it was issued. If no ticket can be found in the padata field, the KDC_ERR_PADATA_TYPE_NOSUPP error is returned.
サービスを承諾するチケット、およびTGSのキーは使用されるでしょう。 TGTが別の分野によって発行されたなら、適切な相互分野キーを使用しなければなりません。 付随のチケットが現在の分野のチケットを与えないどんなチケットですがも、アプリケーション・サーバーのために現在の分野にあって、RENEW、VALIDATE、またはPROXYオプションが要求で指定されて、チケットが要求されているサーバが付随のチケットの中に指定されたサーバであるなら、KDCは、それが発行されたサーバのキーを使用することで認証ヘッダーのチケットを解読するでしょう。 padata野原でチケットを全く発見されることができないなら、KDC_ERR_PADATA_TYPE_NOSUPP誤りは返されます。
Once the accompanying ticket has been decrypted, the user-supplied checksum in the Authenticator must be verified against the contents of the request, and the message rejected if the checksums do not match (with an error code of KRB_AP_ERR_MODIFIED) or if the checksum is not keyed or not collision-proof (with an error code of KRB_AP_ERR_INAPP_CKSUM). If the checksum type is not supported, the KDC_ERR_SUMTYPE_NOSUPP error is returned. If the authorization-data are present, they are decrypted using the sub-session key from the Authenticator.
付随のチケットがいったん解読されると、要求のコンテンツ、およびチェックサムが合っていないか(KRB_AP_ERR_MODIFIEDのエラーコードで)、合わせられないまたは耐でないならチェックサム衝突の(KRB_AP_ERR_INAPP_CKSUMのエラーコードがある)拒絶されたメッセージに対してAuthenticatorのユーザによって供給されたチェックサムについて確かめなければなりません。 チェックサムタイプが支持されないなら、KDC_ERR_SUMTYPE_NOSUPP誤りは返されます。 認可データが存在しているなら、それらは、Authenticatorから主要なサブセッションを使用することで解読されます。
If any of the decryptions indicate failed integrity checks, the KRB_AP_ERR_BAD_INTEGRITY error is returned.
復号化のどれかが、失敗した保全がチェックするのを示すなら、KRB_AP_ERR_BAD_INTEGRITY誤りは返されます。
3.3.3. Generation of KRB_TGS_REP message
3.3.3. KRB_TGS_REPメッセージの世代
The KRB_TGS_REP message shares its format with the KRB_AS_REP (KRB_KDC_REP), but with its type field set to KRB_TGS_REP. The detailed specification is in section 5.4.2.
KRB_TGS_REPメッセージはKRB_AS_REP(KRB_KDC_REP)にもかかわらず、KRB_TGS_REPに設定されたタイプ分野と形式を共有します。セクション5.4.2には仕様詳細があります。
The response will include a ticket for the requested server. The Kerberos database is queried to retrieve the record for the requested server (including the key with which the ticket will be encrypted). If the request is for a ticket granting ticket for a remote realm, and if no key is shared with the requested realm, then the Kerberos server will select the realm "closest" to the requested realm with which it does share a key, and use that realm instead. This is the only case where the response from the KDC will be for a different server than that requested by the client.
応答は要求されたサーバのチケットを含むでしょう。ケルベロスデータベースは、要求されたサーバのための記録を検索するために質問されます(チケットがコード化されるキーを含んでいて)。 要求がリモート分野のチケットを与えるチケットのためのものであり、キーが全く要求された分野と共有されないと、ケルベロスサーバは「最も近いところでそれとキーを共有して、代わりにその分野を使用する要求された分野の」分野を選択するでしょう。 これはKDCからの応答がクライアントによって要求されたそれと異なったサーバのためにある唯一のそうです。
By default, the address field, the client's name and realm, the list of transited realms, the time of initial authentication, the expiration time, and the authorization data of the newly-issued ticket will be copied from the ticket-granting ticket (TGT) or renewable ticket. If the transited field needs to be updated, but the transited type is not supported, the KDC_ERR_TRTYPE_NOSUPP error is returned.
初期の認証、満了時間、および認可のデフォルトでとアドレス・フィールドとクライアントの名前と分野、通過している分野のリスト、時に、新譜のチケットに関するデータはチケットを与えるチケット(TGT)か再生可能なものチケットからコピーされるでしょう。 通過している分野が、アップデートする必要がありますが、通過しているタイプが支持されないなら、KDC_ERR_TRTYPE_NOSUPP誤りは返されます。
Kohl & Neuman [Page 27] RFC 1510 Kerberos September 1993
コールとヌーマン[27ページ]のRFCの1510のケルベロスの1993年9月
If the request specifies an endtime, then the endtime of the new ticket is set to the minimum of (a) that request, (b) the endtime from the TGT, and (c) the starttime of the TGT plus the minimum of the maximum life for the application server and the maximum life for the local realm (the maximum life for the requesting principal was already applied when the TGT was issued). If the new ticket is to be a renewal, then the endtime above is replaced by the minimum of (a) the value of the renew_till field of the ticket and (b) the starttime for the new ticket plus the life (endtimestarttime) of the old ticket.
要求がendtimeを指定するなら、新しいチケットのendtimeは(a) その要求、(b) TGTからのendtime、および(c) TGTのstarttimeの最小限とアプリケーション・サーバーのための最大の人生と地方の分野に、最大の人生の最小限へのセット(TGTが発行されたとき、要求している校長にとって、最大の人生は既に適用された)です。 新しいチケットによる更新であるつもりであるなら上のendtimeを(a) 価値の最小限に取り替える、(b) 新しいチケットのためのチケットとstarttimeの分野と古いチケットの人生(endtimestarttime)まで_を取り替えてください。
If the FORWARDED option has been requested, then the resulting ticket will contain the addresses specified by the client. This option will only be honored if the FORWARDABLE flag is set in the TGT. The PROXY option is similar; the resulting ticket will contain the addresses specified by the client. It will be honored only if the PROXIABLE flag in the TGT is set. The PROXY option will not be honored on requests for additional ticket-granting tickets.
FORWARDEDオプションが要求されると、結果として起こるチケットはクライアントによって指定されたアドレスを含むでしょう。 FORWARDABLE旗がTGTに設定される場合にだけ、このオプションは光栄に思うようになるでしょう。 PROXYオプションは同様です。 結果として起こるチケットはクライアントによって指定されたアドレスを含むでしょう。 TGTのPROXIABLE旗が設定される場合にだけ、光栄に思うようになるでしょう。 PROXYオプションは追加チケットを与えるチケットを求める要求のときに光栄に思うようにならないでしょう。
If the requested start time is absent or indicates a time in the past, then the start time of the ticket is set to the authentication server's current time. If it indicates a time in the future, but the POSTDATED option has not been specified or the MAY-POSTDATE flag is not set in the TGT, then the error KDC_ERR_CANNOT_POSTDATE is returned. Otherwise, if the ticket-granting ticket has the MAYPOSTDATE flag set, then the resulting ticket will be postdated and the requested starttime is checked against the policy of the local realm. If acceptable, the ticket's start time is set as requested, and the INVALID flag is set. The postdated ticket must be validated before use by presenting it to the KDC after the starttime has been reached. However, in no case may the starttime, endtime, or renew- till time of a newly-issued postdated ticket extend beyond the renew-till time of the ticket-granting ticket.
要求された開始時刻が休むか、または過去に時間を示すなら、チケットの開始時刻は認証サーバの現在の時間に決められます。 _POSTDATEが将来、POSTDATEDオプションだけが指定されていないか、5月-POSTDATE旗がTGTに設定されないで、またまたは次に、誤りKDC_ERR_が指定されない時代に返されるのを示すなら。 さもなければ、チケットを与えるチケットでMAYPOSTDATE旗を設定すると、結果として起こるチケットは先日付を書かれるでしょう、そして、要求されたstarttimeは地方の分野の方針に対してチェックされます。 許容できるなら、チケットの開始時刻は要求された通り決められます、そして、INVALID旗は設定されます。 starttimeの後のKDCにそれを提示するのによる使用に達する前に先日付を書かれたチケットを有効にしなければなりません。 しかしながら、いいえがケースに入れるコネがそうするかもしれない、starttime、新譜の先日付を書かれたチケットの時間がチケットを与えるチケットの現金箱を取り替えている時間を超えたところまで広げる現金箱をendtimeするか、または取り替えてください。
If the ENC-TKT-IN-SKEY option has been specified and an additional ticket has been included in the request, the KDC will decrypt the additional ticket using the key for the server to which the additional ticket was issued and verify that it is a ticket-granting ticket. If the name of the requested server is missing from the request, the name of the client in the additional ticket will be used. Otherwise the name of the requested server will be compared to the name of the client in the additional ticket and if different, the request will be rejected. If the request succeeds, the session key from the additional ticket will be used to encrypt the new ticket that is issued instead of using the key of the server for which the new ticket will be used (This allows easy implementation of user-to- user authentication [6], which uses ticket-granting ticket session keys in lieu of secret server keys in situations where such secret
ENC-TKT IN SKEYオプションが指定されて、追加チケットが要求に含まれているなら、KDCは、追加チケットが発行されたサーバにキーを使用することで追加チケットを解読して、それがチケットを与えるチケットであることを確かめるでしょう。 要求されたサーバの名前が要求によってなくなると、追加チケットの中のクライアントの名前は使用されるでしょう。 さもなければ、要求されたサーバの名前は追加チケットの中にクライアントの名前と比較されるでしょう、そして、異なると、要求は拒絶されるでしょう。 要求が成功すると、追加チケットから主要なセッションは、新しいチケットが使用されるサーバのキーを使用することの代わりに発行される新しいチケットをコード化するのに使用されるでしょう。(これがユーザからユーザー認証への[6]の簡単な実現を許す、どれが状況における秘密のサーバキーの代わりにあれほど秘密であるところでチケットを与えるチケットセッションキーを使用するか。
Kohl & Neuman [Page 28] RFC 1510 Kerberos September 1993
コールとヌーマン[28ページ]のRFCの1510のケルベロスの1993年9月
keys could be easily compromised.).
キーが容易に妥協できた、)
If the name of the server in the ticket that is presented to the KDC as part of the authentication header is not that of the ticket- granting server itself, and the server is registered in the realm of the KDC, If the RENEW option is requested, then the KDC will verify that the RENEWABLE flag is set in the ticket and that the renew_till time is still in the future. If the VALIDATE option is rqeuested, the KDC will check that the starttime has passed and the INVALID flag is set. If the PROXY option is requested, then the KDC will check that the PROXIABLE flag is set in the ticket. If the tests succeed, the KDC will issue the appropriate new ticket.
チケットの中の認証ヘッダーの一部としてKDCに提示されているのが、サーバ自体を与えるチケットのものであり、サーバはKDCの分野に登録されます、IfということであるサーバではRENEWオプションが名前であるなら要求されて、次に、KDCが、RENEWABLE旗がチケットとそれに設定されることを確かめる、_まだ未来に、時間があるまで、更新してください。 VALIDATEオプションがrqeuestedされると、KDCは、starttimeが通ったのをチェックするでしょう、そして、INVALID旗は設定されます。 PROXYオプションが要求されると、KDCは、PROXIABLE旗がチケットの中に設定されるのをチェックするでしょう。 テストが成功すると、KDCは適切な新しいチケットを発行するでしょう。
Whenever a request is made to the ticket-granting server, the presented ticket(s) is(are) checked against a hot-list of tickets which have been canceled. This hot-list might be implemented by storing a range of issue dates for "suspect tickets"; if a presented ticket had an authtime in that range, it would be rejected. In this way, a stolen ticket-granting ticket or renewable ticket cannot be used to gain additional tickets (renewals or otherwise) once the theft has been reported. Any normal ticket obtained before it was reported stolen will still be valid (because they require no interaction with the KDC), but only until their normal expiration time.
要求をチケットを与えるサーバにするときはいつも、提示されたチケットはホットリストに対してチェックされます(あります)。 このホットリストは「疑わしいチケット」のさまざまな問題日付を格納することによって、実行されるかもしれません。 提示されたチケットがその範囲にauthtimeを持っているなら、それは拒絶されるでしょうに。 このように、窃盗がいったん報告されたあとに追加チケット(更新であるかそうでない)を獲得するのに盗まれたチケットを与えるチケットか再生可能なものチケットを使用できません。 まだ有効であると(彼らがKDCとの相互作用を全く必要としないので)盗まれた状態で報告される前にもかかわらず、彼らの正常な満了時間までしか得られなかったどんな通常のチケット。
The ciphertext part of the response in the KRB_TGS_REP message is encrypted in the sub-session key from the Authenticator, if present, or the session key key from the ticket-granting ticket. It is not encrypted using the client's secret key. Furthermore, the client's key's expiration date and the key version number fields are left out since these values are stored along with the client's database record, and that record is not needed to satisfy a request based on a ticket-granting ticket. See section A.6 for pseudocode.
KRB_TGS_REPメッセージにおける応答の暗号文部分はAuthenticatorから主要で、現在のサブセッション、またはチケットを与えるチケットから主要なセッションキーでコード化されます。 それは、クライアントの秘密鍵を使用することでコード化されていません。 その上、これらの値がクライアントのデータベース・レコードと共に格納されるので、クライアントのキーの有効期限と主要なバージョンナンバーフィールドは省かれます、そして、その記録はチケットを与えるチケットに基づく要望に応じるのに必要ではありません。 擬似コードに関してセクションA.6を見てください。
3.3.3.1. Encoding the transited field
3.3.3.1. 通過している分野をコード化します。
If the identity of the server in the TGT that is presented to the KDC as part of the authentication header is that of the ticket-granting service, but the TGT was issued from another realm, the KDC will look up the inter-realm key shared with that realm and use that key to decrypt the ticket. If the ticket is valid, then the KDC will honor the request, subject to the constraints outlined above in the section describing the AS exchange. The realm part of the client's identity will be taken from the ticket-granting ticket. The name of the realm that issued the ticket-granting ticket will be added to the transited field of the ticket to be issued. This is accomplished by reading the transited field from the ticket-granting ticket (which is treated as an unordered set of realm names), adding the new realm to the set,
認証ヘッダーの一部としてKDCに寄贈されるTGTのサーバのアイデンティティがチケットを与えるサービスのものですが、TGTが別の分野に起こされたなら、KDCはチケットを解読するためにそんなに主要なその分野と使用と共有された相互分野キーを見上げるでしょう。 チケットが有効であるなら、KDCは上にAS交換について説明するセクションで概説された規制を条件として要求を光栄に思うでしょう。 チケットを与えるチケットからクライアントのアイデンティティの分野の部分を取るでしょう。 チケットを与えるチケットを発行した分野の名前は発行されるチケットの通過している分野に加えられるでしょう。 これはチケットを与えるチケット(順不同のセットの分野名として扱われる)から通過している分野を読むことによって、達成されます、新しい分野をセットに追加して
Kohl & Neuman [Page 29] RFC 1510 Kerberos September 1993
コールとヌーマン[29ページ]のRFCの1510のケルベロスの1993年9月
then constructing and writing out its encoded (shorthand) form (this may involve a rearrangement of the existing encoding).
次に、コード化された(速記)書式(これは既存のコード化の配列換えにかかわるかもしれない)を構成して、書き上げます。
Note that the ticket-granting service does not add the name of its own realm. Instead, its responsibility is to add the name of the previous realm. This prevents a malicious Kerberos server from intentionally leaving out its own name (it could, however, omit other realms' names).
チケットを与えるサービスがそれ自身の分野の名前を加えないことに注意してください。 代わりに、責任は前の分野の名前を加えることです。 これは、悪意があるケルベロスサーバが故意にそれ自身の名前を省くのを防ぎます(しかしながら、それは他の分野の名前を省略するかもしれません)。
The names of neither the local realm nor the principal's realm are to be included in the transited field. They appear elsewhere in the ticket and both are known to have taken part in authenticating the principal. Since the endpoints are not included, both local and single-hop inter-realm authentication result in a transited field that is empty.
どちらも地方の分野か校長の分野の名前は通過している分野に含まれることです。 それらは、チケットの中のほかの場所に見えて、校長を認証するのに参加したのがともに知られています。 終点が含まれていないので、ともに地方の、そして、単一のホップの相互分野認証は人影がない通過している分野をもたらします。
Because the name of each realm transited is added to this field, it might potentially be very long. To decrease the length of this field, its contents are encoded. The initially supported encoding is optimized for the normal case of inter-realm communication: a hierarchical arrangement of realms using either domain or X.500 style realm names. This encoding (called DOMAIN-X500-COMPRESS) is now described.
通過されたそれぞれの分野の名前がこの分野に加えられるので、それは潜在的に非常に長いかもしれません。 この分野の長さを減少させるために、内容はコード化されます。 初めは支持されたコード化は相互分野コミュニケーションの正常なケースのために最適化されます: ドメインかX.500スタイル分野名のどちらかを使用する分野の階層的配列。 このコード化(DOMAIN-X500-COMPRESSと呼ばれる)は現在、説明されます。
Realm names in the transited field are separated by a ",". The ",",
"\", trailing "."s, and leading spaces (" ") are special characters,
and if they are part of a realm name, they must be quoted in the
transited field by preceding them with a "\".
「通過している分野の分野名はa」によって切り離されます」 「The」、」、引きずる「\」、「s、および主な空間、(「「)、特殊文字と「\」でそれらに先行することによってそれらが分野名の一部、通過している分野でそれらを引用しなければならないということであるかどうかということである、」
A realm name ending with a "." is interpreted as being prepended to the previous realm. For example, we can encode traversal of EDU, MIT.EDU, ATHENA.MIT.EDU, WASHINGTON.EDU, and CS.WASHINGTON.EDU as:
「a」がある分野名前結末」は、前の分野にprependedされながら、解釈されます。 例えば、私たちは以下としてEDU、MIT.EDU、ATHENA.MIT.EDU、WASHINGTON.EDU、およびCS.WASHINGTON.EDUの縦断をコード化できます。
"EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.".
「EDU、MIT、アテーナー、WASHINGTON.EDU、Cs、」
Note that if ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were endpoints, that they would not be included in this field, and we would have:
それらがこの分野に含まれていなくて、私たちが含まれていただろうというATHENA.MIT.EDU、またはCS.WASHINGTON.EDUであるなら終点であったメモ:
"EDU,MIT.,WASHINGTON.EDU"
「EDU、MIT、WASHINGTON.EDU、」
A realm name beginning with a "/" is interpreted as being appended to
the previous realm (For the purpose of appending, the realm preceding
the first listed realm is considered to be the null realm ("")). If
it is to stand by itself, then it should be preceded by a space ("
"). For example, we can encode traversal of /COM/HP/APOLLO, /COM/HP,
/COM, and /COM/DEC as:
「a」/で始まる分野名」が前の分野に追加しながら解釈される、(追加の目的のために、最初の記載された分野に先行する分野がヌル分野であると考えられる、(「「)。」 それがそれ自体のそばにあるつもりであるならスペースがそれに先行するべきである、(「「)、」 例えば、私たちは以下として/COM/HP/APOLLO、/COM/HP、/COM、および/COM/DECの縦断をコード化できます。
"/COM,/HP,/APOLLO, /COM/DEC".
「/COM、/hp、/アポロ、/COM/DEC。」
Kohl & Neuman [Page 30] RFC 1510 Kerberos September 1993
コールとヌーマン[30ページ]のRFCの1510のケルベロスの1993年9月
Like the example above, if /COM/HP/APOLLO and /COM/DEC are endpoints, they they would not be included in this field, and we would have:
/COM/HP/APOLLOと/COM/DECは終点であり、それらはそれらです。上記の例のようにこの分野に含まれていなくて、私たちは含まれていたでしょう:
"/COM,/HP"
「/COM、/hp」
A null subfield preceding or following a "," indicates that all realms between the previous realm and the next realm have been traversed (For the purpose of interpreting null subfields, the client's realm is considered to precede those in the transited field, and the server's realm is considered to follow them.). Thus, "," means that all realms along the path between the client and the server have been traversed. ",EDU, /COM," means that that all realms from the client's realm up to EDU (in a domain style hierarchy) have been traversed, and that everything from /COM down to the server's realm in an X.500 style has also been traversed. This could occur if the EDU realm in one hierarchy shares an inter-realm key directly with the /COM realm in another hierarchy.
「aに先行するか、または続くヌル部分体」、」 前の分野と次の分野の間のすべての分野が横断されたのを示します(ヌル部分体を解釈する目的のために、クライアントの分野が通過している分野でそれらに先行すると考えられて、サーバの分野がそれらに続くと考えられます。)。 」 「このようにして、」手段、横断されています。 「EDU、/COM」、クライアントの分野からのすべての分野がEDU(ドメインスタイル階層構造の)に上げるそれが横断されて、また、/COMからX.500スタイルのサーバの分野までのそのすべてが横断されたことを意味します。 1つの階層構造のEDU分野が直接/COM分野のために別の階層構造で主要な相互分野を共有するなら、これは起こるかもしれません。
3.3.4. Receipt of KRB_TGS_REP message
3.3.4. KRB_TGS_REPメッセージの領収書
When the KRB_TGS_REP is received by the client, it is processed in the same manner as the KRB_AS_REP processing described above. The primary difference is that the ciphertext part of the response must be decrypted using the session key from the ticket-granting ticket rather than the client's secret key. See section A.7 for pseudocode.
KRB_TGS_REPがクライアントによって受け取られるとき、それは上で説明されたKRB_AS_REP処理と同じ方法で処理されます。 第一の違いはクライアントの秘密鍵よりむしろチケットを与えるチケットから主要なセッションを使用することで応答の暗号文部分を解読しなければならないということです。 擬似コードに関してセクションA.7を見てください。
3.4. The KRB_SAFE Exchange
3.4. KRBの_の安全な交換
The KRB_SAFE message may be used by clients requiring the ability to detect modifications of messages they exchange. It achieves this by including a keyed collisionproof checksum of the user data and some control information. The checksum is keyed with an encryption key (usually the last key negotiated via subkeys, or the session key if no negotiation has occured).
KRB_SAFEメッセージはそれらが交換するメッセージの変更を検出する能力を必要とするクライアントによって使用されるかもしれません。 それは、利用者データと何らかの制御情報の合わせられたcollisionproofチェックサムを含んでいることによって、これを達成します。 チェックサムは暗号化キーで合わせられます(通常、最後のキーがサブキーを通して交渉されたか、またはセッションキーは交渉でないならoccuredされました)。
3.4.1. Generation of a KRB_SAFE message
3.4.1. KRB_SAFEメッセージの世代
When an application wishes to send a KRB_SAFE message, it collects its data and the appropriate control information and computes a checksum over them. The checksum algorithm should be some sort of keyed one-way hash function (such as the RSA-MD5-DES checksum algorithm specified in section 6.4.5, or the DES MAC), generated using the sub-session key if present, or the session key. Different algorithms may be selected by changing the checksum type in the message. Unkeyed or non-collision-proof checksums are not suitable for this use.
アプリケーションがKRB_SAFEメッセージを送りたがっているとき、それは、データと適切な制御情報を集めて、それらの上でチェックサムを計算します。 チェックサムアルゴリズムは、主要な、しかし、現在のサブセッションを使用することで発生するある種の合わせられた片道ハッシュ関数(セクション6.4.5、またはDES MACで指定されたRSA-MD5-DESチェックサムアルゴリズムなどの)かセッションキーであるべきです。 異なったアルゴリズムは、メッセージでチェックサムタイプを変えることによって、選択されるかもしれません。 Unkeyedされるか耐非衝突のチェックサムはこの使用に適していません。
The control information for the KRB_SAFE message includes both a
KRB_SAFEメッセージのための制御情報は両方を含んでいます。
Kohl & Neuman [Page 31] RFC 1510 Kerberos September 1993
コールとヌーマン[31ページ]のRFCの1510のケルベロスの1993年9月
timestamp and a sequence number. The designer of an application using the KRB_SAFE message must choose at least one of the two mechanisms. This choice should be based on the needs of the application protocol.
タイムスタンプと一連番号。 KRB_SAFEメッセージを使用するアプリケーションのデザイナーは少なくとも2つのメカニズムの1つを選ばなければなりません。この選択はアプリケーション・プロトコルの必要性に基づくべきです。
Sequence numbers are useful when all messages sent will be received by one's peer. Connection state is presently required to maintain the session key, so maintaining the next sequence number should not present an additional problem.
メッセージが送ったすべてが人の同輩によって受け取られるとき、一連番号は役に立ちます。 接続状態は現在、次の一連番号が追加問題を提示するべきでないように、主要で、そう維持しているセッションを維持しなければなりません。
If the application protocol is expected to tolerate lost messages without them being resent, the use of the timestamp is the appropriate replay detection mechanism. Using timestamps is also the appropriate mechanism for multi-cast protocols where all of one's peers share a common sub-session key, but some messages will be sent to a subset of one's peers.
アプリケーション・プロトコルがそれらのない再送される無くなっているメッセージを許容すると予想されるなら、タイムスタンプの使用は適切な再生検出メカニズムです。 また、タイムスタンプを使用するのは、人の同輩が皆、一般的なサブセッションキーを共有するマルチキャストプロトコルのための適切な手段ですが、人の同輩の部分集合にいくつかのメッセージを送るでしょう。
After computing the checksum, the client then transmits the information and checksum to the recipient in the message format specified in section 5.6.1.
そして、チェックサムを計算した後に、クライアントはセクション5.6.1で指定されたメッセージ・フォーマットで情報とチェックサムを受取人に伝えます。
3.4.2. Receipt of KRB_SAFE message
3.4.2. KRB_SAFEメッセージの領収書
When an application receives a KRB_SAFE message, it verifies it as follows. If any error occurs, an error code is reported for use by the application.
アプリケーションがKRB_SAFEメッセージを受け取るとき、それは以下の通りそれについて確かめます。 何か誤りが発生するなら、エラーコードは使用のためにアプリケーションで報告されます。
The message is first checked by verifying that the protocol version and type fields match the current version and KRB_SAFE, respectively. A mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The application verifies that the checksum used is a collisionproof keyed checksum, and if it is not, a KRB_AP_ERR_INAPP_CKSUM error is generated. The recipient verifies that the operating system's report of the sender's address matches the sender's address in the message, and (if a recipient address is specified or the recipient requires an address) that one of the recipient's addresses appears as the recipient's address in the message. A failed match for either case generates a KRB_AP_ERR_BADADDR error. Then the timestamp and usec and/or the sequence number fields are checked. If timestamp and usec are expected and not present, or they are present but not current, the KRB_AP_ERR_SKEW error is generated. If the server name, along with the client name, time and microsecond fields from the Authenticator match any recently-seen such tuples, the KRB_AP_ERR_REPEAT error is generated. If an incorrect sequence number is included, or a sequence number is expected but not present, the KRB_AP_ERR_BADORDER error is generated. If neither a timestamp and usec or a sequence number is present, a KRB_AP_ERR_MODIFIED error is generated.
プロトコルバージョンとタイプ分野がそれぞれ最新版とKRB_SAFEに合っていることを確かめることによって、メッセージは最初に、チェックされます。 ミスマッチは、KRB_AP_がERR_BADVERSIONかKRB_AP_ERR_エムエスジー_TYPE誤りであると生成します。 アプリケーションは、使用されるチェックサムがcollisionproofがチェックサムを合わせたということであることを確かめます、そして、それがそうでないなら、KRB_AP_ERR_INAPP_CKSUM誤りは発生しています。 受取人は、オペレーティングシステムの送付者のレポートが、マッチがメッセージの送付者のアドレスと、(受取人アドレスが指定されるか、または受取人がアドレスを必要とするなら)それであると扱うことを確かめます。受取人のアドレスの1つはメッセージの受取人のアドレスとして現れます。 どちらかのケースのための失敗したマッチは、KRB_AP_がERR_BADADDR誤りであると生成します。 そして、タイムスタンプとusec、そして/または、一連番号分野はチェックされます。 それらがタイムスタンプとusecが予想されていて存在していないか、現在にもかかわらず、またはよく見られないなら、KRB_AP_ERR_SKEW誤りは発生しています。 時間とマイクロセカンドがクライアント名と共にAuthenticatorからさばくサーバー名が最近見られた状態でいずれかにも合っているなら、そのようなtuples、KRB_AP_ERR_REPEAT誤りは発生しています。 一連番号が不正確な一連番号が含まれているか、予想されていますが、または存在していないなら、KRB_AP_ERR_BADORDER誤りは発生しています。 タイムスタンプとusecも一連番号も存在していないなら、KRB_AP_ERR_MODIFIED誤りは発生しています。
Kohl & Neuman [Page 32] RFC 1510 Kerberos September 1993
コールとヌーマン[32ページ]のRFCの1510のケルベロスの1993年9月
Finally, the checksum is computed over the data and control information, and if it doesn't match the received checksum, a KRB_AP_ERR_MODIFIED error is generated.
最終的に、チェックサムはデータと制御情報に関して計算されます、そして、容認されたチェックサムを合わせないなら、KRB_AP_ERR_MODIFIED誤りは発生しています。
If all the checks succeed, the application is assured that the message was generated by its peer and was not modified in transit.
すべてのチェックが成功するなら、アプリケーションはメッセージが同輩によって生成されて、トランジットで変更されなかったことが保証されます。
3.5. The KRB_PRIV Exchange
3.5. KRB_PRIV交換
The KRB_PRIV message may be used by clients requiring confidentiality and the ability to detect modifications of exchanged messages. It achieves this by encrypting the messages and adding control information.
KRB_PRIVメッセージは秘密性と交換されたメッセージの変更を検出する能力を必要とするクライアントによって使用されるかもしれません。 それは、メッセージを暗号化して、制御情報を加えることによって、これを達成します。
3.5.1. Generation of a KRB_PRIV message
3.5.1. KRB_PRIVメッセージの世代
When an application wishes to send a KRB_PRIV message, it collects its data and the appropriate control information (specified in section 5.7.1) and encrypts them under an encryption key (usually the last key negotiated via subkeys, or the session key if no negotiation has occured). As part of the control information, the client must choose to use either a timestamp or a sequence number (or both); see the discussion in section 3.4.1 for guidelines on which to use. After the user data and control information are encrypted, the client transmits the ciphertext and some "envelope" information to the recipient.
アプリケーションがKRB_PRIVメッセージを送りたがっているとき、それは、データと適切な制御情報(セクション5.7.1では、指定される)を集めて、暗号化キーの下でそれらを暗号化します(通常、最後のキーがサブキーを通して交渉されたか、またはセッションキーは交渉でないならoccuredされました)。 制御情報の一部として、クライアントは、タイムスタンプか一連番号のどちらかを使用するのを選ばなければなりません(ともに)。 ガイドラインのためのセクション3.4.1における議論が進行中であるのを見てください、どれを使用するか。 利用者データと制御情報が暗号化されていた後に、クライアントは暗号文と何らかの「封筒」情報を受取人に伝えます。
3.5.2. Receipt of KRB_PRIV message
3.5.2. KRB_PRIVメッセージの領収書
When an application receives a KRB_PRIV message, it verifies it as follows. If any error occurs, an error code is reported for use by the application.
アプリケーションがKRB_PRIVメッセージを受け取るとき、それは以下の通りそれについて確かめます。 何か誤りが発生するなら、エラーコードは使用のためにアプリケーションで報告されます。
The message is first checked by verifying that the protocol version and type fields match the current version and KRB_PRIV, respectively. A mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The application then decrypts the ciphertext and processes the resultant plaintext. If decryption shows the data to have been modified, a KRB_AP_ERR_BAD_INTEGRITY error is generated. The recipient verifies that the operating system's report of the sender's address matches the sender's address in the message, and (if a recipient address is specified or the recipient requires an address) that one of the recipient's addresses appears as the recipient's address in the message. A failed match for either case generates a KRB_AP_ERR_BADADDR error. Then the timestamp and usec and/or the sequence number fields are checked. If timestamp and usec are expected and not present, or they are present but not current, the KRB_AP_ERR_SKEW error is generated. If the server name, along with
プロトコルバージョンとタイプ分野がそれぞれ最新版とKRB_PRIVに合っていることを確かめることによって、メッセージは最初に、チェックされます。 ミスマッチは、KRB_AP_がERR_BADVERSIONかKRB_AP_ERR_エムエスジー_TYPE誤りであると生成します。 アプリケーションは、次に、暗号文を解読して、結果の平文を処理します。 復号化が変更されたためにデータを示しているなら、KRB_AP_ERR_BAD_INTEGRITY誤りは発生しています。 受取人は、オペレーティングシステムの送付者のレポートが、マッチがメッセージの送付者のアドレスと、(受取人アドレスが指定されるか、または受取人がアドレスを必要とするなら)それであると扱うことを確かめます。受取人のアドレスの1つはメッセージの受取人のアドレスとして現れます。 どちらかのケースのための失敗したマッチは、KRB_AP_がERR_BADADDR誤りであると生成します。 そして、タイムスタンプとusec、そして/または、一連番号分野はチェックされます。 それらがタイムスタンプとusecが予想されていて存在していないか、現在にもかかわらず、またはよく見られないなら、KRB_AP_ERR_SKEW誤りは発生しています。 サーバー名であるなら
Kohl & Neuman [Page 33] RFC 1510 Kerberos September 1993
コールとヌーマン[33ページ]のRFCの1510のケルベロスの1993年9月
the client name, time and microsecond fields from the Authenticator match any recently-seen such tuples, the KRB_AP_ERR_REPEAT error is generated. If an incorrect sequence number is included, or a sequence number is expected but not present, the KRB_AP_ERR_BADORDER error is generated. If neither a timestamp and usec or a sequence number is present, a KRB_AP_ERR_MODIFIED error is generated.
Authenticatorからのクライアント名、時間、およびマイクロセカンド分野はどんな最近目にふれているそのようなtuplesにも合って、KRB_AP_ERR_REPEAT誤りは発生しています。 一連番号が不正確な一連番号が含まれているか、予想されていますが、または存在していないなら、KRB_AP_ERR_BADORDER誤りは発生しています。 タイムスタンプとusecも一連番号も存在していないなら、KRB_AP_ERR_MODIFIED誤りは発生しています。
If all the checks succeed, the application can assume the message was generated by its peer, and was securely transmitted (without intruders able to see the unencrypted contents).
すべてのチェックが成功するなら、アプリケーションは、メッセージが同輩によって生成されて、しっかりと送られた(非暗号化されたコンテンツを見ることができる侵入者なしで)と仮定できます。
3.6. The KRB_CRED Exchange
3.6. KRB_信用交換
The KRB_CRED message may be used by clients requiring the ability to send Kerberos credentials from one host to another. It achieves this by sending the tickets together with encrypted data containing the session keys and other information associated with the tickets.
KRB_CREDメッセージは1人のホストから別のものにケルベロス資格証明書を送る能力を必要とするクライアントによって使用されるかもしれません。 それは、セッションキーを含む暗号化されたデータとチケットに関連している他の情報と共にチケットを送ることによって、これを達成します。
3.6.1. Generation of a KRB_CRED message
3.6.1. KRB_CREDメッセージの世代
When an application wishes to send a KRB_CRED message it first (using the KRB_TGS exchange) obtains credentials to be sent to the remote host. It then constructs a KRB_CRED message using the ticket or tickets so obtained, placing the session key needed to use each ticket in the key field of the corresponding KrbCredInfo sequence of the encrypted part of the the KRB_CRED message.
アプリケーションがKRB_CREDメッセージを送りたがっているとき、それは最初に、リモートホストに送られる資格証明書を得ます(KRB_TGS交換を使用します)。 次に、それはそのように得られたチケットかチケットを使用することでKRB_CREDメッセージを構成します、KRB_CREDメッセージの暗号化された部分の対応するKrbCredInfo系列のキーフィールドに各チケットを使用するのに必要であるセッションキーを置いて。
Other information associated with each ticket and obtained during the KRB_TGS exchange is also placed in the corresponding KrbCredInfo sequence in the encrypted part of the KRB_CRED message. The current time and, if specifically required by the application the nonce, s- address, and raddress fields, are placed in the encrypted part of the KRB_CRED message which is then encrypted under an encryption key previosuly exchanged in the KRB_AP exchange (usually the last key negotiated via subkeys, or the session key if no negotiation has occured).
また、各チケットに関連づけられて、KRB_TGS交換の間に得られた他の情報はKRB_CREDメッセージの暗号化された部分に対応するKrbCredInfo系列に置かれます。 電流は調節されます、そして、アプリケーションで明確に必要であるなら、一回だけ、sアドレス、およびraddress野原は次に主要なpreviosulyがKRB_AP交換で交換した暗号化で暗号化されるKRB_CREDメッセージの暗号化された部分に置かれます(通常、最後のキーがサブキーを通して交渉されたか、またはセッションキーは交渉でないならoccuredされました)。
3.6.2. Receipt of KRB_CRED message
3.6.2. KRB_CREDメッセージの領収書
When an application receives a KRB_CRED message, it verifies it. If any error occurs, an error code is reported for use by the application. The message is verified by checking that the protocol version and type fields match the current version and KRB_CRED, respectively. A mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The application then decrypts the ciphertext and processes the resultant plaintext. If decryption shows the data to have been modified, a KRB_AP_ERR_BAD_INTEGRITY error is generated.
アプリケーションがKRB_CREDメッセージを受け取るとき、それはそれについて確かめます。 何か誤りが発生するなら、エラーコードは使用のためにアプリケーションで報告されます。 プロトコルバージョンとタイプ分野がそれぞれ最新版とKRB_CREDに合っているのをチェックすることによって、メッセージは確かめられます。 ミスマッチは、KRB_AP_がERR_BADVERSIONかKRB_AP_ERR_エムエスジー_TYPE誤りであると生成します。 アプリケーションは、次に、暗号文を解読して、結果の平文を処理します。 復号化が変更されたためにデータを示しているなら、KRB_AP_ERR_BAD_INTEGRITY誤りは発生しています。
Kohl & Neuman [Page 34] RFC 1510 Kerberos September 1993
コールとヌーマン[34ページ]のRFCの1510のケルベロスの1993年9月
If present or required, the recipient verifies that the operating system's report of the sender's address matches the sender's address in the message, and that one of the recipient's addresses appears as the recipient's address in the message. A failed match for either case generates a KRB_AP_ERR_BADADDR error. The timestamp and usec fields (and the nonce field if required) are checked next. If the timestamp and usec are not present, or they are present but not current, the KRB_AP_ERR_SKEW error is generated.
現在である、または必要であるなら、受取人は送付者のアドレスに関するオペレーティングシステムのレポートがメッセージの送付者のアドレスに合って、受取人のアドレスの1つがメッセージの受取人のアドレスとして現れることを確かめます。 どちらかのケースのための失敗したマッチは、KRB_AP_がERR_BADADDR誤りであると生成します。 そして、タイムスタンプとusec分野、(必要なら、一回だけがさばく、)、次に、チェックされます。 それらがタイムスタンプとusecが存在していないか、現在にもかかわらず、またはよく見られないなら、KRB_AP_ERR_SKEW誤りは発生しています。
If all the checks succeed, the application stores each of the new tickets in its ticket cache together with the session key and other information in the corresponding KrbCredInfo sequence from the encrypted part of the KRB_CRED message.
すべてのチェックが成功するなら、アプリケーションは対応するKrbCredInfo系列のセッションの主要で他の情報と共にKRB_CREDメッセージの暗号化された部分からチケットキャッシュでそれぞれの新しいチケットを保存します。
4. The Kerberos Database
4. ケルベロスデータベース
The Kerberos server must have access to a database containing the principal identifiers and secret keys of principals to be authenticated (The implementation of the Kerberos server need not combine the database and the server on the same machine; it is feasible to store the principal database in, say, a network name service, as long as the entries stored therein are protected from disclosure to and modification by unauthorized parties. However, we recommend against such strategies, as they can make system management and threat analysis quite complex.).
ケルベロスサーバは、認証されるために主体の主要な識別子を含むデータベースと秘密鍵に近づく手段を持たなければなりません。(ケルベロスサーバの実装は同じマシンの上でデータベースとサーバを結合する必要はありません。 たとえば、主要なデータベースを蓄えるのは可能です、ネットワーク名サービス、そこに保存されたエントリーが権限のないパーティーによる公開と変更から保護される限り。 しかしながら、システム管理と脅威分析がそれらでかなり複雑になる場合があるように私たちはそのようなものに対して戦略を推薦します。).
4.1. Database contents
4.1. データベースコンテンツ
A database entry should contain at least the following fields:
データベースエントリーは少なくとも以下の分野を含むべきです:
Field Value
分野値
name Principal's identifier
key Principal's secret key
p_kvno Principal's key version
max_life Maximum lifetime for Tickets
max_renewable_life Maximum total lifetime for renewable
Tickets
再生可能なもののためのTicketsの最大_再生可能なものの_の寿命のMaximumの総生涯のためのプリンシパルの識別子主要なプリンシパルの秘密の主要なp_kvnoプリンシパルの主要なバージョン最大_寿命Maximum生涯をTicketsと命名してください。
The name field is an encoding of the principal's identifier. The key field contains an encryption key. This key is the principal's secret key. (The key can be encrypted before storage under a Kerberos "master key" to protect it in case the database is compromised but the master key is not. In that case, an extra field must be added to indicate the master key version used, see below.) The p_kvno field is the key version number of the principal's secret key. The max_life field contains the maximum allowable lifetime (endtime - starttime) for any Ticket issued for this principal. The max_renewable_life
名前欄は主体の識別子のコード化です。 キーフィールドは暗号化キーを含んでいます。 このキーは主体の秘密鍵です。 (ストレージの前にデータベースが感染されるといけないのでそれを保護するためにケルベロス「マスターキー」の下でキーを暗号化できますが、マスターキーは暗号化されるというわけではありません。 その場合、マスターキーバージョンが使用されて、以下を見るように示すために付加的な分野を加えなければなりません。) p_kvno分野は主体の秘密鍵の主要なバージョン番号です。 最大_寿命分野は最大のこの主体のために発行されたどんなTicketにおいても、許容できる生涯(endtime--starttime)を含んでいます。 最大_再生可能なもの_の寿命
Kohl & Neuman [Page 35] RFC 1510 Kerberos September 1993
コールとヌーマン[35ページ]のRFCの1510のケルベロスの1993年9月
field contains the maximum allowable total lifetime for any renewable Ticket issued for this principal. (See section 3.1 for a description of how these lifetimes are used in determining the lifetime of a given Ticket.)
分野は最大のこの主体のために発行されたどんな再生可能なものTicketにおいても、許容できる総生涯を含んでいます。 (これらの寿命が与えられたTicketの生涯を決定する際にどう費やされるかに関する記述に関してセクション3.1を見てください。)
A server may provide KDC service to several realms, as long as the database representation provides a mechanism to distinguish between principal records with identifiers which differ only in the realm name.
サーバはいくつかの分野に対するサービスをKDCに供給するかもしれません、データベース表現が分野名だけにおいて異なる識別子がある主要な記録を見分けるためにメカニズムを提供する限り。
When an application server's key changes, if the change is routine (i.e., not the result of disclosure of the old key), the old key should be retained by the server until all tickets that had been issued using that key have expired. Because of this, it is possible for several keys to be active for a single principal. Ciphertext encrypted in a principal's key is always tagged with the version of the key that was used for encryption, to help the recipient find the proper key for decryption.
変化が日常的であるならアプリケーション・サーバーのキーが変化するとき(すなわち、古いキーの公開の結果でない)、そのキーを使用することで発行されたすべてのチケットが期限が切れるまで、古いキーはサーバによって保有されるべきです。 これのために、ただ一つの元本に、数個のキーがアクティブであることは、可能です。 主体のキーで暗号化された暗号文はいつも暗号化に使用されたキーのバージョンでタグ付けをされて、受取人が復号化に関して適切なキーを見つけるのを助けます。
When more than one key is active for a particular principal, the principal will have more than one record in the Kerberos database. The keys and key version numbers will differ between the records (the rest of the fields may or may not be the same). Whenever Kerberos issues a ticket, or responds to a request for initial authentication, the most recent key (known by the Kerberos server) will be used for encryption. This is the key with the highest key version number.
特定の元本に、1個以上のキーがアクティブであるときに、校長には、ケルベロスデータベースでの1つ以上の記録があるでしょう。 キーと主要なバージョン番号は記録の間で異なるでしょう(分野の残りは同じであるかもしれません)。 ケルベロスがチケットを発行するか、または初期の認証を求める要求に応じるときはいつも、最新のキー(ケルベロスサーバによって知られている)は暗号化に使用されるでしょう。 これは最も大きい主要なバージョン番号があるキーです。
4.2. Additional fields
4.2. 追加分野
Project Athena's KDC implementation uses additional fields in its database:
プロジェクトアティナのKDC実装はデータベースで追加分野を使用します:
Field Value
分野値
K_kvno Kerberos' key version expiration Expiration date for entry attributes Bit field of attributes mod_date Timestamp of last modification mod_name Modifying principal's identifier
K_kvnoケルベロスのBitがさばく_最後の変更モッズ_名前Modifying主体の識別子の属性モッズ日付Timestampのエントリー属性の主要なバージョン満了Expiration期日
The K_kvno field indicates the key version of the Kerberos master key under which the principal's secret key is encrypted.
K_kvno分野は主体の秘密鍵が暗号化されているケルベロスマスターキーの主要なバージョンを示します。
After an entry's expiration date has passed, the KDC will return an error to any client attempting to gain tickets as or for the principal. (A database may want to maintain two expiration dates: one for the principal, and one for the principal's current key. This allows password aging to work independently of the principal's
エントリーの有効期限が経過した後に、KDCは主体か主体のチケットを獲得するのを試みるどんなクライアントにも誤りを返すでしょう。 (データベースは2つの有効期限を維持したがっているかもしれません: 主体のためのもの、および主体の現在のキーのためのもの、これは、パスワードの年をとることが主体の如何にかかわらず働くのを許容します。
Kohl & Neuman [Page 36] RFC 1510 Kerberos September 1993
コールとヌーマン[36ページ]のRFCの1510のケルベロスの1993年9月
expiration date. However, due to the limited space in the responses, the KDC must combine the key expiration and principal expiration date into a single value called "key_exp", which is used as a hint to the user to take administrative action.)
有効期限。 しかしながら、応答における限られたスペースのため、KDCは管理行動を取るのにヒントとしてユーザに使用される「キー_exp」と呼ばれるただ一つの値に主要な満了と主要な有効期限を結合しなければなりません。)
The attributes field is a bitfield used to govern the operations involving the principal. This field might be useful in conjunction with user registration procedures, for site-specific policy implementations (Project Athena currently uses it for their user registration process controlled by the system-wide database service, Moira [7]), or to identify the "string to key" conversion algorithm used for a principal's key. (See the discussion of the padata field in section 5.4.2 for details on why this can be useful.) Other bits are used to indicate that certain ticket options should not be allowed in tickets encrypted under a principal's key (one bit each): Disallow issuing postdated tickets, disallow issuing forwardable tickets, disallow issuing tickets based on TGT authentication, disallow issuing renewable tickets, disallow issuing proxiable tickets, and disallow issuing tickets for which the principal is the server.
属性分野は主体にかかわる操作を治めるのに使用されるbitfieldです。 この分野はユーザ登録手順に関連して役に立つかもしれません、サイト特定保険証券実装のために。(プロジェクトアテーナーは、現在、システム全体のデータベース・サービスで制御されたそれらのユーザ登録手続、モイラ[7])か主体のキーに使用される「キーへのストリング」変換アルゴリズムを特定するのにそれを使用します。 (これが役に立つ場合がある理由に関する詳細に関してセクション5.4.2における、padata分野の議論を見てください。) 他のビットはあるチケットオプションが主体のキー(それぞれ1ビット)の下で暗号化されたチケットの中に許容されるべきでないのを示すのに使用されます: 先日付を書かれたチケットを発行するのを禁じてください、そして、前進可能チケットを発行するのを禁じてください、そして、TGT認証に基づくチケットを発行するのを禁じてください、そして、再生可能なものチケットを発行するのを禁じてください、そして、proxiableチケットを発行するのを禁じてください、そして、主体がサーバであるチケットを発行するのを禁じてください。
The mod_date field contains the time of last modification of the entry, and the mod_name field contains the name of the principal which last modified the entry.
モッズ_年月日欄はエントリーの最後の変更の時間を含んでいます、そして、モッズ_名前欄は最後にエントリーを変更した校長の名前を含んでいます。
4.3. Frequently Changing Fields
4.3. 頻繁に職業を替えます。
Some KDC implementations may wish to maintain the last time that a request was made by a particular principal. Information that might be maintained includes the time of the last request, the time of the last request for a ticket-granting ticket, the time of the last use of a ticket-granting ticket, or other times. This information can then be returned to the user in the last-req field (see section 5.2).
いくつかのKDC実装が、最後の時間、特定の元本で要求をしたと主張したがっているかもしれません。 保守されるかもしれない情報は最後の要求の時間、チケットを与えるチケットを求める最後の要求の時間、チケットを与えるチケット、または他の回の最後の使用の時間を含んでいます。 そして、最後のreq分野のユーザにこの情報を返すことができます(セクション5.2を見てください)。
Other frequently changing information that can be maintained is the latest expiration time for any tickets that have been issued using each key. This field would be used to indicate how long old keys must remain valid to allow the continued use of outstanding tickets.
保守できる他の頻繁に変化している情報は各キーを使用することで発行されたどんなチケットのための最も遅い満了時間です。 この分野は、長く古いキーがどのように傑出しているチケットの継続的な使用を許すために有効なままで残らなければならないかを示すのに使用されるでしょう。
4.4. Site Constants
4.4. サイト定数
The KDC implementation should have the following configurable constants or options, to allow an administrator to make and enforce policy decisions:
KDC実装には、管理者が政策決定を作って、実施するのを許容するために、以下の構成可能な定数かオプションがあるべきです:
+ The minimum supported lifetime (used to determine whether the
KDC_ERR_NEVER_VALID error should be returned). This constant
should reflect reasonable expectations of round-trip time to the
+ 最小のサポートしている生涯、(以前はよく決定していた、__決してVALID誤りでないのがそうするべきであるKDC_ERR、返してください、) この定数は往復の時間への合理的な期待を反映するべきです。
Kohl & Neuman [Page 37] RFC 1510 Kerberos September 1993
コールとヌーマン[37ページ]のRFCの1510のケルベロスの1993年9月
KDC, encryption/decryption time, and processing time by the client
and target server, and it should allow for a minimum "useful"
lifetime.
KDC、暗号化/復号化時間、クライアントと目標サーバによる処理時間、およびそれは最小の「役に立つ」生涯を考慮するべきです。
+ The maximum allowable total (renewable) lifetime of a ticket
(renew_till - starttime).
+ チケット(starttimeに_現金箱を取り替える)の最大の許容できる総(再生可能なもの)生涯。
+ The maximum allowable lifetime of a ticket (endtime - starttime).
+ チケット(endtime--starttime)の最大の許容できる生涯。
+ Whether to allow the issue of tickets with empty address fields
(including the ability to specify that such tickets may only be
issued if the request specifies some authorization_data).
+、人影のないアドレス・フィールド(要求がいくつかの認可_データを指定する場合にだけそのようなチケットが発行されるかもしれないと指定する能力を含んでいる)があるチケットの問題を許容であるかどうか
+ Whether proxiable, forwardable, renewable or post-datable tickets
are to be issued.
proxiable、前進可能、再生可能なものまたはポスト時代を推定できるチケットであることにかかわらず+は発行されることになっています。
5. Message Specifications
5. メッセージ仕様
The following sections describe the exact contents and encoding of protocol messages and objects. The ASN.1 base definitions are presented in the first subsection. The remaining subsections specify the protocol objects (tickets and authenticators) and messages. Specification of encryption and checksum techniques, and the fields related to them, appear in section 6.
以下のセクションはプロトコルメッセージと物の正確なコンテンツとコード化について説明します。 ASN.1ベース定義は最初の小区分で提示されます。 残っている小区分はプロトコル物(チケットと固有識別文字)とメッセージを指定します。 暗号化の仕様、チェックサムのテクニック、およびそれらに関連する野原はセクション6に現れます。
5.1. ASN.1 Distinguished Encoding Representation
5.1. 表現をコード化しながら区別されたASN.1
All uses of ASN.1 in Kerberos shall use the Distinguished Encoding Representation of the data elements as described in the X.509 specification, section 8.7 [8].
ケルベロスにおける、ASN.1のすべての用途がX.509仕様(セクション8.7[8])で説明されるようにデータ要素のDistinguished Encoding Representationを使用するものとします。
5.2. ASN.1 Base Definitions
5.2. ASN.1基地の定義
The following ASN.1 base definitions are used in the rest of this section. Note that since the underscore character (_) is not permitted in ASN.1 names, the hyphen (-) is used in its place for the purposes of ASN.1 names.
以下のASN.1ベース定義はこのセクションの残りに使用されます。 強調キャラクタ(_)がASN.1名で受入れられないのでハイフン(-)がASN.1名の目的に場所で使用されることに注意してください。
Realm ::= GeneralString
PrincipalName ::= SEQUENCE {
name-type[0] INTEGER,
name-string[1] SEQUENCE OF GeneralString
}
分野:、:= GeneralString PrincipalName:、:= 系列名前タイプ[0]INTEGER、名前ストリング[1]SEQUENCE OF GeneralString
Kerberos realms are encoded as GeneralStrings. Realms shall not contain a character with the code 0 (the ASCII NUL). Most realms will usually consist of several components separated by periods (.), in the style of Internet Domain Names, or separated by slashes (/) in
ケルベロス分野はGeneralStringsとしてコード化されます。 分野はコード0(ASCII NUL)でキャラクタを含まないものとします。 通常、ほとんどの分野が周期的に切り離されている数個のコンポーネントから成る、()、Domain Namesの、または、中のスラッシュ(/)によって切り離されたインターネットのスタイル
Kohl & Neuman [Page 38] RFC 1510 Kerberos September 1993
コールとヌーマン[38ページ]のRFCの1510のケルベロスの1993年9月
the style of X.500 names. Acceptable forms for realm names are specified in section 7. A PrincipalName is a typed sequence of components consisting of the following sub-fields:
X.500名のスタイル。 分野名のための許容フォームはセクション7で指定されます。 PrincipalNameは以下のサブ分野から成るコンポーネントのタイプされた系列です:
name-type This field specifies the type of name that follows.
Pre-defined values for this field are
specified in section 7.2. The name-type should be
treated as a hint. Ignoring the name type, no two
names can be the same (i.e., at least one of the
components, or the realm, must be different).
This constraint may be eliminated in the future.
Thisがさばく名前タイプは従う名前のタイプを指定します。 この分野への事前に定義された値はセクション7.2で指定されます。 名前タイプはヒントとして扱われるべきです。 どんな2歳のタイプも挙げない名前を無視するのは同じである場合があります(すなわち、少なくともコンポーネント、または分野の1つは異なっているに違いありません)。 この規制は将来、取り除かれるかもしれません。
name-string This field encodes a sequence of components that
form a name, each component encoded as a General
String. Taken together, a PrincipalName and a Realm
form a principal identifier. Most PrincipalNames
will have only a few components (typically one or two).
名前ストリングThis分野は名前を形成するコンポーネント、String司令官としてコード化されたそれぞれのコンポーネントの系列をコード化します。 一緒に取って、PrincipalNameとRealmは主要な識別子を形成します。 ほとんどのPrincipalNamesには、ほんのいくつかのコンポーネント(通常1か2)があるでしょう。
KerberosTime ::= GeneralizedTime
-- Specifying UTC time zone (Z)
KerberosTime:、:= GeneralizedTime--UTCの時間帯を指定すること。(Z)
The timestamps used in Kerberos are encoded as GeneralizedTimes. An encoding shall specify the UTC time zone (Z) and shall not include any fractional portions of the seconds. It further shall not include any separators. Example: The only valid format for UTC time 6 minutes, 27 seconds after 9 pm on 6 November 1985 is 19851106210627Z.
ケルベロスで使用されるタイムスタンプはGeneralizedTimesとしてコード化されます。 コード化は、UTCの時間帯(Z)を指定して、秒のどんな断片的な部分も含んでいないものとします。 それはさらにどんな分離符も含んでいないものとします。 例: 27秒午後1985年11月6日9時以降6分間のUTC時間の唯一の有効な形式が19851106210627Zです。
HostAddress ::= SEQUENCE {
addr-type[0] INTEGER,
address[1] OCTET STRING
}
HostAddress:、:= 系列[1] [0] addr-タイプINTEGER、アドレスOCTET STRING
HostAddresses ::= SEQUENCE OF SEQUENCE {
addr-type[0] INTEGER,
address[1] OCTET STRING
}
HostAddresses:、:= 系列の系列[1] [0] addr-タイプINTEGER、アドレスOCTET STRING
The host adddress encodings consists of two fields:
ホストadddress encodingsは2つの分野から成ります:
addr-type This field specifies the type of address that
follows. Pre-defined values for this field are
specified in section 8.1.
Thisがさばくaddr-タイプは従うアドレスのタイプを指定します。 この分野への事前に定義された値はセクション8.1で指定されます。
address This field encodes a single address of type addr-type.
Thisがさばくアドレスはタイプaddr-タイプのただ一つのアドレスをコード化します。
The two forms differ slightly. HostAddress contains exactly one
2つのフォームが若干異なります。 HostAddressはちょうど1つを含んでいます。
Kohl & Neuman [Page 39] RFC 1510 Kerberos September 1993
コールとヌーマン[39ページ]のRFCの1510のケルベロスの1993年9月
address; HostAddresses contains a sequence of possibly many addresses.
アドレス。 HostAddressesはことによると多くのアドレスの系列を含んでいます。
AuthorizationData ::= SEQUENCE OF SEQUENCE {
ad-type[0] INTEGER,
ad-data[1] OCTET STRING
}
AuthorizationData:、:= 系列の系列[1] [0] 広告タイプINTEGER、広告データOCTET STRING
ad-data This field contains authorization data to be
interpreted according to the value of the
corresponding ad-type field.
Thisがさばく広告データは対応する広告タイプ分野の値に従って解釈されるべき認可データを含んでいます。
ad-type This field specifies the format for the ad-data
subfield. All negative values are reserved for
local use. Non-negative values are reserved for
registered use.
Thisがさばく広告タイプは広告データ部分体に形式を指定します。 すべての負の数が地方の使用のために予約されます。 非負の数は登録された使用のために予約されます。
APOptions ::= BIT STRING {
reserved(0),
use-session-key(1),
mutual-required(2)
}
APOptions:、:= ビット列予約された(0)、使用セッション主要な(1)、互いに必要な(2)
TicketFlags ::= BIT STRING {
reserved(0),
forwardable(1),
forwarded(2),
proxiable(3),
proxy(4),
may-postdate(5),
postdated(6),
invalid(7),
renewable(8),
initial(9),
pre-authent(10),
hw-authent(11)
}
TicketFlags:、:= ビット列予約された(0)(forwardable(1))が(2)を進めて、proxiable(3)、プロキシ(4)がそうするかもしれない、-、(5)に先日付を書いて、(6)、病人(7)、再生可能なもの(8)、authent(10)プレ初期の(9)hw-authent(11)に先日付を書きます。
KDCOptions ::= BIT STRING {
reserved(0),
forwardable(1),
forwarded(2),
proxiable(3),
proxy(4),
allow-postdate(5),
postdated(6),
KDCOptions:、:= BIT STRING、proxiable(3)、プロキシ(4)が予約された(0)(forwardable(1))に(2)を進めさせた、-、(5)に先日付を書いて、(6)に先日付を書きました。
Kohl & Neuman [Page 40] RFC 1510 Kerberos September 1993
コールとヌーマン[40ページ]のRFCの1510のケルベロスの1993年9月
unused7(7),
renewable(8),
unused9(9),
unused10(10),
unused11(11),
renewable-ok(27),
enc-tkt-in-skey(28),
renew(30),
validate(31)
}
unused7(7)、再生可能なもの(8)、unused9(9)、unused10(10)、unused11(11)、再生可能なもの間違いない(27)、skey(28)のenc-tkt、(30)を更新してください、そして、(31)を有効にしてください。
LastReq ::= SEQUENCE OF SEQUENCE {
lr-type[0] INTEGER,
lr-value[1] KerberosTime
}
LastReq:、:= 系列の系列[1] [0] lr-タイプINTEGER、lr-値のKerberosTime
lr-type This field indicates how the following lr-value
field is to be interpreted. Negative values indicate
that the information pertains only to the
responding server. Non-negative values pertain to
all servers for the realm.
Thisがさばくlr-タイプは解釈される以下のlr-値の分野がことである方法を示します。 負の数は、情報が応じるサーバだけに関係するのを示します。非負の数は分野へのすべてのサーバに関係します。
If the lr-type field is zero (0), then no information
is conveyed by the lr-value subfield. If the
absolute value of the lr-type field is one (1),
then the lr-value subfield is the time of last
initial request for a TGT. If it is two (2), then
the lr-value subfield is the time of last initial
request. If it is three (3), then the lr-value
subfield is the time of issue for the newest
ticket-granting ticket used. If it is four (4),
then the lr-value subfield is the time of the last
renewal. If it is five (5), then the lr-value
subfield is the time of last request (of any
type).
lr-タイプ分野が(0)でないなら、情報は全くlr-値の部分体によって伝えられません。 lr-タイプ分野の絶対値が1つ(1)であるなら、lr-値の部分体はTGTを求める姓のイニシャル要求の時間です。 それが2(2)であるなら、lr-値の部分体は姓のイニシャル要求の時間です。 それが3(3)であるなら、lr-値の部分体はチケットを与えるチケットが使用した中で最も新しいもののための問題の時間です。 それが4(4)であるなら、lr-値の部分体は最後の更新の時間です。 それが5(5)であるなら、lr-値の部分体は最後の要求(どんなタイプのも)の時間です。
lr-value This field contains the time of the last request.
The time must be interpreted according to the contents
of the accompanying lr-type subfield.
Thisがさばくlr-値は最後の要求の時間を含んでいます。 付随のlr-タイプ部分体のコンテンツに従って、時間を解釈しなければなりません。
See section 6 for the definitions of Checksum, ChecksumType, EncryptedData, EncryptionKey, EncryptionType, and KeyType.
Checksum、ChecksumType、EncryptedData、EncryptionKey、EncryptionType、およびKeyTypeの定義に関してセクション6を見てください。
Kohl & Neuman [Page 41] RFC 1510 Kerberos September 1993
コールとヌーマン[41ページ]のRFCの1510のケルベロスの1993年9月
5.3. Tickets and Authenticators
5.3. チケットと固有識別文字
This section describes the format and encryption parameters for tickets and authenticators. When a ticket or authenticator is included in a protocol message it is treated as an opaque object.
このセクションはチケットと固有識別文字のための形式と暗号化パラメタについて説明します。 チケットか固有識別文字がプロトコルメッセージに含まれているとき、それは不明瞭な物として扱われます。
5.3.1. Tickets
5.3.1. チケット
A ticket is a record that helps a client authenticate to a service. A Ticket contains the following information:
チケットはクライアントがaにサービスを認証するのを助ける記録です。 Ticketは以下の情報を含んでいます:
Ticket ::= [APPLICATION 1] SEQUENCE {
tkt-vno[0] INTEGER,
realm[1] Realm,
sname[2] PrincipalName,
enc-part[3] EncryptedData
}
-- Encrypted part of ticket
EncTicketPart ::= [APPLICATION 3] SEQUENCE {
flags[0] TicketFlags,
key[1] EncryptionKey,
crealm[2] Realm,
cname[3] PrincipalName,
transited[4] TransitedEncoding,
authtime[5] KerberosTime,
starttime[6] KerberosTime OPTIONAL,
endtime[7] KerberosTime,
renew-till[8] KerberosTime OPTIONAL,
caddr[9] HostAddresses OPTIONAL,
authorization-data[10] AuthorizationData OPTIONAL
}
-- encoded Transited field
TransitedEncoding ::= SEQUENCE {
tr-type[0] INTEGER, -- must be registered
contents[1] OCTET STRING
}
以下にレッテルをはってください:= [APPLICATION1]SEQUENCE、tkt-vno[0] INTEGER、分野[1]分野、sname[2] PrincipalName、enc-パート[3]EncryptedData--チケットEncTicketPartのコード化された部分:、:= [APPLICATION3] SEQUENCEは[0]TicketFlags、キー[1]EncryptionKey、crealm[2]分野、cname[3] PrincipalNameに旗を揚げさせて、[4] TransitedEncoding、authtime[5] KerberosTime、starttime[6] KerberosTime OPTIONAL、endtime[7] KerberosTime、現金箱[8]KerberosTime OPTIONAL、caddr[9] HostAddresses OPTIONALを取り替えている認可データ[10]AuthorizationData OPTIONALを通過しました--Transited分野TransitedEncodingをコード化します:、:= 系列[0] tr-タイプINTEGER--登録されたコンテンツ[1]OCTET STRINGでなければなりません。
The encoding of EncTicketPart is encrypted in the key shared by Kerberos and the end server (the server's secret key). See section 6 for the format of the ciphertext.
EncTicketPartのコード化はケルベロスで共有されたキーとエンドサーバ(サーバの秘密鍵)でコード化されます。 暗号文の形式に関してセクション6を見てください。
tkt-vno This field specifies the version number for the ticket
format. This document describes version number 5.
tkt-vno This分野はチケット形式のバージョン番号を指定します。 このドキュメントはバージョンNo.5について説明します。
realm This field specifies the realm that issued a ticket. It
also serves to identify the realm part of the server's
principal identifier. Since a Kerberos server can only
issue tickets for servers within its realm, the two will
分野This分野はチケットを発行した分野を指定します。 また、それは、サーバの主要な識別子の分野の部分を特定するのに役立ちます。 ケルベロスサーバが分野の中でサーバのチケットを発行できるだけであるので、2は発行するでしょう。
Kohl & Neuman [Page 42] RFC 1510 Kerberos September 1993
コールとヌーマン[42ページ]のRFCの1510のケルベロスの1993年9月
always be identical.
いつも同じであってください。
sname This field specifies the name part of the server's
identity.
sname This分野はサーバのアイデンティティの名前一部を指定します。
enc-part This field holds the encrypted encoding of the
EncTicketPart sequence.
Thisがさばくenc-部分はEncTicketPart系列のコード化されたコード化を保持します。
flags This field indicates which of various options were used or
requested when the ticket was issued. It is a bit-field,
where the selected options are indicated by the bit being
set (1), and the unselected options and reserved fields
being reset (0). Bit 0 is the most significant bit. The
encoding of the bits is specified in section 5.2. The
flags are described in more detail above in section 2. The
meanings of the flags are:
This分野が示すチケットが発行されたとき様々なオプションについて使用されたか、または要求された旗。 それによるリセット(0)であるしばらく分野と、選ばれていないオプションと予約された分野です。そこで、選択されたオプションはセット(1)であるビットによって示されます。 ビット0は最も重要なビットです。 ビットのコード化はセクション5.2で指定されます。 旗はさらに詳細に上でセクション2で説明されます。 旗の意味は以下の通りです。
Bit(s) Name Description
ビット(s)名前記述
0 RESERVED Reserved for future expansion of this
field.
0 この分野の今後の拡大のためのRESERVED Reserved。
1 FORWARDABLE The FORWARDABLE flag is normally only
interpreted by the TGS, and can be
ignored by end servers. When set,
this flag tells the ticket-granting
server that it is OK to issue a new
ticket- granting ticket with a
different network address based on
the presented ticket.
FORWARDABLE FORWARDABLEが旗を揚げさせる1を通常、TGSが解釈するだけであり、エンドサーバは無視できます。 設定されると、この旗は新しいチケットを発行するのがOKであって、提示されたチケットに基づく異なったネットワーク・アドレスがあるチケットを与えるとチケットを与えるサーバに言います。
2 FORWARDED When set, this flag indicates that
the ticket has either been forwarded
or was issued based on authentication
involving a forwarded ticket-granting
ticket.
2FORWARDED Whenセット、この旗はチケットを進めたか、または進められたチケットを与えるチケットにかかわる認証に基づいて発行したのを示します。
3 PROXIABLE The PROXIABLE flag is normally only
interpreted by the TGS, and can be
ignored by end servers. The PROXIABLE
flag has an interpretation identical
to that of the FORWARDABLE flag,
except that the PROXIABLE flag tells
the ticket-granting server that only
non- ticket-granting tickets may be
issued with different network
addresses.
PROXIABLE PROXIABLEが旗を揚げさせる3を通常、TGSが解釈するだけであり、エンドサーバは無視できます。 PROXIABLE旗には、FORWARDABLE旗のものと同じ解釈があります、PROXIABLE旗が、異なったネットワーク・アドレスでチケットを非与えるチケットだけを発行してもよいとチケットを与えるサーバに言うのを除いて。
Kohl & Neuman [Page 43] RFC 1510 Kerberos September 1993
コールとヌーマン[43ページ]のRFCの1510のケルベロスの1993年9月
4 PROXY When set, this flag indicates that a
ticket is a proxy.
4 PROXY Whenはセットして、この旗は、チケットがプロキシであることを示します。
5 MAY-POSTDATE The MAY-POSTDATE flag is normally
only interpreted by the TGS, and can
be ignored by end servers. This flag
tells the ticket-granting server that
a post- dated ticket may be issued
based on this ticket-granting ticket.
5月-POSTDATE5月-POSTDATEが旗を揚げさせる5を通常、TGSが解釈するだけであり、エンドサーバは無視できます。 この旗は、ポストの時代遅れのチケットがこのチケットを与えるチケットに基づいて発行されるかもしれないとチケットを与えるサーバに言います。
6 POSTDATED This flag indicates that this ticket
has been postdated. The end-service
can check the authtime field to see
when the original authentication
occurred.
6POSTDATED This旗は、このチケットが先日付を書かれたのを示します。 終わりサービスは、オリジナルの認証がいつ起こったかを確認するためにauthtime分野をチェックできます。
7 INVALID This flag indicates that a ticket is
invalid, and it must be validated by
the KDC before use. Application
servers must reject tickets which
have this flag set.
7INVALID This旗は、チケットが無効であることを示します、そして、KDCは使用の前にそれを有効にしなければなりません。 アプリケーション・サーバーはこの旗を設定するチケットを拒絶しなければなりません。
8 RENEWABLE The RENEWABLE flag is normally only
interpreted by the TGS, and can
usually be ignored by end servers
(some particularly careful servers
may wish to disallow renewable
tickets). A renewable ticket can be
used to obtain a replacement ticket
that expires at a later date.
RENEWABLE RENEWABLEが旗を揚げさせる8を通常、TGSが解釈するだけであり、通常、エンドサーバは無視できます(いくつかの特に慎重なサーバが再生可能なものチケットを禁じたがっているかもしれません)。 その後に期限が切れる交換チケットを得るのに再生可能なものチケットを使用できます。
9 INITIAL This flag indicates that this ticket
was issued using the AS protocol, and
not issued based on a ticket-granting
ticket.
9INITIAL This旗は、このチケットはASプロトコルを使用することで発行されて、チケットを与えるチケットに基づいて発行されなかったのを示します。
10 PRE-AUTHENT This flag indicates that during
initial authentication, the client
was authenticated by the KDC before a
ticket was issued. The strength of
the preauthentication method is not
indicated, but is acceptable to the
KDC.
10PRE-AUTHENT This旗は初期の認証の間、それを示して、チケットが発行される前にクライアントはKDCによって認証されました。 前認証メソッドの強さは、示されませんが、KDCに許容できます。
11 HW-AUTHENT This flag indicates that the protocol
employed for initial authentication
required the use of hardware expected
to be possessed solely by the named
11HW-AUTHENT This旗は、初期の認証に使われたプロトコルが唯一命名によって所有されていると予想されたハードウェアの使用を必要としたのを示します。
Kohl & Neuman [Page 44] RFC 1510 Kerberos September 1993
コールとヌーマン[44ページ]のRFCの1510のケルベロスの1993年9月
client. The hardware authentication
method is selected by the KDC and the
strength of the method is not
indicated.
クライアント。 ハードウェア認証方法はKDCによって選択されます、そして、メソッドの強さは示されません。
12-31 RESERVED Reserved for future use.
12-31 今後の使用のためのRESERVED Reserved。
key This field exists in the ticket and the KDC response and is
used to pass the session key from Kerberos to the
application server and the client. The field's encoding is
described in section 6.2.
主要なThis分野は、チケットとKDC応答で存在していて、ケルベロスからアプリケーション・サーバーとクライアントまで主要なセッションを過ぎるのに使用されます。 フィールドのコード化はセクション6.2で説明されます。
crealm This field contains the name of the realm in which the
client is registered and in which initial authentication
took place.
crealm This分野はクライアントが登録されていて、初期の認証が行われた分野の名前を含んでいます。
cname This field contains the name part of the client's principal
identifier.
cname This分野はクライアントの主要な識別子の名前部分を含んでいます。
transited This field lists the names of the Kerberos realms that took
part in authenticating the user to whom this ticket was
issued. It does not specify the order in which the realms
were transited. See section 3.3.3.1 for details on how
this field encodes the traversed realms.
通過しているThis分野はこのチケットが発行されたユーザを認証するのに参加したケルベロス分野の名前を記載します。 それは分野が通過されたオーダーを指定しません。 セクション3.3を見てください。.3 .1 この分野がどう横断された分野をコード化するかに関する詳細のために。
authtime This field indicates the time of initial authentication for
the named principal. It is the time of issue for the
original ticket on which this ticket is based. It is
included in the ticket to provide additional information to
the end service, and to provide the necessary information
for implementation of a `hot list' service at the KDC. An
end service that is particularly paranoid could refuse to
accept tickets for which the initial authentication
occurred "too far" in the past.
authtime This分野は命名された主体のための初期の認証の時間を示します。 このチケットが基づいているオリジナルのチケットのための問題の時間です。 それは、終わりのサービスに追加情報を提供して、KDCで'ホットリスト'サービスの実装のための必要事項を提供するためにチケットに含まれています。 特にパラノイアであることの終わりのサービスは、初期の認証が過去に「あまりにはるかに」起こったチケットを受け入れるのを拒否するかもしれません。
This field is also returned as part of the response from
the KDC. When returned as part of the response to initial
authentication (KRB_AS_REP), this is the current time on
the Kerberos server (It is NOT recommended that this time
value be used to adjust the workstation's clock since the
workstation cannot reliably determine that such a
KRB_AS_REP actually came from the proper KDC in a timely
manner.).
また、応答の一部としてKDCからこの野原を返します。 認証(KRB_AS_REP)に頭文字をつけるために応答の一部として返すと、これはケルベロスサーバの現在の時間(この時間的価値がワークステーションが、そのようなKRB_AS_REPが実際に適切なKDCから直ちに来たことを確かに決定できないのでワークステーションの時計を調整するのに使用されることが勧められません。)です。
starttime This field in the ticket specifies the time after which the
ticket is valid. Together with endtime, this field
specifies the life of the ticket. If it is absent from
the ticket, its value should be treated as that of the
チケットのstarttime This分野はチケットが有効である時を指定します。 endtimeと共に、この分野はチケットの寿命を指定します。 チケット、値からそれとして扱われるべきでなくて、それはあります。
Kohl & Neuman [Page 45] RFC 1510 Kerberos September 1993
コールとヌーマン[45ページ]のRFCの1510のケルベロスの1993年9月
authtime field.
authtime分野。
endtime This field contains the time after which the ticket will
not be honored (its expiration time). Note that individual
services may place their own limits on the life of a ticket
and may reject tickets which have not yet expired. As
such, this is really an upper bound on the expiration time
for the ticket.
endtime This分野はチケットが光栄に思うようにならない時(満了時間)を含んでいます。 個々のサービスがチケットの寿命にそれら自身の限界を置いて、まだ期限が切れていないチケットを拒絶するかもしれないことに注意してください。 そういうものとして、これはチケットのための満了時間に本当に上限です。
renew-till This field is only present in tickets that have the
RENEWABLE flag set in the flags field. It indicates the
maximum endtime that may be included in a renewal. It can
be thought of as the absolute expiration time for the
ticket, including all renewals.
現金箱を取り替えているThis分野は中の旗がさばくRENEWABLE旗のセットを持っているチケットの中に存在しているだけです。 それは更新に含まれるかもしれない最大のendtimeを示します。 すべての更新を含むチケットのための絶対満了時間としてそれを考えることができます。
caddr This field in a ticket contains zero (if omitted) or more
(if present) host addresses. These are the addresses from
which the ticket can be used. If there are no addresses,
the ticket can be used from any location. The decision
by the KDC to issue or by the end server to accept zero-
address tickets is a policy decision and is left to the
Kerberos and end-service administrators; they may refuse to
issue or accept such tickets. The suggested and default
policy, however, is that such tickets will only be issued
or accepted when additional information that can be used to
restrict the use of the ticket is included in the
authorization_data field. Such a ticket is a capability.
チケットのcaddr This分野はゼロ(省略されるなら)か、より多くて(現在)のホスト・アドレスを含んでいます。 これらはチケットを使用できるアドレスです。 アドレスが全くなければ、どんな位置からもチケットを使用できます。 問題かエンドサーバによるKDCによる無アドレスチケットを受け入れるという決定は、政策決定であり、ケルベロスと終わりサービス管理者に任せます。 彼らは、そのようなチケットを発行するか、または受け入れるのを拒否するかもしれません。 しかしながら、示されるのとデフォルト方針は承認_データ・フィールドにチケットの使用を制限するのに使用できる追加情報を含んでいるときだけ、そのようなチケットを発行するか、または受け入れるということです。 そのようなチケットは能力です。
Network addresses are included in the ticket to make it
harder for an attacker to use stolen credentials. Because
the session key is not sent over the network in cleartext,
credentials can't be stolen simply by listening to the
network; an attacker has to gain access to the session key
(perhaps through operating system security breaches or a
careless user's unattended session) to make use of stolen
tickets.
ネットワーク・アドレスは、攻撃者が盗まれた資格証明書を使用するのをより困難にするようにチケットに含まれています。 セッションキーがcleartextのネットワークの上に送られないので、単にネットワークを聞くことによって、資格証明書を盗むことができません。 攻撃者は、盗まれたチケットを利用するためにセッションキー(恐らくオペレーティングシステム機密保護違反か不注意なユーザの無人のセッションによる)へのアクセスを得なければなりません。
It is important to note that the network address from which
a connection is received cannot be reliably determined.
Even if it could be, an attacker who has compromised the
client's workstation could use the credentials from there.
Including the network addresses only makes it more
difficult, not impossible, for an attacker to walk off with
stolen credentials and then use them from a "safe"
location.
接続が受け取られているネットワーク・アドレスが確かに決定できないことに注意するのは重要です。 それがそうだったことができるとしても、クライアントのワークステーションに感染した攻撃者はそこから資格証明書を使用できるでしょうに。 ネットワーク・アドレスを含んでいるのに、盗まれた資格証明書を盗んで、次に、「安全な」位置からそれらを使用するのが攻撃者にとって不可能であるのではなく、難しくなるだけです。
Kohl & Neuman [Page 46] RFC 1510 Kerberos September 1993
コールとヌーマン[46ページ]のRFCの1510のケルベロスの1993年9月
authorization-data The authorization-data field is used to pass
authorization data from the principal on whose behalf a
ticket was issued to the application service. If no
authorization data is included, this field will be left
out. The data in this field are specific to the end
service. It is expected that the field will contain the
names of service specific objects, and the rights to those
objects. The format for this field is described in section
5.2. Although Kerberos is not concerned with the format of
the contents of the subfields, it does carry type
information (ad-type).
チケットがだれの代理に発行されたかの主体からアプリケーション・サービスまでの承認データ・フィールドが使用されている承認データパス承認データ。 どんな承認データも含まれていないと、この分野は省かれるでしょう。 この分野のデータは終わりのサービスに特定です。 分野がサービスの特定のオブジェクトの名前、およびそれらのオブジェクトへの権利を含むと予想されます。 形式はセクション5.2でこの分野に説明されます。 ケルベロスは部分体のコンテンツの形式に関係がありませんが、それは情報(広告タイプ)を桁上げの型にします。
By using the authorization_data field, a principal is able
to issue a proxy that is valid for a specific purpose. For
example, a client wishing to print a file can obtain a file
server proxy to be passed to the print server. By
specifying the name of the file in the authorization_data
field, the file server knows that the print server can only
use the client's rights when accessing the particular file
to be printed.
承認_データ・フィールドを使用することによって、元本はある特定の目的で有効なプロキシを発行できます。 例えば. プリント・サーバへのファイルの指定するのによる名前が承認_データ・フィールド、ファイルサーバーで通過される場合ファイルがファイルサーバープロキシを得ることができる印刷に願っているクライアントは、印刷されるために特定のファイルにアクセスするときだけ、プリント・サーバがクライアントの権利を使用できるのを知っています。
It is interesting to note that if one specifies the
authorization-data field of a proxy and leaves the host
addresses blank, the resulting ticket and session key can
be treated as a capability. See [9] for some suggested
uses of this field.
1つがプロキシの承認データ・フィールドを指定して、ホスト・アドレスを空白の状態でおくなら、結果として起こるチケットとセッションキーを能力として扱うことができることに注意するのはおもしろいです。 いくつかのための[9]がこの分野の用途を示したのを確実にしてください。
The authorization-data field is optional and does not have
to be included in a ticket.
承認データ・フィールドは、任意であり、チケットに含まれる必要はありません。
5.3.2. Authenticators
5.3.2. 固有識別文字
An authenticator is a record sent with a ticket to a server to certify the client's knowledge of the encryption key in the ticket, to help the server detect replays, and to help choose a "true session key" to use with the particular session. The encoding is encrypted in the ticket's session key shared by the client and the server:
固有識別文字はチケットでサーバに送られた、暗号化に関するクライアントの知識がチケットの中に主要であることを公認して、サーバが再生を検出するのを助けて、特定のセッションと共に使用する「本当のセッションキー」を選ぶのを助けた記録です。 コード化はクライアントとサーバによって共有されたチケットのセッションキーで暗号化されます:
-- Unencrypted authenticator
Authenticator ::= [APPLICATION 2] SEQUENCE {
authenticator-vno[0] INTEGER,
crealm[1] Realm,
cname[2] PrincipalName,
cksum[3] Checksum OPTIONAL,
cusec[4] INTEGER,
ctime[5] KerberosTime,
subkey[6] EncryptionKey OPTIONAL,
seq-number[7] INTEGER OPTIONAL,
-- Unencrypted固有識別文字Authenticator:、:= [APPLICATION2]SEQUENCE、固有識別文字-vno[0] INTEGER、crealm[1]分野、cname[2] PrincipalName、cksum[3]チェックサムOPTIONAL、キューセック[4]INTEGER、ctime[5] KerberosTime、サブキー[6]EncryptionKey OPTIONAL、seq-数の[7]INTEGER OPTIONAL
Kohl & Neuman [Page 47] RFC 1510 Kerberos September 1993
コールとヌーマン[47ページ]のRFCの1510のケルベロスの1993年9月
authorization-data[8] AuthorizationData OPTIONAL
}
承認データ[8]AuthorizationData OPTIONAL
authenticator-vno This field specifies the version number for the
format of the authenticator. This document specifies
version 5.
固有識別文字-vno This分野は固有識別文字の形式のバージョン番号を指定します。 このドキュメントはバージョン5を指定します。
crealm and cname These fields are the same as those described for the
ticket in section 5.3.1.
crealmとcname These分野はものがチケットのためにセクション5.3.1で説明したのと同じです。
cksum This field contains a checksum of the the application data
that accompanies the KRB_AP_REQ.
cksum This分野はKRB_AP_REQに同伴するアプリケーションデータのチェックサムを含んでいます。
cusec This field contains the microsecond part of the client's
timestamp. Its value (before encryption) ranges from 0 to
999999. It often appears along with ctime. The two fields
are used together to specify a reasonably accurate
timestamp.
キューセックThis分野はクライアントのタイムスタンプのマイクロセカンド部分を含んでいます。 値(暗号化の前の)は0〜999999まで及びます。 それはctimeと共にしばしば現れます。 2つの分野が、合理的に正確なタイムスタンプを指定するのに一緒に使用されます。
ctime This field contains the current time on the client's host.
ctime This分野はクライアントのホストの上に現在の時間を含んでいます。
subkey This field contains the client's choice for an encryption
key which is to be used to protect this specific
application session. Unless an application specifies
otherwise, if this field is left out the session key from
the ticket will be used.
サブキーThis分野はこの特定のアプリケーションセッションのときに保護するのに使用されることになっている暗号化キーのためのクライアントの選択を含んでいます。 この分野が省かれて、アプリケーションが別の方法で指定しないと、チケットから主要なセッションは使用されるでしょう。
seq-number This optional field includes the initial sequence number
to be used by the KRB_PRIV or KRB_SAFE messages when
sequence numbers are used to detect replays (It may also be
used by application specific messages). When included in
the authenticator this field specifies the initial sequence
number for messages from the client to the server. When
included in the AP-REP message, the initial sequence number
is that for messages from the server to the client. When
used in KRB_PRIV or KRB_SAFE messages, it is incremented by
one after each message is sent.
seq-数のThisの任意の分野は、一連番号が再生を検出するのに使用されるとき(また、それはアプリケーションの特定のメッセージによって使用されるかもしれません)、KRB_PRIVかKRB_SAFEメッセージによって使用されるために初期シーケンス番号を含んでいます。 固有識別文字に含まれていると、この分野はクライアントからサーバまでメッセージの初期シーケンス番号を指定します。含まれていると、AP-REPメッセージ、初期シーケンス番号には、サーバからクライアントまでのメッセージのためのそれがいます。 KRB_PRIVかKRB_SAFEメッセージで使用すると、各メッセージを送った後にそれを1つ増加します。
For sequence numbers to adequately support the detection of
replays they should be non-repeating, even across
connection boundaries. The initial sequence number should
be random and uniformly distributed across the full space
of possible sequence numbers, so that it cannot be guessed
by an attacker and so that it and the successive sequence
numbers do not repeat other sequences.
それらが一連番号が適切に再生の検出をサポートするためには、接続境界さえの向こう側の非反復であるべきです。 初期シーケンス番号は、無作為で可能な一連番号の満杯の向こう側に一様に分散されているべきです、攻撃者がそれを推測できないで、それと連続した一連番号が他の系列を繰り返さないように。
Kohl & Neuman [Page 48] RFC 1510 Kerberos September 1993
コールとヌーマン[48ページ]のRFCの1510のケルベロスの1993年9月
authorization-data This field is the same as described for the ticket
in section 5.3.1. It is optional and will only appear when
additional restrictions are to be placed on the use of a
ticket, beyond those carried in the ticket itself.
Thisがさばく承認データはセクション5.3.1でチケットのために説明されるのと同じです。 それは、任意であり、追加制限がチケットの使用に置かれるだけことであるときに、現れるでしょう、チケット自体の中に運ばれたものを超えて。
5.4. Specifications for the AS and TGS exchanges
5.4. ASのための仕様とTGS交換
This section specifies the format of the messages used in exchange between the client and the Kerberos server. The format of possible error messages appears in section 5.9.1.
このセクションはクライアントとケルベロスサーバの間の交換に使用されるメッセージの形式を指定します。可能なエラーメッセージの形式はセクション5.9.1に現れます。
5.4.1. KRB_KDC_REQ definition
5.4.1. KRB_KDC_REQ定義
The KRB_KDC_REQ message has no type of its own. Instead, its type is one of KRB_AS_REQ or KRB_TGS_REQ depending on whether the request is for an initial ticket or an additional ticket. In either case, the message is sent from the client to the Authentication Server to request credentials for a service.
KRB_KDC_REQメッセージには、それ自身のタイプが全くありません。 代わりに、要求が初期のチケットか追加チケットのためのものであるかによって、タイプはKRB_AS_REQかKRB_TGS_REQのひとりです。 どちらの場合ではも、サービスのために資格証明書を要求するためにクライアントからAuthentication Serverにメッセージを送ります。
The message fields are:
メッセージ分野は以下の通りです。
AS-REQ ::= [APPLICATION 10] KDC-REQ TGS-REQ ::= [APPLICATION 12] KDC-REQ
REQとして:、:= [アプリケーション10]KDC-REQ TGS-REQ:、:= [アプリケーション12] KDC-REQ
KDC-REQ ::= SEQUENCE {
pvno[1] INTEGER,
msg-type[2] INTEGER,
padata[3] SEQUENCE OF PA-DATA OPTIONAL,
req-body[4] KDC-REQ-BODY
}
KDC-REQ:、:= 系列pvno[1] INTEGER、msg-タイプ[2]INTEGER、padata[3] SEQUENCE OF PA-DATA OPTIONAL、reqボディー[4]KDC-REQ-BODY
PA-DATA ::= SEQUENCE {
padata-type[1] INTEGER,
padata-value[2] OCTET STRING,
-- might be encoded AP-REQ
}
PA-データ:、:= 系列[2] [1] padata-タイプINTEGER、padata-値のOCTET STRING--コード化されたAP-REQであるかもしれません。
KDC-REQ-BODY ::= SEQUENCE {
kdc-options[0] KDCOptions,
cname[1] PrincipalName OPTIONAL,
-- Used only in AS-REQ
realm[2] Realm, -- Server's realm
-- Also client's in AS-REQ
sname[3] PrincipalName OPTIONAL,
from[4] KerberosTime OPTIONAL,
till[5] KerberosTime,
rtime[6] KerberosTime OPTIONAL,
nonce[7] INTEGER,
以下をKDC-REQ具体化させてください:= SEQUENCE、{がkdc-オプション[0]KDCOptions、cname[1] PrincipalName OPTIONAL--AS-REQ分野[2]分野だけでは、使用されます--サーバの分野--クライアントも[4] [5] KerberosTime、rtime[6] KerberosTime OPTIONAL、一回だけ[7]INTEGERまでのKerberosTime OPTIONALからのAS-REQ sname[3] PrincipalName OPTIONALにあります。
Kohl & Neuman [Page 49] RFC 1510 Kerberos September 1993
コールとヌーマン[49ページ]のRFCの1510のケルベロスの1993年9月
etype[8] SEQUENCE OF INTEGER, -- EncryptionType,
-- in preference order
addresses[9] HostAddresses OPTIONAL,
enc-authorization-data[10] EncryptedData OPTIONAL,
-- Encrypted AuthorizationData encoding
additional-tickets[11] SEQUENCE OF Ticket OPTIONAL
}
好みの命令におけるetype[8] SEQUENCE OF INTEGER(EncryptionType)は、[9]がHostAddresses OPTIONALであると扱います、enc-承認データ[10]EncryptedData OPTIONAL--追加チケット[11]SEQUENCE OF Ticket OPTIONALをコード化するAuthorizationDataを暗号化します。
The fields in this message are:
このメッセージの分野は以下の通りです。
pvno This field is included in each message, and specifies the
protocol version number. This document specifies protocol
version 5.
pvno This分野は、各メッセージに含まれていて、プロトコルバージョン番号を指定します。 このドキュメントはプロトコルバージョン5を指定します。
msg-type This field indicates the type of a protocol message. It
will almost always be the same as the application
identifier associated with a message. It is included to
make the identifier more readily accessible to the
application. For the KDC-REQ message, this type will be
KRB_AS_REQ or KRB_TGS_REQ.
Thisがさばくmsg-タイプはプロトコルメッセージのタイプを示します。 それはほとんどいつもメッセージに関連しているアプリケーション識別子と同じになるでしょう。 識別子を容易にアプリケーションによりアクセスしやすくするのは含まれています。 KDC-REQメッセージに関しては、このタイプは、KRB_AS_REQかKRB_TGS_REQになるでしょう。
padata The padata (pre-authentication data) field contains a of
authentication information which may be needed before
credentials can be issued or decrypted. In the case of
requests for additional tickets (KRB_TGS_REQ), this field
will include an element with padata-type of PA-TGS-REQ and
data of an authentication header (ticket-granting ticket
and authenticator). The checksum in the authenticator
(which must be collisionproof) is to be computed over the
KDC-REQ-BODY encoding. In most requests for initial
authentication (KRB_AS_REQ) and most replies (KDC-REP), the
padata field will be left out.
padata(プレ認証データ)がさばくpadataは信任状を発行するか、または解読することができる前に必要とするかもしれない認証情報のaを含んでいます。 追加チケット(KRB_TGS_REQ)を求める要求の場合では、この分野はPA-TGS-REQのpadata-タイプと認証ヘッダー(チケットを与えるチケットと固有識別文字)に関するデータがある要素を含むでしょう。 固有識別文字(collisionproofであるに違いない)のチェックサムはKDC-REQ-BODYコード化に関して計算されることです。 初期の認証(KRB_AS_REQ)とほとんどの回答(KDC-REP)を求めるほとんどの要求では、padata分野は省かれるでしょう。
This field may also contain information needed by certain
extensions to the Kerberos protocol. For example, it might
be used to initially verify the identity of a client before
any response is returned. This is accomplished with a
padata field with padata-type equal to PA-ENC-TIMESTAMP and
padata-value defined as follows:
また、この分野はケルベロスプロトコルへのある拡大で必要である情報を含むかもしれません。 例えば、それは、どんな応答も返す前に初めはクライアントのアイデンティティについて確かめるのに使用されるかもしれません。 これはpadata分野でPA-ENC-TIMESTAMPと以下の通り定義されたpadata-値と等しいpadata-タイプで達成されます:
padata-type ::= PA-ENC-TIMESTAMP padata-value ::= EncryptedData -- PA-ENC-TS-ENC
以下をpadataタイプしてください:= PA ENC-TIMESTAMP padata価値:、:= EncryptedData--PA ENC t ENC
PA-ENC-TS-ENC ::= SEQUENCE {
patimestamp[0] KerberosTime, -- client's time
pausec[1] INTEGER OPTIONAL
}
PA ENC t ENC:、:= 系列patimestamp[0] KerberosTime、--クライアントのものがpausec[1] INTEGER OPTIONALを調節する
Kohl & Neuman [Page 50] RFC 1510 Kerberos September 1993
コールとヌーマン[50ページ]のRFCの1510のケルベロスの1993年9月
with patimestamp containing the client's time and pausec
containing the microseconds which may be omitted if a
client will not generate more than one request per second.
The ciphertext (padata-value) consists of the PA-ENC-TS-ENC
sequence, encrypted using the client's secret key.
patimestampがクライアントの時間を含んでいて、pausecがクライアントが1秒あたり1つ以上の要求を発生させないなら省略されるかもしれないマイクロセカンドを含んでいて。 暗号文(padata-値)はクライアントの秘密鍵を使用することでコード化されたPA-ENC-TS-ENC系列から成ります。
The padata field can also contain information needed to
help the KDC or the client select the key needed for
generating or decrypting the response. This form of the
padata is useful for supporting the use of certain
"smartcards" with Kerberos. The details of such extensions
are beyond the scope of this specification. See [10] for
additional uses of this field.
また、padata分野はKDCかクライアントが応答を発生するか、または解読するのに必要であるキーを選択するのを助けるのに必要である情報を含むことができます。 padataのこのフォームはケルベロスとのある「スマートカード」の使用を支持することの役に立ちます。 そのような拡大の詳細はこの仕様の範囲を超えています。 この分野の追加用途のための[10]を見てください。
padata-type The padata-type element of the padata field indicates the
way that the padata-value element is to be interpreted.
Negative values of padata-type are reserved for
unregistered use; non-negative values are used for a
registered interpretation of the element type.
padata分野のpadata-タイプ・エレメントのpadata-タイプは解釈されるpadata-価値要素がことである方法を示します。 padata-タイプの負の数は登録されていない使用のために予約されます。 非負の数は要素型の登録された解釈に使用されます。
req-body This field is a placeholder delimiting the extent of the
remaining fields. If a checksum is to be calculated over
the request, it is calculated over an encoding of the KDC-
REQ-BODY sequence which is enclosed within the req-body
field.
req-ボディーThis分野は残りの範囲がさばくプレースホルダの区切りです。 チェックサムが要求に関して計算されることであるなら、KDC- REQ-BODY系列のコード化に関してどれがreq-ボディー分野の中に同封されるかと見込まれます。
kdc-options This field appears in the KRB_AS_REQ and KRB_TGS_REQ
requests to the KDC and indicates the flags that the client
wants set on the tickets as well as other information that
is to modify the behavior of the KDC. Where appropriate,
the name of an option may be the same as the flag that is
set by that option. Although in most case, the bit in the
options field will be the same as that in the flags field,
this is not guaranteed, so it is not acceptable to simply
copy the options field to the flags field. There are
various checks that must be made before honoring an option
anyway.
kdc-オプションThis分野は、KRB_AS_REQとKRB_TGS_REQ要求でKDCにおいて見えて、クライアントが欲しい旗がKDCの動きを変更することになっている他の情報と同様にチケットの上にセットしたのを示します。 適切であるところでは、オプションの名前がそのオプションで設定される旗と同じであるかもしれません。 ケース、オプション分野の大部分のビットが旗の分野のそれと同じになりますが、これが保証されないので、単に旗の分野にオプション分野をコピーするのは許容できません。 とにかくオプションを光栄に思う前にしなければならない様々なチェックがあります。
The kdc_options field is a bit-field, where the selected
options are indicated by the bit being set (1), and the
unselected options and reserved fields being reset (0).
The encoding of the bits is specified in section 5.2. The
options are described in more detail above in section 2.
The meanings of the options are:
kdc_オプション分野によるリセット(0)であるしばらく分野と、選ばれていないオプションと予約された分野です。そこで、選択されたオプションはセット(1)であるビットによって示されます。 ビットのコード化はセクション5.2で指定されます。 オプションはさらに詳細に上でセクション2で説明されます。 オプションの意味は以下の通りです。
Kohl & Neuman [Page 51] RFC 1510 Kerberos September 1993
コールとヌーマン[51ページ]のRFCの1510のケルベロスの1993年9月
Bit(s) Name Description
ビット(s)名前記述
0 RESERVED Reserved for future expansion of this
field.
0 この分野の今後の拡大のためのRESERVED Reserved。
1 FORWARDABLE The FORWARDABLE option indicates that
the ticket to be issued is to have its
forwardable flag set. It may only be
set on the initial request, or in a
subsequent request if the ticket-
granting ticket on which it is based
is also forwardable.
1 前進可能を持つために発行されるチケットをあるオプションが示すFORWARDABLE FORWARDABLEはセットに旗を揚げさせます。 それが初期の要求に設定されるだけであるかもしれませんか、またはまた、その後の要求では、それが基づいているチケットを与えるのもチケットであるなら前進可能です。
2 FORWARDED The FORWARDED option is only specified
in a request to the ticket-granting
server and will only be honored if the
ticket-granting ticket in the request
has its FORWARDABLE bit set. This
option indicates that this is a
request for forwarding. The
address(es) of the host from which the
resulting ticket is to be valid are
included in the addresses field of the
request.
2 FORWARDEDがゆだねるFORWARDEDは要求でチケットを与えるサーバに指定されるだけであり、要求におけるチケットを与えるチケットでFORWARDABLEビットを設定する場合にだけ、光栄に思うようになるでしょう。 このオプションは、これが推進を求めて要求であることを示します。 結果として起こるチケットが有効であることになっているホストのアドレス(es)は要求のアドレス分野に含まれています。
3 PROXIABLE The PROXIABLE option indicates that
the ticket to be issued is to have its
proxiable flag set. It may only be set
on the initial request, or in a
subsequent request if the ticket-
granting ticket on which it is based
is also proxiable.
3 proxiableを持つために発行されるチケットをあるオプションが示すPROXIABLE PROXIABLEはセットに旗を揚げさせます。 それが初期の要求に設定されるだけであるかもしれませんか、またはまた、その後の要求では、それが基づいているチケットを与えるのもチケットであるならproxiableです。
4 PROXY The PROXY option indicates that this
is a request for a proxy. This option
will only be honored if the ticket-
granting ticket in the request has its
PROXIABLE bit set. The address(es) of
the host from which the resulting
ticket is to be valid are included in
the addresses field of the request.
4 PROXYがゆだねるPROXYは、これがプロキシを求めて要求であることを示します。 要求でチケットを与えるチケットでPROXIABLEビットを設定する場合にだけ、このオプションは光栄に思うようになるでしょう。 結果として起こるチケットが有効であることになっているホストのアドレス(es)は要求のアドレス分野に含まれています。
5 ALLOW-POSTDATE The ALLOW-POSTDATE option indicates
that the ticket to be issued is to
have its MAY-POSTDATE flag set. It
may only be set on the initial
request, or in a subsequent request if
5 ALLOW-POSTDATEがゆだねるALLOW-POSTDATEは、発行されるチケットで5月-POSTDATE旗を設定することになっているのを示します。 それは初期の要求の上、または、その後の要求に設定されるだけであるかもしれません。
Kohl & Neuman [Page 52] RFC 1510 Kerberos September 1993
コールとヌーマン[52ページ]のRFCの1510のケルベロスの1993年9月
the ticket-granting ticket on which it
is based also has its MAY-POSTDATE
flag set.
また、それが基づいているチケットを与えるチケットで、5月-POSTDATE旗を設定します。
6 POSTDATED The POSTDATED option indicates that
this is a request for a postdated
ticket. This option will only be
honored if the ticket-granting ticket
on which it is based has its MAY-
POSTDATE flag set. The resulting
ticket will also have its INVALID flag
set, and that flag may be reset by a
subsequent request to the KDC after
the starttime in the ticket has been
reached.
6 POSTDATEDがゆだねるPOSTDATEDは、これが先日付を書かれたチケットを求めて要求であることを示します。 それが基づいているチケットを与えるチケットで5月のPOSTDATE旗を設定する場合にだけ、このオプションは光栄に思うようになるでしょう。 また、結果として起こるチケットで、INVALID旗を設定するでしょう、そして、チケットの中のstarttimeに達した後にその旗はKDCへのその後の要求でリセットされるかもしれません。
7 UNUSED This option is presently unused.
7UNUSED Thisオプションは現在、未使用です。
8 RENEWABLE The RENEWABLE option indicates that
the ticket to be issued is to have its
RENEWABLE flag set. It may only be
set on the initial request, or when
the ticket-granting ticket on which
the request is based is also
renewable. If this option is
requested, then the rtime field in the
request contains the desired absolute
expiration time for the ticket.
8 RENEWABLE旗を持つために発行されるチケットをあるオプションが示すRENEWABLE RENEWABLEはセットしました。 それは初期の要求に設定されるだけであるかもしれなく、また、いつ要求が基づいているチケットを与えるチケットが再生可能なものであるかをそうされます。 このオプションが要求されるなら、要求におけるrtime分野はチケットのための必要な絶対満了時間を含んでいます。
9-26 RESERVED Reserved for future use.
9-26 今後の使用のためのRESERVED Reserved。
27 RENEWABLE-OK The RENEWABLE-OK option indicates that
a renewable ticket will be acceptable
if a ticket with the requested life
cannot otherwise be provided. If a
ticket with the requested life cannot
be provided, then a renewable ticket
may be issued with a renew-till equal
to the the requested endtime. The
value of the renew-till field may
still be limited by local limits, or
limits selected by the individual
principal or server.
RENEWABLE-OKがゆだねる27RENEWABLE-OKは、別の方法で要求された人生を伴うチケットを供給できないと再生可能なものチケットを許容できるのを示します。 要求された人生を伴うチケットを供給できないなら、再生可能なものチケットは現金箱を取り替えている同輩と共に要求されたendtimeに発行されるかもしれません。 現金箱を取り替えている分野の値は地方の限界、または個々の校長かサーバによって選択された限界でまだ制限されているかもしれません。
28 ENC-TKT-IN-SKEY This option is used only by the
ticket-granting service. The ENC-
TKT-IN-SKEY option indicates that the
ticket for the end server is to be
28 ENC-TKT IN SKEY Thisオプションは単にチケットを与えるサービスで使用されます。 オプションがエンドサーバのチケットがそうであることを示すENC- TKT IN SKEY
Kohl & Neuman [Page 53] RFC 1510 Kerberos September 1993
コールとヌーマン[53ページ]のRFCの1510のケルベロスの1993年9月
encrypted in the session key from the
additional ticket-granting ticket
provided.
供給された追加チケットを与えるチケットから主要なセッションのときに、コード化されています。
29 RESERVED Reserved for future use.
29 今後の使用のためのRESERVED Reserved。
30 RENEW This option is used only by the
ticket-granting service. The RENEW
option indicates that the present
request is for a renewal. The ticket
provided is encrypted in the secret
key for the server on which it is
valid. This option will only be
honored if the ticket to be renewed
has its RENEWABLE flag set and if the
time in its renew till field has not
passed. The ticket to be renewed is
passed in the padata field as part of
the authentication header.
30RENEW Thisオプションは単にチケットを与えるサービスで使用されます。 RENEWオプションは、現在の要求が更新のためのものであることを示します。 供給されたチケットはそれが有効であるサーバのために秘密鍵でコード化されます。 分野まで更新してください。このオプションが更新されるべきチケットでRENEWABLE旗を設定して、中の時間である場合にだけ光栄に思うようになる、それ、通っていません。 更新されるべきチケットは認証ヘッダーの一部としてpadata分野で渡されます。
31 VALIDATE This option is used only by the
ticket-granting service. The VALIDATE
option indicates that the request is
to validate a postdated ticket. It
will only be honored if the ticket
presented is postdated, presently has
its INVALID flag set, and would be
otherwise usable at this time. A
ticket cannot be validated before its
starttime. The ticket presented for
validation is encrypted in the key of
the server for which it is valid and
is passed in the padata field as part
of the authentication header.
31VALIDATE Thisオプションは単にチケットを与えるサービスで使用されます。 VALIDATEオプションは、要求が先日付を書かれたチケットを有効にすることであることを示します。 贈られたチケットが先日付を書かれる場合にだけ、光栄に思うでしょう。現在INVALID旗を設定させます。そうでなければ、それは、このとき、使用可能でしょう。 starttimeの前でチケットを有効にすることができません。 合法化のために贈られたチケットは、それが有効であるサーバのキーでコード化されて、認証ヘッダーの一部としてpadata分野で渡されます。
cname and sname These fields are the same as those described for the
ticket in section 5.3.1. sname may only be absent when the
ENC-TKT-IN-SKEY option is specified. If absent, the name
of the server is taken from the name of the client in the
ticket passed as additional-tickets.
cnameとsname These分野はENC-TKT IN SKEYオプションが指定されるときだけ、セクション5.3.1snameのチケットのために説明されたものが休むかもしれないのと同じです。 休むなら、追加チケットとして渡されたチケットの中にクライアントの名前からサーバの名前を取ります。
enc-authorization-data The enc-authorization-data, if present (and it
can only be present in the TGS_REQ form), is an encoding of
the desired authorization-data encrypted under the sub-
session key if present in the Authenticator, or
alternatively from the session key in the ticket-granting
ticket, both from the padata field in the KRB_AP_REQ.
enc認可データ、存在しているなら(それは単にTGS_REQフォームに存在している場合があります)、enc認可データは主要な、しかし、Authenticatorの現在のサブセッションでコード化された必要な認可データのコード化であるかあるいはまた、チケットを与えるチケットの中に主要なセッションから、padataからの両方がKRBで_AP_REQをさばきます。
Kohl & Neuman [Page 54] RFC 1510 Kerberos September 1993
コールとヌーマン[54ページ]のRFCの1510のケルベロスの1993年9月
realm This field specifies the realm part of the server's
principal identifier. In the AS exchange, this is also the
realm part of the client's principal identifier.
分野This分野はサーバの主要な識別子の分野の部分を指定します。 AS交換では、また、これはクライアントの主要な識別子の分野の部分です。
from This field is included in the KRB_AS_REQ and KRB_TGS_REQ
ticket requests when the requested ticket is to be
postdated. It specifies the desired start time for the
requested ticket.
要求されたチケットが先日付を書かれることになっているとき、Thisから、分野はKRB_AS_REQとKRB_TGS_REQチケット要求に含まれています。 それは要求されたチケットのための必要な開始時刻を指定します。
till This field contains the expiration date requested by the
client in a ticket request.
Thisまで、分野はチケット要求でクライアントによって要求された有効期限を含んでいます。
rtime This field is the requested renew-till time sent from a
client to the KDC in a ticket request. It is optional.
rtime This分野はチケット要求でクライアントからKDCに送られた要求された現金箱を取り替えている時間です。 それは任意です。
nonce This field is part of the KDC request and response. It it
intended to hold a random number generated by the client.
If the same number is included in the encrypted response
from the KDC, it provides evidence that the response is
fresh and has not been replayed by an attacker. Nonces
must never be re-used. Ideally, it should be gen erated
randomly, but if the correct time is known, it may suffice
(Note, however, that if the time is used as the nonce, one
must make sure that the workstation time is monotonically
increasing. If the time is ever reset backwards, there is
a small, but finite, probability that a nonce will be
reused.).
一回だけのThis分野はKDC要求と応答の一部です。 それ、それは、乱数がクライアントによって生成されるままにするつもりでした。 同じ数が暗号化された応答にKDCから含まれているなら、それは、応答が新鮮であるという証拠を提供して、攻撃者によって再演されていません。 一回だけを決して再使用してはいけません。 手当たりしだいにeratedされていた状態で情報を得る理想的に、ことであるべきですが、正しい時間が知られているなら、それは十分であるかもしれません。(しかしながら、時間が一回だけとして費やされるなら、ワークステーション時間が単調に増加しているのを確実にしなければならないことに注意してください。 時間が今までに後方にリセットされるなら、一回だけが再利用されるという小さい、しかし、有限な確率があります。).
etype This field specifies the desired encryption algorithm to be
used in the response.
etype This分野は、応答に使用されるために必要な暗号化アルゴリズムを指定します。
addresses This field is included in the initial request for tickets,
and optionally included in requests for additional tickets
from the ticket-granting server. It specifies the
addresses from which the requested ticket is to be valid.
Normally it includes the addresses for the client's host.
If a proxy is requested, this field will contain other
addresses. The contents of this field are usually copied
by the KDC into the caddr field of the resulting ticket.
Thisがさばくアドレスは、チケットのために初期の要求に含まれていて、チケットを与えるサーバからの追加チケットのために要求に任意に含まれています。それは要求されたチケットが有効であることになっているアドレスを指定します。 通常、それはクライアントのホストのためのアドレスを含んでいます。 プロキシが要求されると、この分野は他のアドレスを含むでしょう。 通常、この分野の内容はKDCによって結果として起こるチケットのcaddr分野にコピーされます。
additional-tickets Additional tickets may be optionally included in a
request to the ticket-granting server. If the ENC-TKT-IN-
SKEY option has been specified, then the session key from
the additional ticket will be used in place of the server's
key to encrypt the new ticket. If more than one option
which requires additional tickets has been specified, then
the additional tickets are used in the order specified by
the ordering of the options bits (see kdc-options, above).
追加チケットAdditionalチケットは要求で任意にチケットを与えるサーバに含められるかもしれません。オプションはENC-TKT-IN SKEYであるなら指定されて、次に、追加チケットから主要なセッションは、新しいチケットを暗号化するのにサーバのキーに代わって使用されるでしょう。 追加チケットを必要とする1つ以上のオプションが指定されたなら、追加チケットはオプションビットの注文で指定されたオーダーで使用されます(kdc-オプションを見てください、上です)。
Kohl & Neuman [Page 55] RFC 1510 Kerberos September 1993
コールとヌーマン[55ページ]のRFCの1510のケルベロスの1993年9月
The application code will be either ten (10) or twelve (12) depending on whether the request is for an initial ticket (AS-REQ) or for an additional ticket (TGS-REQ).
応用コードは、要求が初期のチケット(AS-REQ)のためのものであるか、そして、追加チケット(TGS-REQ)のために10(10)か依存のどちらかに12(12)なるだろうこと。
The optional fields (addresses, authorization-data and additional- tickets) are only included if necessary to perform the operation specified in the kdc-options field.
任意の分野(アドレス、承認データ、および追加チケット)は、必要なら、kdc-オプション分野で指定された操作を実行するために含まれているだけです。
It should be noted that in KRB_TGS_REQ, the protocol version number appears twice and two different message types appear: the KRB_TGS_REQ message contains these fields as does the authentication header (KRB_AP_REQ) that is passed in the padata field.
KRB_TGS_REQでは、プロトコルバージョン番号が二度現れることに注意されるべきであり、2つの異なったメッセージタイプが見えます: KRB_TGS_REQメッセージはpadata分野で渡される認証ヘッダー(KRB_AP_REQ)のようにこれらの分野を含んでいます。
5.4.2. KRB_KDC_REP definition
5.4.2. KRB_KDC_REP定義
The KRB_KDC_REP message format is used for the reply from the KDC for either an initial (AS) request or a subsequent (TGS) request. There is no message type for KRB_KDC_REP. Instead, the type will be either KRB_AS_REP or KRB_TGS_REP. The key used to encrypt the ciphertext part of the reply depends on the message type. For KRB_AS_REP, the ciphertext is encrypted in the client's secret key, and the client's key version number is included in the key version number for the encrypted data. For KRB_TGS_REP, the ciphertext is encrypted in the sub-session key from the Authenticator, or if absent, the session key from the ticket-granting ticket used in the request. In that case, no version number will be present in the EncryptedData sequence.
KRB_KDC_REPメッセージ・フォーマットは回答に初期の(AS)要求かその後の(TGS)要求のどちらかのためのKDCから使用されます。 KRB_KDC_REPのためのメッセージタイプが全くありません。タイプは、代わりに、KRB_AS_REPかKRB_TGS_REPになどちらかでしょう。回答の暗号文部分を暗号化するのに使用されるキーはメッセージタイプに頼っています。 KRB_AS_REPに関しては、暗号文はクライアントの秘密鍵で暗号化されます、そして、クライアントの主要なバージョン番号は暗号化されたデータの主要なバージョン番号に含まれています。 KRB_TGS_REPに関しては、Authenticatorから主要なサブセッション、または休むなら、暗号文は暗号化されています、要求で使用されるチケットを与えるチケットから主要なセッション。 その場合、どんなバージョン番号もEncryptedData系列で存在しないでしょう。
The KRB_KDC_REP message contains the following fields:
KRB_KDC_REPメッセージは以下の分野を含んでいます:
AS-REP ::= [APPLICATION 11] KDC-REP TGS-REP ::= [APPLICATION 13] KDC-REP
レップとして:、:= [アプリケーション11] KDC-レップTGS-レップ:、:= [アプリケーション13] KDC-レップ
KDC-REP ::= SEQUENCE {
pvno[0] INTEGER,
msg-type[1] INTEGER,
padata[2] SEQUENCE OF PA-DATA OPTIONAL,
crealm[3] Realm,
cname[4] PrincipalName,
ticket[5] Ticket,
enc-part[6] EncryptedData
}
KDC-レップ:、:= 系列pvno[0] INTEGER、msg-タイプ[1]INTEGER、padata[2] SEQUENCE OF PA-DATA OPTIONAL、crealm[3]分野、cname[4] PrincipalName、チケット[5]チケット、enc-パート[6]EncryptedData
EncASRepPart ::= [APPLICATION 25[25]] EncKDCRepPart EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart
EncASRepPart:、:= [アプリケーション25[25]] EncKDCRepPart EncTGSRepPart:、:= [アプリケーション26] EncKDCRepPart
EncKDCRepPart ::= SEQUENCE {
key[0] EncryptionKey,
last-req[1] LastReq,
EncKDCRepPart:、:= SEQUENCE、キー[0]EncryptionKey、最後のreq[1] LastReq
Kohl & Neuman [Page 56] RFC 1510 Kerberos September 1993
コールとヌーマン[56ページ]のRFCの1510のケルベロスの1993年9月
nonce[2] INTEGER,
key-expiration[3] KerberosTime OPTIONAL,
flags[4] TicketFlags,
authtime[5] KerberosTime,
starttime[6] KerberosTime OPTIONAL,
endtime[7] KerberosTime,
renew-till[8] KerberosTime OPTIONAL,
srealm[9] Realm,
sname[10] PrincipalName,
caddr[11] HostAddresses OPTIONAL
}
一回だけ[2]INTEGER(主要な満了[3]KerberosTime OPTIONAL)は[4] TicketFlagsに旗を揚げさせます、authtime[5] KerberosTime、starttime[6] KerberosTime OPTIONAL、endtime[7] KerberosTime、現金箱[8]KerberosTime OPTIONALを取り替えます、srealm[9]分野、sname[10] PrincipalName、caddr[11] HostAddresses OPTIONAL
NOTE: In EncASRepPart, the application code in the encrypted
part of a message provides an additional check that
the message was decrypted properly.
以下に注意してください。 EncASRepPartに、メッセージの暗号化された部分の応用コードはメッセージが適切に解読された追加チェックを供給します。
pvno and msg-type These fields are described above in section 5.4.1.
msg-type is either KRB_AS_REP or KRB_TGS_REP.
pvnoとmsg-タイプThese分野は上でセクション5.4.1で説明されます。msg-タイプは、KRB_AS_REPかKRB_TGS_REPのどちらかです。
padata This field is described in detail in section 5.4.1. One
possible use for this field is to encode an alternate
"mix-in" string to be used with a string-to-key algorithm
(such as is described in section 6.3.2). This ability is
useful to ease transitions if a realm name needs to change
(e.g., when a company is acquired); in such a case all
existing password-derived entries in the KDC database would
be flagged as needing a special mix-in string until the
next password change.
padata This分野はセクション5.4.1で詳細に説明されます。 この分野の1つの活用可能性はストリングからキーへのアルゴリズム(セクション6.3.2で説明される)で使用されるために代替の「中では、混入する」ストリングをコード化することです。 分野名が、変化する(例えば、会社はいつ後天的ですか)必要があるなら、この能力は変遷を緩和するために役に立ちます。 KDCデータベースにおけるこのような場合にはすべての既存のパスワードで派生しているエントリーが次のパスワード変化まで特別な中で混入するストリングを必要とするとして旗を揚げられるでしょう。
crealm, cname, srealm and sname These fields are the same as those
described for the ticket in section 5.3.1.
crealm、cname、srealm、およびsname These分野はものがチケットのためにセクション5.3.1で説明したのと同じです。
ticket The newly-issued ticket, from section 5.3.1.
チケットはセクション5.3.1からの新譜のチケットです。
enc-part This field is a place holder for the ciphertext and related
information that forms the encrypted part of a message.
The description of the encrypted part of the message
follows each appearance of this field. The encrypted part
is encoded as described in section 6.1.
Thisがさばくenc-部分は暗号文と関連情報のためのメッセージの暗号化された部分を形成する場所所有者です。 メッセージの暗号化された部分の記述はこの分野の各外観を次に続かせています。 暗号化された部分はセクション6.1で説明されるようにコード化されます。
key This field is the same as described for the ticket in
section 5.3.1.
主要なThis分野はセクション5.3.1でチケットのために説明されるのと同じです。
last-req This field is returned by the KDC and specifies the time(s)
of the last request by a principal. Depending on what
information is available, this might be the last time that
a request for a ticket-granting ticket was made, or the
last time that a request based on a ticket-granting ticket
最後のreq This分野は、元本でKDCによって返されて、最後の要求の時間を指定します。 どんな情報が利用可能であるかよって、これは、チケットを与えるチケットを求める要求をした最後の時間、または要求がチケットを与えるチケットに基礎づけた最後の時間であるかもしれません。
Kohl & Neuman [Page 57] RFC 1510 Kerberos September 1993
コールとヌーマン[57ページ]のRFCの1510のケルベロスの1993年9月
was successful. It also might cover all servers for a
realm, or just the particular server. Some implementations
may display this information to the user to aid in
discovering unauthorized use of one's identity. It is
similar in spirit to the last login time displayed when
logging into timesharing systems.
うまくいく。 また、それは分野、またはまさしく特定のサーバのためにすべてのサーバをカバーするかもしれません。いくつかの実装が、人のアイデンティティの無断使用を発見する際に支援するためにこの情報をユーザに表示するかもしれません。 それは精神において時分割システムにログインするとき表示された最後のログイン時間と同様です。
nonce This field is described above in section 5.4.1.
一回だけのThis分野は上でセクション5.4.1で説明されます。
key-expiration The key-expiration field is part of the response from
the KDC and specifies the time that the client's secret key
is due to expire. The expiration might be the result of
password aging or an account expiration. This field will
usually be left out of the TGS reply since the response to
the TGS request is encrypted in a session key and no client
information need be retrieved from the KDC database. It is
up to the application client (usually the login program) to
take appropriate action (such as notifying the user) if the
expira tion time is imminent.
主要な満了がさばく主要な満了は、KDCからの応答の一部であり、クライアントの秘密鍵が期限が切れることになっている時間を指定します。 満了はパスワードの年をとるかアカウント満了の結果であるかもしれません。 TGS要求への応答がセッションキーで暗号化されて、クライアント情報が全くKDCデータベースから検索される必要はないので、通常、この野原はTGS回答から外されるでしょう。 expira tion時間が差し迫っているなら、それは、適切な行動(ユーザに通知などなどの)を取るためにはアプリケーションクライアント(通常ログインプログラム)次第です。
flags, authtime, starttime, endtime, renew-till and caddr These
fields are duplicates of those found in the encrypted
portion of the attached ticket (see section 5.3.1),
provided so the client may verify they match the intended
request and to assist in proper ticket caching. If the
message is of type KRB_TGS_REP, the caddr field will only
be filled in if the request was for a proxy or forwarded
ticket, or if the user is substituting a subset of the
addresses from the ticket granting ticket. If the client-
requested addresses are not present or not used, then the
addresses contained in the ticket will be the same as those
included in the ticket-granting ticket.
旗、caddr These分野が付属チケットの暗号化された部分で見つけられたものの写し(セクション5.3.1を見る)である、authtime、starttimeはendtimeされます、現金箱を取り替えて、したがって、クライアントが確かめるかもしれないなら、それらは意図している要求と適切なチケットキャッシュにおけるアシストに合っています。 タイプKRB_TGS_REPにメッセージがあると、要求がプロキシのためにあったか、チケットを進めた、またはユーザがチケットを与えるチケットからアドレスの部分集合を代入している場合にだけ、caddr分野は記入されるでしょう。 クライアントが、アドレスが現在でない、または使用されていないよう要求したなら、チケットに含まれたアドレスはチケットを与えるチケットにそれらを含んでいるのと同じになるでしょう。
5.5. Client/Server (CS) message specifications
5.5. クライアント/サーバ(CS)メッセージ仕様
This section specifies the format of the messages used for the authentication of the client to the application server.
このセクションはクライアントの認証にアプリケーション・サーバーに使用されるメッセージの形式を指定します。
5.5.1. KRB_AP_REQ definition
5.5.1. KRB_AP_REQ定義
The KRB_AP_REQ message contains the Kerberos protocol version number, the message type KRB_AP_REQ, an options field to indicate any options in use, and the ticket and authenticator themselves. The KRB_AP_REQ message is often referred to as the "authentication header".
KRB_AP_REQメッセージはケルベロスプロトコルバージョン番号を含んでいます、メッセージタイプKRB_AP_REQ、使用中のどんなオプション、チケット、および固有識別文字自体も示すオプション分野。 KRB_AP_REQメッセージはしばしば「認証ヘッダー」と呼ばれます。
AP-REQ ::= [APPLICATION 14] SEQUENCE {
pvno[0] INTEGER,
msg-type[1] INTEGER,
AP-REQ:、:= [APPLICATION14]SEQUENCE、pvno[0] INTEGER、msg-タイプ[1]INTEGER
Kohl & Neuman [Page 58] RFC 1510 Kerberos September 1993
コールとヌーマン[58ページ]のRFCの1510のケルベロスの1993年9月
ap-options[2] APOptions,
ticket[3] Ticket,
authenticator[4] EncryptedData
}
ap-オプション[2]APOptions、チケット[3]チケット、固有識別文字[4]EncryptedData
APOptions ::= BIT STRING {
reserved(0),
use-session-key(1),
mutual-required(2)
}
APOptions:、:= ビット列予約された(0)、使用セッション主要な(1)、互いに必要な(2)
pvno and msg-type These fields are described above in section 5.4.1.
msg-type is KRB_AP_REQ.
pvnoとmsg-タイプThese分野は上でセクション5.4.1で説明されます。msg-タイプはKRB_AP_REQです。
ap-options This field appears in the application request (KRB_AP_REQ)
and affects the way the request is processed. It is a
bit-field, where the selected options are indicated by the
bit being set (1), and the unselected options and reserved
fields being reset (0). The encoding of the bits is
specified in section 5.2. The meanings of the options are:
ap-オプションThis分野は、アプリケーション要求(KRB_AP_REQ)に現れて、要求が処理される方法に影響します。 それによるリセット(0)であるしばらく分野と、選ばれていないオプションと予約された分野です。そこで、選択されたオプションはセット(1)であるビットによって示されます。 ビットのコード化はセクション5.2で指定されます。 オプションの意味は以下の通りです。
Bit(s) Name Description
ビット(s)名前記述
0 RESERVED Reserved for future expansion of
this field.
0 この分野の今後の拡張のためのRESERVED Reserved。
1 USE-SESSION-KEYThe USE-SESSION-KEY option indicates
that the ticket the client is
presenting to a server is encrypted in
the session key from the server's
ticket-granting ticket. When this
option is not specified, the ticket is
encrypted in the server's secret key.
1 USE-SESSION-KEYThe USE-SESSION-KEYオプションは、クライアントがサーバに贈っているチケットがサーバのチケットを与えるチケットから主要なセッションのときに暗号化されるのを示します。 このオプションが指定されないとき、チケットはサーバの秘密鍵で暗号化されます。
2 MUTUAL-REQUIREDThe MUTUAL-REQUIRED option tells the
server that the client requires mutual
authentication, and that it must
respond with a KRB_AP_REP message.
2 MUTUAL-REQUIREDThe MUTUAL-REQUIREDオプションはクライアントが互いの認証を必要として、それがKRB_AP_REPメッセージで応じなければならないとサーバに言います。
3-31 RESERVED Reserved for future use.
3-31 今後の使用のためのRESERVED Reserved。
ticket This field is a ticket authenticating the client to the
server.
チケットThis分野はサーバにクライアントを認証するチケットです。
authenticator This contains the authenticator, which includes the
client's choice of a subkey. Its encoding is described in
section 5.3.2.
固有識別文字Thisは固有識別文字を含んでいます。(それは、クライアントのサブキーの選択を含んでいます)。 コード化はセクション5.3.2で説明されます。
Kohl & Neuman [Page 59] RFC 1510 Kerberos September 1993
コールとヌーマン[59ページ]のRFCの1510のケルベロスの1993年9月
5.5.2. KRB_AP_REP definition
5.5.2. KRB_AP_REP定義
The KRB_AP_REP message contains the Kerberos protocol version number, the message type, and an encrypted timestamp. The message is sent in in response to an application request (KRB_AP_REQ) where the mutual authentication option has been selected in the ap-options field.
KRB_AP_REPメッセージはケルベロスプロトコルバージョン番号、メッセージタイプ、および暗号化されたタイムスタンプを含んでいます。 メッセージは互いの認証オプションがap-オプション分野で選択されたアプリケーション要求(KRB_AP_REQ)に対応して送られます。
AP-REP ::= [APPLICATION 15] SEQUENCE {
pvno[0] INTEGER,
msg-type[1] INTEGER,
enc-part[2] EncryptedData
}
AP-レップ:、:= [アプリケーション15] 系列pvno[0] INTEGER、msg-タイプ[1]INTEGER、enc-パート[2]EncryptedData
EncAPRepPart ::= [APPLICATION 27] SEQUENCE {
ctime[0] KerberosTime,
cusec[1] INTEGER,
subkey[2] EncryptionKey OPTIONAL,
seq-number[3] INTEGER OPTIONAL
}
EncAPRepPart:、:= [アプリケーション27] 系列ctime[0] KerberosTime、キューセック[1]INTEGER、サブキー[2]EncryptionKey OPTIONAL、seq-数の[3]INTEGER OPTIONAL
NOTE: in EncAPRepPart, the application code in the encrypted part of a message provides an additional check that the message was decrypted properly.
以下に注意してください。 EncAPRepPartに、メッセージの暗号化された部分の応用コードはメッセージが適切に解読された追加チェックを供給します。
The encoded EncAPRepPart is encrypted in the shared session key of the ticket. The optional subkey field can be used in an application-arranged negotiation to choose a per association session key.
コード化されたEncAPRepPartはチケットの共有されたセッションキーで暗号化されます。 協会セッションキーあたりのaを選ぶのにアプリケーションで整っている交渉に任意のサブキー分野を使用できます。
pvno and msg-type These fields are described above in section 5.4.1.
msg-type is KRB_AP_REP.
pvnoとmsg-タイプThese分野は上でセクション5.4.1で説明されます。msg-タイプはKRB_AP_REPです。
enc-part This field is described above in section 5.4.2.
Thisがさばくenc-部分は上でセクション5.4.2で説明されます。
ctime This field contains the current time on the client's host.
ctime This分野はクライアントのホストの上に現在の時間を含んでいます。
cusec This field contains the microsecond part of the client's
timestamp.
キューセックThis分野はクライアントのタイムスタンプのマイクロセカンド部分を含んでいます。
subkey This field contains an encryption key which is to be used
to protect this specific application session. See section
3.2.6 for specifics on how this field is used to negotiate
a key. Unless an application specifies otherwise, if this
field is left out, the sub-session key from the
authenticator, or if also left out, the session key from
the ticket will be used.
サブキーThis分野はこの特定のアプリケーションセッションのときに保護するのに使用されることになっている暗号化キーを含んでいます。 この分野がキーを交渉するのにどう使用されるかの詳細に関してセクション3.2.6を見てください。 また、省かれて、この分野が省かれるならアプリケーションが別の方法で指定しないと、固有識別文字から主要なサブセッションであり、チケットから主要なセッションは使用されるでしょう。
Kohl & Neuman [Page 60] RFC 1510 Kerberos September 1993
コールとヌーマン[60ページ]のRFCの1510のケルベロスの1993年9月
5.5.3. Error message reply
5.5.3. エラーメッセージ回答
If an error occurs while processing the application request, the KRB_ERROR message will be sent in response. See section 5.9.1 for the format of the error message. The cname and crealm fields may be left out if the server cannot determine their appropriate values from the corresponding KRB_AP_REQ message. If the authenticator was decipherable, the ctime and cusec fields will contain the values from it.
誤りがアプリケーション要求を処理している間、発生すると、応答でKRB_ERRORメッセージを送るでしょう。 エラーメッセージの形式に関してセクション5.9.1を見てください。 サーバが対応するKRB_AP_REQメッセージからそれらの適切な値を決定できないなら、cnameとcrealm分野は置かれるかもしれません。 固有識別文字が解読可能だったなら、ctimeとキューセック分野はそれからの値を含むでしょう。
5.6. KRB_SAFE message specification
5.6. KRB_SAFEメッセージ仕様
This section specifies the format of a message that can be used by either side (client or server) of an application to send a tamper- proof message to its peer. It presumes that a session key has previously been exchanged (for example, by using the KRB_AP_REQ/KRB_AP_REP messages).
このセクションはアプリケーションのどちらの側(クライアントかサーバ)によっても使用される、タンパー証拠メッセージを同輩に送ることができるメッセージの形式を指定します。 それは、セッションキーが以前に交換されたと(例えばKRB_AP_REQ/KRB_AP_REPメッセージを使用することによって)推定します。
5.6.1. KRB_SAFE definition
5.6.1. KRB_SAFE定義
The KRB_SAFE message contains user data along with a collision-proof checksum keyed with the session key. The message fields are:
KRB_SAFEメッセージはセッションキーで合わせられた耐衝突のチェックサムに伴う利用者データを含んでいます。 メッセージ分野は以下の通りです。
KRB-SAFE ::= [APPLICATION 20] SEQUENCE {
pvno[0] INTEGER,
msg-type[1] INTEGER,
safe-body[2] KRB-SAFE-BODY,
cksum[3] Checksum
}
KRB-金庫:、:= [アプリケーション20] 系列pvno[0] INTEGER、msg-タイプ[1]INTEGER、安全なボディー[2]KRB-SAFE-BODY、cksum[3]チェックサム
KRB-SAFE-BODY ::= SEQUENCE {
user-data[0] OCTET STRING,
timestamp[1] KerberosTime OPTIONAL,
usec[2] INTEGER OPTIONAL,
seq-number[3] INTEGER OPTIONAL,
s-address[4] HostAddress,
r-address[5] HostAddress OPTIONAL
}
KRBの安全なボディー:、:= 系列利用者データ[0]OCTET STRING、タイムスタンプ[1]KerberosTime OPTIONAL、usec[2] INTEGER OPTIONAL seq-数の[3]INTEGER OPTIONAL、s-アドレス[4]HostAddress、r-アドレス[5]HostAddress OPTIONAL
pvno and msg-type These fields are described above in section 5.4.1.
msg-type is KRB_SAFE.
pvnoとmsg-タイプThese分野は上でセクション5.4.1で説明されます。msg-タイプはKRB_SAFEです。
safe-body This field is a placeholder for the body of the KRB-SAFE
message. It is to be encoded separately and then have the
checksum computed over it, for use in the cksum field.
安全なボディーThis分野はKRB-SAFEメッセージのボディーのためのプレースホルダです。 それで、cksum分野での使用のために別々にコード化されて、次に、それの上でチェックサムを計算することになっています。
cksum This field contains the checksum of the application data.
Checksum details are described in section 6.4. The
cksum This分野はアプリケーションデータのチェックサムを含んでいます。 チェックサムの詳細はセクション6.4で説明されます。 The
Kohl & Neuman [Page 61] RFC 1510 Kerberos September 1993
コールとヌーマン[61ページ]のRFCの1510のケルベロスの1993年9月
checksum is computed over the encoding of the KRB-SAFE-BODY
sequence.
チェックサムはKRB-SAFE-BODY系列のコード化に関して計算されます。
user-data This field is part of the KRB_SAFE and KRB_PRIV messages
and contain the application specific data that is being
passed from the sender to the recipient.
Thisがさばく利用者データは、KRB_SAFEとKRB_PRIVメッセージの一部であり、送付者から受取人まで通過されているアプリケーションの特定のデータを含んでいます。
timestamp This field is part of the KRB_SAFE and KRB_PRIV messages.
Its contents are the current time as known by the sender of
the message. By checking the timestamp, the recipient of
the message is able to make sure that it was recently
generated, and is not a replay.
タイムスタンプThis分野はKRB_SAFEとKRB_PRIVメッセージの一部です。 メッセージ送信者によって知られているように内容は現在の時間です。 タイムスタンプをチェックすることによって、メッセージの受取人は、それが最近生成されたのを確実にすることができて、再生ではありません。
usec This field is part of the KRB_SAFE and KRB_PRIV headers.
It contains the microsecond part of the timestamp.
usec This分野はKRB_SAFEとKRB_PRIVヘッダーの一部です。 それはタイムスタンプのマイクロセカンド部分を含んでいます。
seq-number This field is described above in section 5.3.2.
Thisがさばくseq-数は上でセクション5.3.2で説明されます。
s-address This field specifies the address in use by the sender of
the message.
Thisがさばくs-アドレスはメッセージ送信者で使用中のアドレスを指定します。
r-address This field specifies the address in use by the recipient of
the message. It may be omitted for some uses (such as
broadcast protocols), but the recipient may arbitrarily
reject such messages. This field along with s-address can
be used to help detect messages which have been incorrectly
or maliciously delivered to the wrong recipient.
Thisがさばくr-アドレスはメッセージの受取人で使用中のアドレスを指定します。 それはいくつかの用途(放送プロトコルなどの)のために省略されるかもしれませんが、受取人は任意にそのようなメッセージを拒絶するかもしれません。 不当か陰湿に間違った受取人に提供されたメッセージを検出するのを助けるのにs-アドレスに伴うこの分野を使用できます。
5.7. KRB_PRIV message specification
5.7. KRB_PRIVメッセージ仕様
This section specifies the format of a message that can be used by either side (client or server) of an application to securely and privately send a message to its peer. It presumes that a session key has previously been exchanged (for example, by using the KRB_AP_REQ/KRB_AP_REP messages).
このセクションはアプリケーションのどちらの側(クライアントかサーバ)によっても使用される、メッセージを同輩にしっかりと、そして個人的に送ることができるメッセージの形式を指定します。 それは、セッションキーが以前に交換されたと(例えばKRB_AP_REQ/KRB_AP_REPメッセージを使用することによって)推定します。
5.7.1. KRB_PRIV definition
5.7.1. KRB_PRIV定義
The KRB_PRIV message contains user data encrypted in the Session Key. The message fields are:
KRB_PRIVメッセージはSession Keyで暗号化された利用者データを含んでいます。 メッセージ分野は以下の通りです。
KRB-PRIV ::= [APPLICATION 21] SEQUENCE {
pvno[0] INTEGER,
msg-type[1] INTEGER,
enc-part[3] EncryptedData
}
KRB-PRIV:、:= [アプリケーション21] 系列pvno[0] INTEGER、msg-タイプ[1]INTEGER、enc-パート[3]EncryptedData
Kohl & Neuman [Page 62] RFC 1510 Kerberos September 1993
コールとヌーマン[62ページ]のRFCの1510のケルベロスの1993年9月
EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE {
user-data[0] OCTET STRING,
timestamp[1] KerberosTime OPTIONAL,
usec[2] INTEGER OPTIONAL,
seq-number[3] INTEGER OPTIONAL,
s-address[4] HostAddress, -- sender's addr
r-address[5] HostAddress OPTIONAL
-- recip's addr
}
EncKrbPrivPart:、:= [アプリケーション28] 系列利用者データ[0]OCTET STRING、タイムスタンプ[1]KerberosTime OPTIONAL、usec[2] INTEGER OPTIONAL seq-数の[3]INTEGER OPTIONAL、s-アドレス[4]HostAddress--[5] 送付者のaddr r-アドレスHostAddress OPTIONAL--recipのaddr
NOTE: In EncKrbPrivPart, the application code in the encrypted part of a message provides an additional check that the message was decrypted properly.
以下に注意してください。 EncKrbPrivPartに、メッセージの暗号化された部分の応用コードはメッセージが適切に解読された追加チェックを供給します。
pvno and msg-type These fields are described above in section 5.4.1.
msg-type is KRB_PRIV.
pvnoとmsg-タイプThese分野は上でセクション5.4.1で説明されます。msg-タイプはKRB_PRIVです。
enc-part This field holds an encoding of the EncKrbPrivPart sequence
encrypted under the session key (If supported by the
encryption method in use, an initialization vector may be
passed to the encryption procedure, in order to achieve
proper cipher chaining. The initialization vector might
come from the last block of the ciphertext from the
previous KRB_PRIV message, but it is the application's
choice whether or not to use such an initialization vector.
If left out, the default initialization vector for the
encryption algorithm will be used.). This encrypted
encoding is used for the enc-part field of the KRB-PRIV
message. See section 6 for the format of the ciphertext.
EncKrbPrivPart系列のコード化がセッションキーの下で暗号化したenc-部分This分野船倉(使用中の暗号化メソッドでサポートされるなら、初期化ベクトルは暗号化手順に通過されるかもしれません、適切な暗号推論を達成するために。 初期化ベクトルは暗号文の最後のブロックから前のKRB_PRIVメッセージから来るかもしれませんが、そのような初期化ベクトルを使用するかどうかが、アプリケーションの選択です。 省かれると、暗号化アルゴリズムのためのデフォルト初期化ベクトルは使用されるでしょう。). この暗号化されたコード化はKRB-PRIVメッセージのenc-部分分野に使用されます。 暗号文の形式に関してセクション6を見てください。
user-data, timestamp, usec, s-address and r-address These fields are
described above in section 5.6.1.
利用者データであり、タイムスタンプ、usec、s-アドレス、およびr-アドレスThese分野は上でセクション5.6.1で説明されます。
seq-number This field is described above in section 5.3.2.
Thisがさばくseq-数は上でセクション5.3.2で説明されます。
5.8. KRB_CRED message specification
5.8. KRB_CREDメッセージ仕様
This section specifies the format of a message that can be used to send Kerberos credentials from one principal to another. It is presented here to encourage a common mechanism to be used by applications when forwarding tickets or providing proxies to subordinate servers. It presumes that a session key has already been exchanged perhaps by using the KRB_AP_REQ/KRB_AP_REP messages.
このセクションは1つの主体から別のものにケルベロス資格証明書を送るのに使用できるメッセージの形式を指定します。 それは、サーバを下位に置かせるためにチケットを進めるか、またはプロキシを提供するとき、一般的なメカニズムがアプリケーションで使用されるよう奨励するためにここに提示されます。 それは、セッションキーが恐らくKRB_AP_REQ/KRB_AP_REPメッセージを使用することによって既に交換されたと推定します。
5.8.1. KRB_CRED definition
5.8.1. KRB_CRED定義
The KRB_CRED message contains a sequence of tickets to be sent and information needed to use the tickets, including the session key from
KRB_CREDメッセージは主要な状態で送られるチケットの系列とセッションを含んで、チケットを使用するのに必要である情報を含んでいます。
Kohl & Neuman [Page 63] RFC 1510 Kerberos September 1993
コールとヌーマン[63ページ]のRFCの1510のケルベロスの1993年9月
each. The information needed to use the tickets is encryped under an encryption key previously exchanged. The message fields are:
それぞれ。 チケットを使用するのに必要である情報は以前に交換された暗号化キーの下でencrypedされます。 メッセージ分野は以下の通りです。
KRB-CRED ::= [APPLICATION 22] SEQUENCE {
pvno[0] INTEGER,
msg-type[1] INTEGER, -- KRB_CRED
tickets[2] SEQUENCE OF Ticket,
enc-part[3] EncryptedData
}
KRB-信用:、:= [アプリケーション22] 系列{pvno[0] INTEGER、[1] INTEGERをmsgタイプしてください--KRB_CREDチケット[2]SEQUENCE OF Ticket、enc-パート[3]EncryptedData}
EncKrbCredPart ::= [APPLICATION 29] SEQUENCE {
ticket-info[0] SEQUENCE OF KrbCredInfo,
nonce[1] INTEGER OPTIONAL,
timestamp[2] KerberosTime OPTIONAL,
usec[3] INTEGER OPTIONAL,
s-address[4] HostAddress OPTIONAL,
r-address[5] HostAddress OPTIONAL
}
EncKrbCredPart:、:= [アプリケーション29] 系列チケットインフォメーション[0]SEQUENCE OF KrbCredInfo、一回だけ[1]INTEGER OPTIONAL、タイムスタンプ[2]KerberosTime OPTIONAL(usec[3] INTEGER OPTIONAL)は[4]がHostAddress OPTIONALであるとsで扱います、r-アドレス[5]HostAddress OPTIONAL
KrbCredInfo ::= SEQUENCE {
key[0] EncryptionKey,
prealm[1] Realm OPTIONAL,
pname[2] PrincipalName OPTIONAL,
flags[3] TicketFlags OPTIONAL,
authtime[4] KerberosTime OPTIONAL,
starttime[5] KerberosTime OPTIONAL,
endtime[6] KerberosTime OPTIONAL
renew-till[7] KerberosTime OPTIONAL,
srealm[8] Realm OPTIONAL,
sname[9] PrincipalName OPTIONAL,
caddr[10] HostAddresses OPTIONAL
}
KrbCredInfo:、:= 系列キー[0]EncryptionKey、prealm[1]分野OPTIONAL(pname[2] PrincipalName OPTIONAL)は[3] TicketFlags OPTIONALに旗を揚げさせます、authtime[4] KerberosTime OPTIONAL、starttime[5] KerberosTime OPTIONAL、現金箱[7]を取り替えているendtime[6] KerberosTime OPTIONAL KerberosTime OPTIONAL、srealm[8]分野OPTIONAL、sname[9] PrincipalName OPTIONAL、caddr[10] HostAddresses OPTIONAL
pvno and msg-type These fields are described above in section 5.4.1.
msg-type is KRB_CRED.
pvnoとmsg-タイプThese分野は上でセクション5.4.1で説明されます。msg-タイプはKRB_CREDです。
tickets
These are the tickets obtained from the KDC specifically
for use by the intended recipient. Successive tickets are
paired with the corresponding KrbCredInfo sequence from the
enc-part of the KRB-CRED message.
チケットTheseは意図している受取人によってKDCから特に使用に得られたチケットです。 連続したチケットはKRB-CREDメッセージのenc-部分から対応するKrbCredInfo系列と対にされます。
enc-part This field holds an encoding of the EncKrbCredPart sequence
encrypted under the session key shared between the sender
and the intended recipient. This encrypted encoding is
used for the enc-part field of the KRB-CRED message. See
section 6 for the format of the ciphertext.
EncKrbCredPart系列のコード化がセッションキーの下で暗号化したenc-部分This分野船倉は送付者と意図している受取人を平等に割り当てました。 この暗号化されたコード化はKRB-CREDメッセージのenc-部分分野に使用されます。 暗号文の形式に関してセクション6を見てください。
Kohl & Neuman [Page 64] RFC 1510 Kerberos September 1993
コールとヌーマン[64ページ]のRFCの1510のケルベロスの1993年9月
nonce If practical, an application may require the inclusion of a
nonce generated by the recipient of the message. If the
same value is included as the nonce in the message, it
provides evidence that the message is fresh and has not
been replayed by an attacker. A nonce must never be re-
used; it should be generated randomly by the recipient of
the message and provided to the sender of the mes sage in
an application specific manner.
一回だけのIf実用的であることで、アプリケーションはメッセージの受取人によって生成された一回だけの包含を必要とするかもしれません。 同じ値が一回だけとしてメッセージに含まれているなら、それは、メッセージが新鮮であるという証拠を提供して、攻撃者によって再演されていません。 一回だけを決して再使用してはいけません。 それをメッセージの受取人が手当たりしだいに生成して、アプリケーションの特定の方法でmes賢人の送付者に提供するべきです。
timestamp and usec These fields specify the time that the KRB-CRED
message was generated. The time is used to provide
assurance that the message is fresh.
タイムスタンプとusec These分野はKRB-CREDメッセージが生成された時間を指定します。 時間は、メッセージが新鮮であるという保証を提供するために費やされます。
s-address and r-address These fields are described above in section
5.6.1. They are used optionally to provide additional
assurance of the integrity of the KRB-CRED message.
s-アドレスとr-アドレスThese分野は上でセクション5.6.1で説明されます。 それらは、KRB-CREDメッセージの保全の追加保証を提供するのに任意に使用されます。
key This field exists in the corresponding ticket passed by the
KRB-CRED message and is used to pass the session key from
the sender to the intended recipient. The field's encoding
is described in section 6.2.
主要なThis分野は、KRB-CREDメッセージによって渡された対応するチケットの中に存在していて、送付者から意図している受取人まで主要なセッションを過ぎるのに使用されます。 フィールドのコード化はセクション6.2で説明されます。
The following fields are optional. If present, they can be associated with the credentials in the remote ticket file. If left out, then it is assumed that the recipient of the credentials already knows their value.
以下の分野は任意です。 存在しているなら、リモートチケットファイルの資格証明書にそれらを関連づけることができます。 省かれるなら、資格証明書の受取人が既にそれらの値を知ると思われます。
prealm and pname The name and realm of the delegated principal
identity.
代表として派遣された主要なアイデンティティの名前と分野をprealmして、pnameします。
flags, authtime, starttime, endtime, renew-till, srealm, sname,
and caddr These fields contain the values of the
corresponding fields from the ticket found in the ticket
field. Descriptions of the fields are identical to the
descriptions in the KDC-REP message.
旗、authtime、starttime、endtime、現金箱を取り替えます、srealm、sname、およびcaddr These分野はチケット野原で発見されるチケットからの対応する分野の値を含んでいます。 分野の記述はKDC-REPメッセージにおける記述と同じです。
5.9. Error message specification
5.9. エラーメッセージ仕様
This section specifies the format for the KRB_ERROR message. The fields included in the message are intended to return as much information as possible about an error. It is not expected that all the information required by the fields will be available for all types of errors. If the appropriate information is not available when the message is composed, the corresponding field will be left out of the message.
このセクションはKRB_ERRORメッセージに形式を指定します。 メッセージに含まれていた分野ができるだけ誤りに関して多くの情報を返すことを意図します。 分野によって必要とされたすべての情報がすべてのタイプの誤りに利用可能になるというわけではないと予想されます。 メッセージがいつ落ち着いているかという適切な情報が利用可能でないなら、対応する野原はメッセージから外されるでしょう。
Note that since the KRB_ERROR message is not protected by any encryption, it is quite possible for an intruder to synthesize or
またはKRB_ERRORメッセージがどんな暗号化でも保護されないので侵入者が統合するのが、かなり可能であることに注意してください。
Kohl & Neuman [Page 65] RFC 1510 Kerberos September 1993
コールとヌーマン[65ページ]のRFCの1510のケルベロスの1993年9月
modify such a message. In particular, this means that the client should not use any fields in this message for security-critical purposes, such as setting a system clock or generating a fresh authenticator. The message can be useful, however, for advising a user on the reason for some failure.
そのようなメッセージを変更してください。 特に、これは、クライアントがセキュリティ重要な目的にこのメッセージのどんな分野も使用するべきでないことを意味します、システムクロックを設定するか、または新鮮な固有識別文字を生成するのなどように。 しかしながら、メッセージは何らかの失敗の理由に関してユーザにアドバイスすることの役に立つ場合があります。
5.9.1. KRB_ERROR definition
5.9.1. KRB_ERROR定義
The KRB_ERROR message consists of the following fields:
KRB_ERRORメッセージは以下の分野から成ります:
KRB-ERROR ::= [APPLICATION 30] SEQUENCE {
pvno[0] INTEGER,
msg-type[1] INTEGER,
ctime[2] KerberosTime OPTIONAL,
cusec[3] INTEGER OPTIONAL,
stime[4] KerberosTime,
susec[5] INTEGER,
error-code[6] INTEGER,
crealm[7] Realm OPTIONAL,
cname[8] PrincipalName OPTIONAL,
realm[9] Realm, -- Correct realm
sname[10] PrincipalName, -- Correct name
e-text[11] GeneralString OPTIONAL,
e-data[12] OCTET STRING OPTIONAL
}
KRB-誤り:、:= [アプリケーション30] 系列pvno[0] INTEGER、[1] msg-タイプINTEGER、ctime[2] KerberosTime OPTIONAL、キューセック[3]INTEGER OPTIONAL、stime[4] KerberosTime、susec[5] INTEGER、エラーコード[6]INTEGER、crealm[7]分野OPTIONAL、cname[8] PrincipalName OPTIONAL、分野[9]分野--正しい分野sname[10] PrincipalName--Correctは電子テキストを[11]GeneralString OPTIONALと命名します、電子データ[12]OCTET STRING OPTIONALです。
pvno and msg-type These fields are described above in section 5.4.1.
msg-type is KRB_ERROR.
pvnoとmsg-タイプThese分野は上でセクション5.4.1で説明されます。msg-タイプはKRB_ERRORです。
ctime This field is described above in section 5.4.1.
ctime This分野は上でセクション5.4.1で説明されます。
cusec This field is described above in section 5.5.2.
キューセックThis分野は上でセクション5.5.2で説明されます。
stime This field contains the current time on the server. It is
of type KerberosTime.
stime This分野はサーバに現在の時間を含んでいます。タイプKerberosTimeにはそれがあります。
susec This field contains the microsecond part of the server's
timestamp. Its value ranges from 0 to 999. It appears
along with stime. The two fields are used in conjunction to
specify a reasonably accurate timestamp.
susec This分野はサーバのタイムスタンプのマイクロセカンド部分を含んでいます。 値は0〜999まで及びます。 それはstimeと共に現れます。 2つの分野が、合理的に正確なタイムスタンプを指定するのに接続詞に使用されます。
error-code This field contains the error code returned by Kerberos or
the server when a request fails. To interpret the value of
this field see the list of error codes in section 8.
Implementations are encouraged to provide for national
language support in the display of error messages.
Thisがさばくエラーコードは要求が失敗するとケルベロスかサーバによって返されたエラーコードを含んでいます。 この分野の値を解釈するには、セクション8のエラーコードのリストを見てください。 実装がエラーメッセージのディスプレイにおける国語サポートに備えるよう奨励されます。
crealm, cname, srealm and sname These fields are described above in
crealm、cname、srealm、およびsname These分野は中で上で説明されます。
Kohl & Neuman [Page 66] RFC 1510 Kerberos September 1993
コールとヌーマン[66ページ]のRFCの1510のケルベロスの1993年9月
section 5.3.1.
セクション5.3.1。
e-text This field contains additional text to help explain the
error code associated with the failed request (for example,
it might include a principal name which was unknown).
Thisがさばく電子テキストは失敗した要求に関連しているエラーコードについて説明するのを助ける追加テキストを含んでいます(例えば、それは未知である主要な名前を含むかもしれません)。
e-data This field contains additional data about the error for use
by the application to help it recover from or handle the
error. If the errorcode is KDC_ERR_PREAUTH_REQUIRED, then
the e-data field will contain an encoding of a sequence of
padata fields, each corresponding to an acceptable pre-
authentication method and optionally containing data for
the method:
アプリケーションによる使用が、それが誤りを回復するか、または扱うのを助けるように、Thisがさばく電子データは誤りに関して追加データを含んでいます。 errorcodeがKDC_ERR_PREAUTH_REQUIREDであるなら、電子データ・フィールドはpadata分野の系列のコード化を含むでしょう、それぞれ許容できるプレ認証方法と任意にメソッドのためのデータを含むと対応しています:
METHOD-DATA ::= SEQUENCE of PA-DATA
メソッドデータ:、:= PA-データの系列
If the error-code is KRB_AP_ERR_METHOD, then the e-data field will contain an encoding of the following sequence:
エラーコードがKRB_AP_ERR_METHODであるなら、電子データ・フィールドは以下の系列のコード化を含むでしょう:
METHOD-DATA ::= SEQUENCE {
method-type[0] INTEGER,
method-data[1] OCTET STRING OPTIONAL
}
メソッドデータ:、:= 系列[1] [0] メソッドタイプINTEGER、メソッドデータOCTET STRING OPTIONAL
method-type will indicate the required alternate method; method-data will contain any required additional information.
メソッドタイプは必要な代替方法を示すでしょう。 メソッドデータはどんな必要な追加情報も含むでしょう。
6. Encryption and Checksum Specifications
6. 暗号化とチェックサム仕様
The Kerberos protocols described in this document are designed to use stream encryption ciphers, which can be simulated using commonly available block encryption ciphers, such as the Data Encryption Standard [11], in conjunction with block chaining and checksum methods [12]. Encryption is used to prove the identities of the network entities participating in message exchanges. The Key Distribution Center for each realm is trusted by all principals registered in that realm to store a secret key in confidence. Proof of knowledge of this secret key is used to verify the authenticity of a principal.
本書では説明されたケルベロスプロトコルはストリーム暗号化暗号を使用するように設計されています、データ暗号化規格[11]などのように、ブロック連鎖とチェックサムメソッド[12]に関連して。一般的に利用可能なブロック暗号化暗号を使用することで暗号をシミュレートできます。 暗号化は、交換処理に参加するネットワーク実体のアイデンティティを立証するのに使用されます。 各分野へのKey Distributionセンターが信用で秘密鍵を保存するとその分野に登録されたすべての校長によって信じられます。 この秘密鍵に関する知識の証拠は、元本の信憑性について確かめるのに使用されます。
The KDC uses the principal's secret key (in the AS exchange) or a shared session key (in the TGS exchange) to encrypt responses to ticket requests; the ability to obtain the secret key or session key implies the knowledge of the appropriate keys and the identity of the KDC. The ability of a principal to decrypt the KDC response and present a Ticket and a properly formed Authenticator (generated with the session key from the KDC response) to a service verifies the identity of the principal; likewise the ability of the service to
KDCはチケット要求への応答を暗号化するのに、主体の秘密鍵(AS交換における)か共有されたセッションキー(TGS交換における)を使用します。 秘密鍵かセッションキーを入手する能力は適切なキーに関する知識とKDCのアイデンティティを含意します。 元本がサービスにKDCが応答であると解読して、Ticketと適切に形成されたAuthenticatorを寄贈する(KDC応答によって主要なセッションで、生成されます)能力は主体のアイデンティティについて確かめます。 同様にサービスの能力
Kohl & Neuman [Page 67] RFC 1510 Kerberos September 1993
コールとヌーマン[67ページ]のRFCの1510のケルベロスの1993年9月
extract the session key from the Ticket and prove its knowledge thereof in a response verifies the identity of the service.
Ticketから主要なセッションを抽出してください、そして、それの応答における知識がサービスのアイデンティティについて確かめると立証してください。
The Kerberos protocols generally assume that the encryption used is secure from cryptanalysis; however, in some cases, the order of fields in the encrypted portions of messages are arranged to minimize the effects of poorly chosen keys. It is still important to choose good keys. If keys are derived from user-typed passwords, those passwords need to be well chosen to make brute force attacks more difficult. Poorly chosen keys still make easy targets for intruders.
一般に、ケルベロスプロトコルは、使用される暗号化が暗号文解読術から安全であると仮定します。 しかしながら、いくつかでは、不十分に選ばれたキーの効果を最小にするためにケース、メッセージの暗号化された部分での分野の注文を配置します。 良いキーを選ぶのはまだ重要です。 ユーザによってタイプされたパスワードからキーを得るなら、それらのパスワードは、ブルートフォースアタックをより難しくするように適切である必要があります。 不十分に選ばれたキーはまだ侵入者のための格好の的を作っています。
The following sections specify the encryption and checksum mechanisms currently defined for Kerberos. The encodings, chaining, and padding requirements for each are described. For encryption methods, it is often desirable to place random information (often referred to as a confounder) at the start of the message. The requirements for a confounder are specified with each encryption mechanism.
以下のセクションはメカニズムが現在ケルベロスのために定義した暗号化とチェックサムを指定します。 encodingsと、推論と、それぞれのための要件を水増しするのは説明されます。 暗号化メソッドに、無作為の情報(しばしば交絡因子と呼ばれる)をメッセージの始めに置くのはしばしば望ましいです。 交絡因子のための要件はそれぞれの暗号化メカニズムで指定されます。
Some encryption systems use a block-chaining method to improve the the security characteristics of the ciphertext. However, these chaining methods often don't provide an integrity check upon decryption. Such systems (such as DES in CBC mode) must be augmented with a checksum of the plaintext which can be verified at decryption and used to detect any tampering or damage. Such checksums should be good at detecting burst errors in the input. If any damage is detected, the decryption routine is expected to return an error indicating the failure of an integrity check. Each encryption type is expected to provide and verify an appropriate checksum. The specification of each encryption method sets out its checksum requirements.
いくつかの暗号化システムが暗号文のセキュリティの特性を改良するブロック連鎖メソッドを使用します。 しかしながら、これらの推論メソッドはしばしば復号化の保全チェックを提供するというわけではありません。 そのようなシステム(CBCモードによるDESなどの)を復号化で確かめることができる平文のチェックサムで増大して、どんな改ざんや損害も検出するのに、使用しなければなりません。 そのようなチェックサムは入力におけるバースト誤りを検出するのが上手であるはずです。 何か損害が検出されるなら、復号化ルーチンが保全チェックの失敗を示す誤りを返すと予想されます。 それぞれの暗号化タイプは、適切なチェックサムを提供して、確かめると予想されます。 それぞれの暗号化メソッドの仕様はチェックサム要件を述べます。
Finally, where a key is to be derived from a user's password, an algorithm for converting the password to a key of the appropriate type is included. It is desirable for the string to key function to be one-way, and for the mapping to be different in different realms. This is important because users who are registered in more than one realm will often use the same password in each, and it is desirable that an attacker compromising the Kerberos server in one realm not obtain or derive the user's key in another.
最終的に、キーがユーザのパスワードから得られることになっているところに適切なタイプのキーにパスワードを変換するためのアルゴリズムは含まれています。 主要な機能へのストリングが一方向であり、マッピングが異なった分野において異なるのは、望ましいです。1つ以上の分野に登録されるユーザがそれぞれでしばしば同じパスワードを使用するので、これは重要であり、1つの分野でケルベロスサーバに感染する攻撃者が別のものでユーザのキーを入手もしませんし、引き出しもしないのが、望ましいです。
For a discussion of the integrity characteristics of the candidate encryption and checksum methods considered for Kerberos, the the reader is referred to [13].
ケルベロスのために考えられた候補暗号化とチェックサムメソッドの保全の特性の議論について、読者は[13]を参照されます。
6.1. Encryption Specifications
6.1. 暗号化仕様
The following ASN.1 definition describes all encrypted messages. The enc-part field which appears in the unencrypted part of messages in
以下のASN.1定義はすべての暗号化メッセージについて説明します。 メッセージの非暗号化された部分に中に現れるenc-部分野原
Kohl & Neuman [Page 68] RFC 1510 Kerberos September 1993
コールとヌーマン[68ページ]のRFCの1510のケルベロスの1993年9月
section 5 is a sequence consisting of an encryption type, an optional key version number, and the ciphertext.
セクション5は暗号化タイプ、任意の主要なバージョン番号、および暗号文から成る系列です。
EncryptedData ::= SEQUENCE {
etype[0] INTEGER, -- EncryptionType
kvno[1] INTEGER OPTIONAL,
cipher[2] OCTET STRING -- ciphertext
}
EncryptedData:、:= 系列etype[0] INTEGER--EncryptionType kvno[1] INTEGER OPTIONAL、暗号[2]OCTET STRING--暗号文
etype This field identifies which encryption algorithm was used
to encipher the cipher. Detailed specifications for
selected encryption types appear later in this section.
etype This分野は、どの暗号化アルゴリズムが暗号を暗号化するのに使用されたかを特定します。 選択された暗号化タイプのための仕様詳細は後でこのセクションに現れます。
kvno This field contains the version number of the key under
which data is encrypted. It is only present in messages
encrypted under long lasting keys, such as principals'
secret keys.
kvno This分野はデータが暗号化されているキーのバージョン番号を含んでいます。 それは単に主体の秘密鍵などの持続的なキーの下で暗号化されたメッセージに存在しています。
cipher This field contains the enciphered text, encoded as an
OCTET STRING.
Thisがさばく暗号はOCTET STRINGとしてコード化された暗号化されたテキストを含んでいます。
The cipher field is generated by applying the specified encryption algorithm to data composed of the message and algorithm-specific inputs. Encryption mechanisms defined for use with Kerberos must take sufficient measures to guarantee the integrity of the plaintext, and we recommend they also take measures to protect against precomputed dictionary attacks. If the encryption algorithm is not itself capable of doing so, the protections can often be enhanced by adding a checksum and a confounder.
暗号分野は、メッセージで構成されたデータとアルゴリズム特有の入力に指定された暗号化アルゴリズムを適用することによって、生成されます。 ケルベロスとの使用のために定義された暗号化メカニズムは平文の保全を保証できるくらいの対策を実施しなければなりません、そして、私たちはまた、それらが前計算された辞書攻撃から守る対策を実施することを勧めます。 暗号化アルゴリズム自体がそうすることができないなら、チェックサムと交絡因子を加えることによって、保護をしばしば機能アップできます。
The suggested format for the data to be encrypted includes a confounder, a checksum, the encoded plaintext, and any necessary padding. The msg-seq field contains the part of the protocol message described in section 5 which is to be encrypted. The confounder, checksum, and padding are all untagged and untyped, and their length is exactly sufficient to hold the appropriate item. The type and length is implicit and specified by the particular encryption type being used (etype). The format for the data to be encrypted is described in the following diagram:
データが暗号化される提案された形式は交絡因子、チェックサム、コード化された平文、およびどんな必要な詰め物も含んでいます。 msg-seq分野は暗号化されていることになっているセクション5で説明されたプロトコルメッセージの部分を含んでいます。 交絡因子、チェックサム、および詰め物は、すべて非タグ付けをされて、非タイプされます、そして、それらの長さは、適切な項目を保持するためにまさに十分です。 特定の暗号化タイプによって使用されることで(etype)、タイプと長さは、内在して指定されています。 データが暗号化される形式は以下のダイヤグラムで説明されます:
+-----------+----------+-------------+-----+
|confounder | check | msg-seq | pad |
+-----------+----------+-------------+-----+
+-----------+----------+-------------+-----+ |交絡因子| チェック| msg-seq| パッド| +-----------+----------+-------------+-----+
The format cannot be described in ASN.1, but for those who prefer an ASN.1-like notation:
形式は、ASN.1で説明されるのではなく、ASNの.1のような記法を好む人のために説明できます:
Kohl & Neuman [Page 69] RFC 1510 Kerberos September 1993
コールとヌーマン[69ページ]のRFCの1510のケルベロスの1993年9月
CipherText ::= ENCRYPTED SEQUENCE {
confounder[0] UNTAGGED OCTET STRING(conf_length) OPTIONAL,
check[1] UNTAGGED OCTET STRING(checksum_length) OPTIONAL,
msg-seq[2] MsgSequence,
pad UNTAGGED OCTET STRING(pad_length) OPTIONAL
}
暗号文:、:= 暗号化された系列[1] UNTAGGED OCTET STRING(チェックサム_長さ)OPTIONAL、msg-seq[2] MsgSequenceは、交絡因子[0]UNTAGGED OCTET STRING(conf_長さ)OPTIONALがUNTAGGED OCTET STRING(パッド_長さ)OPTIONALを水増しするのをチェックします。
In the above specification, UNTAGGED OCTET STRING(length) is the notation for an octet string with its tag and length removed. It is not a valid ASN.1 type. The tag bits and length must be removed from the confounder since the purpose of the confounder is so that the message starts with random data, but the tag and its length are fixed. For other fields, the length and tag would be redundant if they were included because they are specified by the encryption type.
上記の仕様では、UNTAGGED OCTET STRING(長さ)はそのタグと長さを取り除いている八重奏ストリングのための記法です。 それは有効なASN.1タイプではありません。 交絡因子の目的が取り除くので、メッセージが無作為のデータから始まるように交絡因子からタグビットと長さを取り除かなければなりませんが、タグとその長さは固定しています。 他の分野において、暗号化タイプによって指定されるのでそれらが含まれているなら、長さとタグは余分でしょうに。
One generates a random confounder of the appropriate length, placing it in confounder; zeroes out check; calculates the appropriate checksum over confounder, check, and msg-seq, placing the result in check; adds the necessary padding; then encrypts using the specified encryption type and the appropriate key.
それを交絡因子に置いて、1つは適切な長さの無作為の交絡因子を生成します。 チェックからのゼロ。 結果をチェックに置いて、交絡因子、チェック、およびmsg-seqの上で適切なチェックサムについて計算します。 必要な詰め物を加えます。 そして、指定された暗号化タイプと適切なキーを使用することで、暗号化します。
Unless otherwise specified, a definition of an encryption algorithm that specifies a checksum, a length for the confounder field, or an octet boundary for padding uses this ciphertext format (The ordering of the fields in the CipherText is important. Additionally, messages encoded in this format must include a length as part of the msg-seq field. This allows the recipient to verify that the message has not been truncated. Without a length, an attacker could use a chosen plaintext attack to generate a message which could be truncated, while leaving the checksum intact. Note that if the msg-seq is an encoding of an ASN.1 SEQUENCE or OCTET STRING, then the length is part of that encoding.). Those fields which are not specified will be omitted.
別の方法で指定されない場合、チェックサムを指定する暗号化アルゴリズムの定義、交絡因子分野への長さ、または詰め物のための八重奏境界がこの暗号文形式を使用します。(CipherTextでの分野の注文は重要です。 さらに、この形式でコード化されたメッセージはmsg-seq分野の一部として長さを含まなければなりません。 これで、受取人は、メッセージが先端を切られていないことを確かめることができます。 長さがなければ、攻撃者は、チェックサムを完全なままにする間に先端を切られることができたメッセージを生成するのに選ばれた平文攻撃を使用できました。 長さがmsg-seqがASN.1SEQUENCEかOCTET STRINGのコード化であるならそのコード化の一部であることに注意してください。). 指定されないそれらの分野は省略されるでしょう。
In the interest of allowing all implementations using a particular encryption type to communicate with all others using that type, the specification of an encryption type defines any checksum that is needed as part of the encryption process. If an alternative checksum is to be used, a new encryption type must be defined.
特定の暗号化タイプを使用するすべての実装がすべての他のものとコミュニケートするのをそのタイプを使用することで許容することのために、暗号化タイプの仕様は暗号化プロセスの一部として必要であるどんなチェックサムも定義します。 代替のチェックサムが使用されていることであるなら、新しい暗号化タイプを定義しなければなりません。
Some cryptosystems require additional information beyond the key and the data to be encrypted. For example, DES, when used in cipher- block-chaining mode, requires an initialization vector. If required, the description for each encryption type must specify the source of such additional information.
暗号系の中にはキーとデータを超えた追加情報が暗号化されるのを必要とするものもあります。 例えば、暗号ブロック連鎖モードで使用されると、DESは初期化ベクトルを必要とします。 必要なら、それぞれの暗号化タイプのための記述はそのような追加情報の源を指定しなければなりません。
Kohl & Neuman [Page 70] RFC 1510 Kerberos September 1993
コールとヌーマン[70ページ]のRFCの1510のケルベロスの1993年9月
6.2. Encryption Keys
6.2. 暗号化キー
The sequence below shows the encoding of an encryption key:
以下の系列は暗号化キーのコード化を示しています:
EncryptionKey ::= SEQUENCE {
keytype[0] INTEGER,
keyvalue[1] OCTET STRING
}
EncryptionKey:、:= 系列keytype[0] INTEGER、keyvalue[1] OCTET STRING
keytype This field specifies the type of encryption key that
follows in the keyvalue field. It will almost always
correspond to the encryption algorithm used to generate the
EncryptedData, though more than one algorithm may use the
same type of key (the mapping is many to one). This might
happen, for example, if the encryption algorithm uses an
alternate checksum algorithm for an integrity check, or a
different chaining mechanism.
keytype This分野はkeyvalue分野で続く暗号化キーのタイプを指定します。 それはほとんどいつもEncryptedDataを生成するのに使用される暗号化アルゴリズムに対応するでしょう、1つ以上のアルゴリズムが同じタイプのキーを使用するかもしれませんが(マッピングは1つに多くです)。 例えば、暗号化アルゴリズムが保全チェック、または異なった推論メカニズムに代替のチェックサムアルゴリズムを使用するなら、これは起こるかもしれません。
keyvalue This field contains the key itself, encoded as an octet
string.
八重奏ストリングとしてコード化されて、keyvalue This分野はキー自体を含んでいます。
All negative values for the encryption key type are reserved for local use. All non-negative values are reserved for officially assigned type fields and interpretations.
暗号化の主要なタイプのためのすべての負の数が地方の使用のために予約されます。 すべての非負の数が公式に割り当てられたタイプ分野と解釈のために予約されます。
6.3. Encryption Systems
6.3. 暗号化システム
6.3.1. The NULL Encryption System (null)
6.3.1. ヌル暗号化システム(ヌル)です。
If no encryption is in use, the encryption system is said to be the NULL encryption system. In the NULL encryption system there is no checksum, confounder or padding. The ciphertext is simply the plaintext. The NULL Key is used by the null encryption system and is zero octets in length, with keytype zero (0).
どんな暗号化も使用中でないなら、暗号化システムはNULL暗号化システムであると言われます。 NULL暗号化では、そこのシステムは、チェックサムがない、交絡因子または詰め物です。 暗号文は単に平文です。 NULL Keyはヌル暗号化システムによって使用されて、keytypeゼロ(0)に従った長さが八重奏ではありません。
6.3.2. DES in CBC mode with a CRC-32 checksum (des-cbc-crc)
6.3.2. CRC-32チェックサムがあるCBCモードによるDES(des-cbc-crc)
The des-cbc-crc encryption mode encrypts information under the Data Encryption Standard [11] using the cipher block chaining mode [12]. A CRC-32 checksum (described in ISO 3309 [14]) is applied to the confounder and message sequence (msg-seq) and placed in the cksum field. DES blocks are 8 bytes. As a result, the data to be encrypted (the concatenation of confounder, checksum, and message) must be padded to an 8 byte boundary before encryption. The details of the encryption of this data are identical to those for the des- cbc-md5 encryption mode.
des-cbc-crc暗号化モードは、データ暗号化規格の下で[11] 暗号ブロック連鎖モード[12]を使用することで情報を暗号化します。 CRC-32チェックサム、(ISOで説明されて、3309[14])は交絡因子とメッセージ系列(msg-seq)に適用されて、cksum分野に置かれます。 DESブロックは8バイトです。 その結果、暗号化の前に暗号化されるべきデータ(交絡因子、チェックサム、およびメッセージの連結)を8バイト境界に水増ししなければなりません。 des- cbc-md5暗号化モードに、このデータの暗号化の詳細はそれらと同じです。
Note that, since the CRC-32 checksum is not collisionproof, an
CRC-32チェックサムがcollisionproofでないので、それに注意してください。
Kohl & Neuman [Page 71] RFC 1510 Kerberos September 1993
コールとヌーマン[71ページ]のRFCの1510のケルベロスの1993年9月
attacker could use a probabilistic chosenplaintext attack to generate a valid message even if a confounder is used [13]. The use of collision-proof checksums is recommended for environments where such attacks represent a significant threat. The use of the CRC-32 as the checksum for ticket or authenticator is no longer mandated as an interoperability requirement for Kerberos Version 5 Specification 1 (See section 9.1 for specific details).
攻撃者は、交絡因子が中古の[13]であっても有効なメッセージを生成するのに確率的なchosenplaintext攻撃を使用するかもしれません。 耐衝突のチェックサムの使用はそのような攻撃が多大なる脅威を表す環境のために推薦されます。 チェックサムとしてのCRC-32のチケットか固有識別文字の使用はもうケルベロスバージョン5Specification1のための相互運用性要件として強制されません(特定の詳細に関してセクション9.1を見てください)。
6.3.3. DES in CBC mode with an MD4 checksum (des-cbc-md4)
6.3.3. MD4チェックサムがあるCBCモードによるDES(des-cbc-md4)
The des-cbc-md4 encryption mode encrypts information under the Data Encryption Standard [11] using the cipher block chaining mode [12]. An MD4 checksum (described in [15]) is applied to the confounder and message sequence (msg-seq) and placed in the cksum field. DES blocks are 8 bytes. As a result, the data to be encrypted (the concatenation of confounder, checksum, and message) must be padded to an 8 byte boundary before encryption. The details of the encryption of this data are identical to those for the descbc-md5 encryption mode.
des-cbc-md4暗号化モードは、データ暗号化規格の下で[11] 暗号ブロック連鎖モード[12]を使用することで情報を暗号化します。 MD4チェックサム、(説明されたコネ[15])は、交絡因子とメッセージ系列(msg-seq)に適用されて、cksum分野に置かれます。 DESブロックは8バイトです。 その結果、暗号化の前に暗号化されるべきデータ(交絡因子、チェックサム、およびメッセージの連結)を8バイト境界に水増ししなければなりません。 descbc-md5暗号化モードに、このデータの暗号化の詳細はそれらと同じです。
6.3.4. DES in CBC mode with an MD5 checksum (des-cbc-md5)
6.3.4. MD5チェックサムがあるCBCモードによるDES(des-cbc-md5)
The des-cbc-md5 encryption mode encrypts information under the Data Encryption Standard [11] using the cipher block chaining mode [12]. An MD5 checksum (described in [16]) is applied to the confounder and message sequence (msg-seq) and placed in the cksum field. DES blocks are 8 bytes. As a result, the data to be encrypted (the concatenation of confounder, checksum, and message) must be padded to an 8 byte boundary before encryption.
des-cbc-md5暗号化モードは、データ暗号化規格の下で[11] 暗号ブロック連鎖モード[12]を使用することで情報を暗号化します。 MD5チェックサム、(説明されたコネ[16])は、交絡因子とメッセージ系列(msg-seq)に適用されて、cksum分野に置かれます。 DESブロックは8バイトです。 その結果、暗号化の前に暗号化されるべきデータ(交絡因子、チェックサム、およびメッセージの連結)を8バイト境界に水増ししなければなりません。
Plaintext and DES ciphtertext are encoded as 8-octet blocks which are concatenated to make the 64-bit inputs for the DES algorithms. The first octet supplies the 8 most significant bits (with the octet's MSbit used as the DES input block's MSbit, etc.), the second octet the next 8 bits, ..., and the eighth octet supplies the 8 least significant bits.
平文とDES ciphtertextはDESアルゴリズムのための64ビットの入力をするように連結される8八重奏のブロックとしてコード化されます。最初の八重奏は8つの最上位ビット(DES入力ブロックのMSbitなどとして使用される八重奏のMSbitと)、2番目の八重奏に次の8ビットを供給します…, そして、8番目の八重奏は8つの最下位ビットを供給します。
Encryption under DES using cipher block chaining requires an additional input in the form of an initialization vector. Unless otherwise specified, zero should be used as the initialization vector. Kerberos' use of DES requires an 8-octet confounder.
暗号ブロック連鎖を使用するDESの下の暗号化は初期化ベクトルの形で追加入力を必要とします。 別の方法で指定されない場合、ゼロは初期化ベクトルとして使用されるべきです。 DESのケルベロスの使用は8八重奏の交絡因子を必要とします。
The DES specifications identify some "weak" and "semiweak" keys; those keys shall not be used for encrypting messages for use in Kerberos. Additionally, because of the way that keys are derived for the encryption of checksums, keys shall not be used that yield "weak" or "semi-weak" keys when eXclusive-ORed with the constant F0F0F0F0F0F0F0F0.
DES仕様はいくつかの「弱い」と"semiweak"キーを特定します。 ケルベロスにおける使用へのメッセージを暗号化するのにそれらのキーを使用しないものとします。 キーがチェックサムの暗号化のために引き出されて、キーを使用しないものとする方法のために、一定のF0F0F0F0F0F0F0F0とeXclusive-ORedであるときに、さらに、それは「弱い」か「準弱い」キーをもたらします。
Kohl & Neuman [Page 72] RFC 1510 Kerberos September 1993
コールとヌーマン[72ページ]のRFCの1510のケルベロスの1993年9月
A DES key is 8 octets of data, with keytype one (1). This consists of 56 bits of key, and 8 parity bits (one per octet). The key is encoded as a series of 8 octets written in MSB-first order. The bits within the key are also encoded in MSB order. For example, if the encryption key is: (B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8) where B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8 are the parity bits, the first octet of the key would be B1,B2,...,B7,P1 (with B1 as the MSbit). [See the FIPS 81 introduction for reference.]
DESキーはkeytype1つ(1)があるデータの8つの八重奏です。 これはキー、および8つのパリティビット(1八重奏あたり1つ)の56ビットから成ります。 最初にMSBに書かれた一連の8つの八重奏が注文されるとき、キーはコード化されます。 また、キーの中のビットはMSBオーダーでコード化されます。 例えば、暗号化であるなら、キーは以下の通りです。 (B1、B2、…、B7、P1、B8、…、B14、P2、B15、…、B49、P7、B50、…、B56、P8) どこB1、B2…B56はMSB注文、およびP1、P2、…のキービットです。P8がパリティビットである、キーの最初の八重奏はB1、B2、…でしょう。B7、P1(MSbitとしてのB1と)。 [参照に関してFIPS81序論を見てください。]
To generate a DES key from a text string (password), the text string normally must have the realm and each component of the principal's name appended(In some cases, it may be necessary to use a different "mix-in" string for compatibility reasons; see the discussion of padata in section 5.4.2.), then padded with ASCII nulls to an 8 byte boundary. This string is then fan-folded and eXclusive-ORed with itself to form an 8 byte DES key. The parity is corrected on the key, and it is used to generate a DES CBC checksum on the initial string (with the realm and name appended). Next, parity is corrected on the CBC checksum. If the result matches a "weak" or "semiweak" key as described in the DES specification, it is eXclusive-ORed with the constant 00000000000000F0. Finally, the result is returned as the key. Pseudocode follows:
テキスト文字列(パスワード)から主要なDESを発生させるように、通常、テキスト文字列は校長の名前の分野と各成分を追加されて(いくつかの場合、互換性理由に異なった「中では、混入する」ストリングを使用するのが必要であるかもしれません;.2にセクション5.4のpadataの議論を見てください)、次に、ASCIIヌルで水増しするように8バイト境界に持たなければなりません。 次に、このストリングはファンに折り重ねられます、そして、8バイトのDESキーはフォームへのそれ自体がいるeXclusive-ORedが折り重ねられます。 同等はキーの上に修正されます、そして、それは、初期のストリング(分野と名前を追加している)の上にDES CBCチェックサムを発生させるのに使用されます。 次に、同等はCBCチェックサムで修正されます。 結果がDES仕様で説明されるように「弱い」か"semiweak"キーに合っているなら、それは一定の00000000000000F0とeXclusive-ORedです。 最終的に、結果はキーとして返されます。 擬似コードは従います:
string_to_key(string,realm,name) {
odd = 1;
s = string + realm;
for(each component in name) {
s = s + component;
}
tempkey = NULL;
pad(s); /* with nulls to 8 byte boundary */
for(8byteblock in s) {
if(odd == 0) {
odd = 1;
reverse(8byteblock)
}
else odd = 0;
tempkey = tempkey XOR 8byteblock;
}
fixparity(tempkey);
key = DES-CBC-check(s,tempkey);
fixparity(key);
if(is_weak_key_key(key))
key = key XOR 0xF0;
return(key);
}
_キー(ストリング、分野、名前)へのストリング_変な=1 ; s=は(名前の各コンポーネント)のために+ 分野を結びます。s=s+コンポーネント; tempkeyはNULLと等しいです; パッド、(sの8byteblock)のための8バイト境界*/へのヌルがある/*、変な=1 ; (変な=0)逆(8byteblock)であるなら、変な=0; tempkeyするのはtempkey XOR 8byteblockと等しいです;、fixparity(tempkey); 主要な=DES-CBC-チェック(s、tempkey); fixparity(主要な); ;(_弱い_キー_キー(キー)です)キーが主要なXOR 0xF0と等しいなら 戻ってください(主要な)。
Kohl & Neuman [Page 73] RFC 1510 Kerberos September 1993
コールとヌーマン[73ページ]のRFCの1510のケルベロスの1993年9月
6.4. Checksums
6.4. チェックサム
The following is the ASN.1 definition used for a checksum:
↓これはチェックサムに使用されるASN.1定義です:
Checksum ::= SEQUENCE {
cksumtype[0] INTEGER,
checksum[1] OCTET STRING
}
チェックサム:、:= 系列cksumtype[0] INTEGER、チェックサム[1]OCTET STRING
cksumtype This field indicates the algorithm used to generate the
accompanying checksum.
cksumtype This分野は、アルゴリズムが以前は付随のチェックサムをよく発生させていたのを示します。
checksum This field contains the checksum itself, encoded
as an octet string.
八重奏ストリングとしてコード化されて、Thisがさばくチェックサムはチェックサム自体を含んでいます。
Detailed specification of selected checksum types appear later in this section. Negative values for the checksum type are reserved for local use. All non-negative values are reserved for officially assigned type fields and interpretations.
タイプが後でこのセクションで見える選択されたチェックサムの仕様詳細。 チェックサムタイプのための負の数は地方の使用のために予約されます。 すべての非負の数が公式に割り当てられたタイプ分野と解釈のために予約されます。
Checksums used by Kerberos can be classified by two properties: whether they are collision-proof, and whether they are keyed. It is infeasible to find two plaintexts which generate the same checksum value for a collision-proof checksum. A key is required to perturb or initialize the algorithm in a keyed checksum. To prevent message-stream modification by an active attacker, unkeyed checksums should only be used when the checksum and message will be subsequently encrypted (e.g., the checksums defined as part of the encryption algorithms covered earlier in this section). Collision- proof checksums can be made tamper-proof as well if the checksum value is encrypted before inclusion in a message. In such cases, the composition of the checksum and the encryption algorithm must be considered a separate checksum algorithm (e.g., RSA-MD5 encrypted using DES is a new checksum algorithm of type RSA-MD5-DES). For most keyed checksums, as well as for the encrypted forms of collisionproof checksums, Kerberos prepends a confounder before the checksum is calculated.
2つの特性でケルベロスで使用されるチェックサムは分類できます: 耐であるかどうかと、それら衝突のそれらは合わせられるのであるかどうか 耐衝突のチェックサムのために同じチェックサム値を発生させる2つの平文を見つけるのは実行不可能です。 キーが、合わせられたチェックサムにおけるアルゴリズムを混乱させるか、または初期化するのに必要です。 チェックサムとメッセージが次にコード化されるときだけ(例えばより早くこのセクションでカバーされた暗号化アルゴリズムの一部と定義されたチェックサム)、活発な攻撃者によるメッセージストリーム変更を防ぐために、「非-合わせ」られたチェックサムは使用されるべきです。 メッセージでの包含の前にチェックサム値をコード化するなら衝突証拠チェックサムをまた、干渉防止するようにすることができます。 そのような場合、別々のチェックサムアルゴリズムであるとチェックサムの構成と暗号化アルゴリズムを考えなければなりません(例えばDESを使用することでコード化されたRSA-MD5はタイプRSA-MD5-DESの新しいチェックサムアルゴリズムです)。 ほとんどの合わせられたチェックサムにおいて、チェックサムの前の同じくらい良いコード化されたフォームのcollisionproofチェックサム、ケルベロスprependsのように交絡因子は計算されます。
6.4.1. The CRC-32 Checksum (crc32)
6.4.1. CRC-32チェックサム(crc32)
The CRC-32 checksum calculates a checksum based on a cyclic redundancy check as described in ISO 3309 [14]. The resulting checksum is four (4) octets in length. The CRC-32 is neither keyed nor collision-proof. The use of this checksum is not recommended. An attacker using a probabilistic chosen-plaintext attack as described in [13] might be able to generate an alternative message that satisfies the checksum. The use of collision-proof checksums is recommended for environments where such attacks represent a
CRC-32チェックサムはISO3309[14]で説明されるように周期冗長検査に基づくチェックサムについて計算します。 結果として起こるチェックサムは長さが4(4)八重奏です。 合わせられないでまた耐はありませんCRC-32衝突の。 このチェックサムの使用は推薦されません。 [13]で説明されるように確率的な選ばれた平文攻撃を使用している攻撃者はチェックサムを満たす代替のメッセージを発生させることができるかもしれません。 耐衝突のチェックサムの使用はそのような攻撃がaを表す環境のために推薦されます。
Kohl & Neuman [Page 74] RFC 1510 Kerberos September 1993
コールとヌーマン[74ページ]のRFCの1510のケルベロスの1993年9月
significant threat.
多大なる脅威。
6.4.2. The RSA MD4 Checksum (rsa-md4)
6.4.2. RSA MD4チェックサム(rsa-md4)
The RSA-MD4 checksum calculates a checksum using the RSA MD4 algorithm [15]. The algorithm takes as input an input message of arbitrary length and produces as output a 128-bit (16 octet) checksum. RSA-MD4 is believed to be collision-proof.
RSA-MD4チェックサムは、RSA MD4アルゴリズム[15]を使用することでチェックサムについて計算します。 アルゴリズムは、任意の長さに関する入力メッセージを入力するとき取って、128ビット(16八重奏)のチェックサムを出力するとき、作成されます。 RSA-MD4が衝突耐であると信じられています。
6.4.3. RSA MD4 Cryptographic Checksum Using DES (rsa-md4des)
6.4.3. DESを使用するRSA MD4の暗号のチェックサム(rsa-md4des)
The RSA-MD4-DES checksum calculates a keyed collisionproof checksum by prepending an 8 octet confounder before the text, applying the RSA MD4 checksum algorithm, and encrypting the confounder and the checksum using DES in cipher-block-chaining (CBC) mode using a variant of the key, where the variant is computed by eXclusive-ORing the key with the constant F0F0F0F0F0F0F0F0 (A variant of the key is used to limit the use of a key to a particular function, separating the functions of generating a checksum from other encryption performed using the session key. The constant F0F0F0F0F0F0F0F0 was chosen because it maintains key parity. The properties of DES precluded the use of the complement. The same constant is used for similar purpose in the Message Integrity Check in the Privacy Enhanced Mail standard.). The initialization vector should be zero. The resulting checksum is 24 octets long (8 octets of which are redundant). This checksum is tamper-proof and believed to be collision-proof.
RSA MD4チェックサムアルゴリズムを適用して、異形がeXclusive-ORingによって計算されるキーの異形を使用しながら暗号ブロック連鎖(CBC)モードでDESを使用することで交絡因子とチェックサムをコード化して、RSA-MD4-DESチェックサムがテキストの前に8八重奏交絡因子をprependingする合わせられたcollisionproofチェックサムについて計算する、一定のF0F0F0F0F0F0F0F0があるキー(キーの異形はキーの使用を特定の機能に制限するのに使用されます、セッションキーを使用することで実行された他の暗号化からチェックサムを発生させる機能を切り離して。 主要な同等を維持するので、一定のF0F0F0F0F0F0F0F0は選ばれました。 DESの特性は補数の使用を排除しました。 同じ定数はPrivacy Enhancedメール規格におけるMessage Integrity Checkの同様の目的に使用されます。). 初期化ベクトルはゼロであるべきです。 長い間(それの8つの八重奏が余分である)、結果として起こるチェックサムは24の八重奏です。 このチェックサムは、干渉防止していて、衝突耐であると信じられています。
The DES specifications identify some "weak keys"; those keys shall not be used for generating RSA-MD4 checksums for use in Kerberos.
DES仕様はいくつかの「弱いキー」を特定します。 ケルベロスにおける使用のためにRSA-MD4チェックサムを発生させるのにそれらのキーを使用しないものとします。
The format for the checksum is described in the following diagram:
チェックサムのための形式は以下のダイヤグラムで説明されます:
+--+--+--+--+--+--+--+--
| des-cbc(confounder
+--+--+--+--+--+--+--+--
+--+--+--+--+--+--+--+-- | des-cbc、(交絡因子+--+--+--+--+--+--+(+)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
rsa-md4(confounder+msg),key=var(key),iv=0) |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ rsa-md4(交絡因子+msg)、主要な=var(主要な)、iv=0) | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The format cannot be described in ASN.1, but for those who prefer an ASN.1-like notation:
形式は、ASN.1で説明されるのではなく、ASNの.1のような記法を好む人のために説明できます:
rsa-md4-des-checksum ::= ENCRYPTED UNTAGGED SEQUENCE {
confounder[0] UNTAGGED OCTET STRING(8),
check[1] UNTAGGED OCTET STRING(16)
}
rsa-md4-des-チェックサム:、:= コード化されたUNTAGGED系列交絡因子[0]UNTAGGED OCTET STRING(8)、チェック[1]UNTAGGED OCTET STRING(16)
Kohl & Neuman [Page 75] RFC 1510 Kerberos September 1993
コールとヌーマン[75ページ]のRFCの1510のケルベロスの1993年9月
6.4.4. The RSA MD5 Checksum (rsa-md5)
6.4.4. RSA MD5チェックサム(rsa-md5)
The RSA-MD5 checksum calculates a checksum using the RSA MD5 algorithm [16]. The algorithm takes as input an input message of arbitrary length and produces as output a 128-bit (16 octet) checksum. RSA-MD5 is believed to be collision-proof.
RSA-MD5チェックサムは、RSA MD5アルゴリズム[16]を使用することでチェックサムについて計算します。 アルゴリズムは、任意の長さに関する入力メッセージを入力するとき取って、128ビット(16八重奏)のチェックサムを出力するとき、作成されます。 RSA-MD5が衝突耐であると信じられています。
6.4.5. RSA MD5 Cryptographic Checksum Using DES (rsa-md5des)
6.4.5. DESを使用するRSA MD5の暗号のチェックサム(rsa-md5des)
The RSA-MD5-DES checksum calculates a keyed collisionproof checksum by prepending an 8 octet confounder before the text, applying the RSA MD5 checksum algorithm, and encrypting the confounder and the checksum using DES in cipher-block-chaining (CBC) mode using a variant of the key, where the variant is computed by eXclusive-ORing the key with the constant F0F0F0F0F0F0F0F0. The initialization vector should be zero. The resulting checksum is 24 octets long (8 octets of which are redundant). This checksum is tamper-proof and believed to be collision-proof.
RSA-MD5-DESチェックサムは、RSA MD5チェックサムアルゴリズムを適用して、テキストの前に8八重奏交絡因子をprependingすることによって合わせられたcollisionproofチェックサムについて計算して、eXclusive-ORingで異形が計算されるキーの異形を使用しながら暗号ブロック連鎖(CBC)モードでDESを使用することで交絡因子とチェックサムをコード化するのと計算します。一定のF0F0F0F0F0F0F0F0があるキー。 初期化ベクトルはゼロであるべきです。 長い間(それの8つの八重奏が余分である)、結果として起こるチェックサムは24の八重奏です。 このチェックサムは、干渉防止していて、衝突耐であると信じられています。
The DES specifications identify some "weak keys"; those keys shall not be used for encrypting RSA-MD5 checksums for use in Kerberos.
DES仕様はいくつかの「弱いキー」を特定します。 ケルベロスにおける使用のためにRSA-MD5チェックサムをコード化するのにそれらのキーを使用しないものとします。
The format for the checksum is described in the following diagram:
チェックサムのための形式は以下のダイヤグラムで説明されます:
+--+--+--+--+--+--+--+--
| des-cbc(confounder
+--+--+--+--+--+--+--+--
+--+--+--+--+--+--+--+-- | des-cbc、(交絡因子+--+--+--+--+--+--+(+)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
rsa-md5(confounder+msg),key=var(key),iv=0) |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ rsa-md5(交絡因子+msg)、主要な=var(主要な)、iv=0) | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The format cannot be described in ASN.1, but for those who prefer an ASN.1-like notation:
形式は、ASN.1で説明されるのではなく、ASNの.1のような記法を好む人のために説明できます:
rsa-md5-des-checksum ::= ENCRYPTED UNTAGGED SEQUENCE {
confounder[0] UNTAGGED OCTET STRING(8),
check[1] UNTAGGED OCTET STRING(16)
}
rsa-md5-des-チェックサム:、:= コード化されたUNTAGGED系列交絡因子[0]UNTAGGED OCTET STRING(8)、チェック[1]UNTAGGED OCTET STRING(16)
6.4.6. DES cipher-block chained checksum (des-mac)
6.4.6. DES暗号ブロックはチェックサムをチェーニングしました。(des-mac)
The DES-MAC checksum is computed by prepending an 8 octet confounder to the plaintext, performing a DES CBC-mode encryption on the result using the key and an initialization vector of zero, taking the last block of the ciphertext, prepending the same confounder and encrypting the pair using DES in cipher-block-chaining (CBC) mode using a a variant of the key, where the variant is computed by
DES-MACチェックサムは8八重奏交絡因子を平文にprependingすることによって、計算されます、ゼロのキーと初期化ベクトルを使用することでDES CBC-モード暗号化を結果に実行して、暗号文の最後のブロックを取って、異形が計算されるキーのa異形を使用しながら暗号ブロック連鎖(CBC)モードでDESを使用することで同じ交絡因子をprependingして、組をコード化して
Kohl & Neuman [Page 76] RFC 1510 Kerberos September 1993
コールとヌーマン[76ページ]のRFCの1510のケルベロスの1993年9月
eXclusive-ORing the key with the constant F0F0F0F0F0F0F0F0. The initialization vector should be zero. The resulting checksum is 128 bits (16 octets) long, 64 bits of which are redundant. This checksum is tamper-proof and collision-proof.
eXclusive-ORing、一定のF0F0F0F0F0F0F0F0があるキー。 初期化ベクトルはゼロであるべきです。 結果として起こるチェックサムは長さ64ビットにどれが余分であるかの128ビット(16の八重奏)です。 干渉防止するのと耐ですこのチェックサム衝突の。
The format for the checksum is described in the following diagram:
チェックサムのための形式は以下のダイヤグラムで説明されます:
+--+--+--+--+--+--+--+--
| des-cbc(confounder
+--+--+--+--+--+--+--+--
+--+--+--+--+--+--+--+-- | des-cbc、(交絡因子+--+--+--+--+--+--+(+)
+-----+-----+-----+-----+-----+-----+-----+-----+
des-mac(conf+msg,iv=0,key),key=var(key),iv=0) |
+-----+-----+-----+-----+-----+-----+-----+-----+
+-----+-----+-----+-----+-----+-----+-----+-----+ des-mac(conf+msg、ivは0と主要な状態で等しい)、主要な=var(主要な)、iv=0) | +-----+-----+-----+-----+-----+-----+-----+-----+
The format cannot be described in ASN.1, but for those who prefer an ASN.1-like notation:
形式は、ASN.1で説明されるのではなく、ASNの.1のような記法を好む人のために説明できます:
des-mac-checksum ::= ENCRYPTED UNTAGGED SEQUENCE {
confounder[0] UNTAGGED OCTET STRING(8),
check[1] UNTAGGED OCTET STRING(8)
}
des-mac-チェックサム:、:= コード化されたUNTAGGED系列交絡因子[0]UNTAGGED OCTET STRING(8)、チェック[1]UNTAGGED OCTET STRING(8)
The DES specifications identify some "weak" and "semiweak" keys; those keys shall not be used for generating DES-MAC checksums for use in Kerberos, nor shall a key be used whose veriant is "weak" or "semi-weak".
DES仕様はいくつかの「弱い」と"semiweak"キーを特定します。 ケルベロスにおける使用のためにDES-MACチェックサムを発生させるのにそれらのキーを使用しないものとして、またキーによる使用されて、だれのveriantが「弱い」か「準弱いか」ということでないものとします。
6.4.7. RSA MD4 Cryptographic Checksum Using DES alternative
(rsa-md4-des-k)
6.4.7. RSA MD4 Cryptographic Checksum Using DES代替手段(rsa-md4-des-k)
The RSA-MD4-DES-K checksum calculates a keyed collision-proof checksum by applying the RSA MD4 checksum algorithm and encrypting the results using DES in cipherblock-chaining (CBC) mode using a DES key as both key and initialization vector. The resulting checksum is 16 octets long. This checksum is tamper-proof and believed to be collision-proof. Note that this checksum type is the old method for encoding the RSA-MD4-DES checksum and it is no longer recommended.
RSA-MD4-DES-Kチェックサムは、ともに主要であるとして主要なDESと初期化ベクトルを使用しながらcipherblock-推論(CBC)モードでDESを使用することでRSA MD4チェックサムアルゴリズムを適用して、結果をコード化することによって、耐衝突の合わせられたチェックサムについて計算します。 長い間、結果として起こるチェックサムは16の八重奏です。 このチェックサムは、干渉防止していて、衝突耐であると信じられています。 このチェックサムタイプがRSA-MD4-DESチェックサムをコード化するための古い方法であり、それがもうお勧めでないことに注意してください。
6.4.8. DES cipher-block chained checksum alternative (desmac-k)
6.4.8. DES暗号ブロックはチェックサム代替手段をチェーニングしました。(desmac-k)
The DES-MAC-K checksum is computed by performing a DES CBC-mode encryption of the plaintext, and using the last block of the ciphertext as the checksum value. It is keyed with an encryption key and an initialization vector; any uses which do not specify an additional initialization vector will use the key as both key and initialization vector. The resulting checksum is 64 bits (8 octets) long. This checksum is tamper-proof and collision-proof. Note that
DES-MAC-Kチェックサムは、平文のDES CBC-モード暗号化を実行して、チェックサム値として暗号文の最後のブロックを使用することによって、計算されます。 それは暗号化キーと初期化ベクトルで合わせられます。 追加初期化ベクトルを指定しないどんな用途もキーと初期化ベクトルの両方としてキーを使用するでしょう。 結果として起こるチェックサムは長さ64ビットです(8つの八重奏)。 干渉防止するのと耐ですこのチェックサム衝突の。 それに注意してください。
Kohl & Neuman [Page 77] RFC 1510 Kerberos September 1993
コールとヌーマン[77ページ]のRFCの1510のケルベロスの1993年9月
this checksum type is the old method for encoding the DESMAC checksum and it is no longer recommended.
このチェックサムタイプはDESMACチェックサムをコード化するための古い方法です、そして、それはもうお勧めではありません。
The DES specifications identify some "weak keys"; those keys shall not be used for generating DES-MAC checksums for use in Kerberos.
DES仕様はいくつかの「弱いキー」を特定します。 ケルベロスにおける使用のためにDES-MACチェックサムを発生させるのにそれらのキーを使用しないものとします。
7. Naming Constraints
7. 規制を命名します。
7.1. Realm Names
7.1. 分野名
Although realm names are encoded as GeneralStrings and although a realm can technically select any name it chooses, interoperability across realm boundaries requires agreement on how realm names are to be assigned, and what information they imply.
分野名はGeneralStringsとしてコード化されます、そして、分野はそれが選ぶどんな名前も技術的に選択できますが、分野境界の向こう側の相互運用性は分野名がどのように割り当てられるかことであり、彼らがどんな情報を含意するかに関する協定を必要とします。
To enforce these conventions, each realm must conform to the conventions itself, and it must require that any realms with which inter-realm keys are shared also conform to the conventions and require the same from its neighbors.
これらのコンベンションを実施するために、各分野がそれ自体でコンベンションに従わなければならなくて、それは、また、相互分野キーが共有されるどんな分野もコンベンションに従うのが必要であり、隣人から同じくらい必要としなければなりません。
There are presently four styles of realm names: domain, X500, other, and reserved. Examples of each style follow:
現在、4つのスタイルの分野名があります: ドメイン、他の、そして、予約されたX500。 それぞれのスタイルに関する例は従います:
domain: host.subdomain.domain (example)
X500: C=US/O=OSF (example)
other: NAMETYPE:rest/of.name=without-restrictions (example)
reserved: reserved, but will not conflict with above
ドメイン: host.subdomain.domain(例)X500: C=米国/O=OSF(例)他: NAMETYPE: 制限(例)のない=が予約した休息/of.name: 上で衝突しないのを除いて、予約されます。
Domain names must look like domain names: they consist of components separated by periods (.) and they contain neither colons (:) nor slashes (/).
ドメイン名はドメイン名に似なければなりません: 周期的に切り離されているコンポーネントから成る、()、どちらのコロンも含んでいない、(:、)、または、スラッシュ(/)。
X.500 names contain an equal (=) and cannot contain a colon (:) before the equal. The realm names for X.500 names will be string representations of the names with components separated by slashes. Leading and trailing slashes will not be included.
X.500名が同輩(=)を含んで、コロンは含むことができない、(:、)、同輩の前で。 X.500名のための分野名はスラッシュによって切り離されるコンポーネントの名前のストリング表現になるでしょう。 主で引きずっているスラッシュは含まれないでしょう。
Names that fall into the other category must begin with a prefix that contains no equal (=) or period (.) and the prefix must be followed by a colon (:) and the rest of the name. All prefixes must be assigned before they may be used. Presently none are assigned.
もう片方のカテゴリになる名前が同輩(=)か期間を全く含まない接頭語で始まらなければならない、()、コロンが接頭語のあとに続かなければならない、(:、)、そして、名前の残り。 それらが使用されるかもしれない前にすべての接頭語を割り当てなければなりません。 現在の、なにも割り当てられません。
The reserved category includes strings which do not fall into the first three categories. All names in this category are reserved. It is unlikely that names will be assigned to this category unless there is a very strong argument for not using the "other" category.
予約されたカテゴリは最初の3つのカテゴリにならないストリングを含んでいます。 このカテゴリにおけるすべての名前が予約されています。 「他」のカテゴリを使用しないための非常に強い議論がない場合名前がこのカテゴリに割り当てられるのは、ありそうもないです。
These rules guarantee that there will be no conflicts between the
これらの規則は、闘争が全く間にないのを保証します。
Kohl & Neuman [Page 78] RFC 1510 Kerberos September 1993
コールとヌーマン[78ページ]のRFCの1510のケルベロスの1993年9月
various name styles. The following additional constraints apply to the assignment of realm names in the domain and X.500 categories: the name of a realm for the domain or X.500 formats must either be used by the organization owning (to whom it was assigned) an Internet domain name or X.500 name, or in the case that no such names are registered, authority to use a realm name may be derived from the authority of the parent realm. For example, if there is no domain name for E40.MIT.EDU, then the administrator of the MIT.EDU realm can authorize the creation of a realm with that name.
様々な名前スタイル。 以下の追加規制はドメインとX.500カテゴリにおける、分野名の課題に適用されます: インターネットドメイン名かX.500名を所有している(だれがそれを割り当てられたかに)組織がドメインかX.500形式のための分野の名前を使用しなければならない、そのようなどんな名前も登録されていなくて、さもなければ、親分野の権威から分野名を使用する権威を得るかもしれません。 例えば、E40.MIT.EDUのためのドメイン名が全くなければ、MIT.EDU分野の管理者はその名前で分野の創設を認可できます。
This is acceptable because the organization to which the parent is assigned is presumably the organization authorized to assign names to its children in the X.500 and domain name systems as well. If the parent assigns a realm name without also registering it in the domain name or X.500 hierarchy, it is the parent's responsibility to make sure that there will not in the future exists a name identical to the realm name of the child unless it is assigned to the same entity as the realm name.
親が配属される組織がおそらくX.500の子供に名前を割り当てるのが認可された組織とまた、ドメイン名システムであるので、これは許容できます。 親がまた、ドメイン名かX.500階層構造でそれを登録することのない分野名を割り当てて、分野名と同じ実体に割り当てられない場合、それはそこでは、意志が将来a名の同じ状態で存在しないのを子供の分野名に確実にする親の責任です。
7.2. Principal Names
7.2. 主要な名前
As was the case for realm names, conventions are needed to ensure that all agree on what information is implied by a principal name. The name-type field that is part of the principal name indicates the kind of information implied by the name. The name-type should be treated as a hint. Ignoring the name type, no two names can be the same (i.e., at least one of the components, or the realm, must be different). This constraint may be eliminated in the future. The following name types are defined:
分野名のためのケースのように、コンベンションが、すべてが、どんな情報が主要な名前で含意されるかに同意するのを保証するのが必要です。 主要な名前の一部である名前タイプ分野は名前によって含意された情報の種類を示します。 名前タイプはヒントとして扱われるべきです。 どんな2歳のタイプも挙げない名前を無視するのは同じである場合があります(すなわち、少なくともコンポーネント、または分野の1つは異なっているに違いありません)。 この規制は将来、取り除かれるかもしれません。 以下の名前タイプは定義されます:
name-type value meaning
NT-UNKNOWN 0 Name type not known
NT-PRINCIPAL 1 Just the name of the principal as in
DCE, or for users
NT-SRV-INST 2 Service and other unique instance (krbtgt)
NT-SRV-HST 3 Service with host name as instance
(telnet, rcommands)
NT-SRV-XHST 4 Service with host as remaining components
NT-UID 5 Unique ID
NT-プリンシパル1知られているJustではなく、NT-UNKNOWN0NameタイプのためにDCEのように主体の名前を意味しながら、値を名前でタイプしてください。さもないと、ユーザにちなんで、ホストがいるNT-SRV-INST2Serviceと他のユニークなインスタンス(krbtgt)NT-SRV-HST3Serviceはインスタンス(telnet、rcommands)NT-SRV-XHSTとしてコンポーネントのままで残っているとしてのホストがいる4ServiceをNT-UID5Unique IDと命名します。
When a name implies no information other than its uniqueness at a particular time the name type PRINCIPAL should be used. The principal name type should be used for users, and it might also be used for a unique server. If the name is a unique machine generated ID that is guaranteed never to be reassigned then the name type of UID should be used (note that it is generally a bad idea to reassign names of any type since stale entries might remain in access control lists).
名前が特定の時間のユニークさ以外の情報を全く含意しないとき、名前タイププリンシパルは使用されるべきです。 タイプという主要な名前はユーザに使用されるべきです、そして、また、それはユニークなサーバに使用されるかもしれません。名前が保証される、決して再選任されないIDであると生成されたユニークなマシンであるなら、UIDというタイプという名前は使用されるべきです(聞き古したエントリーがアクセスコントロールリストに残るかもしれないので、一般に、どんなタイプの名前も再選任するのが、悪い考えであることに注意してください)。
Kohl & Neuman [Page 79] RFC 1510 Kerberos September 1993
コールとヌーマン[79ページ]のRFCの1510のケルベロスの1993年9月
If the first component of a name identifies a service and the remaining components identify an instance of the service in a server specified manner, then the name type of SRV-INST should be used. An example of this name type is the Kerberos ticket-granting ticket which has a first component of krbtgt and a second component identifying the realm for which the ticket is valid.
名前の最初の成分がサービスを特定して、残っているコンポーネントがサーバの指定された方法でサービスのインスタンスを特定するなら、SRV-INSTというタイプという名前は使用されるべきです。 この名前タイプに関する例は、krbtgtの最初の部品を持っているチケットを与えるケルベロスチケットと分野を特定するチケットが有効である2番目のコンポーネントです。
If instance is a single component following the service name and the instance identifies the host on which the server is running, then the name type SRV-HST should be used. This type is typically used for Internet services such as telnet and the Berkeley R commands. If the separate components of the host name appear as successive components following the name of the service, then the name type SRVXHST should be used. This type might be used to identify servers on hosts with X.500 names where the slash (/) might otherwise be ambiguous.
インスタンスがサービス名に従うただ一つのコンポーネントであり、インスタンスがサーバが稼働しているホストを特定するなら、タイプという名前SRV-HSTは使用されるべきです。 このタイプはtelnetやバークレーRコマンドなどのインターネットのサービスに通常使用されます。 サービスの名前に従って、ホスト名の別々の成分が連続したコンポーネントとして現れるなら、タイプという名前SRVXHSTは使用されるべきです。 このタイプは、そうでなければスラッシュ(/)があいまいであるかもしれないX.500名とホストの上のサーバを同一視するのに使用されるかもしれません。
A name type of UNKNOWN should be used when the form of the name is not known. When comparing names, a name of type UNKNOWN will match principals authenticated with names of any type. A principal authenticated with a name of type UNKNOWN, however, will only match other names of type UNKNOWN.
名前の書式が知られていないとき、UNKNOWNの名前タイプは使用されるべきです。 名前を比較するとき、タイプUNKNOWNという名前はどんなタイプの名前でも認証された主体に合うでしょう。 しかしながら、タイプUNKNOWNという名前で認証された元本はタイプUNKNOWNという他の名前に合うだけでしょう。
Names of any type with an initial component of "krbtgt" are reserved for the Kerberos ticket granting service. See section 8.2.3 for the form of such names.
"krbtgt"の初期のコンポーネントがあるどんなタイプの名前もサービスを承諾するケルベロスチケットのために予約されます。 そのような名前のフォームに関してセクション8.2.3を見てください。
7.2.1. Name of server principals
7.2.1. サーバ主体の名前
The principal identifier for a server on a host will generally be composed of two parts: (1) the realm of the KDC with which the server is registered, and (2) a two-component name of type NT-SRV-HST if the host name is an Internet domain name or a multi-component name of type NT-SRV-XHST if the name of the host is of a form such as X.500 that allows slash (/) separators. The first component of the two- or multi-component name will identify the service and the latter components will identify the host. Where the name of the host is not case sensitive (for example, with Internet domain names) the name of the host must be lower case. For services such as telnet and the Berkeley R commands which run with system privileges, the first component will be the string "host" instead of a service specific identifier.
一般に、ホストの上のサーバのための主要な識別子は2つの部品で構成されるでしょう: (1) ホストの名前がスラッシュ(/)に分離符を許容するX.500などのフォームのものであるなら、ホスト名であるならサーバが登録されるのと(2)のa2コンポーネントの名(タイプNT-SRV-HST)であるKDCの分野は、インターネットドメイン名かタイプNT-SRV-XHSTという多成分系の名前です。 2か多成分系の名前の最初の成分はサービスを特定するでしょう、そして、後者のコンポーネントはホストを特定するでしょう。 ホストの名前が大文字と小文字を区別していないところでは(例えばインターネットドメイン名で)、ホストの名前は小文字であるに違いありません。 telnetやシステム特権と共に稼働するバークレーRコマンドなどのサービスのために、最初のコンポーネントはサービスの特定の識別子の代わりにストリング」になるでしょう「ホスト。
8. Constants and other defined values
8. 定数と他の定義された値
8.1. Host address types
8.1. ホスト・アドレスタイプ
All negative values for the host address type are reserved for local use. All non-negative values are reserved for officially assigned
ホスト・アドレスタイプのためのすべての負の数が地方の使用のために予約されます。 割り当てられて、非負の数が公式に予約されるすべて
Kohl & Neuman [Page 80] RFC 1510 Kerberos September 1993
コールとヌーマン[80ページ]のRFCの1510のケルベロスの1993年9月
type fields and interpretations.
分野と解釈をタイプしてください。
The values of the types for the following addresses are chosen to match the defined address family constants in the Berkeley Standard Distributions of Unix. They can be found in <sys/socket.h> with symbolic names AF_xxx (where xxx is an abbreviation of the address family name).
以下のアドレスが定義に合うように選ばれているので、タイプの値はUnixのバークレーStandard Distributionsでファミリーに定数を扱います。 <sys/socket.h>で英字名AF_xxx(xxxがアドレス姓の略語であるところ)でそれらを見つけることができます。
Internet addresses
インターネット・アドレス
Internet addresses are 32-bit (4-octet) quantities, encoded in MSB
order. The type of internet addresses is two (2).
インターネット・アドレスはMSBオーダーでコード化された(4八重奏)の32ビットの量です。 インターネットアドレスのタイプは2(2)です。
CHAOSnet addresses
CHAOSnetアドレス
CHAOSnet addresses are 16-bit (2-octet) quantities, encoded in MSB
order. The type of CHAOSnet addresses is five (5).
CHAOSnetアドレスはMSBオーダーでコード化された(2八重奏)の16ビットの量です。 CHAOSnetアドレスのタイプは5(5)です。
ISO addresses
ISOアドレス
ISO addresses are variable-length. The type of ISO addresses is
seven (7).
ISOアドレスは可変長です。 ISOアドレスのタイプは7(7)です。
Xerox Network Services (XNS) addresses
ゼロックスNetwork Services(XNS)アドレス
XNS addresses are 48-bit (6-octet) quantities, encoded in MSB
order. The type of XNS addresses is six (6).
XNSアドレスはMSBオーダーでコード化された(6八重奏)の48ビットの量です。 XNSアドレスのタイプは6(6)です。
AppleTalk Datagram Delivery Protocol (DDP) addresses
AppleTalkデータグラムDeliveryプロトコル(DDP)アドレス
AppleTalk DDP addresses consist of an 8-bit node number and a 16-
bit network number. The first octet of the address is the node
number; the remaining two octets encode the network number in MSB
order. The type of AppleTalk DDP addresses is sixteen (16).
AppleTalk DDPアドレスは8ビットのノード番号と16の噛み付いているネットワーク・ナンバーから成ります。 アドレスの最初の八重奏はノード番号です。 残っている2つの八重奏がMSBオーダーにおけるネットワーク・ナンバーをコード化します。 AppleTalk DDPアドレスのタイプは16(16)です。
DECnet Phase IV addresses
DECnet Phase IVアドレス
DECnet Phase IV addresses are 16-bit addresses, encoded in LSB
order. The type of DECnet Phase IV addresses is twelve (12).
DECnet Phase IVアドレスはLSBオーダーでコード化された16ビットのアドレスです。 DECnet Phase IVアドレスのタイプは12(12)です。
8.2. KDC messages
8.2. KDCメッセージ
8.2.1. IP transport
8.2.1. IP輸送
When contacting a Kerberos server (KDC) for a KRB_KDC_REQ request using IP transport, the client shall send a UDP datagram containing only an encoding of the request to port 88 (decimal) at the KDC's IP
IP輸送を使用することでREQが要求するKRB_KDC_のために、ケルベロスサーバ(KDC)に連絡するとき、クライアントはKDCのIPで88(10進)を移植するという要求のコード化だけを含むUDPデータグラムを送るものとします。
Kohl & Neuman [Page 81] RFC 1510 Kerberos September 1993
コールとヌーマン[81ページ]のRFCの1510のケルベロスの1993年9月
address; the KDC will respond with a reply datagram containing only an encoding of the reply message (either a KRB_ERROR or a KRB_KDC_REP) to the sending port at the sender's IP address.
アドレス。 応答データグラムが応答メッセージ(KRB_ERRORかKRB_KDC_REPのどちらか)のコード化だけを送付者のIP住所の送付ポートに含んでいて、KDCは応じるでしょう。
8.2.2. OSI transport
8.2.2. OSI輸送
During authentication of an OSI client to and OSI server, the mutual authentication of an OSI server to an OSI client, the transfer of credentials from an OSI client to an OSI server, or during exchange of private or integrity checked messages, Kerberos protocol messages may be treated as opaque objects and the type of the authentication mechanism will be:
そして、OSIクライアントの認証、OSIサーバ、OSIクライアントへのOSIサーバの互いの認証、OSIクライアントからOSIサーバまで個人的であるか保全チェックのメッセージの交換間の資格証明書の転送、ケルベロスプロトコルメッセージは不透明なオブジェクトとして扱われるかもしれなくて、認証機構のタイプは以下の通りになるでしょう。
OBJECT IDENTIFIER ::= {iso (1), org(3), dod(5),internet(1),
security(5), kerberosv5(2)}
オブジェクト識別子:、:= iso(1)、org(3)、dod(5)、インターネット(1)、セキュリティ(5)、kerberosv5(2)
Depending on the situation, the opaque object will be an authentication header (KRB_AP_REQ), an authentication reply (KRB_AP_REP), a safe message (KRB_SAFE), a private message (KRB_PRIV), or a credentials message (KRB_CRED). The opaque data contains an application code as specified in the ASN.1 description for each message. The application code may be used by Kerberos to determine the message type.
状況によって、不透明なオブジェクトは、認証ヘッダー(KRB_AP_REQ)、認証回答(KRB_AP_REP)、または安全なメッセージ(KRB_SAFE)か、プライベート・メッセージ(KRB_PRIV)か、資格証明書メッセージになるでしょう(KRB_CRED)。 不明瞭なデータは各メッセージのためのASN.1記述における指定されるとしての応用コードを含んでいます。 応用コードは、メッセージタイプを決定するのにケルベロスで使用されるかもしれません。
8.2.3. Name of the TGS
8.2.3. TGSという名前
The principal identifier of the ticket-granting service shall be
composed of three parts: (1) the realm of the KDC issuing the TGS
ticket (2) a two-part name of type NT-SRVINST, with the first part
"krbtgt" and the second part the name of the realm which will accept
the ticket-granting ticket. For example, a ticket-granting ticket
issued by the ATHENA.MIT.EDU realm to be used to get tickets from the
ATHENA.MIT.EDU KDC has a principal identifier of "ATHENA.MIT.EDU"
(realm), ("krbtgt", "ATHENA.MIT.EDU") (name). A ticket-granting
ticket issued by the ATHENA.MIT.EDU realm to be used to get tickets
from the MIT.EDU realm has a principal identifier of "ATHENA.MIT.EDU"
(realm), ("krbtgt", "MIT.EDU") (name).
チケットを与えるサービスの主要な識別子は3つの部品で構成されるものとします: (1) 最初の部分"krbtgt"があるタイプNT-SRVINSTという2部分の名前をTGSチケット(2)に発行して、チケットを与えるチケットを受け入れる分野の名前を第二部に発行するKDCの分野。 例えば、ATHENA.MIT.EDU KDCからチケットを手に入れるのに使用されるためにATHENA.MIT.EDU分野によって発行されたチケットを与えるチケットは"ATHENA.MIT.EDU"(分野)、("krbtgt"、"ATHENA.MIT.EDU")(命名する)の主要な識別子を持っています。 MIT.EDU分野からチケットを手に入れるのに使用されるためにATHENA.MIT.EDU分野によって発行されたチケットを与えるチケットは"ATHENA.MIT.EDU"(分野)、("krbtgt"、"MIT.EDU")(命名する)の主要な識別子を持っています。
8.3. Protocol constants and associated values
8.3. プロトコル定数と関連値
The following tables list constants used in the protocol and defines their meanings.
以下は、プロトコルに使用されるリスト定数を見送って、それらの意味を定義します。
Kohl & Neuman [Page 82] RFC 1510 Kerberos September 1993
コールとヌーマン[82ページ]のRFCの1510のケルベロスの1993年9月
---------------+-----------+----------+----------------+--------------- Encryption type|etype value|block size|minimum pad size|confounder size ---------------+-----------+----------+----------------+--------------- NULL 0 1 0 0 des-cbc-crc 1 8 4 8 des-cbc-md4 2 8 0 8 des-cbc-md5 3 8 0 8
---------------+-----------+----------+----------------+--------------- 暗号化タイプ|etype値|ブロック・サイズ|最小のパッドサイズ|交絡因子サイズ---------------+-----------+----------+----------------+--------------- NULL0 1 0 0des-cbc-crc1 8 4 8des-cbc-md4 2 8 0 8 des-cbc-md5 3 8 0 8
-------------------------------+-------------------+------------- Checksum type |sumtype value |checksum size -------------------------------+-------------------+------------- CRC32 1 4 rsa-md4 2 16 rsa-md4-des 3 24 des-mac 4 16 des-mac-k 5 8 rsa-md4-des-k 6 16 rsa-md5 7 16 rsa-md5-des 8 24
-------------------------------+-------------------+------------- チェックサムタイプ|sumtype値|チェックサムサイズ-------------------------------+-------------------+------------- CRC32 1 4rsa-md4 2 16rsa-md4-des3 24des-mac4 16des-mac-k5 8rsa-md4-des-k6 16rsa-md5 7 16rsa-md5-des8 24
-------------------------------+----------------- padata type |padata-type value -------------------------------+----------------- PA-TGS-REQ 1 PA-ENC-TIMESTAMP 2 PA-PW-SALT 3
-------------------------------+----------------- padataタイプ|padata-タイプ値-------------------------------+----------------- 1PA-TGS-REQ PA ENCタイムスタンプ2PA PW塩の3
-------------------------------+------------- authorization data type |ad-type value -------------------------------+------------- reserved values 0-63 OSF-DCE 64 SESAME 65
-------------------------------+------------- 承認データ型|広告タイプ値-------------------------------+------------- 予約された値0-63OSF-DCE64SESAME65
-------------------------------+----------------- alternate authentication type |method-type value -------------------------------+----------------- reserved values 0-63 ATT-CHALLENGE-RESPONSE 64
-------------------------------+----------------- 代替の認証タイプ|メソッドタイプ値-------------------------------+----------------- 予約された値0-63ATT-CHALLENGE-RESPONSE64
-------------------------------+------------- transited encoding type |tr-type value -------------------------------+------------- DOMAIN-X500-COMPRESS 1 reserved values all others
-------------------------------+------------- タイプをコード化しながら、通過されます。|tr-タイプ値-------------------------------+------------- 予約されたDOMAIN-X500-COMPRESS1はすべての他のものを評価します。
Kohl & Neuman [Page 83] RFC 1510 Kerberos September 1993
コールとヌーマン[83ページ]のRFCの1510のケルベロスの1993年9月
--------------+-------+----------------------------------------- Label |Value |Meaning or MIT code --------------+-------+-----------------------------------------
--------------+-------+----------------------------------------- ラベル|値|意味かMITコード--------------+-------+-----------------------------------------
pvno 5 current Kerberos protocol version number
pvnoの5の現在のケルベロスプロトコルバージョン番号
message types
メッセージタイプ
KRB_AS_REQ 10 Request for initial authentication
KRB_AS_REP 11 Response to KRB_AS_REQ request
KRB_TGS_REQ 12 Request for authentication based on TGT
KRB_TGS_REP 13 Response to KRB_TGS_REQ request
KRB_AP_REQ 14 application request to server
KRB_AP_REP 15 Response to KRB_AP_REQ_MUTUAL
KRB_SAFE 20 Safe (checksummed) application message
KRB_PRIV 21 Private (encrypted) application message
KRB_CRED 22 Private (encrypted) message to forward
credentials
KRB_ERROR 30 Error response
KRB、_KRB_AS_REQへのAS_REP11ResponseがTGT KRB_TGS_REP13ResponseでKRB_TGS_REQ12Requestを認証に基づいた状態でKRB_TGS_REQに要求する初期の認証KRB_のためのAS_REQ10RequestはKRB_AP_REQ_MUTUAL KRB_SAFE20Safe(checksummedしました)アプリケーションメッセージKRB_PRIV21兵士(暗号化される)のアプリケーションメッセージKRB_CRED22兵士(暗号化される)へのAP_REP15ResponseがKRB_ERROR30Error応答を資格証明書に送るために通信させるサーバKRB_にKRB_AP_REQ14アプリケーション要求を要求します。
name types
名前タイプ
KRB_NT_UNKNOWN 0 Name type not known
KRB_NT_PRINCIPAL 1 Just the name of the principal as in DCE, or
for users
KRB_NT_SRV_INST 2 Service and other unique instance (krbtgt)
KRB_NT_SRV_HST 3 Service with host name as instance (telnet,
rcommands)
KRB_NT_SRV_XHST 4 Service with host as remaining components
KRB_NT_UID 5 Unique ID
KRB_NT_UNKNOWN0Nameタイプの知られていない_KRB_NTプリンシパル1JustはホストがいるSRV_HST3ServiceがコンポーネントKRB_NT_UID5Unique IDのままで残っているとしてのホストと共にインスタンス(telnet、rcommands)KRB_NT_SRV_XHST4Serviceとして命名するユーザのDCEか、KRB_NT_SRV_INST2Serviceと他のユニークなインスタンス(krbtgt)KRB_NT_のための主体の名前です。
error codes
エラーコード
KDC_ERR_NONE 0 No error
KDC_ERR_NAME_EXP 1 Client's entry in database has
expired
KDC_ERR_SERVICE_EXP 2 Server's entry in database has
expired
KDC_ERR_BAD_PVNO 3 Requested protocol version number
not supported
KDC_ERR_C_OLD_MAST_KVNO 4 Client's key encrypted in old
master key
KDC_ERR_S_OLD_MAST_KVNO 5 Server's key encrypted in old
master key
KDC_ERR_C_PRINCIPAL_UNKNOWN 6 Client not found in Kerberos database
KDC_ERR_S_PRINCIPAL_UNKNOWN 7 Server not found in Kerberos database
KDC_ERR_PRINCIPAL_NOT_UNIQUE 8 Multiple principal entries in
database
KDC_ERR_NONE0いいえ誤りKDC_ERR_NAME_EXP、データベースにおける1ClientのエントリーがKDC_ERR_SERVICE_EXPを吐き出した、データベースにおける2ServerのエントリーはC_OLD_MAST_KVNO4Clientのキーが巨匠で暗号化したKDC_ERR_であることはサポートされなかったKDC_ERR_BAD_PVNO3Requestedプロトコルバージョン番号を吐き出しました; S_OLD_MAST_KVNO5Serverのキーが巨匠の主要な__KDC_ERR Cプリンシパル_UNKNOWN6Clientで暗号化した主要なKDC_ERR_は、ケルベロスデータベースKDC_ERR_Sで_プリンシパル_UNKNOWN7ServerがケルベロスデータベースKDCで__データベースにおけるUNIQUE8のMultipleの主要なエントリーではなく、ERR_プリンシパル_を見つけなかったのがわかりませんでした。
Kohl & Neuman [Page 84] RFC 1510 Kerberos September 1993
コールとヌーマン[84ページ]のRFCの1510のケルベロスの1993年9月
KDC_ERR_NULL_KEY 9 The client or server has a null key
KDC_ERR_CANNOT_POSTDATE 10 Ticket not eligible for postdating
KDC_ERR_NEVER_VALID 11 Requested start time is later than
end time
KDC_ERR_POLICY 12 KDC policy rejects request
KDC_ERR_BADOPTION 13 KDC cannot accommodate requested
option
KDC_ERR_ETYPE_NOSUPP 14 KDC has no support for encryption
type
KDC_ERR_SUMTYPE_NOSUPP 15 KDC has no support for checksum type
KDC_ERR_PADATA_TYPE_NOSUPP 16 KDC has no support for padata type
KDC_ERR_TRTYPE_NOSUPP 17 KDC has no support for transited type
KDC_ERR_CLIENT_REVOKED 18 Clients credentials have been revoked
KDC_ERR_SERVICE_REVOKED 19 Credentials for server have been
revoked
KDC_ERR_TGT_REVOKED 20 TGT has been revoked
KDC_ERR_CLIENT_NOTYET 21 Client not yet valid - try again
later
KDC_ERR_SERVICE_NOTYET 22 Server not yet valid - try again
later
KDC_ERR_KEY_EXPIRED 23 Password has expired - change
password to reset
KDC_ERR_PREAUTH_FAILED 24 Pre-authentication information
was invalid
KDC_ERR_PREAUTH_REQUIRED 25 Additional pre-authentication
required*
KRB_AP_ERR_BAD_INTEGRITY 31 Integrity check on decrypted field
failed
KRB_AP_ERR_TKT_EXPIRED 32 Ticket expired
KRB_AP_ERR_TKT_NYV 33 Ticket not yet valid
KRB_AP_ERR_REPEAT 34 Request is a replay
KRB_AP_ERR_NOT_US 35 The ticket isn't for us
KRB_AP_ERR_BADMATCH 36 Ticket and authenticator don't match
KRB_AP_ERR_SKEW 37 Clock skew too great
KRB_AP_ERR_BADADDR 38 Incorrect net address
KRB_AP_ERR_BADVERSION 39 Protocol version mismatch
KRB_AP_ERR_MSG_TYPE 40 Invalid msg type
KRB_AP_ERR_MODIFIED 41 Message stream modified
KRB_AP_ERR_BADORDER 42 Message out of order
KRB_AP_ERR_BADKEYVER 44 Specified version of key is not
available
KRB_AP_ERR_NOKEY 45 Service key not available
KRB_AP_ERR_MUT_FAIL 46 Mutual authentication failed
KRB_AP_ERR_BADDIRECTION 47 Incorrect message direction
KRB_AP_ERR_METHOD 48 Alternative authentication method
required*
KRB_AP_ERR_BADSEQ 49 Incorrect sequence number in message
KRB_AP_ERR_INAPP_CKSUM 50 Inappropriate type of checksum in
KDC_ERR_NULL_KEY 9 The client or server has a null key KDC_ERR_CANNOT_POSTDATE 10 Ticket not eligible for postdating KDC_ERR_NEVER_VALID 11 Requested start time is later than end time KDC_ERR_POLICY 12 KDC policy rejects request KDC_ERR_BADOPTION 13 KDC cannot accommodate requested option KDC_ERR_ETYPE_NOSUPP 14 KDC has no support for encryption type KDC_ERR_SUMTYPE_NOSUPP 15 KDC has no support for checksum type KDC_ERR_PADATA_TYPE_NOSUPP 16 KDC has no support for padata type KDC_ERR_TRTYPE_NOSUPP 17 KDC has no support for transited type KDC_ERR_CLIENT_REVOKED 18 Clients credentials have been revoked KDC_ERR_SERVICE_REVOKED 19 Credentials for server have been revoked KDC_ERR_TGT_REVOKED 20 TGT has been revoked KDC_ERR_CLIENT_NOTYET 21 Client not yet valid - try again later KDC_ERR_SERVICE_NOTYET 22 Server not yet valid - try again later KDC_ERR_KEY_EXPIRED 23 Password has expired - change password to reset KDC_ERR_PREAUTH_FAILED 24 Pre-authentication information was invalid KDC_ERR_PREAUTH_REQUIRED 25 Additional pre-authentication required* KRB_AP_ERR_BAD_INTEGRITY 31 Integrity check on decrypted field failed KRB_AP_ERR_TKT_EXPIRED 32 Ticket expired KRB_AP_ERR_TKT_NYV 33 Ticket not yet valid KRB_AP_ERR_REPEAT 34 Request is a replay KRB_AP_ERR_NOT_US 35 The ticket isn't for us KRB_AP_ERR_BADMATCH 36 Ticket and authenticator don't match KRB_AP_ERR_SKEW 37 Clock skew too great KRB_AP_ERR_BADADDR 38 Incorrect net address KRB_AP_ERR_BADVERSION 39 Protocol version mismatch KRB_AP_ERR_MSG_TYPE 40 Invalid msg type KRB_AP_ERR_MODIFIED 41 Message stream modified KRB_AP_ERR_BADORDER 42 Message out of order KRB_AP_ERR_BADKEYVER 44 Specified version of key is not available KRB_AP_ERR_NOKEY 45 Service key not available KRB_AP_ERR_MUT_FAIL 46 Mutual authentication failed KRB_AP_ERR_BADDIRECTION 47 Incorrect message direction KRB_AP_ERR_METHOD 48 Alternative authentication method required* KRB_AP_ERR_BADSEQ 49 Incorrect sequence number in message KRB_AP_ERR_INAPP_CKSUM 50 Inappropriate type of checksum in
Kohl & Neuman [Page 85] RFC 1510 Kerberos September 1993
Kohl & Neuman [Page 85] RFC 1510 Kerberos September 1993
message
KRB_ERR_GENERIC 60 Generic error (description in e-text)
KRB_ERR_FIELD_TOOLONG 61 Field is too long for this
implementation
message KRB_ERR_GENERIC 60 Generic error (description in e-text) KRB_ERR_FIELD_TOOLONG 61 Field is too long for this implementation
*This error carries additional information in the e-data field. The contents of the e-data field for this message is described in section 5.9.1.
*This error carries additional information in the e-data field. The contents of the e-data field for this message is described in section 5.9.1.
9. Interoperability requirements
9. Interoperability requirements
Version 5 of the Kerberos protocol supports a myriad of options. Among these are multiple encryption and checksum types, alternative encoding schemes for the transited field, optional mechanisms for pre-authentication, the handling of tickets with no addresses, options for mutual authentication, user to user authentication, support for proxies, forwarding, postdating, and renewing tickets, the format of realm names, and the handling of authorization data.
Version 5 of the Kerberos protocol supports a myriad of options. Among these are multiple encryption and checksum types, alternative encoding schemes for the transited field, optional mechanisms for pre-authentication, the handling of tickets with no addresses, options for mutual authentication, user to user authentication, support for proxies, forwarding, postdating, and renewing tickets, the format of realm names, and the handling of authorization data.
In order to ensure the interoperability of realms, it is necessary to define a minimal configuration which must be supported by all implementations. This minimal configuration is subject to change as technology does. For example, if at some later date it is discovered that one of the required encryption or checksum algorithms is not secure, it will be replaced.
In order to ensure the interoperability of realms, it is necessary to define a minimal configuration which must be supported by all implementations. This minimal configuration is subject to change as technology does. For example, if at some later date it is discovered that one of the required encryption or checksum algorithms is not secure, it will be replaced.
9.1. Specification 1
9.1. Specification 1
This section defines the first specification of these options. Implementations which are configured in this way can be said to support Kerberos Version 5 Specification 1 (5.1).
This section defines the first specification of these options. Implementations which are configured in this way can be said to support Kerberos Version 5 Specification 1 (5.1).
Encryption and checksum methods
Encryption and checksum methods
The following encryption and checksum mechanisms must be supported. Implementations may support other mechanisms as well, but the additional mechanisms may only be used when communicating with principals known to also support them: Encryption: DES-CBC-MD5 Checksums: CRC-32, DES-MAC, DES-MAC-K, and DES-MD5
The following encryption and checksum mechanisms must be supported. Implementations may support other mechanisms as well, but the additional mechanisms may only be used when communicating with principals known to also support them: Encryption: DES-CBC-MD5 Checksums: CRC-32, DES-MAC, DES-MAC-K, and DES-MD5
Realm Names
Realm Names
All implementations must understand hierarchical realms in both the Internet Domain and the X.500 style. When a ticket granting ticket for an unknown realm is requested, the KDC must be able to determine the names of the intermediate realms between the KDCs realm and the requested realm.
All implementations must understand hierarchical realms in both the Internet Domain and the X.500 style. When a ticket granting ticket for an unknown realm is requested, the KDC must be able to determine the names of the intermediate realms between the KDCs realm and the requested realm.
Kohl & Neuman [Page 86] RFC 1510 Kerberos September 1993
Kohl & Neuman [Page 86] RFC 1510 Kerberos September 1993
Transited field encoding
Transited field encoding
DOMAIN-X500-COMPRESS (described in section 3.3.3.1) must be supported. Alternative encodings may be supported, but they may be used only when that encoding is supported by ALL intermediate realms.
DOMAIN-X500-COMPRESS (described in section 3.3.3.1) must be supported. Alternative encodings may be supported, but they may be used only when that encoding is supported by ALL intermediate realms.
Pre-authentication methods
Pre-authentication methods
The TGS-REQ method must be supported. The TGS-REQ method is not used on the initial request. The PA-ENC-TIMESTAMP method must be supported by clients but whether it is enabled by default may be determined on a realm by realm basis. If not used in the initial request and the error KDC_ERR_PREAUTH_REQUIRED is returned specifying PA-ENCTIMESTAMP as an acceptable method, the client should retry the initial request using the PA-ENC-TIMESTAMP preauthentication method. Servers need not support the PAENC-TIMESTAMP method, but if not supported the server should ignore the presence of PA-ENC-TIMESTAMP pre-authentication in a request.
The TGS-REQ method must be supported. The TGS-REQ method is not used on the initial request. The PA-ENC-TIMESTAMP method must be supported by clients but whether it is enabled by default may be determined on a realm by realm basis. If not used in the initial request and the error KDC_ERR_PREAUTH_REQUIRED is returned specifying PA-ENCTIMESTAMP as an acceptable method, the client should retry the initial request using the PA-ENC-TIMESTAMP preauthentication method. Servers need not support the PAENC-TIMESTAMP method, but if not supported the server should ignore the presence of PA-ENC-TIMESTAMP pre-authentication in a request.
Mutual authentication
Mutual authentication
Mutual authentication (via the KRB_AP_REP message) must be supported.
Mutual authentication (via the KRB_AP_REP message) must be supported.
Ticket addresses and flags
Ticket addresses and flags
All KDC's must pass on tickets that carry no addresses (i.e., if a TGT contains no addresses, the KDC will return derivative tickets), but each realm may set its own policy for issuing such tickets, and each application server will set its own policy with respect to accepting them. By default, servers should not accept them.
All KDC's must pass on tickets that carry no addresses (i.e., if a TGT contains no addresses, the KDC will return derivative tickets), but each realm may set its own policy for issuing such tickets, and each application server will set its own policy with respect to accepting them. By default, servers should not accept them.
Proxies and forwarded tickets must be supported. Individual realms and application servers can set their own policy on when such tickets will be accepted.
Proxies and forwarded tickets must be supported. Individual realms and application servers can set their own policy on when such tickets will be accepted.
All implementations must recognize renewable and postdated tickets, but need not actually implement them. If these options are not supported, the starttime and endtime in the ticket shall specify a ticket's entire useful life. When a postdated ticket is decoded by a server, all implementations shall make the presence of the postdated flag visible to the calling server.
All implementations must recognize renewable and postdated tickets, but need not actually implement them. If these options are not supported, the starttime and endtime in the ticket shall specify a ticket's entire useful life. When a postdated ticket is decoded by a server, all implementations shall make the presence of the postdated flag visible to the calling server.
User-to-user authentication
User-to-user authentication
Support for user to user authentication (via the ENC-TKTIN-SKEY KDC option) must be provided by implementations, but individual realms may decide as a matter of policy to reject such requests on a per- principal or realm-wide basis.
Support for user to user authentication (via the ENC-TKTIN-SKEY KDC option) must be provided by implementations, but individual realms may decide as a matter of policy to reject such requests on a per- principal or realm-wide basis.
Kohl & Neuman [Page 87] RFC 1510 Kerberos September 1993
Kohl & Neuman [Page 87] RFC 1510 Kerberos September 1993
Authorization data
Authorization data
Implementations must pass all authorization data subfields from ticket-granting tickets to any derivative tickets unless directed to suppress a subfield as part of the definition of that registered subfield type (it is never incorrect to pass on a subfield, and no registered subfield types presently specify suppression at the KDC).
Implementations must pass all authorization data subfields from ticket-granting tickets to any derivative tickets unless directed to suppress a subfield as part of the definition of that registered subfield type (it is never incorrect to pass on a subfield, and no registered subfield types presently specify suppression at the KDC).
Implementations must make the contents of any authorization data subfields available to the server when a ticket is used. Implementations are not required to allow clients to specify the contents of the authorization data fields.
Implementations must make the contents of any authorization data subfields available to the server when a ticket is used. Implementations are not required to allow clients to specify the contents of the authorization data fields.
9.2. Recommended KDC values
9.2. Recommended KDC values
Following is a list of recommended values for a KDC implementation, based on the list of suggested configuration constants (see section 4.4).
Following is a list of recommended values for a KDC implementation, based on the list of suggested configuration constants (see section 4.4).
minimum lifetime 5 minutes
minimum lifetime 5 minutes
maximum renewable lifetime 1 week
maximum renewable lifetime 1 week
maximum ticket lifetime 1 day
maximum ticket lifetime 1 day
empty addresses only when suitable restrictions appear
in authorization data
empty addresses only when suitable restrictions appear in authorization data
proxiable, etc. Allowed.
proxiable, etc. Allowed.
10. Acknowledgments
10. Acknowledgments
Early versions of this document, describing version 4 of the protocol, were written by Jennifer Steiner (formerly at Project Athena); these drafts provided an excellent starting point for this current version 5 specification. Many people in the Internet community have contributed ideas and suggested protocol changes for version 5. Notable contributions came from Ted Anderson, Steve Bellovin and Michael Merritt [17], Daniel Bernstein, Mike Burrows, Donald Davis, Ravi Ganesan, Morrie Gasser, Virgil Gligor, Bill Griffeth, Mark Lillibridge, Mark Lomas, Steve Lunt, Piers McMahon, Joe Pato, William Sommerfeld, Stuart Stubblebine, Ralph Swick, Ted T'so, and Stanley Zanarotti. Many others commented and helped shape this specification into its current form.
Early versions of this document, describing version 4 of the protocol, were written by Jennifer Steiner (formerly at Project Athena); these drafts provided an excellent starting point for this current version 5 specification. Many people in the Internet community have contributed ideas and suggested protocol changes for version 5. Notable contributions came from Ted Anderson, Steve Bellovin and Michael Merritt [17], Daniel Bernstein, Mike Burrows, Donald Davis, Ravi Ganesan, Morrie Gasser, Virgil Gligor, Bill Griffeth, Mark Lillibridge, Mark Lomas, Steve Lunt, Piers McMahon, Joe Pato, William Sommerfeld, Stuart Stubblebine, Ralph Swick, Ted T'so, and Stanley Zanarotti. Many others commented and helped shape this specification into its current form.
Kohl & Neuman [Page 88] RFC 1510 Kerberos September 1993
Kohl & Neuman [Page 88] RFC 1510 Kerberos September 1993
11. References
11. References
[1] Miller, S., Neuman, C., Schiller, J., and J. Saltzer, "Section
E.2.1: Kerberos Authentication and Authorization System",
M.I.T. Project Athena, Cambridge, Massachusetts, December 21,
1987.
[1] Miller, S., Neuman, C., Schiller, J., and J. Saltzer, "Section E.2.1: Kerberos Authentication and Authorization System", M.I.T. Project Athena, Cambridge, Massachusetts, December 21, 1987.
[2] Steiner, J., Neuman, C., and J. Schiller, "Kerberos: An
Authentication Service for Open Network Systems", pp. 191-202 in
Usenix Conference Proceedings, Dallas, Texas, February, 1988.
[2] Steiner, J., Neuman, C., and J. Schiller, "Kerberos: An Authentication Service for Open Network Systems", pp. 191-202 in Usenix Conference Proceedings, Dallas, Texas, February, 1988.
[3] Needham, R., and M. Schroeder, "Using Encryption for
Authentication in Large Networks of Computers", Communications
of the ACM, Vol. 21 (12), pp. 993-999, December 1978.
[3] Needham, R., and M. Schroeder, "Using Encryption for Authentication in Large Networks of Computers", Communications of the ACM, Vol. 21 (12), pp. 993-999, December 1978.
[4] Denning, D., and G. Sacco, "Time stamps in Key Distribution
Protocols", Communications of the ACM, Vol. 24 (8), pp. 533-536,
August 1981.
[4] Denning, D., and G. Sacco, "Time stamps in Key Distribution Protocols", Communications of the ACM, Vol. 24 (8), pp. 533-536, August 1981.
[5] Kohl, J., Neuman, C., and T. Ts'o, "The Evolution of the
Kerberos Authentication Service", in an IEEE Computer Society
Text soon to be published, June 1992.
[5] Kohl, J., Neuman, C., and T. Ts'o, "The Evolution of the Kerberos Authentication Service", in an IEEE Computer Society Text soon to be published, June 1992.
[6] Davis, D., and R. Swick, "Workstation Services and Kerberos
Authentication at Project Athena", Technical Memorandum TM-424,
MIT Laboratory for Computer Science, February 1990.
[6] Davis, D., and R. Swick, "Workstation Services and Kerberos Authentication at Project Athena", Technical Memorandum TM-424, MIT Laboratory for Computer Science, February 1990.
[7] Levine, P., Gretzinger, M, Diaz, J., Sommerfeld, W., and K.
Raeburn, "Section E.1: Service Management System, M.I.T.
Project Athena, Cambridge, Mas sachusetts (1987).
[7] Levine, P., Gretzinger, M, Diaz, J., Sommerfeld, W., and K. Raeburn, "Section E.1: Service Management System, M.I.T. Project Athena, Cambridge, Mas sachusetts (1987).
[8] CCITT, Recommendation X.509: The Directory Authentication
Framework, December 1988.
[8] CCITT, Recommendation X.509: The Directory Authentication Framework, December 1988.
[9] Neuman, C., "Proxy-Based Authorization and Accounting for
Distributed Systems," in Proceedings of the 13th International
Conference on Distributed Computing Systems", Pittsburgh, PA,
May 1993.
[9] Neuman, C., "Proxy-Based Authorization and Accounting for Distributed Systems," in Proceedings of the 13th International Conference on Distributed Computing Systems", Pittsburgh, PA, May 1993.
[10] Pato, J., "Using Pre-Authentication to Avoid Password Guessing
Attacks", Open Software Foundation DCE Request for Comments 26,
December 1992.
[10] Pato, J., "Using Pre-Authentication to Avoid Password Guessing Attacks", Open Software Foundation DCE Request for Comments 26, December 1992.
[11] National Bureau of Standards, U.S. Department of Commerce, "Data
Encryption Standard", Federal Information Processing Standards
Publication 46, Washington, DC (1977).
[11] National Bureau of Standards, U.S. Department of Commerce, "Data Encryption Standard", Federal Information Processing Standards Publication 46, Washington, DC (1977).
Kohl & Neuman [Page 89] RFC 1510 Kerberos September 1993
Kohl & Neuman [Page 89] RFC 1510 Kerberos September 1993
[12] National Bureau of Standards, U.S. Department of Commerce, "DES
Modes of Operation", Federal Information Processing Standards
Publication 81, Springfield, VA, December 1980.
[12] National Bureau of Standards, U.S. Department of Commerce, "DES Modes of Operation", Federal Information Processing Standards Publication 81, Springfield, VA, December 1980.
[13] Stubblebine S., and V. Gligor, "On Message Integrity in
Cryptographic Protocols", in Proceedings of the IEEE Symposium
on Research in Security and Privacy, Oakland, California, May
1992.
[13] Stubblebine S., and V. Gligor, "On Message Integrity in Cryptographic Protocols", in Proceedings of the IEEE Symposium on Research in Security and Privacy, Oakland, California, May 1992.
[14] International Organization for Standardization, "ISO Information
Processing Systems - Data Communication High-Level Data Link
Control Procedure - Frame Structure", IS 3309, October 1984, 3rd
Edition.
[14] International Organization for Standardization, "ISO Information Processing Systems - Data Communication High-Level Data Link Control Procedure - Frame Structure", IS 3309, October 1984, 3rd Edition.
[15] Rivest, R., "The MD4 Message Digest Algorithm", RFC 1320, MIT
Laboratory for Computer Science, April 1992.
[15] Rivest, R., "The MD4 Message Digest Algorithm", RFC 1320, MIT Laboratory for Computer Science, April 1992.
[16] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, MIT
Laboratory for Computer Science, April 1992.
[16] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, MIT Laboratory for Computer Science, April 1992.
[17] Bellovin S., and M. Merritt, "Limitations of the Kerberos
Authentication System", Computer Communications Review, Vol.
20(5), pp. 119-132, October 1990.
[17] Bellovin S., and M. Merritt, "Limitations of the Kerberos Authentication System", Computer Communications Review, Vol. 20(5), pp. 119-132, October 1990.
12. Security Considerations
12. Security Considerations
Security issues are discussed throughout this memo.
Security issues are discussed throughout this memo.
13. Authors' Addresses
13. Authors' Addresses
John Kohl Digital Equipment Corporation 110 Spit Brook Road, M/S ZKO3-3/U14 Nashua, NH 03062
John Kohl Digital Equipment Corporation 110 Spit Brook Road, M/S ZKO3-3/U14 Nashua, NH 03062
Phone: 603-881-2481 EMail: jtkohl@zk3.dec.com
Phone: 603-881-2481 EMail: jtkohl@zk3.dec.com
B. Clifford Neuman USC/Information Sciences Institute 4676 Admiralty Way #1001 Marina del Rey, CA 90292-6695
B. Clifford Neuman USC/Information Sciences Institute 4676 Admiralty Way #1001 Marina del Rey, CA 90292-6695
Phone: 310-822-1511 EMail: bcn@isi.edu
Phone: 310-822-1511 EMail: bcn@isi.edu
Kohl & Neuman [Page 90] RFC 1510 Kerberos September 1993
Kohl & Neuman [Page 90] RFC 1510 Kerberos September 1993
A. Pseudo-code for protocol processing
A. Pseudo-code for protocol processing
This appendix provides pseudo-code describing how the messages are to be constructed and interpreted by clients and servers.
This appendix provides pseudo-code describing how the messages are to be constructed and interpreted by clients and servers.
A.1. KRB_AS_REQ generation
request.pvno := protocol version; /* pvno = 5 */
request.msg-type := message type; /* type = KRB_AS_REQ */
A.1. KRB_AS_REQ generation request.pvno := protocol version; /* pvno = 5 */ request.msg-type := message type; /* type = KRB_AS_REQ */
if(pa_enc_timestamp_required) then
request.padata.padata-type = PA-ENC-TIMESTAMP;
get system_time;
padata-body.patimestamp,pausec = system_time;
encrypt padata-body into request.padata.padata-value
using client.key; /* derived from password */
endif
if(pa_enc_timestamp_required) then request.padata.padata-type = PA-ENC-TIMESTAMP; get system_time; padata-body.patimestamp,pausec = system_time; encrypt padata-body into request.padata.padata-value using client.key; /* derived from password */ endif
body.kdc-options := users's preferences;
body.cname := user's name;
body.realm := user's realm;
body.sname := service's name; /* usually "krbtgt",
"localrealm" */
if (body.kdc-options.POSTDATED is set) then
body.from := requested starting time;
else
omit body.from;
endif
body.till := requested end time;
if (body.kdc-options.RENEWABLE is set) then
body.rtime := requested final renewal time;
endif
body.nonce := random_nonce();
body.etype := requested etypes;
if (user supplied addresses) then
body.addresses := user's addresses;
else
omit body.addresses;
endif
omit body.enc-authorization-data;
request.req-body := body;
body.kdc-オプション:=ユーザsの好み。 body.cname:=ユーザの名前。 body.realm:=ユーザの分野。 body.sname:=サービスの名前。 通常/*"krbtgt"、"localrealm"*/は次に、(body.kdc-options.POSTDATEDは用意ができています)body.from:=であるなら始動時を要求しました。 ほか、body.fromを省略してください。 endif body.till:=は終わりの時間を要求しました。 (body.kdc-options.RENEWABLEは用意ができています)当時のbody.rtime:=が最後の更新時間を要求したなら。 endif body.nonceの:=の無作為の_一回だけ()。 body.etype:=はetypesを要求しました。 (ユーザの供給されたアドレス)当時のbody.addresses:=ユーザアドレスであるなら。 ほか、body.addressesを省略してください。 endifはbody.enc認可データを省略します。 request.req-ボディー:=ボディー。
kerberos := lookup(name of local kerberos server (or servers));
send(packet,kerberos);
kerberos:=ルックアップ(ローカルのkerberosサーバ(または、サーバ)の名前)。 (パケット、kerberos)を送ってください。
wait(for response);
if (timed_out) then
retry or use alternate server;
endif
待ってください(応答のために)。 (調節された_が外にある状態で)その時なら、交互のサーバを再試行するか、または使用してください。 endif
Kohl & Neuman [Page 91] RFC 1510 Kerberos September 1993
コールとヌーマン[91ページ]のRFCの1510のケルベロスの1993年9月
A.2. KRB_AS_REQ verification and KRB_AS_REP generation
decode message into req;
A.2。 KRB_AS_REQ検証とKRB_AS_REP世代はメッセージをreqに解読します。
client := lookup(req.cname,req.realm);
server := lookup(req.sname,req.realm);
get system_time;
kdc_time := system_time.seconds;
クライアント:=ルックアップ(req.cname、req.realm)。 サーバ:=ルックアップ(req.sname、req.realm)。 システム_時間を得てください。 kdc_時間:=システム_time.seconds。
if (!client) then
/* no client in Database */
error_out(KDC_ERR_C_PRINCIPAL_UNKNOWN);
endif
if (!server) then
/* no server in Database */
error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN);
endif
(KDC_ERR_C_プリンシパル_UNKNOWN)からのDatabase*/誤り_の(クライアント)当時の/*ノークライアントであるなら。 endif、(_KDC_ERR_Sプリンシパル_UNKNOWN)からのDatabase*/誤り_の(サーバ)当時の/*ノーサーバであるなら。 endif
if(client.pa_enc_timestamp_required and
pa_enc_timestamp not present) then
error_out(KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP));
endif
(KDC_ERR_PREAUTH_REQUIRED(_PA ENC_TIMESTAMP))からの次に、(_が必要とした_enc_タイムスタンプとpa_enc_タイムスタンプが寄贈しないclient.pa)誤り_であるなら。 endif
if(pa_enc_timestamp present) then
decrypt req.padata-value into decrypted_enc_timestamp
using client.key;
using auth_hdr.authenticator.subkey;
if (decrypt_error()) then
error_out(KRB_AP_ERR_BAD_INTEGRITY);
if(decrypted_enc_timestamp is not within allowable
skew) then error_out(KDC_ERR_PREAUTH_FAILED);
endif
if(decrypted_enc_timestamp and usec is replay)
error_out(KDC_ERR_PREAUTH_FAILED);
endif
add decrypted_enc_timestamp and usec to replay cache;
endif
(pa_enc_タイムスタンププレゼント)であるなら、client.keyを使用することで解読された_enc_タイムスタンプにreq.padata-値を解読してください。 auth_hdr.authenticator.subkeyを使用します。 (_外(KRB_AP_ERR_BAD_INTEGRITY)で次に、_誤り())が誤りであると解読してください。 (KDC_ERR_PREAUTH_FAILED)からの次に、(許容できる斜行の中に解読された_enc_タイムスタンプがありません)誤り_であるなら。 endif、(KDC_ERR_PREAUTH_FAILED)からの(_enc_タイムスタンプとusecであると解読されているのは、再生です)誤り_であるなら。 endifはキャッシュを再演するために解読された_enc_タイムスタンプとusecを加えます。 endif
use_etype := first supported etype in req.etypes;
使用_etype:=は最初に、req.etypesでetypeを支持しました。
if (no support for req.etypes) then
error_out(KDC_ERR_ETYPE_NOSUPP);
endif
(KDC_ERR_ETYPE_NOSUPP)からの次に、(req.etypesのサポートがありません)誤り_であるなら。 endif
new_tkt.vno := ticket version; /* = 5 */
new_tkt.sname := req.sname;
new_tkt.srealm := req.srealm;
reset all flags in new_tkt.flags;
新しい_tkt.vno:=チケットバージョン。 /*は5の*/新しい_tkt.sname:=req.snameと等しいです。 新しい_tkt.srealm:=req.srealm。 新しい_tkt.flagsのすべての旗をリセットしてください。
Kohl & Neuman [Page 92] RFC 1510 Kerberos September 1993
コールとヌーマン[92ページ]のRFCの1510のケルベロスの1993年9月
/* It should be noted that local policy may affect the */
/* processing of any of these flags. For example, some */
/* realms may refuse to issue renewable tickets */
/、*ローカルの方針がこれらの旗のどれかの*//*処理に影響するかもしれないことに注意されるべきです。 例えば、いくつかの*//*分野が、再生可能なものチケット*/を発行するのを拒否するかもしれません。
if (req.kdc-options.FORWARDABLE is set) then
set new_tkt.flags.FORWARDABLE;
endif
if (req.kdc-options.PROXIABLE is set) then
set new_tkt.flags.PROXIABLE;
endif
if (req.kdc-options.ALLOW-POSTDATE is set) then
set new_tkt.flags.ALLOW-POSTDATE;
endif
if ((req.kdc-options.RENEW is set) or
(req.kdc-options.VALIDATE is set) or
(req.kdc-options.PROXY is set) or
(req.kdc-options.FORWARDED is set) or
(req.kdc-options.ENC-TKT-IN-SKEY is set)) then
error_out(KDC_ERR_BADOPTION);
endif
_tkt.flags.FORWARDABLEがその時新しい状態でセットしたなら(req.kdc-options.FORWARDABLEは用意ができています)。 endifは(req.kdc-options.PROXIABLEは用意ができています)その時なら新しい_tkt.flags.PROXIABLEを設定しました。 endifは(req.kdc-options.ALLOW-POSTDATEは用意ができています)その時なら新しい_tkt.flags.ALLOW-POSTDATEを設定しました。 または、または、または、または、endif、(req.kdc-options.RENEWは用意ができています)、(req.kdc-options.VALIDATEは用意ができています)、(req.kdc-options.PROXYは用意ができています)、(req.kdc-options.FORWARDEDは用意ができています)、(req.kdc-options.ENC-TKT IN SKEYは用意ができています)) (KDC_ERR_BADOPTION)からの次に、誤り_。 endif
new_tkt.session := random_session_key();
new_tkt.cname := req.cname;
new_tkt.crealm := req.crealm;
new_tkt.transited := empty_transited_field();
新しい_tkt.session:=無作為の_セッション_キー()。 新しい_tkt.cname:=req.cname。 新しい_tkt.crealm:=req.crealm。 新しい_tkt.transited:=空の_は_野原()を通過しました。
new_tkt.authtime := kdc_time;
新しい_tkt.authtime:=kdc_時間。
if (req.kdc-options.POSTDATED is set) then
if (against_postdate_policy(req.from)) then
error_out(KDC_ERR_POLICY);
endif
set new_tkt.flags.INVALID;
new_tkt.starttime := req.from;
else
omit new_tkt.starttime; /* treated as authtime when
omitted */
endif
if (req.till = 0) then
till := infinity;
else
till := req.till;
endif
(req.kdc-options.POSTDATED、セット) (KDC_ERR_POLICY)からの次に、(_に対して_方針(req.from)に先日付を書いてください)誤り_であるなら、その時です。 endifは新しい_tkt.flags.INVALIDを設定しました。 新しい_tkt.starttime:=req.from。 ほか、新しい_tkt.starttimeを省略してください。 省略された*/endifであるときにそして、:=無限までの(req.till=0)であるならauthtimeとして扱われた/*。 ほかの現金箱の:=req.till。 endif
new_tkt.endtime := min(till,
new_tkt.starttime+client.max_life,
new_tkt.starttime+server.max_life,
new_tkt.starttime+max_life_for_realm);
新しい_tkt.endtime:=分(新しい_tkt.starttime+client.max_の寿命、新しい_tkt.starttime+server.max_の寿命、新しい_tkt.starttime+が_人生_に_分野に最大限にするまで)。
Kohl & Neuman [Page 93] RFC 1510 Kerberos September 1993
コールとヌーマン[93ページ]のRFCの1510のケルベロスの1993年9月
if ((req.kdc-options.RENEWABLE-OK is set) and
(new_tkt.endtime < req.till)) then
/* we set the RENEWABLE option for later processing */
set req.kdc-options.RENEWABLE;
req.rtime := req.till;
endif
そして、(req.kdc-options.RENEWABLE-OKは設定されます)、(新しい_tkt.endtime<req.till)) 次に、後での*/設定しているreq.kdc-options.RENEWABLEを処理する私たちがRENEWABLEオプションを設定する/*。 req.rtime:=req.till。 endif
if (req.rtime = 0) then
rtime := infinity;
else
rtime := req.rtime;
endif
次に、(req.rtime=0)rtime:=無限であるなら。 ほかのrtime:=req.rtime。 endif
if (req.kdc-options.RENEWABLE is set) then
set new_tkt.flags.RENEWABLE;
new_tkt.renew-till := min(rtime,
new_tkt.starttime+client.max_rlife,
new_tkt.starttime+server.max_rlife,
new_tkt.starttime+max_rlife_for_realm);
else
omit new_tkt.renew-till; /* only present if RENEWABLE */
endif
_tkt.flags.RENEWABLEがその時新しい状態でセットしたなら(req.kdc-options.RENEWABLEは用意ができています)。 新しい_tkt.renew、-、現金箱の:=分(__分野へのrtimeであって、新しいrlifeであって、新しい_の_tkt.starttime+server.max_rlifeであって、新しい_tkt.starttime+client.max_tkt.starttime+最大rlife_)。 ほか、新しい_tkt.renew-現金箱を省略してください。 *がRENEWABLE*/endifである場合にだけ提示する/
if (req.addresses) then
new_tkt.caddr := req.addresses;
else
omit new_tkt.caddr;
endif
(req.addresses)当時の新しい_tkt.caddr:=req.addressesであるなら。 ほか、新しい_tkt.caddrを省略してください。 endif
new_tkt.authorization_data := empty_authorization_data();
新しい_tkt.authorization_データ:=は_認可_データ()を空にします。
encode to-be-encrypted part of ticket into OCTET STRING;
new_tkt.enc-part := encrypt OCTET STRING
using etype_for_key(server.key), server.key, server.p_kvno;
チケットのコード化された部分をOCTET STRINGにコード化してください。 新しい_tkt.enc-パート:=は_キー(server.key)、server.key、server.p_kvnoにetype_を使用することでOCTET STRINGをコード化します。
/* Start processing the response */
応答*/を処理する/*始め
resp.pvno := 5;
resp.msg-type := KRB_AS_REP;
resp.cname := req.cname;
resp.crealm := req.realm;
resp.ticket := new_tkt;
resp.pvno:=5。 resp.msg-タイプ:=KRB_AS_REP。 resp.cname:=req.cname。 resp.crealm:=req.realm。 resp.ticketの:=の新しい_tkt。
resp.key := new_tkt.session;
resp.last-req := fetch_last_request_info(client);
resp.nonce := req.nonce;
resp.key-expiration := client.expiration;
resp.keyの:=の新しい_tkt.session。 resp.last-req:=フェッチ_最終_要求_インフォメーション(クライアント)。 resp.nonce:=req.nonce。 resp.key-満了:=client.expiration。
Kohl & Neuman [Page 94] RFC 1510 Kerberos September 1993
コールとヌーマン[94ページ]のRFCの1510のケルベロスの1993年9月
resp.flags := new_tkt.flags;
resp.flagsの:=の新しい_tkt.flags。
resp.authtime := new_tkt.authtime;
resp.starttime := new_tkt.starttime;
resp.endtime := new_tkt.endtime;
resp.authtimeの:=の新しい_tkt.authtime。 resp.starttimeの:=の新しい_tkt.starttime。 resp.endtimeの:=の新しい_tkt.endtime。
if (new_tkt.flags.RENEWABLE) then
resp.renew-till := new_tkt.renew-till;
endif
次に、(新しい_tkt.flags.RENEWABLE)resp.renew-現金箱の:=の新しい_tkt.renew-現金箱であるなら。 endif
resp.realm := new_tkt.realm;
resp.sname := new_tkt.sname;
resp.realmの:=の新しい_tkt.realm。 resp.snameの:=の新しい_tkt.sname。
resp.caddr := new_tkt.caddr;
resp.caddrの:=の新しい_tkt.caddr。
encode body of reply into OCTET STRING;
回答のボディーをOCTET STRINGにコード化してください。
resp.enc-part := encrypt OCTET STRING
using use_etype, client.key, client.p_kvno;
send(resp);
resp.enc-パート:=は使用_etype、client.key、client.p_kvnoを使用することでOCTET STRINGをコード化します。 (resp)を送ってください。
A.3. KRB_AS_REP verification
decode response into resp;
A.3。 KRB_AS_REP検証は応答をrespに解読します。
if (resp.msg-type = KRB_ERROR) then
if(error = KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP))
then set pa_enc_timestamp_required;
goto KRB_AS_REQ;
endif
process_error(resp);
return;
endif
_(resp.msg-タイプ=KRB_ERROR)であるなら、次に、(誤り=KDC_ERR_PREAUTH_REQUIRED(_PA ENC_TIMESTAMP))がpaを設定するなら、enc_タイムスタンプ_が必要です。 goto KRB_AS_REQ。 endif過程_誤り(resp)。 戻ってください。 endif
/* On error, discard the response, and zero the session key */
/* from the response immediately */
/、*誤りのときに、応答を捨ててくださいといって、すぐに応答からのセッション主要な*//*のゼロを合わせてください、*/
key = get_decryption_key(resp.enc-part.kvno, resp.enc-part.etype,
resp.padata);
unencrypted part of resp := decode of decrypt of resp.enc-part
using resp.enc-part.etype and key;
zero(key);
キー=は_復号化_キー(resp.enc-part.kvno、resp.enc-part.etype、resp.padata)を手に入れます。 resp:=の非コード化された部分が解読する、resp.enc-part.etypeを使用して、キーはresp.enc-部分を解読します。 ゼロ(主要な)。
if (common_as_rep_tgs_rep_checks fail) then
destroy resp.key;
return error;
endif
(_レップ_チェックが失敗するレップ_tgs_としての一般的な_)であるなら、resp.keyを破壊してください。 誤りを返してください。 endif
if near(resp.princ_exp) then
(resp.princ_exp)その時頃に
Kohl & Neuman [Page 95] RFC 1510 Kerberos September 1993
コールとヌーマン[95ページ]のRFCの1510のケルベロスの1993年9月
print(warning message);
endif
save_for_later(ticket,session,client,server,times,flags);
印刷してください(警告メッセージ)。 endifは後で_のために_を取っておきます(チケット(セッション、クライアント、サーバ、回)は弛みます)。
A.4. KRB_AS_REP and KRB_TGS_REP common checks
if (decryption_error() or
(req.cname != resp.cname) or
(req.realm != resp.crealm) or
(req.sname != resp.sname) or
(req.realm != resp.realm) or
(req.nonce != resp.nonce) or
(req.addresses != resp.caddr)) then
destroy resp.key;
return KRB_AP_ERR_MODIFIED;
endif
A.4。 KRB_AS_REPと_のREPの一般的なKRB_TGSチェックは(復号化_誤り()、(req.cname!=resp.cname)、(req.realm!=resp.crealm)、(req.sname!=resp.sname)、(req.realm!=resp.realm)、(req.nonce!=resp.nonce)または(req.addresses!=resp.caddr))その時ならresp.keyを破壊します。 KRB_AP_ERR_MODIFIEDを返してください。 endif
/* make sure no flags are set that shouldn't be, and that */
/* all that should be are set */
if (!check_flags_for_compatability(req.kdc-options,resp.flags))
then destroy resp.key;
return KRB_AP_ERR_MODIFIED;
endif
次に、(_compatability(req.kdc-オプション、resp.flags)のためのチェック_旗の_)がresp.keyを破壊するなら、*がどんな旗もそれがセットであるべきでないことを確信するようにする/、およびそのすべてがその*//*であるべきであることはセット*/です。 KRB_AP_ERR_MODIFIEDを返してください。 endif
if ((req.from = 0) and
(resp.starttime is not within allowable skew)) then
destroy resp.key;
return KRB_AP_ERR_SKEW;
endif
if ((req.from != 0) and (req.from != resp.starttime)) then
destroy resp.key;
return KRB_AP_ERR_MODIFIED;
endif
if ((req.till != 0) and (resp.endtime > req.till)) then
destroy resp.key;
return KRB_AP_ERR_MODIFIED;
endif
(req.from=0)と(許容できる斜行の中にresp.starttimeがありません)その時なら、resp.keyを破壊してください。 KRB_AP_ERR_SKEWを返してください。 次に、endifは((req.from!=0)と(req.from!=resp.starttime))であるならresp.keyを破壊します。 KRB_AP_ERR_MODIFIEDを返してください。 次に、endifは((req.till!=0)と(resp.endtime>req.till))であるならresp.keyを破壊します。 KRB_AP_ERR_MODIFIEDを返してください。 endif
if ((req.kdc-options.RENEWABLE is set) and
(req.rtime != 0) and (resp.renew-till > req.rtime)) then
destroy resp.key;
return KRB_AP_ERR_MODIFIED;
endif
if ((req.kdc-options.RENEWABLE-OK is set) and
(resp.flags.RENEWABLE) and
(req.till != 0) and
(resp.renew-till > req.till)) then
destroy resp.key;
return KRB_AP_ERR_MODIFIED;
そして、(req.kdc-options.RENEWABLEは用意ができています)、次に、(req.rtime!=0)と(resp.renew-現金箱の>req.rtime)はresp.keyを破壊します。 KRB_AP_ERR_MODIFIEDを返してください。 そして、endif、(req.kdc-options.RENEWABLE-OKは設定されます)、次に、(resp.flags.RENEWABLE)、(req.till!=0)、および(resp.renew-現金箱の>req.till)はresp.keyを破壊します。 KRB_AP_ERR_MODIFIEDを返してください。
Kohl & Neuman [Page 96] RFC 1510 Kerberos September 1993
コールとヌーマン[96ページ]のRFCの1510のケルベロスの1993年9月
endif
endif
A.5. KRB_TGS_REQ generation
/* Note that make_application_request might have to */
/* recursivly call this routine to get the appropriate */
/* ticket-granting ticket */
A.5。 recursivlyが適切な*//*を得るためにアプリケーション_要求で*//*にこのルーチンを呼ぶかもしれない_をチケットを与えるチケット*/にするKRB_TGS_REQ世代/*注意
request.pvno := protocol version; /* pvno = 5 */
request.msg-type := message type; /* type = KRB_TGS_REQ */
request.pvno:=プロトコルバージョン。 /*pvnoは5request.msg*/タイプ:=メッセージタイプと等しいです。 /*タイプはKRB_TGS_REQ*/と等しいです。
body.kdc-options := users's preferences;
/* If the TGT is not for the realm of the end-server */
/* then the sname will be for a TGT for the end-realm */
/* and the realm of the requested ticket (body.realm) */
/* will be that of the TGS to which the TGT we are */
/* sending applies */
body.sname := service's name;
body.realm := service's realm;
body.kdc-オプション:=ユーザsの好み。 エンドサーバ*//*の分野にはTGTがなくて、次に、snameが終わり分野*//*のためのTGTのためにものになるだろうか、そして、要求されたチケット(body.realm)*//*の分野がTGSのものであるために望んでいる/*、どれ、TGT、私たちは*//*発信が*/body.sname:=サービスの名前を適用するということです。 body.realm:=サービスの分野。
if (body.kdc-options.POSTDATED is set) then
body.from := requested starting time;
else
omit body.from;
endif
body.till := requested end time;
if (body.kdc-options.RENEWABLE is set) then
body.rtime := requested final renewal time;
endif
body.nonce := random_nonce();
body.etype := requested etypes;
if (user supplied addresses) then
body.addresses := user's addresses;
else
omit body.addresses;
endif
(body.kdc-options.POSTDATEDは用意ができています)当時のbody.from:=が始動時を要求したなら。 ほか、body.fromを省略してください。 endif body.till:=は終わりの時間を要求しました。 (body.kdc-options.RENEWABLEは用意ができています)当時のbody.rtime:=が最後の更新時間を要求したなら。 endif body.nonceの:=の無作為の_一回だけ()。 body.etype:=はetypesを要求しました。 (ユーザの供給されたアドレス)当時のbody.addresses:=ユーザアドレスであるなら。 ほか、body.addressesを省略してください。 endif
body.enc-authorization-data := user-supplied data;
if (body.kdc-options.ENC-TKT-IN-SKEY) then
body.additional-tickets_ticket := second TGT;
endif
body.enc認可データ:=はデータをユーザと同じくらい提供しました。 (body.kdc-options.ENC-TKT IN SKEY)当時のbody.additionalチケット_チケット:=第2TGTであるなら。 endif
request.req-body := body;
check := generate_checksum (req.body,checksumtype);
request.req-ボディー:=ボディー。 チェック:=は_チェックサム(req.body、checksumtype)を発生させます。
request.padata[0].padata-type := PA-TGS-REQ;
request.padata[0].padata-value := create a KRB_AP_REQ using
the TGT and checksum
request.padata[0].padata-タイプ:=PA-TGS-REQ。 request.padata[0].padata-値の:=は、TGTとチェックサムを使用することでKRB_AP_REQを作成します。
Kohl & Neuman [Page 97] RFC 1510 Kerberos September 1993
コールとヌーマン[97ページ]のRFCの1510のケルベロスの1993年9月
/* add in any other padata as required/supplied */
/*は、いかなる他のpadataでも必要に応じて、/が*/を供給したと言い足します。
kerberos := lookup(name of local kerberose server (or servers));
send(packet,kerberos);
kerberos:=ルックアップ(ローカルのkerberoseサーバ(または、サーバ)の名前)。 (パケット、kerberos)を送ってください。
wait(for response);
if (timed_out) then
retry or use alternate server;
endif
待ってください(応答のために)。 (調節された_が外にある状態で)その時なら、交互のサーバを再試行するか、または使用してください。 endif
A.6. KRB_TGS_REQ verification and KRB_TGS_REP generation
/* note that reading the application request requires first
determining the server for which a ticket was issued, and
choosing the correct key for decryption. The name of the
server appears in the plaintext part of the ticket. */
A.6。 KRB_TGS_REQ検証とKRB_TGS_REP世代/*は、アプリケーション要求を読むのが、最初に復号化のために、チケットが正しいキーを支給されて、選んでいたサーバを決定するのを必要とすることに注意します。 サーバの名前はチケットの平文部分に現れます。 */
if (no KRB_AP_REQ in req.padata) then
error_out(KDC_ERR_PADATA_TYPE_NOSUPP);
endif
verify KRB_AP_REQ in req.padata;
(KRBがない、(KDC_ERR_PADATA_TYPE_NOSUPP)からの_req.padataのAP_REQ) 次に、誤り_。 endifはreq.padataでKRB_AP_REQについて確かめます。
/* Note that the realm in which the Kerberos server is
operating is determined by the instance from the
ticket-granting ticket. The realm in the ticket-granting
ticket is the realm under which the ticket granting ticket was
issued. It is possible for a single Kerberos server to
support more than one realm. */
ケルベロスサーバが作動している分野が例でチケットを与えるチケットから決定するという/*メモ。 チケットを与えるチケットの分野はチケットを与えるチケットが発行された分野です。 ただ一つのケルベロスサーバが1つ以上の分野を支持するのは、可能です。 */
auth_hdr := KRB_AP_REQ;
tgt := auth_hdr.ticket;
auth_hdr:=KRB_AP_REQ。 tgt:=auth_hdr.ticket。
if (tgt.sname is not a TGT for local realm and is not
req.sname) then error_out(KRB_AP_ERR_NOT_US);
(KRB_AP_ERR_NOT_米国)からの次に、(tgt.snameは地方の分野へのTGTでなく、またreq.snameではありません)誤り_であるなら。
realm := realm_tgt_is_for(tgt);
分野:=分野_tgt_は(tgt)のための_です。
decode remainder of request;
要求の残りを解読してください。
if (auth_hdr.authenticator.cksum is missing) then
error_out(KRB_AP_ERR_INAPP_CKSUM);
endif
if (auth_hdr.authenticator.cksum type is not supported) then
error_out(KDC_ERR_SUMTYPE_NOSUPP);
endif
if (auth_hdr.authenticator.cksum is not both collision-proof
and keyed) then
error_out(KRB_AP_ERR_INAPP_CKSUM);
endif
(KRB_AP_ERR_INAPP_CKSUM)からの次に、(auth_hdr.authenticator.cksumはなくなっています)誤り_であるなら。 endif、(KDC_ERR_SUMTYPE_NOSUPP)からの次に、(auth_hdr.authenticator.cksumタイプは支持されません)誤り_であるなら。 endif、(KRB_AP_ERR_INAPP_CKSUM)からの次に、(auth_hdr.authenticator.cksumはともに衝突耐なくて合わせられます)誤り_であるなら。 endif
Kohl & Neuman [Page 98] RFC 1510 Kerberos September 1993
コールとヌーマン[98ページ]のRFCの1510のケルベロスの1993年9月
set computed_checksum := checksum(req);
if (computed_checksum != auth_hdr.authenticatory.cksum) then
error_out(KRB_AP_ERR_MODIFIED);
endif
計算された_チェックサム:=チェックサム(req)を設定してください。 (KRB_AP_ERR_MODIFIED)からの次に、(_チェックサム!=auth_hdr.authenticatory.cksumを計算します)誤り_であるなら。 endif
server := lookup(req.sname,realm);
サーバ:=ルックアップ(req.sname、分野)。
if (!server) then
if (is_foreign_tgt_name(server)) then
server := best_intermediate_tgs(server);
else
/* no server in Database */
error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN);
endif
endif
(サーバ)であるなら、(_外国_tgt_名(サーバ)です)当時のサーバ:=であるなら_中間的_tgs(サーバ)を負かしてください。 ほかの/*、(_KDC_ERR_Sプリンシパル_UNKNOWN)からのDatabase*/誤り_でサーバがありません。 endif endif
session := generate_random_session_key();
セッション:=は_無作為の_セッション_キー()を発生させます。
use_etype := first supported etype in req.etypes;
使用_etype:=は最初に、req.etypesでetypeを支持しました。
if (no support for req.etypes) then
error_out(KDC_ERR_ETYPE_NOSUPP);
endif
(KDC_ERR_ETYPE_NOSUPP)からの次に、(req.etypesのサポートがありません)誤り_であるなら。 endif
new_tkt.vno := ticket version; /* = 5 */
new_tkt.sname := req.sname;
new_tkt.srealm := realm;
reset all flags in new_tkt.flags;
新しい_tkt.vno:=チケットバージョン。 /*は5の*/新しい_tkt.sname:=req.snameと等しいです。 新しい_tkt.srealm:=分野。 新しい_tkt.flagsのすべての旗をリセットしてください。
/* It should be noted that local policy may affect the */
/* processing of any of these flags. For example, some */
/* realms may refuse to issue renewable tickets */
/、*ローカルの方針がこれらの旗のどれかの*//*処理に影響するかもしれないことに注意されるべきです。 例えば、いくつかの*//*分野が、再生可能なものチケット*/を発行するのを拒否するかもしれません。
new_tkt.caddr := tgt.caddr;
resp.caddr := NULL; /* We only include this if they change */
if (req.kdc-options.FORWARDABLE is set) then
if (tgt.flags.FORWARDABLE is reset) then
error_out(KDC_ERR_BADOPTION);
endif
set new_tkt.flags.FORWARDABLE;
endif
if (req.kdc-options.FORWARDED is set) then
if (tgt.flags.FORWARDABLE is reset) then
error_out(KDC_ERR_BADOPTION);
endif
set new_tkt.flags.FORWARDED;
new_tkt.caddr := req.addresses;
新しい_tkt.caddr:=tgt.caddr。 resp.caddr:=NULL。 /、*彼らが(req.kdc-options.FORWARDABLEは用意ができています)その時なら(KDC_ERR_BADOPTION)からの次に、(tgt.flags.FORWARDABLEはリセットされます)誤り_であるなら*/を変える場合にだけ、私たちはこれを入れます。 endifは新しい_tkt.flags.FORWARDABLEを設定しました。 (req.kdc-options.FORWARDEDは用意ができています)その時なら(KDC_ERR_BADOPTION)からの次に、(tgt.flags.FORWARDABLEはリセットされます)誤り_であるならendifする、。 endifは新しい_tkt.flags.FORWARDEDを設定しました。 新しい_tkt.caddr:=req.addresses。
Kohl & Neuman [Page 99] RFC 1510 Kerberos September 1993
コールとヌーマン[99ページ]のRFCの1510のケルベロスの1993年9月
resp.caddr := req.addresses;
endif
if (tgt.flags.FORWARDED is set) then
set new_tkt.flags.FORWARDED;
endif
resp.caddr:=req.addresses。 endifは(tgt.flags.FORWARDEDは用意ができています)その時なら新しい_tkt.flags.FORWARDEDを設定しました。 endif
if (req.kdc-options.PROXIABLE is set) then
if (tgt.flags.PROXIABLE is reset)
error_out(KDC_ERR_BADOPTION);
endif
set new_tkt.flags.PROXIABLE;
endif
if (req.kdc-options.PROXY is set) then
if (tgt.flags.PROXIABLE is reset) then
error_out(KDC_ERR_BADOPTION);
endif
set new_tkt.flags.PROXY;
new_tkt.caddr := req.addresses;
resp.caddr := req.addresses;
endif
(req.kdc-options.PROXIABLE、セット) (KDC_ERR_BADOPTION)からの(tgt.flags.PROXIABLEはリセットされます)誤り_であるなら、その時です。 endifは新しい_tkt.flags.PROXIABLEを設定しました。 (req.kdc-options.PROXYは用意ができています)その時なら(KDC_ERR_BADOPTION)からの次に、(tgt.flags.PROXIABLEはリセットされます)誤り_であるならendifする、。 endifは新しい_tkt.flags.PROXYを設定しました。 新しい_tkt.caddr:=req.addresses。 resp.caddr:=req.addresses。 endif
if (req.kdc-options.POSTDATE is set) then
if (tgt.flags.POSTDATE is reset)
error_out(KDC_ERR_BADOPTION);
endif
set new_tkt.flags.POSTDATE;
endif
if (req.kdc-options.POSTDATED is set) then
if (tgt.flags.POSTDATE is reset) then
error_out(KDC_ERR_BADOPTION);
endif
set new_tkt.flags.POSTDATED;
set new_tkt.flags.INVALID;
if (against_postdate_policy(req.from)) then
error_out(KDC_ERR_POLICY);
endif
new_tkt.starttime := req.from;
endif
(req.kdc-options.POSTDATE、セット) (KDC_ERR_BADOPTION)からの(tgt.flags.POSTDATEはリセットされます)誤り_であるなら、その時です。 endifは新しい_tkt.flags.POSTDATEを設定しました。 (req.kdc-options.POSTDATEDは用意ができています)その時なら(KDC_ERR_BADOPTION)からの次に、(tgt.flags.POSTDATEはリセットされます)誤り_であるならendifする、。 endifは新しい_tkt.flags.POSTDATEDを設定しました。 新しい_tkt.flags.INVALIDを設定してください。 (KDC_ERR_POLICY)からの次に、(_に対して_方針(req.from)に先日付を書いてください)誤り_であるなら。 endifの新しい_tkt.starttime:=req.from。 endif
if (req.kdc-options.VALIDATE is set) then
if (tgt.flags.INVALID is reset) then
error_out(KDC_ERR_POLICY);
endif
if (tgt.starttime > kdc_time) then
error_out(KRB_AP_ERR_NYV);
endif
if (check_hot_list(tgt)) then
(req.kdc-options.VALIDATE、セット) (KDC_ERR_POLICY)からの次に、(tgt.flags.INVALIDはリセットされます)誤り_であるなら、その時です。 endif、(KRB_AP_ERR_NYV)からの(tgt.starttime>kdc_時間)次に、誤り_であるなら。 そして、(_チェックの熱い_リスト(tgt))であるなら、endifします。
Kohl & Neuman [Page 100] RFC 1510 Kerberos September 1993
コールとヌーマン[100ページ]のRFCの1510のケルベロスの1993年9月
error_out(KRB_AP_ERR_REPEAT);
endif
tkt := tgt;
reset new_tkt.flags.INVALID;
endif
誤り_アウト、(KRB_AP_が間違える、_反復)、。 endif tkt:=tgt。 新しい_tkt.flags.INVALIDをリセットしてください。 endif
if (req.kdc-options.(any flag except ENC-TKT-IN-SKEY, RENEW,
and those already processed) is set) then
error_out(KDC_ERR_BADOPTION);
endif
(KDC_ERR_BADOPTION)からの次に、(req.kdc-オプション(既に処理されたENC-TKT IN SKEY、RENEW、およびもの以外のどんな旗も)は設定されます)誤り_であるなら。 endif
new_tkt.authtime := tgt.authtime;
新しい_tkt.authtime:=tgt.authtime。
if (req.kdc-options.RENEW is set) then
/* Note that if the endtime has already passed, the ticket */
/* would have been rejected in the initial authentication */
/* stage, so there is no need to check again here */
if (tgt.flags.RENEWABLE is reset) then
error_out(KDC_ERR_BADOPTION);
endif
if (tgt.renew-till >= kdc_time) then
error_out(KRB_AP_ERR_TKT_EXPIRED);
endif
tkt := tgt;
new_tkt.starttime := kdc_time;
old_life := tgt.endttime - tgt.starttime;
new_tkt.endtime := min(tgt.renew-till,
new_tkt.starttime + old_life);
else
new_tkt.starttime := kdc_time;
if (req.till = 0) then
till := infinity;
else
till := req.till;
endif
new_tkt.endtime := min(till,
new_tkt.starttime+client.max_life,
new_tkt.starttime+server.max_life,
new_tkt.starttime+max_life_for_realm,
tgt.endtime);
したがって、次に、endtimeが既に通ったなら、チケット*//*が初期の認証*//*段階で拒絶されただろうという(req.kdc-options.RENEWは用意ができています)/*メモであるなら、再びここで*/をチェックする必要は次に、(tgt.flags.RENEWABLEはリセットされます)誤りであるなら全く_外(KDC_ERR_BADOPTION)にありません。 endif、(KRB_AP_ERR_TKT_EXPIRED)からの(tgt.renew-現金箱>=kdc_時間)次に、誤り_であるなら。 endif tkt:=tgt。 新しい_tkt.starttime:=kdc_時間。 古い_の寿命:=tgt.endttime(tgt.starttime) (tgt.renew-現金箱、新しい_tkt.starttime+古い_の寿命)新しい_tkt.endtime:=分。 ほかの新しい_tkt.starttime:=kdc_時間。 そして、:=無限までの(req.till=0)であるなら。 ほかの現金箱の:=req.till。 endif新しい_tkt.endtime:=分(新しい_tkt.starttime+client.max_の寿命、新しい_tkt.starttime+server.max_の寿命、新しい_tkt.starttime+が_分野、tgt.endtimeのために_人生_に最大限にするまで)。
if ((req.kdc-options.RENEWABLE-OK is set) and
(new_tkt.endtime < req.till) and
(tgt.flags.RENEWABLE is set) then
/* we set the RENEWABLE option for later */
/* processing */
set req.kdc-options.RENEWABLE;
req.rtime := min(req.till, tgt.renew-till);
そして、(req.kdc-options.RENEWABLE-OKは設定されます)、(新しい_tkt.endtime<req.till)、(tgt.flags.RENEWABLE、セット) 次に、私たちが設定する/*は後の*//*処理*/セットreq.kdc-options.RENEWABLE(req.rtime:=分(req.till、tgt.renew-現金箱))のためのRENEWABLEオプションです。
Kohl & Neuman [Page 101] RFC 1510 Kerberos September 1993
コールとヌーマン[101ページ]のRFCの1510のケルベロスの1993年9月
endif
endif
endif endif
if (req.rtime = 0) then
rtime := infinity;
else
rtime := req.rtime;
endif
次に、(req.rtime=0)rtime:=無限であるなら。 ほかのrtime:=req.rtime。 endif
if ((req.kdc-options.RENEWABLE is set) and
(tgt.flags.RENEWABLE is set)) then
set new_tkt.flags.RENEWABLE;
new_tkt.renew-till := min(rtime,
new_tkt.starttime+client.max_rlife,
new_tkt.starttime+server.max_rlife,
new_tkt.starttime+max_rlife_for_realm,
tgt.renew-till);
else
new_tkt.renew-till := OMIT;
/* leave the renew-till field out */
endif
if (req.enc-authorization-data is present) then
decrypt req.enc-authorization-data
into decrypted_authorization_data
using auth_hdr.authenticator.subkey;
if (decrypt_error()) then
error_out(KRB_AP_ERR_BAD_INTEGRITY);
endif
endif
new_tkt.authorization_data :=
req.auth_hdr.ticket.authorization_data +
decrypted_authorization_data;
(req.kdc-options.RENEWABLE、_次に、新しい状態で設定された(tgt.flags.RENEWABLEは設定しています)セットはtkt.flags.RENEWABLEです。 新しい_tkt.renew、-、現金箱の:=分(rtimeであって、新しいrlifeであって、新しい_の_tkt.starttime+server.max_rlifeであって、新しい_tkt.starttime+client.max_tkt.starttime+最大_は_分野、tgt.renew-現金箱のために_をrlifeします)。 ほかの新しい_tkt.renew-現金箱の:=OMIT。 (req.enc認可データは存在しています)その時がauth_hdr.authenticator.subkeyを使用することで解読された_認可_データにreq.enc認可データを解読するなら、/*は出ている*/endifに現金箱を取り替えている野原を出ます。 (_外(KRB_AP_ERR_BAD_INTEGRITY)で次に、_誤り())が誤りであると解読してください。 新しいendif endifの_tkt.authorization_データ:=req.auth_hdr.ticket.authorization_データ+解読された_認可_データ。
new_tkt.key := session;
new_tkt.crealm := tgt.crealm;
new_tkt.cname := req.auth_hdr.ticket.cname;
新しい_tkt.key:=セッション。 新しい_tkt.crealm:=tgt.crealm。 新しい_tkt.cname:=req.auth_hdr.ticket.cname。
if (realm_tgt_is_for(tgt) := tgt.realm) then
/* tgt issued by local realm */
new_tkt.transited := tgt.transited;
else
/* was issued for this realm by some other realm */
if (tgt.transited.tr-type not supported) then
error_out(KDC_ERR_TRTYPE_NOSUPP);
endif
new_tkt.transited
:= compress_transited(tgt.transited + tgt.realm)
endif
*次に、(分野_tgt_は(tgt):=tgt.realmのための_です)/であるなら、tgtは地方の分野*/新しい_でtkt.transited:=tgt.transitedを発行しました。 ほかに、/*は(KDC_ERR_TRTYPE_NOSUPP)からの次に、(支持されなかったtgt.transited.tr-タイプ)誤り_であるならある他の分野*/によってこの分野に発行されました。 endifの新しい_tkt.transited:=湿布_はendifを通過しました(tgt.transited+tgt.realm)。
Kohl & Neuman [Page 102] RFC 1510 Kerberos September 1993
コールとヌーマン[102ページ]のRFCの1510のケルベロスの1993年9月
encode encrypted part of new_tkt into OCTET STRING;
if (req.kdc-options.ENC-TKT-IN-SKEY is set) then
if (server not specified) then
server = req.second_ticket.client;
endif
if ((req.second_ticket is not a TGT) or
(req.second_ticket.client != server)) then
error_out(KDC_ERR_POLICY);
endif
エンコードは新しい_tktの一部をOCTET STRINGにコード化しました。 (req.kdc-options.ENC-TKT IN SKEYは用意ができています)その時なら、サーバは(サーバは指定しませんでした)その時ならreq2番目_ticket.clientと等しいです。 または、endif、(req2番目の_チケットはTGTではありません)、(KDC_ERR_POLICY)からの(req2番目の_ticket.client!=サーバ)次に、誤り_。 endif
new_tkt.enc-part := encrypt OCTET STRING using
using etype_for_key(second-ticket.key),
second-ticket.key;
else
new_tkt.enc-part := encrypt OCTET STRING
using etype_for_key(server.key), server.key,
server.p_kvno;
endif
新しい_tkt.enc-パート:=は_キー(2番目-ticket.key)、2番目-ticket.keyにetype_を使用することでOCTET STRING使用をコード化します。 ほかに、新しい_tkt.enc-パート:=は_キー(server.key)、server.key、server.p_kvnoにetype_を使用することでOCTET STRINGをコード化します。 endif
resp.pvno := 5;
resp.msg-type := KRB_TGS_REP;
resp.crealm := tgt.crealm;
resp.cname := tgt.cname;
resp.ticket := new_tkt;
resp.pvno:=5。 resp.msg-タイプ:=KRB_TGS_REP。 resp.crealm:=tgt.crealm。 resp.cname:=tgt.cname。 resp.ticketの:=の新しい_tkt。
resp.key := session;
resp.nonce := req.nonce;
resp.last-req := fetch_last_request_info(client);
resp.flags := new_tkt.flags;
resp.key:=セッション。 resp.nonce:=req.nonce。 resp.last-req:=フェッチ_最終_要求_インフォメーション(クライアント)。 resp.flagsの:=の新しい_tkt.flags。
resp.authtime := new_tkt.authtime;
resp.starttime := new_tkt.starttime;
resp.endtime := new_tkt.endtime;
resp.authtimeの:=の新しい_tkt.authtime。 resp.starttimeの:=の新しい_tkt.starttime。 resp.endtimeの:=の新しい_tkt.endtime。
omit resp.key-expiration;
resp.key-満了を省略してください。
resp.sname := new_tkt.sname;
resp.realm := new_tkt.realm;
resp.snameの:=の新しい_tkt.sname。 resp.realmの:=の新しい_tkt.realm。
if (new_tkt.flags.RENEWABLE) then
resp.renew-till := new_tkt.renew-till;
endif
次に、(新しい_tkt.flags.RENEWABLE)resp.renew-現金箱の:=の新しい_tkt.renew-現金箱であるなら。 endif
encode body of reply into OCTET STRING;
回答のボディーをOCTET STRINGにコード化してください。
if (req.padata.authenticator.subkey)
resp.enc-part := encrypt OCTET STRING using use_etype,
(req.padata.authenticator.subkey)resp.enc-パート:=であるなら、使用_etypeを使用することでOCTET STRINGをコード化してください。
Kohl & Neuman [Page 103] RFC 1510 Kerberos September 1993
コールとヌーマン[103ページ]のRFCの1510のケルベロスの1993年9月
req.padata.authenticator.subkey;
else resp.enc-part := encrypt OCTET STRING
using use_etype, tgt.key;
req.padata.authenticator.subkey。 ほかに、resp.enc-パート:=は使用_etype、tgt.keyを使用することでOCTET STRINGをコード化します。
send(resp);
(resp)を送ってください。
A.7. KRB_TGS_REP verification
decode response into resp;
A.7。 KRB_TGS_REP検証は応答をrespに解読します。
if (resp.msg-type = KRB_ERROR) then
process_error(resp);
return;
endif
(resp.msg-タイプ=KRB_ERROR)であるなら、_誤り(resp)を処理してください。 戻ってください。 endif
/* On error, discard the response, and zero the session key from
the response immediately */
/、*誤りのときに、応答を捨ててくださいといって、すぐに応答によって主要なセッションのゼロを合わせてください、*/
if (req.padata.authenticator.subkey)
unencrypted part of resp :=
decode of decrypt of resp.enc-part
using resp.enc-part.etype and subkey;
else unencrypted part of resp :=
decode of decrypt of resp.enc-part
using resp.enc-part.etype and tgt's session key;
if (common_as_rep_tgs_rep_checks fail) then
destroy resp.key;
return error;
endif
(req.padata.authenticator.subkey)が:=が解読するrespの一部を非コード化した、resp.enc-part.etypeを使用して、サブキーはresp.enc-部分を解読します。 resp:=のほかの非コード化された部分が解読する、resp.enc-part.etypeを使用して、tgtのセッションキーはresp.enc-部分を解読します。 (_レップ_チェックが失敗するレップ_tgs_としての一般的な_)であるなら、resp.keyを破壊してください。 誤りを返してください。 endif
check authorization_data as necessary;
save_for_later(ticket,session,client,server,times,flags);
必要に応じて認可_データをチェックしてください。 後で_のために_を取っておいてください(チケット(セッション、クライアント、サーバ、回)は弛みます)。
A.8. Authenticator generation
body.authenticator-vno := authenticator vno; /* = 5 */
body.cname, body.crealm := client name;
if (supplying checksum) then
body.cksum := checksum;
endif
get system_time;
body.ctime, body.cusec := system_time;
if (selecting sub-session key) then
select sub-session key;
body.subkey := sub-session key;
endif
if (using sequence numbers) then
select initial sequence number;
body.seq-number := initial sequence;
endif
A.8。 固有識別文字世代body.authenticator-vno:=固有識別文字vno。 /*は5*/body.cname、body.crealm:=クライアント名と等しいです。 次に、(チェックサムを供給します)body.cksum:=チェックサムであるなら。 endifはシステム_時間を得ます。 body.ctime、body.cusec:=システム_時間。 (サブセッションキーを選択します)その時なら、サブセッションキーを選択してください。 body.subkey:=サブセッションキー。 endifは(一連番号を使用します)その時なら初期シーケンス番号を選択します。 body.seq-数の:=は系列に頭文字をつけます。 endif
Kohl & Neuman [Page 104] RFC 1510 Kerberos September 1993
コールとヌーマン[104ページ]のRFCの1510のケルベロスの1993年9月
A.9. KRB_AP_REQ generation
obtain ticket and session_key from cache;
A.9。 KRB_AP_REQ世代はキャッシュから主要なチケットとセッション_を得ます。
packet.pvno := protocol version; /* 5 */
packet.msg-type := message type; /* KRB_AP_REQ */
packet.pvno:=プロトコルバージョン。 /*5packet.msg*/タイプ:=メッセージタイプ。 /*KRB_AP_REQ*/
if (desired(MUTUAL_AUTHENTICATION)) then
set packet.ap-options.MUTUAL-REQUIRED;
else
reset packet.ap-options.MUTUAL-REQUIRED;
endif
if (using session key for ticket) then
set packet.ap-options.USE-SESSION-KEY;
else
reset packet.ap-options.USE-SESSION-KEY;
endif
packet.ticket := ticket; /* ticket */
generate authenticator;
encode authenticator into OCTET STRING;
encrypt OCTET STRING into packet.authenticator
using session_key;
(必要(MUTUAL_AUTHENTICATION))であるなら、packet.ap-options.MUTUAL-REQUIREDを設定してください。 ほかのリセットpacket.ap-options.MUTUAL-REQUIRED。 endifは(チケットに、主要なセッションを使用します)その時ならpacket.ap-options.USE-SESSION-KEYを設定しました。 ほかのリセットpacket.ap-options.USE-SESSION-KEY。 endif packet.ticket:=チケット。 /*チケット*/は固有識別文字を発生させます。 固有識別文字をOCTET STRINGにコード化してください。 セッション_キーを使用することでOCTET STRINGをpacket.authenticatorにコード化してください。
A.10. KRB_AP_REQ verification
receive packet;
if (packet.pvno != 5) then
either process using other protocol spec
or error_out(KRB_AP_ERR_BADVERSION);
endif
if (packet.msg-type != KRB_AP_REQ) then
error_out(KRB_AP_ERR_MSG_TYPE);
endif
if (packet.ticket.tkt_vno != 5) then
either process using other protocol spec
or error_out(KRB_AP_ERR_BADVERSION);
endif
if (packet.ap_options.USE-SESSION-KEY is set) then
retrieve session key from ticket-granting ticket for
packet.ticket.{sname,srealm,enc-part.etype};
else
retrieve service key for
packet.ticket.{sname,srealm,enc-part.etype,enc-part.skvno};
endif
if (no_key_available) then
if (cannot_find_specified_skvno) then
error_out(KRB_AP_ERR_BADKEYVER);
else
error_out(KRB_AP_ERR_NOKEY);
endif
A.10。 KRB_AP_REQ検証はパケットを受けます。 次に、(packet.pvno!=5)は他のプロトコル仕様を使用することで処理されるか、そして、(KRB_AP_ERR_BADVERSION)からの誤り_。 endif、(_KRB_AP_ERR_エムエスジーTYPE)からの次に、(packet.msg-タイプ!=KRB_AP_REQ)誤り_であるなら。 次に、(packet.ticket.tkt_vno!=5)がもう一方を使用することで処理されるなら、endifは_外(KRB_AP_ERR_BADVERSION)で仕様か誤りについて議定書の中で述べます。 endifは(packet.ap_options.USE-SESSION-KEYは用意ができています)その時ならpacket.ticket sname、srealm、enc-part.etypeのチケットを与えるチケットからセッションキーを検索します。 ほか、packet.ticket sname、srealm、enc-part.etype、enc-part.skvnoに、主要なサービスを検索してください。 次に、(利用可能な_キーがない_)であるなら次に、(skvnoすることができません_が、_指定された_がわかる)誤りであるなら_外(KRB_AP_ERR_BADKEYVER)でendifする、。 (KRB_AP_ERR_NOKEY)からのほかの誤り_。 endif
Kohl & Neuman [Page 105] RFC 1510 Kerberos September 1993
コールとヌーマン[105ページ]のRFCの1510のケルベロスの1993年9月
endif
decrypt packet.ticket.enc-part into decr_ticket
using retrieved key;
if (decryption_error()) then
error_out(KRB_AP_ERR_BAD_INTEGRITY);
endif
decrypt packet.authenticator into decr_authenticator
using decr_ticket.key;
if (decryption_error()) then
error_out(KRB_AP_ERR_BAD_INTEGRITY);
endif
if (decr_authenticator.{cname,crealm} !=
decr_ticket.{cname,crealm}) then
error_out(KRB_AP_ERR_BADMATCH);
endif
if (decr_ticket.caddr is present) then
if (sender_address(packet) is not in decr_ticket.caddr)
then error_out(KRB_AP_ERR_BADADDR);
endif
elseif (application requires addresses) then
error_out(KRB_AP_ERR_BADADDR);
endif
if (not in_clock_skew(decr_authenticator.ctime,
decr_authenticator.cusec)) then
error_out(KRB_AP_ERR_SKEW);
endif
if (repeated(decr_authenticator.{ctime,cusec,cname,crealm}))
then error_out(KRB_AP_ERR_REPEAT);
endif
save_identifier(decr_authenticator.{ctime,cusec,cname,crealm});
get system_time;
if ((decr_ticket.starttime-system_time > CLOCK_SKEW) or
(decr_ticket.flags.INVALID is set)) then
/* it hasn't yet become valid */
error_out(KRB_AP_ERR_TKT_NYV);
endif
if (system_time-decr_ticket.endtime > CLOCK_SKEW) then
error_out(KRB_AP_ERR_TKT_EXPIRED);
endif
/* caller must check decr_ticket.flags for any pertinent */
/* details */
return(OK, decr_ticket, packet.ap_options.MUTUAL-REQUIRED);
endifは_チケット使用が検索したdecrへのpacket.ticket.enc-部分キーを解読します。 ((KRB_AP_ERR_BAD_INTEGRITY)からの復号化_誤り())次に、誤り_。 endifはdecr_ticket.keyを使用することでdecr_固有識別文字にpacket.authenticatorを解読します。 ((KRB_AP_ERR_BAD_INTEGRITY)からの復号化_誤り())次に、誤り_。 endif、(decr_固有識別文字cname、crealm、cname、crealm) =decr_チケット(KRB_AP_ERR_BADMATCH)からの次に、誤り_。 (decr_ticket.caddrは存在しています)その時なら(KRB_AP_ERR_BADADDR)からの次に、(送付者_アドレス(パケット)がdecr_ticket.caddrにありません)誤り_であるならendifする、。 (KRB_AP_ERR_BADADDR)からのendif elseif(アプリケーションはアドレスを必要とする)の当時の誤り_。 endif、(KRB_AP_ERR_SKEW)からの(コネ_時計_斜行(decr_authenticator.ctime、decr_authenticator.cusec)でない)次に、誤り_であるなら。 (KRB_AP_ERR_REPEAT)からのendifな、しかし、(繰り返しにされる(decr_固有識別文字ctime、キューセック、cname、crealm))の当時の誤り_。 endifは_識別子(decr_固有識別文字ctime、キューセック、cname、crealm)を保存します。 システム_時間を得てください。 *(decr_ticket.starttimeシステム_時間>CLOCK_SKEW)か次に、(decr_ticket.flags.INVALIDは用意ができています)/であるなら、_外でまだ有効な*/誤りになっていません(KRB_AP_ERR_TKT_NYV)。 endif、(KRB_AP_ERR_TKT_EXPIRED)からの次に、(システム_時間decrな_ticket.endtime>CLOCK_SKEW)誤り_であるなら。 endif/*訪問者はどんな適切な*//*詳細*/リターンがないかどうかdecr_ticket.flagsをチェックしなければなりません(OK、decr_チケット、packet.ap_options.MUTUAL-REQUIRED)。
A.11. KRB_AP_REP generation
packet.pvno := protocol version; /* 5 */
packet.msg-type := message type; /* KRB_AP_REP */
body.ctime := packet.ctime;
body.cusec := packet.cusec;
A.11。 KRB_AP_REP世代packet.pvno:=プロトコルバージョン。 /*5packet.msg*/タイプ:=メッセージタイプ。 /*KRB_AP_REP*/body.ctime:=packet.ctime。 body.cusec:=packet.cusec。
Kohl & Neuman [Page 106] RFC 1510 Kerberos September 1993
コールとヌーマン[106ページ]のRFCの1510のケルベロスの1993年9月
if (selecting sub-session key) then
select sub-session key;
body.subkey := sub-session key;
endif
if (using sequence numbers) then
select initial sequence number;
body.seq-number := initial sequence;
endif
(サブセッションキーを選択します)その時なら、サブセッションキーを選択してください。 body.subkey:=サブセッションキー。 endifは(一連番号を使用します)その時なら初期シーケンス番号を選択します。 body.seq-数の:=は系列に頭文字をつけます。 endif
encode body into OCTET STRING;
ボディーをOCTET STRINGにコード化してください。
select encryption type;
encrypt OCTET STRING into packet.enc-part;
暗号化タイプを選んでください。 packet.enc-部分にOCTET STRINGをコード化してください。
A.12. KRB_AP_REP verification
receive packet;
if (packet.pvno != 5) then
either process using other protocol spec
or error_out(KRB_AP_ERR_BADVERSION);
endif
if (packet.msg-type != KRB_AP_REP) then
error_out(KRB_AP_ERR_MSG_TYPE);
endif
cleartext := decrypt(packet.enc-part)
using ticket's session key;
if (decryption_error()) then
error_out(KRB_AP_ERR_BAD_INTEGRITY);
endif
if (cleartext.ctime != authenticator.ctime) then
error_out(KRB_AP_ERR_MUT_FAIL);
endif
if (cleartext.cusec != authenticator.cusec) then
error_out(KRB_AP_ERR_MUT_FAIL);
endif
if (cleartext.subkey is present) then
save cleartext.subkey for future use;
endif
if (cleartext.seq-number is present) then
save cleartext.seq-number for future verifications;
endif
return(AUTHENTICATION_SUCCEEDED);
A.12。 KRB_AP_REP検証はパケットを受けます。 次に、(packet.pvno!=5)は他のプロトコル仕様を使用することで処理されるか、そして、(KRB_AP_ERR_BADVERSION)からの誤り_。 endif、(_KRB_AP_ERR_エムエスジーTYPE)からの次に、(packet.msg-タイプ!=KRB_AP_REP)誤り_であるなら。 endif cleartext:=はチケットのセッションキーを使用することで(packet.enc-部分)を解読します。 ((KRB_AP_ERR_BAD_INTEGRITY)からの復号化_誤り())次に、誤り_。 endif、(KRB_AP_ERR_MUT_FAIL)からの次に、(cleartext.ctime!はauthenticator.ctimeと等しいです)誤り_であるなら。 endif、(KRB_AP_ERR_MUT_FAIL)からの次に、(cleartext.cusec!はauthenticator.cusecと等しいです)誤り_であるなら。 endifは(cleartext.subkeyは存在しています)その時なら今後の使用のためにcleartext.subkeyを取っておきます。 endifは(cleartext.seq-数は存在しています)その時なら将来の検証のcleartext.seq-数を節約します。 endifリターン(AUTHENTICATION_SUCCEEDED)。
A.13. KRB_SAFE generation
collect user data in buffer;
A.13。 バッファのKRB_SAFEの世代の料金先方払いの利用者データ。
/* assemble packet: */
packet.pvno := protocol version; /* 5 */
packet.msg-type := message type; /* KRB_SAFE */
/*はパケットを組み立てます: */packet.pvno:=プロトコルバージョン。 /*5packet.msg*/タイプ:=メッセージタイプ。 /*KRBの_の安全な*/
Kohl & Neuman [Page 107] RFC 1510 Kerberos September 1993
コールとヌーマン[107ページ]のRFCの1510のケルベロスの1993年9月
body.user-data := buffer; /* DATA */
if (using timestamp) then
get system_time;
body.timestamp, body.usec := system_time;
endif
if (using sequence numbers) then
body.seq-number := sequence number;
endif
body.s-address := sender host addresses;
if (only one recipient) then
body.r-address := recipient host address;
endif
checksum.cksumtype := checksum type;
compute checksum over body;
checksum.checksum := checksum value; /* checksum.checksum */
packet.cksum := checksum;
packet.safe-body := body;
body.user-data:=バッファ。 /*DATA*/は(タイムスタンプを使用します)その時ならシステム_時間を得ます。 body.timestamp、body.usec:=システム_時間。 endifは(一連番号を使用します)その時なら:=一連番号にbody.seq付番します。 endif body.s-アドレス:=送付者ホスト・アドレス。 (1人の受取人だけ)当時のbody.r-アドレス:=受取人であるなら、アドレスをホスティングしてください。 endif checksum.cksumtype:=チェックサムタイプ。 ボディーの上でチェックサムを計算してください。 checksum.checksum:=チェックサム価値。 /*checksum.checksum*/packet.cksum:=チェックサム。 packet.safe-ボディー:=ボディー。
A.14. KRB_SAFE verification
receive packet;
if (packet.pvno != 5) then
either process using other protocol spec
or error_out(KRB_AP_ERR_BADVERSION);
endif
if (packet.msg-type != KRB_SAFE) then
error_out(KRB_AP_ERR_MSG_TYPE);
endif
if (packet.checksum.cksumtype is not both collision-proof
and keyed) then
error_out(KRB_AP_ERR_INAPP_CKSUM);
endif
if (safe_priv_common_checks_ok(packet)) then
set computed_checksum := checksum(packet.body);
if (computed_checksum != packet.checksum) then
error_out(KRB_AP_ERR_MODIFIED);
endif
return (packet, PACKET_IS_GENUINE);
else
return common_checks_error;
endif
A.14。 KRB_SAFE検証はパケットを受けます。 次に、(packet.pvno!=5)は他のプロトコル仕様を使用することで処理されるか、そして、(KRB_AP_ERR_BADVERSION)からの誤り_。 endif、(_KRB_AP_ERR_エムエスジーTYPE)からの次に、(packet.msg-タイプ!=KRB_SAFE)誤り_であるなら。 endif、(KRB_AP_ERR_INAPP_CKSUM)からの次に、(packet.checksum.cksumtypeはともに衝突耐なくて合わせられます)誤り_であるなら。 次に、endifは(安全な_priv_一般的な_チェック_OK(パケット))であるなら計算された_チェックサム:=チェックサムを設定しました(packet.body)。 (KRB_AP_ERR_MODIFIED)からの次に、(_チェックサム!=packet.checksumを計算します)誤り_であるなら。 endifリターン(パケット、PACKET_は_GENUINEです)。 ほかのリターンの一般的な_は_誤りをチェックします。 endif
A.15. KRB_SAFE and KRB_PRIV common checks
if (packet.s-address != O/S_sender(packet)) then
/* O/S report of sender not who claims to have sent it */
error_out(KRB_AP_ERR_BADADDR);
endif
if ((packet.r-address is present) and
(packet.r-address != local_host_address)) then
A.15。 KRB_SAFEとKRB_PRIVの一般的なチェックが次に、(packet.s-アドレス!=OS_送付者(パケット))/*OSであるなら送付者について報告する、だれが、_外(KRB_AP_ERR_BADADDR)で*/誤りをそれに送ったと主張するか。 endif、(packet.r-アドレスは存在しています)、(packet.r-アドレス!=ローカルの_ホスト_アドレス)その時
Kohl & Neuman [Page 108] RFC 1510 Kerberos September 1993
コールとヌーマン[108ページ]のRFCの1510のケルベロスの1993年9月
/* was not sent to proper place */
error_out(KRB_AP_ERR_BADADDR);
endif
if (((packet.timestamp is present) and
(not in_clock_skew(packet.timestamp,packet.usec))) or
(packet.timestamp is not present and timestamp expected))
then error_out(KRB_AP_ERR_SKEW);
endif
if (repeated(packet.timestamp,packet.usec,packet.s-address))
then error_out(KRB_AP_ERR_REPEAT);
endif
if (((packet.seq-number is present) and
((not in_sequence(packet.seq-number)))) or
(packet.seq-number is not present and sequence expected))
then error_out(KRB_AP_ERR_BADORDER);
endif
if (packet.timestamp not present and
packet.seq-number not present) then
error_out(KRB_AP_ERR_MODIFIED);
endif
*が送られなかった/は*/誤り_の適切に家を見つけます(KRB_AP_ERR_BADADDR)。 そして、endif、(packet.timestampは存在しています)、((KRB_AP_ERR_SKEW)からのコネ_時計_斜行(packet.timestamp、packet.usec)か(packet.timestampは現在でなくてタイムスタンプ期待しています)当時の誤り_でない。 (KRB_AP_ERR_REPEAT)からのendifな、しかし、(繰り返しにされる(packet.timestamp、packet.usec、packet.sアドレス))の当時の誤り_。 そして、endif、(packet.seq-数は存在しています)、((KRB_AP_ERR_BADORDER)からのコネ_系列(packet.seq-数)でない次に、(packet.seq-数は、プレゼントとまたは予想された系列ではありません)誤り_でない。 endif、(KRB_AP_ERR_MODIFIED)からの次に、(プレゼントとどんなpacket.seq-数も寄贈しないpacket.timestamp)誤り_であるなら。 endif
save_identifier(packet.{timestamp,usec,s-address},
sender_principal(packet));
_識別子を保存してください、(パケットタイムスタンプ、usec、sアドレス、送付者_校長(パケット)。
return PACKET_IS_OK;
リターンPACKET_はOKに_です。
A.16. KRB_PRIV generation
collect user data in buffer;
A.16。 バッファのKRB_PRIVの世代の料金先方払いの利用者データ。
/* assemble packet: */
packet.pvno := protocol version; /* 5 */
packet.msg-type := message type; /* KRB_PRIV */
/*はパケットを組み立てます: */packet.pvno:=プロトコルバージョン。 /*5packet.msg*/タイプ:=メッセージタイプ。 /*KRB_PRIV*/
packet.enc-part.etype := encryption type;
packet.enc-part.etype:=暗号化タイプ。
body.user-data := buffer;
if (using timestamp) then
get system_time;
body.timestamp, body.usec := system_time;
endif
if (using sequence numbers) then
body.seq-number := sequence number;
endif
body.s-address := sender host addresses;
if (only one recipient) then
body.r-address := recipient host address;
endif
body.user-data:=バッファ。 (使用タイムスタンプ)であるなら、システム_時間を得てください。 body.timestamp、body.usec:=システム_時間。 endifは(一連番号を使用します)その時なら:=一連番号にbody.seq付番します。 endif body.s-アドレス:=送付者ホスト・アドレス。 (1人の受取人だけ)当時のbody.r-アドレス:=受取人であるなら、アドレスをホスティングしてください。 endif
Kohl & Neuman [Page 109] RFC 1510 Kerberos September 1993
コールとヌーマン[109ページ]のRFCの1510のケルベロスの1993年9月
encode body into OCTET STRING;
ボディーをOCTET STRINGにコード化してください。
select encryption type;
encrypt OCTET STRING into packet.enc-part.cipher;
暗号化タイプを選んでください。 OCTET STRINGをpacket.enc-part.cipherにコード化してください。
A.17. KRB_PRIV verification
receive packet;
if (packet.pvno != 5) then
either process using other protocol spec
or error_out(KRB_AP_ERR_BADVERSION);
endif
if (packet.msg-type != KRB_PRIV) then
error_out(KRB_AP_ERR_MSG_TYPE);
endif
A.17。 KRB_PRIV検証はパケットを受けます。 次に、(packet.pvno!=5)は他のプロトコル仕様を使用することで処理されるか、そして、(KRB_AP_ERR_BADVERSION)からの誤り_。 endif、(_KRB_AP_ERR_エムエスジーTYPE)からの次に、(packet.msg-タイプ!=KRB_PRIV)誤り_であるなら。 endif
cleartext := decrypt(packet.enc-part) using negotiated key;
if (decryption_error()) then
error_out(KRB_AP_ERR_BAD_INTEGRITY);
endif
cleartext:=は交渉されたキーを使用することで(packet.enc-部分)を解読します。 ((KRB_AP_ERR_BAD_INTEGRITY)からの復号化_誤り())次に、誤り_。 endif
if (safe_priv_common_checks_ok(cleartext)) then
return(cleartext.DATA, PACKET_IS_GENUINE_AND_UNMODIFIED);
else
return common_checks_error;
endif
(安全な_priv_一般的な_チェック_OK(cleartext))であるなら、戻ってくださいcleartext.DATA、PACKET_は_GENUINE_と(_UNMODIFIEDです)。 ほかのリターンの一般的な_は_誤りをチェックします。 endif
A.18. KRB_CRED generation
invoke KRB_TGS; /* obtain tickets to be provided to peer */
A.18。 KRB_CRED世代はKRB_TGSを呼び出します。 /*は、同輩*/に提供するためにチケットを得ます。
/* assemble packet: */
packet.pvno := protocol version; /* 5 */
packet.msg-type := message type; /* KRB_CRED */
/*はパケットを組み立てます: */packet.pvno:=プロトコルバージョン。 /*5packet.msg*/タイプ:=メッセージタイプ。 /*KRB_信用*/
for (tickets[n] in tickets to be forwarded) do
packet.tickets[n] = tickets[n].ticket;
done
(進められるチケットの中のチケット[n])に関しては、packet.tickets[n]=チケット[n].ticketをしてください。 します。
packet.enc-part.etype := encryption type;
packet.enc-part.etype:=暗号化タイプ。
for (ticket[n] in tickets to be forwarded) do
body.ticket-info[n].key = tickets[n].session;
body.ticket-info[n].prealm = tickets[n].crealm;
body.ticket-info[n].pname = tickets[n].cname;
body.ticket-info[n].flags = tickets[n].flags;
body.ticket-info[n].authtime = tickets[n].authtime;
body.ticket-info[n].starttime = tickets[n].starttime;
body.ticket-info[n].endtime = tickets[n].endtime;
body.ticket-info[n].renew-till = tickets[n].renew-till;
(進められるチケットの中のチケット[n])に関しては、[n] body.ticket-インフォメーション.key=チケット[n].sessionをしてください。 body.ticket-インフォメーション[n].prealmはチケット[n].crealmと等しいです。 body.ticket-インフォメーション[n].pnameはチケット[n].cnameと等しいです。 body.ticket-インフォメーション[n].flagsはチケット[n].flagsと等しいです。 body.ticket-インフォメーション[n].authtimeはチケット[n].authtimeと等しいです。 body.ticket-インフォメーション[n].starttimeはチケット[n].starttimeと等しいです。 body.ticket-インフォメーション[n].endtimeはチケット[n].endtimeと等しいです。 body.ticketインフォメーション[n].renew現金箱=は[n] .renew-現金箱にレッテルをはります。
Kohl & Neuman [Page 110] RFC 1510 Kerberos September 1993
コールとヌーマン[110ページ]のRFCの1510のケルベロスの1993年9月
body.ticket-info[n].srealm = tickets[n].srealm;
body.ticket-info[n].sname = tickets[n].sname;
body.ticket-info[n].caddr = tickets[n].caddr;
done
body.ticket-インフォメーション[n].srealmはチケット[n].srealmと等しいです。 body.ticket-インフォメーション[n].snameはチケット[n].snameと等しいです。 body.ticket-インフォメーション[n].caddrはチケット[n].caddrと等しいです。 します。
get system_time;
body.timestamp, body.usec := system_time;
システム_時間を得てください。 body.timestamp、body.usec:=システム_時間。
if (using nonce) then
body.nonce := nonce;
endif
次に、(一回だけを使用します)body.nonce:=一回だけであるなら。 endif
if (using s-address) then
body.s-address := sender host addresses;
endif
if (limited recipients) then
body.r-address := recipient host address;
endif
次に、(s-アドレスを使用します)body.s-アドレス:=送付者であるなら、アドレスをホスティングしてください。 次に、(限られた受取人)が:=受取人にbody.r演説するなら、endifはアドレスをホスティングします。 endif
encode body into OCTET STRING;
ボディーをOCTET STRINGにコード化してください。
select encryption type;
encrypt OCTET STRING into packet.enc-part.cipher
using negotiated encryption key;
暗号化タイプを選んでください。 交渉された暗号化キーを使用することでOCTET STRINGをpacket.enc-part.cipherにコード化してください。
A.19. KRB_CRED verification
receive packet;
if (packet.pvno != 5) then
either process using other protocol spec
or error_out(KRB_AP_ERR_BADVERSION);
endif
if (packet.msg-type != KRB_CRED) then
error_out(KRB_AP_ERR_MSG_TYPE);
endif
A.19。 KRB_CRED検証はパケットを受けます。 次に、(packet.pvno!=5)は他のプロトコル仕様を使用することで処理されるか、そして、(KRB_AP_ERR_BADVERSION)からの誤り_。 endif、(_KRB_AP_ERR_エムエスジーTYPE)からの次に、(packet.msg-タイプ!=KRB_CRED)誤り_であるなら。 endif
cleartext := decrypt(packet.enc-part) using negotiated key;
if (decryption_error()) then
error_out(KRB_AP_ERR_BAD_INTEGRITY);
endif
if ((packet.r-address is present or required) and
(packet.s-address != O/S_sender(packet)) then
/* O/S report of sender not who claims to have sent it */
error_out(KRB_AP_ERR_BADADDR);
endif
if ((packet.r-address is present) and
(packet.r-address != local_host_address)) then
/* was not sent to proper place */
error_out(KRB_AP_ERR_BADADDR);
cleartext:=は交渉されたキーを使用することで(packet.enc-部分)を解読します。 ((KRB_AP_ERR_BAD_INTEGRITY)からの復号化_誤り())次に、誤り_。 そして、(存在しているか、または必要であるpacket.r-アドレス)と次に(packet.s-アドレス!=OS_送付者(パケット))/*OSが送付者について報告するならendifする、だれが、_外(KRB_AP_ERR_BADADDR)でendifに*/誤りをそれに送ったと主張するか、(packet.r-アドレスは存在しています)、(packet.r-アドレス!=ローカル_ホスト_アドレス)) 次に、/*は_外(KRB_AP_ERR_BADADDR)で適所*/誤りに送られませんでした。
Kohl & Neuman [Page 111] RFC 1510 Kerberos September 1993
コールとヌーマン[111ページ]のRFCの1510のケルベロスの1993年9月
endif
if (not in_clock_skew(packet.timestamp,packet.usec)) then
error_out(KRB_AP_ERR_SKEW);
endif
if (repeated(packet.timestamp,packet.usec,packet.s-address))
then error_out(KRB_AP_ERR_REPEAT);
endif
if (packet.nonce is required or present) and
(packet.nonce != expected-nonce) then
error_out(KRB_AP_ERR_MODIFIED);
endif
endif、(KRB_AP_ERR_SKEW)からの(コネ_時計_斜行(packet.timestamp、packet.usec)でない)次に、誤り_であるなら。 (KRB_AP_ERR_REPEAT)からのendifな、しかし、(繰り返しにされる(packet.timestamp、packet.usec、packet.sアドレス))の当時の誤り_。 そして、endif、(packet.nonceは必要であるか、または存在しています)、(KRB_AP_ERR_MODIFIED)からの(期待しているpacket.nonce!=一回だけ)次に、誤り_。 endif
for (ticket[n] in tickets that were forwarded) do
save_for_later(ticket[n],key[n],principal[n],
server[n],times[n],flags[n]);
return
(進められたチケットの中のチケット[n])に関して後で_のために_を取っておいてください。(チケット[n](主要な[n]、校長[n]、サーバ[n]、回[n])は[n])に旗を揚げさせます。 リターン
A.20. KRB_ERROR generation
A.20。 KRB_エラー生成
/* assemble packet: */
packet.pvno := protocol version; /* 5 */
packet.msg-type := message type; /* KRB_ERROR */
/*はパケットを組み立てます: */packet.pvno:=プロトコルバージョン。 /*5packet.msg*/タイプ:=メッセージタイプ。 /*KRB_誤り*/
get system_time;
packet.stime, packet.susec := system_time;
packet.realm, packet.sname := server name;
システム_時間を得てください。 packet.stime、packet.susec:=システム_時間。 packet.realm、packet.sname:=サーバー名。
if (client time available) then
packet.ctime, packet.cusec := client_time;
endif
packet.error-code := error code;
if (client name available) then
packet.cname, packet.crealm := client name;
endif
if (error text available) then
packet.e-text := error text;
endif
if (error data available) then
packet.e-data := error data;
endif
次に、(空いているクライアント時間)packet.ctimeであるなら、packet.cusec:=クライアント_時間です。 endif packet.error-code:=エラーコード。 (クライアント名の利用可能)の当時のpacket.cnameであるなら、packet.crealm:=クライアント名です。 endifな、しかし、(誤りテキスト利用可能)の当時のpacket.e-テキスト:=誤りテキスト。 endifな、しかし、(エラー・データ利用可能)の当時のpacket.e-データ:=エラー・データ。 endif
Kohl & Neuman [Page 112]
コールとヌーマン[112ページ]
一覧
スポンサーリンク
