RFC1507 日本語訳
1507 DASS - Distributed Authentication Security Service. C. Kaufman. September 1993. (Format: TXT=287809 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group C. Kaufman
Request for Comments: 1507 Digital Equipment Corporation
September 1993
コメントを求めるワーキンググループC.コーフマン要求をネットワークでつないでください: 1507 DEC1993年9月
DASS
Distributed Authentication Security Service
ダスは認証セキュリティー・サービスを広げました。
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard. Discussion and suggestions for improvement are requested. 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.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはインターネット標準を指定しません。 議論と改善提案は要求されています。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Table of Contents
目次
1. Introduction ................................................ 2
1.1 What is DASS? .......................................... 2
1.2 Central Concepts ....................................... 4
1.3 What This Document Won't Tell You ..................... 11
1.4 The Relationship between DASS and ISO Standards ....... 17
1.5 An Authentication Walkthrough ......................... 20
2. Services Used .............................................. 25
2.1 Time Service .......................................... 25
2.2 Random Numbers ........................................ 26
2.3 Naming Service ........................................ 26
3. Services Provided .......................................... 37
3.1 Certificate Contents .................................. 38
3.2 Encrypted Private Key Structure ....................... 40
3.3 Authentication Tokens ................................. 40
3.4 Credentials ........................................... 43
3.5 CA State .............................................. 47
3.6 Data types used in the routines ....................... 47
3.7 Error conditions ...................................... 49
3.8 Certificate Maintenance Functions ..................... 49
3.9 Credential Maintenance Functions ...................... 55
3.10 Authentication Procedures ............................. 63
3.11 DASSlessness Determination Functions .................. 87
4. Certificate and message formats ............................ 89
4.1 ASN.1 encodings ....................................... 89
4.2 Encoding Rules ........................................ 96
4.3 Version numbers and forward compatibility ............. 96
4.4 Cryptographic Encodings ............................... 97
Annex A - Typical Usage ........................................ 101
A.1 Creating a CA ........................................ 101
1. 序論… 2 1.1 ダスは者ですか? .......................................... 2 1.2の主要な概念… 4 1.3 これが記録することはあなたに言わないでしょう… 11 1.4 ダスとISO規格との関係… 17 1.5 認証ウォークスルー… 20 2. 利用されたサービス… 25 2.1時間指定サービス… 25 2.2 無作為の数… 26 2.3名前付けサービス… 26 3. サービスは提供されました… 37 3.1 コンテンツを証明してください… 38 3.2 秘密鍵構造を暗号化します… 40 3.3 認証トークン… 40 3.4の資格証明書… 43 3.5 カリフォルニア州… 47 ルーチンに使用される3.6のデータ型… 47 3.7のエラー条件… 49 3.8 メインテナンス機能を証明してください… 49 3.9 資格証明メインテナンスは機能します… 55 3.10 認証手順… 63 3.11に、DASSlessness決断は機能します… 87 4. 証明書とメッセージ形式… 89 4.1 ASN.1encodings… 89 4.2 コード化は統治されます… 96 4.3 バージョン番号と前進の互換性… 96 4.4 暗号のEncodings… 97はAを付加します--典型的な用法。 カリフォルニアを作成する101A.1… 101
Kaufman [Page 1] RFC 1507 DASS September 1993
コーフマン[1ページ]RFC1507ダス1993年9月
A.2 Creating a User Principal ............................ 102
A.3 Creating a Server Principal .......................... 103
A.4 Booting a Server Principal ........................... 103
A.5 A user logs on to the network ........................ 103
A.6 An Rlogin (TCP/IP) connection is made ................ 104
A.7 A Transport-Independent Connection ................... 104
Annex B - Support of the GSSAPI ................................ 104
B.1 Summary of GSSAPI .................................... 105
B.2 Implementation of GSSAPI over DASS ................... 106
B.3 Syntax ............................................... 110
Annex C - Imported ASN.1 definitions ........................... 112
Glossary ....................................................... 114
Security Considerations ......................................... 119
Author's Address ................................................ 119
Figures
Figure 1 - Authentication Exchange Overview .................... 24
ユーザ元本を創造するA.2… サーバ元本を創造する102A.3… サーバ元本をブートする103A.4… ユーザがネットワークにログオンする103A.5… Rlogin(TCP/IP)接続が作られている103A.6… 104 A.7のA輸送から独立している接続… 104はBを付加します--GSSAPIのサポート。 GSSAPIの104B.1概要… ダスの上のGSSAPIの105B.2実装… 106B.3構文… 110はCを付加します--ASN.1定義であるとインポートされます… 112用語集… 114 セキュリティ問題… 119作者のアドレス… 119の数字が1について計算します--認証交換概要。 24
1. Introduction
1. 序論
1.1 What is DASS?
1.1 ダスは者ですか?
Authentication is a security service. The goal of authentication is to reliably learn the name of the originator of a message or request. The classic way by which people authenticate to computers (and by which computers authenticate to one another) is by supplying a password. There are a number of problems with existing password based schemes which DASS attempts to solve. The goal of DASS is to provide authentication services in a distributed environment which are both more secure (more difficult for a bad guy to impersonate a good guy) and easier to use than existing mechanisms.
認証はセキュリティー・サービスです。 認証の目標はメッセージか要求の創始者の名前を確かに学ぶことです。 古典的な方法で、人々がコンピュータ(そしてコンピュータがお互いに認証するもので)に認証するものが、パスワードを提供することによって、あります。 ダスが解決するのを試みる既存のパスワードに基づいている体系に関する多くの問題があります。 ダスの目標は分散環境で、より安全で、かつ(悪者がいい人をまねるより難しい)既存のメカニズムより使用に簡単な認証サービスを提供することです。
In a distributed environment, authentication is particularly challenging. Users do not simply log on to one machine and use resources there. Users start processes on one machine which may request services on another. In some cases, the second system must request services from a third system on behalf of the user. Further, given current network technology, it is fairly easy to eavesdrop on conversations between computers and pick up any passwords that might be going by.
分散環境で、認証は特にやりがいがあります。 ユーザはそこに1台のマシンと使用にリソースを絶対に登録しません。 ユーザは別のものでサービスを要求するかもしれない1台のマシンにプロセスを始めます。 いくつかの場合、2番目のシステムはユーザを代表して3番目のシステムからサービスを要求しなければなりません。 現在のネットワーク技術を考えて、さらに、コンピュータでの会話を立ち聞きして、過ぎているどんなパスワードも受信するのはかなり簡単です。
DASS uses cryptographic mechanisms to provide "strong, mutual" authentication. Mutual authentication means that the two parties communicating each reliably learn the name of the other. Strong authentication means that in the exchange neither obtains any information that it could use to impersonate the other to a third party. This can't be done with passwords alone. Mutual authentication can be done with passwords by having a "sign" and a "counter-sign" which the two parties must utter to assure one another
ダスは、「強く、互い」の認証を提供するのに暗号のメカニズムを使用します。 互いの認証は、それぞれを伝える2回のパーティーがもう片方の名前を確かに学ぶことを意味します。 強い認証は、交換におけるそれがどちらも、それが第三者にもう片方をまねるのに使用できた少しの情報も得ないことを意味します。 パスワードが単独の状態でこれができません。 互いの認証は、パスワードで「サイン」を持っていることによってしていて2回のパーティーがお互いを保証するために発声しなければならない「副署」であることができます。
Kaufman [Page 2] RFC 1507 DASS September 1993
コーフマン[2ページ]RFC1507ダス1993年9月
of their identities. But whichever party speaks first reveals information which can be used by the second (unauthenticated) party to impersonate it. Longer sequences (often seen in spy movies) cannot solve the problem in general. Further, anyone who can eavesdrop on the conversation can impersonate either party in a subsequent conversation (unless passwords are only good once). Cryptography provides a means whereby one can prove knowledge of a secret without revealing it. People cannot execute cryptographic algorithms in their heads, and thus cannot strongly authenticate to computers directly. DASS lays the groundwork for "smart cards": microcomputers sealed in credit cards which when activated by a PIN will strongly authenticate to a computer. Until smart cards are available, the first link from a user to a DASS node remains vulnerable to eavesdropping. DASS mechanisms are constructed so that after the initial authentication, smart card or password based authentication looks the same.
彼らのアイデンティティについて。 しかし、最初に話すどのパーティーがそれをまねる秒で中古(非認証される)のパーティーであるかもしれない情報を明らかにするか。 より長い系列(スパイ映画でしばしば見られる)は一般に、問題を解決できません。 さらに、会話を立ち聞きできるだれでもその後の会話における何れの当事者をまねることができます(パスワードがかつて良いだけではないなら)。 暗号は1つがそれを明らかにしないで秘密に関する知識を立証できる手段を提供します。 その結果、人々は彼らの頭で暗号アルゴリズムを実行できません。強く、直接コンピュータに認証できません。 ダスは「スマートカード」のために土台を作ります: 暗証番号によって動かされると強くそうするクレジットカードで密封されたマイクロコンピュータはコンピュータに認証します。 スマートカードが利用可能になるまで、ユーザからダスノードへの最初のリンクは盗聴に被害を受け易いままで残っています。 ダスメカニズムが構成されるので、ベースの認証は初期の認証、スマートカードまたはパスワードの後に同じに見えます。
Today, systems are constructed to think of user identities in terms of accounts on individual computers. If I have accounts on ten machines, there is no way a priori to see that those ten accounts all belong to the same individual. If I want to be able to access a resource through any of the ten machines, I must tell the resource about all ten accounts. I must also tell the resource when I get an eleventh account.
今日、システムは、アカウントに関して個々のコンピュータでユーザアイデンティティを考えるために構成されます。 私が10台のマシンの上にアカウントを持っているなら、それらの10のアカウントがすべて、同じ個人のものであることを確認するために先験的などんな道もありません。 10台のマシンのどれかを通してリソースにアクセスできるようになりたいなら、私はすべての10のアカウントに関するリソースを言わなければなりません。 また、私は、いつ11番目のアカウントを得るかをリソースに言わなければなりません。
DASS supports the concept of global identity and network login. A user is assigned a name from a global namespace and that name will be recognized by any node in the network. (In some cases, a resource may be configured as accessible only by a particular user acting through a particular node. That is an access control decision, and it is supported by DASS, but the user is still known by his global identity). From a practical point of view, this means that a user can have a single password (or smart card) which can be used on all systems which allow him access and access control mechanisms can conveniently give access to a user through any computer the user happens to be logged into. Because a single user secret is good on all systems, it should never be necessary for a user to enter a password other than at initial login. Because cryptographic mechanisms are used, the password should never appear on the network beyond the initial login node.
ダスはグローバルなアイデンティティとネットワークログインの概念をサポートします。 名前はグローバルな名前空間からユーザに割り当てられます、そして、その名前はネットワークにおけるどんなノードによっても認識されるでしょう。 (いくつかの場合、リソースは単に特定のノードを通して行動している特定のユーザがアクセスしやすいとして構成されるかもしれません。 それはアクセス制御決定です、そして、それはダスによってサポートされますが、ユーザは彼のグローバルなアイデンティティによってまだ知られています。). 実用的な観点、ユーザが制御機構が便利に与えることができるアクセスとアクセスを彼に許すすべてのシステムの上で使用できるただ一つのパスワード(または、スマートカード)にユーザにアクセスさせることができるこの手段からどんなコンピュータまでも、ユーザはたまたまログインされます。 シングルユーザー秘密がすべてのシステムの上で良いので、ユーザが初期のログイン以外のパスワードを入力するのは決して必要であるべきではありません。 暗号のメカニズムが使用されているので、パスワードは初期のログインノードを超えたネットワークに決して現れるべきではありません。
DASS was designed as a component of the Distributed System Security Architecture (DSSA) (see "The Digital Distributed System Security Architecture" by M. Gasser, A. Goldstein, C. Kaufman, and B. Lampson, 1989 National Computer Security Conference). It is a goal of DSSA that access control on all systems be based on users' global names and the concept of "accounts" on computers eventually be replaced with unnamed rights to execute processes on those computers. Until
ダスはDistributed System Security Architecture(DSSA)の部品として設計されました。(M.ガッサー、A.ゴールドスティーン、C.コーフマン、およびB.ランプソンのそばで「デジタル分散システムセキュリティー体系」を見てください、1989年のNationalコンピュータSecurityコンファレンス). 結局、それは、すべてのシステムにおけるアクセスコントロールがユーザのグローバル名に基づいているDSSAの目標、そして、コンピュータの「アカウント」の概念です。それらのコンピュータでプロセスを実行する無名権利に取り替えます。 until
Kaufman [Page 3] RFC 1507 DASS September 1993
コーフマン[3ページ]RFC1507ダス1993年9月
this happens, computers will continue to support the concept of "local accounts" and access controls on resources on those systems will still be based on those accounts. There is today within the Berkeley rtools running over the Internet Protocol suite the concept of a ".rhosts database" which gives access to local accounts from remote accounts. We envision that those databases will be extended to support granting access to local accounts based on DASS global names as a bridge between the past and the future. DASS should greatly simplify the administration of those databases for the (presumably common) case where a user should be granted access to an account ignoring his choice of intermediate systems.
これは起こります、そして、コンピュータは、「ローカルのアカウント」の概念をサポートし続けるでしょう、そして、それでも、それらのシステムに関するリソースに関するアクセス制御はそれらのアカウントに基づくでしょう。 バークレーの中にインターネットプロトコルスイートの上でリモートアカウントからローカルのアカウントへのアクセスを与える「.rhostsデータベース」の概念を実行するrtoolsが今日、あります。 私たちはそれを思い描きます。それらのデータベースは、過去と未来の間で与えるのがブリッジとしてダスグローバル名に基づくローカルのアカウントへのアクセスであるとサポートするために拡張されているでしょう。 ダスは彼の中間システムの選択を無視するアカウントへのユーザのアクセスが承諾されるべきである(おそらく一般的)のケースのためのそれらのデータベースの管理を大いに簡素化するべきです。
1.2 Central Concepts
1.2 主要な概念
1.2.1 Strong Authentication with Public Keys
1.2.1 公開鍵との強い認証
DASS makes heavy use of the RSA Public Key cryptosystem. The important properties of the RSA algorithms for purposes of this discussion are:
ダスはRSA Public Key暗号系の重い使用をします。 この議論の目的のためのRSAアルゴリズムの重要な特性は以下の通りです。
- It supports the creation of a public/private key pair, where
operations with one key of the pair reverse the operations of
the other, but it is computationally infeasible to derive the
private key from the public key.
- それは1公衆/秘密鍵組の創設をサポートします。(組の1個のキーによる操作はもう片方の操作を逆にしますが、そこでは、公開鍵から秘密鍵を得るのは計算上実行不可能です)。
- It supports the "signing" of a message with the private key,
after which anyone knowing the public key can "verify" the
signature and know that it was constructed with knowledge of
the private key and that the message was not subsequently
altered.
- それは秘密鍵でメッセージの「署名」をサポートします。(その時、公開鍵を知っているだれでも、署名について「確かめ」て、それが秘密鍵に関する知識で組み立てられて、メッセージが次に変更されなかったのを知ることができました後)。
- It supports the "enciphering" of a message by anyone knowing
the public key such that only someone with knowledge of the
private key can recover the message.
- それは秘密鍵に関する知識をもっているだれかだけがメッセージを回復できるように公開鍵を知っているだれによるもメッセージの「暗号化」をサポートします。
With access to the RSA algorithms, it is easy to see how one could construct a "strong" authentication mechanism. Each "principal" (user or computer) would construct a public/private key pair, publish the public key, and keep secret the private key. To authenticate to you, I would write a message, sign it with my private key, and send it to you. You would verify the message using my public key and know the message came from me. If mutual authentication were desired, you could create an acknowledgment and sign it with your private key; I could verify it with your public key and I would know you received my message.
RSAアルゴリズムへのアクセスでは、1つがどう「強い」認証機構を構成するかもしれないかを見るのは簡単です。 各「主体」(ユーザかコンピュータ)は、公衆/秘密鍵組を構成して、公開鍵を発行して、秘密鍵を秘密にするでしょう。 認証する、Iは伝言を書いて、私の秘密鍵をそれと契約してください、そして、それを送ってください。 あなたは、私の公開鍵を使用することでメッセージについて確かめて、メッセージが私から来たのを知っているでしょう。 互いの認証が望まれているなら、あなたは、承認を作成して、秘密鍵をそれと契約できるでしょうに。 私はあなたの公開鍵でそれについて確かめることができました、そして、あなたが私のメッセージを受け取ったのを知っているでしょう。
The authentication algorithms used by DASS are considerably more complex than those described in the paragraph above in order to deal
ダスによって使用された認証アルゴリズムが上のパラグラフで説明されたものよりかなり複雑である、取引
Kaufman [Page 4] RFC 1507 DASS September 1993
コーフマン[4ページ]RFC1507ダス1993年9月
with a large number of practical concerns including subtle security threats. Some of these are discussed below.
多くの実用的な関心が微妙な軍事的脅威を含んでいて。 以下でこれらの或るものについて議論します。
1.2.2 Timestamps vs. Challenge/Response
1.2.2 タイムスタンプ対挑戦/応答
Cryptosystems give you the ability to sign messages so that the receiver has assurance that the signer of the message knew some cryptographic secret. Free-standing public key based authentication is sufficiently expensive that it is unlikely that anyone would want to sign every message of an interactive communication, and even if they did they would still face the threat of someone rearranging the messages or playing them multiple times. Authentication generally takes place in the context of establishing some sort of "connection," where a conversation will ensue under the auspices of the single peer-entity authentication. This connection might be cryptographically protected against modification or reordering of the messages, but any such protection would be largely independent of the authentication which occurred at the start of the connection. DASS provides as a side effect of authentication the provision of a shared key which may be used for this purpose.
暗号系がメッセージに署名する能力をあなたに与えるので、受信機には、メッセージの署名者が何らかの暗号の秘密を知っていたという保証があります。 無料の地位の公開鍵に基づいている認証は十分高価です。だれでもインタラクティブコミュニケーションに関するあらゆるメッセージに署名したがっていて、そうしたとしても彼らがメッセージを再配列するか、または複数の回それらをプレーしながらまだだれかの脅威に直面しているのは、ありそうもないです。 一般に、認証は会話がただ一つの同輩実体認証の前兆で続くある種の「接続」を設立することの文脈で行われます。 この接続は、暗号で変更に対して保護されるか、またはメッセージを再命令しているかもしれませんが、そのようなどんな保護も接続の始めに起こった認証から主に独立しているでしょう。 ダスは認証の副作用としてこのために使用されるかもしれない共有されたキーの設備を提供します。
If in our simple minded authentication above, I signed the message "It's really me!" with my private key and sent it to you, you could verify the signature and know the message came from me and give the connection in which this message arrived access to my resources. Anyone watching this message over the network, however, could replay it to any server (just like a password!) and impersonate me. It is important that the message I send you only be accepted by you and only once. I can prevent the message from being useful at any other server by including your name in the message. You will only accept the message if you see your name in it. Keeping you from accepting the message twice is harder.
私が上で私たちの簡単な気にされた認証では、私の秘密鍵で「それは本当に私です!」というメッセージに署名して、それをあなたに送るなら、あなたは、署名について確かめて、メッセージがこのメッセージが到達した接続に私のリソースへのアクセスを与えに私から来たのを知ることができるでしょうに。 しかしながら、ネットワークの上でこのメッセージを見ているだれでも、どんなサーバ(まさしくパスワードのような!)にもそれを再演して、私をまねることができました。 私があなたに送るメッセージが一度だけあなたによって受け入れられるだけであるのは、重要です。 私は、メッセージがいかなる他のサーバでもメッセージにあなたの名前を含んでいることによって役に立つのを防ぐことができます。 それであなたの名前を見る場合にだけ、あなたはメッセージを受け入れるでしょう。 あなたが二度メッセージを受け入れるのを妨げるのは、より困難です。
There are two "standard" ways of providing this replay protection. One is called challenge/response and the other is called timestamp- based. In a challenge response type scheme, I tell you I want to authenticate, you generate a "challenge" (generally a number), and I include the challenge in the message I sign. You will only accept a message if it contains the recently generated challenge and you will make sure you never issue the same challenge to me twice (either by using a sequence number, a timestamp, or a random number big enough that the probability of a duplicate is negligible). In the timestamp-based scheme, I include the current time in my message. You have a rule that you will not accept messages more than - say - five minutes old and you keep track of all messages you've seen in the last five minutes. If someone replays the message within five minutes, you will reject it because you will remember you've seen it before; if someone replays it after five minutes, you will reject it
この反復操作による保護を提供する2つの「標準」の方法があります。 1は挑戦/応答と呼ばれます、そして、もう片方が基づくタイムスタンプと呼ばれます。 チャレンジレスポンスタイプ体系では、私はあなたに言います。認証したいと思う、あなたは、「挑戦」が(一般に数)であると生成して、私は署名するメッセージで挑戦を入れます。 あなたは、二度(写しの確率が取るにたらないほど大きい一連番号を使用するか、タイムスタンプ、または乱数で)それが最近発生している挑戦を含んでいるか、そして、あなたが作るメッセージがあなたが私への同じ挑戦を決して発行しないのを確信していると受け入れるだけでしょう。 タイムスタンプベースの体系では、私はメッセージで現在の時間を入れます。 あなたがメッセージをさらに受け入れないという規則がある、--言ってください--5分の老人とあなたはここ5個の議事録で見たすべてのメッセージの動向をおさえます。 だれかが5分以内にメッセージを再演すると、以前それを見たことがあるのを覚えているので、あなたはそれを拒絶するでしょう。 だれかが5分後にそれを再演すると、あなたはそれを拒絶するでしょう。
Kaufman [Page 5] RFC 1507 DASS September 1993
コーフマン[5ページ]RFC1507ダス1993年9月
as timed out.
外で調節されているように。
The disadvantage of the challenge/response based scheme is that it requires extra messages. While one-way authentication could otherwise be done with a single message and mutual authentication with one message in each direction, the challenge/response scheme always requires at least three messages.
挑戦/応答に基づいている体系の不都合は付加的なメッセージを必要とするということです。 そうでなければ、一方向認証は各方向による1つのメッセージがあるただ一つのメッセージでされて互いの認証であるかもしれませんが、挑戦/応答体系はいつも少なくとも3つのメッセージを必要とします。
The disadvantage of the timestamp-based scheme is that it requires secure synchronized time. If our clocks drift apart by more than five minutes, you will reject all of my attempts to authenticate. If a network time service spoofer can convince you to turn back your clock and then subsequently replays an expired message, you will accept it again. The multicast nature of existing distributed time services and the likelihood of detection make this an unlikely threat, but it must be considered in any analysis of the security of the scheme. The timestamp scheme also requires the server to keep state about all messages seen in the clock skew interval. To be secure, this must be kept on stable storage (unless rebooting takes longer than the permitted clock skew interval).
タイムスタンプベースの体系の不都合は安全な連動している時間を必要とするということです。 私たちの時計が5分以上別れると、あなたは認証する私の試みのすべてを拒絶するでしょう。 ネットワーク時間指定サービスspooferがあなたの時計を折り返すようにあなたを説得できて、次に、次に満期のメッセージを再演すると、あなたは再びそれを受け入れるでしょう。 既存の分配された時間指定サービスのマルチキャスト本質と検出の見込みはこれをありそうもない脅威にしますが、体系のセキュリティのどんな分析でもそれを考えなければなりません。 また、タイムスタンプ体系は、時計斜行間隔で見られたすべてのメッセージに関して状態を維持するためにサーバを必要とします。 安全に、なるように、これを安定貯蔵に保たなければなりません(リブートに受入れられた時計斜行間隔ほど時間がかからない場合)。
DASS uses the timestamp-based scheme. The primary motivations behind this decision were so that authentication messages could be "piggybacked" on existing connection establishment messages and so that DASS would fit within the same "form factor" (number and direction of messages) as Kerberos.
ダスはタイムスタンプベースの体系を使用します。 この決定の後ろのプライマリ動機は、既存のコネクション確立メッセージで認証メッセージを「便乗でき」て、ダスがケルベロスと同じ「形状因子」(メッセージの数と方向)の中で合うためのそうです。
1.2.3 Delegation
1.2.3 委譲
In a distributed environment, authentication alone is not enough. When I log onto a computer, not only do I want to prove my identity to that computer, I want to use that computer to access network resources (e.g., file systems, database systems) on my behalf. My files should (normally) be protected so that I can access them through any node I log in through. DASS allows them to be so protected without allowing all of the systems that I might ever use to access those files in my absence. In the process of logging in, my password gives my login node access to my RSA secret. It can use that secret to "impersonate" me on any requests it makes on my behalf. It should forget all secrets associated with me when I log off. This limits the trust placed in computer systems. If someone takes control of a computer, they can impersonate all people who use that computer after it is taken over but no others.
分散環境で、認証だけが十分ではありません。 私であるときにはコンピュータにログオンしてください、そして、そのコンピュータへの私のアイデンティティを立証したいと思うだけではなく、私に代わってネットワーク資源(例えば、システムをファイルしてください、データベース・システム)にアクセスするのにそのコンピュータを使用したいと思います。 (通常、)私のファイルは、私が私がログインするどんなノードを通してもそれらにアクセスできるように、保護されるべきです。 ダスは、私が私の留守中にそれらのファイルをアクセスに使用できるようにそれらがシステムのすべてを許容しないで保護されるのを許します。 ログインすることの途中に、私のパスワードは私のRSAへの私のログインノードアクセスを秘密に与えます。 それは、それが私に代わってするどんな要求のときにも私を「まねること」にその秘密を使用できます。 私がログオフするとき、それは私に関連しているすべての秘密を忘れるべきです。 これはコンピュータ・システムに置かれた信頼を制限します。だれかがコンピュータを制御するなら、それが持って行かれた後にそのコンピュータを使用するすべての人々をまねますが、それらはどんな他のものもまねることができません。
Normally when I access a network service, I want to strongly authenticate to it. That is, I want to prove my identity to that service, but I don't want to allow that service to learn anything that would allow it to impersonate me. This allows me to use a
通常、私であるときにはサービス、Iが強くそれに認証したがっているネットワークにアクセスしてください。 すなわち、そのサービスへの私のアイデンティティを立証したいと思いますが、そのサービスがそれが私をまねることができる何も学ぶのを許したいと思いません。 これで、私はaを使用できます。
Kaufman [Page 6] RFC 1507 DASS September 1993
コーフマン[6ページ]RFC1507ダス1993年9月
service without trusting it for more than the service it is delivering. When using some services, for example remote login services, I may want that service to act on my behalf in calling additional services. DASS provides a mechanism whereby I can pass secrets to such services that allow them to impersonate me.
それが提供しているサービス以上でそれを信じることのないサービス。 いくつかのサービス、例えばリモート・ログインサービスを利用するとき、私は、追加サービスと呼ぶ際にそのサービスに私の代理に影響して欲しいと思うかもしれません。 ダスは私がそれらが私をまねることができるそのようなサービスに秘密を通過できるメカニズムを提供します。
Future versions of this architecture may allow "limited delegation" so that a user may delegate to a server only those rights the server needs to carry out the user's wishes. This version can limit delegation only in terms of time. The information a user gives a server (other than the initial login node) can be used to impersonate the user but only for a limited period of time. Smart cards will permit that time limitation to apply to the initial login node as well.
このアーキテクチャの将来のバージョンは、ユーザがサーバがユーザの願望を行うために必要とするそれらの権利をサーバだけへ代表として派遣することができるように、「限られた委譲」を許容するかもしれません。 このバージョンは時間だけに関して委譲を制限できます。 ユーザをまねるのに使用されますが、ユーザがサーバ(初期のログインノードを除いた)を与える情報は時間の限定期間だけの間そうすることができます。 スマートカードは、その時、制限がまた、初期のログインノードに適用されることを許可するでしょう。
1.2.4 Certification Authorities
1.2.4 証明当局
A flaw in the strong authentication mechanism described above is that it assumes that every "principal" (user and node) knows the public key of every other principal it wants to authenticate. If I can fool a server into thinking my public key is actually your public key, I can impersonate you by signing a message, saying it is from you, and having the server verify the message with what it thinks is your public key.
上で説明された強い認証機構の欠点はあらゆる「主体」(ユーザとノード)がそれが認証したがっている他のあらゆる主体の公開鍵を知っていると仮定するということです。 サーバが、私の公開鍵が実際にあなたの公開鍵であると思うようにだますことができるなら、私はメッセージに署名することによって、あなたをまねることができます、それがあなたの公開鍵であると考えるものでそれがあなたから来ていると言って、サーバにメッセージについて確かめさせて。
To avoid the need to securely install the public key of every principal in the database of every other principal, the concept of a "Certification Authority" was invented. A certification authority is a principal trusted to act as an introduction service. Each principal goes to the certification authority, presents its public key, and proves it has a particular name (the exact mechanisms for this vary with the type of principal and the level of security to be provided). The CA then creates a "certificate" which is a message containing the name and public key of the principal, an expiration date, and bookkeeping information signed by the CA's private key. All "subscribers" to a particular CA can then be authenticated to one another by presenting their certificates and proving knowledge of the corresponding secret. CAs need only act when new principals are being named and new private keys created, so that can be maintained under tight physical security.
しっかりと他のあらゆる主体に関するデータベースにあらゆる主体の公開鍵をインストールする必要性を避けるために、「認証局」の概念は発明されました。 証明権威は序論サービスとして機能すると信じられた元本です。 各校長は、証明権威に行って、公開鍵を提示して、それには特定の名前があると立証します(主体のタイプと提供されるセキュリティのレベルに従って、これのための正確なメカニズムは異なります)。 そして、カリフォルニアはCAの秘密鍵によって署名される主体、有効期限、および簿記情報の名前と公開鍵を含むメッセージである「証明書」を作成します。 そして、彼らの証明書を提示して、対応する秘密に関する知識を立証することによって、特定のカリフォルニアへのすべての「加入者」をお互いに認証できます。 CAsが、新しい主体が命名されているときの行為だけと新しい秘密鍵を作成する必要があるので、きつい物理的なセキュリティの下でそれを主張できます。
The two problems with the scheme as described so far are "revocation" and "scaleability".
今までのところ説明される体系に関する2つの問題が、「取消し」と"scaleability"です。
1.2.4.1 Certificate Revocation
1.2.4.1 証明書取消し
Revocation is the process of announcing that a key has (or may have) fallen into the wrong hands and should no longer be accepted as proof
取消しはキーが間違った手になって(または、そうしたかもしれません)、もう証拠として認められるべきでないと発表するプロセスです。
Kaufman [Page 7] RFC 1507 DASS September 1993
コーフマン[7ページ]RFC1507ダス1993年9月
of some particular identity. With certificates as described above, someone who learns your secret and your certificate can impersonate you indefinitely - even after you have learned of the compromise. It lacks the ability corresponding to changing your password. DASS supports two independent mechanisms for revoking certificates. In the future, a third may be added.
何らかの特定のアイデンティティについて。 上で説明される証明書で、あなたが感染を知った後にさえあなたの秘密とあなたの証明書を学ぶだれかがあなたを無期限にまねることができます。 それはあなたのパスワードを変えると対応する能力を欠いています。 ダスは、証明書を取り消すために2つの独立しているメカニズムをサポートします。 将来、3分の1は加えられるかもしれません。
One method for revocation is using timeouts and renewals of certificates. Part of the signed message which is a certificate may be a time after which the certificate should not be believed. Periodically, the CA would renew certificates by signing one with a later timeout. If a key were compromised, a new key would be generated and a new certificate signed. The old certificate would only be valid until its timeout. Timeouts are not perfect revocation mechanisms because they provide only slow revocation (timeouts are typically measured in months for the load on the CA and communication with users to be kept manageable) and they depend on servers having an accurate source of the current time. Someone who can trick a server into turning back its clock can use expired certificates.
取消しのための1つのメソッドは証明書のタイムアウトと更新を使用することです。 証明書である署名しているメッセージの一部が証明書が信じられるべきでない時であるかもしれません。 定期的に、カリフォルニアは、後のタイムアウトを1つと契約することによって、証明書を更新するでしょう。 キーが感染されるなら、新しいキーは生成されるでしょうに、そして、新しい証明書は署名しました。 古い証明書はタイムアウトまで有効であるだけでしょう。 遅い取消しだけを提供するので(タイムアウトはカリフォルニアの負荷とユーザとのコミュニケーションが処理しやすく保たれるために何カ月も通常測定されます)、タイムアウトは完全な取消しメカニズムではありません、そして、彼らは現在の時間の正確な源を持っているサーバによります。 時計が使用できるターン後部にサーバをだますことができるだれかが証明書を吐き出しました。
The second method is by listing all non-revoked certificates in the naming service and believing only certificates found there. The advantage of this method is that it is almost immediate (the only delay is for name service "skulking" and caching delays). The disadvantages are: (1) the availability of authentication is only as good as the availability of the naming service and (2) the security of revocation is only as good as the security of the naming service.
名前付けサービスですべての非取り消された証明書をリストアップして、2番目のメソッドはそこで見つけられた証明書だけを信じていることです。 このメソッドの利点はそれがほとんど即座であるという(唯一の遅れが「忍び歩い」て、遅れをキャッシュする名前サービスのためのものです)ことです。 損失は以下の通りです。 (1) (2) 認証の有用性が単に名前付けサービスの有用性と同じくらい良く、取消しのセキュリティは単に名前付けサービスのセキュリティと同じくらい良いです。
A third method for revocation - not currently supported by DASS - is for certification authorities to periodically issue "revocation lists" which list certificates which should no longer be accepted.
取消し(現在、ダスによってサポートされない)のための3番目のメソッドは証明当局が定期的にもう受け入れられるべきでない証明書をリストアップする「取消しリスト」を発行することです。
1.2.4.2 Certification Authority Hierarchy
1.2.4.2 認証局階層構造
While using a certification authority as an introduction service scales much better than having every principal learn the public key of every other principal by some out of band means, it has the problem that it creates a central point of trust. The certification authority can impersonate any principal by inventing a new key and creating a certificate stating that the new key represents the principal. In a large organization, there may be no individual who is sufficiently trusted to operate the CA. Even if there were, in a large organization it would be impractical to have every individual authenticate to that single person. Replicating the CA solves the availability problem but makes the trust problem worse. When authentication is to be used in a global context - between companies - the concept of a single CA is untenable.
序論サービスがあらゆる校長にいくつかでバンド手段から他のあらゆる主体の公開鍵を学ばせるよりはるかによく比例しながら証明権威を使用している間、それには、信頼の主要なポイントを作成するという問題があります。 証明権威は、新しいキーを発明して、新しいキーが主体を表すと述べる証明書を作成することによって、どんな主体もまねることができます。 大きな組織には、カリフォルニアを操作すると十分信じられる個人が全くいないかもしれません。 あったとしても、大きな組織では、すべての個人に独身の人をそれに認証させるのは、非実用的でしょうに。 カリフォルニアを模写するのに、有用性問題を解決しますが、信用問題は、より悪くなります。 認証が会社の間の世界状況で使用されることであるときに、単一のカリフォルニアの概念は支持できません。
Kaufman [Page 8] RFC 1507 DASS September 1993
コーフマン[8ページ]RFC1507ダス1993年9月
DASS addresses this problem by creating a hierarchy of CAs. The CA hierarchy is tied to the naming hierarchy. For each directory in the namespace, there is a single CA responsible for certifying the public keys of its members. That CA will also certify the public keys of the CAs of all child directories and of the CA of the parent directory. With this cross-certification, it is possible knowing the public key of any CA to verify the public keys of a series of intermediate CAs and finally to verify the public key of any principal.
ダスは、CAsの階層構造を作成することによって、このその問題を訴えます。 カリフォルニア階層構造は命名階層構造に結ばれます。 名前空間における各ディレクトリのために、メンバーの公開鍵を公認するのに責任がある単一のカリフォルニアがあります。 また、そのカリフォルニアはすべての子供ディレクトリのCAsと親ディレクトリのカリフォルニアの公開鍵を公認するでしょう。 この相互認証では、どんな主体の公開鍵についても確かめるために最終的に一連の中間的CAsの公開鍵について確かめるためにどんなカリフォルニアの公開鍵も知っているのは可能です。
Because the CA hierarchy is tied to the naming hierarchy, the trust placed in any individual CA is limited. If a CA is compromised, it can impersonate any of the principals listed in its directory, but it cannot impersonate arbitrary principals.
カリフォルニア階層構造が命名階層構造に結ばれるので、どんな個々のカリフォルニアにも置かれた信頼は限られています。 カリフォルニアが感染されるなら、ディレクトリに記載された主体のどれかをまねることができますが、それは任意の主体をまねることができません。
DASS provides mechanisms for every principal to know the public key of its "parent" CA - the CA controlling the directory in which it is named. The result is the following rules for the implications of a compromised CA:
ダスは「親」カリフォルニアの公開鍵を知るためにあらゆる主体にメカニズムを提供します--それが命名されるディレクトリを制御するカリフォルニア。 結果は感染しているカリフォルニアの含意のための以下の規則です:
a) A CA can impersonate any principal named in its directory.
a) カリフォルニアはディレクトリで指定されたどんな主体もまねることができます。
b) A CA can impersonate any principal to a server named in its
directory.
b) カリフォルニアはディレクトリで指定されたサーバにどんな主体もまねることができます。
c) A CA can impersonate any principal named in a subdirectory to
any server not named in the same subdirectory.
c) カリフォルニアはサブディレクトリで同じサブディレクトリで指定されなかったどんなサーバともいうどんな主体もまねることができます。
d) A CA can impersonate to any server in a subdirectory any
principal not named in the same subdirectory.
d) カリフォルニアはサブディレクトリで同じサブディレクトリで指定されなかったどんな主体もどんなサーバにもまねることができます。
The implication is that a compromise low in the naming tree will compromise all principals below that directory while a compromise high in the naming tree will compromise only the authentication of principals far apart in the naming hierarchy. In particular, when multiple organizations share a namespace (as they do in the case of X.500), the compromise of a CA in one organization can not result in false authentication within another organization.
含意は高さ命名木の感染が命名階層構造でかけ離れている主体の認証だけに感染する間命名木の感染安値がそのディレクトリの下におけるすべての主体に感染するということです。 複数の組織が名前空間を共有するとき(X.500の場合でするように)、特に、1つの組織におけるカリフォルニアの感染は別の組織の中で誤った認証をもたらすことができません。
DASS uses the X.500 directory hierarchy for principal naming. At the top of the hierarchy are names of countries. National authorities are not expected to establish certification authorities (at least initially), so an alternative mechanism must be used to authenticate entities "distant" in the naming hierarchy. The mechanism for this in DASS is the "cross-certificate" where a CA certifies the public key for some CA or principal not its parent or child. By limiting the chains of certificates they will use to parent certificates followed by a single "cross certificate" followed by child
ダスは主要な命名にX.500ディレクトリ階層構造を使用します。 階層構造の最上部に、国の名前があります。 国内当局が証明当局(少なくとも初めは)を設立しないと予想されて、命名階層構造における「遠方」の実体を認証するのに代替のメカニズムを使用しなければなりません。 ダスのこれのためのメカニズムはカリフォルニアが何らかのカリフォルニアか主体のための公開鍵がその親でなくて、また子供でもないことを公認する「交差している証明書」です。 それらが子供によって後をつけられた単一の「交差している証明書」があとに続いた親証明書に使用する証明書のチェーンを制限することによって
Kaufman [Page 9] RFC 1507 DASS September 1993
コーフマン[9ページ]RFC1507ダス1993年9月
certificates, a DASS implementation can avoid the need to have CAs near the root of the tree or can avoid the requirement to trust them even if they do exist. A special case can also be supported whereby a global authority whose name is not the root can certify the local roots of independent "islands".
証明書、ダス実装は木の根の近くにCAsを持つ必要性を避けることができるか、または彼らが存在しても、彼らを信じるという要件を避けることができます。 また、名前が根でないグローバルな権威が独立している「島」の地方のルーツを公認できる特別なケースを支えることができます。
1.2.5 User vs. Node Authentication
1.2.5 ユーザ対ノード認証
In concept, DASS mechanisms support the mutual authentication of two principals regardless of whether those principals are people, computers, or applications. Those mechanisms have been extended, however, to deal with a common case of a pair of principals acting together (a user and a node) authenticating to a single principal (a remote server). This is done by having optionally in each credentials structure two sets of secrets - one for the user and one for the node. When authentication is done using such credentials, both secrets sign the request so the receiving party can verify that both principals are present.
概念では、ダスメカニズムはそれらの主体が人々、コンピュータ、またはアプリケーションであることにかかわらず2つの主体の互いの認証をサポートします。 しかしながら、1組の主体が一緒に行動するよくある例(ユーザとノード)に対処するために(リモートサーバ)をただ一つの元本に認証しながら、それらのメカニズムを広げてあります。 それぞれの資格証明書構造に任意に2セットの秘密を持っていることによって、これをします--ユーザのためのものとノードのためのもの。 認証がそのような資格証明書を使用し終わっていると、受領者が、両方の主体が存在していることを確かめることができるように、両方の秘密は要求に署名します。
This setup has a number of advantages. It permits access controls to be enforced based on both the identity of the user and the identity of the originating node. It also makes it possible to define users of systems who have no network wide identities who can access network resources on the basis of node credentials alone. The security of such a setup is less because a node can impersonate all of its users even when they are not logged in, but it offers an easier transition from existing global identities for all users.
このセットアップには、多くの利点があります。 それは、アクセス制御がユーザのアイデンティティと起因するノードのアイデンティティの両方に基づいて励行されることを許可します。 また、それで、いいえにノード資格証明書に基づいて単独でネットワーク資源にアクセスできる広いアイデンティティをネットワークでつながせるシステムのユーザを定義するのは可能になります。 彼らがログインさえされないとき、ノードがユーザのすべてをまねることができるので、そのようなセットアップのセキュリティは、より少ないのですが、それはすべてのユーザのために存在するのからの、より簡単な変遷にグローバルなアイデンティティを提供します。
1.2.6 Protection of User Keys
1.2.6 ユーザキーの保護
DASS mechanisms generally deal with authentication between principals each knowing a private key. For principals who are people, special mechanisms are provided for maintaining that private key. In particular, it many cases it will be most convenient to keep passwords as secrets rather than private keys. This architecture specifies a means of storing private keys encrypted under passwords. This would provide security as good as hiding a private key were it not that people tend to choose passwords from a small space (like words in a dictionary) such that a password can be more easily guessed than a private key. To address this potential weakness, DASS specifies a protocol between a login node and a login agent whereby the login agent can audit and limit the rate of password guesses. Use of these features is optional. A user with a smart card could store a private key directly and bypass all of these mechanisms. If users can be forced to choose "good" passwords, the login agent could be eliminated and encrypted credentials could be stored directly in the naming service.
一般に、ダスメカニズムは、それぞれ秘密鍵を知りながら、主体の間で認証に対処します。 そうする主体において、人々であり、特別なメカニズムは、その秘密鍵を維持しながら、備えられます。 特にそれ、大部分が秘密鍵よりむしろ秘密としてパスワードを保つのに便利であったならそれがそうする多くのケース。 このアーキテクチャはパスワードの下で暗号化された秘密鍵を保存する手段を指定します。 これは、パスワードが秘密鍵より容易に推測されているように、それがそれでなかったなら秘密鍵を隠して、人々が、パスワードを選ぶ傾向があるのと小さいスペースから同じくらい良いセキュリティ(辞書の単語のような)を提供するでしょう。 この潜在的弱点を扱うために、ダスはログインノードとログインエージェントの間のログインエージェントがパスワード推測の速度を監査して、制限できるプロトコルを指定します。 これらの特徴の使用は任意です。 スマートカードをもっているユーザは、直接秘密鍵を保存して、これらのメカニズムのすべてを迂回させることができました。ユーザがやむを得ず「良い」パスワードを選ぶことができるなら、ログインエージェントを排除したかもしれません、そして、直接名前付けサービスで暗号化された資格証明書は保存できました。
Kaufman [Page 10] RFC 1507 DASS September 1993
コーフマン[10ページ]RFC1507ダス1993年9月
Another way in which user keys are protected is that the architecture does not require that they be available except briefly at login. This reduces the threat of a user walking away from a logged on workstation and having someone take over the workstation and extract his key. It also makes the use of RSA based smart cards practical; the card could keep the user's private key and execute one signature operation at login time to authenticate an entire session.
アーキテクチャが、それらが利用可能であることを必要としないということであり、ユーザキーが保護される別の方法は簡潔にログインでそうです。 これはユーザが、ログオンされたワークステーションから無傷で助かって、だれかがワークステーションを持って行って、彼のキーを抽出するのを持つ脅威を抑えます。 また、それはRSAの使用をベースのスマートカードに実用的にします。 カードは、全体のセッションを認証するログイン時にユーザの秘密鍵を保って、1つの署名操作を実行するかもしれません。
1.3 What This Document Won't Tell You
1.3 このドキュメントがあなたに言わないこと
Architecture documents are by their nature difficult to read. This one is no exception. The reason is that an architecture document contains the details sufficient to build interoperable implementations, but it is not a design specification. It goes out of its way to leave out any details which an implementation could choose without affecting interoperability. It also does not specify all the uses of the services provided because these services are properly regarded as general purpose tools.
アーキテクチャドキュメントは読むのが本質的に難しいです。 これは例外ではありません。 理由はアーキテクチャドキュメントが共同利用できる実装を築き上げることができるくらいの詳細を含んでいるということですが、それはデザイン仕様ではありません。 それはわざわざ、実装が相互運用性に影響しないで選ぶことができたどんな詳細も省きます。 また、それはすべてのこれらのサービスが適切に汎用のツールと見なされるので提供されたサービスの用途を指定するというわけではありません。
The remainder of this section includes information which is not properly part of the authentication architecture, but which may be useful in understanding why the architecture is the way it is.
このセクションの残りは認証アーキテクチャを適切に離れさせないことですが、アーキテクチャがなぜ道であるかを理解する際に役に立つかもしれない情報を含んでいます。
1.3.1 How DASS is Embedded in an Operating System
1.3.1 ダスはどうOperating SystemのEmbeddedであるか。
While architecturally DASS does not require any operating system support in order to be used by an application (other than the services listed in Section 2), it is expected that actual implementations of DASS will be closely tied to the operating systems of host computers. This is done both for security and for convenience.
建築上、ダスがアプリケーション(セクション2に記載されたサービスを除いた)で使用されるために少しのオペレーティングシステムサポートも必要としていない間、ダスの実際の実装が密接にホストコンピュータのオペレーティングシステムに結ばれると予想されます。 セキュリティと便宜のためにこれをします。
In particular, it is expected that when a user logs into a node, a set of credentials will be created for that user and then associated by the operating system with all processes initiated by or on behalf of the user. When a user delegates to a service, the remote operating system is expected to accept the delegation and start up the remote process with the delegated credentials. Most nodes are expected to have credentials of their own and support the concept of user accounts. When user credentials are created, the node is expected to verify them in its own context, determine the appropriate user account, and add node credentials to the created credentials set.
特に、ユーザがノードにログインするとき、1セットの資格証明書がユーザかユーザを代表して開始されるすべてのプロセスにそのユーザのために作成されて、次に、オペレーティングシステムで関連づけられると予想されます。 サービスへのユーザ代表であるときに、リモートオペレーティングシステムは、代表として派遣された資格証明書で委譲を受け入れて、リモートプロセスを立ち上げると予想されます。 ほとんどのノードが、それら自身の資格証明書を持って、ユーザアカウントの概念をサポートすると予想されます。 ユーザ資格証明書が作成されるとき、ノードは、それ自身の文脈でそれらについて確かめて、適切なユーザアカウントを決定して、作成された資格証明書へのノード資格証明書がセットしたと言い足すと予想されます。
1.3.2 Forms of Credentials
1.3.2 資格証明書のフォーム
In the DASS architecture, there is a single data structure called "Credentials" with a large number of optional parts. In an
ダスアーキテクチャには、多くのオプショナル・パーツがある「資格証明書」と呼ばれるただ一つのデータ構造があります。 in
Kaufman [Page 11] RFC 1507 DASS September 1993
コーフマン[11ページ]RFC1507ダス1993年9月
implementation, it is possible that not all of the architecturally allowed subsets will be supported and credentials structures with different subsets of the data may be implemented quite differently.
実装、建築上、許容された部分集合のすべてがサポートされるというわけではなくて、データの異なった部分集合がある資格証明書構造が全く異なって実装されるのは、可能です。
The major categories of credentials likely to be supported in an implementation are:
実装でサポートしそうな資格証明書の大範疇は以下の通りです。
- Claimant credentials - these are the credentials which would
normally be associated with a user process in order that it be
able to create authentication tokens. It would contain the
user's name, login ticket, session private key, and (at least
logically) local node credentials and cached outgoing
contexts.
- 主張者資格証明書、--、これらが通常、ユーザ・プロセスに関連している資格証明書であるそれ、認証トークンを作成できてください。 それは、ユーザの名前、ログインチケット、セッション秘密鍵、および(少なくとも論理的に)ローカルのノード資格証明書を含んで、送信する関係をキャッシュしました。
- Verifier credentials - these are the credentials which would
normally be associated with a server which must verify tokens
and produce mutual authentication response tokens. Since
servers may be started by a node on demand, some
representation of verifier credentials must exist independent
of a process. If an operating system wishes to authenticate a
request before starting a server process, the credentials must
exist in usable form. An implementation may choose to have
all services on a "node" share a verifier credentials
structure, or it may choose to have each service have its own.
- 検証資格証明書--これらは通常、トークンについて確かめて、互いの認証応答トークンを生産しなければならないサーバに関連している資格証明書です。 サーバがオンデマンドのノードによって始められるかもしれないので、検証資格証明書の何らかの表現がプロセスの如何にかかわらず存在しなければなりません。 オペレーティングシステムであるなら、サーバプロセス、資格証明書を始める前に要求を認証するという願望は使用可能なフォームに存在しなければなりません。 実装が、「ノード」におけるすべてのサービスに検証資格証明書構造を共有させるのを選ぶかもしれませんか、またはそれは、各サービスにそれ自身のものを持たせるのを選ぶかもしれません。
- Combined credentials - architecturally, a server may have a
structure which is both claimant credentials and verifier
credentials combined so that the server may act in either role
using a single structure. There is some overlap in the
contents. There is no requirement, however, that an
implementation support such a structure.
- 結合した資格証明書--建築上、サーバには、サーバがどちらの役割でもただ一つの構造を使用することで行動できるように結合された主張者資格証明書と検証資格証明書の両方である構造があるかもしれません。 コンテンツには何らかのオーバラップがあります。 しかしながら、要件が全くなくて、それはそのようなaが構造化する実装サポートです。
- Stub credentials - In the architecture, a credentials
structure is created whenever a token is accepted. If delegation
took place, these are claimant credentials usable by their
possessor to create additional tokens. If no delegation took
place, this structure exists as an architectural place holder
against which an implementation may attempt to authenticate
user and node names. An implementation might choose to
implement stub credentials with a different mechanism than
claimant or verifier credentials. In particular, it might do
whatever user and node authentication is useful itself and not
support this structure at all.
- スタッブ資格証明書--アーキテクチャでは、トークンを受け入れるときはいつも、資格証明書構造は作成されます。 委譲が行われたなら、これらは追加トークンを作成する彼らの所有者が使用可能な主張者資格証明書です。 委譲が全く行われなかったなら、この構造は実装がユーザとノード名を認証するのを試みるかもしれない建築場所所有者として存在しています。 実装は、主張者か検証資格証明書より異なったメカニズムでスタッブ資格証明書を実装するのを選ぶかもしれません。 特に、それは、それ自体でどんな役に立つユーザとノード認証もして、この構造を全く支えないかもしれません。
Kaufman [Page 12] RFC 1507 DASS September 1993
コーフマン[12ページ]RFC1507ダス1993年9月
1.3.3 Support for Alternative Certification Authority
Implementations
1.3.3 代替の認証局実装のサポート
A motivating factor in much of the design of DASS is the need to protect certification authorities from compromise. CAs are only used to create certificates for new principals and to renew them on expiration (expiration intervals are likely to be measured in months). They therefore do not need to be highly available. For maximum security, CAs could be implemented on standalone PCs where the hardware, software, and keys can be locked in a safe when the CA is not in use. The certificates the CA generates must be delivered to the naming service to be registered, and a possible mechanism for this is for the CA to have an RS232 line to an on-line component which can pass certificates and related information but not login sessions. The intent would be to make it implausible to mount a network attack against the CA. Alternatively, certificates could be carried to the network on a floppy disk.
ダスのデザインの多くの動機づけている要素は感染から証明当局を保護する必要性です。 CAsは、新しい主体のための証明書を作成して、満了のときにそれらを更新するのに使用されるだけです(満了間隔は何カ月も測定されそうです)。 したがって、それらは非常に利用可能である必要はありません。 カリフォルニアが使用中でないときに、最大のセキュリティのために、ハードウェア、ソフトウェア、およびキーに金庫を閉じ込めることができるところでスタンドアロンPCの上でCAsを実装することができました。 登録されるためにカリフォルニアが作る証明書を名前付けサービスに提供しなければなりません、そして、これのための可能なメカニズムはカリフォルニアがログインセッションではなく、証明書と関連する情報を渡すことができるオンラインコンポーネントにRS232系列を持つことです。 意図はカリフォルニアに対してネットワーク攻撃を仕掛けるのを信じがたくするだろうことです。 あるいはまた、フロッピーディスクの上のネットワークまで証明書を運ぶことができました。
For CAs to be secure, a whole host of design details must be done right. The most important of these is the design of user and system manager interfaces that make it difficult to "trick" a user or system manager into doing the wrong thing and certifying an impostor or revealing a key. Mechanisms for generating keys must also be carefully protected to assure that the generated key cannot be guessed (because of lack of randomness) and is not recorded where a penetrator can get it. Because a certificate contains relatively little human intelligible information (its most important components are UIDs and public keys), it will be a challenge to design a user interface that assures the human operator only authorizes the signing of intented certificates. Such considerations are beyond the scope of the architecture (since they do not affect interoperability), but they did affect the design in subtle ways. In particular, it does not assume uniform security throughout the CA hierarchy and is designed to assure that the compromise of a CA in one part of the hierarchy does not have global implications.
CAsが安全であるように、まさしく多くのデザインの詳細をしなければなりません。 これらで最も重要であるのは、ユーザとユーザかシステム・マネージャが間違ったことをして、詐欺師を公認するか、またはキーを明らかにするのに「だます」であることを難しくするシステム・マネージャインタフェースのデザインです。 キーを生成するのはまた、発生しているキーを推測できないことを(偶発性の不足のために)保証するために慎重に保護しなければならなくて、あるので、メカニズムは、針入度計がどこでそれを得ることができるかを記録しませんでした。 証明書が比較的少ない人間の明瞭な情報を含んでいるので(最も重要なコンポーネントは、UIDsと公開鍵です)、それはそれが「不-テント」の証明書の署名を認可するだけであることを人間のオペレータに知らせるユーザーインタフェースを設計するために挑戦になるでしょう。 そのような問題はアーキテクチャの範囲を超えていましたが(相互運用性に影響しないので)、それらはそれとなくデザインに影響しました。 それは、特に、カリフォルニア階層構造中で一定のセキュリティを仮定しないで、階層構造の一部のカリフォルニアの感染にはグローバルな意味がないことを保証するように設計されています。
The architecture does not require that CAs be off-line. The CA could be software that can run on any node when the proper secret is installed. Administrative convenience can be gained by integrating the CA with account registration utilities and naming service maintenance. As such, the CA would have to be on-line when in use in order to register certificates in the naming service. The CA key could be unlocked with a password and the password could be entered on each use both to authenticate the CA operator and to assure that compromise of the host node while the CA is not in use will not compromise the CA. This design would be subject to attacks based on planting Trojan horses in the CA software, but is entirely interoperable with a more secure implementation. Realistic tradeoffs
アーキテクチャは、CAsがオフラインであることを必要としません。 カリフォルニアは適切な秘密がインストールされるときどんなノードでも動くことができるソフトウェアであるかもしれません。 アカウント登録ユーティリティと名前付けサービスメインテナンスとカリフォルニアを統合することによって、管理便利を獲得できます。 使用中であるときに、そういうものとして、カリフォルニアは、名前付けサービスで証明書を登録するためにオンラインでなければならないでしょう。 カリフォルニアキーの錠がパスワードで開くことができて、各使用のときにともにカリフォルニアのオペレータを認証して、カリフォルニアが使用中でない間ホストノードの感染がカリフォルニアに感染しないことを保証するためにパスワードは入力できました。 このデザインは、カリフォルニアソフトウェアにトロイの木馬を植えることに基づいて攻撃を受けることがあるでしょうが、より安全な実装で完全に共同利用できます。 現実的な見返り
Kaufman [Page 13] RFC 1507 DASS September 1993
コーフマン[13ページ]RFC1507ダス1993年9月
must be made between security, cost, and administrative convenience bearing in mind that a system is only as secure as its weakest link and that there is no benefit in making the CA substantially more secure than the other components of the system.
システムが単に最も弱いリンクと同じくらい安全であり、カリフォルニアをシステムの他の部品より実質的に安全にするのにおいて利益が全くないのを覚えておきながら、セキュリティと、費用と、管理便利の間で作らなければなりません。
1.3.4 Services Provided vs. Application Program Interface
1.3.4 適用業務プログラム・インタフェースに対して提供されたサービス
Section 3 of this document specifies "abstract interfaces" to the services provided by DASS. This means it tells what services are provided, what parameters are supplied by the caller, and what data is returned. It does not specify the calling interfaces. Calling interfaces may be platform, operating system, and language dependent. They do not affect interoperability; different implementations which implement completely different calling interfaces can still interoperate over a network. They do, however, affect portability. A program which runs on one platform can only run on another which implements an identical API.
このドキュメントのセクション3は「抽象的なインタフェース」をダスによって提供されたサービスに指定します。 これは、どんなサービスを提供するか、そして、訪問者がどんなパラメタを提供するか、そして、どんなデータを返すかを言うことを意味します。 それは呼ぶインタフェースを指定しません。 インタフェースと呼ぶのはプラットホーム、オペレーティングシステム、および言語に依存しているかもしれません。 それらは相互運用性に影響しません。 完全に異なった呼ぶのにインタフェースを実装する異なった実装はネットワークの上にまだ共同利用できます。 しかしながら、それらは移植性に影響します。 1個のプラットホームで動くプログラムは同じAPIを実装する別のもので動くことができるだけです。
In order to support portability of applications - not just between implementations of DASS but between implementations of DASS and implementations of Kerberos - a "Generic Security Service API" has been designed and is outlined in Annex B. This API could be the only "published" interface to DASS services. This interface does not, however, give access to all the functions provided by DASS and it provides some non-DASS services. It does not give access to the "login" service, for example, so the login function cannot be implemented in a portable way. Clearly an implementation must provide some implementation of the login function, though perhaps only to one system program and the implementation need not be portable. Similarly, the Generic API provides no access to node authentication information, so applications which use these services may not be portable.
ダスの実装だけではなく、ダスの実装とケルベロスの実装の間のアプリケーションの移植性をサポートするために、「ジェネリックセキュリティー・サービスAPI」は、設計されていて、ダスへの唯一の「発行された」インタフェースがサービスであったかもしれないならAnnex B.This APIに概説されます。 しかしながら、このインタフェースはダスによって提供されたすべての機能へのアクセスを与えません、そして、それはいくつかの非ダスのサービスを提供します。 それが「ログイン」サービスへのアクセスを与えないので、例えば、携帯用の方法でログイン機能を実装することができません。 明確に、実装はログイン機能の何らかの実装を提供しなければなりません、システムプログラムと実装は恐らく1つだけに携帯用である必要はありませんが。 同様に、Generic APIがノード認証情報へのアクセスを全く提供しないので、これらのサービスを利用するアプリケーションは携帯用でないかもしれません。
The Generic API provides services for encryption of user data for integrity and possibly privacy. These services are not specified as a part of the DASS architecture. This is because we envisioned that such services would be provided by the communications network and not in applications. These services are provided by the Generic API because these services are provided by Kerberos, there exist applications which use these services, and they are desired in the context of the IETF-CAT work. The DASS architecture includes a Key Distribution service so that the encryption functions of the Generic API can be supported and integrated. Annex B specifies how those services can be implemented using DASS services.
Generic APIは保全とことによるとプライバシーのための利用者データの暗号化のためのサービスを提供します。 これらのサービスはダスアーキテクチャの一部として指定されません。 これは私たちがサービスがアプリケーションではなく、通信網によって提供されるそのそのようなものを思い描いたからです。 Generic APIは、ケルベロスでこれらのサービスを提供して、これらのサービスを利用する利用が存在していて、IETF-CAT仕事の文脈でそれらを望んでいるので、これらのサービスを提供します。 ダスアーキテクチャは、Generic APIの暗号化機能をサポートして、統合できるようにKey Distributionサービスを含んでいます。 別館Bはダスのサービスを利用することでどうそれらのサービスを実装することができるかを指定します。
The Services Provided also differ from the GSSAPI because there are important extensions envisioned to the API for future applications and it was important to assure that architecturally those services
また、将来のアプリケーションのためにAPIに思い描かれた重要な拡大があるので、Services ProvidedはGSSAPIと異なっています、そして、そんなに建築上、それらのサービスを保証するのは重要でした。
Kaufman [Page 14] RFC 1507 DASS September 1993
コーフマン[14ページ]RFC1507ダス1993年9月
were available. In particular, DASS provides the ability for a principal to have multiple aliases and for the receiver of an authentication token to verify any one of them. We want DASS to support the case where a server only learns the name it is trying to validate in the course of evaluating an ACL. This may be long after a connection is accepted. The Services Provided section therefore separates the Accept_token function from the Verify Principal Name. The other motivation behind a different interface is that DASS provides node authentication - the ability to authenticate the node from which a request originates as well as the user. Because Kerberos provides no such mechanism, the capability is missing from the GSSAPI, but we expect some applications will want to make use of it.
利用可能。 特に、ダスは元本には複数の別名があって、認証トークンの受信機がそれらのどれかについて確かめる能力を提供します。 私たちは、ダスにサーバがACLを評価することの間にそれが有効にしようとしている名前を学ぶだけであるケースを支えて欲しいと思います。 接続を受け入れるずっと後にこれはそうです。 したがって、Services Provided部はVerifyプリンシパルNameとAccept_トークン機能を切り離します。 異なったインタフェースの後ろのもう片方の動機はダスはノード認証を提供します--要求がユーザと同様に起因するノードを認証する能力ということです。 ケルベロスがどんなそのようなメカニズムも提供しないので、能力はGSSAPIからなくなりますが、私たちは、いくつかのアプリケーションがそれを利用したくなると予想します。
1.3.5 Use of a Naming Service
1.3.5 名前付けサービスの使用
With the exception of the syntactical representation of names, which is tied to X.500, the DASS architecture is designed to be independent of the particular underlying naming service. While the intention is that certificates be stored in an X.500 naming service in the fields architecturally reserved for this purpose in the standard, this specification allows for the possibility of different forms of certificate stores. The SPX implementation of DASS implements its own certificate distribution service because we did not want to introduce a dependency on an X.500 naming service.
名前の構文の表現を除いて、ダスアーキテクチャは、特定の基本的な名前付けサービスから独立しているように設計されています。(それは、X.500に結ばれます)。 意志は証明書が建築上、このために規格で予約された分野のX.500名前付けサービスで保存されるということですが、この仕様は異なった形式の証明書店の可能性を考慮します。 私たちがX.500名前付けサービスで依存を導入したくなかったので、ダスのSPX実装は、それ自身の証明書が配布サービスであると実装します。
1.3.6 Key Hiding - Credentials
1.3.6 主要な隠れること--資格証明書
The abstract interfaces described in section 3 specify that "credentials" and "keys" are the inputs and outputs of various routines. Credentials structures in particular contain secret information which should not be made available to the calling application. In most cases, keeping this information from applications is simply a matter of prudence - a misbehaving application can do nearly as much damage using the credentials as it can by using the secrets directly. Having access to the keys themselves may allow an application to bypass auditing or leak a key to an accomplice who can use it on another node where a large amount of activity is less likely to be noticed. In some cases, most dramatically where a "node key" is present in user credentials, it is vital that the contents of the credentials be kept out of the hands of applications.
セクション3で説明された抽象的なインタフェースは、「資格証明書」と「キー」が様々なルーチンの入力と出力であると指定します。 資格証明書構造は呼ぶアプリケーションが入手するべきでない秘密の情報を特に含んでいます。 多くの場合、アプリケーションからこの情報を妨げるのは、単に思慮の問題です--ふらちな事するアプリケーションは、それが直接秘密を使用することによって与えることができるように資格証明書を使用することでほとんど同じくらい多くの損害を与えることができます。 キー自体に近づく手段を持っているのは、アプリケーションに監査を迂回させるか、または別のノードで上多量の活動が、より気付かれそうにないそれを使用できる共犯のキーを漏らさせるかもしれません。 いくつかの場合、「ノードキー」がユーザ資格証明書で存在しているところでアプリケーションの手が資格証明書のコンテンツに入れないようにされるのは、最も劇的に、重大です。
To accomplish this, a concrete interface is expected to create "credentials handles" that are passed in and out of DASS routines. The credentials themselves would be kept in some portion of memory where unprivileged code can't get at them.
これを達成するために、具体的なインタフェースがダスのルーチンについて内外に通過される「資格証明書ハンドル」を作成すると予想されます。 資格証明書自体は「非-特権を与え」させられたコードがそれらに達することができないメモリの何らかの部分に保たれるでしょう。
Kaufman [Page 15] RFC 1507 DASS September 1993
コーフマン[15ページ]RFC1507ダス1993年9月
There is another aspect of the way credentials are used which is important to the design of real implementations. In normal use, a user will create a set of credentials in the process of logging on to a system and then use them from many processes or jobs. When many processes share a set of credentials, it is important for the sake of performance that they share one set of credentials rather than having a copy of the credentials made for each. This is because information is cached in credentials as a side effect of some requests and for good performance those caches should be shared.
資格証明書が使用されている本当の実装のデザインに重要な方法のもう一つの側面があります。 通常の使用で、多くのプロセスか仕事からシステムと次に、使用にそれらを登録することの途中にユーザは1セットの資格証明書を作成するでしょう。 多くのプロセスが1セットの資格証明書を共有するとき、性能のために、それぞれのために資格証明書のコピーを作らせるよりむしろ1セットの資格証明書を共有するのは、重要です。 これはいくつかの副作用が要求するように情報が資格証明書でキャッシュされて、それらのキャッシュが望ましい市場成果において共有されるべきであるからです。
As an example, consider a system executing a series of copy commands moving files from one system to another. The credentials of the user will have been established when the user logged on. The first time a copy is requested, a new process will start up, open a connection to the destination system, and create a token to authenticate itself. Creating that token will be an expensive operation, but information will be computed and "cached" in the credentials structure which will allow any subsequent tokens on behalf of that user to that server to be computed cheaply. After the copy completes, the connection is closed and the process terminates. In response to a second copy request, another new process will be created and a new token computed. For this operation to get a performance benefit from the caching, the information computed by the first process must somehow make it to the second.
例と、1台のシステムから別のものへファイルを移す一連のコピーコマンドを実行するシステムを考えてください。 ユーザがログオンしたとき、ユーザの資格証明書は確立していてしまうでしょう。 コピーが初めて要求されるとき、ニュープロセスは、始動して、目的地システムに接続を開いて、それ自体を認証するためにトークンを作成するでしょう。 そのトークンを作成するのが、高価な操作ですが、情報は、計算されて、そのサーバへのそのユーザを代表したどんなその後のトークンも安く計算されるのを許容する資格証明書構造で「キャッシュされるでしょう」。 コピーが完成した後、接続は閉じられて、プロセスは終わります。 2番目のコピー要求に対応して、別のニュープロセスは、作成されていて計算された新しいトークンになるでしょう。 この操作がキャッシュから性能利益を得るように、最初のプロセスによって計算された情報はどうにか2番目に行かなければなりません。
A model for how this caching might work can be seen in the way Kerberos caches credentials. Kerberos keeps credentials in a file whose name can be computed from the name of the local user. This file is initialized as part of the login process and its protection is set so that only processes running under the UID of the user may read and write the file. Processes cache information there; all processes running on behalf of the user share the file.
ケルベロスが資格証明書をキャッシュする方法でこのキャッシュがどう働くことができるようにモデルを見ることができるか。 ケルベロスは地元のユーザの名前から名前を計算できるファイルの資格証明書を保ちます。 ユーザのUIDで実行されるプロセスだけがファイルを読み書きできるようにログインプロセスとその保護の一部が設定されるとき、このファイルは初期化されます。 プロセスはそこで情報をキャッシュします。 ユーザを代表して稼働するすべてのプロセスがファイルを共有します。
There are two problems with this scheme: first, on a diskless node putting information in a file exposes it to eavesdroppers on the network; second, it does not accomplish the "key hiding" function described earlier in this section. In a more secure implementation, the kernel or a privileged process would manage some "pool" of credentials for all processes on a node and would grant access to them only through the DASS calls. Credentials structures are complex and varying length; DASS may organize them as a set of pools rather than as contiguous blocks of data. All such design issues are "beyond the scope of the architecture". Implementations must decide how to control access to credentials. They could copy the Kerberos scheme of having credentials available to processes with the UID of the login session which created them and to privileged processes or there may be a more elaborate mechanism for "passing" credentials handles from process to process. This design should probably follow
この体系に関する2つの問題があります: まず最初に、ファイルはネットワークで情報を入れるディスクレスノードの上では、立ち聞きする者にそれを暴露します。 2番目に、それは、より早くこのセクションで説明された「主要な隠れること」機能を達成しません。 より安全な実装では、カーネルか特権があるプロセスが、ノードの上のすべてのプロセスのために資格証明書のいくつかの「プール」を管理して、単にダスの呼び出しでそれらへのアクセスを承諾するでしょう。 資格証明書構造は複雑で異なった長さです。 ダスは隣接のブロックのデータとしてというよりむしろ1セットのプールとしてそれらを組織化するかもしれません。 そのようなすべてのデザイン問題が「アーキテクチャの範囲」にあります。 実装は資格証明書へのアクセスを制御する方法を決めなければなりません。 彼らがそれらを作成したログインセッションのUIDと、そして、特権があるプロセスにプロセスに利用可能な有資格証明書のケルベロス体系をコピーするかもしれませんか、または資格証明書ハンドルのプロセスからプロセスまで「通過」であるための、より入念なメカニズムがあるかもしれません。 このデザインはたぶん従うべきです。
Kaufman [Page 16] RFC 1507 DASS September 1993
コーフマン[16ページ]RFC1507ダス1993年9月
the operating system mechanisms for passing around local privileges.
地方の特権を回すためのオペレーティングシステムメカニズム。
1.3.7 Key Hiding - Contexts
1.3.7 主要な隠れること--文脈
The "GSSAPI" has a concept of a security context which has some of the same key hiding problems as a credentials structure. Security contexts are used in calls to cryptographically protect user data (from modification or from disclosure and modification) using keys established during authentication. The "services provided" specification says that create_ and accept_token return a "shared key" and "instance identifier". The GSSAPI says that a context handle is returned which is an integer. A secure implementation would keep the key and instance identifier in protected memory and only allow access to them through provided interfaces.
"GSSAPI"には、資格証明書構造として同じ主要な隠れること問題のいくつかを持っているセキュリティ文脈の概念があります。 セキュリティ文脈は認証の間に設立されたキーを使用することで暗号で、利用者データ(変更か公開と変更からの)を保護するという要求に使用されます。 「サービスは提供した」という仕様が、それが_を作成して、トークンが「共有されたキー」と「インスタンス識別子」を返す_を受け入れると言います。 GSSAPIは、整数である文脈ハンドルが返されると言います。 安全な実装は、保護されたメモリのキーとインスタンス識別子を保って、提供されたインタフェースにそれらへのアクセスの通ることを許すだけでしょう。
Unlike credentials, there is probably no need to provide mechanisms for contexts to be shared between processes. Contexts will normally be associated with some notion of a communications "connection" and ends of a connection are not normally shared. If an implementation chooses to provide additional services to applications like message sequencing or duplicate detection, contexts will have to contain additional fields. These can be created and maintained without any additional authentication services.
資格証明書と異なって、文脈がプロセスの間で共有されるためにメカニズムを提供する必要はたぶん全くありません。 通常、文脈は「接続」というコミュニケーションの何らかの概念に関連するでしょう、そして、通常、接続の終わりは共有されません。 実装が、メッセージ配列や写し検出のようなアプリケーションに対する追加サービスを提供するのを選ぶと、文脈は追加分野を含まなければならないでしょう。 少しも追加認証サービスなしでこれらを作成して、維持できます。
1.4 The Relationship between DASS and ISO Standards
1.4 ダスとISO規格との関係
This section provides an introduction to DASS authentication in terms of the ISO Authentication Framework (DP10181-2). The purpose of this introduction is to give the reader an intuitive understanding of the way DASS works and how its mechanisms and terminology relate to standards. Important details have been omitted here but are spelled out in section 3.
このセクションはISO Authentication Framework(DP10181-2)に関してダスの認証に序論を提供します。 この序論の目的はダスが働く方法とそのメカニズムと用語がどう規格に関連するかに関する直感的な理解を読者に与えることです。 重要な詳細は、ここで省略されましたが、セクション3でスペルアウトされます。
1.4.1 Concepts
1.4.1 概念
The primary goal of authentication is to prevent impersonation, that is, the pretense to a false identity. Authentication always involves identification in some form. Without authentication, anyone could claim to be whomever they wished and get away with it.
認証のプライマリ目標はものまね、すなわち、見せかけるのを偽名に防ぐことです。 認証はいつも何らかのフォームに識別にかかわります。 認証がなければ、だれでも、彼らが願っていた人なら誰でもであるか、そして、それをうまくやると主張できました。
If it didn't matter with whom one was communicating, elaborate procedures for authentication would be unnecessary. However, in most systems, and in timesharing and distributed processing environments in particular, the rights of individuals are often circumscribed by security policy. In particular, authorization (identity based access control) and accountability (audit) provisions could be circumvented if masquerading attempts were impossible to prevent or detect.
あるものがだれを伝えていたかと共に重要でないなら、認証のための入念な手順は不要でしょうに。 しかしながら、特にほとんどのシステム、時分割、および分散処理環境で、個人の権利は安全保障政策でしばしば外接しています。 仮装試みは防ぐか、または検出するのが不可能であるなら、特に、承認(アイデンティティはアクセスコントロールを基礎づけた)と責任(監査する)条項を回避できるでしょうに。
Kaufman [Page 17] RFC 1507 DASS September 1993
コーフマン[17ページ]RFC1507ダス1993年9月
Almost all practical authentication mechanisms suitable for use in distributed environments rely on knowledge of some secret information. Most differences lie in how one presents evidence that they know the secret. Some schemes, in particular the familiar simple use of passwords, are quite susceptible to attack. Generally, the threats to authentication may be classified as:
分散環境における使用に適したほとんどすべての実用的な認証機構が何らかの秘密の情報に関する知識を当てにします。 ほとんどの違いが1つがどう、彼らが秘密を知っているという証拠を提示するかであります。 いくつかの体系(特にパスワードの身近な簡単な使用)が攻撃するのにおいて十分影響されやすいです。 一般に、認証への脅威は以下として分類されるかもしれません。
- forgery, attempting to guess or otherwise fabricate evidence;
- 証拠を推測するか、またはそうでなければ、作るのを試みる偽造
- replay, where one can eavesdrop upon another's authentication
exchange and learn enough to impersonate them; and
- 人が別のものの認証交換を盗み聞いて、それらをまねることができるくらい学ぶことができるところで再演してください。 そして
- interception, where one slips between the communicants and is
able to modify the communications channel unnoticed.
- 1つが聖餐拝受者の間を滑って、目だたない状態でコミュニケーションチャンネルを変更できるところでの妨害。
Most such attacks can be countered by using what is known as strong authentication. Strong authentication refers to techniques that permit one to provide evidence that they know a particular secret without revealing even a hint about the secret. Thus neither the entity to whom one is authenticating, nor an eavesdropper on the conversation can further their ability to impersonate the authenticating principal at some future time as the result of an authentication exchange.
強い認証として知られていることを使用することによって、そのようなほとんどの攻撃に対抗できます。 強い認証は1つが彼らが秘密に関してヒントさえ明らかにしないで特定の秘密を知っているという証拠を提供することを許可するテクニックを示します。 したがって、1つが認証である実体も会話での立ち聞きする者も何らかの将来の時間に認証交換の結果として認証主体をまねる彼らの能力を促進できません。
Strong authentication mechanisms, in particular those used here, rely on cryptographic techniques. In particular, DASS uses public key cryptography. Note that interception attacks cannot be countered by strong authentication alone, but generally need additional security mechanisms to secure the communication channel, such as data encryption.
強い認証機構(特にここで使用されたもの)は暗号のテクニックを当てにします。 特に、ダスは公開鍵暗号を使用します。 一般に、通信チャネルを保証するために追加担保メカニズムを必要とするのを除いて、データ暗号化などのように強い認証で妨害攻撃に単独で対抗できないことに注意してください。
1.4.2 Principals and Their Roles
1.4.2 主体とそれらの役割
All authentication is on behalf of principals. In DASS the following types of principals are recognized:
すべての認証が主体を代表しています。 ダスでは、以下のタイプの主体は認識されます:
- user principals, normally people with accounts who are
responsible for performing particular tasks. Generally it is
users that are authorized to do things by virtue of having
been granted access rights, or who are to be held accountable
for specific actions subject to being audited.
- ユーザ主体、通常アカウントをもっている特定のタスクを実行するのに責任がある人々。 一般にそれはアクセス権を与えたことによってことをするのに権限を与えられることになっているか、または監査されることを条件として特定の動作について責任があるように主張されることになっているユーザです。
- server principals, which are accessed by users.
- サーバ主体。(その主体はユーザによってアクセスされます)。
- node principals, corresponding to locations where users and
servers, or more accurately, processes acting on behalf of
principals can reside.
- 位置に対応するノード主体、どこ、正確に、主体を代表して行動するプロセスがそうすることができるユーザとサーバか、その他、住んでくださいか。
Kaufman [Page 18] RFC 1507 DASS September 1993
コーフマン[18ページ]RFC1507ダス1993年9月
Principals can act in one of two capacities:
主体は2つの人収容の1つで行動できます:
- the claimant is the active entity seeking to authenticate
itself, and
- そして主張者がそれ自体を認証しようとするアクティブな実体である。
- the verifier is the passive entity to whom the claimant is
authenticating.
- 検証は主張者が認証している受け身の実体です。
Users normally are claimants, whereas servers are usually verifiers, although sometimes servers can also be claimants.
また、時々サーバは主張者であるかもしれませんが、サーバは通常検証ですが、通常、ユーザは主張者です。
There is another kind of principal:
もう1種類の主体があります:
- certification authorities (CA's) issue certificates which
attest to another principal's public key.
- 証明当局(CAのもの)は別の主体の公開鍵を証明する証明書を発行します。
1.4.3 Representation, Delegation and Representation Transfer
1.4.3 表現、委譲、および表現は移されます。
Of course, although it is users that are responsible for what the computer does, human beings are physically unable to directly do anything within a computer system. In point of fact, it is a process executing on behalf of a user that actually performs useful work. From the point of view of performing security controlled functions, the process is the agent, or representative, of the user, and is authorized by that user to do things on his behalf. In the terms used in the ISO Authentication Framework, the user is said to have a representation in the process.
もちろん、それはコンピュータがすることに責任があるユーザですが、人間はコンピュータ・システムの中で物理的に直接何もできません。 事実上、実際に実質的な仕事を実行するのは、ユーザを代表して実行されるプロセスです。 セキュリティの制御機能を実行する観点から、プロセスは、ユーザのエージェント、または代表であり、そのユーザによって彼に代わってことをするのが認可されます。 ISO Authentication Frameworkで使用される用語で、ユーザはプロセスに表現を持っていると言われています。
The representation has to come into existence somehow. Delegation refers to the act of creating a representation. A user is said to create a representation for themselves by delegating to a process. If the user creates another process, say by doing an rlogin on a different computer, a representation may be needed there as well. This may be accomplished automatically by a process known as representation transfer. DASS uses the term delegation to also mean the act of creating additional representations on a remote systems.
表現はどうにか生まれなければなりません。 委譲は表現を作成する行為を示します。 ユーザはプロセスに委任することによって自分たちの表現を作成すると言われています。 ユーザが別のプロセスを作成するなら、することによって、異なったコンピュータの上のrloginであり、また、表現がそこで必要であるかもしれないと言ってください。 これは表現転送として知られているプロセスによって自動的に達成されるかもしれません。 ダスは、また、追加表現をリモートシステムに作成する行為を意味するのに委譲という用語を使用します。
A representation is instantiated in DASS as credentials. Credentials include the identity of the principal as well as the cryptographic "state" needed to engage in strong authentication procedures. Claimant information in credentials enable principals to authenticate themselves to others, whereas verifier information in credentials permit principals to verify the claims of others. Credentials intended primarily for use by a claimant will be referred to as claimant credentials in the text which follows. Credentials intended primarily for use in verification will be referred to as verifier credentials. A particular set of credentials may or may not contain
表現は資格証明書としてダスに例示されます。 資格証明書は強い認証手順に従事するのに必要である暗号の「状態」と同様に主体のアイデンティティを含んでいます。 資格証明書における主張者情報は、校長が他のものに自分たちを認証するのを可能にしますが、資格証明書における検証情報は、校長が他のもののクレームについて確かめることを許可します。 主として使用のために主張者によって意図された資格証明書は従うテキストの主張者資格証明書と呼ばれるでしょう。 主として検証における使用のために意図する資格証明書は検証資格証明書と呼ばれるでしょう。 特定のセットの資格証明書は含むかもしれません。
Kaufman [Page 19] RFC 1507 DASS September 1993
コーフマン[19ページ]RFC1507ダス1993年9月
all of the data necessary to be used in both roles. That will depend on the mechanisms by which the credentials were created.
両方の役割で使用されているのに必要なデータのすべて。 それは資格証明書が作成されたメカニズムによるでしょう。
In some contexts, but not here, the concept of representation and/or delegation is sometimes referred to as proxy. This term is used in ECMA TR/46. We avoid use of the term because of possible confusion with an unrelated use of the term in the context of DECnet.
いくつかの文脈では、表現、そして/または、委譲の概念はここに呼ばれるのではなく、時々プロキシと呼ばれます。 今期はECMA TR/46で使用されます。 私たちはDECnetの文脈における用語の関係ない使用への可能な混乱で用語の使用を避けます。
1.4.4 Key Distribution, Replay, Mutual Authentication and Trust
1.4.4 主要な分配、再生、互いの認証、および信頼
Strong authentication uses cryptographic techniques. The particular mechanisms used in DASS result in the distribution of cryptographic keys as a side effect. These keys are suitable for use for providing a data origin authentication service and/or a data confidentiality service between a pair of authenticated principals.
強い認証は暗号のテクニックを使用します。 ダスで使用される特定のメカニズムは副作用として暗号化キーの分配をもたらします。 これらのキーはデータ発生源認証サービス、そして/または、データの機密性サービスを1組の認証された主体の間に提供する使用に適しています。
Replay detection is provided using timestamps on relevant authentication messages, combined with remembering previously accepted messages until they become "stale". This is in contrast to other techniques, such as challenge and response exchanges.
「聞き古したである」なるまで以前に受け入れられたメッセージを覚えていると結合された関連認証メッセージに関するタイムスタンプを使用することで再生検出を提供します。 これは挑戦や応答交換などの他のテクニックと対照的になっています。
Authentication can be one-way or mutual. One-way authentication is when only one party, in DASS the claimant, authenticates to the other. Mutual authentication provides, in addition, authentication of the verifier back to the claimant. In certain communications schemes, for example connectionless transfer, only one-way authentication is meaningful. DASS supports mutual authentication as a simple extension of one-way authentication for use in environments where it makes sense.
認証は、一方向である、または互いである場合があります。 一方向認証はいつです。パーティーが主張者のダスでもう片方に認証する1つだけ。 互いの認証はさらに、検証の認証を主張者に提供して戻します。 あるコミュニケーション体系、例えば、コネクションレスな転送では、一方向認証だけが重要です。 ダスはそれが理解できる環境における使用のための一方向認証の単純拡大として互いの認証をサポートします。
DASS potentially can allow many different "trust relationships" to exist. All principals trust one or more CA's to safeguard the certification process. Principals use certificates as the basis for authenticating identities, and trust that CA's which issue certificates act responsibly. Users expect CA's to make sure that certificates (and related secrets) are only made for principals that the CA knows or has properly authenticated on its own.
ダスは多くの異なった「信頼関係」を潜在的に存在させることができます。 すべての校長が1つを信じるか、安全装置への、より多くのCAが証明プロセスです。 校長はアイデンティティを認証する基礎として証明書を使用します、そして、問題証明書が責任をもって行動させるCAのそのものを信じてください。 ユーザは、CAのものが、証明書(そして、秘密について話す)がカリフォルニアが知っているか、またはそれ自身のところで適切に認証した主体のために作られているだけであるのを確実にすると予想します。
1.5 An Authentication Walkthrough
1.5 認証ウォークスルー
The OSI Authentication Framework characterizes authentication as occurring in six phases. This section attempts to describe DASS in these terms.
OSI Authentication Frameworkは六相で起こるとして認証を特徴付けます。 このセクションは、これらの用語でダスについて説明するのを試みます。
Kaufman [Page 20] RFC 1507 DASS September 1993
コーフマン[20ページ]RFC1507ダス1993年9月
1.5.1 Installation
1.5.1 インストール
In this phase, principal certificates are created, as is the additional information needed to create claimant and verifier credentials. OSI defines three sub-phases:
このフェーズでは、主要な証明書は主張者と検証資格証明書を創造するのに必要である追加情報のように作成されます。 OSIは3つのサブフェーズを定義します:
- Enrollment. In DASS, this is the definition of a principal in
terms of a key, name and UID.
- 登録。 ダスと、これはキー、名前、およびUIDに関する元本の定義です。
- Validation, confirmation of identity to the satisfaction of
the CA, after which the CA generates a certificate.
- 合法化、カリフォルニアが証明書を作るカリフォルニアの満足へのアイデンティティの確認。
- Confirmation. In DASS, this is the act of providing the user
with the certificate and with the CA's own name, key and UID,
followed up by the user creating a trusted authority for that
CA. A trusted authority is a certificate for the CA signed by
the user.
- 確認。 ダスでは、これはCAの証明書をユーザに提供する、自己の名前、キー、およびUIDとの信じられた権威をそのカリフォルニアに作成するユーザによって追求された行為です。 信じられた権威はユーザによって署名されたカリフォルニアのための証明書です。
Included in this step in DASS is the posting of the certificate so as to be available to principals wishing to verify the principal's identity. In addition, the user principal saves the trusted authority so as to be available when it creates credentials.
ダスのこのステップに含まれていて、主体のアイデンティティについて確かめることを願いながら主体に利用可能になるように、証明書は任命がありますか? さらに、ユーザ主体は、資格証明書を作成するとき、利用可能になるように信じられた権威を保存します。
1.5.2 Distribution
1.5.2 分配
DASS distributes certificates by placing them in the name service.
ダスは、サービスという名前にそれらを置くことによって、証明書を配布します。
1.5.3 Acquisition
1.5.3 獲得
Whenever principals wish to authenticate to one another, they access the Name Service to obtain whatever public key certificates they need and create the necessary credentials. In DASS, acquisition means obtaining credentials.
いつ、お互いに認証する主体願望、それらは彼らが必要とするどんな公開鍵証明書も入手して、必要な資格証明書を作成するためにName Serviceにアクセスするか。 ダスでは、獲得は、資格証明書を得ることを意味します。
Claimant credentials implement the representation of a principal in a process, or, more accurately, provide a representation of the principal for use by a process. In making this representation, the principal delegates to a temporary delegation key. In this fashion the claimant's long term principal key need not remain in the system.
主張者資格証明書は、プロセスで元本の表現を実装するか、またはプロセスで、より正確に主体の表現を使用に提供します。 この表現、主要な代表を一時的な委譲キーに作る際に。 こんなやり方で主張者の長期主体キーはシステムに残る必要はありません。
Claimant credentials are made by invoking the get credentials primitive. Claimant credentials are a DASS specific data structure containing:
主張者資格証明書が呼び出すことによって作られている、資格証明書を原始的にならせてください。 主張者資格証明書は以下を含むダス特有のデータ構造です。
- a name
- 名前
- a ticket, a data structure containing
- チケット、データ構造含有
Kaufman [Page 21] RFC 1507 DASS September 1993
コーフマン[21ページ]RFC1507ダス1993年9月
. a validity interval,
. 正当性間隔
. UID, and
そして. UID。
. (temporary) delegation public key, along with a
. aに伴う(一時的)の委譲公開鍵
. digital signature on the above made with the principal
private key
. 主要な秘密鍵で作られた上記におけるデジタル署名
- the delegation private key
- 委譲秘密鍵
Optionally in addition, there may be credential information relating to the node on which the user is logged in and the account on that node. A detailed description of all the information found in credentials can be found in section 3. Verifier credentials are made with initialize_server. Verifier credentials consist of a principal (long term) private key. The rationale is that these credentials are usually needed by servers that must be able to run indefinitely without re-entry of any long term key.
任意に、そのノードの上にユーザがログインされるノードをアカウントに関連する資格証明情報があるかもしれません。 セクション3で資格証明書で見つけられたすべての情報の詳述を見つけることができます。 _サーバを初期化してください。検証資格証明書が作られている、検証資格証明書は主要な(長期)秘密鍵から成ります。 原理は通常、これらの資格証明書がどんな長期キーの再突入なしでも無期限に稼働できなければならないサーバによって必要とされるということです。
In addition, claimants and verifiers have a trusted authority, which consists of information about a trusted CA. That information is its:
さらに、主張者と検証には、信じられた権威があります。(それは、信じられたカリフォルニアの情報から成ります)。 その情報がそうである、それ、:
- name (this will appear in the "issuer" field in principal
certificates),
- 名前(これは主要な証明書の「発行人」分野に現れるでしょう)
- public key (to use in verifying certificates issued by that
CA), and
- そして公開鍵(そのカリフォルニアによって発行された証明書について確かめる際に使用する)。
- UID.
- UID。
Trusted authorities are used by principals to verify certificates for other principals' public keys. CAs are arranged in a hierarchy corresponding to the naming hierarchy, where each directory in the naming hierarchy is controlled by a single CA. Each CA certifies the CA of its parent directory, the CAs of each of its child directories, and optionally CAs elsewhere in the naming hierarchy (mainly to deal with the case where the directories up to a common ancestor lack CAs). Even though a principal has only a single CA as a trusted authority, it can securely obtain the public key of any principal in the namespace by "walking the CA hierarchy".
信じられた当局は主体によって使用されて、他の主体の公開鍵のための証明書について確かめます。 CAsは命名階層構造に対応する階層構造でアレンジされます。そこでは、命名階層構造の各ディレクトリが単一のカリフォルニアによって制御されます。 各カリフォルニアは任意に親ディレクトリのカリフォルニア、それぞれの子供ディレクトリのCAsを公認します。命名階層構造(主に一般的な先祖までのディレクトリがCAsを欠いているところでケースに対処する)におけるほかの場所のCAs。 元本には、信じられた権威として単一のカリフォルニアしかありませんが、それは「カリフォルニア階層構造を歩きます」でしっかりと名前空間におけるどんな主体の公開鍵も得ることができます。
1.5.4 Transfer
1.5.4 転送
The DASS exchange of authentication information is illustrated in Figure 1-1. During the transfer phase, the DASS claimant sends an authentication token to the verifier. Authentication tokens are made by invoking the create_token primitive. The authentication token is
認証情報のダスの交換は図1-1で例証されます。 転送段階の間、ダス主張者は認証トークンを検証に送ります。 認証トークンが呼び出すことによって作られている、原始的に_トークンを作成してください。 認証トークンはそうです。
Kaufman [Page 22] RFC 1507 DASS September 1993
コーフマン[22ページ]RFC1507ダス1993年9月
cryptographically protected and specified as a DASS data structure in ASN.1. The authentication token includes:
暗号で保護されていてASN.1のダスデータ構造として指定されています。 認証トークンは:
- a ticket,
- チケット
- a DES authenticating key encrypted using the intended
verifier's public key
- 意図している検証の公開鍵を使用することで暗号化されたキーを認証するDES
- one of the following:
- 以下の1つ:
. if delegation is not being performed, a digital signature on
the encrypted DES key using the delegation private key, or
または. 実行される暗号化されたDESにおけるデジタル署名が委譲であるなら委譲秘密鍵を使用することで主要でない。
. if delegation is being performed, sending the delegation
private key, DES encrypted using the DES authenticating key
委譲秘密鍵、キーを認証しながらDESを使用することで暗号化されたDESを送って、委譲は実行されています。
- an authenticator, which is a cryptographic checksum made using
the DES authenticating key over a buffer containing
- 固有識別文字。(その固有識別文字はバッファ含有の上で主要なDES認証を使用することで作られた暗号のチェックサムです)。
. a timestamp
. タイムスタンプ
. any application supplied "channel bindings". For example,
addresses or other context information. The purpose of this
field is to thwart substitution and replay attacks.
. どんなアプリケーションも「チャンネル結合」を供給しました。 例えば、アドレスか他の文脈情報。 この分野の目的は代替と反射攻撃を阻むことです。
- additional optional information concerning node authentication
and context.
- ノード認証と文脈の追加任意の情報。
As a side effect, after init_authentication_context, the caller receives a local authentication context, a data structure containing:
副作用として、イニット_認証_文脈の後に、訪問者はローカルの認証関係、以下を含むデータ構造を受けます。
- the DES key, and
- そしてDESキー。
- if mutual authentication is being requested, the expected
response.
- 互いの認証が要求されているなら、予想された応答です。
In order to construct an authentication token, the claimant needs to access the verifier's public key certificate from the Name Service (labeled CDC, for Certificate Distribution Center, in the figure).
認証トークンを構成するために、主張者は、Name Service(図のCertificate DistributionセンターのためにCDCとラベルされる)から検証の公開鍵証明書にアクセスする必要があります。
Note that while an authenticator can only be used once, it is permissible to re-establish the same local authentication context multiple times. That is, the ticket and DES key establishment components of the authentication token may have a relatively long lifetime. This permits a performance improvement in that repeated applications of public key operations can be alleviated if one caches authentication contexts, along with other components from a successfully used authentication token and the associated verified
一度固有識別文字を使用できるだけですが、同じローカルの認証関係を複数の回復職させるのが許されていることに注意してください。 すなわち、認証トークンのチケットとDESの主要な設立の部品には、比較的長い寿命があるかもしれません。 これは1つが認証文脈をキャッシュするなら公開鍵操作の繰り返された応用を軽減できるという点で性能改良を可能にします、首尾よく使用された認証トークンと関連から確かめられた他のコンポーネントと共に
Kaufman [Page 23] RFC 1507 DASS September 1993
コーフマン[23ページ]RFC1507ダス1993年9月
principal public key value. It is a relatively inexpensive operation to create (and verify) "fresh" authenticators based on cached authentication context.
主要な公開鍵値。 それが作成する比較的安価な操作である、(検証、)、「新鮮な」固有識別文字はキャッシュされた認証文脈を基礎づけました。
Claimant Actions | Communications | Verifier Actions
| |
verifier name | |
| | |
| | +---+|
\------------------->| ||
trusted | | ||
authorities | |CDC||
| +-----------+ |certificate| ||
| | Verify |<-------------| ||
\--->|Certificate| | +---+|
+-----------+ | |
Claimant | | |
credentials Verifier | | Verifier
| Public Key | | Credentials
| | | | |
| V | | V
| +-----------+ | Authentication | +-----------+
| | Make | | Token | | Check | Replay
\--->| Token |-------------------->| Token |<-->Cache
+-----------+ | | +-----------+
DES <---/ | | | | | \----->DES
key | | | /Claimant key
| | |/Public Key
| | / | trusted
| | Claimant /| V authorities
| |+---+ Name / | +-----------+ |
authentication || |<-------/ | | Verify |<----/
context || |certificate| |Certificate|
| ||CDC|------------>| |-->accept/
| || | | +-----------+ reject
| || | | | \
| |+---+ |authentication\
V | mutual | context V
+-----------+ | authentication | | claimant
/--| Accept | | response | +----------+credentials
V | Mutual |<--------------------| Make |(delegation)
accept/ +-----------+ | | | Response |
reject | | +----------+
| |
主張者動作| コミュニケーション| 検証動作| | 検証名| | | | | | | +---+| \------------------->| || 信じられます。| | || 当局| |CDC|| | +-----------+ |証明書| || | | 確かめます。| <、-、-、-、-、-、-、-、-、-、-、-、--、| || \--->|証明書| | +---+| +-----------+ | | 主張者| | | 資格証明書Verifier| | 検証| 公開鍵| | 資格証明書| | | | | | V| | V| +-----------+ | 認証| +-----------+ | | 造| | トークン| | チェック| 再生\--->| トークン|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| トークン| <-->キャッシュ+-----------+ | | +-----------+ デス<。---/ | | | | | \----->DESキー| | | /主張者キー| | |/公開鍵| | / | 信じられます。| | 主張者/| V当局| |+---+ 名前/| +-----------+ | 認証|| | <、-、-、-、-、-、--/ | | 確かめます。| <、-、-、--/文脈|| |証明書| |証明書| | ||CDC|、-、-、-、-、-、-、-、-、-、-、--、>| |-->は/を受け入れます。| || | | +-----------+ 廃棄物| || | | | \ | |+---+ |認証\V| 互い| 文脈V+-----------+ | 認証| | 主張者/--| 受け入れてください。| | 応答| +----------+ 資格証明書V| 互い| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| 造|(委譲) /+を受け入れてください。-----------+ | | | 応答| 廃棄物| | +----------+ | |
Figure 1 - Authentication Exchange Overview
図1--認証交換概要
Kaufman [Page 24] RFC 1507 DASS September 1993
コーフマン[24ページ]RFC1507ダス1993年9月
1.5.5 Verification
1.5.5 検証
Upon receipt of an authentication token, the verifier extracts the DES key using its verifier credentials, accesses the Name Service (labeled CDC for Certificate Distribution Center) to obtain the certificates needed to perform cryptographic checks on the incoming information, and verifies all of the signatures on the received certificates and the authentication token. Verification can result in creation of new claimant credentials if delegation is performed.
認証トークンを受け取り次第、検証は、検証資格証明書を使用することでDESキーを抽出して、入って来る情報に暗号のチェックを実行するのが必要である証明書を入手するために、Name Service(Certificate DistributionセンターのためにCDCとラベルされる)にアクセスして、受け取られていている証明書と認証トークンで署名のすべてについて確かめます。 委譲が実行されるなら、検証は新しい主張者資格証明書の作成をもたらすことができます。
As part of this process, verified authenticators are retained for a suitable timeout period.
このプロセスの一部として、確かめられた固有識別文字は適当なタイムアウト時間の間、保有されます。
1.5.6 Unenrolment
1.5.6 Unenrolment
This is the removal of information from the Name Service. The only other form of revocation supported by DASS is certificate timeout. Every certificate contains an expiration time (expected in ordinary use to be about a year from its signing date). DASS does not currently support the revocation lists in X.509.
これはName Serviceからの情報の取り外しです。 ダスによってサポートされた他の唯一の形式の取消しは証明書タイムアウトです。 あらゆる証明書が満了時間(普通の使用で、署名日付からおよそ1年であると予想する)を含んでいます。 ダスは、現在、取消しがX.509のリストであるとサポートしません。
2. Services Used
2. 利用されたサービス
Aside from operating system services needed to maintain its internal state, DASS relies on a global distributed database in which to store its certificates, a reliable source of time, and a source of random numbers for creating cryptographic keys.
内部の状態を維持するのに必要であるオペレーティングシステムサービスは別として、ダスは暗号化キーを作成するために証明書、時間の信頼すべき筋、および乱数の源を保存するグローバルな分散データベースを当てにします。
2.1 Time Service
2.1 時間指定サービス
DASS requires access to the current time in several of its algorithms. Some of its uses of time are security critical. In others, network synchronization of clocks is required. DASS does not, however, depend on having a single source of time which is both secure and tightly synchronized.
ダスはいくつかのアルゴリズムで現在の時間へのアクセスを必要とします。時間の用途のいくつかがセキュリティ重要です。 他のものでは、時計のネットワーク同期が必要です。 しかしながら、ダスは両方である時間の単独の源を安全でしっかり連動するようにするのを当てにしません。
The requirements on system provided time are:
システムの提供された時の要件は以下の通りです。
- For purposes of validating certificates and tickets, the
system needs access to know the date and time accurate to
within a few hours with no particular synchronization
requirements. If this time is inaccurate, then valid requests
may be rejected and expired messages may be accepted.
Certificate expiration is a backup revocation mechanism, so
this can only cause a security compromise in the event of
multiple failures. In theory, this could be provided by
having a local clock on every node accurate to within a few
hours over the life of the product to provide this function.
- 特定の同期要件なしで証明書、チケット、必要性が日付を知るためにアクセスするシステム、および数時間に正確な時間を有効にする目的のために。 今回が不正確であるなら、有効な要求を拒絶するかもしれません、そして、満期のメッセージを受け入れるかもしれません。 証明書満了がバックアップ取消しメカニズムであるので、これは複数の失敗の場合、セキュリティ感染を引き起こすだけである場合があります。 理論上、この機能を提供するために製品の寿命の上であらゆるノードの上の地方の時計を正確に数時間まですることによって、これを提供できるでしょう。
Kaufman [Page 25] RFC 1507 DASS September 1993
コーフマン[25ページ]RFC1507ダス1993年9月
If an insecure network time service is used to provide this
time, there are theoretical security threats, but they are
expected to be logistically impractical to exploit.
不安定なネットワーク時間指定サービスが今回提供するのに使用されるなら、理論上の軍事的脅威がありますが、利用するためにロジスティックに非実用的であると予想されます。
- For purposes of detecting replay of authentication tokens, the
system needs access to a strictly monotonic time source which
is reasonably synchronized across the network (within a few
minutes) for the system to work, but inaccuracy does not
present a security threat except as noted below. It may
constitute an availability threat because valid requests may
be rejected. In order to get strict monotonicity in the
presence of a rapid series of requests, time must be returned
with high precision. There is no requirement for a high
degree of accuracy. Inaccurate time could present a security
threat in the following scenario: if a client's clock is made
sufficiently fast that its tokens are rejected, someone
harvesting those tokens from the wire could replay them later
and impersonate the client. In some environments, this might
be an easier threat than harvesting tokens and preventing
their delivery.
- 認証トークンの再生を検出する目的のために、システムはシステムが扱うネットワーク(数分以内の)の向こう側に合理的に同期する厳密に単調な時間ソースへのアクセスを必要としますが、以下に述べられる以外に、不正確は軍事的脅威を提示しません。 有効な要求が拒絶されるかもしれないので、それは有用性の脅威を構成するかもしれません。 急速なシリーズの要求があるとき厳しい単調を得るために、高い精度と共に時間を返さなければなりません。 高精度のための要件が全くありません。 不正確な時間は以下のシナリオにおける軍事的脅威を提示するかもしれません: クライアントの時計が十分速く作られるなら、だれかがワイヤからそれらのトークンを取り入れて、トークンが拒絶されるのが、後でそれらを再演して、クライアントをまねるかもしれません。 いくつかの環境で、これはトークンを取り入れて、彼らの配送を防ぐより簡単な脅威であるかもしれません。
- For purposes of aging stale entries from caches, DASS requires
reasonably accurate timing of intervals. To the extent that
intervals are reported as shorter than the actually were,
revocation of certificates from the naming service may not be
as timely as it should be.
- キャッシュから聞き古したエントリーの年をとる目的のために、ダスは間隔の合理的に正確なタイミングを必要とします。 間隔が、より短いとして報告されるという範囲、実際にあった、名前付けサービスからの証明書の取消しはそれであるべきであるほどタイムリーでないかもしれません。
2.2 Random Numbers
2.2 無作為の数
In order to generate keys, DASS needs a source of "cryptographic quality" random numbers. Cryptographic quality means that knowing any of the "random numbers" returned from a series and knowing all state information which is not protected, an attacker cannot predict any of the other numbers in the series. Hardware sources are ideal, but there are alternative techniques which may also be acceptable. A 56 bit "truly random" seed (say from a series of coin tosses) could be used as a DES key to encrypt an infinite length known text block in CBC mode to produce a pseudo-rand sequence provided the key and current point in the sequence were adequately protected. There is considerable controversy surrounding what constitutes cryptographic quality random numbers, and it is not a goal of this document to resolve it.
キーを生成するために、ダスは「暗号の品質」無作為の数の源を必要とします。 暗号の品質は、「乱数」のどれかがシリーズから戻ったのを知っていて、保護されないすべての州の情報を知っていて、攻撃者がシリーズにおける他の数のどれかを予測できないことを意味します。 ハードウェアソースは理想的ですが、また、許容できるかもしれない代替のテクニックがあります。 56の噛み付いている「本当に無作為」の種子(一連のコイントスから、言う)は無限の長さを暗号化するために主要なDESとして使用されて、系列で系列が主要で現在のポイントを提供した疑似底ならし革を作り出すCBCモードによる知られているテキストブロックが適切に保護されたということであるかもしれません。 暗号の上質の乱数を構成することを囲む大きな論争があります、そして、それはそれを決議するこのドキュメントの目標ではありません。
2.3 Naming Service
2.3 名前付けサービス
DASS stores creates and uses "certificates" associated with every principal in the system, and encrypted credentials associated with most. This information is stored in an on-line service
ダス店は、関連している暗号化されたあらゆる主体がシステムにある、大部分に関連している資格証明書で「証明書」を作成して、使用します。 この情報はパソコン通信で保存されます。
Kaufman [Page 26] RFC 1507 DASS September 1993
コーフマン[26ページ]RFC1507ダス1993年9月
associated with the principal being certified. The long term vision is for DASS to use an X.500 naming service, and DASS will from its inception authenticate X.500 names. To avoid a dependence on having an X.500 naming service available (and to gain the benefits of a "login agent" that controls password guessing), an alternative certificate distribution center protocol is also described.
公認される主体に関連しています。 長期ビジョンがダスがX.500名前付けサービスを使用することであり、ダスは始まりからX.500名を認証するでしょう。 また、利用可能な(パスワード推測を制御する「ログインエージェント」の利益を獲得するために)X.500名前付けサービスを持っていることへの依存を避けるために、代替の証明書配送センタープロトコルは説明されます。
The specific requirements DASS places on the naming service are:
名前付けサービスの決められた一定の要求ダス場所は以下の通りです。
- It must be highly available. A user's naming service entry
must be available to any node where the user is to obtain
services (or service will be denied). A server's naming
service entry must be available from any node from which the
service is to be invoked (or service will be denied).
- それは非常に利用可能でなければなりません。 ユーザの名前付けサービスエントリーはユーザがサービスを得ることになっている(サービスは否定されるでしょう)どんなノードにも利用可能であるに違いありません。 サーバの名前付けサービスエントリーは呼び出されるサービスがことであるどんなノードからも利用可能であるに違いありません(サービスは否定されるでしょう)。
- It must be timely. The presence of "stale" information in the
naming service may cause some problems. When a password
changes, the old password may remain valid (and the new
password invalid) to the extent the naming service provides
stale information. When a user or server is added to the
network, it will not be able to participate in authentication
until the information added to the naming service is available
at the node doing the authentication. In the unusual
circumstance that a key changes, the entity whose key has
changed will not be able to use the new key until the new
certificate is uniformly available.
- それはタイムリーであるに違いありません。 名前付けサービスにおける、「聞き古した」情報の存在はいくつかの問題を引き起こすかもしれません。パスワードが変化するとき、古いパスワードは名前付けサービスが聞き古した情報を提供するという範囲に有効なままで(そして、新しいパスワード病人)残るかもしれません。 ユーザかサーバがネットワークに追加されるとき、名前付けサービスに加えられた情報が認証しながらノードで利用可能になるまで、それは認証に参加できないでしょう。 キーが変える珍しい状況では、新しい証明書が一様に利用可能になるまで、キーが変化した実体は新しいキーを使用できないでしょう。
- It must be secure with regard to certain specific properties.
In general, the security of DASS protected applications does
not depend on the security of the naming service. It is
expected that the availability needs of the naming service
will prevent it from being as secure as some applications need
to be. There are two aspects of DASS security which do depend
on the security of the naming service: timely revocation of
certificates and protection of user secrets against dictionary
based password guessing. DASS depends on the removal of
certificates from the naming service in order to revoke them
more quickly than waiting for them to time out. For this
mechanism to provide any actual security, it must not be
possible for a network entity to "impersonate" the naming
service and the naming service must be able to enforce access
controls which prevent a revoked certificate from being
reinstated by an unauthorized entity. In the long run, it is
expected that DASS itself will be used to secure the naming
service, which presents certain potential recursion problems
(to be addressed in the naming service design). If the naming
service is not authenticated (as is expected in early
- それはある特定の性質に関して安全であるに違いありません。 一般に、保護されたアプリケーションがするダスのセキュリティは名前付けサービスのセキュリティによりません。 名前付けサービスの有用性の必要性が、いくつかのアプリケーションが、必要があるのとそれが同じくらい安全であることを防ぐと予想されます。 名前付けサービスのセキュリティによるダスセキュリティの2つの局面があります: 証明書のタイムリーな取消しと辞書に対するユーザ秘密の保護はパスワード推測を基礎づけました。 ダスは、タイムアウトにそれらを待つよりはやくそれらを取り消すために名前付けサービスからの証明書の取り外しを当てにします。 このメカニズムがどんな実際のセキュリティも提供するように、ネットワーク実体が名前付けサービスと名前付けサービスを「まねること」が取り消された証明書が権限のない実体で復職するのを防ぐアクセス制御を実施できなければならないのは、可能であるはずがありません。 結局、ダス自身が、ある潜在的再帰問題(名前付けサービスデザインで扱われる)を提示する名前付けサービスを保証するのに使用されると予想されます。 名前付けサービスが認証されない、(早いところでは、予想されます。
Kaufman [Page 27] RFC 1507 DASS September 1993
コーフマン[27ページ]RFC1507ダス1993年9月
versions) attacks where a revoked certificate is "reinstated"
through impersonation of the naming service are possible.
バージョン) 取り消された証明書が名前付けサービスのものまねで「復職するところ」で攻撃は可能です。
The specific functions DASS requests of the naming service are simple:
名前付けサービスの具体的な機能ダスの要求は簡単です:
- Given an X.500 name, store a set of certificates associated
with that name.
- X.500名を考えて、その名前に関連している証明書のセットを保存してください。
- Given an X.500 name, retrieve the set of certificates
associated with that name.
- X.500名を考えて、その名前に関連している証明書のセットを検索してください。
- Given an X.500 name, store a set of encrypted credentials
associated with that name.
- X.500名を考えて、その名前に関連している暗号化された資格証明書のセットを保存してください。
- Given and X.500 name, retrieve a set of encrypted credentials
associated with that name.
- 与えてX.500名義であり、その名前に関連している暗号化された資格証明書のセットを検索してください。
Implementation over a particular naming service may implement more specialized functions for reasons of efficiency. For example, the certificates associated with a name may be separated into several sets (child, parent, cross, self) so that only the relevant ones may be retrieved. In order that access to the naming service itself be secure, the protocols should be authenticated. Certificates should generally be readable without authentication in order to avoid recursion problems. Requests to read encrypted credentials should be specialized and should include proof of knowledge of the password in order that the naming service can audit and slow down false password guesses.
特定の名前付けサービスの上の実装は効率の理由で、より専門化している機能を実装するかもしれません。 例えば、名前に関連している証明書は、関連検索できないように数セット(子供、親は横断します、自己)に切り離されるかもしれません。 それ自体に名前付けサービスにアクセスしてください。安全にしてください、そして、プロトコルは認証されるべきです。 一般に、証明書は、再帰問題を避けるために認証なしで読み込み可能であるべきです。暗号化された資格証明書を読むという要求は、専門にされるべきであり、名前付けサービスが誤ったパスワード推測を監査して、減速させることができるように、パスワードに関する知識の証拠を含むべきです。
The following sections describe the interfaces to specific naming services:
以下のセクションは特定の名前付けサービスにインタフェースについて説明します:
2.3.1 Interface to X.500
2.3.1 X.500に連結してください。
Certificates associated with a particular name are stored as attributes of the entry as specified in X.509. X.509 defines attributes appropriate for parent and cross certificates (CrossCertificatePair, CACertificate) for some principals; we will have to define a DASSUserPrincipal object class including these attributes in order to properly use them with ordinary users. Retrieval is via normal X.500 protocols. Certificates should be world readable and modifiable only by appropriate authorities.
特定の名前に関連している証明書はX.509の指定されるとしてのエントリーの属性として保存されます。 X.509はいくつかの主体のための親にとって、適切な属性と交差している証明書(CrossCertificatePair、CACertificate)を定義します。 私たちは、一般ユーザと共にそれらを適切に使用するためにこれらの属性を含むDASSUserPrincipalオブジェクトのクラスを定義しなければならないでしょう。 検索が正常なX.500プロトコルであります。 証明書は単に適切な当局が読み込み可能で修正できる世界であるべきです。
Encrypted credentials are stored with the entry of the principal under a yet to be defined attribute. The credentials should be encoded as specified in section 4. In the absence of extensions to the X.500 protocol to control password guessing, the encrypted
暗号化された資格証明書はまだ定義されなかった属性の下で主体のエントリーで保存されます。 資格証明書はセクション4で指定されるようにコード化されるべきです。 制御用パスワード推測、暗号化へのX.500プロトコルへの拡大がないとき
Kaufman [Page 28] RFC 1507 DASS September 1993
コーフマン[28ページ]RFC1507ダス1993年9月
credentials should be world readable and updatable only by the named principal and other appropriate authorities.
資格証明書は世界の読み込み可能で命名された主体だけでアップデート可能であって他の適切な当局であるべきです。
2.3.2 Interface to CDC
2.3.2 CDCに連結してください。
The CDC (Certificate Distribution Center) is a special purpose name server created to service DASS until an X.500 service is available in all of the environments where DASS needs to operate. The CDC uses a special purpose protocol to communicate with DASS clients. The protocol was designed for efficiency, simplicity, and security. CDCs use DASS as an authentication mechanism and to protect encrypted credentials from unaudited password guessing.
CDC(証明書Distributionセンター)はX.500サービスがダスが作動する必要があるところで環境で全部で利用可能になるまでダスにサービスを提供するために作成された専用ネームサーバです。 CDCは、ダスクライアントとコミュニケートするのに専用プロトコルを使用します。 プロトコルは効率、簡単さ、およびセキュリティのために設計されました。 CDCは認証機構としてダスを使用します、そして、保護するのは非監査のパスワード推測から資格証明書を暗号化しました。
Each DASS client maintains a list of CDCs and the portion of the namespace served by that CDC. Each directory has a master replica which is the only one which will accept updates. The CDCs maintain consistency with one another using protocols beyond the scope of this document. When a DASS client wishes to make a request of a CDC, it opens a TCP or DECnet connection to the CDC and sends an ASN.1 (BER) encoded request and receives a corresponding ASN.1 (BER) encoded response. Clients are expected to learn the IP or DECnet address and port number of the CDC supporting a particular name from a local configuration file. To maximize performance, the requests bundle what would be several requests if made in terms of requests for individual certificates. It is intended that all certificates needed for an authentication operation be retrievable with at most two CDC requests/responses (one to the CDC of the client and one to the CDC of the server).
それぞれのダスクライアントはそのCDCによって役立たれるCDCのリストと名前空間の部分を維持します。 各ディレクトリには、アップデートを受け入れる唯一無二であるマスターレプリカがあります。 CDCはお互いがこのドキュメントの範囲を超えてプロトコルを使用している一貫性を維持します。 ダスクライアントがCDCの要求をしたがっているとき、それは、TCPかDECnet接続をCDCに開いて、ASN.1(BER)のコード化された要求を送って、対応するASN.1(BER)のコード化された応答を受けます。 クライアントがローカルの構成ファイルから特定の名前をサポートするCDCのIPかDECnetアドレスとポートナンバーを学ぶと予想されます。 性能を最大にするために、要求は個々の証明書に関する要求で作られるならいくつかの要求であることを添付します。 認証操作に必要であるすべての証明書が高々2つのCDC要求/応答(クライアントのCDCへの1とサーバのCDCへの1)で回収可能であることを意図します。
Documented here is the protocol a DASS client would use to retrieve certificates and credentials from a CDC and update a user password. This protocol does not provide for updates to the certificate and credential databases. Such updates must be supported for a practical system, but could be done either by extensions to this protocol or by local security mechanisms implemented on nodes supporting the CDC. Similarly, availability can be enhanced by replicating the CDC. Automating the replication of updates could be implemented by extensions to this protocol or by some other mechanism. This specification assumes that updates and replication are local matters solved by individual CA/CDC implementations.
ここに記録されているのは、ダスクライアントがCDCから証明書と資格証明書を検索して、ユーザパスワードをアップデートするのに使用するプロトコルです。 このプロトコルは証明書と資格証明データベースにアップデートに備えません。 そのようなアップデートが実用的なシステムのためにサポートしなければなりませんでしたが、このプロトコルへの拡大かCDCをサポートしながらノードの上で実装されたローカルのセキュリティー対策でできました。 同様に、CDCを模写することによって、有用性を高めることができます。 このプロトコルへの拡大かある他のメカニズムはアップデートの模写を自動化するのを実装することができました。 この仕様は、アップデートと模写が個々のカリフォルニア/CDC実装によって解決された地域にかかわる事柄であると仮定します。
Requests and responses are encoded as follows:
要求と応答は以下の通りコード化されます:
2.3.2.1 ReadPrinCertRequest
2.3.2.1 ReadPrinCertRequest
This request asks the CDC to return the child certificates and selected incoming cross certificates for the specified object. The format of the request is:
この要求は、指定されたオブジェクトのための子供証明書と選択された入って来る交差している証明書を返すようにCDCに頼みます。 要求の形式は以下の通りです。
Kaufman [Page 29] RFC 1507 DASS September 1993
コーフマン[29ページ]RFC1507ダス1993年9月
ReadPrinCertRequest ::= [4] IMPLICIT SEQUENCE {
flags [0] BIT STRING DEFAULT {},
index [1] IMPLICIT INTEGER DEFAULT 0,
resolveFrom [2] Name OPTIONAL,
principal Name,
crossCertIssuers ListOfIssuers OPTIONAL
}
ListOfIssuers ::= SEQUENCE OF Name
ReadPrinCertRequest:、:= [4] IMPLICIT SEQUENCE、旗[0]BIT STRING DEFAULT、インデックス[1]IMPLICIT INTEGER DEFAULT0、resolveFrom[2]はOPTIONALを命名します、主要なName、crossCertIssuers ListOfIssuers OPTIONAL、ListOfIssuers:、:= 名前の系列
The first 24 bits of flags, if present, contain a protocol version number. Clients following this spec should place the value 2.0.0 in the three bytes. Servers following this spec should accept any value of the form 1.x.x or 2.x.x. flags bits beyond the first 24 are reserved for future use (should not be supplied by clients and should be ignored by servers).
存在しているなら、旗の最初の24ビットはプロトコルバージョン番号を含んでいます。 この仕様の後をつけるクライアントは3バイトにおける値2.0の.0を置くべきです。 この仕様に続くサーバがフォーム1.x.xのどんな値も受け入れるべきですか、またはビット最初の24を超えた2.x.x.旗は今後の使用(クライアントが供給するべきでなくて、サーバは無視するべきである)のために予約されます。
index is only used if the response exceeds the size of a single message; in that case, the query is repeated with index set to the value that was returned by ReadPrinCertResponse. resolveFrom and principal imply a set of entities for which certificates should be retrieved. resolveFrom (if present) must be an ancestor of principal and child certificates will be retrieved for principal and all names which are ancestors of principal but descendants of resolveFrom. The encoding of names is per X.500 and is specified in more detail in section 4. The CDC returns the certificates in order of the object they came from, parents before children.
応答がただ一つのメッセージのサイズを超えている場合にだけ、インデックスは使用されます。 ReadPrinCertResponse. resolveFromと主体で返して、証明書が検索されるべきである1セットの実体を含意してください。その場合、質問はインデックスセットでresolveFrom(存在しているなら)が主体の先祖であるに違いないということであった値に繰り返されます、そして、子供証明書は主体の先祖にもかかわらず、resolveFromの子孫である主体とすべての名前のために検索されるでしょう。 名前のコード化は、X.500単位であって、さらに詳細にセクション4で指定されます。 CDCは、それらが来たオブジェクトの順に証明書を返して、以前、子供の親代わりとなります。
crossCertIssuers is a list of cross certifiers that would be believed in the context of this authentication. If supplied, the CDC may return a chain of certificates starting with one of the named crossCertIssuers and ending with the named principal. One of resolveFrom or crossCertIssuers must be present in any request; if both are present, the CDC may return either chain.
crossCertIssuersは交差しているこの認証の文脈が信じられている証明することのリストです。 供給するなら、命名された主体で命名されたcrossCertIssuersと結末の1つから始めて、CDCは証明書のチェーンを返すかもしれません。 resolveFromかcrossCertIssuersの1つはどんな要求にも存在していなければなりません。 両方が存在しているなら、CDCはチェーンを返すかもしれません。
2.3.2.2 ReadPrinCertResponse
2.3.2.2 ReadPrinCertResponse
This is the response a CDC sends to a ReadPrinCertRequest. Its syntax is:
これはCDCがReadPrinCertRequestに送る応答です。 構文は以下の通りです。
ReadPrinCertResponse ::= [5] IMPLICIT SEQUENCE {
status [0] IMPLICIT CDCstatus DEFAULT success,
index [1] INTEGER OPTIONAL,
resolveTo [2] Name OPTIONAL,
certSequence [3] IMPLICIT CertSequence,
indexInvalidator [4] OCTET STRING (SIZE(8)) OPTIONAL,
flags [5] BIT STRING OPTIONAL
}
CertSequence ::= SEQUENCE OF Certificate
ReadPrinCertResponse:、:= [5] IMPLICIT SEQUENCE、状態[0]IMPLICIT CDCstatus DEFAULT成功、インデックス[1]INTEGER OPTIONAL、resolveTo[2]はOPTIONALを命名します、certSequence[3]IMPLICIT CertSequence、indexInvalidator[4]OCTET STRING、(SIZE(8)) OPTIONAL、旗[5]BIT STRING OPTIONAL、CertSequence:、:= 証明書の系列
Kaufman [Page 30] RFC 1507 DASS September 1993
コーフマン[30ページ]RFC1507ダス1993年9月
status indicates success or the cause of the failure.
状態は失敗の成功か原因を示します。
index if present indicates that the request could not be fully satisfied in a single request because of size limitations. The request should be repeated with this index supplied in the request to get more.
プレゼントが、要望がサイズ制限のためにただ一つの要求で完全に応じることができたというわけではないのを示すなら、索引をつけてください。 要求は以上を得るという要求でこのインデックスを供給している状態で繰り返されるべきです。
resolveTo will be present if index is present and should be supplied in the request for more certificates. certSequence contains certificates found matching the search criteria.
インデックスを存在していて、より多くの証明書に関する要求で供給すると、resolveToは存在するでしょう。certSequenceは検索評価基準を合わせているのが見つけられた証明書を含んでいます。
indexInvalidator may be present and indicates the version of the database being read. If a set of certificates is being read in multiple requests (because there were too many to return in a single message), the reader should check that the value for indexInvalidator is the same on each request. If it is not, the server may have skipped or duplicated some certificates. This field must not be present if the version number in the request was missing or version 1.x.x.
indexInvalidatorは存在しているかもしれなくて、読まれるデータベースのバージョンを示します。 1セットの証明書が複数の要求で読まれているなら(ただ一つのメッセージで戻るために多く過ぎるのがあるので)、読者は、indexInvalidatorのための値が各要求のときに同じであることをチェックするべきです。 それがそうでないなら、サーバは、いくつかの証明書をスキップしたか、またはコピーしたかもしれません。 この分野は要求におけるバージョン番号が取り逃がすかバージョン1.x.xであったなら存在しているはずがありません。
The first 24 bits of flags, if present, indicate the protocol version number. Implementers of this version of the spec should supply 2.0.0 and should accept any version number of the form 1.x.x or 2.x.x.
存在しているなら、旗の最初の24ビットはプロトコルバージョン番号を示します。 そして、仕様のこのバージョンのImplementersが供給するはずである、2.0、.0、フォーム1.x.xか2.x.xのどんなバージョン番号も受け入れるべきです。
2.3.2.3 ReadOutgoingCertRequest
2.3.2.3 ReadOutgoingCertRequest
This requests from the CDC a list of all parent and outgoing cross certificates for a specified object. A CDC is capable of storing cross certificates either with the subject or the issuer of the cross certificate. In response to this request, the CDC will return all parent and cross certificates stored with the issuer for the named principal and all of its ancestors. Its syntax is:
これはCDCから指定されたオブジェクトのためのすべての親と送信する交差している証明書のリストを要求します。 CDCは交差している証明書の対象か発行人と共に交差している証明書を保存できます。 この要求に対応して、CDCは、先祖の命名された主体とすべてのためにすべての親を返して、発行人と共に保存された証明書に交差するでしょう。 構文は以下の通りです。
ReadOutgoingCertRequest ::= [6] IMPLICIT SEQUENCE {
flags [0] BIT STRING DEFAULT {},
index [1] IMPLICIT INTEGER DEFAULT 0,
principal Name
}
ReadOutgoingCertRequest:、:= [6] 暗黙の系列旗[0]BIT STRING DEFAULT、[1] IMPLICIT INTEGER DEFAULT0、主要なNameに索引をつけてください。
The first 24 bits of flags is a protocol version number and should contain 2.0.0 for clients implementing this version of the spec. Servers implementing this version of the spec should accept any version number of the form 1.x.x or 2.x.x. The remaining bits are reserved for future use (they should not be supplied by clients and they should be ignored by servers).
旗の最初の24ビットがaプロトコルバージョン番号であり、含むはずである、2.0、.0、仕様のこのバージョンを実装するクライアントのために。 仕様のこのバージョンを実装するサーバはフォーム1.x.xか2.x.xのどんなバージョン番号も受け入れるべきです。 残っているビットは今後の使用のために予約されます(クライアントがそれらを供給するべきではありません、そして、サーバは彼らを無視するべきです)。
index is used for continuation (see ReadPrinCertRequest).
インデックスは継続に使用されます(ReadPrinCertRequestを見てください)。
Kaufman [Page 31] RFC 1507 DASS September 1993
コーフマン[31ページ]RFC1507ダス1993年9月
principal is the name for which certificates are requested.
主体は証明書が要求されている名前です。
2.3.2.4 ReadOutgoingCertResponse
2.3.2.4 ReadOutgoingCertResponse
This is the response to a ReadOutgoingCertRequest. Its syntax is:
これはReadOutgoingCertRequestへの応答です。 構文は以下の通りです。
ReadOutgoingCertResponse::= [7] IMPLICIT SEQUENCE {
status [0] IMPLICIT CDCStatus DEFAULT success,
index [1] INTEGER OPTIONAL,
certSequence [2] IMPLICIT CertSequence,
indexInvalidator [3] OCTET STRING (SIZE(8))
OPTIONAL,
flags [4] BIT STRING OPTIONAL
}
ReadOutgoingCertResponse:、:= [7] 暗黙の系列状態[0]IMPLICIT CDCStatus DEFAULT成功、インデックス[1]INTEGER OPTIONAL、certSequence[2]IMPLICIT CertSequence、indexInvalidator[3]OCTET STRING、(SIZE(8)) OPTIONAL、旗[4]BIT STRING OPTIONAL
CertSequence ::= SEQUENCE OF Certificate
CertSequence:、:= 証明書の系列
status indicates success of the cause of failure of the operation.
状態は操作の失敗の原因の成功を示します。
index is used for continuation; see ReadPrinCertRequest.
インデックスは継続に使用されます。 ReadPrinCertRequestを見てください。
certSequence is the list of parent and outgoing cross certificates.
certSequenceは親と送信する交差している証明書のリストです。
indexInvalidator is used for continuation; see ReadPrinCertResponse (the same rules apply with respect to version numbers).
indexInvalidatorは継続に使用されます。 ReadPrinCertResponseを見てください(同じ規則はバージョン番号に関して適用されます)。
The first 24 bits of flags, if present, contain the protocol version number. Clients implementing this version of the spec should supply the value 2.0.0. Servers should accept any values of the form 1.x.x or 2.x.x. The remaining bits are reserved for future use (they should not be supplied by clients and should be ignored by servers).
存在しているなら、旗の最初の24ビットはプロトコルバージョン番号を含んでいます。 仕様のこのバージョンを実装するクライアントは値2.0の.0を供給するべきです。 サーバはフォーム1.x.xか2.x.xのどんな値も受け入れるべきです。 残っているビットは今後の使用のために予約されます(それらをクライアントが供給するべきでなくて、サーバは無視するべきです)。
2.3.2.5 ReadCredentialRequest
2.3.2.5 ReadCredentialRequest
This request is made to retrieve an principal's encrypted credentials. To prevent unaudited password guessing, this structure includes an encrypted value that proves that the requester knows the password that will decrypt the structure. The syntax of the request is:
元本の暗号化された資格証明書を検索するのをこの要求をします。 非監査のパスワード推測を防ぐために、この構造はリクエスタが構造を解読するパスワードを知っていると立証する暗号化された値を含んでいます。 要求の構文は以下の通りです。
ReadCredentialRequest ::= [2] IMPLICIT SEQUENCE {
flags [0] BIT STRING DEFAULT {}
principal Name,
logindata [2] BIT STRING DEFAULT {},
token [3] BIT STRING OPTIONAL
}
ReadCredentialRequest:、:= [2] 暗黙の系列旗[0]BIT STRING DEFAULT、主要なName、logindata[2]BIT STRING DEFAULT、トークン[3]BIT STRING OPTIONAL
Kaufman [Page 32] RFC 1507 DASS September 1993
コーフマン[32ページ]RFC1507ダス1993年9月
The first 24 bits of flags contains the version number of the protocol. The value 2.0.0 should be supplied. Any value of the form 1.x.x or 2.x.x should be accepted. Any additional bits are reserved for future use (should not be supplied by clients and should be ignored by servers).
旗の最初の24ビットはプロトコルのバージョン番号を含んでいます。 値2.0の.0を供給するべきです。 フォーム1.x.xか2.x.xのどんな値も受け入れるべきです。 どんな追加ビットも今後の使用(クライアントが供給するべきでなくて、サーバは無視するべきである)のために予約されます。
principal is the name of the principal for whom encrypted credentials are desired.
主体は暗号化された資格証明書が望まれている主体の名前です。
logindata is an encrypted value. It may only be present if the version number is 2.0.0 or higher. It must be present to read credentials which are protected by the login agent functionality of the CDC. It is constructed as a single RSA block encrypted under the public key of the CDC. The public key of the CDC is learned by some local means. Possibilities include a local configuration file or by using DASS to read and verify a chain of certificates ending with the CDC [the CDC serving a directory should have its public key listed under a name consisting of the directory name with the RDN "CSS=X509"; the OID for the type CSS is 1.3.24.9.1]. The contents of the block are as follows:
logindataは暗号化された値です。 バージョン番号が存在している場合にだけ、存在しているかもしれません。2.0 .0以上。 CDCのログインエージェントの機能性によって保護される資格証明書を読むのは存在していなければなりません。 それはCDCの公開鍵の下で暗号化された1つのRSAブロックとして組み立てられます。 CDCの公開鍵はいくつかのローカルの手段によって学習されます。 ポシビリティーズは、ローカルの構成ファイルを含んでいるか、またはCDCで終わりながら証明書のチェーンを読んで、確かめるのにダスを使用することによって、そうします。タイプCSSのためのOIDはそうです。[ディレクトリに役立つCDCで、RDN"CSS=X509"と共にディレクトリ名から成る名前の下で公開鍵を記載するべきです;、1.3 .24 .9 .1]。 ブロックの内容は以下の通りです:
- The low order eight bytes contain a randomly generated DES key
with the last byte of the DES key placed in the last byte of
the RSA block. This DES key will be used by the CDC to
encrypt the response. Key parity bits are ignored.
- 下位8バイトは主要なRSAブロックの最後のバイトに置かれているDESキーの最後のバイトで手当たりしだいに発生しているDESを含んでいます。 このDESキーはCDCによって使用されて、応答を暗号化するでしょう。 主要なパリティビットは無視されます。
- The next to last eight bytes contain a long Posix time with
the integer time encoded as a byte string using big endian
order.
- ベストエイトバイトへの次は、ビッグエンディアンオーダーを使用することで整数時間がバイトストリングとしてコード化されている長いPosix時間を含んでいます。
- The next eight bytes (from the end) contain a hash of the
password. The algorithm for computing this hash is listed in
section 4.4.2. The CDC never computes this hash; it simply
compares the value it receives with the value associated with
the credentials.
- 次の8バイト(終わりからの)はパスワードのハッシュを含んでいます。 このハッシュを計算するためのアルゴリズムはセクション4.4.2で記載されています。 CDCはこのハッシュを決して計算しません。 それは単に資格証明書に関連している値と受ける値を比べます。
- The next sixteen bytes (from the end) contain zero.
- 次の16バイト(終わりからの)はゼロを含んでいます。
- The remainder of the RSA block (which should be the same size
as the public modulus of the CDC) contains a random number.
The first byte should be chosen to be non-zero but so the
value in the block does not exceed the RSA modulus. Servers
should ignore these bits. This random number need not be of
cryptographic strength, but should not be the same value for
all encryptions. Repeating the DES key would be adequate.
- RSAブロック(CDCの公共の係数と同じサイズであるべきである)の残りは乱数を含んでいます。 最初のバイトは非ゼロになるように選ばれるべきですが、したがって、ブロックの値はRSA係数を超えていません。 サーバはこれらのビットを無視するべきです。 この乱数は、暗号の強さがある必要はありませんが、すべての暗号化のための同じ値であるべきではありません。 DESキーを繰り返すのは適切でしょう。
- The byte string thus constructed is encrypted using the RSA
algorithm by treating the string of bytes as a "big endian"
- このようにして構成されたバイトストリングは、「ビッグエンディアン」としてバイトのストリングを扱うことによってRSAアルゴリズムを使用することで暗号化されています。
Kaufman [Page 33] RFC 1507 DASS September 1993
コーフマン[33ページ]RFC1507ダス1993年9月
integer and treating the integer result as "big endian" to
make a string of bytes.
整数と整数を扱うのは、一連のバイトを作るために「ビッグエンディアン」として結果として生じます。
token will not be present in the initial implementation but a space is reserved in case some future implementation wants to authenticate and audit the node from which a user is logging in.
トークンは初期の実装では存在しないでしょうが、何らかの将来の実装がユーザがログインしているノードを認証して、監査したがっている場合でスペースは予約されます。
2.3.2.6 ReadCredentialProtectedResponse
2.3.2.6 ReadCredentialProtectedResponse
This is the second possible response to a ReadPrinLoginRequest. It is returned when the encrypted credentials are protected from password guessing by the CDC acting as a login agent. Its syntax is:
これはReadPrinLoginRequestへの2番目の可能な応答です。 ログインエージェントとして務めるCDCのそばでのパスワード推測から暗号化された資格証明書を保護するとき、それを返します。 構文は以下の通りです。
ReadCredentialProtectedResponse::=[16] IMPLICIT SEQUENCE {
status [0] IMPLICIT CDCStatus DEFAULT success,
encryptedCredential [1] BIT STRING,
flags [2] BIT STRING OPTIONAL
}
ReadCredentialProtectedResponse:、:=[16] 暗黙の系列状態[0]IMPLICIT CDCStatus DEFAULT成功(encryptedCredential[1]BIT STRING)は[2] BIT STRING OPTIONALに旗を揚げさせます。
status indicates that the request succeeded or the cause of the failure.
状態は、要求が成功したのを示します。または、失敗の原因。
encryptedCredential contains the DASSPrivateKey structure (defined in section 4.1) encrypted under a DES key computed from the user's name and password as specified in section 4.4.2 and then reencrypted under the DES key provided in the ReadPrinLoginRequest.
encryptedCredentialはセクション4.4.2における指定されるとしてのユーザの名前とパスワードから計算されたDESキーの下で暗号化されて、次にReadPrinLoginRequestに提供されたDESキーの下で再暗号化されたDASSPrivateKey構造(セクション4.1で、定義される)を含んでいます。
The first 24 bits of flags, if present, contains the version number of the protocol. Implementers of this version of the spec should supply 2.0.0 and should accept any version number of the form 2.x.x. Other bits are reserved for future use (they should not be supplied and they should be ignored).
存在しているなら、旗の最初の24ビットはプロトコルのバージョン番号を含んでいます。 そして、仕様のこのバージョンのImplementersが供給するはずである、2.0、.0、フォーム2.x.xのどんなバージョン番号も受け入れるべきです。 他のビットは今後の使用のために予約されます(それらを供給するべきではありません、そして、それらを無視するべきです)。
2.3.2.7 WriteCredentialRequest
2.3.2.7 WriteCredentialRequest
This is a request to update the encrypted credential structure. It is used when a user's key or password changes. The syntax of the request is:
これは暗号化された資格証明構造をアップデートするという要求です。 ユーザのキーかパスワードが変化するとき、それは使用されています。 要求の構文は以下の通りです。
WriteCredentialRequest ::= [17] IMPLICIT SEQUENCE {
flags [0] BIT STRING DEFAULT {},
authtoken [2] BIT STRING OPTIONAL,
principal [3] Name,
logindata [4] BIT STRING DEFAULT {},
furtherSensitiveStuff [5] BIT STRING
}
WriteCredentialRequest:、:= [17] 暗黙の系列旗[0]BIT STRING DEFAULT、authtoken[2]BIT STRING OPTIONAL、主体[3]名前、logindata[4]BIT STRING DEFAULT、furtherSensitiveStuff[5]BIT STRING
The first 24 bits of flags is a version number. Clients implementing
旗の最初の24ビットはバージョン番号です。 クライアントの実装すること
Kaufman [Page 34] RFC 1507 DASS September 1993
コーフマン[34ページ]RFC1507ダス1993年9月
this version of the spec should supply 2.0.0. Servers should accept any value of the form 2.x.x. Additional bits are reserved for future use (clients should not supply them and servers should ignore them).
仕様のこのバージョンは供給2.0.0がそうするべきです。 サーバはフォーム2.x.xのどんな値も受け入れるべきです。 追加ビットは今後の使用のために予約されます(クライアントが彼らを供給するべきではありません、そして、サーバはそれらを無視するべきです)。
token, if present, authenticates the entity making the request. A request will be accepted either from a principal proving knowledge of the password (see logindata below) or a principal presenting a token in this field and satisfying the authorization policy of the CDC. This field need not be present if logindata includes the hash2 of the password (anyone knowing the old password may set a new one).
存在しているなら、トークンは要求をする実体を認証します。 パスワード(以下のlogindataを見る)に関する主要な立証知識かこの分野にトークンを提示して、CDCの承認方針を満たす元本から要求を受け入れるでしょう。 logindataがパスワードのhash2を含んでいるなら(古いパスワードを知っているだれでも新しいものを設定するかもしれません)、この分野は存在している必要はありません。
principal is the name of the object for which encrypted credentials should be updated.
主体は暗号化された資格証明書がアップデートされるべきであるオブジェクトの名前です。
logindata is encrypted as in ReadPrinLoginRequest. It proves that the requester knows the old password of the principal to be updated (unless the token supplied is from the user's CA) and includes the key which encrypts furtherSensitiveStuff.
logindataはReadPrinLoginRequestのように暗号化されています。 それは、リクエスタが主体の古いパスワードをアップデートするのを(供給されたトークンがユーザのカリフォルニアから来ていない場合)知っていて、furtherSensitiveStuffを暗号化するキーを含んでいると立証します。
furtherSensitiveStuff is an encrypted field constructed as follows:
furtherSensitiveStuffは以下の通り構成された暗号化された分野です:
- The first eight bytes consist of the hash2 defined in section
4.4.2 with the last byte of the hash2 value stored first. The
CDC stores this value and compares it with the values supplied
in future requests of ReadCredentialRequest and
WriteCredentialRequest.
- 最初の8バイトはhash2価値の最後のバイトが最初に保存されている状態でセクション4.4.2で定義されたhash2から成ります。 CDCは、この値を保存して、ReadCredentialRequestとWriteCredentialRequestの今後の要求で供給された値とそれを比べます。
- The next (variable number of) bytes contains a DASSPrivateKey
structure (defined in section 4.1). This is the new
credential structure that will be returned by the CDC on
future ReadCredentialRequests.
- 次、(可変数、)、バイトはDASSPrivateKey構造(セクション4.1で、定義される)を含んでいます。 これは将来のReadCredentialRequestsの上のCDCによって返される新しい資格証明構造です。
- The result is padded with zero bytes to a multiple of eight
bytes.
- 結果はどんなバイトでも8バイトの倍数に水増しされません。
- The entire padded string is encrypted using the key from
logindata or token using DES in CBC mode with zero IV.
- 全体のそっと歩いているストリングは、logindataかトークンからどんなIVと共にもCBCモードでDESを使用しないことでキーを使用することで暗号化されています。
the new eight byte "hash2" defined in section 4.4.2 concatenated with the DASSPrivateKey structure encrypted under the new "hash1" all encrypted under the DES key included in logindata.
新しい8バイト、「DASSPrivateKey構造が新しさの下で暗号化されている状態で、セクション4.4.2で定義されたhash2"は「logindataにDESキーを含んでいる下ですべて暗号化されたhash1"」を連結しました。
2.3.2.8 HereIsStatus
2.3.2.8 HereIsStatus
This is the response message to ill-formed requests and requests that only return a status and no data. It's syntax is:
これは状態を返しますが、どんなデータも返すだけではない不適格な要求と要求への応答メッセージです。 構文があるということです:
Kaufman [Page 35] RFC 1507 DASS September 1993
コーフマン[35ページ]RFC1507ダス1993年9月
HereIsStatus ::= [1] IMPLICIT SEQUENCE {
status [0] IMPLICIT CDCStatus DEFAULT success
}
HereIsStatus:、:= [1] 暗黙の系列状態[0]IMPLICIT CDCStatus DEFAULT成功
status indicates success or the cause of the failure.
状態は失敗の成功か原因を示します。
2.3.2.9 Status Codes
2.3.2.9 ステータスコード
The following are the CDCStatus codes that can be returned by servers. Not all of these values are possible with all calls, and some of the status codes are not possible with any of the calls described in this document.
↓これはサーバで返すことができるCDCStatusコードです。 これらの値のすべてがすべての呼び出しで可能であるというわけではありません、そして、呼び出しのどれかが本書では説明されている状態で、ステータスコードのいくつかが可能ではありません。
CDCStatus ::= INTEGER {
CDCStatus:、:= 整数
success(0),
accessDenied(1),
成功(0)、accessDenied(1)
wrongCDC(2), --this CDC does not store the
--requested information
wrongCDC(2)、--、このCDCがどんな店もしない--、求められた情報
unrecognizedCA(3),
unrecognizedPrincipal(4),
unrecognizedCA(3)、unrecognizedPrincipal(4)
decodeRequestError(5),--invalid BER
illegalRequest(6), --request not recognised
decodeRequestError(5)--無効のBER illegalRequest(6)--認識されなかった要求
objectDoesNotExist(7),
illegalAttribute(8),
objectDoesNotExist(7)、illegalAttribute(8)
notPrimaryCDC(9),--write requests not accepted
--at this CDC replica
notPrimaryCDC(9)--このCDCレプリカで受け入れられなかった要求を書いてください。
authenticationFailure(11),
incorrectPassword(12),
authenticationFailure(11)、incorrectPassword(12)
objectAlreadyExists(13),
objectWouldBeOrphan(15),
objectAlreadyExists(13)、objectWouldBeOrphan(15)
objectIsPermanent(16),
objectIsPermanent(16)
objectIsTentative(17),
parentIsTentative(18),
objectIsTentative(17)、parentIsTentative(18)
certificateNotFound(19),
attributeNotFound(20),
certificateNotFound(19)、attributeNotFound(20)
ioErrorOnCertifDatabase(100),
ioErrorOnCertifDatabase(100)
Kaufman [Page 36] RFC 1507 DASS September 1993
コーフマン[36ページ]RFC1507ダス1993年9月
databaseFull(101),
databaseFull(101)
serverInternalError(102),
serverFatalError(103),
serverInternalError(102)、serverFatalError(103)
insufficientResources(104)
}
insufficientResources(104)
3. Services Provided
3. サービスは提供されました。
This section specifies the services provided by DASS in terms of abstract interfaces and a model implementation. A particular implementation may support only a subset of these services and may provide them through interfaces which combine functions and supply some parameters implicitly. The specific calling interfaces are in some cases language and operating system specific. An actual implementation may choose, for example, to structure interfaces so that security contexts are established and then passed implicitly in calls rather than explicitly including them in every call. It might also bundle keys into opaque structures to be used with supplied encryption and decryption routines in order to enhance security and modularity and better comply with export regulations. Annex B describes a Portable API designed so that applications using a limited subset of the capabilities of DASS can be easily ported between operating systems and between DASS and Kerberos based environments. The model implementation describes data structures which include cached values to enhance performance. Implementations may choose different contents or different caching strategies so long as the same sequence of calls would produce the same output for some caching policy.
このセクションは抽象的なインタフェースとモデル実装でダスによって提供されたサービスを指定します。 特定の実装は、これらのサービスの部分集合だけをサポートして、機能を結合するインタフェースを通してそれらを提供して、それとなくいくつかのパラメタを提供するかもしれません。 いくつかの場合、特定の呼ぶインタフェースは言語とオペレーティングシステム特有です。 例えば、実際の実装が、インタフェースを構造化するのを選ぶかもしれないので、セキュリティ文脈は、あらゆる呼び出しに明らかにそれらを含んでいるより呼び出しでそれとなくむしろ確立されて、次に、通過されます。 また、それは、セキュリティとモジュール方式を高めて、輸出規制に従うほうがよいために供給された暗号化と復号化ルーチンと共に使用されるために不明瞭な構造にキーを投げ込むかもしれません。 別館Bは容易にオペレーティングシステムの間と、そして、ダスとケルベロスに基づいている環境の間にダスの能力の限られた部分集合を使用するアプリケーションは移植できるように設計されたPortable APIについて説明します。 モデル実装は性能を高めるためにキャッシュされた値を含んでいるデータ構造について説明します。 呼び出しの同じ系列が何らかのキャッシング方針のための同じ出力を起こすだろう限り、実装は異なったコンテンツか異なったキャッシュ戦略を選ぶかもしれません。
DASS operates on four kinds of data structures: Certificates, Credentials, Tokens, and Certification Authority State. Certificates and Tokens are passed between implementations and thus their exact format must be architecturally specified. This detailed bit-for-bit specification is in section 4. Credentials generally exist only within a single node and their format is therefore not specified here. The contents of all of these data structures is listed below followed by the algorithms for manipulating them.
ダスは4種類のデータ構造を作動させます: 証明書、資格証明書、トークン、および認証局状態。 証明書とTokensは実装の間で渡されます、そして、その結果、建築上、それらの正確な形式を指定しなければなりません。 この詳細なビットビット仕様はセクション4にあります。 一般に、資格証明書はただ一つのノードだけの中に存在しています、そして、したがって、それらの形式はここで指定されません。 それらを操るためのアルゴリズムがあとに続いていて、これらのデータ構造のすべてのコンテンツは以下に記載されています。
There are three kinds of services provided by DASS: Certificate Maintenance, Credential Maintenance, and Authentication. The first two kinds exist only in support of the third. Certificate maintenance functions maintain the database of public keys in the naming service. These functions tend to be fairly specialized and may not be supported on all platforms. Before authentication can take place, both authenticating principals must have constructed credentials structures. These are built using the Credential Maintenance calls.
ダスによって提供された3種類のサービスがあります: メインテナンス、資格証明メインテナンス、および認証を証明してください。 最初の2種類は単に3番目を支持して存在しています。 証明書メインテナンス機能は名前付けサービスにおける公開鍵に関するデータベースを維持します。 これらの機能は、公正に専門にされる傾向があって、すべてのプラットホームでサポートされないかもしれません。ともに主体を認証すると、行われることができる前に資格証明書構造は構成されたに違いありません。 Credential Maintenance呼び出しを使用するのはこれらに建てられます。
Kaufman [Page 37] RFC 1507 DASS September 1993
コーフマン[37ページ]RFC1507ダス1993年9月
The Authentication functions use credential information and certificates, produce and consume authentication tokens and tell the two communicating parties one another's names.
Authentication機能は、資格証明情報と証明書を使用して、生産して、認証トークンを消費して、2回の交信パーティーにお互いの名前を言います。
3.1 Certificate Contents
3.1 証明書コンテンツ
For purposes of this architecture, a certificate is a data structure posted in the naming service which proclaims that knowledge of the private key associated with a stated public key authenticates a named principal. Certificates are "signed" by some authority, are readable by anyone, and can be verified by anyone knowing the public key of the authority. DASS organizes the CA trust hierarchy around the naming hierarchy. There exists a trusted authority associated with each directory in the naming hierarchy. Generally, each authority creates certificates stating the public keys of each of its children (in the naming hierarchy) and the public key of its parent (in the naming hierarchy). In this way, anyone knowing the public key of any authority can learn the public key of any other by "walking the tree". In order that principals may authenticate even when all of their ancestor directories do not participate in DASS, authorities may also create "cross-certificates" which certify the public key of a named entity which is not a descendent. Rules for finding and following these cross-certificates are described in the Get_Pub_Keys routines. Every principal is expected to know the public key of the CA of the directory in which it is named. This must be securely learned when the principal is initialized and may be maintained in some form of local storage or by having the principal sign a certificate listing the name and public key of its parent and posting that certificate in the naming service.
このアーキテクチャの目的のために、証明書は述べられた公開鍵に関連している秘密鍵に関する知識が命名された元本を認証すると宣言する名前付けサービスで掲示されたデータ構造です。 証明書について、何らかの権威で「署名し」て、だれでも読み込み可能であり、権威の公開鍵を知っているだれでも確かめることができます。 ダスは命名階層構造の周りでカリフォルニア信頼階層構造を組織化します。 命名階層構造で各ディレクトリに関連している信じられた権威は存在しています。 一般に、各権威は子供各人の公開鍵(命名階層構造の)と親の公開鍵(命名階層構造の)を述べる証明書を作成します。 このように、どんな権威の公開鍵も知っているだれでも「木を押して行きます」でいかなる他の公開鍵も学ぶことができます。 校長がいつさえ認証できるように、それらの先祖ディレクトリのすべてがダスに参加しないか、また、当局はa下降していない名前付の実体の公開鍵を公認する「交差している証明書」を作成するかもしれません。 これらの交差している証明書を見つけて、従うための規則はGet_Pub_キーズのルーチンで説明されます。 あらゆる主体がそれが命名されるディレクトリのカリフォルニアの公開鍵を知ると予想されます。 これは、主体が初期化されて、何らかの形式の地方のストレージか主体を親の名前と公開鍵を記載する証明書に署名させることによって維持されるかもしれないならしっかりと学習されていて、名前付けサービスでその証明書を掲示しなければなりません。
The syntax and content of DASS certificates are defined in terms of X.509 (Directory - Authentication Framework). While that standard prescribes a single syntax for certificates, DASS considers certificates to be of one of six types:
ダス証明書の構文と中身はX.509(ディレクトリ--認証Framework)に関して定義されます。 その規格はただ一つの構文を証明書に定めますが、ダスは、6つのタイプのひとりには証明書があると考えます:
- Normal Principal certificates are signed by a CA and certify
the name and public key of a principal where the name of the
CA is a prefix of the name of the principal and is one
component shorter.
- 正常なプリンシパル証明書は、カリフォルニアの名前が主体の名前の接頭語であり、1つのコンポーネントより短いところでカリフォルニアによって署名されて、元本の名前と公開鍵を公認します。
- Trusted Authority certificates are signed by an ordinary
principal and certify the name and public key of the
principal's CA (i.e., the CA whose name is a prefix of the
principal's name and is one component shorter).
- 信じられたAuthority証明書は、主体のカリフォルニアの名前と公開鍵が(すなわち、名前が主体の名前の接頭語であり、1つのコンポーネントより短いカリフォルニア)であると普通の元本によって署名されて、公認します。
- Child certificates are signed by a CA and certify the name and
public key of a CA of a descendent directory (i.e., where the
name of the issuing CA is a prefix of the name of the subject
- 子供証明書がカリフォルニアによって署名されて、下降のディレクトリのカリフォルニアの名前と公開鍵を公認する、(すなわち、発行カリフォルニアの名前が対象の名前の接頭語であるところ
Kaufman [Page 38] RFC 1507 DASS September 1993
コーフマン[38ページ]RFC1507ダス1993年9月
CA and is one component shorter).
カリフォルニア、1つのコンポーネントが、より短い、)
- Parent certificates are signed by a CA and certify the name
and public key of the CA of its parent directory (i.e., whose
name is a prefix of the name of the issuer and is one
component shorter).
- 親証明書は、カリフォルニアによって署名されて、親ディレクトリ(すなわち、名前が発行人の名前の接頭語であり、1つのコンポーネントより短い)のカリフォルニアの名前と公開鍵を公認します。
- Cross certificates are signed by a CA and certify the name and
public key of a CA of a directory where neither name is a
prefix of the other.
- 交差している証明書は、カリフォルニアによって署名されて、どちらの名前ももう片方の接頭語でないディレクトリのカリフォルニアの名前と公開鍵を公認します。
- Self certificates are signed by a principal or a CA and the
issuer and subject name are the same. They are not used in
this version of the architecture but are defined as a
convenient data structure in which in which implementations
may insecurely pass public keys and they may be used in the
future in certain key roll-over procedures.
- 自己証明書は元本かカリフォルニアによって署名されます、そして、発行人と対象の名前は同じです。 それらは、アーキテクチャのこのバージョンで使用されませんが、どれがどの実装に不安定に公開鍵を通過するかもしれないかに便利なデータ構造と定義されます、そして、将来、ある主要なロールオーバー手順で使用されるかもしれません。
It is intended that some future version of the architecture relax the restrictions above where prefixes must be one component shorter. Being able to handle certificates where prefixes are two or more components shorter complicates the logic of treewalking somewhat and is not immediately necessary, so such certificates are disallowed for now.
アーキテクチャの何らかの将来のバージョンがところでの上接頭語が1つのコンポーネントより短くなければならない規制を緩和することを意図します。 接頭語が2つ以上のコンポーネントより短い証明書を扱うことができるのはtreewalkingの論理をいくらか複雑にして、すぐに必要でないので、そのような証明書は当分禁じられます。
The syntax of certificates is defined in section 4. For purposes of the algorithms which follow, the following is the portion of the content which is used (names in brackets refer to the field names in the ASN.1 encoded structure):
証明書の構文はセクション4で定義されます。 従うアルゴリズムの目的のために、↓これは使用された内容の部分(括弧の名前はASN.1のコード化された構造のフィールド名を示す)です:
- UID of the issuer (optional)
- 発行人のUID(任意)です。
- Full name of the issuer (the authority or principal signing)
[issuer]
- 発行人(権威か主要な署名)のフルネーム[発行人]
- UID of the subject (optional)
- 対象のUID(任意)です。
- Full name of the subject (the authority or principal whose key
is being certified) [subject]
- 対象(キーが公認されている権威か主体)のフルネーム[対象]
- Public Key of the subject [subjectPublicKey]
- 対象の公共のKey[subjectPublicKey]
- Period of validity (effective date and expiration date)
[valid]
- 正当性(発効日、有効期限)について以上[有効]です。
- Signature over the entire content of the certificate created
using the private key of the issuer.
- 発行人の秘密鍵を使用することで作成された証明書の全体の中身の上の署名。
Kaufman [Page 39] RFC 1507 DASS September 1993
コーフマン[39ページ]RFC1507ダス1993年9月
When parsing a certificate, the reader compares the two name fields to determine what type of certificate it is. For Parent and Trusted Authority certificates, the names are ignored for purposes of all further processing. For Child and Normal Principal certificates, only the suffix by which the child's name is longer than the parent's is used for further processing. The reason for this is so that if a branch of the namespace is renamed, all of the certificates in the moved branch remain valid for purposes of DASS processing. The only purposes of having full names in these certificates are (1) to comply with X.509, (2) for possible interoperability with other architectures using different algorithms, and (3) to allow principals to securely store their own names in trusted authority certificates in the case where they do not have enough local storage to keep it.
証明書を分析するとき、読者は、どんなタイプの証明書を決定するかために2つの名前欄を比較します。 ParentとTrusted Authority証明書に関しては、名前はさらなるすべての処理の目的のために無視されます。 ChildとNormalプリンシパル証明書に関しては、子供の名前が親より長い接尾語だけがさらなる処理に使用されます。 この理由は、名前空間のブランチが改名されるなら、動くブランチにおける証明書のすべてがダスの処理の目的のために有効なままで残るためのそうです。 これらの証明書のフルネームを持つ唯一の目的がX.509に従う(1)です、他のアーキテクチャが校長がしっかりとそれらがそれを保つことができるくらいの地方のストレージを持っていないケースの中の信じられた権威証明書のそれら自身の名前を保存するのを許容するのに異なったアルゴリズム、および(3)を使用している可能な相互運用性のための(2)。
3.2 Encrypted Private Key Structure
3.2 暗号化された秘密鍵構造
In order that humans need only remember a password rather than a full set of credentials, and also to make installation of nodes and servers easier, there is a defined format for encrypting RSA secrets under a password and posting in the naming service. This structure need only exist when passwords are used to protect RSA secrets; for servers which keep their secrets in non-volatile memory or users who carry smart cards, they are unnecessary.
人間が資格証明書のフルセットよりむしろパスワードを覚えているだけでよくて、また、ノードとサーバのインストールをより簡単にするように名前付けサービスにはRSA秘密を暗号化するための定義された形式がパスワードと任命であるように。 パスワードがRSA秘密を保護するのに使用されるとき、この構造は存在するだけでよいです。 非揮発性メモリーかスマートカードを運ぶユーザで秘密を握るサーバにおいて、それらは不要です。
This structure includes the RSA private/public key pair encrypted under a DES key. The DES key is computed as a one-way hash of the password. This structure also optionally includes the UID of the principal. It is needed only if a single RSA key is shared by multiple principals (with multiple UIDs).
この構造はDESキーの下で暗号化されたRSA私設の/公開鍵組を含んでいます。 DESキーはパスワードの一方向ハッシュとして計算されます。 また、この構造は任意に主体のUIDを含んでいます。 複数の主体(複数のUIDsと)で単一のRSAキーが共有される場合にだけ、それが必要です。
Since this structure is posted in the name service and may be used by multiple implementations, its format must be architecturally defined. The exact encoding is listed in section 4.
この構造がサービスという名前で掲示されて、複数の実装によって使用されるかもしれないので、建築上、書式を定義しなければなりません。 正確なコード化はセクション4で記載されています。
3.3 Authentication Tokens
3.3 認証トークン
This section of the document defines the contents of the authentication tokens which are produced and consumed by Create_token and Accept_token. With DASS, the token passed from the client to the server is complex, with a large number of optional parts, while the token passed from server to client (in the case of mutual authentication only) is small and simple.
ドキュメントのこのセクションはCreate_トークンとAccept_トークンによって生産されて、消費される認証トークンのコンテンツを定義します。 ダスと共に、クライアントからサーバまで通過されたトークンは複雑です、多くのオプショナル・パーツで、サーバからクライアント(互いの認証だけの場合における)まで通過されたトークンが、ささやかであって、簡単ですが。
The authentication token potentially contains a large number of parts, most of which are optional depending on the type of authentication. The following defines the content and purpose of each of the parts, but does not describe the actual encoding (in the belief that such details would be distracting). The encoding is in
認証トークンは潜在的に多くの部品を含んでいます。認証のタイプに頼っていて、その大部分は任意です。 以下は、それぞれの部品の内容と目的を定義しますが、実際のコード化(そのような詳細がそらしているだろうという信念における)について説明しません。 中にコード化があります。
Kaufman [Page 40] RFC 1507 DASS September 1993
コーフマン[40ページ]RFC1507ダス1993年9月
section 4.
セクション4。
The authentication process begins when the initiator calls Create_token with the name of the target. This routine returns an authentication token, which is sent to the target. The target calls Accept_token passing it the token. Both routines produce a second "mutual authentication token". The target returns this to the initiator to prove that it received the token.
創始者が、目標の名前でCreateを_トークンと呼ぶとき、認証過程は始まります。 このルーチンは認証トークンを返します。(それは、目標に送られます)。 目標が、Acceptを_トークンパッシングと呼ぶ、それ、トークン。 両方のルーチンは2番目の「互いの認証トークン」を生産します。 目標は、トークンを受けたと立証するためにこれを創始者に返します。
3.3.1 Initial Authentication Token
3.3.1 初期の認証トークン
The components of the initial authentication token are (names in brackets refer to the field names within the ASN.1 encoded structures defined in section 4):
初期の認証トークンのコンポーネントはこと(括弧の名前はセクション4で定義されたASN.1のコード化された構造の中のフィールド名を示す)です:
a) Encrypted Shared Key - [authenticatingKey] - This is a Shared
(DES) key encrypted under the public key of the target. Also
included in the encrypted structure is a validity interval and
a recognizable pattern so that the receiver can tell whether
the decryption was successful.
a) 暗号化されたShared Key--[authenticatingKey]--これは目標の公開鍵の下で暗号化されたShared(DES)キーです。 また、暗号化に含まれていて、構造は、受信機が、復号化がうまくいったかどうか言うことができるための正当性間隔と認識可能なパターンです。
b) Login Ticket - [sourcePrincipal.userTicket] - This is a
"delegation certificate" signed by a principal's long term
private key delegating to a short term public key. Its "active
ingredients" are:
b) ログインTicket--[sourcePrincipal.userTicket]--これは短期間公開鍵に委任する主体の長期秘密鍵によって署名される「委譲証明書」です。 「有効成分」は以下の通りです。
1) UID of delegating principal [subjectUID]
1) 代表として派遣する主体のUID[subjectUID]
2) Period of validity [validity]
2) 正当性について以上[正当性]
3) Delegation public key [delegatingPublicKey]
3) 委譲公開鍵[delegatingPublicKey]
4) Signature by private key of principal
The existence of this signature is testimony that the
private key corresponding to the delegation public key
speaks for the user during the validity interval.
This data structure is optional and will be missing if the
authentication is only on behalf of a Local Username on a
node (i.e., proxy) rather than on behalf of a real principal
with a real key.
4) 署名、主体の秘密鍵で、この署名の存在は委譲公開鍵に対応する秘密鍵が正当性間隔の間ユーザを代弁するという証言です。 認証が実際のキーで単に本当の元本を代表してというよりむしろノード(すなわち、プロキシ)の上のLocal Usernameを代表していると、このデータ構造は、任意であり、なくなるでしょう。
c) Shared Key Ticket - [sourcePrincipal.sharedKeyTicketSignature]
- This is a signature of the Encrypted Shared Key by the
Delegation Public key in the Login Ticket. The existence of
this signature is testimony that the DES key in the encrypted
shared key speaks for the user.
c) 共有されたKey Ticket--[sourcePrincipal.sharedKeyTicketSignature]--これはLogin Ticketで主要なDelegation PublicによるEncrypted Shared Keyの署名です。 この署名の存在は暗号化された共有されたキーで主要なDESがユーザを代弁するという証言です。
This data structure is optional and will be missing if the
このデータ構造は、任意であり、なくなるでしょう。
Kaufman [Page 41] RFC 1507 DASS September 1993
コーフマン[41ページ]RFC1507ダス1993年9月
authentication is only on behalf of a Local Username on a node
(i.e., proxy) rather than on behalf of a real principal with a
real key. It will also be missing if delegation is taking
place.
認証は実際のキーで単に本当の元本を代表してというよりむしろノード(すなわち、プロキシ)の上のLocal Usernameを代表しています。 また、委譲が行われていると、なくなるでしょう。
d) Node Ticket - [sourceNode.nodeTicketSignature] - This is a
signature of the Encrypted Shared key and a "Local Username"
on the host node by the node's private key. The existence of
this signature is testimony by the node that the DES key in
the encrypted shared key speaks for the named account on that
node.
d) ノードTicket--[sourceNode.nodeTicketSignature]--これは、ノードの秘密鍵によるEncrypted Sharedキーの署名とホストノードに関する「ローカルのユーザ名」です。 この署名の存在はノードによる暗号化された共有されたキーで主要なDESがそのノードの上で命名されたアカウントを代弁するという証言です。
e) Delegator - [sourcePrincipal.delegator] - This data structure
contains the private login key encrypted under the Shared key.
It is optional and is present only if the initiator is
delegating to the destination.
e) Delegator--[sourcePrincipal.delegator]--このデータ構造はSharedキーの下で暗号化された個人的なログインキーを含んでいます。 創始者が目的地に委任している場合にだけ、任意であり、存在しています。
f) Authenticator - [authenticatorData] - This data structure
contains a timestamp and a message digest of the channel
bindings signed by the Shared Key. It is always present.
f) 固有識別文字--[authenticatorData]--このデータ構造はShared Keyによって署名されたチャンネル結合のタイムスタンプとメッセージダイジェストを含んでいます。 それはいつも存在しています。
g) Principal name - [sourcePrincipal.userName] - This is the name
of the initiating principal. It is optional and will be
missing for strong proxy where bits on the wire are at a
premium and where the destination is capable of independently
constructing the name.
g) 主要な名前--[sourcePrincipal.userName]--これは開始主体の名前です。 それは、任意であり、プレミアムにはワイヤのビットがあって、目的地が独自に名前を構成できるところで強いプロキシにおいて、なくなるでしょう。
h) Node name - [sourceNode.nodeName] - This is the name of the
initiating node. It is optional and will be missing for strong
proxy where bits on the wire are at a premium and the name is
present elsewhere in the message being passed.
h) ノード名--[sourceNode.nodeName]--これは開始ノードの名前です。 それは、任意であり、強いプロキシにおいて、通過されるメッセージのほかの場所の現在のプレミアムと存在という名前にはワイヤのビットがあるところでなくなるでしょう。
i) Local Username - [sourceNode.username] - This is the local
user name on the initiating node. It is optional and will be
missing for strong proxy where bits on the wire are at a
premium and where the name is present elsewhere in the message
being passed.
i) 地方のUsername--[sourceNode.username]--これは開始ノードの上のローカルのユーザ名です。 それは、任意であり、強いプロキシにおいて、通過されるメッセージでプレミアムにはワイヤのビットがあって、名前がほかの場所に存在しているところでなくなるでしょう。
3.3.2 Mutual Authentication Token
3.3.2 互いの認証トークン
The authentication buffer sent from the target to the initiator (in the case of mutual authentication) is much simpler. It contains only the timestamp taken from the authenticator encrypted under the Shared Key. It is ASN.1 encoded to allow for future extensions.
目標から創始者(互いの認証の場合における)に送られた認証バッファははるかに簡単です。 それはShared Keyの下で暗号化された固有識別文字から取られたタイムスタンプだけを含んでいます。 それは今後の拡大を考慮するためにコード化されたASN.1です。
Kaufman [Page 42] RFC 1507 DASS September 1993
コーフマン[42ページ]RFC1507ダス1993年9月
3.4 Credentials
3.4 資格証明書
DASS organizes its internal state with Credentials structures. There are many kinds of information which can be stored in credentials. Rather than making a different kind of data structure for each kind of data, DASS provides a single credentials structure where most of its fields are optional. Operating systems must provide some mechanism for having several processes share credentials. An example of a mechanism for doing this would be for credentials to be stored in a file and the name of the file is used as a "handle" by all processes which use those credentials. Some of the calls which follow cause credentials structures to be updated. It is important to the performance of a system that updates to credentials (such as occur during the routines Verify_Principal_Name and Verify_Node_Name, where the caches are updated) be visible to all processes sharing those credentials.
ダスはCredentials構造がある内部の状態を組織化します。 資格証明書で保存できる多くの種類の情報があります。 各種類のデータのための異種のデータ構造を作るよりむしろ、ダスは分野の大部分が任意である構造をただ一つの資格証明書に提供します。 オペレーティングシステムはいくつかのプロセスに資格証明書を共有させるのに何らかのメカニズムを提供しなければなりません。 これをするためのメカニズムに関する例が資格証明書がファイルに保存されるだろうことであり、ファイルの名前は「ハンドル」としてそれらの資格証明書を使用するすべてのプロセスによって使用されます。 続く呼び出しのいくつかが資格証明書構造をアップデートさせます。 システムの性能に、資格証明書(ルーチンのVerify_プリンシパル_NameとVerify_Node_Nameの間、キャッシュがアップデートされるところに起こる)へのアップデートがそれらの資格証明書を共有するすべてのプロセスに目に見えるのは、重要です。
In many of the calls which follow, the credentials passed may be labeled: claimant credentials, verifier credentials or some such. This indicates whose credentials are being passed rather than a type of credentials. DASS supports only one type of credentials, though the fields present in the credentials of one sort of principal may be quite different from those present in the credentials of another.
続く呼び出しの多くでは、通過された資格証明書はラベルされるかもしれません: 主張者資格証明書、検証資格証明書またはいくらかのそのようなもの。 これは、資格証明書が資格証明書のタイプよりむしろだれのものに通過されているかを示します。 ダスは1つのタイプの資格証明書だけをサポートします、1種類の主体の資格証明書における現在の分野が別のものの資格証明書で出席しているそれらと全く異なるかもしれませんが。
An implementation may choose to support multiple kinds of credentials structures each of which will support only a subset of the functions available if it is not implementing the full architecture. This would be the case, for example, if an implementation did not support the case where a server both received requests from other principals and made requests on its own behalf using a single set of credentials.
実装は、完全なアーキテクチャを実装していないならそれのそれぞれが利用可能な機能の部分集合だけをサポートする複数の種類の資格証明書構造を支えるのを選ぶかもしれません。 例えば、実装がサーバが他の主体から要求を受け取って、1セットの資格証明書を使用することでそれ自身に代わって要求をしたケースを支えないなら、これはそうでしょうに。
The following are a list of the fields that may be contained in a credentials structure. They are grouped according to common usage.
↓これは資格証明書構造に含まれるかもしれない分野のリストです。 一般的な用法によると、それらは分類されます。
3.4.1 Claimant information
3.4.1 主張者情報
This is the information used when the holder of these credentials is requesting something. It includes:
これはこれらの資格証明書の所有者が何かを要求しているとき使用される情報です。 それは:
a) Full X.500 name of the principal
a) 主体の完全なX.500名
b) Public Key of the principal
b) 主体の公共のKey
c) Login Ticket - a login ticket contains:
c) ログインTicket--ログインチケットは以下を含んでいます。
1) the UID of the principal
1) 主体のUID
Kaufman [Page 43] RFC 1507 DASS September 1993
コーフマン[43ページ]RFC1507ダス1993年9月
2) a period of validity (effective date & expiration date)
2) 期間の正当性(発効日、有効期限)
3) a delegation public key
3) 委譲公開鍵
4) a signature of the ticket contents by the principal's long
term key
4) 主体の長期キーによるチケットコンテンツの署名
d) Delegation Private Key (corresponding to the public key in c3)
d) 委譲秘密鍵(c3の公開鍵に対応します)
e) Encrypted Shared Key (present only when credentials were
created by accept_token; this information is needed to verify
a node ticket after credentials are accepted)
e) 暗号化された共有されたキー(現在資格証明書が作成されて、_トークンを受け入れてください; この情報が資格証明書を受け入れた後にノードチケットについて確かめるのに必要であるということであった場合にだけ)です。
3.4.2 Verifier information
3.4.2 検証情報
This is the information needed by a server to decrypt incoming requests. It is also used by generate_server_ticket to generate a login ticket.
これは入って来る要求を解読するためにサーバによって必要とされた情報です。 それはそうです、また、使用されて、_サーバ_チケットを生成して、ログインチケットを生成してください。
a) RSA private key.
a) RSA秘密鍵。
3.4.3 Trusted Authority
3.4.3 信じられた権威
This is information used to seed the walk of the CA hierarchy to reliably find the public key(s) associated with a name. Normally, the trusted authority in a set of credentials will be the directory parent of the principal named in Claimant information. In some circumstances, it may instead be the directory parent of the node on which the credentials reside.
これは公開鍵が名前に関連しているのが確かにわかるためにカリフォルニア階層構造の散歩に種を蒔くのに使用される情報です。 通常、資格証明書のセットにおける信じられた権威はClaimant情報で指定された主体のディレクトリ親になるでしょう。 いくつかの事情では、それは代わりに資格証明書があるノードのディレクトリ親であるかもしれません。
a) Full X.500 name of a CA
a) カリフォルニアの完全なX.500名
b) Corresponding RSA Public Key
b) 対応するRSA公開鍵
c) Corresponding UID
c) 対応するUID
3.4.4 Remote node authentication
3.4.4 遠隔ノード認証
This information is present only for credentials generated by "Accept_token". It includes information about any remote node which vouched for the request.
この情報は「_トークンを受け入れてください」によって生成された資格証明書のためだけに存在しています。 それは要求を保証したどんな遠隔ノードの情報も含んでいます。
a) Full X.500 name of the node
a) ノードの完全なX.500名
b) Local Username on the node
b) ノードの上の地方のUsername
c) Node ticket.
c) ノードチケット。
Kaufman [Page 44] RFC 1507 DASS September 1993
コーフマン[44ページ]RFC1507ダス1993年9月
3.4.5 Local node credentials
3.4.5 地方のノード資格証明書
This information is added by Combine_credentials, and is used by Create_token to add a node signature to outbound requests.
この情報はCombine_資格証明書によって加えられて、Create_トークンによって使用されて、ノード署名を外国行きの要求に追加します。
a) Full X.500 name of the node
a) ノードの完全なX.500名
b) Local Username on the node
b) ノードの上の地方のUsername
c) RSA private key of the node
c) ノードのRSA秘密鍵
3.4.6 Cached outgoing contexts
3.4.6 キャッシュされた送信する関係
There may be one (or more) such structures for each server for which this principal has created authentication tokens. These represent a cache: they may be discarded at any time with no effect except on performance. For each association, the following information is kept:
この校長が認証トークンを作成した各サーバのためのそのような構造の(さらに)1つがあるかもしれません。 これらはキャッシュを表します: 性能を除いて、それらはいつでも、効果なしで捨てられるかもしれません。 各協会に関しては、以下の情報は保たれます:
a) Destination RSA Public Key (index)
a) 目的地RSA公開鍵(インデックス)
b) Encrypted Shared key
b) 暗号化されたSharedキー
c) Shared Key Ticket (optional, included if there has been a
non-delegating connection)
c) 共有された主要なチケット(任意である、非代表として派遣している接続があったかどうかを含んでいる、)
d) Node Ticket
d) ノードチケット
e) Delegator (optional, included if there has been a delegating
connection)
e) Delegator(任意である、接続を代表として派遣しながらaがあったかどうかを含んでいる、)
f) Validity interval
f) 正当性間隔
g) Shared Key
g) 共有されたキー
3.4.7 Cached Incoming Contexts
3.4.7 キャッシュされた入って来る文脈
There may be one such structure for each client from which this server has received an authentication token. These represent a cache: they may be discarded at any time with no effect except on performance. (An implementation may choose to keep one System-wide Cache (and list of incoming timestamps). While it is unlikely that the same Encrypted Shared Key will result from encryption of Shared keys generated by different clients or for different servers, an implementation must ensure that an entry made for one client/server can not be reused by another client/server. Similarly an implementation may choose to keep separate caches for the Shared Key/Validity Interval/Delegation Public Key, the Nodename/UID/key/username and the Principal name/UID/key.) For each association, the following information is kept:
このサーバが認証トークンを受けた各クライアントのためのそのような構造の1つがあるかもしれません。 これらはキャッシュを表します: 性能を除いて、それらはいつでも、効果なしで捨てられるかもしれません。 ( 実装は、1System全体のCache(そして、入って来るタイムスタンプのリスト)を保つのを選ぶかもしれません。同じEncrypted Shared Keyが異なったクライアントか異なったサーバのために生成されたSharedキーの暗号化から生じるのが、ありそうもない間、実装は、別のクライアント/サーバで1つのクライアント/サーバのためにされたエントリーを再利用できないのを確実にしなければなりません; 同様に、実装は、Shared Key/正当性のための別々のキャッシュがInterval/委譲Public Keyと、Nodename/UID/キー/ユーザ名とプリンシパル名前/UID/キーであることを保つのを選ぶかもしれません; ) 各協会に関しては、以下の情報は保たれます:
Kaufman [Page 45] RFC 1507 DASS September 1993
コーフマン[45ページ]RFC1507ダス1993年9月
a) Encrypted Shared key (index)
a) 暗号化されたSharedキー(インデックス)
b) Shared Key
b) 共有されたキー
c) Validity Interval
c) 正当性間隔
d) Full X.500 name of Client Principal
d) 完全なX.500名(Clientプリンシパル)
e) UID of Client Principal
e) クライアント主体のUID
f) Public Key of Client Principal
f) クライアント主体の公開鍵
g) Name of Client Node
g) クライアントノードの名前
h) UID of Client Node
h) クライアントノードのUID
i) Public Key of Client Node
i) クライアントノードの公開鍵
j) Local Username on Client node
j) Clientノードの上の地方のUsername
k) Delegation Public key of Client Principal's Login Ticket
k) ClientプリンシパルのLogin Ticketの委譲Publicキー
The Name, UID and Public key of the Principal are all entered together once the Login Ticket has been verified. Similarly the Node name, Node key and Username are entered together once the Node Ticket has been verified. These pieces of information are only present if they have been verified.
Login Ticketがいったん確かめられると、プリンシパルのName、UID、およびPublicキーはすべて一緒に入れられます。 同様に、Node Ticketがいったん確かめられると、Node名、Nodeキー、およびUsernameは一緒に入れられます。 それらが確かめられた場合にだけ、情報のこれらの断片は存在しています。
3.4.8 Received Authenticators
3.4.8 容認された固有識別文字
A record of all the authenticators received is kept. This is used to detect replayed messages. (This list must be common to all targets that could accept the same authenticator (channel bindings will prevent other targets from accepting the same authenticator). This includes different `servers' sharing the same key.) The entries in this list may be deleted when the timestamp is old enough that they would no longer be accepted. This list is kept separate from the Cached incoming context in order that the information in the cached incoming context can be discarded at any time. An implementation could choose to save these timestamps with the cached incoming context if it ensures that it can never purge entries from the cache before the timestamp has aged sufficiently. This list is accessed based on an extract from the signature from the Authenticator. The extract must be at least 64 bits, to ensure that it is very unlikely that 2 authenticators will be received with matching signatures.
固有識別文字が受けたすべてに関する記録はつけられます。 これは、再演されたメッセージを検出するのに使用されます。 このリストは同じ固有識別文字を受け入れることができたすべての目標に共通であるに違いありません(チャンネル結合は、他の目標が同じ固有識別文字を受け入れるのを防ぐでしょう)。(これは同じキーを共有しながら、異なった'サーバ'を含めます。) タイムスタンプがそれらがもう受け入れられないほど古いときに、このリストにおけるエントリーは削除されるかもしれません。 このリストは、いつでもキャッシュされた入って来る文脈の情報を捨てることができるようにCachedの入って来る文脈から別々に保たれます。 タイムスタンプが十分年をとる前にエントリーからキャッシュから決して追放できないのを確実にするなら、実現は、キャッシュされた入って来る文脈でこれらのタイムスタンプを保存するのを選ぶかもしれません。 このリストは署名からの抽出に基づいてAuthenticatorからアクセスされます。 抽出は、合っている署名で2つの固有識別文字を受け取るのが確実に非常にありそうもなくなるようにするためには少なくとも64ビットでなければなりません。
a) Extract from Signature from Authenticator
a) 固有識別文字からの署名からの抽出
Kaufman [Page 46] RFC 1507 DASS September 1993
コーフマン[46ページ]RFC1507ダス1993年9月
b) Timestamp
b) タイムスタンプ
If an implementation runs out of space to store additional authenticators, it may either reject the token which would have overflowed the table or it may temporarily narrow the allowed clock skew to allow it to free some of the space used to hold "old" authenticators. The first strategy will always falsely reject tokens; the second may cause false rejection of tokens if the allowed clock skew gets narrowed beyond the actual clock skew in the network.
実現が追加固有識別文字を格納するためにスペースを使い果たすなら、テーブルからはみ出させた象徴を拒絶するかもしれませんか、またはそれは、「古い」固有識別文字を保持するのに使用される何らかのスペースを解放するのを許容するために一時許容時計斜行を狭くするかもしれません。 最初の戦略はいつも間違って象徴を拒絶するでしょう。 実際の時計斜行を超えて許容時計斜行がネットワークで狭くされるなら、2番目は象徴の誤った拒絶を引き起こすかもしれません。
3.5 CA State
3.5 カリフォルニア州
The CA needs to maintain some internal state in order to generate certificates. This internal state must be protected at all times, and great care must be taken to prevent its being disclosed. A CA may choose to maintain additional state information in order to enhance security. In particular, it is the responsibility of the CA to assure that the same UID is not serially reused by two holders of a single name. In most cases, this can be done by creating the UID at the time the user is registered. To securely permit users to keep their UIDs when transferring from another CA, the CA must keep a record of any UIDs used by previous holders of the name. Since actions of a CA are so security sensitive, the CA should also maintain an audit trail of all certificates signed so that a history can be reconstructed in the event of a compromise. Finally, for the convenience of the CA operator, the CA should record a list of the directories for which it is responsible and their UIDs so that these need not be entered whenever the CA is to be used. The state includes at least the following information:
カリフォルニアは、証明書を作るために何らかの内部の状態を維持する必要があります。 いつもこの内部の状態を保護しなければなりません、そして、それがあるのを明らかにされた状態で防ぐために高度の注意を取らなければなりません。 カリフォルニアは、セキュリティを高めるために追加州の情報を保守するのを選ぶかもしれません。 同じUIDが順次ただ一つの名前の2個の所有者によって再利用されないことを保証するのは、特に、カリフォルニアの責任です。 多くの場合、ユーザが登録されているときUIDを作成することによって、これができます。 名前の前の所有者がどんなUIDsに関する記録も使用して、別のカリフォルニア(カリフォルニア)から移動するとき、ユーザが彼らのUIDsを保つことをしっかりと許可するのがおかなければなりません。 したがって、カリフォルニアの動作がセキュリティ敏感であるので、また、カリフォルニアは妥協の場合、歴史を復元できるようにサインされたすべての証明書の監査証跡を維持するべきです。 最終的に、カリフォルニアのオペレータの都合のために、カリフォルニアは、カリフォルニアが使用されていることになっているときはいつも、これらが入られる必要はないように、それが責任があるディレクトリとそれらのUIDsのリストを記録するべきです。 州は少なくとも以下の情報を含めます:
- Public Key of CA
- カリフォルニアの公開鍵
- Private Key of CA
- カリフォルニアの秘密鍵
- Serial number of next certificate to be issued
- 発行される次の証明書の通し番号
3.6 Data types used in the routines
3.6 ルーチンに使用されるデータ型
There are several abstract data types used as parameters to the routines described in this section. These are listed here
ルーチンへのパラメタがこのセクションで説明したように使用されるいくつかの抽象データ型があります。 これらはここに記載されています。
a) Integer
a) 整数
b) Name
Names unless otherwise noted are always X.500 names. While
most of the design of DASS is naming service independent, the
syntax of certificates and tokens only permits X.500 names to
be used. If DASS is to be used in an environment where some
b) 別の方法で注意されない場合、いつも名前NamesはX.500名です。 ダスのデザインの大部分がサービスを独立者と命名していることである間、証明書と象徴の構文は、X.500名が使用されることを許可するだけです。 ダスが環境で使用されるつもりである、どこ、いくつか
Kaufman [Page 47] RFC 1507 DASS September 1993
コーフマン[47ページ]RFC1507ダス1993年9月
other form of name is used, those names must be translated
into something syntactically compliant with X.500 using some
mechanism which is beyond the scope of this architecture. The
only other form of name appearing in this architecture is a
"local user name", which corresponds to the simple name of an
"account" on a node. As a type, such names appear in
parameter lists as "Strings".
他のフォームの名前が使用されている、シンタクス上この構造の範囲にある何らかのメカニズムを使用しているX.500で何か言いなりになっているものにそれらの名前を翻訳しなければなりません。 この構造の他の唯一のフォームの名前排臨はノードの「アカウント」の単純名に対応する「ローカルのユーザ名」です。 タイプとして、そのような名前は「ストリング」としてパラメータ・リストに現れます。
c) String
A String is a sequence of printable characters.
c) ストリングA Stringは印刷可能なキャラクタの系列です。
d) Absolute Time
A UTC time. The precision of these Times is not stated. A
precision of the order of one second in all times is
sufficient.
d) 絶対Time A UTC時間。 これらのタイムズの精度は述べられていません。 すべての回での1秒の注文の精度は十分です。
e) Time Interval
A Time interval is composed of 2 times. A Start Time and an
End Time, both of which are Absolute Times
e) 時間Interval A Time間隔は2回で構成されます。 Start TimeとEnd Time。それの両方がAbsoluteタイムズです。
f) Timestamp
A Timestamp is a time in POSIX format. I.e., two 32 bit
Integers. The first representing seconds, and the second
representing nanoseconds.
f) タイムスタンプA TimestampはPOSIX形式において時間です。 すなわち、32ビットの2Integers。 最初の表す秒、および数ナノ秒を表す秒。
g) Duration
A Duration is the length of a time interval.
g) 持続時間A Durationは時間間隔の長さです。
h) Octet String
A sequence of bytes containing binary data
h) 2進のデータを含むバイトの八重奏String A系列
i) Boolean
A value of either True or False
i) TrueかFalseのどちらかのブールA値
j) UID
A UID is an bit string of 128 bits.
j) UID A UIDは128ビットのビット列です。
k) OID
An OID is an ISO Object Identifier.
k) OID An OIDはISO Object Identifierです。
l) Shared key
A Shared key is a DES key, a sequence of 8 bytes
l) 共有された主要なA SharedキーはDESキー、8バイトの系列です。
m) CA State
A structure of the form described in '3.5
m) '3.5'で説明された形式のカリフォルニア州A構造
n) Credentials
A structure of the form described in '3.4
n) '3.4'で説明された形式の信任状A構造
Kaufman [Page 48] RFC 1507 DASS September 1993
コーフマン[48ページ]RFC1507ダス1993年9月
o) Certificate
An ASN.1 encoding of the structure described in '3.1
o) '3.1'で説明された構造の証明書An ASN.1コード化
p) Authentication Token
An ASN.1 encoding of the structure described in '3.3.1
p) 構造の認証Token An ASN.1コード化は'3.3で.1について'説明しました。
q) Mutual Authentication Token
An ASN.1 encoding of the structure described in '3.3.2
q) 構造の互いのAuthentication Token An ASN.1コード化は'3.3で.2について'説明しました。
r) Encrypted Credentials
An ASN.1 encoding of the structure described in '3.2
r) '3.2'で説明された構造のコード化されたCredentials An ASN.1コード化
s) Public key
A representation of an RSA Public key, including all the
information needed to encode the public key in a certificate.
s) RSA Publicキーの公開鍵A表現、すべての情報を含んでいるのは証明書の公開鍵をコード化する必要がありました。
t) Set of Public key/UID pairs
A set of Public key/UID pairs. This Data type is only used
internally in DASS - it does not appear in any interface used
to other architectures.
t) Aが設定したPublicキー/UIDのPublicキー/UID組のセットは対にされます。 このDataタイプはダスで内部的に使用されるだけです--それは他の構造に使用されるどんなインタフェースにも現れません。
3.7 Error conditions
3.7 エラー条件
These routines can return the following error conditions (an implementation may indicate errors with more or less precision):
これらのルーチンは以下のエラー条件を返すことができます(実現はだいたい精度で誤りを示すかもしれません):
a) Incomplete chain of trustworthy CAs
a) 信頼できるCAsの不完全なチェーン
b) Target has no keys which can be trusted.
b) 目標は信じることができないキーを全く持っています。
c) Invalid Authentication Token
c) 無効の認証象徴
d) Login Ticket Expired
d) ログインチケットは期限が切れました。
e) Invalid Password
e) 無効のパスワード
f) Invalid Credentials
f) 無効の信任状
g) Invalid Authenticator
g) 無効の固有識別文字
h) Duplicate Authenticator
h) 固有識別文字をコピーしてください。
3.8 Certificate Maintenance Functions
3.8 証明書維持機能
Authentication services depend on a set of data structures maintained in the naming service. There are two kinds of information: Certificates, which associate names and public keys and are signed by off-line Certification Authorities; and Encrypted Credentials, which
認証サービスは命名サービスで維持されたデータ構造のセットに依存します。 2種類の情報があります: 証明書、;(証明書は、名前と公開鍵を関連づけて、オフラインCertification Authoritiesによってサインされます)。 そして、Encrypted Credentials、どれ
Kaufman [Page 49] RFC 1507 DASS September 1993
コーフマン[49ページ]RFC1507ダス1993年9月
contain RSA Private Keys and certain context information encrypted under passwords. Encrypted Credentials are only necessary in environments where passwords are used. Credentials may alternatively be stored in some other secure manner (for example on a smart card).
RSA兵士のキーズとパスワードの下でコード化されたある文脈情報を含んでください。 コード化されたCredentialsがパスワードが使用されている環境だけで必要です。 あるいはまた、信任状はある他の安全な方法(例えば、スマートカードの)に格納されるかもしれません。
The certificate maintenance services are designed so that the most sensitive - the actual signing of certificates - may be done by an off-line authority. Once signed, certificates must be posted in the naming service to be believed. The precise mechanisms for moving certificates between off-line CAs and the on-line naming service are implementation dependent. For the off-line mechanisms to provide any actual security, the CAs must be told what to sign in some reliable manner. The mechanisms for doing this are implementation dependent. The abstract interface says that the CA is given all of the information that goes into a certificate and it produces the signed certificate. There are requirements surrounding the auditing of a CA's actions. The details of what actions are audited, where the audit trail is maintained, and what utilities exist to search that audit trail are not specified here. The functions a CA must provide are:
証明書保守サービスは、オフライン権威で、最も敏感(証明書の実際の調印)ができるように設計されています。 いったんサインされると、信じられるために命名サービスで証明書を掲示しなければなりません。 証明書をオフラインCAsとオンライン命名サービスの間に動かすための正確なメカニズムは実現に依存しています。 オフラインメカニズムがどんな実際のセキュリティも提供するように、何らかの信頼できる方法で何にサインしたらよいかをCAsを言わなければなりません。 これをするためのメカニズムは実現に依存しています。 抽象的なインタフェースは、証明書を調べる情報のすべてがカリフォルニアに与えられていると言います、そして、それは署名入りの証書を製作します。 CAの動作の監査を囲む要件があります。 どんな動作の詳細は監査されるか、そして、監査証跡がどこで維持されるか、そして、どんなユーティリティがその監査証跡を捜すために存在しているかはここで指定されません。 カリフォルニアが提供しなければならない機能は以下の通りです。
3.8.1 Install CA
3.8.1 カリフォルニアをインストールしてください。
Install_CA(
keysize Integer, --inputs
CA_state CA State, --outputs
CA_Public_Key Public Key)
_カリフォルニアをインストールしてください。(_keysize Integer--入力カリフォルニア_州のカリフォルニア州--出力カリフォルニアPublic_Key Public Key)
This routine need only generate a public/private key pair of the requested size. Keysize is likely to be in implementation constant rather than a parameter. The value is likely to be either 512 or 640. Key sizes throughout will have to increase over time as factoring technology and CPU speeds improve. Both keys are stored as part of the CA_state; the public key is returned so that other CAs may cross-certify this one. The `Next Serial number' in the CA state is set to 1.
このルーチンは要求されたサイズの公衆/秘密鍵組を発生させるだけでよいです。 Keysizeする、おそらく、パラメタよりむしろ実現定数にはあることになっています。 値は512か640である傾向があります。 意志中の主要なサイズは時間がたつにつれて技術を因数分解するとして増加しなければなりません、そして、CPU速度は向上します。 両方のキーはカリフォルニア_状態の一部として収納されます。 他のCAsがこれを十字で公認できるように、公開鍵を返します。 カリフォルニア州の'次のSerial番号'は1に設定されます。
3.8.2 Create Certificate
3.8.2 証明書を作成してください。
Create_certificate(
--inputs
Renewal Boolean,
Include_UID Boolean,
Issuer_name Name,
Issuer_UID UID,
Effective_date Absolute Time,
Expiration_date Absolute Time,
Subject_name Name,
_証明書を作成してください、(--入力更新論理演算子、インクルード_UIDのブールの、そして、発行人_名前名義の発行人_UID UID、有効な_が絶対時間の日付を入れて、満了_が絶対時間、対象_名前名の日付を入れる
Kaufman [Page 50] RFC 1507 DASS September 1993
コーフマン[50ページ]RFC1507ダス1993年9月
Subject_UID UID,
Subject_public_key Public Key,
--updated
CA_state CA State,
--outputs
Certificate Certificate)
対象_UID UID(対象の_公共の_主要な公開鍵(アップデートされたカリフォルニア_州のカリフォルニア州))が証明書証明書を出力する、)
This procedure creates and signs a certificate. Note that the various contents of the certificate must be communicated to the CA in some reliable fashion. The Issuer_name and UID are the name and UID of the directory on whose behalf the certificate is being signed.
この手順は、証明書を作成して、サインします。 何らかの信頼できるファッションで証明書の様々な中身をカリフォルニアに伝えなければならないことに注意してください。 Issuer_名前とUIDは証明書がに代わってサインされているディレクトリの名前とUIDです。
This routine formats and signs a certificate with the private key in CA_state. It audits the creation of the certificate and updates the sequence number which is part of CA_state. The Issuer and Subject names are X.500 names. If the CA state includes a history of what UIDs have previously been used by what names, this call will only succeed in the collision case if the Renewal boolean is set true. If the Include_UID boolean is set true, this routine will generate a 1992 format X.509 certificate; otherwise it will generate a 1988 format X.509 certificate.
このルーチンは、カリフォルニア_状態で秘密鍵で証明書をフォーマットして、サインします。 それは、証明書の創造を監査して、カリフォルニア_状態の一部である一連番号をアップデートします。 IssuerとSubject名はX.500名です。 カリフォルニア州が何に関する歴史を含めるかなら、UIDsは以前にどんな名前によって使用されるか、そして、Renewal論理演算子が本当に設定される場合にだけ、この呼び出しは衝突ケースに成功するでしょう。 Include_UID論理演算子が本当に設定されると、このルーチンは1992年の形式X.509証明書を作るでしょう。 さもなければ、それは1988年の形式X.509証明書を作るでしょう。
3.8.3 Create Principal
3.8.3 校長を創造してください。
Create_principal(
--inputs
Password String,
keysize Integer,
Principal_name Name,
Principal_UID UID,
Parent_Public_key Public Key,
Parent_UID UID,
--outputs
Encrypted_Credentials Encrypted Credentials,
Trusted_authority_certificate Certificate)
主要な状態で_を作成してください。(_出力Encrypted_Credentials Encrypted Credentials、--入力Password String、keysize Integer、プリンシパル_名前Name、プリンシパル_UID UID、Parent_Public_キーPublic Key、Parent_UID UID--Trusted_権威証明書Certificate)
This procedure creates a new principal by generating a new public/private key pair, encrypting the public and private keys under the password, and signing a trusted authority certificate for the parent CA. In an implementation not using passwords (e.g., smart cards), an alternative mechanism must be used for initially creating principals. If a principal has protected storage for trusted authority information, it is not necessary to create a trusted authority certificate and store it in the naming service. Some procedure analogous to this one must be executed, however, in which the principal learns the public key and UID of its CA and its own name.
この手順は新しい公衆/秘密鍵組を発生させることによって、新しい元本を創造します、パスワードの下で公衆と秘密鍵をコード化して、信じられた権威証明書に親カリフォルニアにサインして。 パスワード(例えば、スマートカード)を使用しない実現では、初めはに校長を創造しながら、代替のメカニズムを使用しなければなりません。 元本が信じられた権威情報のための格納を保護したなら、信じられた権威証明書を作成して、命名サービスにそれを格納するのは必要ではありません。 しかしながら、これへの類似の何らかの手順を実行しなければなりません、校長が、カリフォルニアとそれ自身の公開鍵とUIDが命名することを学ぶもので。
Kaufman [Page 51] RFC 1507 DASS September 1993
コーフマン[51ページ]RFC1507ダス1993年9月
This routine creates two output structures with the following steps:
このルーチンは以下のステップがある2つの出力構造を作成します:
a) Generate a public/private key pair using the indicated
keysize. An implementation will likely fix the keysize as an
implementation constant, most likely 512 or 640 bits, rather
than accepting it as a parameter. Key sizes generally will
have to increase over time as factoring technology and CPU
speeds improve.
a) 表示を使用するとkeysizeされる公衆/秘密鍵組を発生させてください。 実現がおそらく修理される、実現定数(たぶんパラメタとしてそれを認めるよりむしろ512ビットか640ビット)として、keysizeします。 一般に、主要なサイズは時間がたつにつれて技術を因数分解するとして増加しなければならないでしょう、そして、CPU速度は向上します。
b) Form the encrypted credentials by using the public key,
private key, and Principal_UID and encrypting them using a
hash of the password as the key.
b) 公開鍵、秘密鍵、およびプリンシパル_UIDを使用して、キーとしてパスワードの細切れ肉料理を使用することでそれらをコード化することによって、コード化された信任状を形成してください。
c) Generate a trusted authority certificate (which is identical
in format to a "parent" certificate) getting fields as
follows:
c) 野原が以下の通りになって、信じられた権威証明書(形式が「親」証明書と同じである)を作ってください:
1) Certificate version is X.509 1992.
1) 証明書バージョンはX.509 1992です。
2) Issuer name is the Principal name (which is an X.500 name).
2) 発行人名はプリンシパル名(X.500名である)です。
3) Issuer UID is the Principal UID.
3) 発行人UIDはプリンシパルUIDです。
4) Validity is for all time.
4) 時間中に、正当性があります。
5) Subject name is constructed from the Principal name by
removing the last simple name from the hierarchical name.
5) 対象の名前は、プリンシパル名から階層的な名前から最後の単純名を取り除くことによって、構成されます。
6) Subject UID is the CA_UID.
6) 対象のUIDはカリフォルニア_UIDです。
7) Subject Public Key is the CA_Public_Key
7) 対象のPublic Keyはカリフォルニア_Public_Keyです。
8) Sequence number is 1.
8) 一連番号は1です。
9) Sign the certificate with the newly generated private key of
the principal.
9) 校長の新たに発生した秘密鍵を証明書と契約してください。
3.8.4 Change Password
3.8.4 変化パスワード
Change_password( --inputs
Encrypted_credentials Encrypted Credentials,
Old_password String,
New_password String,
--outputs
Encrypted_credentials Encrypted Credentials)
変化_パスワード(--、入力、コード化された_信任状は信任状、古い_パスワードストリング、新しい_パスワードストリングをコード化しました--出力が信任状がコード化した_をコード化した、信任状)
If credentials are stored encrypted under a password, it is possible to change the password if the old one is known. Note that it is
信任状がパスワードの下でコード化されていた状態で格納されるなら、古い方が知られているなら、パスワードを変えるのは可能です。 注意
Kaufman [Page 52] RFC 1507 DASS September 1993
コーフマン[52ページ]RFC1507ダス1993年9月
insufficient to just change a user's password if the password has been disclosed. Anyone knowing the old password may have already learned the user's private key. If a password has been disclosed, the secure recovery procedure is to call create_principal again followed by create_certificate to certify the new key.
パスワードが明らかにされたならただユーザのパスワードを変えるために、不十分です。 古いパスワードを知っているだれでも既にユーザの秘密鍵を学んだかもしれません。 パスワードが明らかにされたなら、安全なリカバリ手順は呼ぶのが_再び続かれる校長を創造するということです。_証明書を作成して、新しいことがキーであることを公認してください。
Using DASS, it may not be appropriate for users to periodically change their passwords as a precaution unless they also change their private keys by the procedure above. The only likely use of the change_password procedure is to handle the case where an administrator has chosen a password for the user in the course of setting up the account and the user wishes to change it to something the user can remember. A future version of the architecture may smooth key roll-over by having the change_password command also generate a new key and sign a "self" certificate in which the old key certifies the new one. As a separate step, a CA which notices a self certificate posted in the naming service could certify the new key instead of the old one when the user's certificate is renewed. While this procedure is not as rapid or as reliable as having the user directly interact with the CA, it offers a reasonable tradeoff between security and convenience when there is no evidence of password compromise.
ダスを使用して、また、上の手順で自己の秘密鍵を変えないなら、ユーザが注意として定期的に彼らのパスワードを変えるのは、適切でないかもしれません。 ユーザは、変化_パスワード手順の唯一のありそうな使用がアカウントをセットアップすることの間に管理者がユーザのためにパスワードを選んだケースを扱うことであり、それをユーザが思い出すことができる何かに変えたがっています。 アーキテクチャの将来のバージョンは、また、変化_パスワードコマンドに新しいキーを生成させることによって主要なロールオーバーを整えて、古いキーが新しい方を公認する「自己」証明書に署名するかもしれません。 ユーザの証明書が更新されるとき、別々のステップとして、名前付けサービスで掲示された自己証明書に気付くカリフォルニアは古い方の代わりに新しいキーを公認できました。 この手順がユーザに直接カリフォルニアと対話させるほど急速でなく、また信頼できないので、パスワード感染に関する証拠が全くないとき、それはセキュリティと便利の間に手頃な見返りを提供します。
This routine simply decrypts the encrypted credentials structure supplied using the password supplied. It returns a bad status if the format of the decrypted information is bad (indicating an incorrect password). Otherwise, it creates a new encrypted credentials structure by encrypting the same data with the new password. It would be highly desirable for the user interface to this function to provide the capability to randomly generate passwords and prohibit easily guessed user chosen passwords using length, character set, and dictionary lookup rules, but such capabilities are beyond the scope of this document. If encrypted credentials are stored in some local secure storage, the above function is all that is necessary (in fact, if the storage is sufficiently secure, no password is needed; credentials could be stored unenciphered). If they are stored in a naming service, this function must be coupled with one which retrieves the old encrypted credentials from the naming service and stores the new. The full protocol is likely to include access control checks that require the principal to acquire credentials and produce tokens. For best security, the encrypted credentials should be accessible only through a login agent. The role of the login agent is to audit and limit the rate of password guessing. If passwords are well chosen, there is no significant threat from password guessing because searching the space is computationally infeasible. In the context of a login agent, change password will be implemented with a specialized protocol requiring knowledge of the password and (for best security) a trusted authority from which the
このルーチンは、暗号化された資格証明書が提供されたパスワードを使用することで供給された構造であると単に解読します。 解読された情報の形式が悪いなら(間違ったパスワードを示して)、それは悪い状態を返します。 さもなければ、それは、新しいパスワードで同じデータを暗号化することによって、新しい暗号化された資格証明書構造を作成します。 この機能へのユーザーインタフェースが長さ、文字集合、および辞書ルックアップ規則を使用することで手当たりしだいにパスワードを生成して、容易に推測されたユーザ選ばれたパスワードを禁止する能力を提供するのが、非常に望ましいでしょうが、そのような能力はこのドキュメントの範囲を超えています。 暗号化された資格証明書が何らかの地方の安全なストレージで保存されるなら、上の機能は必要なすべて(事実上、ストレージが十分安全であるなら、パスワードは全く必要ではありません; 非暗号化されていた状態で資格証明書を保存できた)です。 それらが名前付けサービスで保存されるなら、この機能は、名前付けサービスから古い暗号化された資格証明書を検索するものと結合しなければならなくて、新しさを保存します。 完全なプロトコルは資格証明書を取得して、トークンを生産するために主体を必要とするアクセス制御チェックを含んでいそうです。 最も良いセキュリティのために、暗号化された資格証明書はログインエージェントだけを通してアクセスしやすいはずです。 ログインエージェントの役割は、パスワード推測のレートを監査して、制限することです。 パスワードが適切であるなら、スペースを捜すのが計算上実行不可能であるので、パスワード推測からの多大なる脅威が全くありません。 ログインエージェントの文脈では、専門化しているプロトコルがパスワードに関する知識と(最も良いセキュリティのための)信じられた権威を必要とすることで変化パスワードが実装される、どれ
Kaufman [Page 53] RFC 1507 DASS September 1993
コーフマン[53ページ]RFC1507ダス1993年9月
public key of the login agent can be learned. See section 2.3.2 for the plans for the non-X.500 credential storage facility.
ログインエージェントの公開鍵について学習できます。 非X.500の資格証明貯蔵場所のためのプランに関してセクション2.3.2を見てください。
3.8.5 Change Name
3.8.5 変化名
Change_name(
--inputs
Claimant_Credentials Credentials,
New_name Name,
CA_Public_Key Public Key,
CA_UID UID,
--outputs
Trusted_Authority_Certificate Certificate)
変化_名(--入力主張者_資格証明書資格証明書、新しい_名前名、カリフォルニアの_の公共の_主要な公開鍵、カリフォルニア_UID UID--出力の信じられた_権威_証明書証明書)
DASS permits a principal to have many current aliases, but only one current name. A principal can authenticate itself as any of its aliases but verifies the names of others relative to the name by which it knows itself. Aliases can be created simply by using the create_certificate function once for each alias. To change the name of a principal, however, requires that the principal securely learn the public key and UID of its new parent CA. As with create_principal, if a principal has secure private storage for its trusted authority information, it need not create a certificate, but some analogous procedure must be able to install new naming information.
ダスは、元本が多くの現在の別名を持っていて、1つの現在の名前しか持っていないことを許可します。 元本は、別名のどれかとしてそれ自体を認証できますが、それが己を知っている名前に比例して他のものの名前について確かめます。 単に使用することによって別名を作成できる、各別名のために一度_証明書機能を作成してください。 しかしながら、元本の名前を変えるのは、校長がしっかりと新しい親カリフォルニアの公開鍵とUIDを学ぶのを必要とします。 元本には信じられた権威情報のための安全な個人的なストレージがありますが、証明書を作成する必要はありませんが、何らかの類似の手順が新しい命名情報をインストールできなければならないなら、主要な状態で_を作成してください。
This routine produces a new Trusted Authority Certificate with contents as follows:
コンテンツは以下の通りでこのルーチンは新しいTrusted Authority Certificateを生産します:
a) Issuer name is New_name (an X.500 name)
a) 発行人名はNew_名前です。(X.500名)
b) Issuer_UID is Principal UID from Credentials.
b) 発行人_UIDはCredentialsからのプリンシパルUIDです。
c) Validity is for all time.
c) 時間中に、正当性があります。
d) Subject name is constructed from the Issuer name by removing
the last simple name from the hierarchical name, and
converting to an X.500 name.
d) 対象の名前は、Issuer名から階層的な名前から最後の単純名を移して、X.500名に変えることによって、構成されます。
e) Subject UID is CA_UID
e) 対象のUIDはカリフォルニア_UIDです。
f) Subject Public Key is CA_Public_Key
f) 対象のPublic Keyはカリフォルニア_Public_Keyです。
g) Sequence number is 1.
g) 一連番号は1です。
h) The certificate is signed with the private key of the
principal from the credentials. Note that this call will only
succeed if the principal's private key is in the credentials,
h) 証明書は資格証明書からの主体の秘密鍵を契約されます。 資格証明書に主体の秘密鍵がある場合にだけこの呼び出しが成功することに注意してください。
Kaufman [Page 54] RFC 1507 DASS September 1993
コーフマン[54ページ]RFC1507ダス1993年9月
which will only be true if the credentials were created by
calling Create_server_credentials.
Create_サーバを_資格証明書と呼ぶことによって資格証明書が作成された場合にだけ、本当でしょう。
3.9 Credential Maintenance Functions
3.9 資格証明メインテナンス機能
DASS credentials can potentially have information about two principals. This functionality is included to support the case where a user on a node has two identities that might be recognized for purposes of managing access controls. First, there is the user's network identity; second, there is an identity as controlling a particular "account" or "username" on that node. There are two reasons for recognizing this second identity: first, access controls might be specified such that only a user is only permitted access to certain resources when coming through certain trusted nodes (e.g., files that can't be accessed from a terminal at home); and second, before the transition strategy to global identities is complete, as a way to refer to USER@NODE in a way analogous to existing mechanisms but with greater security.
ダス資格証明書は潜在的に2つの主体の情報を持つことができます。 この機能性は、ノードの上のユーザがアクセス制御を管理する目的として認識されるかもしれない2つのアイデンティティを持っているケースを支えるために含まれています。 まず最初に、ユーザのネットワークのアイデンティティがあります。 2番目に、そのノードに関する特定の「アカウント」か「ユーザ名」を制御するとしてアイデンティティがあります。 この2番目のアイデンティティを認識する2つの理由があります: まず最初にアクセス制御が指定されるかもしれないので、ある信じられたノード(例えばホームの端末からアクセスできないファイル)を通り抜けるときだけ、あるリソースへのアクセスはユーザだけに受入れられます。 そして、以前2番目に、グローバルなアイデンティティへの変遷戦略は完全です、ある意味でメカニズムにもかかわらず、よりすばらしいセキュリティで存在することへの類似の USER@NODE について言及する方法として。
The mapping of global usernames to local user names on a node is outside the scope of DASS. This is done via a "proxy database" or some analogous local mechanism. What DASS provides are mechanisms for adding node oriented credentials into a user's credentials structure, carrying the dual authentication information in authentication tokens, and extracting the information from the credentials structure created by Accept_token.
ダスの範囲の外にノードの上のローカルのユーザ名へのグローバルなユーザ名に関するマッピングがあります。 「プロキシデータベース」か何らかの類似の局所機構でこれをします。 ダスが提供するものはノードがユーザの資格証明書構造に資格証明書を適応させたと言い足すためのメカニズムです、認証トークンで二元的な認証情報を運んで、Accept_トークンによって作成された資格証明書構造から情報を抜粋して。
Some applications of DASS will not make use of the node authentication related extensions. In that case, they will never use the Combine_credentials, Create_credentials, Get_node_info, or Verify_node_name functions.
ダスのいくつかのアプリケーションはノード認証の使用を関連する拡大にしないでしょう。 その場合、彼らはCombine_資格証明書、Create_資格証明書、Get_ノード_インフォメーション、またはVerify_ノード_名前機能を決して使用しないでしょう。
The "normal" sequence of events surrounding a user logging into a node are as follows:
ノードにログインしているユーザを囲むイベントの「正常な」系列は以下の通りです:
a) When the user logs in, he types either a local user ID known
to the node or a global name (the details of the user
interface are implementation specific). Through some sort of
local mapping, the node determines both a global name and a
local account name. The user also enters a password
corresponding to the global name.
a) ユーザがログインするとき、彼はノードかグローバル名に知られている地方のユーザIDをタイプします(ユーザーインタフェースの細部は実装特有です)。 ある種のローカルのマッピングを通して、ノードはグローバル名とローカルのアカウント名の両方を決定します。 また、ユーザはグローバル名に対応するパスワードを入力します。
b) The node calls network_login specifying the user's global name
and the supplied password. The result is credentials which
can be used to access network services but which have not yet
been verified to be valid.
b) ノードは、ネットワーク_ログインをユーザのグローバル名と与えられたパスワードを指定すると呼びます。 結果はネットワーク・サービスにアクセスするのに使用できますが、有効になるようにまだ確かめられていない資格証明書です。
Kaufman [Page 55] RFC 1507 DASS September 1993
コーフマン[55ページ]RFC1507ダス1993年9月
c) The node calls verify_principal_name using its own credentials
to verify the authenticity of the user's credentials (these
node credentials must have previously been established by a
call to initialize_server during node initialization).
c) ノード呼び出しは、ユーザの資格証明書の信憑性について確かめるのにそれ自身の資格証明書を使用することで_主体_名前について確かめます(ノード初期化の間に_サーバを初期化するという要求でこれらのノード資格証明書は以前に、確立されたに違いありません)。
d) If that test succeeds, the node adds its credentials to those
of the user by calling combine_credentials.
d) そのテストが成功するなら、ノードは、呼ぶのによるユーザのものへの資格証明書が_資格証明書を結合すると言い足します。
The set of facilities for manipulating credentials follow:
資格証明書が続く操りのための施設のセット:
3.9.1 Network login
3.9.1 ネットワークログイン
Network_login(
--inputs
Name Name,
password String,
keysize Integer,
expiration Time interval,
TA_credentials Credentials,--optional
--outputs
Claimant_credentials Credentials)
ネットワーク_ログイン(--入力Name Name、パスワードString、keysize Integer、満了Time間隔、TA_資格証明書Credentials(任意である)がClaimant_資格証明書Credentialsを出力する)
This function creates credentials for a principal when the principal "logs into the network".
主体が「ネットワークにログインする」とき、この機能は元本のために資格証明書を作成します。
Name is the X.500 name of the principal.
名前は主体のX.500名です。
Password is a secret which authenticates the principal to the network.
パスワードはネットワークに主体を認証する秘密です。
Keysize specifies the size of the temporary "login" or "delegation" key. In a real implementation, it is expected to be an implementation constant (most likely 384 or 512 bits).
Keysizeする、一時的な「ログイン」か「委譲」キーのサイズを指定します。 本当の実装では、それは実装定数(たぶん384ビットか512ビット)であると予想されます。
Expiration sets a lifetime for the credentials created. For a normal login, this is likely to be an implementation constant on the order of 8-72 hours. Some mechanism for overriding it must be provided to make it possible (for example) to submit a background job that might run days or even months after they are submitted.
資格証明書のための寿命が創設した満了セット。 通常のログインにおいて、これは8〜72時間の注文での実装定数である傾向があります。 (例えば)それらを提出した何カ月も後に稼働さえするかもしれないバックグラウンドジョブを提出するのを可能にするようにそれをくつがえすための何らかのメカニズムを提供しなければなりません。
TA_credentials are used if the encrypted credentials are protected by a login agent. If they are missing, the password will be less well protected from guessing attacks.
暗号化された資格証明書がログインエージェントによって保護されるなら、TA_資格証明書は使用されています。 それらがなくなると、パスワードは攻撃を推測するのからそれほどよくない保護されないでしょう。
This routine does not (as one might expect) securely authenticate the principal to the calling procedure. Since the password is used to obtain the principal's private key, this call will normally fail if the principal supplies an invalid password. A penetrator who has
このルーチンはしっかりと呼ぶ手順に主体を認証しません(人が予想するかもしれないように)。 パスワードが主体の秘密鍵を得るのに使用されるので、主体が無効のパスワードを提供すると、通常、この呼び出しは失敗するでしょう。 そうした針入度計
Kaufman [Page 56] RFC 1507 DASS September 1993
コーフマン[56ページ]RFC1507ダス1993年9月
compromised the naming service could plant fake encrypted credentials under any name and impersonate that name as far as this call is concerned. A caller that wishes to authenticate the user in addition to obtaining credentials to be able to act on the user's behalf should call Verify_principal_name (below) with the created credentials and the credentials of the calling process.
感染されて、この呼び出しに関する限り、名前付けサービスは、どんな名前の下でもにせの暗号化された資格証明書を植えて、その名前をまねるかもしれません。 ユーザの代理に影響できるように資格証明書を得ることに加えてユーザを認証したがっている訪問者は、作成された資格証明書と呼び出しプロセスの資格証明書でVerify_を主体_名前(below)と呼ぶべきです。
This routine constructs a credentials structure from information found in the naming service encrypted using the supplied password.
このルーチンは与えられたパスワードを使用することで暗号化された名前付けサービスで見つけられた情報から資格証明書構造を構成します。
a) If the encrypted credentials structure is protected with a
login agent, retrieve the public key of the login agent:
a) 暗号化された資格証明書構造がログインエージェントと共に保護されるなら、ログインエージェントの公開鍵を検索してください:
1) If TA_credentials are available, use them in a call to
Get_Pub_Keys to get the public key of the login agent (whose
name is derived from the name of the principal by truncating
the last element of the RDN and adding CSS=X509).
1) TA_資格証明書が利用可能であるなら、呼び出しにGet_Pub_キーズにそれらを使用して、ログインエージェント(名前は主体の名前からRDNの最後の要素に先端を切らせて、CSS=X509を加えることによって、得られる)の公開鍵を得てください。
2) If TA_credentials are not available, look up the public key
of the login agent in the naming service.
2) TA_資格証明書が利用可能でないなら、名前付けサービスでログインエージェントの公開鍵を見上げてください。
Login agents limit and audit password guesses, and are
important when passwords may not be well chosen (as when users
are allowed to choose their own). To fully prevent the
password guessing threat, principals may only log onto nodes
that already have TA_credentials which can be used to
authenticate the login agent. To support nodes which have no
credentials of their own and to allow this procedure to
support node initialization, it is possible to network login
without TA credentials.
ログインエージェントは、パスワード推測を制限して、監査して、パスワードが適切でないときに、重要です(ユーザがそれら自身のを選ぶことができる時として)。 パスワード推測の脅威を完全に防ぐために、校長は既に、ログインエージェントを認証するのに使用できるTA_資格証明書を持っているノードにログオンするだけであるかもしれません。 それら自身の資格証明書を全く持っていないノードをサポートして、この手順がノード初期化をサポートするのを許容するために、それはTA資格証明書なしでネットワークログインに可能です。
A principal who logs into a node that lacks TA credentials is
subject to the following subtle security threat: A penetrator
who impersonates the naming service could post his own public
key and address as those of the login agent. This procedure
would then in the process of logging in reveal the the
penetrator enough information for the penetrator to mount an
unaudited password guessing attack against the principal's
credentials.
TA資格証明書を欠いているノードにログインする元本は以下の微妙な軍事的脅威を受けることがあります: 名前付けサービスをまねる針入度計はログインエージェントのものとして彼自身の公開鍵とアドレスを掲示するかもしれません。 そして、ログインすることの途中にこの手順は針入度計が主体の資格証明書に対して攻撃を推測しながら非監査のパスワードを取り付けることができるくらいの針入度計情報を明らかにするでしょう。
b) Retrieve the encrypted credentials from the naming service or
login agent. In the case of the login agent, the password is
one-way hashed to produce proof of knowledge of the password
and the hashed value is supplied to the login agent encrypted
under its public key as part of the request.
b) 名前付けサービスかログインエージェントから暗号化された資格証明書を検索してください。 ログインエージェントの場合では、パスワードはパスワードに関する知識の生産物証拠に論じ尽くされた状態で一方向です、そして、要求の一部として公開鍵の下で暗号化されたログインエージェントに論じ尽くされた値を与えます。
c) Decrypt the encrypted credentials structure using a the
supplied password. Verify that the decryption was successful
c) aを使用する資格証明書が構造化する暗号化に与えられたパスワードを解読してください。 復号化がうまくいったことを確かめてください。
Kaufman [Page 57] RFC 1507 DASS September 1993
コーフマン[57ページ]RFC1507ダス1993年9月
by verifying that the resulting structure can be parsed
according the the ASN.1 rules for Encrypted_Credentials and
that the two included primes when multiplied together produce
the included modulus. If the decryption was unsuccessful then
the routine returns the `Invalid password' error status. The
decryption results in both the Private Key and the Public Key.
ASN.1規則Encrypted_Credentialsのために結果として起こる構造を分析できて、一緒に掛けられると2が盛りを含んでいたことを確かめることによって、含まれている係数を生産してください。 復号化が失敗していたなら、ルーチンは'無効のパスワード'エラー状況を返します。 復号化は兵士のKeyとPublic Keyの両方をもたらします。
d) Generate a public/private key pair for the Delegation Key,
using the indicated keysize. Key size is likely to be an
implementation constant rather than a supplied parameter, with
likely values being 384 and 512 bits. Key sizes generally
will have to increase over time as factoring technology and
CPU speeds improve. Delegation keys can be relatively shorter
than long term keys because DASS is designed so that
compromise of the delegation key after it has expired does not
result in a security compromise. An important advantage of
making key size an implementation constant is that nodes can
generate key pairs in advance, thus speeding up this procedure.
Key generation is the most CPU intensive RSA procedure and
could make login annoyingly slow.
d) Delegation Keyのために公衆/秘密鍵組を生成してください、そして、表示を使用するのはkeysizeされます。 主要なサイズは供給されたパラメタよりむしろ実装定数である傾向があります、384と512ビットであるありそうな値で。 一般に、主要なサイズは時間がたつにつれて技術を因数分解するとして増加しなければならないでしょう、そして、CPU速度は向上します。 期限が切れた後に委譲キーの感染がセキュリティ感染をもたらさないようにダスが設計されているので、委譲キーは長期キーより比較的短い場合があります。 主要なサイズを実装定数にする重要な利点はノードがあらかじめ主要な組を生成することができるということです、その結果、この手順を早くします。 キー生成は、最も多くのCPUの徹底的なRSA手順であり、ログインをうるさく遅くすることができました。
e) Construct a Login Ticket by signing with the user's private
key a combination of the public key, a validity period
constructed from the current time and the expiration passed in
the call, and the principal UID found in the encrypted-key
structure.
e) 暗号化されて主要な構造の公開鍵の組み合わせ、現在の時間から組み立てられた有効期間、呼び出しで通過された満了、およびUIDが見つけた主体とユーザの秘密鍵を契約するのによるLogin Ticketを組み立ててください。
f) Forget the user's private key.
f) ユーザの秘密鍵を忘れてください。
g) Retrieve from the naming service any trusted authority
certificates stored with the user's entry. Discard any that
are not signed by the user's public key and UID. An
implementation in which the login node has credentials of its
own may choose its trusted authority information instead of
retrieving and verifying trusted authority certificates from
the naming service. This will have a subtle effect on the
security of the resulting system.
g) 名前付けサービスから、ユーザのエントリーで保存されたあらゆる信じられた権威証明書を検索してください。 ユーザの公開鍵とUIDによって署名されないいずれも捨ててください。 名前付けサービスからの信じられた権威証明書を検索して、確かめることの代わりにログインノードがそれ自身の資格証明書を持っている実装は信じられた権威情報を選ぶかもしれません。 これは結果として起こるシステムのセキュリティに微妙な影響を与えるでしょう。
h) Construct a credentials structure from:
h) 以下から資格証明書構造を構成してください。
1) Claimant credentials:
1) 主張者資格証明書:
(i) Name of the principal from calling parameter
(ii) Login Ticket as constructed in (e)
(iii)Delegation Private key as constructed in (d)
(iv) Public key from the encrypted credentials structure
(i) 暗号化された資格証明書構造から(d)(iv)公開鍵で組み立てられるように(e)(iii)Delegation兵士で組み立てられるパラメタ(ii)ログインTicketが主要であると言うのからの主体の名前
2) No verifier credentials
2) 検証資格証明書がありません。
Kaufman [Page 58] RFC 1507 DASS September 1993
コーフマン[58ページ]RFC1507ダス1993年9月
3) Trusted Authorities: for the most recently signed trusted
authority certificate (There is normally only one Trusted
Authority Certificate. If there is more than one then an
implementation may choose to maintain a list of all the valid
keys. They should all refer to the same CA (UID and name).):
3) 当局は信じました: 最も最近署名している信じられた権威証明書のために(通常、1Trusted Authority Certificateしかありません。 1つ以上があれば、実装は、すべての有効なキーのリストを維持するのを選ぶかもしれません。 彼らが皆、同じカリフォルニアについて言及するべきである、(UIDと名前).):
(i) Name of the CA from the subject field of the certificate
(ii) Public Key of the CA from the subject public key field
(iii)UID of the CA from the subject UID field
(i) 対象のUID分野からのカリフォルニアの対象の公開鍵分野(iii)UIDからのカリフォルニアの証明書(ii)の公共のKeyの対象の分野からのカリフォルニアの名前
4) no remote node credentials
4) 遠隔ノード資格証明書がありません。
5) no local node credentials
5) 地方のノード資格証明書がありません。
6) no cached outgoing associations
6) キャッシュされた出発している協会がありません。
7) no cached incoming associations
7) キャッシュされた入って来る協会がありません。
3.9.2 Create Credentials
3.9.2 資格証明書を作成してください。
Create_credentials(
--outputs
Claimant_credentials Credentials)
_資格証明書を作成してください。(--、出力主張者_資格証明書資格証明書)
This routine creates an "empty" credentials structure. It is needed in the case of a user logging into a node and obtaining node oriented credentials but no global username credentials. Because the "combine_credentials" call wants to modify a set of user credentials rather than create a new set, this call is needed to produce the "shell" for combine_credentials to fill in.
このルーチンは「空」の資格証明書構造を作成します。 それがノードにログインしているユーザの場合で必要でした、そして、ノードを得る場合、資格証明書が適応しましたが、どんなグローバルなユーザ名資格証明書も適応しませんでした。 「コンバイン_資格証明書」呼び出しが新しいセットを創設するよりむしろ1セットのユーザ資格証明書を変更したがっているので、この呼び出しがコンバイン_資格証明書が記入する「シェル」を生産するのに必要です。
It is unlikely that any real implementation would support this function, but rather would have some functions which combine network_login, create_credentials, and combine_credentials in whatever ways are supported by that node.
むしろネットワーク_ログインを結合して、_資格証明書を作成して、_資格証明書を結合するいくつかの機能を持っているだろうというのを除いて、どんな本当の実装もそのノードによってサポートされるどんな方法でもこの機能をサポートするのは、ありそうもないです。
3.9.3 Combine Credentials
3.9.3 資格証明書を結合してください。
Combine_credentials(
--inputs
node_credentials Credentials,
localusername String,
--updated
user_credentials Credentials)
_資格証明書を結合してください。(--入力ノード_資格証明書Credentials、localusername String--アップデートされたユーザ_資格証明書Credentials)
This routine is provided by implementations which support the notion of local node credentials. After the node has verified to its own
地方のノード資格証明書の概念をサポートする実装はこのルーチンを提供します。 ノードはそれ自身に確かめました。
Kaufman [Page 59] RFC 1507 DASS September 1993
コーフマン[59ページ]RFC1507ダス1993年9月
satisfaction that the user_credentials are entitled to access to a particular local account, this call adds node credential information to the user_credential structure. This function may be applied to user_credentials created by network_login, create_credentials, or accept_token.
ユーザ_資格証明書が特定のローカルのアカウントにアクセスする権利を与えられる満足、この呼び出しはユーザ_資格証明書構造にノード資格証明書情報を追加します。 この機能は、資格証明書がネットワーク_ログインで作成したユーザ_に適用されるか、_資格証明書を作成するか、または_トークンを受け入れるかもしれません。
a) Fill in the local node credentials substructure of
user_credentials as follows:
a) 以下のユーザ_資格証明書のローカルのノード資格証明書基礎に記入してください:
1) Full name of the node: from Full name of the Principal in
node_credentials
1) ノードのフルネーム: Full名(ノード_資格証明書におけるプリンシパル)から
2) Local username on the node: from proxy lookup
2) ノードに関するローカルのユーザ名: プロキシルックアップから
3) RSA private key of the node: from verifier credentials in
node_credentials
3) ノードのRSA秘密鍵: ノード_資格証明書における検証資格証明書から
b) Optionally, change the trusted authorities to match the
trusted authorities from the node credentials. This is an
implementation option, done most likely as a performance
optimization. The only case where this option is required is
where no trusted authorities existed in the user credentials
(because they were created by create_credentials of
accept_token). Server credentials should generally keep their
own trusted authorities.
b) 任意に、信じられた当局を変えて、ノード資格証明書から信じられた当局を合わせてください。 これはたぶんパフォーマンスの最適化として行われた実装オプションです。 このオプションが必要である唯一のケースがどんな信じられた当局もユーザ資格証明書で存在しなかったところである、(それらが作成されたので_資格証明書を作成してください、受諾、_トークン) 一般に、サーバ資格証明書はそれら自身の信じられた当局を維持するべきです。
It is likely that an implementation will choose not to replicate its node credentials in every credentials structure that it supports, but rather will maintain some sort of pointer to a single copy. This algorithm is stated as it is only for ease of specification.
実装は、それが支えるあらゆる資格証明書構造でノード資格証明書を模写するというわけではないのを選びますが、むしろただ一つのコピーにある種の指針を維持しそうでしょう。 それが仕様の容易さのためだけのものであるときに、このアルゴリズムは述べられます。
3.9.4 Initialize_server
3.9.4 _サーバを初期化してください。
initialize_server(
--inputs
Name Name,
password String,
TA_credentials Credentials, --optional
--outputs
Server_credentials Credentials)
_サーバを初期化してください。(--入力Name Name、パスワードString、TA_資格証明書Credentials(任意である)がServer_資格証明書Credentialsを出力する)
Somehow a server must get access to its credentials. One way is for the credentials to be stored in the naming service like user credentials encrypted under a service password. The service then needs to gain at startup time access to a service password. This may be easier to manage and is not insecure so long as the service password is well chosen. Alternately, the service needs some mechanism to gain access directly to its credentials. The credentials
どうにか、サーバは資格証明書に近づく手段を得なければなりません。 1つの方法は資格証明書がサービスパスワードの下で暗号化されたユーザ資格証明書のように名前付けサービスで保存されることです。 そして、サービスは、サービスパスワードへの始動時間アクセスで獲得する必要があります。 サービスパスワードが適切である限り、これは、管理するのが、より簡単であるかもしれなく、不安定ではありません。 交互に、サービスは、直接資格証明書へのアクセスを得るために何らかのメカニズムを必要とします。 資格証明書
Kaufman [Page 60] RFC 1507 DASS September 1993
コーフマン[60ページ]RFC1507ダス1993年9月
created by this call are intended to be very long lived. They do not time out, so a node or server might store them in Non-Volatile memory after "initial installation" rather than calling this routine at each "boot". These credentials are shared between all servers which use the same key. This routine works as follows:
これによって作成されて、非常に長い間呼び出しが送られることを意図します。 彼らがどんなタイムアウトもしないので、ノードかサーバが「初度施設」の後に各「ブーツ」にこのルーチンを呼ぶよりNon-揮発性メモリーにむしろそれらを保存するかもしれません。 これらの資格証明書は同じキーを使用するすべてのサーバの間で共有されます。 このルーチンは以下の通り働いています:
a) Retrieve from the naming service or login agent the encrypted
credentials structure corresponding to the supplied name. See
Network_login for a discussion of the use of TA_credentials
and login agents.
a) 名前付けサービスかログインエージェントから、供給された名前に対応する暗号化された資格証明書構造を検索してください。 Network_がTA_資格証明書とログインエージェントの使用の議論のためにログインするのを見てください。
b) Decrypt that structure using a one-way hash of the supplied
password. Verify that the decryption was successful. Verify
that the public key in the structure matches the private key.
b) 与えられたパスワードの一方向ハッシュを使用して、その構造を解読してください。 復号化がうまくいったことを確かめてください。 構造の公開鍵が秘密鍵に合っていることを確かめてください。
c) Retrieve from the naming service any trusted authority
certificates stored under the supplied name. Discard any which
do not contain the UID from the encrypted credentials
structure or are not signed by the key in the encrypted
credentials structure.
c) 名前付けサービスから、供給された名前の下で保存されたあらゆる信じられた権威証明書を検索してください。 暗号化された資格証明書構造からUIDを含んでいないか、または暗号化された資格証明書構造のキーによって署名されないいずれも捨ててください。
d) Construct a credentials structure from:
d) 以下から資格証明書構造を構成してください。
1) Claimant credentials:
(i) Name of the principal from the calling parameter
(ii) UID of the principal from the encrypted-key structure
(iii) No login ticket
(iv) No login secret key
1) 主張者資格証明書: (i) 呼ぶパラメタ(ii)からの主体の名前 暗号化されて主要な構造(iii)からの主体のUID ログインチケットがありません(iv)。 いいえログイン秘密主要です。
2) Verifier credentials:
(i) Server secret key from the encrypted-key structure
2) 検証資格証明書: (i) 暗号化されて主要な構造からのサーバ秘密鍵
3) Trusted Authorities: from the most recently signed Trusted
Authority Certificate:
(i) Name of CA from the Subject Name field
(ii) UID of the CA from the Subject UID field
(iii) Public Key of the CA from the Subject Public Key field
3) 当局は信じました: 最も最近署名しているTrusted Authority Certificateから: (i) Subject Name分野(ii)からのカリフォルニアの名前 Subject UID分野(iii)からのカリフォルニアのUID Subject Public Key分野からのカリフォルニアの公共のKey
4) no node credentials
4) ノード資格証明書がありません。
5) no cached outgoing associations
5) キャッシュされた出発している協会がありません。
6) no cached incoming associations
6) キャッシュされた入って来る協会がありません。
Kaufman [Page 61] RFC 1507 DASS September 1993
コーフマン[61ページ]RFC1507ダス1993年9月
3.9.5 Generate Server Ticket
3.9.5 サーバチケットを生成してください。
generate_server_ticket(
--inputs
expiration Time interval,
--updated
Server_credentials Credentials)
_がサーバ_チケットであると生成してください。(--入力満了Time間隔--アップデートされたServer_資格証明書Credentials)
Server credentials created by initialize_server can be used to accept incoming authentication tokens and can act as node_credentials for outgoing authentications, but cannot create user_credentials of their own. If a server initiates connections on its own behalf, it must have a ticket just like any other user might have. That ticket has limited lifetime and the right to act on behalf of the server can be delegated. The server cannot, however, delegate the right to receive connections intended for it. An implementation must come up with a policy for the expiration of server tickets and how long before expiration they are renewed. A likely policy is for this procedure to be implicitly called by Create_token if there is no current ticket present in the credentials. If so, this interface need not be exposed.
作成されたサーバ資格証明書は、_ノードとしての入って来る認証トークンを受け入れるのにおいて中古、そして、缶の条例が外向的な認証のための資格証明書であったかもしれないなら_サーバを初期化しますが、それら自身のユーザ_資格証明書を作成できません。 サーバがそれ自身に代わって接続を開始するなら、それはいかなる他のユーザもまさしく持っていたかもしれないようにチケットを持たなければなりません。 そのチケットは生涯を制限しました、そして、サーバを代表して行動する権利を代表として派遣することができます。 しかしながら、サーバはそれのために意図する接続を受ける権利を代表として派遣することができません。 実装はサーバチケットと満了のずっと前にそれらがどう更新されるかに関する満了のための方針を思いつかなければなりません。 ありそうな方針は資格証明書における現在のどんな当日券もなければこの手順がCreate_トークンによってそれとなく呼ばれることです。 そうだとすれば、このインタフェースは暴露される必要はありません。
This routine is implemented as follows:
このルーチンは以下の通り実装されます:
a) Generate an RSA public/private key pair.
a) RSA公衆/秘密鍵組を生成してください。
b) Compute a validity interval from the current time and the
expiration supplied.
b) 現在の時間と供給された満了からの正当性間隔を計算してください。
c) Construct a login ticket from the RSA public key (from a),
validity interval (from b), the UID from the credentials, and
signed with the server key in the credentials. (Discard
previous Login Ticket if there was one).
c) RSA公開鍵からログインチケットを組み立ててください。(資格証明書における資格証明書の、そして、サーバで署名されたキーからのa)、正当性間隔(bからの)、UIDから。 (1つがあったなら、前のLogin Ticketを捨てます。)
d) Discard all information in the Cached Outgoing Contexts.
d) Cached Outgoing Contextsのすべての情報を捨ててください。
3.9.6 Delete Credentials
3.9.6 資格証明書を削除してください。
delete_credentials(
--updated
credentials Credentials)
_資格証明書を削除してください。(--、アップデートされた資格証明書Credentials)
Erases the secrets in the credentials structure and deallocates the storage.
資格証明書構造で秘密を消して、ストレージを「反-割り当て」ます。
Kaufman [Page 62] RFC 1507 DASS September 1993
コーフマン[62ページ]RFC1507ダス1993年9月
3.10 Authentication Procedures
3.10 認証手順
The guts of the authentication process takes place in the next two calls. When one principal wishes to authenticate to another, it calls Create_token and sends the token which results to the other. The recipient calls Accept_token and creates a new set of credentials. The other calls in this section manipulate the received credentials in order to retrieve its contents and verify the identity of the token creator.
認証過程の腸は次の2つの呼び出しで行われます。 1つの主体であるときに、別のものに認証する願望であり、それは、Createを_トークンと呼んで、もう片方に結果として生じるトークンを送ります。 受取人は、Acceptを_トークンと呼んで、新しいセットの資格証明書を作成します。 このセクションでの他の呼び出しは、コンテンツを検索するために容認された資格証明書を操って、トークンクリエイターのアイデンティティについて確かめます。
3.10.1 Create Token
3.10.1 トークンを作成してください。
Create_token(
--inputs
target_name Name,
deleg_req_flag Boolean,
mutual_req_flag Boolean,
replay_det_req_flag Boolean,
sequence_req_flag Boolean,
chan_bindings Octet String,
Include_principal_name Boolean,
Include_node_name Boolean,
Include_username Boolean,
--updated
claimant_credentials Credentials,
--outputs
authentication_token Authentication token,
mutual_authentication_token
Mutual Authentication token,
Shared_key Shared Key,
instance_identifier Timestamp)
_トークンを作成してください。(--入力目標_名のName(Include_主体_名のブールの、そして、Include_ノード_名のブールの、そして、Include_ユーザ名ブールのdeleg_req_旗のブールの、そして、互いの_req_旗のブールの、そして、再生_det_req_旗のブールの、そして、系列_req_旗のブールのchan_結合Octet String(アップデートされた主張者_資格証明書Credentials))は認証_トークンAuthenticationトークンを出力します、互いの_認証_トークンMutual Authenticationトークン、_の主要なShared Shared Key、インスタンス_識別子Timestamp)
This routine is used by the initiator of a connection to create an authentication token which will prove its identity. If the claimant credentials includes node/account information, the token will include node authentication.
このルーチンは、アイデンティティを立証する認証トークンを作成するのに接続の創始者によって使用されます。 主張者資格証明書がノード/会計情報を含んでいると、トークンはノード認証を含むでしょう。
target_name is the X.500 name of the intended recipient of the token. Only an entity with access to the private key associated with that name will be able to verify the created token and generate the mutual_authentication_token.
目標_名前はトークンの意図している受取人のX.500名です。 その名前に関連している秘密鍵へのアクセスがある実体だけが、作成されたトークンについて確かめて、互いの_認証_トークンを生成することができるでしょう。
deleg_req_flag indicates whether the caller wishes to delegate to the recipient of the token. If it is set, the delegated_credentials returned by Accept_token will be capable of generating tokens on behalf of the caller. Node based authentication information cannot be delegated. The mutual_req_flag, replay_det_req_flag , and sequence_req_flag are put in the authentication token and passed to
deleg_req_旗は、訪問者がトークンの受取人に委任したがっているかどうかを示します。 それが設定されると、Accept_トークンによって返された代表として派遣された_資格証明書は訪問者を代表してトークンを生成することができるでしょう。 ノードに基づいている認証情報を代表として派遣することができません。 互いの_req_旗、再生_det_req_旗、および系列_req_旗に認証トークンに入れられて、通過されます。
Kaufman [Page 63] RFC 1507 DASS September 1993
コーフマン[63ページ]RFC1507ダス1993年9月
the target. This information is included in the token to make it easier to implement the GSSAPI over DASS. DASS itself makes no use of this information.
目標。 この情報は、ダスの上でGSSAPIを実装するのをより簡単にするようにトークンに含まれています。 ダス自身はこの情報の無駄をします。
In most applications, the purpose of a token exchange is to authenticate the principals controlling the two ends of a communication channel. chan_bindings contains an identifier of the channel which is being authenticated, and thus its format and content should be tied to the underlying communication protocol. DASS only guarantees that the information has been communicated reliably to the named target. If DASS is used with a cryptographically protected channel (such as SP4), this data should contain a one-way hash of the key used to encrypt the channel. If that channel is multiplexed, the data should also include the ID of the subchannel. If the channel is not encrypted, the network must be trusted not to modify data on a connection. The source and target network addresses and a connection ID should be included in the chan_bindings at the source and checked at the target. A token exchange also results in the two ends sharing a key and an instance identifier. If that key and instance identifier are used to cryptographically protect subsequent communications, then chan_bindings need not have any cryptographic significance but may be used to differentiate multiple entities sharing the public keys of communicating principals. For example, if a service is replicated and all replicas share a public key, chan_bindings should include something that identifies a single instance of the service (such as current address) so that the token cannot be successfully presented to more than one of the servers.
ほとんどのアプリケーションでは、トークン交換の目的は通信チャネルchan_結合の2つの終わりを制御する校長を認証するのが認証されているチャンネルに関する識別子を含んでいて、その結果、その形式と内容が基本的な通信プロトコルに結ばれるべきであるということです。 ダスは、情報が命名された目標に確かに伝えられたのを保証するだけです。 暗号で保護されたチャンネル(SP4などの)でダスが使用されるなら、このデータはチャンネルを暗号化するのに使用されるキーの一方向ハッシュを含むべきです。 また、そのチャンネルを多重送信するなら、データはサブチャネルのIDを含むべきです。 チャンネルが暗号化されていないなら、接続に関するデータを変更しないとネットワークを信じなければなりません。 ソース、目標ネットワーク・アドレス、および接続IDは、ソースにchan_結合に含まれていて、目標でチェックされるべきです。 また、トークン交換は、キーとインスタンス識別子を共有しながら、2つの終わりをもたらします。 そのキーとインスタンス識別子が暗号でその後のコミュニケーションを保護するのに使用されるなら、chan_結合は、少しの暗号の意味も持つ必要はありませんが、交信主体の公開鍵を共有する複数の実体を差別化するのに使用されるかもしれません。 例えば、サービスが模写されて、すべてのレプリカが公開鍵を共有するなら、chan_結合は首尾よくサーバの1つ以上にトークンを提示できないようにただ一つのサービス(現在のアドレスなどの)のインスタンスを特定する何かを含むべきです。
include_principal_name, include_node_name, and include_username are flags which determine whether the principal name, node name, and/or username from the credentials structure are to be included in the token. This information is made optional in a token so that applications which communicate this information out of band can produce "compressed" tokens. If this information is included in the token, it will be used to populate the corresponding fields in the credentials structure created by Accept_token. claimant_credentials are the credentials of the calling procedure. The secrets contained therein are used to sign the token and the trusted authorities are used to securely learn the public key of the target. The cached outgoing contexts portion of the credentials may be updated as a side effect of this call.
インクルード_主体_名、インクルード_ノード_名、およびインクルード_ユーザ名が旗である、どれ、構造がある資格証明書からの主要な名前、ノード名、そして/または、ユーザ名が含まれているか否かに関係なく、トークンで決定するか。 バンドからこの情報を伝えるアプリケーションが「圧縮された」トークンを生産できるように、この情報をトークンで任意にします。 この情報がトークンに含まれていると、それは、Accept_トークンによって作成された資格証明書構造で対応する分野に居住するのに使用されるでしょう。主張者_資格証明書は呼ぶ手順の資格証明書です。 そこに含まれた秘密はトークンに署名するのに使用されます、そして、信じられた当局は、しっかりと目標の公開鍵を学ぶのに使用されます。 この呼び出しの副作用として資格証明書のキャッシュされた外向的な文脈部分をアップデートするかもしれません。
The major output of this routine is an authentication_token which can be passed to the target in order to authenticate the caller.
このルーチンの主要な出力は訪問者を認証するために目標に通過できる認証_トークンです。
In addition to returning an authentication token, this routine returns a mutual_authentication_token, a shared_key, and an instance_identifier. The mutual authentication token is the same as
認証トークンを返すことに加えて、このルーチンは互いの_認証_トークン、共有された_キー、およびインスタンス_識別子を返します。 トークンが同じである互いの認証
Kaufman [Page 64] RFC 1507 DASS September 1993
コーフマン[64ページ]RFC1507ダス1993年9月
the one generated by the Accept_token call at the target. If the protocol using DASS wishes mutual authentication, the target should return this token to the source. The source will compare it to the one returned by this routine using Compare_Mutual_Token (below) and know that the token was accepted at its proper destination.
the one generated by the Accept_token call at the target. If the protocol using DASS wishes mutual authentication, the target should return this token to the source. The source will compare it to the one returned by this routine using Compare_Mutual_Token (below) and know that the token was accepted at its proper destination.
The DES key and instance identifier can be used to encrypt or sign data to be sent to this target. The key and instance will be given to the target by Accept_token, and the key will only be known by the two parties to the authentication. If a single set of credentials is used to authenticate to the same target more than once, the same DES key is likely to be returned each time. If the parties wish to protect against the possibility of an outside agent mixing and matching messages from one authenticated session with those of another, they should include the instance identifier in the messages. The instance identifier is a timestamp and it is guaranteed that the DES key/instance identifier pair will be unique.
The DES key and instance identifier can be used to encrypt or sign data to be sent to this target. The key and instance will be given to the target by Accept_token, and the key will only be known by the two parties to the authentication. If a single set of credentials is used to authenticate to the same target more than once, the same DES key is likely to be returned each time. If the parties wish to protect against the possibility of an outside agent mixing and matching messages from one authenticated session with those of another, they should include the instance identifier in the messages. The instance identifier is a timestamp and it is guaranteed that the DES key/instance identifier pair will be unique.
An implementation may wish to "hide" the DES key from calling applications by placing it in system storage and providing calls which encrypt/decrypt/sign/verify using the key.
An implementation may wish to "hide" the DES key from calling applications by placing it in system storage and providing calls which encrypt/decrypt/sign/verify using the key.
The primary tasks of this routine are to create its output parameters. As a side effect, it may also update claimant_credentials It's algorithm is as follows:
The primary tasks of this routine are to create its output parameters. As a side effect, it may also update claimant_credentials It's algorithm is as follows:
a) The login ticket is checked. If it has passed the end of its
lifetime an `Login Ticket Expired' error is returned. If there
is a login ticket, but no corresponding private key then an
`Invalid credentials' error is returned (this is the case if
the credentials were created by an authentication-without-
delegation operation). If there is no login ticket or an
expired one and if the long term private key is present in the
credentials, an implementation may choose to automatically call
create_server_ticket to renew the ticket.
a) The login ticket is checked. If it has passed the end of its lifetime an `Login Ticket Expired' error is returned. If there is a login ticket, but no corresponding private key then an `Invalid credentials' error is returned (this is the case if the credentials were created by an authentication-without- delegation operation). If there is no login ticket or an expired one and if the long term private key is present in the credentials, an implementation may choose to automatically call create_server_ticket to renew the ticket.
b) Create new timestamp using the current time. (This timestamp
must be unique for this Shared Key. The timestamp is a 64 bit
POSIX time, with a resolution of 1 nanosecond An implemen tation
must ensure that timestamps cannot be reused.)
b) Create new timestamp using the current time. (This timestamp must be unique for this Shared Key. The timestamp is a 64 bit POSIX time, with a resolution of 1 nanosecond An implemen tation must ensure that timestamps cannot be reused.)
c) The public key and UID of target_name are looked up by calling
get_pub_keys, using the target_name and the Trusted Authority
section of the claimant_credentials structure. If none is
found, an error status is returned. Otherwise, the cached
outbound connections portion of credentials are searched
(indexed by target Public Key) for a cached Shared key with a
validity interval which has not expired. If a suitable one is
c) The public key and UID of target_name are looked up by calling get_pub_keys, using the target_name and the Trusted Authority section of the claimant_credentials structure. If none is found, an error status is returned. Otherwise, the cached outbound connections portion of credentials are searched (indexed by target Public Key) for a cached Shared key with a validity interval which has not expired. If a suitable one is
Kaufman [Page 65] RFC 1507 DASS September 1993
Kaufman [Page 65] RFC 1507 DASS September 1993
found skip to step g, else create a cache entry as follows:
found skip to step g, else create a cache entry as follows:
d) Destination Public Key is the one found looking up the target.
A Shared Key is generated at random. A validity interval is
chosen according to node policy but not to exceed the validity
interval of the ticket in the credentials (if any).
d) Destination Public Key is the one found looking up the target. A Shared Key is generated at random. A validity interval is chosen according to node policy but not to exceed the validity interval of the ticket in the credentials (if any).
e) Create the Encrypted Shared Key, using the public key of the
Target, and place in the cache.
e) Create the Encrypted Shared Key, using the public key of the Target, and place in the cache.
f) If node authentication credentials are available in the
credentials structure, create a "Node Ticket" signature using
the node secret and include it in the cache.
f) If node authentication credentials are available in the credentials structure, create a "Node Ticket" signature using the node secret and include it in the cache.
g) If delegation is requested and no delegator is present in the
cache, create one by encrypting the delegation private key
under the Shared key. The delegation private key is
represented as an ASN.1 data structure containing only one of
the primes (p).
g) If delegation is requested and no delegator is present in the cache, create one by encrypting the delegation private key under the Shared key. The delegation private key is represented as an ASN.1 data structure containing only one of the primes (p).
h) If delegation is not requested and no Shared Key Ticket is in
the cache, create one by signing the requisite information
with the delegation private key.
h) If delegation is not requested and no Shared Key Ticket is in the cache, create one by signing the requisite information with the delegation private key.
i) Create the Authenticator. The contents of the Authenticator
(including the channel bindings) are encoded into ASN.1, and
the signature is computed. The Authenticator is then
re-encoded, without including the Channel Bindings but using
the same signature.
i) Create the Authenticator. The contents of the Authenticator (including the channel bindings) are encoded into ASN.1, and the signature is computed. The Authenticator is then re-encoded, without including the Channel Bindings but using the same signature.
j) Create output_token as follows:
1) Encrypted Shared Key from cache
2) Login Ticket from Claimant Credentials (if present)
3) Shared Key Ticket from cache (if no delegation and if
present)
4) Node Ticket from cache (if present)
5) Delegator from cache (if delegation and if present)
6) Authenticator
7) Principal name from credentials (if present and parameter
requests this)
8) Node name from credentials (if present and parameter request
this)
9) Local Username from credentials (if present and parameter
requests this)
j) Create output_token as follows: 1) Encrypted Shared Key from cache 2) Login Ticket from Claimant Credentials (if present) 3) Shared Key Ticket from cache (if no delegation and if present) 4) Node Ticket from cache (if present) 5) Delegator from cache (if delegation and if present) 6) Authenticator 7) Principal name from credentials (if present and parameter requests this) 8) Node name from credentials (if present and parameter request this) 9) Local Username from credentials (if present and parameter requests this)
k) Compute Mutual_authentication_token by encrypting the
timestamp from the authenticator using the Shared key.
k) Compute Mutual_authentication_token by encrypting the timestamp from the authenticator using the Shared key.
Kaufman [Page 66] RFC 1507 DASS September 1993
Kaufman [Page 66] RFC 1507 DASS September 1993
l) The instance_identifier is the timestamp. This and the Shared
key are returned for use by the caller for further encryption
operations (if these are supported).
l) The instance_identifier is the timestamp. This and the Shared key are returned for use by the caller for further encryption operations (if these are supported).
3.10.2 Accept_token
3.10.2 Accept_token
Accept_token(
--inputs
authentication_token Authentication Token,
chan_bindings Octet String,
--updated
verifying_credentials Credentials,
--outputs
accepted_credentials Credentials,
deleg_req_flag Boolean,
mutual_req_flag Boolean,
replay_det_req_flag Boolean,
sequence_req_flag Boolean,
mutual_authentication_token
Mutual authentication token
shared_key Shared Key,
instance_identifier Timestamp)
Accept_token( --inputs authentication_token Authentication Token, chan_bindings Octet String, --updated verifying_credentials Credentials, --outputs accepted_credentials Credentials, deleg_req_flag Boolean, mutual_req_flag Boolean, replay_det_req_flag Boolean, sequence_req_flag Boolean, mutual_authentication_token Mutual authentication token shared_key Shared Key, instance_identifier Timestamp)
This routine is used by the recipient of an authentication token to validate it. authentication_token is the token as received; chan_bindings is the identifier of the channel being authenticated. See the description of Create_token for information on the appropriate contents for chan_bindings. DASS does not enforce any particular content, but checks to assure that the same value is supplied to both Create_token and Accept_token.
This routine is used by the recipient of an authentication token to validate it. authentication_token is the token as received; chan_bindings is the identifier of the channel being authenticated. See the description of Create_token for information on the appropriate contents for chan_bindings. DASS does not enforce any particular content, but checks to assure that the same value is supplied to both Create_token and Accept_token.
Verifying_credentials are the credentials of the recipient of the token. They must include the private key of the entity named as the target in Create_token or the call will fail. The cached incoming contexts section of the verifying credentials may be modified as a side effect of this call.
Verifying_credentials are the credentials of the recipient of the token. They must include the private key of the entity named as the target in Create_token or the call will fail. The cached incoming contexts section of the verifying credentials may be modified as a side effect of this call.
Accepted_credentials will contain additional information about the token creator. If delegation was requested, these credentials can be used to make additional calls to Create_token on the creator's behalf. Whether or not delegation was requested, they can also be used in the calls which follow to gain additional information about the token creator.
Accepted_credentials will contain additional information about the token creator. If delegation was requested, these credentials can be used to make additional calls to Create_token on the creator's behalf. Whether or not delegation was requested, they can also be used in the calls which follow to gain additional information about the token creator.
The deleg_req_flag indicates whether the accepted_credentials include delegation which can be used by the recipient to act on behalf of the principal. Mutual_req_flag, replay_det_req_flag, and sequence_req_flag are passed through from Create_token in support of
The deleg_req_flag indicates whether the accepted_credentials include delegation which can be used by the recipient to act on behalf of the principal. Mutual_req_flag, replay_det_req_flag, and sequence_req_flag are passed through from Create_token in support of
Kaufman [Page 67] RFC 1507 DASS September 1993
Kaufman [Page 67] RFC 1507 DASS September 1993
the GSSAPI. DASS makes no use of these fields.
the GSSAPI. DASS makes no use of these fields.
The mutual_authentication_token can be returned to the token creator as proof of receipt. In many protocols, this will be used by a client to authenticate a server. Only the genuine server would be able to compute the mutual_authentication_token from the token.
The mutual_authentication_token can be returned to the token creator as proof of receipt. In many protocols, this will be used by a client to authenticate a server. Only the genuine server would be able to compute the mutual_authentication_token from the token.
The shared_key and instance_identifier can be used to encrypt or sign data between the two authenticating parties. See Create_token.
The shared_key and instance_identifier can be used to encrypt or sign data between the two authenticating parties. See Create_token.
This routine verifies the contents of the authentication token in the context of the verifying credentials (In particular, the Private Key of the server is used. Also, the Cached Incoming Contexts and Incoming Timestamp list is used.) and returns information about it. The algorithm updates a cache of information. This cache is not updated if the algorithm exits with an error. The algorithm is as follows:
This routine verifies the contents of the authentication token in the context of the verifying credentials (In particular, the Private Key of the server is used. Also, the Cached Incoming Contexts and Incoming Timestamp list is used.) and returns information about it. The algorithm updates a cache of information. This cache is not updated if the algorithm exits with an error. The algorithm is as follows:
a) If there is a Login Ticket, but no Shared Key Ticket or
Delegator then exit with error `Invalid Authenticator'. If
there is a Shared Key Ticket or Delegator, but no Login Ticket
then exit with error `Invalid Authentication Token'.
a) If there is a Login Ticket, but no Shared Key Ticket or Delegator then exit with error `Invalid Authenticator'. If there is a Shared Key Ticket or Delegator, but no Login Ticket then exit with error `Invalid Authentication Token'.
Look up the Encrypted Shared key in the Cached Incoming Contexts
of the credentials structure. (This cache entry is used during
the execution of this routine. An implementation must ensure that
references to the cache entry can not be affected by other users
modifying the cache. One way is to use a copy of the cache entry,
and update it at exit.) If it is not found then create
a new cache entry as follows:
Look up the Encrypted Shared key in the Cached Incoming Contexts of the credentials structure. (This cache entry is used during the execution of this routine. An implementation must ensure that references to the cache entry can not be affected by other users modifying the cache. One way is to use a copy of the cache entry, and update it at exit.) If it is not found then create a new cache entry as follows:
1) Encrypted Shared Key, from the Authentication Token.
1) Encrypted Shared Key, from the Authentication Token.
2) Shared Key and Validity Interval, by decrypting the
Encrypted Shared Key using the server private key in
credentials. If the decryption fails then exit with error
`Invalid Authentication Token'.
2) Shared Key and Validity Interval, by decrypting the Encrypted Shared Key using the server private key in credentials. If the decryption fails then exit with error `Invalid Authentication Token'.
b) Check that the Validity Interval (in the cache entry) includes
the current time; return `Invalid Authentication Token' if not.
b) Check that the Validity Interval (in the cache entry) includes the current time; return `Invalid Authentication Token' if not.
Check the Timestamp is within max-clock-skew of the current
time, return `invalid Authentication Token' if not.
Check the Timestamp is within max-clock-skew of the current time, return `invalid Authentication Token' if not.
Reconstruct the Authenticator including the Channel Bindings
passed as a parameter.
Reconstruct the Authenticator including the Channel Bindings passed as a parameter.
Kaufman [Page 68] RFC 1507 DASS September 1993
Kaufman [Page 68] RFC 1507 DASS September 1993
Check that the reconstructed Authenticator is signed by the
Shared key. If not then exit with error `Invalid
Authentication Token'.
Check that the reconstructed Authenticator is signed by the Shared key. If not then exit with error `Invalid Authentication Token'.
Look up the Authenticator Signature in the Received
Authenticators. If the same Signature is found in the list
then exit with error `Duplicate Authenticator'. Otherwise add
the Signature and timestamp to the list.
Look up the Authenticator Signature in the Received Authenticators. If the same Signature is found in the list then exit with error `Duplicate Authenticator'. Otherwise add the Signature and timestamp to the list.
If there is a Login Ticket and the Delegation Public key is in
the cache entry, then check that the same key is specified in
the Login Ticket, if not then exit with error `Invalid
Authentication Token'. Place the Delegation Public key in the
cache if it is not already there.
If there is a Login Ticket and the Delegation Public key is in the cache entry, then check that the same key is specified in the Login Ticket, if not then exit with error `Invalid Authentication Token'. Place the Delegation Public key in the cache if it is not already there.
If there is a Login Ticket, the Delegation Public key was not
previously in the cache entry, and there is a Shared Key
Ticket in the Authentication Token, then check that the Shared
Key Ticket is signed by the Delegation Public Key in the Login
Ticket. If not then exit with error `Invalid Authentication
Token'.
If there is a Login Ticket, the Delegation Public key was not previously in the cache entry, and there is a Shared Key Ticket in the Authentication Token, then check that the Shared Key Ticket is signed by the Delegation Public Key in the Login Ticket. If not then exit with error `Invalid Authentication Token'.
If a delegator is present in the message then decrypt the
delegator using the Shared key. If the private key does not
match the Delegation Public key then exit with error
`Invalid Authentication Token' (The prime in the delegator
is used to find the other prime (from the modulus). The division
must not have a remainder. Neither prime may be 1. The two
primes are then used to reconstruct any other information
needed to perform cryptographic operations.).
If a delegator is present in the message then decrypt the delegator using the Shared key. If the private key does not match the Delegation Public key then exit with error `Invalid Authentication Token' (The prime in the delegator is used to find the other prime (from the modulus). The division must not have a remainder. Neither prime may be 1. The two primes are then used to reconstruct any other information needed to perform cryptographic operations.).
Build the delegation credentials data structure as follows:
Build the delegation credentials data structure as follows:
1) Claimant credentials:
(i) Login Ticket from the Authentication token
(ii) Delegation Private key from the decrypted delegator if
the token is delegating.
(iii)Encrypted Shared Key from the Authentication token.
2) There are no verifier credentials.
3) Trusted authorities are copied from the verifying_credentials
passed to this routine (If an implementation is able to
obtain the original Trusted Authorities of the Principal then
it may do so instead of using the server's Trusted
Authorities.).
4) Remote node credentials (Node name, Username, Node Ticket)
5) There are no local node credentials.
6) There are no cached contexts.
1) Claimant credentials: (i) Login Ticket from the Authentication token (ii) Delegation Private key from the decrypted delegator if the token is delegating. (iii)Encrypted Shared Key from the Authentication token. 2) There are no verifier credentials. 3) Trusted authorities are copied from the verifying_credentials passed to this routine (If an implementation is able to obtain the original Trusted Authorities of the Principal then it may do so instead of using the server's Trusted Authorities.). 4) Remote node credentials (Node name, Username, Node Ticket) 5) There are no local node credentials. 6) There are no cached contexts.
Kaufman [Page 69] RFC 1507 DASS September 1993
Kaufman [Page 69] RFC 1507 DASS September 1993
c) The returned boolean values are obtained from the
Authenticator.
c) The returned boolean values are obtained from the Authenticator.
d) Mutual_authentication_token is computed by encrypting the
timestamp from the Authenticator with the Shared key from the
cache.
d) Mutual_authentication_token is computed by encrypting the timestamp from the Authenticator with the Shared key from the cache.
e) Instance_identifier is the timestamp from the Authenticator.
This and the Shared key are returned to the caller for further
encryption operations (if these are supported).
e) Instance_identifier is the timestamp from the Authenticator. This and the Shared key are returned to the caller for further encryption operations (if these are supported).
3.10.3 Compare Mutual Token
3.10.3 Compare Mutual Token
Compare_mutual_token(
--inputs
Generated_token Mutual authentication token,
Received_token Mutual authentication token,
--outputs
equality_flag Boolean)
Compare_mutual_token( --inputs Generated_token Mutual authentication token, Received_token Mutual authentication token, --outputs equality_flag Boolean)
This routine compares two mutual authentication tokens and tells whether they match. In the expected use, the first is the token generated by Create_token at the initiating end and the second is the token generated by Accept_token at the accepting end and returned to the initiating end. This routine can be implemented as a byte by byte comparison of the two parameters.
This routine compares two mutual authentication tokens and tells whether they match. In the expected use, the first is the token generated by Create_token at the initiating end and the second is the token generated by Accept_token at the accepting end and returned to the initiating end. This routine can be implemented as a byte by byte comparison of the two parameters.
3.10.4 Get Node Info
3.10.4 Get Node Info
get_node_info(
--inputs
accepted_credentials Credentials,
--outputs
nodename Name,
username String)
get_node_info( --inputs accepted_credentials Credentials, --outputs nodename Name, username String)
This routine extracts from accepted credentials the name of the node from which the authentication token came and the named account on that node. Because this information is not cryptographically protected within the token, this information can only be regarded as a "hint" by the receiving application. It can, however, be verified using Verify_node_name in a cryptographically secure manner. This information will only be present if these are accepted credentials and it the caller of Create_token set the include_node_name and/or include_username flags.
このルーチンはそのノードで受け入れられた信任状から認証象徴が来たノードの名前と命名されたアカウントを抜粋します。 この情報が象徴の中に暗号で保護されないので、受信アプリケーションでこの情報を「ヒント」と見なすことができるだけです。 それは保証できて、しかしながら、確かめられた使用がaのVerify_ノード_名であったなら暗号で方法を保証してください。 この情報はこれらが受け入れられた信任状であり、それがインクルード_ノード_名、そして/または、インクルード_ユーザ名が旗を揚げさせるCreate_象徴セットの訪問者である場合にだけ存在するでしょう。
An actual implementation is not likely to have get_node_info and verify_node_name as separate calls. They are specified this way
実際の実現は_ノード_インフォメーションを得て、電話することを別々の_ノード_名前について確かめるのを持っていそうにはありません。 それらはこのように指定されます。
Kaufman [Page 70] RFC 1507 DASS September 1993
コーフマン[70ページ]RFC1507ダス1993年9月
because there are different ways this information might be used. For most applications, the nodename and username will be included in the token, and a single function might extract and verify them (it might in fact be part of accept token). For other applications, the nodename and username will not be in the token but rather will be computed from other information passed during connection initiation so a call would have to take these as inputs. Still other applications such as ACL evaluators that want to support the renaming and aliasing capabilities of DASS would defer verifying node information until they came upon an ACL which allowed access only from a particular node. They would then verify that the name on the ACL was an authenticatable alias for the node which created the token. All of these uses can be defined in terms of calls to get_node_info and verify_node_name.
異なった道があるので、この情報は使用されるかもしれません。 ほとんどのアプリケーションにおいて、nodenameとユーザ名が象徴に含まれて、ただ一つの機能がそれらを抽出して、確かめるかもしれない、(事実上、それが部分であるかもしれない、受諾、象徴) 他のアプリケーションにおいて、nodenameとユーザ名が象徴にありませんが、接続開始の間に通過された他の情報からむしろ計算されるので、呼び出しは入力としてこれらをみなさなければならないでしょう。 特定のノードだけからアクセスを許したACLに出くわすまでノード情報について確かめながらダスの能力が延期する改名とエイリアシングを支持したがっているACL評価者などのまだ他のアプリケーション。 そして、彼らは、ACLの上の名前が通称象徴を作成したノードのための認証可能であったことを確かめるでしょう。 _ノード_インフォメーションを得て、_ノード_名前について確かめるという要求でこれらの用途のすべてを定義できます。
3.10.5 Get Principal UID
3.10.5 UID校長を手に入れてください。
get_principal_uid(
--inputs
accepted_credentials Credentials,
--outputs
uid UID)
_校長_uidを手に入れてください。(--入力は_信任状Credentialsを受け入れました--uid UIDを出力する)
This routine extracts a principal UID from a set of credentials.
このルーチンは1セットの信任状からUID校長を抽出します。
As with Get_Node_Info, this interface is not likely to appear in an actual implementation, but rather will be bundled with other routines. It is specified this way because there might be a variety of algorithms by which credentials are evaluated and all of them can be defined in terms of these primitives.
Get_Node_Infoの場合、このインタフェースは、実際の実現では現れそうではありませんが、他のルーチンでむしろ束ねられるでしょう。 信任状を評価して、これらの基関数でそれらのすべてを定義できるさまざまなアルゴリズムがあるかもしれないので、それはこのように指定されます。
In DASS, it is possible for a principal to have many aliases. This can happen either because the principal was given multiple names to limit the number of CAs that need to be trusted when authenticating to different servers or because the principal's name has changed and the old name remains behind as an alias. Accept_token returns the name by which the principal identified itself when creating its credentials. A service may know the user by some alias. The normal way to handle this is for the service to know the principal's UID (which is constant over name changes) and to compare it with the UID in the token to identify a likely alias situation. It gets the UID from the token using this routine. It then confirms the alias by calling verify_principal_name.
ダスでは、元本には多くの別名があるのは、可能です。 異なったサーバに認証するとき、信じられる必要があるCAsの数を制限するために複数の名前を校長に与えたか、校長の名前が変化して、または旧名が別名として後ろにいるので、これは起こることができます。 象徴が信任状を作成するとき校長が身元を明らかにした名前を返す_を受け入れてください。 サービスは何らかの別名でユーザを知るかもしれません。 これを扱う正常な方法は、サービスが校長のUID(改名の上で一定である)を知って、ありそうな別名状況を特定するために象徴でUIDとそれを比べることです。 それは、象徴からこのルーチンを使用することでUIDを手に入れます。 そして、それは、呼ぶのによる別名が_校長_名前について確かめると確認します。
The UID is in a signed portion of accepted credentials, but the signature may not have been verified at the time this call is issued. The information returned by this routine must therefore be regarded as a hint. If a call to Verify_principal_name succeeds, however,
UIDが受け入れられた信任状のサインされた部分にありますが、この呼び出しが発行されるとき、署名は確かめられていないかもしれません。 したがって、このルーチンで返された情報をヒントと見なさなければなりません。 しかしながら、Verify_校長_名への呼び出しが成功するなら
Kaufman [Page 71] RFC 1507 DASS September 1993
コーフマン[71ページ]RFC1507ダス1993年9月
then the caller can securely know that the name given to that routine and the UID returned by this one are the authenticated source of the token.
そして、訪問者は、そのルーチンに与えられた名前とこれによって返されたUIDが象徴の認証された源であることをしっかりと知ることができます。
3.10.6 Get Principal Name
3.10.6 主要な名前を得てください。
get_principal_name(
--inputs
accepted_credentials Credentials,
--outputs
name Name)
_校長_名前を得てください。(--入力は_信任状Credentialsを受け入れました--出力がNameを命名する)
This routine extracts a principal name from a set of credentials. This name is the name most recently associated with the principal. It may be the name that the principal supplied when the credentials were created (in which case it may not have been verified yet) or it may be a different name that has been verified.
このルーチンは1セットの信任状から主要な名前を抜粋します。 この名前はごく最近という校長に関連している名前です。 確かめられたのは、信任状が作成されたか(その場合、それはまだ確かめられていないかもしれません)、それが異なった名前であるときに校長が提供した名前であるかもしれません。
As with Get_Node_Info and Get_Principal_UID, this routine is not likely to appear in an actual implementation, but will be bundled in some fashion with related procedures. The name returned by this procedure is not guaranteed to have been cryptographically verified. Verify_Principal_Name performs that function.
Get_Node_InfoとGet_プリンシパル_UIDの場合、このルーチンは、実際の実現では現れそうではありませんが、関連する手順で何らかのファッションで束ねられるでしょう。 この手順で返された名前は、暗号で確かめられたために保証されません。 _プリンシパルについて確かめてください。_Nameはその機能を実行します。
3.10.7 Get Lifetime
3.10.7 生涯を得てください。
get_lifetime(
--inputs
Claimant_credentials Credentials,
--outputs
lifetime Duration)
_生涯を得てください。(生涯Durationを出力します(入力Claimant_信任状Credentials))
This routine computes the life remaining in a set of credentials. Its most common use would be to know to renew credentials before they expire.
このルーチンは、信任状のセットに残りながら、人生を計算します。 最も一般的な使い方は期限が切れる前に信任状を更新するのを知るだろうことです。
Returns the remaining lifetime of the login ticket in the credentials. This can either be the done on the node where the original login took place, or at a server which has been delegated to. It indicates how much longer these credentials can be used for further delegations. This routine will return 0 if the login ticket has passed the end of its life, if there is no login ticket, or if the credentials do not contain the private key certified by the ticket (i.e., where they were created by an authentication-without- delegation operation).
信任状でログインチケットの残っている生涯を返します。 これはノードの上、または、オリジナルのログインが行われた委任されたサーバにおいてであることができます。 それは、一層の代表団にどれほど長い間これらの信任状を使用できるかを示します。 ログインチケットが末期を渡したなら、このルーチンは0を返すでしょう、信任状がチケットによって公認された秘密鍵を含んでいないならログインチケットが全くなければ(すなわち、それらが認証で作成されたところ、-、代表団操作、)
Kaufman [Page 72] RFC 1507 DASS September 1993
コーフマン[72ページ]RFC1507ダス1993年9月
3.10.8 Verify Node Name
3.10.8 ノード名について確かめてください。
Verify_node_name(
--inputs
nodename Name,
username String,
--updated
verifying_credentials Credentials,
accepted_credentials Credentials,
--outputs
Name matches Boolean)
_ノード_名前について確かめてください。(--入力nodename Name(ユーザ名String(_信任状Credentials、受け入れられた_信任状Credentialsについて確かめながら、アップデートする))がブールでNameマッチを出力する)
This routine tests whether the originating node of an authentication token can be authenticated as having the provided name. Like a principal, a node may have multiple aliases. One of them may be returned by Get_node_info, but this call allows a suspected alias to be verified. The verifying credentials supplied with this call must be the same credentials as were used in the Accept_token call. The procedure for completing this request is as follows:
提供された名前を持っていると認証象徴の由来しているノードを認証できるか否かに関係なく、このルーチンはテストされます。 元本のように、ノードには、複数の別名があるかもしれません。 Get_ノード_インフォメーションでそれらの1つを返すかもしれませんが、この呼び出しは、疑われた別名が確かめられるのを許容します。 この呼び出しが供給された検証信任状はAccept_象徴呼び出しに使用された同じ信任状であるに違いありません。 この要求を終了するための手順は以下の通りです:
a) If there is no Node Ticket in the claimant credentials then
return False.
a) 主張者信任状にNode Ticketが全くなければ、Falseを返してください。
b) Search the incoming context cache of the verifying credentials
for an entry containing the same encrypted shared key as the
encrypted shared key subfield of the claimant information of
the accepted credentials. In the steps which follow,
references to "the cache" refer to this entry. If none is
found, initialize such an entry as follows:
b) 受け入れられた信任状の主張者情報のコード化された共有された主要な部分体と同じコード化された共有されたキーを含むエントリーとして検証信任状の入って来る文脈キャッシュを捜してください。 従う方法では、「キャッシュ」の参照はこのエントリーについて言及します。 なにも見つけられないなら、以下のそのようなエントリーを初期化してください:
1) Encrypted shared key from the encrypted shared key subfield
of the claimant information of the accepted credentials.
1) 受け入れられた信任状の主張者情報のコード化された共有された主要な部分体からのコード化された共有されたキー。
2) The shared key and validity interval are determined by
decrypting the encrypted shared key using the RSA private
key in the verifier information of the server credentials.
If this procedure is called after a call to Accept_token
using the same server credentials (as is required for
correct use), the shared key and validity interval must
correctly decrypt. If called in some other context, the
results are undefined. The validity interval is not
checked.
2) 共有されたキーと正当性間隔は、サーバ信任状の検証情報でRSA秘密鍵を使用しながら、コード化された共有されたキーを解読することによって、決定します。 この手順が呼び出しの後に同じサーバ信任状(正しい使用に必要であるように)、共有されたキー、および正当性間隔が正しく解読しなければならないAccept_象徴使用に呼ばれるなら。 ある他の文脈に呼ばれるなら、結果は未定義です。 正当性間隔はチェックされません。
3) Initialize all other entries in the cache to missing.
3) キャッシュにおける他のすべてのエントリーを取り逃がすのに初期化してください。
c) If there is a "local username on client node" in the cache and
it does not match the username supplied as a parameter, return
False.
c) キャッシュには「クライアントノードに関するローカルのユーザ名」があって、パラメタとして提供されたユーザ名を合わせないなら、Falseを返してください。
Kaufman [Page 73] RFC 1507 DASS September 1993
コーフマン[73ページ]RFC1507ダス1993年9月
d) If there is a "name of client node" in the cache and it
matches the nodename supplied as a parameter:
d) キャッシュには「クライアントノードの名前」があって、パラメタとして供給されたnodenameを合わせるなら:
1) Set the "Full name of the node" subfield of the remote node
authentication field of the accepted credentials to be the
nodename supplied as a parameter.
1) 受け入れられた信任状の遠隔ノード認証分野の「ノードのフルネーム」部分体にパラメタとして供給されたnodenameであるように設定してください。
2) Set the "Local Username on the node" subfield of the remote
node authentication field of the accepted credentials to be
the username supplied as a parameter.
2) 受け入れられた信任状の遠隔ノード認証分野の「ノードの上の地方のUsername」部分体にパラメタとして提供されたユーザ名であるように設定してください。
3) return True.
3) Trueを返してください。
e) Call the Get_Pub_Keys subroutine with the server_credentials,
the nodename supplied as a parameter, and Try_Hard=False.
e) サーバ_信任状、パラメタとして供給されたnodename、およびTry_Hard=があるGet_Pub_キーズサブルーチンが誤っていると言ってください。
f) If "Public Key of Client Node" is missing from the cache,
check all of the Public keys returned to see if one verifies
the node ticket. If one does, set the "Public Key of Client
Node" and "UID of Client Node" fields in the cache to be the
PK/UID pair that verified the ticket and set the "Local
Username on Client node" field to be the username supplied as
a parameter..
f) 「クライアントノードの公開鍵」がキャッシュからなくなるなら、キーが返したPublicのすべてをチェックして、人がノードチケットについて確かめるかどうか確認してください。 1がそうするなら、キャッシュにおける「クライアントノードの公開鍵」と「クライアントノードのUID」分野にチケットについて確かめたPK/UID組であり、「Clientノードの上の地方のUsername」分野にパラメタとして提供されたユーザ名であるように設定するように設定してください。
g) If any of the Public Key/UID pairs match the "Public Key of
Client Node" and "UID of Client Node" fields in the cache,
then:
g) Public Key/UIDのどれかが対にするなら、キャッシュにおける「クライアントノードの公開鍵」と「クライアントノードのUID」分野を合わせてください、そして:
1) Set the "name of client node" in the cache equal to the
nodename supplied as a parameter.
1) パラメタとして供給されたnodenameと等しいキャッシュにおける「クライアントノードの名前」を設定してください。
2) Set the "Full name of the node" subfield of the remote node
authentication field of the accepted credentials to be the
nodename supplied as a parameter.
2) 受け入れられた信任状の遠隔ノード認証分野の「ノードのフルネーム」部分体にパラメタとして供給されたnodenameであるように設定してください。
3) Set the "Local Username on the node" subfield of the remote
node authentication field of the accepted credentials to be
the username supplied as a parameter.
3) 受け入れられた信任状の遠隔ノード認証分野の「ノードの上の地方のUsername」部分体にパラメタとして提供されたユーザ名であるように設定してください。
4) Return True.
4) 本当に戻ってください。
h) If none of them match, call Get_Pub_Keys again with
Try_Hard=True and repeat steps 6 & 7. If Step 7 fails a
second time, return False.
h) それらのいずれも合っていないなら、Try_Hard=が本当の状態でもう一度Get_をPub_キーズと呼んでください、そして、ステップ6と7を繰り返してください。 Step7がもう一度失敗するなら、Falseを返してください。
Kaufman [Page 74] RFC 1507 DASS September 1993
コーフマン[74ページ]RFC1507ダス1993年9月
3.10.9 Verify Principal Name
3.10.9 主要な名前について確かめてください。
Verify_principal_name(
--inputs
principal_name Name,
--updated
verifier_credentials Credentials,
claimant_credentials Credentials,
--outputs
Name matches Boolean)
_校長_名前について確かめてください。(--入力_校長がName--アップデートされた検証_信任状Credentials、主張者_信任状Credentials--出力をNameマッチとブールで命名する)
This routine tests (in the context of the verifier credentials) whether the claimant credentials are authenticatable as being those of the named principal. This procedure is called with a set of accepted credentials to authenticate their source, or with a set of credentials produced by network_login to authenticate the creator of those credentials. If the claimant credentials were created by Accept_token, then the verifier credentials supplied in this call must be the same as those used in that call. The procedure for completing this request is as follows:
主張者信任状が命名された校長のものであるとして認証可能であるか否かに関係なく、このルーチンはテストされます(検証信任状の文脈で)。 この手順は、1セットの受け入れられた信任状で呼ばれて、彼らのソースを認証するか、またはそれらの信任状の創造者を認証するために1セットの信任状でネットワーク_ログインで作成されます。 主張者信任状がAccept_象徴によって作成されたなら、この呼び出しで供給された検証信任状はそれで使用されるものが呼ぶのと同じであるに違いありません。 この要求を終了するための手順は以下の通りです:
a) If there is no Login Ticket in the claimant credentials, then
return False.
a) 主張者信任状にLogin Ticketが全くなければ、Falseを返してください。
b) If the current time is not within the validity interval of the
Login Ticket, then return False.
b) 現在の時間がLogin Ticketの正当性間隔中にないなら、Falseを返してください。
c) If there is an Encrypted Shared Key present in the Claimant
information field of the claimant credentials, then find or
create a matching cache entry in the Cached Incoming Contexts
of the verifier credentials. In the description which
follows, references to "the cache" refer to this entry. If
the cache entry must be created, its contents is set to be as
follows:
c) 主張者信任状のClaimant情報フィールドの現在のEncrypted Shared Keyがあれば、検証信任状のCached Incoming Contextsで合っているキャッシュエントリーを見つけるか、または作成してください。 続く記述では、「キャッシュ」の参照はこのエントリーについて言及します。 キャッシュエントリーを作成しなければならないなら、コンテンツは以下の通りであるように設定されます:
1) Encrypted shared key from the encrypted shared key subfield
of the claimant information of the accepted credentials.
1) 受け入れられた信任状の主張者情報のコード化された共有された主要な部分体からのコード化された共有されたキー。
2) The shared key and validity interval are determined by
decrypting the encrypted shared key using the RSA private
key in the verifier information of the server credentials.
If this procedure is called after a call to Accept_token
using the same server credentials (as is required for
correct use), the shared key and validity interval must
correctly decrypt. If called in some other context, the
results are undefined. The validity interval is not
checked.
2) 共有されたキーと正当性間隔は、サーバ信任状の検証情報でRSA秘密鍵を使用しながら、コード化された共有されたキーを解読することによって、決定します。 この手順が呼び出しの後に同じサーバ信任状(正しい使用に必要であるように)、共有されたキー、および正当性間隔が正しく解読しなければならないAccept_象徴使用に呼ばれるなら。 ある他の文脈に呼ばれるなら、結果は未定義です。 正当性間隔はチェックされません。
Kaufman [Page 75] RFC 1507 DASS September 1993
コーフマン[75ページ]RFC1507ダス1993年9月
3) Initialize all other entries in the cache to missing.
3) キャッシュにおける他のすべてのエントリーを取り逃がすのに初期化してください。
d) If there is a cache entry and if the "Public Key of Client
Principal" field is present and if the "UID of Client
Principal" field is present and matches the UID in the Login
Ticket, then:
d) キャッシュエントリーがあって、「クライアント校長の公開鍵」分野が存在していて、「クライアント校長のUID」であるなら、分野は、存在していて、Login TicketでUIDに合っています、そして:
1) Set the Public Key of the principal field in the Claimant
information to be the Public Key of Client Principal.
1) Claimant情報の主要分野のPublic KeyにClientプリンシパルのPublic Keyであるように設定してください。
2) If the "Full name of the principal" field is missing from
the claimant information of the claimant credentials, then
set it to the "Name of Client Principal" field from the
cache.
2) 「校長のフルネーム」分野が主張者信任状の主張者情報からなくなるなら、キャッシュから「クライアント校長の名前」分野にそれを設定してください。
e) If there is a cache entry and if the "Name of Client
Principal" field is present and if it matches the principal
name supplied to this routine and if the UID in the cache
matches the UID in the Login Ticket, return True.
e) キャッシュエントリーがあって、「クライアント校長の名前」分野が存在していて、供給という主要な名前をこのルーチンに合わせて、キャッシュにおけるUIDがLogin TicketでUIDに合っているなら、Trueを返してください。
f) Call the Get_Pub_Keys subroutine with the name and verifier
credentials supplied to this routine and Try_Hard=FALSE.
Ignore any keys retrieved where the corresponding UID does not
match the UID in the claimant credentials.
f) Hard=FALSEにこのルーチンとTry_に名前と検証信任状を提供しているGet_Pub_キーズサブルーチンに電話をしてください。 対応するUIDが主張者信任状でUIDに合っていないところで検索されたあらゆるキーを無視してください。
g) If the Public Key of the principal is missing from the
claimant information of the claimant credentials, then attempt
to verify the signature on the login ticket with each public
key returned by Get_Pub_Keys. If verification succeeds:
g) 校長のPublic Keyが主張者信任状の主張者情報からなくなるなら、各公開鍵がGet_Pub_キーズによって返されているログインチケットの上に署名について確かめるのを試みてください。 検証が成功するなら:
1) Set the Public Key of the principal in the claimant
information of the claimant credentials to be the Public Key
that verified the ticket.
1) 主張者信任状の主張者情報の校長のPublic Keyにチケットについて確かめたPublic Keyであるように設定してください。
2) If the Full name of the principal in the claimant
information of the claimant credentials is missing, set it
to the name supplied to this routine.
2) 主張者信任状の主張者情報の校長のFull名がなくなるなら、このルーチンに提供された名前にそれを設定してください。
3) If there is a cache entry, set the Name of Client Principal
to be the name supplied to this routine, the UID of Client
Principal to be the UID from the Login Ticket, and the
Public Key of Client Principal to be the Public Key that
verified the ticket.
3) キャッシュエントリーがあれば、チケットについて確かめたPublic KeyになるようにClientプリンシパルのNameにこのルーチンに提供された名前と、Login TicketからのUIDであるClientプリンシパルのUIDと、ClientプリンシパルのPublic Keyであるように設定してください。
4) Return True.
4) 本当に戻ってください。
h) If the Public Key of the principal is present in the claimant
information of the claimant credentials, then see if it
h) 校長のPublic Keyが主張者信任状の主張者情報に存在しているなら、それであるなら見てください。
Kaufman [Page 76] RFC 1507 DASS September 1993
コーフマン[76ページ]RFC1507ダス1993年9月
matches any of the public keys returned by Get_Pub_Keys. If
one of them matches:
公開鍵のいずれもGet_Pub_キーズで返したマッチ。 彼らのひとりが合っているなら:
1) If the Full name of the principal in the claimant
information of the claimant credentials is missing, set it
to the name supplied to this routine.
1) 主張者信任状の主張者情報の校長のFull名がなくなるなら、このルーチンに提供された名前にそれを設定してください。
2) If there is a cache entry, set the Name of Client Principal
to be the name supplied to this routine, the UID of Client
Principal to be the UID from the Login Ticket, and the
Public Key of Client Principal to be the Public Key that
verified the ticket.
2) キャッシュエントリーがあれば、チケットについて確かめたPublic KeyになるようにClientプリンシパルのNameにこのルーチンに提供された名前と、Login TicketからのUIDであるClientプリンシパルのUIDと、ClientプリンシパルのPublic Keyであるように設定してください。
3) Return True.
3) 本当に戻ってください。
i) If steps 7 & 8 fail, retry the call to Get_Pub_Keys with
Try_Hard=TRUE, and retry steps 7 & 8. If they fail again,
return false.
i) ステップ7と8が失敗するなら、Try_Hard=TRUEと共にGet_Pub_キーズに呼び出しを再試行してください、そして、ステップ7と8を再試行してください。 再び失敗するなら、虚偽で戻ってください。
3.10.10 Get Pub Keys
3.10.10 パブキーを手に入れてください。
Get_Pub_Keys(
--inputs
TA_credentials Credentials
Try_Hard Boolean,
Target Name Name,
--outputs
Pub_keys Set of Public key/UID pairs
_Pub_キーズを手に入れてください、(--ブールでTA_信任状Credentials Try_Hardを入力する、Target Name Name、--Publicキー/UIDの出力Pub_キーSetが対にする
This common subroutine is used in the execution of Create_Token, Verify_Principal_Name, and Verify_Node_Name. Given the name of a principal, it retrieves a set of public key/UID pairs which authenticate that principal (normally only one pair). It does this by retrieving from the naming service a series of certificates, verifying the signatures on those certificates, and verifying that the sequence of certificates constitute a valid "treewalk".
この一般的なサブルーチンはCreate_Token、Verify_プリンシパル_Name、およびVerify_Node_Nameの実行に使用されます。 元本の名前を考えて、それはその校長を認証する1セットの公開鍵/UID組(通常1組だけ)を救済します。 それは命名サービスから一連の証明書を検索することによって、これをします、それらの証明書の上に署名について確かめて、証明書の系列が有効な"treewalk"を構成することを確かめて。
The credentials structure passed into this procedure represent a starting point for the treewalk. Included in these credentials will be the public key, UID, and name of an authority that is trusted to authenticate all remote principals (directly or indirectly).
構造がこの手順に通過した信任状はtreewalkのために出発点を表します。 これらの信任状に含まれているのは、すべてのリモート校長(直接か間接的に)を認証すると信じられる権威の公開鍵と、UIDと、名前になるでしょう。
The "Try_Hard" bit is a specification anomaly resulting from the fact that caches maintained by this routine are not transparent to the calling routines. It tells this procedure to bypass caches when doing all name service lookups because the information in caches is believed to be stale. In general, a routine will call Get_Pub_Keys with Try_Hard set false and try to use the keys returned. If use of
「_一生懸命試みてください」ビットはこのルーチンで維持されたキャッシュが呼出しルーチンに透明でないという事実から生じる仕様異常です。 それは、キャッシュにおける情報が聞き古したである信じられているのですべての名前サービスルックアップをするときにはキャッシュを迂回させるようにこの手順に言います。 一般に、ルーチンは、Try_Hardがあるキーズが設定するGet_Pub_が偽であると言って、キーが返した使用に試みるでしょう。 使用です。
Kaufman [Page 77] RFC 1507 DASS September 1993
コーフマン[77ページ]RFC1507ダス1993年9月
those keys fails, the calling routine may call this routine again with Try_Hard set true in hopes of getting additional keys. Routinely calling this routine with Try_Hard set true is likely to have adverse performance implications but would not affect the correctness or the security of the operation.
それらのキーは失敗して、呼出しルーチンは再び追加キーを手に入れるという望みが本当にはめ込まれたTry_Hardと共にこのルーチンを呼ぶかもしれません。 きまりきってHardが本当に設定するTry_とのこのルーチンを呼ぶ場合、不利な性能意味が持たれていそうですが、操作の正当性かセキュリティが影響されないでしょう。
The name supplied is the full X.500 name of the principal for whom public keys are needed as part of some authentication process.
供給という名前は公開鍵が何らかの認証過程の一部として必要である校長の完全なX.500名です。
This procedure securely learns the public keys and UIDs of foreign principals by constructing a valid chain of certificates between its trusted TA and the certificate naming the foreign principal. In the simplest case, where the TA has signed a certificate for the foreign principal, the chain consists of a single certificate. Otherwise, the chain must consist of a series of certificates where the first is signed by the TA, the last is a certificate for the foreign principal, and the subject of each principal in the chain is the issuer of the next. What follows is first a definition of what constitutes a valid chain of certificates followed by a model algorithm which constructs all of (and only) the valid chains which exist between the TA and the target name.
この手順は、外国人の校長を任命しながら信じられたTAと証明書の間で証明書の有効なチェーンを組み立てることによって、しっかりと外国人の校長の公開鍵とUIDsを学びます。 最も簡単な場合では、チェーンはただ一つの証明書から成ります。そこでは、TAが外国人の校長のために証明書にサインしました。 さもなければ、チェーンは1番目がTAによってサインされる一連の証明書から成らなければなりません、そして、最終は外国人の校長への証明書です、そして、チェーンにおける、それぞれの校長の対象は次の発行人です。 続くことは最初に、TAと目標名の間に存在する(単に)有効なチェーンを皆、作るモデルアルゴリズムがあとに続いた証明書の有効なチェーンを構成することに関する定義です。
In order to limit the implications of the compromise of a single CA, and also to limit the complexity of the search of the certificate space, there are restrictions on what constitutes a valid chain of certificates from the TA to the Name provided. The only CAs whose compromise should be able to compromise an authentication are those controlling directories that are ancestors of one of the two names and that are not above a common ancestor. Therefore, only certificates signed by those CAs will be considered valid in a certificate chain. Normally, the CA for a directory is expected to certify a public key and UID for the CA of each child directory and one parent directory. A CA may also certify another CA for some remote part of the naming hierarchy, and such certificates are necessary if there are no CAs assigned to directories high in the naming hierarchy.
単一のカリフォルニアの妥協の含意を制限して、また、証明書スペースの検索の複雑さを制限するために、何がTAから提供されたNameまで証明書の有効なチェーンを構成するかに関する制限があります。 妥協が認証で妥協できるべきである唯一のCAsが2つの名前の1つの先祖であり、一般的な先祖の上にないディレクトリを制御するものです。 それらのCAsによってサインされた証明書だけが証明書チェーンで有効であると考えられるでしょう。 通常、ディレクトリのためのカリフォルニアがそれぞれの子供ディレクトリと1つの親ディレクトリのカリフォルニアに公開鍵とUIDを公認すると予想されます。 また、カリフォルニアは命名階層構造の何らかのリモート部分に別のカリフォルニアを公認するかもしれません、そして、高い命名階層構造でディレクトリに割り当てられたCAsが全くなければ、そのような証明書が必要です。
A certificate chain is considered valid if it meets the following criteria:
以下の評価基準を満たすなら、証明書チェーンは有効であると考えられます:
a) It must consist of zero or more parent certificates, followed
by zero or one cross certificates, followed by zero or more
child certificates.
a) それがゼロから成らなければならない、さもなければ、より多くの親証明書がゼロか、より多くの子供証明書で従いました、続いて、ゼロか1通の交差している証明書に従います。
b) The number of parent certificates may not exceed the number of
levels in the naming hierarchy between the TA name and the
name of the least common ancestor in the naming hierarchy
between the TA name and the target name.
b) 親証明書の数はTA名と目標名の間の命名階層構造の最も一般的でない先祖のTA名と名前の間の命名階層構造のレベルの数を超えないかもしれません。
Kaufman [Page 78] RFC 1507 DASS September 1993
コーフマン[78ページ]RFC1507ダス1993年9月
c) Each parent certificate must be stored in the naming service
under the entry of its issuer.
c) 命名サービスに発行人のエントリーでそれぞれの親証明書を格納しなければなりません。
d) The subject of the cross certificate (if any) must be an
ancestor of the target name but must be a longer name than the
least common ancestor of the TA name and the target name.
d) 交差している証明書(もしあれば)の対象は、TA名の最も一般的でない先祖と目標名より長い目標名の先祖でなければなりませんが、名前であるに違いありません。
e) The cross certificate (if any) must have been stored in the
naming service under the entry of its issuer or there must
have been an indication in the naming service that
certificates signed by this issuer may be stored with their
subjects.
e) 交差している証明書(もしあれば)が命名サービスに発行人のエントリーで格納されたに違いありませんか、またはこの発行人によってサインされた証明書がそれらの対象で格納されるかもしれないという命名サービスにおける指示があったに違いありません。
f) The issuer of each parent certificate does not have stored
with it in the naming service a cross certificate with the
same issuer whose subject is an ancestor of the target name.
f) 証明書がするそれぞれの親の発行人は対象が目標名の先祖であるのと同じ発行人と共に命名サービスにそれで交差している証明書を格納していません。
g) Each child certificate must be stored in the naming service
under the entry of its subject.
g) 命名サービスに対象のエントリーでそれぞれの子供証明書を格納しなければなりません。
h) The subject of each child certificate does not have associated
with it in the naming service a cross certificate with the
same subject whose issuer is the same as the issuer of any of
the parent certificates or the cross certificate of the chain.
h) 証明書がするそれぞれの子供の対象は発行人が親証明書のどれかかチェーンの交差している証明書の発行人と同じであるのと同じ対象で命名サービスで交差している証明書をそれに関連づけていません。
i) The subject of each certificate must be the issuer of the
certificate that follows in the chain. The equality test can
be met by either of two methods:
i) それぞれの証明書の対象はチェーンで従う証明書の発行人であるに違いありません。 2つの方法のどちらかは平等テストを迎えることができます:
1) The public key of the subject in the earlier certificate
verifies the signature of the later and the subject UID in
the earlier certificate is equal to the issuer UID in the
later; or
1) 以前の証明書の対象の公開鍵は後の署名について確かめます、そして、以前の証明書の対象のUIDは後の発行人UIDと等しいです。 または
2) The public key of the subject in the earlier certificate
verifies the signature of the later, the earlier lacks a
subject UID and/or the later lacks an issuer UID and the
name of the subject in the earlier certificate is equal to
the name of the issuer in the later.
2) 以前の証明書の対象の公開鍵は後の署名について確かめます、そして、より早くに対象のUIDを欠いている、そして/または、発行人UIDが、より遅く、欠けて、以前の証明書の対象の名前は後の発行人の名前と等しいです。
j) The Public Key of the TA verifies the signature of the first
certificate.
j) TAのPublic Keyは最初の証明書の署名について確かめます。
k) The UID of the TA equals the UID of the issuer of the first
certificate or the UID is missing on one or both places and
the name of the TA equals the name of the issuer of the first
certificate.
k) TAのUIDが最初の証明書の発行人のUIDと等しいです、UIDが1でなくなるか、またはTAという両方の場所と名前は最初の証明書の発行人の名前と等しいです。
Kaufman [Page 79] RFC 1507 DASS September 1993
コーフマン[79ページ]RFC1507ダス1993年9月
l) All of the certificates are valid X.509 encodings and the
current time is within all of their validity intervals.
l) 証明書のすべてが有効なX.509 encodingsです、そして、彼らの正当性間隔のすべて中に現在の時間があります。
If a chain is valid, the name which it authenticates can be constructed as follows:
チェーンが有効であるなら、以下の通り、それが認証する名前を構成できます:
a) If the chain contains a cross certificate, the name
authenticated can be constructed by taking the subject name
from the cross certificate and appending to it a relative name
for each child certificate which follows. The relative name
is the extension by which the subject name in the child
certificate extends the issuer name.
a) チェーンが交差している証明書を含むなら、交差している証明書から対象の名前を取って、従うそれぞれの子供証明書のために相対的な名前をそれに追加することによって、認証という名前を構成できます。 相対的な名前は子供証明書の対象の名前が発行人名を広げる拡大です。
b) If the chain does not contain a cross certificate, the name
authenticated can be constructed by taking the TA name,
truncating from it the last n name components where n is the
number of parent certificates in the chain, and appending to
the result a relative name for each child certificate. The
relative name is the extension by which the subject name in
the child certificate extends the issuer name.
b) チェーンが交差している証明書を含まないなら、TA名を取ることによって、認証という名前を構成できます、チェーンでそれからのnが親証明書の数である最後のn名前コンポーネントに先端を切らせて、それぞれの子供証明書のために相対的な名前を結果に追加して。 相対的な名前は子供証明書の対象の名前が発行人名を広げる拡大です。
In the common case, the authenticated name will be the subject name in the last certificate. The authenticated name is constructed by the rules above to deal with namespace reorganization. If a branch of the namespace is renamed (due to, for example, a corporate acquisition or reorganization), only the certificates around the break point need to be regenerated. Certificates below the break will continue to contain the old names (until renewed), but the algorithms above assure the principals in that branch will be able to authenticate as their new names. Further, if the certificates at the branch point are maintained for both the old and new names for an interim period, principals in the moved branch will be able to authenticate as either their old or new names for that interim period without having duplicate certificates.
よくある例では、認証された名前は最後の証明書で対象の名前になるでしょう。 認証された名前は名前空間再編成に対処するためには上の規則で構成されます。 名前空間のブランチが改名されるなら(例えば、法人の獲得か再編成のため)、ブレークポイントの周りの証明書だけが、作り直される必要があります。 以下の中断がずっと含む老人が彼らの新しい名前として認証できるしかし、名前(更新されるまで)、上のアルゴリズムが、そのブランチの校長を保証する証明書。 有がなければ、ブランチポイントの証明書が暫時のための古くて新しい名前、動くブランチの校長がその暫時のための彼らの古いか新しい名前として認証できる両方のために維持されるなら、さらに、証明書をコピーしてください。
A final complication that the algorithm must deal with is the location of cross certificates. If a key is compromised or for some other reason it is important to revoke a certificate ahead of its expiration, it is removed from the naming service. This algorithm will only use certificates that it has recently retrieved from the naming service, so revocation is as effective as the mechanisms that prevent impersonation of the naming service. There are plans to eventually use DASS mechanisms to secure access to the naming service; until they are in place, name service impersonation is a theoretical threat to the security of revocation. Opinions differ as to whether it is a practical threat. Child certificates are always stored with the
アルゴリズムが対処しなければならない最終的な複雑さは交差している証明書の位置です。 キーが妥協するか、満了の前に証明書を取り消すのが重要であるある他の理由であるなら、命名サービスからそれを取り除きます。 このアルゴリズムがそれが最近命名サービスから検索した証明書を使用するだけであるので、取消しは命名サービスのものまねを防ぐメカニズムと同じくらい有効です。 結局命名サービスへのアクセスを保証するのにダスメカニズムを使用する計画があります。 彼らが適所にいるまで、名前サービスものまねは取消しのセキュリティへの理論上の脅威です。 意見はそれが実用的な脅威であるかどうかに関して異なります。 子供証明書はいつも格納されます。
Kaufman [Page 80] RFC 1507 DASS September 1993
コーフマン[80ページ]RFC1507ダス1993年9月
subject and will not be found unless stored in the name server of the subject. Parent certificates are always stored with the issuer and will not be found unless stored in the name server of the issuer. For best security, cross certificates should be stored with the issuer because the name server for the subject may not be adequately trustworthy to perform revocation. There are performance and availability penalties, however, in doing so. The architecture and the algorithm therefore support storing cross certificates with either the issuer or the subject. There must be some sort of flag in the name service associated with the issuer saying whether cross certificates from that issuer are permitted to be stored in the subject's name service entry, and if that flag is set such certificates will be found and used.
対象のネームサーバに格納されない場合備え付けないためにかけて、望んでください。 親証明書は、発行人と共にいつも格納されて、発行人のネームサーバに格納されないと、見つけられないでしょう。 最も良いセキュリティのために、対象のためのネームサーバが取消しを実行するために適切に信頼できないかもしれないので、交差している証明書は発行人と共に格納されるべきです。 しかしながら、そうするのにおいて性能と有用性刑罰があります。 したがって、構造とアルゴリズムは、発行人か対象のどちらかで交差している証明書を格納するのを支持します。 対象の名前サービスエントリーにその発行人からの交差している証明書が格納されることが許可されているか否かに関係なく、発行人ことわざに関連している名前サービスにはある種の旗があるに違いなくて、その旗が設定されると、そのような証明書は、見つけられて、使用されるでしょう。
In order to make revocation effective, DASS must assure that naming service caches do not become arbitrarily stale (the allowed age of a cache entry is included in the sum of times with together make up the revocation time). If DASS uses a naming service such as DNS that does not time out cache entries, it must bypass cache on all calls and (to achieve reasonable performance) maintain its own naming service cache. It may be advantageous to maintain a cache in any case so the that the fact that the certificates have been verified can be cached as well as the fact that they are current.
取消しを有効にするように、ダスは、命名サービスキャッシュが任意に聞き古したであるならないことを(キャッシュエントリーの時代が含まれている一緒にいるのがある回の合計が取消し時間にする許容)保証しなければなりません。 ダスがキャッシュエントリーをタイムアウトでないのにするDNSなどの命名サービスを利用するなら、それは、すべての呼び出しのときにキャッシュを迂回させて、それ自身の命名サービスキャッシュを維持しなければなりません(妥当な性能を達成する)。 どのような場合でも、aがそうをキャッシュすると主張するのが有利であるかもしれない、それらがよく見られるという事実と同様に証明書が確かめられたという事実をキャッシュできます。
3.10.10.1 Basic Algorithm
3.10.10.1 基本的なアルゴリズム
For ease of exposition, this first description will ignore the operation of any caches. Permissible modifications to take advantage of caches and enhance performance will be covered in the next section. This path will be followed if the Try_Hard bit is set True on the call.
博覧会の容易さのために、この最初の記述はどんなキャッシュの操作も無視するでしょう。 キャッシュを利用して、性能を高める許されている変更は次のセクションでカバーされているでしょう。 この経路はTry_Hardビットが呼び出しでのセットTrueであるなら続かれるでしょう。
Rather than trying construct all possible chains between the TA and the name to be authenticated (in the event of multiple certificates per principal, there could be exponentially many valid chains), this algorithm computes a set of PK/UID/Name triples that are valid for each principal on the path between the TA and the name to be authenticated. By doing so, it minimizes the processing of redundant information.
むしろ、このアルゴリズムはすべて可能な骨の折れる構造物が認証される(複数の1校長あたりの証明書の場合、指数関数的に多くの有効なチェーンがあるかもしれない)ためにTAと名前の間でチェーニングするより1セットのTAと名前の間の経路の各校長が認証されるために有効なPK/UID/名前三重を計算します。 そうすることによって、それは余分な情報の処理を最小にします。
a) Determining path and initialization
a) 経路と初期化を決定します。
Several state variables are manipulated during the tree walk.
These are called:
いくつかの州の変数が木の散歩の間、操られます。 これらは呼ばれます:
Kaufman [Page 81] RFC 1507 DASS September 1993
コーフマン[81ページ]RFC1507ダス1993年9月
1) Current-directory-name
This is the name indicating the current place in the tree
walk. Initially, this is the name of the TA.
1) 現在のディレクトリ名Thisは木の散歩における現在の場所を示す名前です。 初めは、これはTAという名前です。
2) Least-Common-Ancestor-Name
This is the portion of the names which is common to both the
CA and the Target. This is computed at initialization and
does not change during the treewalk.
2) 最も一般的でない先祖名のThisは名前のカリフォルニアとTargetの両方に共通の部分です。 これは、初期化で計算されて、treewalkの間、変化しません。
3) Trusted-Key-Set
For each name which is an ancestor of either the TA or the
Target but not of the Least-Common-Ancestor, a list of
PK/UID/Name triples. This is initialized to a single triple
from the TA information in the supplied credentials.
3) 信じられた主要なセットForはそれぞれどれがTAの先祖であるか、そして、Targetを命名しますが、Leastの一般的な先祖について命名するというわけではありません、PK/UID/名前三重のリスト。 これは供給された信任状のTA情報からシングルに3倍初期化されます。
4) Search-when-descending
This is a list of PK/UID/Name triples of issuers that will
be trusted when descending the tree. This set is initially
empty.
4) 下るときの検索Thisは木を滑降させるとき信じられる発行人のPK/UID/名前三重のリストです。 このセットは初めは、空です。
5) Saved-RDNs
This is a sequence of Relative Distinguished Names (RDNs)
stripped off the right of the target name to form
Least-common-ancestor-name. This "stack" is initially empty
and is populated during Step 3.
5) 救われたRDNs Thisは目標名がLeastの一般的な先祖名を形成する権利で剥取られたRelative Distinguished Names(RDNs)の系列です。 この「スタック」は、初めは、空であり、Step3の間、居住されます。
b) Ascending the "TA side" of the tree
b) 木の「TA側」を昇ります。
While Current-directory-name is not identical to
Common-point-Name the algorithm moves up the tree. At each
step it does the following operations.
Current-ディレクトリ名はCommonポイント名と同じではありませんが、アルゴリズムは木を上げます。 各ステップでは、それは以下の操作をします。
1) Find all cross certificates stored in the naming service
under Current-directory-name in which the subject is an
ancestor of the principal to be authenticated or an
indication that cross certificates from this issuer are
stored in the subject entry. If there is an indication that
such certificates are stored in the subject entry, copy all
triples in Trusted-Key-Set for Current-directory-name into
the "Search-when-descending" list. If any such certificates
are found, filter them to include only those which meet the
following criteria:
1) 認証されるために対象が校長の先祖であるCurrent-ディレクトリ名の下における命名サービスに格納された証明書かこの発行人からの交差している証明書が対象のエントリーに格納されるという指示をすべての十字に見つけてください。 そのような証明書が対象のエントリーに格納されるという指示があれば、Current-ディレクトリ名のために「下るときの検索」リストの中にTrustedの主要なセットにおけるすべての三重をコピーしてください。 何かそのような証明書が見つけられるなら、それらをフィルターにかけて、以下の評価基準を満たすものだけを含んでください:
(i) For some triple in the Trusted-Key-Set corresponding to
the Current-directory-name, the public key in the triple
verifies the signature on the certificate and either the
UID in the triple matches the issuer UID in the
certificate or the UID in the triple and/or the
そして/または(i) Current-ディレクトリ名に対応するTrusted主要なセットにおける何らかの三重のために、三重における公開鍵が証明書の上に署名について確かめて、三重におけるUIDが三重における証明書かUIDで発行人UIDを合わせる。
Kaufman [Page 82] RFC 1507 DASS September 1993
コーフマン[82ページ]RFC1507ダス1993年9月
certificate is missing and the name in the triple matches
the issuer name in the certificate.
証明書はなくなります、そして、三重における名前は証明書の発行人名に合っています。
(ii) No certificates were found signed by this issuer in which
the subject name is longer than the subject name in this
certificate (i.e., if there are cross certificates to two
different ancestors, accept only those which lead to the
closest ancestor).
(ii)は対象の名前より長い間対象の名前がこの証明書にあるこの発行人でサインしました(すなわち、2人の異なった先祖への交差している証明書があれば、最も近い先祖に通じるものだけを受け入れてください)証明書が全く見つけられなかった。
(iii)The current time is within the validity interval of the
certificate.
(iii) 証明書の正当性間隔中に、現在の時間があります。
2) If any cross certificates were found (whether or not they
were all eliminated as part of the filtering process), set
Current-directory-name to the longest name that was found in
any certificate and construct a set of PK/UID/Name triples
for that name from the certificates which pass the filter
and place them in the Trusted Key Set associated with their
subject. Exit the ascending tree loop at this point and
proceed directly to step 3. Note that this means that if
there are cross certificates to an ancestor of the target
but they are all rejected (for example if they have
expired), the treewalk will not construct a chain through
the least common ancestor and will ultimately fail unless a
crosslink from a lower ancestor is found stored with its
subject. This is a security feature.
2) どれか交差している証明書が当たられて(それらがろ過過程の一部としてすべて排除されたか否かに関係なく)、どんな証明書でも見つけられた中で最も長い名前にCurrent-ディレクトリ名を設定して、PK/UID/名前の1セットを構成するなら、フィルタを渡して、それらをTrusted Key Setに置く証明書からのその名前のための三重はそれらの対象と交際しました。 ここに昇っている木の輪を出てください、そして、直接ステップ3に進んでください。 これがtreewalkが最も一般的でない先祖を通してチェーンを組み立てないで、目標の先祖への交差している証明書がありますが、それらがすべて拒絶されて(例えば、期限が切れたなら)、下側の先祖からのクロスリンクが対象で格納されているのがわからないと結局失敗することを意味することに注意してください。 これはセキュリティ機能です。
3) If no cross certificates are found, find all the parent
directory certificates for the directory whose name is in
the Current-directory-name. Filter these to find only those
which meet the following criteria:
3) どんな交差している証明書も見つけられないなら、名前がCurrent-ディレクトリ名にあるディレクトリのためのすべての親ディレクトリ証明書を見つけてください。 これらをフィルターにかけて、以下の評価基準を満たすものだけを見つけてください:
(i) The current time is within the validity interval.
(i) 正当性間隔中に、現在の時間があります。
(ii) For some triple corresponding to the
Current-directory-name, the public key in the triple
verifies the signature on the certificate and either the
UID in the triple matches the issuer UID in the
certificate or the UID in the triple and/or the
certificate is missing and the name in the triple matches
the issuer name in the certificate.
3倍Current-ディレクトリ名に対応するいくつかのための(ii)、三重における公開鍵は証明書の上に署名について確かめます、そして、三重、そして/または、証明書のUIDはなくなります、そして、三重におけるUIDは証明書で発行人UIDに合っているか、または三重における名前が証明書の発行人名に合っています。
4) Construct PK/UID/Name triples from the remaining
certificates for the directory whose name is constructed by
stripping the rightmost simple name from the
Current-directory-name and place them in the Trusted-Key-Set.
4) 名前がCurrent-ディレクトリ名から一番右の単純名を剥取ることによって構成されるディレクトリのための残っている証明書からPK/UID/名前三重を構成してください、そして、Trustedの主要なセットにそれらを置いてください。
Kaufman [Page 83] RFC 1507 DASS September 1993
コーフマン[83ページ]RFC1507ダス1993年9月
5) Strip the rightmost simple name of the
Current-directory-name.
5) Current-ディレクトリ名を一番右の単純名から奪い取ってください。
6) Repeat from step (a) (testing to see if
current-directory-name is the same as Common-point-Name).
6) ステップ(a)から、繰り返してください。 (Commonが名前を指すとき現在のディレクトリ名が同じであるかどうか確認するために、テストします。)
c) Searching the "target side" of the tree for a crosslink:
c) クロスリンクのために木の「目標側」を捜します:
1) Initialization: set Current-directory-name to the name
supplied as input to this procedure.
1) 初期設定: この手順に入力されるようにCurrent-ディレクトリ名を供給という名前に設定してください。
2) Retrieve from the naming service all cross certificates
associated with Current-directory-name. Filter to only
those that meet the following criteria:
2) 命名サービスから、Current-ディレクトリ名に関連しているすべての交差している証明書を検索してください。 以下の評価基準を満たすものだけに以下をフィルターにかけてください。
(i) The current time is within their validity interval.
(i) 彼らの正当性間隔中に、現在の時間があります。
(ii) The subject name is equal to Current-directory-name.
(ii) 対象の名前はCurrent-ディレクトリ名と等しいです。
(iii)For some PK/UID/Name triple in the
"Search-when-descending" list compiled while ascending
the tree, the Public Key verifies the signature on the
certificate and either the UID matches the issuer UID in
the certificate or a UID is missing from the triple
and/or the certificate and the Name in the triple matches
the issuer name in the certificate.
木を昇っている間にコンパイルされた「下るときの検索」リストの何らかのPK/UID/名前三重のための(iii)、Public Keyは証明書の上に署名について確かめます、そして、UIDは三重、そして/または、証明書からなくなります、そして、UIDは証明書で発行人UIDに合っているか、または三重におけるNameが証明書の発行人名に合っています。
(iv) There are no certificates found meeting criteria (ii) and
(iii) matching a PK/UID/Name triple in the
Search-when-descending list whose subject is a directory
lower in the naming hierarchy.
(iv) 3倍PK/UID/名前に合っている評価基準(ii)を満たしているのは見つけられなかった証明書と全く(iii)が対象がディレクトリである下るときの検索リストで命名階層構造で、より低くあります。
3) If any qualifying certificates are found, construct
PK/UID/Name triples for each of them; these should replace
rather than supplement any triples already in the
Trusted-key-set for that directory.
3) 何か資格を得る証明書が見つけられるなら、構造物PK/UID/名はそれぞれのそれらのために3倍になります。 これらはそのディレクトリのために補うよりむしろ既にTrustedの主要なセットにおけるどんな三重も取り替えるべきです。
4) If after steps (b) and (c), there are no PK/UID/Name triples
corresponding to Current-directory-name in Trusted-Key-Set,
shorten Current-directory-name by one RDN (pushing it onto
the Saved-RDNs stack) and repeat this process until
Current-directory-name is equal to
Least-common-ancestor-name or there is at least one triple
in Trusted-key-set corresponding to Current-directory-name.
4) Trustedの主要なセットでCurrent-ディレクトリ名に対応するどんなPK/UID/名前三重もステップ(b)と(c)後になければ、1RDNでCurrent-ディレクトリ名を短くしてください、そして、(Saved-RDNsスタックにそれを押して)Current-ディレクトリ名がLeastの一般的な先祖名と等しいか、またはCurrent-ディレクトリ名へのTrustedの主要なセット対応における少なくとも1つの三重があるまで、この過程を繰り返してください。
d) Descending the tree
d) 木を滑降させます。
While the list Saved-RDNs is not Empty the algorithm moves
リストSaved-RDNsはアルゴリズムが動かすEmptyではありませんが
Kaufman [Page 84] RFC 1507 DASS September 1993
コーフマン[84ページ]RFC1507ダス1993年9月
down the tree. At each step it does the following operations.
木の下側に。 各ステップでは、それは以下の操作をします。
1) Remove the first RDN from Saved-RDNs and append it to the
Current-directory-name.
1) Saved-RDNsから最初のRDNを取り外してください、そして、Current-ディレクトリ名にそれを追加してください。
2) Find all the child directory certificates for the directory
whose name is in the current-directory-name.
2) 名前が現在のディレクトリ名にあるディレクトリのためのすべての子供ディレクトリ証明書を見つけてください。
3) Filter these certificates to find only those which meet the
following criteria:
3) これらの証明書をフィルターにかけて、以下の評価基準を満たすものだけを見つけてください:
(i) The current time is within the validity interval.
(i) 正当性間隔中に、現在の時間があります。
(ii) For some PK/UID/Name triple in the Current-key-set for
the parent directory, the Public Key verifies the
signature on the certificate and either the UID matches
the issuer UID of the certificate or the UID is missing
from the triple and/or the certificate and the Name in
the triple matches the issuer name in the certificate.
親ディレクトリのためのCurrentの主要なセットにおける何らかのPK/UID/名前三重のための(ii)、Public Keyは証明書の上に署名について確かめます、そして、UIDは三重、そして/または、証明書からなくなります、そして、UIDは証明書の発行人UIDに合っているか、または三重におけるNameが証明書の発行人名に合っています。
(iii)The issuer name in the certificate is a prefix of the
subject name and the difference between the two names is
the final RDN of Current-directory-name.
(iii) 証明書の発行人名は対象の名前の接頭語であり、2つの名前の違いはCurrent-ディレクトリ名の最終的なRDNです。
4) Take the key, UID, and name from each remaining certificate
and form a new triple corresponding to
Current-directory-name in Trusted-Key-Set. If this set is
empty then the algorithm exits with the
'Incomplete-chain-of-trustworthy-CAs' error condition.
4) それぞれの残っている証明書からキー、UID、および名前を取ってください、そして、Trustedの主要なセットでCurrent-ディレクトリ名に対応する新しい三重を形成してください。 このセットが空であるなら、アルゴリズムは'信頼できるCAsの不完全なチェーン'エラー条件と共に出ます。
5) repeat from step (a), appending a new simple name to
Current-directory-name.
5) ステップ(a)から、Current-ディレクトリ名に新しい単純名を追加して、繰り返してください。
e) Find public keys:
If there are no triples in the Trusted-Key-Set for the named
principal, then the algorithm exits with the `Target-has-no-keys-w
error condition. Otherwise, the Public Key and UID are
extracted from each pair, duplicates are eliminated, and this
set is returned as the Pub_keys.
e) 公開鍵を見つけてください: Trustedの命名された校長にとって、主要なセットに三重が全くなければ、アルゴリズムは'目標にはキーwが全くないエラー条件'と共に出ます。 さもなければ、各組からPublic KeyとUIDを抽出します、そして、写しを排除します、そして、Pub_キーとしてこのセットを返します。
3.10.10.2 Allowed Variations - Caching
3.10.10.2 変化--キャッシュは許されました。
Some use of caches can be implemented without affecting the semantics of the Get_Pub_Keys routine. For example, a crypto-cache could remember the public key that verified a signature in the past and could avoid the verification operation if the same key was used to verify the same data structure again. In some cases, however, it is impossible (or at least inconvenient) for a cache implementation to
Get_Pub_キーズのルーチンの意味論に影響しないで、キャッシュの何らかの使用を実行できます。 例えば、暗号キャッシュは、過去に署名について確かめた公開鍵を覚えていることができて、同じキーが再び同じデータ構造について確かめるのに使用されるなら、検証操作を避けるかもしれないでしょうに。 いくつかの場合、aが実現をキャッシュするので、しかしながら、それは、不可能、そして、(少なくとも不便)です。
Kaufman [Page 85] RFC 1507 DASS September 1993
コーフマン[85ページ]RFC1507ダス1993年9月
be completely transparent.
完全に透明であってください。
In particular, for good performance it is important that certificates not be re-retrieved from the naming service on every authentication. This must be balanced against the need to have changes to the contents of the naming service be reflected in DASS calls on a timely basis. There are two cases of interest: changes which cause an authentication which previously would have succeeded to fail and changes which cause an authentication which previously would have failed to succeed. These two cases are subject to different time constraints.
望ましい市場成果に、証明書があらゆる認証のときに命名サービスから再検索されるというわけではないのは、特に、重要です。 これはタイムリーベースで命名サービスのコンテンツへの変化をダスの呼び出しに反映させる必要性に対してバランスをとらなければなりません。 興味がある2つのケースがあります: 以前に成功した認証が失敗される変化と以前に成功していない認証を引き起こす変化。 これらの2つのケースが異なった時間規制を受けることがあります。
In general, changes that cause authentication to succeed must be reflected quite quickly - on the order of minutes. If a user attempts an operation, it fails, the user tracks down a system manager and causes the appropriate updates to take place, and the user retries the operation, it is unacceptable for the operation to continue to fail for an extended period because of stale caches.
一般に、数分の注文ときに全くすぐに認証が成功する変化を反映しなければなりません。 ユーザが操作を試みて、失敗して、ユーザがシステム・マネージャを捜し出して、適切なアップデートを行われさせて、ユーザが操作を再試行するなら、操作が、聞き古したキャッシュで長期間の間、失敗し続けているのは、容認できません。
Changes that cause authentication to fail must be reflected reliably within a bounded period of time for security reasons. If a user leaves the company, it must be possible to revoke his ability to authenticate within a relatively short period of time - say hours.
境界がある期間以内に安全保障上の理由で認証が失敗される変化を確かに反映しなければなりません。 ユーザが退職するなら、比較的短い期間以内に認証する彼の能力を取り消すのは可能であるに違いありません--時間、言ってください。
These constraints mean that a naming service cache which contains arbitrarily old information is unacceptable. To meet the second constraint, naming service cache entries must be timed out within a reasonable period of time unless in implementation verifies that the certificate is still present (a crypto-cache which lasted longer would be legal; rather than deleting a name service cache entry, in implementation might instead verify that the entry was still present in the naming service. This would avoid repeating the cryptographic "verify").
これらの規制は、任意に古い情報を含む命名サービスキャッシュが容認できないことを意味します。 2番目の規制を満たすために、中ではなく適正な期間以内にエントリーを調節しなければならないサービスキャッシュを実現と命名するのは、証明書がまだ存在していることを確かめます。(より長い間続いた暗号キャッシュは法的でしょう。 名前を削除するとキャッシュエントリーが修理されるむしろ実現では、代わりにエントリーが命名サービスでまだ存在していたことを確かめるかもしれません。 これは、暗号の「検証」を繰り返すのを避けるでしょう。).
In order to assure that information cached for even a few hours not deny authentication for that extended period, it must be possible to bypass caches when the result would otherwise be a failure. Since the performance of authentication failures is not a serious concern, it is acceptable to expect that before an operation fails a retry will be made to the naming service to see if there are any new relevant certificates (or in certain obscure conditions, to see if any relevant certificates have been deleted).
そうでなければ、結果が失敗であるだろうというときに、数時間さえキャッシュされた情報がその長期間の間認証を否定しないことを保証するために、キャッシュを迂回させるのは可能でなければなりません。 認証失敗の性能が真剣な関心でないので、操作が再試行に失敗する前に何か新しい関連証明書があるかどうかを(ある、状態をあいまいにして、何か関連証明書が削除されたかどうかを見てください)見るのをそれを命名サービスにすると予想するのは許容できます。
If on a call to Get_Pub_Keys, the Try_Hard bit is True, then this procedure must return results based on the contents of the naming service no more than five minutes previous (this would normally be accomplished by ignoring name service caches and making all operations directly to the naming service). If the Try_Hard bit is
Get_Pub_キーズへの呼び出しのときにTry_HardビットがTrueであるなら、この手順は5分間未満命名サービスのコンテンツに前であることの状態で基づく結果を返さなければなりません(通常、これは名前サービスキャッシュを無視して、すべての操作を直接命名サービスにすることによって、達成されるでしょう)。 Try_Hardビットがそうなら
Kaufman [Page 86] RFC 1507 DASS September 1993
コーフマン[86ページ]RFC1507ダス1993年9月
False, this procedure may return results based on the contents of the naming service any time in the previous few hours, in the sense that it may ignore any certificate added in the previous few hours and may use any certificate deleted in the previous few hours. Procedures which call this routine with Try_Hard set to false must be prepared to call it again with Try_Hard True if their operation fails possibly from this result.
虚偽で、この手順は前の数時間でいつでも命名サービスのコンテンツに基づく結果を返すかもしれません、前の数時間で加えられたどんな証明書も無視して、前の数時間で削除されたどんな証明書も使用するかもしれないという意味で。 彼らの操作がことによるとこの結果から失敗するなら、Try_Hard Trueと共にそれにもう一度電話をするようにHardが誤っているのに設定するTry_とのこのルーチンを呼ぶ手順を準備しなければなりません。
The exact timer values for "five minutes" and "a few hours" are expected to be implementation constants.
「5分」と「数時間」の間の正確なタイマ値は実現定数であると予想されます。
In the envisioned implementation, the entire "ascending treewalk" is retrieved, verified, and its digested contents cached when a principal first establishes credentials. A mechanism should be provided to refresh this information periodically for principals whose sessions might be long lived, but it would probably be acceptable in the unlikely event of a user's ancestor's keys changing to require that the user log out and log back in. This is consistent with the observed behavior of existing security mechanisms.
思い描かれた実現では、全体の「上昇treewalk」は、検索されて、確かめられます、そして、元本であるときにキャッシュされた読みこなされたコンテンツは最初に、信任状を確立します。 メカニズムはセッションが長さが生きましたが、それがたぶんユーザの先祖のもののありそうもない出来事で許容できるだろうということであるかもしれない校長のために定期的にこの情報をリフレッシュするのが必要とするユーザが登録する変化を合わせるならアウトとログがコネを支持するということであるべきです。 これは既存のセキュリティー対策の観測された振舞いと一致しています。
The descending treewalk, on the other hand, is expected to be maintained as a more conventional cache, where entries are kept in a fixed amount of memory with a "least recently used" replacement policy and a watchdog timer that assures that stale information is not kept indefinitely. A call to Get_Pub_Keys with Try_Hard set false would first check that cache for relevant certificates and only if none were found there would it go out to the naming service. If there were newer certificates in the naming service, they might not be found and an authentication might therefore fail.
他方では、より従来のキャッシュとして下っているtreewalkが維持されると予想されます、エントリーが固定メモリー容量で「最も最近でない、中古」の交換方針で保たれて、その聞き古した情報を保証するウオッチドッグタイマーは無期限に保たれないところで。 Try_Hardがあるキーズが虚偽で設定するGet_Pub_への呼び出しは最初に関連証明書がないかどうかそのキャッシュをチェックするでしょう、そして、なにもそこで見つけられない場合にだけ、それは命名サービスに出かけるでしょうか? 命名サービスにより新しい証明書があれば、それらは見つけられないでしょうに、そして、したがって、認証は失敗するかもしれません。
When Try_Hard is false, an implementation may assume that certificates not in the cache do not exist so long as that assumption does not cause an authentication to falsely succeed. In that case, it may only make that assumption if the certificates have been verified to not exist within the revocation time (a few hours).
Try_Hardが偽であるときに、実現は、認証がその仮定で間違って成功しない限り、証明書がキャッシュで存在すると仮定するかもしれません。 その場合、それは証明書が取消し時間(数時間)中に存在しないように確かめられた場合にだけそれを仮定にするかもしれません。
3.11 DASSlessness Determination Functions
3.11に、DASSlessness決断は機能します。
In order to provide better interoperability with alternative authentication mechanisms and to provide backward compatibility with older (insecure) authentication mechanisms, it is sometimes important to be able to determine in a secure way what the appropriate authentication mechanism is for a particular named principal. For some applications, this will be done by a local mechanism, where either the person creating access control information must know and specify the mechanism for each principal or a system administrator on the node must maintain a database mapping names to mechanisms. Three applications come to mind where scaleability makes such mechanisms
代替の認証機構をより良い相互運用性に提供して、より古い(不安定な)認証機構を後方の互換性に提供するために、適切な認証機構が特定の命名された元本のための何であるかを安全な方法で決定できるのは時々重要です。 いくつかのアプリケーションにおいて、局所機構はこれをするでしょう。(そこでは、アクセス制御情報を作成する人が、各校長にメカニズムを知って、指定しなければなりませんか、またはノードの上のシステム管理者は名前をメカニズムに写像するデータベースを維持しなければなりません)。3つのアプリケーションがscaleabilityがそのようなメカニズムを作るところで気にするようになります。
Kaufman [Page 87] RFC 1507 DASS September 1993
コーフマン[87ページ]RFC1507ダス1993年9月
implausible:
信じがたい:
a) To transparently secure proxy-based applications (like rlogin)
in an environment where some hosts have been upgraded to
support DASS and some have not, a node must be willing to
accept connections authenticated only by their network
addresses but only if they can be assured that such nodes do
not have DASS installed. Access to a resource becomes secure
without administrative action when all nodes authorized to
access it have been upgraded.
a) 環境における何人かのホストがダスをサポートするためにアップグレードして、何かがアップグレードしていなかった透過的に安全なプロキシベースのアプリケーション(rloginのような)と、ノードは、彼らのネットワーク・アドレスにもかかわらず、そのようなノードでダスをインストールしないことをそれらを保証できるだけであるかどうかによって認証された接続を受け入れても構わないと思っているに違いありません。 それにアクセスするのが認可されたすべてのノードがアップグレードしたとき、リソースへのアクセスは管理動作なしで安全になります。
In this scenario, the server node must be able to determine
whether the client node is DASSless in a secure fashion.
このシナリオでは、サーバノードは、安全なファッションでクライアントノードがDASSlessであるかどうか決定できなければなりません。
b) Similarly, in a mixed environment where some servers are
running DASS and some are not, it may be desirable for clients
to authenticate servers if they can but it would be
unacceptable for a client to stop being able to access a
DASSless server once DASS is installed on the client. In such
a situation where server authentication is desirable but not
essential, the client would like to determine in a secure
fashion whether the server can accept DASS authentication.
b) そうすることができるならいくつかのサーバが実行しているダスであり、何かがそのようなダスでない複雑な環境で、同様に、クライアントがサーバを認証するのが、望ましいかもしれませんが、クライアントが、ダスがいったんクライアントの上にインストールされるとDASSlessサーバにアクセスできるのを止めるのは、容認できないでしょう。 サーバ証明が望ましいのですが、不可欠でないそのような状況で、クライアントは、サーバがダスの認証を受け入れることができるかどうかと安全なファッションで決心したがっています。
c) In a DASS/Kerberos interoperability scenario, a server may
decide that Kerberos authentication is "good enough" for
principals that do not have DASS credentials without
introducing trust in on-line authorities when DASS credentials
are available. In parallel with case 1, we want it to be true
that when the last principal with authority to access an
object is upgraded to DASS, we automatically cease to trust
PasswdEtc servers without administrative action on the part of
the object owner. For this purpose, the authenticator must
learn in a secure fashion that the principal is incapable of
DASS authentication.
c) ダス/ケルベロス相互運用性シナリオでは、サーバは、ダス資格証明書が利用可能であるときにオンライン当局で信頼を導入しないでダス資格証明書を持っていない校長にとって、ケルベロス認証が「十分良い」と決めるかもしれません。 ケース1と平行して、私たちは、オブジェクトにアクセスする権威がある最後の主体であるときに、本当に、それがダスにアップグレードするということであって欲しいと思って、オブジェクト所有者側の管理動作なしでPasswdEtcサーバを信じるのを自動的にやめます。 このために、固有識別文字は、主体がダスの認証で不可能であることを安全なファッションで学ばなければなりません。
Reliably determining DASSlessness is optional for implementations of DASS and for applications. No other capabilities of DASS rely on this one.
ダスの実装とアプリケーションに、DASSlessnessを確かに決定するのは任意です。 ダスの他のどんな能力もこれを当てにしません。
The interface to the DASSlessness inquiry function is specified as a call independent of all others. This capability must be exposed to the calling application so that a server that receives a request and no token can ask whether the named principal should be believed without a token. It might improve performance and usability if in real interfaces DASSlessness were returned in addition to a bad status on the function that creates a token if the token is targeted toward a server incapable or processing it. An application could then decide whether to make the request without a token (and give up
DASSlessness問い合せ機能へのインタフェースはすべての他のものの如何にかかわらず呼び出しとして指定されます。 要求を受けますが、何かトークンは受けないサーバが、命名された主体がトークンなしで信じられるべきであるかどうか尋ねることができるように、呼ぶアプリケーションにこの能力を暴露しなければなりません。 本当のインタフェースでトークンがサーバに向かって不可能な状態で狙うか、またはそれを処理しているならトークンを作成する機能の悪い状態に加えてDASSlessnessを返すなら、それは性能とユーザビリティを向上させるでしょうに。 次に、アプリケーションが、トークンなしで要求をするかどうか決めるかもしれない、(あきらめてください。
Kaufman [Page 88] RFC 1507 DASS September 1993
コーフマン[88ページ]RFC1507ダス1993年9月
server authentication) or to abort the request.
サーバ証明、)、要求を中止するために。
3.11.1 Query DASSlessness
3.11.1 質問DASSlessness
Query_DASSlessness(
--inputs
verifying_credentials Credentials,
principal_name Name,
--outputs
alternate_authentication Set of OIDs)
質問_DASSlessness(--_資格証明書Credentials、主体_名前Nameについて確かめる入力--出力はOIDsの_認証Setを交替します)
This function uses the verifying credentials to search for an alternative authentication mechanism certificate for the named principal or for any CA on the path between the verifying credentials and the named principal. Such a certificate is identical to an DASS X.509 certificate except that it lists a different algorithm identifier for the public key of the subject than that expected by DASS.
この機能は、命名された主体かどんなカリフォルニアのための検証資格証明書と命名された主体の間の経路の代替の認証機構証明書も検索するのに検証資格証明書を使用します。 対象の公開鍵のためのダスによって予想されたそれと異なったアルゴリズム識別子をリストアップするのを除いて、そのような証明書はDASS X.509証明書と同じです。
This function is implemented identically to Get_Pub_Keys except:
以下を除いて、この機能は同様にGet_Pub_キーズに実装されます。
a) If in any set of certificates found, no valid DASS certificate
is found and one or more certificates are found that would
otherwise be valid except for an invalid subject public key
OID, the OID from that certificate or certificates is returned
and the algorithm terminates.
a) どんなセットの証明書でも見つけられるなら、どんな有効なダス証明書も見つけられません、そして、1通以上のそうでなければその証明書か証明書からのOID、OIDを返して、アルゴリズムが終える無効の対象の公開鍵を除いて、有効な証明書が見つけられます。
b) On initial execution, Try_Hard=False. If the first execution
fails to retrieve any valid PK/UID pairs but also fails to
find any invalid OID certificates, repeat the execution with
Try_Hard=True.
b) 初期の実行のときに、Try_Hardは偽と等しいです。 最初の実行がどんな有効なPK/UID組も救済しませんが、どんな無効のOID証明書もまた見つけないなら、Try_Hard=が本当の状態で実行を繰り返してください。
c) If the either execution finds PK/UID pairs or if neither finds
and invalid OID certificates, fail by returning a null set.
c) 実行はPK/UID組に当たるか、またはどちらの掘り出し物と無効のOID証明書であるなら、零集合を返しながら、失敗してください。
4. Certificate and message formats
4. 証明書とメッセージ・フォーマット
4.1 ASN.1 encoding
4.1 ASN.1コード化
Some definitions are taken from X.501 and X.509.
X.501とX.509からいくつかの定義を取ります。
Dass DEFINITIONS ::=
ダスDEFINITIONS:、:=
BEGIN
始まってください。
--CCITT Definitions:
--CCITT定義:
joint-iso-ccitt OBJECT IDENTIFIER ::= {2}
共同iso-ccitt OBJECT IDENTIFIER:、:= {2}
Kaufman [Page 89] RFC 1507 DASS September 1993
コーフマン[89ページ]RFC1507ダス1993年9月
ds OBJECT IDENTIFIER ::= {joint-iso-ccitt 5}
algorithm OBJECT IDENTIFIER ::= {ds 8}
encryptionAlgorithm OBJECT IDENTIFIER ::= {algorithm 1}
hashAlgorithm OBJECT IDENTIFIER ::= {algorithm 2}
signatureAlgorithm OBJECT IDENTIFIER ::= {algorithm 3}
rsa OBJECT IDENTIFIER ::= {encryptionAlgorithm 1}
ds OBJECT IDENTIFIER:、:= 共同iso-ccitt5アルゴリズムOBJECT IDENTIFIER:、:= ds8encryptionAlgorithmオブジェクト識別子:、:= アルゴリズム1hashAlgorithmオブジェクト識別子:、:= アルゴリズム2signatureAlgorithmオブジェクト識別子:、:= アルゴリズム3rsa OBJECT IDENTIFIER:、:= encryptionAlgorithm1
iso OBJECT IDENTIFIER ::= {1}
identified-organization OBJECT IDENTIFIER ::= {iso 3}
ecma OBJECT IDENTIFIER ::= {identified-organization 12}
member-company OBJECT IDENTIFIER ::= {ecma 2}
digital OBJECT IDENTIFIER ::= {member-company 1011}
iso OBJECT IDENTIFIER:、:= 1 特定された組織OBJECT IDENTIFIER:、:= iso3ecma OBJECT IDENTIFIER:、:= 特定された組織12連盟会社OBJECT IDENTIFIER:、:= ecma2のデジタルOBJECT IDENTIFIER:、:= 連盟会社1011
--1989 OSI Implementors Workshop "Stable" Agreements
--1989のOSI作成者ワークショップ「うまや」協定
oiw OBJECT IDENTIFIER ::= {identified-organization 14}
dssig OBJECT IDENTIFIER ::= {oiw 7}
oiwAlgorithm OBJECT IDENTIFIER ::= {dssig 2}
oiwEncryptionAlgorithm OBJECT IDENTIFIER ::= {oiwAlgorithm 1}
oiwHashAlgorithm OBJECT IDENTIFIER ::= {oiwAlgorithm 2}
oiwSignatureAlgorithm OBJECT IDENTIFIER ::= {oiwAlgorithm 3}
oiwMD2 OBJECT IDENTIFIER ::= {oiwHashAlgorithm 1}
--null parameter
oiwMD2withRSA OBJECT IDENTIFIER ::= {oiwSignatureAlgorithm 1}
--null parameter
oiw OBJECT IDENTIFIER:、:= 特定された組織14、dssig OBJECT IDENTIFIER:、:= oiw7oiwAlgorithmオブジェクト識別子:、:= dssig2oiwEncryptionAlgorithmオブジェクト識別子:、:= oiwAlgorithm1oiwHashAlgorithmオブジェクト識別子:、:= oiwAlgorithm2oiwSignatureAlgorithmオブジェクト識別子:、:= oiwAlgorithm3oiwMD2オブジェクト識別子:、:= oiwHashAlgorithm1--ヌルパラメタoiwMD2withRSA OBJECT IDENTIFIER:、:= oiwSignatureAlgorithm1--ヌルパラメタ
--X.501 definitions
--X.501定義
AttributeType ::= OBJECT IDENTIFIER
AttributeValue ::= ANY
AttributeValueAssertion ::= SEQUENCE {AttributeType,AttributeValue}
AttributeType:、:= 識別子AttributeValueは反対します:、:= どんなAttributeValueAssertionも:、:= 系列AttributeType、AttributeValue
Name ::= CHOICE { --only one for now
RDNSequence
}
RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
DistinguishedName ::= RDNSequence
以下を命名してください:= CHOICE、--、当分間の1だけ、RDNSequence、RDNSequence:、:= RelativeDistinguishedName DistinguishedNameの系列:、:= RDNSequence
RelativeDistinguishedName ::= SET OF AttributeValueAssertion
RelativeDistinguishedName:、:= AttributeValueAssertionのセット
--X.509 definitions (with proposed 1992 extensions presumed)
--X.509定義(1992の提案された拡大が推定されている)
ENCRYPTED MACRO ::= BEGIN TYPE NOTATION ::= type(ToBeEnciphered) VALUE NOTATION ::= value(VALUE BIT STRING) END -- of ENCRYPTED
暗号化されたマクロ:、:= タイプ記法を始めてください:、:= (ToBeEnciphered)値の記法をタイプしてください:、:= 暗号化されることの値(値のビット列)の終わり
Kaufman [Page 90] RFC 1507 DASS September 1993
コーフマン[90ページ]RFC1507ダス1993年9月
SIGNED MACRO ::=
BEGIN
TYPE NOTATION ::= type (ToBeSigned)
VALUE NOTATION ::= value (VALUE
SEQUENCE{
ToBeSigned,
AlgorithmIdentifier, --of the algorithm used to
--generate the signature
ENCRYPTED OCTET STRING --where the octet string is the
--result of the hashing of the
--value of "ToBeSigned"
}
)
END -- of SIGNED
署名しているマクロ:、:= タイプ記法を始めてください:、:= (ToBeSigned)VALUE NOTATIONをタイプしてください:、:= 値、(VALUE SEQUENCE、ToBeSigned、アルゴリズムのAlgorithmIdentifierは以前はよくそうしていました--八重奏ストリングが生成するところで署名がENCRYPTED OCTET STRINGであると生成してください、--、論じ尽くすことが結果として生じる、--、"ToBeSigned"の値、)、SIGNEDのEND
SIGNATURE MACRO ::=
BEGIN
TYPE NOTATION ::= type (OfSignature)
VALUE NOTATION ::= value (VALUE
SEQUENCE {
AlgorithmIdentifier, --of the algorithm used to compute
ENCRYPTED OCTET STRING -- the signature where the octet
-- string is a function (e.g., a
-- compressed or hashed version)
-- of the value 'OfSignature',
-- which may include the
-- identifier of the algorithm
-- used to compute the signature
}
)
END -- of SIGNATURE
署名マクロ:、:= タイプ記法を始めてください:、:= (OfSignature)VALUE NOTATIONをタイプしてください:、:= 値、(VALUE SEQUENCE、ENCRYPTED OCTET STRINGを計算するのに使用されるアルゴリズムのAlgorithmIdentifier、署名、ストリングが機能(例えば、a--圧縮されたか論じ尽くされたバージョン)であるという値の'OfSignature'(そうするかもしれない)の八重奏が含むどこ、以前はよく署名を計算していたか、(アルゴリズムに関する識別子))、SIGNATUREのEND
Certificate ::= SIGNED SEQUENCE {
version [0] Version DEFAULT v1988,
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer Name,
valid Validity,
subject Name,
subjectPublicKey SubjectPublicKeyInfo,
issuerUID [1] IMPLICIT UID OPTIONAL, -- v1992
subjectUID [2] IMPLICIT UID OPTIONAL -- v1992
}
以下を証明してください:= 系列であると署名されます。バージョン[0]バージョンDEFAULT v1988、serialNumber CertificateSerialNumber、署名AlgorithmIdentifier、発行人Name(有効なValidity)はName、subjectPublicKey SubjectPublicKeyInfo、issuerUID[1]IMPLICIT UID OPTIONAL--v1992 subjectUID[2]IMPLICIT UID OPTIONAL--v1992をかけます。
--The Algorithm Identifier for both the signature field
--両方の署名分野へのAlgorithm Identifier
Kaufman [Page 91] RFC 1507 DASS September 1993
コーフマン[91ページ]RFC1507ダス1993年9月
--and in the signature itself is:
-- oiwMD2withRSA (1.3.14.7.2.3.1)
--コネ、署名自体は以下の通りです。 -- oiwMD2withRSA(1.3.14.7.2.3.1)
Version ::= INTEGER {v1988(0), v1992(1)}
バージョン:、:= 整数v1988(0)、v1992(1)
CertificateSerialNumber ::= INTEGER
CertificateSerialNumber:、:= 整数
Validity ::= SEQUENCE {
NotBefore UTCTime,
NotAfter UTCTime
}
正当性:、:= 系列NotBefore UTCTime、NotAfter UTCTime
AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameter ANY DEFINED BY algorithm OPTIONAL
}
AlgorithmIdentifier:、:= 系列アルゴリズムOBJECT IDENTIFIER、パラメタANY DEFINED BYアルゴリズムOPTIONAL
--The algorithms we support in one context or another are:
--oiwMD2withRSA (1.3.14.7.2.3.1) with parameter NULL
--rsa (2.5.8.1.1) with parameter keysize INTEGER which is
-- the keysize in bits
--decDEA (1.3.12.1001.7.1.2) with optional parameter
-- missing
--decDEAMAC (1.3.12.2.1011.7.3.3) with optional parameter
-- missing
--私たちが何らかの文脈でサポートするアルゴリズムは以下の通りです。 --oiwMD2withRSA、(1.3、.14、.7、.2、.3、パラメタNULL --rsaがある.1、)(2.5 .8 .1 .1) そうするパラメタkeysize INTEGERと共に--、ビット--decDEAでkeysizeする、(1.3 .12 .1001 .7 .1 .2) 任意のパラメタで--、なくなった--decDEAMAC、(1.3 .12 .2 .1011 .7 .3 .3) 任意のパラメタで--、なくなる。
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier, -- rsa (2.5.8.1.1)
subjectPublicKey BIT STRING
-- the "bits" further decode into a DASS public key
}
SubjectPublicKeyInfo:、:= 系列アルゴリズムAlgorithmIdentifier--rsaする、(2.5、.8、.1、.1)subjectPublicKey BIT STRING、--「ビット」がさらにダス公開鍵に解読する
UID ::= BIT STRING
UID:、:= ビット列
-- the following definitions are for Digital specified Algorithms
-- 以下の定義はDigitalの指定されたAlgorithmsのためのものです。
cryptoAlgorithm OBJECT IDENTIFIER ::= {digital 7}
cryptoAlgorithmオブジェクト識別子:、:= デジタル7
decEncryptionAlgorithm OBJECT IDENTIFIER ::= {cryptoAlgorithm 1}
decHashAlgorithm OBJECT IDENTIFIER ::= {cryptoAlgorithm 2}
decSignatureAlgorithm OBJECT IDENTIFIER ::= {cryptoAlgorithm 3}
decDASSLessness OBJECT IDENTIFIER ::= {cryptoAlgorithm 6}
decEncryptionAlgorithmオブジェクト識別子:、:= cryptoAlgorithm1decHashAlgorithmオブジェクト識別子:、:= cryptoAlgorithm2decSignatureAlgorithmオブジェクト識別子:、:= cryptoAlgorithm3decDASSLessnessオブジェクト識別子:、:= cryptoAlgorithm6
decMD2withRSA OBJECT IDENTIFIER ::= {decSignatureAlgorithm 1}
decMD4withRSA OBJECT IDENTIFIER ::= {decSignatureAlgorithm 2}
decDEAMAC OBJECT IDENTIFIER ::= {decSignatureAlgorithm 3}
decMD2withRSAオブジェクト識別子:、:= decSignatureAlgorithm1decMD4withRSAオブジェクト識別子:、:= decSignatureAlgorithm2decDEAMACオブジェクト識別子:、:= decSignatureAlgorithm3
Kaufman [Page 92] RFC 1507 DASS September 1993
コーフマン[92ページ]RFC1507ダス1993年9月
decDEA OBJECT IDENTIFIER ::= {decEncryptionAlgorithm 2}
decMD2 OBJECT IDENTIFIER ::= {decHashAlgorithm 1}
decMD4 OBJECT IDENTIFIER ::= {decHashAlgorithm 2}
decDEAオブジェクト識別子:、:= decEncryptionAlgorithm2decMD2オブジェクト識別子:、:= decHashAlgorithm1decMD4オブジェクト識別子:、:= decHashAlgorithm2
ShortPosixTime ::= INTEGER -- number of seconds since base time
ShortPosixTime:、:= INTEGER--秒数は以来、時間を基礎づけます。
LongPosixTime ::= SEQUENCE {
INTEGER, -- number of seconds since base time
INTEGER -- number of nanoseconds since second
}
LongPosixTime:、:= 系列INTEGER--ベース時間INTEGER以来の秒数--2番目以来の数ナノ秒の数
ShortPosixValidity ::= SEQUENCE {
notBefore ShortPosixTime,
notAfter ShortPosixTime }
ShortPosixValidity:、:= 系列notBefore ShortPosixTime、notAfter ShortPosixTime
-- Note: Annex C of X.509 prescribes the following format for the -- representation of a public key, but does not give the structure -- a name.
-- 以下に注意してください。 X.509の別館Cが以下の形式を定める、--構造を与えないのを除いた公開鍵の表現、名前。
DASSPublicKey ::= SEQUENCE {
modulus INTEGER,
exponent INTEGER
}
DASSPublicKey:、:= 系列係数INTEGER、解説者INTEGER
DASSPrivateKey ::= SEQUENCE {
p INTEGER , -- prime p
q [0] IMPLICIT INTEGER OPTIONAL , -- prime q
mod[1] IMPLICIT INTEGER OPTIONAL, -- modulus
exp [2] IMPLICIT INTEGER OPTIONAL, -- public exponent
dp [3] IMPLICIT INTEGER OPTIONAL , -- exponent mod p
dq [4] IMPLICIT INTEGER OPTIONAL , -- exponent mod q
cr [5] IMPLICIT INTEGER OPTIONAL , -- Chinese
--remainder coefficient
uid[6] IMPLICIT UID OPTIONAL,
more[7] IMPLICIT BIT STRING OPTIONAL --Reserved for
--future use
}
DASSPrivateKey:、:= 系列{p INTEGER--予約されていた状態でp q[0]IMPLICIT INTEGER OPTIONAL([1] IMPLICIT INTEGER OPTIONAL--係数exp[2]IMPLICIT INTEGER OPTIONAL--公共の解説者dp[3]IMPLICIT INTEGER OPTIONAL--解説者モッズp dq[4]IMPLICIT INTEGER OPTIONAL--主要なqモッズ解説者モッズq cr[5]IMPLICIT INTEGER OPTIONAL--中国語--残り係数uid[6] IMPLICIT UID OPTIONAL、より多くの[7]IMPLICIT BIT STRING OPTIONAL)を用意してください--今後の使用}
LocalUserName ::= OCTET STRING
ChannelId ::= OCTET STRING
VersionNumber ::= OCTET STRING (SIZE(3))
-- first octet is major version
-- second octet is minor version
-- third octet is ECO rev.
versionZero VersionNumber ::= '000000'H
LocalUserName:、:= 八重奏ストリングChannelId:、:= 八重奏ストリングVersionNumber:、:= OCTET STRING、(SIZE(3))--最初の八重奏は主要なバージョンです--2番目の八重奏はさ細なバージョンです--3番目の八重奏はECOが. versionZero VersionNumberを回転させるということです:、:= '000000'H
Kaufman [Page 93] RFC 1507 DASS September 1993
コーフマン[93ページ]RFC1507ダス1993年9月
Authenticator ::= SIGNED SEQUENCE {
type BIT STRING,
-- first bit `delegation required'
-- second bit `Mutual Authentication Requested'
whenSigned LongPosixTime ,
channelId [3] IMPLICIT ChannelId OPTIONAL
-- channel bindings are included when doing the
-- signature, but excluded when transmitting the
-- Authenticator
}
-- uses decDEAMAC (1.3.12.2.1011.7.3.3)
固有識別文字:、:= するとき、{BIT STRINGをタイプしてください--'委譲が必要とした最初のビット'('互いのAuthentication Requested'whenSigned LongPosixTimeは2番目に噛み付きました、channelId[3]IMPLICIT ChannelId OPTIONAL)というSIGNED SEQUENCEチャンネル結合が含まれている、--、署名にもかかわらず、除かれる、伝えると--、固有識別文字、--、decDEAMACを使用します。(1.3.12.2.1011.7.3.3)
EncryptedKey ::= SEQUENCE {
algorithm AlgorithmIdentifier,
-- uses rsa (2.5.8.1.1)
encryptedAuthKey BIT STRING
-- as defined in section 4.4.5
}
EncryptedKey:、:= 系列アルゴリズムAlgorithmIdentifier、--、用途がrsaされる(2.5、.8、.1、定義されたコネセクション4.4.5としての.1)encryptedAuthKey BIT STRING
SignatureOnEncryptedKey ::= SIGNATURE EncryptedKey
-- uses oiwMD2withRSA (1.3.14.7.2.3.1)
-- Signature bits computed over EncryptedKey structure
SignatureOnEncryptedKey:、:= SIGNATURE EncryptedKey--、oiwMD2withRSAを使用する、(1.3、.14、.7、.2、.3、ビットがEncryptedKey構造で計算した.1)--署名
LoginTicket ::= SIGNED SEQUENCE {
version [0] IMPLICIT VersionNumber DEFAULT versionZero,
validity ShortPosixValidity ,
subjectUID UID ,
delegatingPublicKey SubjectPublicKeyInfo
}
-- uses oiwMD2withRSA (1.3.14.7.2.3.1)
LoginTicket:、:= SIGNED SEQUENCE、バージョン[0]IMPLICIT VersionNumber DEFAULT versionZero、正当性ShortPosixValidity、subjectUID UID、delegatingPublicKey SubjectPublicKeyInfo--、oiwMD2withRSAを使用します。(1.3.14.7.2.3.1)
Delegator ::= SEQUENCE {
algorithm AlgorithmIdentifier
-- decDEA encryption (1.3.12.1001.7.1.2)
encryptedPrivKey ENCRYPTED DASSPrivateKey,
-- (only p is included)
}
Delegator:、:= 系列アルゴリズムAlgorithmIdentifier--、decDEA暗号化、(1.3 .12 .1001 .7 .1 .2)encryptedPrivKey ENCRYPTED DASSPrivateKey--、(pだけが含まれています)
UserClaimant ::= SEQUENCE {
userTicket [0] IMPLICIT LoginTicket,
evidence CHOICE {
delegator [1] IMPLICIT Delegator ,
-- encrypted delegation private key
-- under DES authenticating key
-- present if delegating
sharedKeyTicketSignature [2]
UserClaimant:、:= SEQUENCE、userTicket[0]IMPLICIT LoginTicket、証拠CHOICE、sharedKeyTicketSignatureを代表として派遣するなら、「反-遺贈者」[1]IMPLICIT Delegator(キーを認証するDESの下の暗号化された委譲秘密鍵)は提示します。[2]
Kaufman [Page 94] RFC 1507 DASS September 1993
コーフマン[94ページ]RFC1507ダス1993年9月
IMPLICIT SignatureOnEncryptedKey
-- present if not delegating
} ,
userName [3] IMPLICIT Name OPTIONAL
-- name of user principal
}
IMPLICIT SignatureOnEncryptedKey--そうでなければ、代表として派遣することを提示してください。 , ユーザ校長における名義のuserName[3]IMPLICIT Name OPTIONAL
EncryptedKeyandUserName ::= SEQUENCE {
encryptedKey EncryptedKey ,
username LocalUserName
}
EncryptedKeyandUserName:、:= 系列encryptedKey EncryptedKey、ユーザ名LocalUserName
SignatureOnEncryptedKeyandUserName ::=
SIGNATURE EncryptedKeyandUserName
-- uses oiwMD2withRSA (1.3.14.7.2.3.1)
-- Signature bits computed over
-- EncryptedKeyandUserName structure
-- using node private key
}
SignatureOnEncryptedKeyandUserName:、:= SIGNATURE EncryptedKeyandUserName--、oiwMD2withRSAを使用する、(1.3、.14、.7、ノード秘密鍵を使用して、.3.1(ビットが計算した署名))EncryptedKeyandUserNameが構造化する.2
NodeClaimant ::= SEQUENCE {
nodeTicket Signature[0] IMPLICIT
SignatureOnEncryptedKeyandUserName,
nodeName [1] IMPLICIT Name OPTIONAL,
username [2] IMPLICIT LocalUserName OPTIONAL
}
NodeClaimant:、:= 系列nodeTicket Signature[0] IMPLICIT SignatureOnEncryptedKeyandUserName、nodeName[1]IMPLICIT Name OPTIONAL、ユーザ名[2]IMPLICIT LocalUserName OPTIONAL
AuthenticationToken ::= SEQUENCE {
version [0] IMPLICIT VersionNumber DEFAULT versionZero,
authenticator [1] IMPLICIT Authenticator ,
encryptedKey [2] IMPLICIT EncryptedKey OPTIONAL ,
-- required if initiating token
userclaimant [3] IMPLICIT UserClaimant OPTIONAL ,
-- missing if only doing node authentication
-- required if not doing node authentication
nodeclaimant [4] IMPLICIT NodeClaimant OPTIONAL
-- missing if only doing principal authentication
-- required if not doing principal authentication
}
AuthenticationToken:、:= 系列バージョン[0]IMPLICIT VersionNumber DEFAULT versionZero、必要である、または主要な認証をして、固有識別文字[1]IMPLICIT Authenticator(encryptedKey[2]IMPLICIT EncryptedKey OPTIONAL(象徴userclaimant[3]IMPLICIT UserClaimant OPTIONALを開始するなら、ノード認証をするだけであるなら消えて、必要である))はそうでなければ、主要な認証をするだけであるなら消えて、ノード認証nodeclaimant[4]IMPLICIT NodeClaimant OPTIONALをするのを必要としました。
MutualAuthenticationToken ::= CHOICE {
v1Response [0] IMPLICIT OCTET STRING (SIZE(6))
-- Constructed as follows: A single DES block
-- of eight octets is constructed from the two
-- integers in the timestamp. First four bytes
-- are the high order integer encoded MSB
-- first; Last four bytes are the low order
MutualAuthenticationToken:、:= CHOICE、v1Response[0]IMPLICIT OCTET STRING、(8つの八重奏のSIZE(6))(以下の通り: 1DESブロックして組み立てられる)は2から組み立てられます--タイムスタンプの整数、最初の4バイト--高位整数であることはMSBをコード化しました--1番目、最後の4バイトは下位です。
Kaufman [Page 95] RFC 1507 DASS September 1993
コーフマン[95ページ]RFC1507ダス1993年9月
-- integer encoded MSB first. The block is
-- encrypted using the shared DES key, and
-- the first six bytes are the OCTET STRING.
-- With the [0] type and 6-byte length, the
-- MutualAuthenticationToken has a fixed
-- length of eight bytes.
}
END
-- 整数は最初に、MSBをコード化しました。 そして、ブロックはそうです--共有されたDESキーを使用することでコード化される、--最初の6バイトはOCTET STRINGです。 -- [0]タイプと6バイトの長さで--MutualAuthenticationTokenは麻薬を注射します--8バイトの長さ } 終わり
4.2 Encoding Rules
4.2 規則をコード化すること。
Whenever a structure is to be signed it must always be constructed the same way. This is particularly important where a signed structure has to be reconstructed by the recipient before the signature is verified. The rules listed below are taken from X.509.
サインされる構造がことであるときはいつも、同じようにそれをいつも組み立てなければなりません。 署名が確かめられる前にこれはサインされた構造が受取人によって再建されなければならないところで特に重要です。 X.509から以下に記載された規則を取ります。
- the definite form of length encoding shall be used, encoded in
the minimum number of octets;
- 長さのコード化の已然形は、八重奏の最小の数で中古で、コード化するようになるでしょう。
- for string types, the constructed form of encoding shall not
be used;
- ストリングタイプのために、組み立てられたフォームのコード化を使用しないものとします。
- if the value of a type is its default value, it shall be
absent;
- タイプの値がデフォルト値であるなら、欠けるでしょう。
- the components of a Set type shall be encoded in ascending
order of their tag value;
- Setタイプの成分はそれらのタグ価値の昇順でコード化されるものとします。
- the components of a Set-of type shall be encoded in ascending
order of their octet value;
- aのコンポーネント、Set、-、タイプはそれらの八重奏価値の昇順でコード化されるものとします。
- if the value of a Boolean type is true, the encoding shall
have its contents octet set to `FF'16;
- ブールタイプの値が本当であるなら、コード化で、'FF16年'にコンテンツ八重奏を設定するものとします。
- each unused bits in the final octet of the encoding of a
BitString value, if there are any, shall be set to zero;
- それぞれ、いずれかあれば、BitString価値のコード化の最終的な八重奏における未使用のビットはゼロに設定されるものとします。
- the encoding of a Real type shall be such that bases 8, 10 and
16 shall not be used, and the binary scaling factor shall be
zero.
- ベース8、10、および16を使用しないものとして、2進のけた移動子がゼロになるようにレアルタイプのコード化はものになるでしょう。
4.3 Version numbers and forward compatibility
4.3 バージョン番号と下位互換
The LoginTicket and AuthenticationToken structures contain a three octet version identifier which is intended to ease transition to future revisions of this architecture. The default value, and the value which should always be supplied by implementations of this version of the architecture is 0.0.0
LoginTicketとAuthenticationToken構造はこの構造の今後の改正への変遷を緩和することを意図する3八重奏バージョン識別子を含んでいます。 デフォルト値、およびいつも供給して、構造のこのバージョンの実現が0.0であるということであるべきである値、.0
Kaufman [Page 96] RFC 1507 DASS September 1993
コーフマン[96ページ]RFC1507ダス1993年9月
(three zero octets). The first octet is the major version. An implementation of this version of the architecture should refuse to process data structures where it is other than zero, because changing it indicates that the interpretation of some subsidiary data structure has changed. The second octet is the minor version. An implementation of this version of the architecture should ignore the value of this octet. Some future version of the architecture may set a value other than zero and may specify some different processing of the remainder of the structure based on that different value. Such a change would be backward compatible and interoperable. The third octet is the ECO revision. No implementation should make any processing decisions based on the value of that octet. It may be logged, however, to help in debugging interoperability problems.
(3は八重奏のゼロに合っています。) 最初の八重奏は主要なバージョンです。 構造のこのバージョンの実現は、ゼロを除いて、それがあるデータ構造を処理するのを拒否するべきです、それを変えるのが、何らかの補助のデータ構造の解釈が変化したのを示すので。 2番目の八重奏はさ細なバージョンです。 構造のこのバージョンの実現はこの八重奏の値を無視するべきです。 構造の何らかの将来のバージョンが、ゼロ以外の値を設定して、その異価に基づく構造の残りの何らかの異なった処理を指定するかもしれません。 そのような変化は互換性があって共同利用できた状態で後方でしょう。 3番目の八重奏はECO改正です。 どんな実現もその八重奏の値に基づくどんな処理決定もするべきではありません。 しかしながら、それは、相互運用性問題をデバッグするのを手伝うために登録されるかもしれません。
In the CDC protocol, there is also a three octet version numbering scheme, where versions 1.0.0 and 2.0.0 have been defined. Implementations should follow the same rules above and reject major version numbers greater than 2.
そこでCDCでは、議定書を作ってください。3八重奏バージョンナンバリングスキームも、どこがバージョン1.0.0であるか、そして、2.0に、.0は定義されました。 実現は、上の同じ規則に従って、2以上のメジャーバージョン番号を拒絶するべきです。
ASN.1 is inherently extensible because it allows new fields to be added "onto the end" of existing data structures in an unambiguous way. Implementations of DASS are encouraged to ignore any such additional fields in order to enhance backwards compatibility with future versions of the architecture. Unfortunately, commonly available ASN.1 compilers lack this capability, so this behavior cannot reasonably be required and may limit options for future extensions.
新しい分野がそれで「終わり」に加えるので、ASN.1は本来既存のデータ構造で明白な方法で広げることができます。 ダスの実現が後方に構造の将来のバージョンとの互換性を高めるためにそのようなどんな追加分野も無視するよう奨励されます。 残念ながら、一般的に利用可能なASN.1コンパイラがこの能力を欠いているので、この振舞いは、合理的に必要であることができなく、今後の拡大のためのオプションを制限するかもしれません。
4.4 Cryptographic Encoding
4.4 暗号のコード化
Some of the substructures listed in the previous sections are specified as ENCRYPTED OCTET STRINGs containing encrypted information. DASS uses the DES, RSA, and MD2 cryptosystems Each of those cryptosystems specifies a function from octet string into another in the presence of a key (except MD2, which is keyless). This section describes how to form the octet strings on which the DES and RSA operations are performed.
前項で記載された基礎のいくつかがコード化された情報を含むENCRYPTED OCTET STRINGsとして指定されます。 ダス用途のDES、RSA、およびそれらの暗号系のMD2暗号系Eachはキー(キーがないMD2を除いた)があるとき八重奏ストリングから別のものに機能を指定します。 このセクションはDESとRSA操作が実行される八重奏ストリングを形成する方法を説明します。
4.4.1 Algorithm Independence vs. Key Parity
4.4.1 アルゴリズム独立対主要な同等
All of the defined encodings for DASS for secret key encryption are based on DES. It is intended, however, that other cryptosystems could be substituted without any other changes for formats or algorithms. The required "form factor" for such a cryptosystem is that it have a 64 bit key and operate on 64 bit blocks (this appears to be a common form factor for a cryptosystem). For this reason, DES keys are in all places
秘密鍵暗号化のためのダスのための定義されたencodingsのすべてがDESに基づいています。 しかしながら、変化なしでいかなる他のも形式かアルゴリズムに他の暗号系を代入できたことを意図します。そのような暗号系に、必要な「形状因子」は64ビットのキーを持って、64ビットのブロックを作動させるということ(これは暗号系のための一般的な形状因子であるように見える)です。 この理由で、DESキーがすべての場所にあります。
Kaufman [Page 97] RFC 1507 DASS September 1993
コーフマン[97ページ]RFC1507ダス1993年9月
treated as though they were 64 bits long rather than 56. Only in the operation of the algorithm itself are eight bits of the key dropped and key parity bits substituted. Choosing a key always involves picking a 64 bit random number.
まるでそれらが56よりむしろ長さ64ビットであるかのように、扱われます。 キーの8ビットはアルゴリズム自体の操作だけで落とされました、そして、主要なパリティビットは代理をしました。 キーを選ぶのは、いつも64の噛み付いている乱数を選ぶことを伴います。
4.4.2 Password Hashing
4.4.2 パスワードの論じ尽くすこと
Encrypted credentials are encrypted using DES as described in the next section. The key for that encryption is derived from the user's password and name by the following algorithm:
コード化された信任状は、次のセクションで説明されるようにDESを使用することでコード化されています。 ユーザのパスワードと名前から以下のアルゴリズムでその暗号化のためのキーを得ます:
a) Put the rightmost RDN of the user's name in canonical form
according to BER and the X.509 encoding rules. For any string
types that are case insensitive, map to upper case, and where
matching is independent of number of spaces collapse all
multiple spaces to a single space and delete leading and
trailing spaces.
a) BERとX.509符号化規則に従って、ユーザの名前の一番右のRDNを標準形に置いてください。 大文字、およびどこへの地図が合っていて、大文字と小文字を区別しないタイプの如何にかかわらずあるどんなストリングのためにも、空間の数は、すべての複数の空間をシングルスペースまで潰して、主で引きずっている空間を削除します。
Note: the RDN is used to add "salt" to the hash calculation
so that someone can't precompute the hash of all the words in
a dictionary and then apply them against all names. Deriving
the salt from the last RDN of the name is a compromise. If it
were derived from the whole name, all encrypted keys would be
obsoleted when a branch of the namespace was renamed. If it
were independent of name, interaction with a login agent would
take two extra messages to retrieve the salt. With this
scheme, encrypted keys are obsoleted by a change in the last
RDN and if a final RDN is common to a large number of users,
dictionary attacks against them are easier; but the common
case works as desired.
以下に注意してください。 RDNは、だれかが辞書のすべての単語の細切れ肉料理を前計算して、次に、すべての名前に対してそれらを適用できないように「塩」を細切れ肉料理計算に加えるのに使用されます。 名前の最後のRDNから塩を得るのは、妥協です。 名前空間のブランチを改名したとき、全部の名前からそれを得るなら、すべてのコード化されたキーを時代遅れにするでしょうに。 それが名前から独立しているなら、ログインエージェントとの相互作用は塩を検索する2つの余分な伝言を受け取るでしょうに。 この計画では、コード化されたキーは最後のRDNにおける変化によって時代遅れにされて、多くのユーザにとって、最終的なRDNが一般的であるなら、それらに対する辞書攻撃は、より簡単です。 しかし、よくある例は望まれているように働いています。
b) Compute TEMP as the MD2 message digest of the concatenation of
the password and the RDN computed above.
b) パスワードとRDNの連結のMD2メッセージダイジェストが上で計算されたようにTEMPを計算してください。
c) Repeat the following 40 times: Use the first 64 bits of TEMP
as a DES key to encrypt the second 64 bits; XOR the result
with the first 64 bits of TEMP; and compute a new TEMP as MD2
of the 128 bit result.
c) 以下の40回繰り返してください: 2番目の64ビットをコード化するために主要なDESとしてTEMPの最初の64ビットを使用してください。 XOR、TEMPの最初の64ビットがある結果。 そして、128のもののMD2が結果に噛み付いたので、新しいTEMPを計算してください。
d) Use the final 64 bits of the result (called hash1) as the key
to decrypt the encrypted credentials. Use the first 64 bits
(called hash2) as the proof of knowledge of the password for
presentation to a login agent (if any).
d) キーとして結果(hash1と呼ばれる)の最終的な64ビットを使用して、コード化された信任状を解読してください。 プレゼンテーションに、パスワードに関する知識の証拠として最初の64ビット(hash2と呼ばれる)をログインエージェント(もしあれば)に使用してください。
Kaufman [Page 98] RFC 1507 DASS September 1993
コーフマン[98ページ]RFC1507ダス1993年9月
4.4.3 Digital DEA encryption
4.4.3 デジタルDEA暗号化
DES encryption is used in the following places:
DES暗号化は以下の場所で使用されます:
- In the encryption of the encrypted credentials structure
- コード化された信任状構造の暗号化で
- To encrypt the delegator in authentication tokens
- 認証象徴で「反-遺贈者」をコード化するために
- To encrypt the time in the mutual authenticator
- 互いの固有識別文字で時間をコード化するために
In the first two cases, a varying length block of information coded in ASN.1 is encrypted. This is done by dividing the block of information into 8 octet blocks, padding the last block with zero bytes if necessary, and encrypting the result using the CBC mode of DES. A zero IV is used.
最初の2つの場合では、ASN.1でコード化された情報の異なったレングス・ブロックはコード化されています。 情報のブロックを8つの八重奏ブロックに分割することによって、これをします、必要なら、バイトのゼロを合わせて、DESのCBCモードを使用することで結果をコード化するのに最後のブロックを水増しして。 AゼロIVは使用されています。
In the third case, a fixed length (8 byte) quantity (a timestamp) is encrypted. The timestamp is mapped to a byte string using "big endian" order and the block is encrypted using the ECB mode of DES.
3番目の場合では、固定長(8バイト)量(タイムスタンプ)はコード化されています。 タイムスタンプは「ビッグエンディアン」オーダーを使用することでバイトストリングに写像されます、そして、ブロックは、DESのECBモードを使用することでコード化されています。
4.4.4 Digital MAC Signing
4.4.4 デジタルMAC調印
DES signing is used in the Authenticator. Here, the signature is computed over an ASN.1 structure. The signature is the CBC residue of the structure padded to a multiple of eight bytes with zeros. The CBC is computed with an IV of zero.
DES調印はAuthenticatorで使用されます。 ここで、署名はASN.1構造で計算されます。 署名はゼロに従った8バイトの倍数に水増しされた構造のCBCの残りです。 CBCはゼロのIVと共に計算されます。
4.4.5 RSA Encryption
4.4.5 RSA暗号化
RSA encryption is used in the Encrypted Shared Key. RSA encryption is best thought of as operating on blocks which are integers rather than octet strings and the results are also integers. Because an RSA encryption permutes the integers between zero and (modulus-1), it is generally thought of as acting on a block of size (keysizeinbits-1) and producing a block of size (keysizeinbits) where keysizeinbits is the smallest number of bits in which the modulus can be represented.
RSA暗号化はEncrypted Shared Keyで使用されます。 RSA暗号化は八重奏ストリングよりむしろ整数であるブロックを作動させると特に考えられます、そして、また、結果は整数です。 RSA暗号化がゼロと(係数-1)の間の整数を並べ替えるので、一般に、それはkeysizeinbitsが係数を表すことができるビットの最も少ない数であるところに1ブロックのサイズ(keysizeinbits-1)に影響して、1ブロックのサイズ(keysizeinbits)を生産すると考えられます。
DASS only supports key sizes which are a multiple of eight bits (This restriction is only required to support interoperation with certain existing implementations. If the key size is not a multiple of eight bits, the high order byte may not be able to hold values as large as the mandated '64'. This is not a problem so long as the two high order bytes together are non-zero, but certain early implementations check for the value '64' and will not interoperate with implementations that use some other value.).
ダスは8ビットの倍数である主要なサイズを支持するだけです。(この制限が、ある既存の実現でinteroperationを支持するのに必要であるだけです。 '主要なサイズが8ビットの倍数でないなら、高位バイトは一緒に2高位バイトが非ゼロですが、値のためのある早めの実現チェックが64年である限り、問題ではなく、強制された64年と同じくらい大きい値を保持できないかもしれなく'て、ある他の値を使用する実現で共同利用しないでしょう。).
The encrypted shared key structure is laid out as follows:
コード化された共有された主要な構造は以下の通り設計されます:
Kaufman [Page 99] RFC 1507 DASS September 1993
コーフマン[99ページ]RFC1507ダス1993年9月
- The DES key to be shared is placed in the last eight bytes
- 共有されているために主要なDESはベストエイトバイトに置かれます。
- The POSIX format creation time encoded in four bytes using big
endian byte order is placed in the next four (from the end)
bytes
- ビッグエンディアンバイトオーダーを使用しながら4バイトでコード化されたPOSIX形式創造時間は次の4(終わりからの)バイトに置かれます。
- The POSIX format expiration time encoded in four bytes using
big endian byte order is placed in the next four (from the
end) bytes
- ビッグエンディアンバイトオーダーを使用しながら4バイトでコード化されたPOSIX形式満了時間は次の4(終わりからの)バイトに置かれます。
- Four zero bytes are placed in the next four (from the end)
bytes
- バイトが全く置かれない4 次の4(終わりからの)バイト
- The first byte contains the constant '64' (decimal)
- '最初のバイトは一定の64年を含んでいます'(小数)
- All remaining bytes are filled with random bytes (the security
of the system does not depend on the cryptographic randomness
of these bytes, but they should not be a frequently repeating
or predictable value. Repeating the DES key from the last
bytes would be good).
- すべての残っているバイトが無作為のバイトで満たされます。(システムのセキュリティはこれらのバイトの暗号の偶発性によりませんが、それらは頻繁に繰り返しているか、予測できる値であるべきではありません。 最後のバイトから主要なDESを繰り返すのは良いでしょう。).
The RSA algorithm is applied to the integer formed by treating the bytes above as an integer in big endian order and the resulting integer is converted to a BIT STRING by laying out the integer in 'big endian' order.
RSAアルゴリズムは上でビッグエンディアンオーダーにおける整数としてバイトを扱うことによって形成された整数に適用されます、そして、結果として起こる整数は、'ビッグエンディアン'オーダーにおける整数を広げることによって、BIT STRINGに変換されます。
On decryption, the process is reversed; the decryptor should verify the four explicitly zero bytes but should not verify the contents of the high order byte or the random bytes.
復号化では、過程は逆にされます。 decryptorは明らかに4について確かめるはずです。バイトのゼロを合わせますが、高位バイトか無作為のバイトのコンテンツについて確かめるべきではありません。
4.4.6 oiwMD2withRSA Signatures
4.4.6 oiwMD2withRSA署名
RSA-MD2 signatures are used on certificates, login tickets, shared key tickets, and node tickets. In all cases, a signature is computed on an ASN.1 encoded string using an RSA private key. This is done as follows:
RSA-MD2署名は証明書、ログインチケット、共有された主要なチケット、およびノードチケットの上に使用されます。 すべての場合では、署名は、ASN.1のコード化されたストリングの上にRSA秘密鍵を使用することで計算されます。 これは以下の通り完了しています:
- The MD2 algorithm is applied to the ASN.1 encoded string to
produce a 128 bit message digest
- MD2アルゴリズムは、128ビットのメッセージダイジェストを作成するためにASN.1のコード化されたストリングに適用されます。
- The message digest is placed in the low order bytes of the RSA
block (big endian)
- メッセージダイジェストはRSAブロックの下位バイトに置かれます。(ビッグエンディアン)
- The next two lowest order bytes are the ASN.1 'T' and 'L' for
an OCTET STRING.
- 次の最も低い2オーダーバイトは、OCTET STRINGのためのASN.1'T'と'L'です。
- The remainder of the RSA block is filled with zeros
- RSAブロックの残りはゼロでいっぱいにされます。
Kaufman [Page 100] RFC 1507 DASS September 1993
コーフマン[100ページ]RFC1507ダス1993年9月
- The RSA operation is performed, and the resulting integer is
converted to an octet string by laying out the bytes in big
endian order.
- RSA操作は実行されます、そして、結果として起こる整数は、ビッグエンディアンオーダーにおけるバイトを広げることによって、八重奏ストリングに変換されます。
On verification, a value like the above or one where the message digest is present but the 'T' and 'L' are missing (zero) should be accepted for backwards compatibility with an earlier definition of this crypto algorithm.
検証のときに、この暗号アルゴリズムの以前の定義との遅れている互換性のために、上や1つのようなメッセージダイジェストが存在していますが、'T'と'L'がなくなる値(ゼロ)を受け入れるべきです。
4.4.7 decMD2withRSA Signatures
4.4.7 decMD2withRSA署名
This algorithm is the same as the oiwMD2withRSA algorithm as defined above. We allocated an algorithm object identifier from the Digital space in case the definition of that OID should change. It will not be used unless the meaning of oiwMD2withRSA becomes unstable.
このアルゴリズムは上で定義されるoiwMD2withRSAアルゴリズムと同じです。 そのOIDの定義が変化するといけないので、私たちはDigitalスペースからアルゴリズム物の識別子を割り当てました。 oiwMD2withRSAの意味が不安定にならないと、それは使用されないでしょう。
Annex A
別館A
Typical Usage
典型的な用法
This annex describes one way a system could use DASS services (as described in section 3) to provide security services. While this example provided motivation for some of the properties of DASS, it is not intended to represent the only way that DASS may be used. This goes through the steps that would be needed to install DASS "from scratch".
この別館は、セキュリティー・サービスを提供するためにシステムがダスのサービスを利用するかもしれない(セクション3で説明されるように)1つの方法を述べます。 この例はダスのいくつかの特性に関する動機を提供しましたが、ダスが使用されるかもしれないのが唯一の道を表すことを意図しません。 これは「最初から」ダスをインストールするのが必要である階段を通ります。
A.1 Creating a CA
カリフォルニアを作成するA.1
A CA is created by initializing its state. Each CA can sign certificates that will be placed in some directory in the name service. Before these certificates will be believed in a wider context than the sub-tree of the name space which is headed by that directory, the CA must be certified by a CA for the parent directory. The procedure below accomplishes this. For most secure operation, the CA should run on an off-line system and communicate with the rest of the network by interchanging files using a simple specialized mechanism such as an RS232 line or a floppy disk. It is assumed that access to the CA is controlled and that the CA will accept instructions from an operator.
カリフォルニアは、状態を初期化することによって、作成されます。 各カリフォルニアはサービスという名前で何らかのディレクトリに置かれる証明書に署名することができます。 これらの証明書はそのディレクトリによって率いられる名前スペースの下位木より広い関係を信じられる前に、カリフォルニアが親ディレクトリのためにカリフォルニアを公認しなければなりません。 以下の手順はこれを達成します。 最も安全な操作のために、カリフォルニアは、RS232系列かフロッピーディスクなどの簡単な専門化しているメカニズムを使用することでファイルを交換することによって、オフラインシステムで動いて、ネットワークの残りとコミュニケートするべきです。 カリフォルニアへのアクセスが制御されていて、カリフォルニアがオペレータから指示を受け入れると思われます。
- Call Install_CA to create the CA State.
This state is saved within the CA system and is never
disclosed.
- Install_カリフォルニアに電話をして、カリフォルニア州を創設してください。 この状態は、カリフォルニアシステムの中で節約されて、決して明らかにされません。
- If this is the first CA in the namespace and the CA is
intended to certify only members of a single directory, we are
done. Otherwise, the new CA must be linked into the CA
- これが名前空間で最初のカリフォルニアであり、カリフォルニアを単一ディレクトリの唯一のメンバーを公認するつもりであるなら、私たちをします。 さもなければ、新しいカリフォルニアをカリフォルニアにリンクしなければなりません。
Kaufman [Page 101] RFC 1507 DASS September 1993
コーフマン[101ページ]RFC1507ダス1993年9月
hierarchy by cross-certifying the parent and children of this
CA. There is no requirement that CA hierarchies be created
from the root down, but to simplify exposition, only this case
will be described. The newly created CA must learn its name,
its UID, the UID of its parent directory, and the public key
of the parent directory CA by some out of band reliable means.
Most likely, this would be done by looking up the information
in the naming service and asking the CA operator to verify it.
The CA then forms this information into a parent certificate
and signs it using the Create_certificate function. It
communicates the certificate to the network and posts it in
the naming service.
このカリフォルニアの親と子供を十字で公認するのによる階層構造。 カリフォルニア階層構造が根から作成されて、ダウンしてくださいが、博覧会を簡素化するために、本件だけが説明されるということであるという要件が全くありません。 新たに作成されたカリフォルニアは名前、UID、親ディレクトリのUID、および信頼できるバンドからのいくつかによるカリフォルニアが意味する親ディレクトリの公開鍵を学ばなければなりません。 たぶん、名前付けサービスにおける情報を調べて、それについて確かめるようにカリフォルニアのオペレータに頼むことによって、これをするでしょう。 カリフォルニアは、次に、この情報で親証明書を作って、Create_証明書機能を使用することでそれに署名します。 それは、証明書をネットワークに伝えて、名前付けサービスでそれを掲示します。
- This name, UID, and public key of the new CA are taken to the
CA of the parent directory, which verifies it (again by some
unspecified out-of-band mechanism) and calls
Create_Certificate to create a child certificate using its own
Name and UID in the issuer fields. This certificate is also
placed in the naming service.
- 新しいカリフォルニアのこの名前、UID、および公開鍵はそれについて確かめる親ディレクトリのカリフォルニアに持って行かれます、そして、(再び何らかの不特定のバンドで出ているメカニズムで)子供を創造するという呼び出しCreate_Certificateは発行人分野でそれ自身のNameを使用して、UIDを証明します。 また、この証明書は名前付けサービスに置かれます。
A CA can sign certificates for more than one directory. In this case it is possible that a single CA will take the role of both CAs in the example above. The above procedure can be simplified in this case, as no interchange of information is required.
カリフォルニアは1つ以上のディレクトリのための証明書に署名することができます。 この場合、単一のカリフォルニアが上記の例で両方のCAsの役割を果たすのは、可能です。 情報の置き換えは全く必要でないようにこの場合上の手順を簡素化できます。
A.2 Creating a User Principal
ユーザ元本を創造するA.2
A system manager may create a new user principal by invoking the Create_principal function supplying the principal's name, UID, and the public key/UID of the parent CA. The public key and UID must be obtained in a reliable out of band manner. This is probably by having knowledge of that information "wired into" the utility which creates new principals. At account creation time, the system manager must supply what will become the user's password. This might be done by having the user present and directly enter a password or by having the password selected by some random generator.
システム・マネージャは、親カリフォルニアの主体の名前、UID、および公開鍵/UIDを提供しながらCreate_主体機能を呼び出すことによって、新しいユーザ元本を創造するかもしれません。 バンド方法から信頼できるaで公開鍵とUIDを入手しなければなりません。 たぶん情報が「配線した」それに関する知識を持っていることによって、これは新しい主体を作成するユーティリティです。 アカウント作成時間に、システム・マネージャはユーザのパスワードになるものを供給しなければなりません。 ユーザがパスワードを提示して、直接入力するのを持っているか、またはある無作為のジェネレータにパスワードを選択させることによって、これをするかもしれません。
The trusted authority certificate and corresponding user public key generated by the Create_principal function are sent to the CA which verifies its contents (again by an out-of-band mechanism) and signs a corresponding certificate. The encrypted credentials, CA signed certificate, and trusted authority certificates are all placed in the naming service. The process by which the password is made known to the user must be protected by some out-of-band mechanism.
コンテンツ(再びバンドで出ているメカニズムによる)について確かめて、対応する証明書に署名するカリフォルニアにCreate_主体機能によって作られた信じられた権威証明書と対応するユーザ公開鍵を送ります。 暗号化された資格証明書、カリフォルニア署名入りの証書、および信じられた権威証明書は名前付けサービスにすべて置かれます。 何らかのバンドで出ているメカニズムでパスワードがユーザに明らかにされるプロセスを保護しなければなりません。
In some cases the principal may wish to generate its own key, and not use the Encrypted_Credentials. (e.g., if the Principal is represented by a Smart Card). This may be done using a procedure similar to the
いくつかの場合、校長は、使用ではなく、それ自身のキーがEncrypted_Credentialsであると生成したがっているかもしれません。 (例えば、プリンシパルがSmart Cardが代理をされるなら。) された使用しているa手順が同様であったなら、これはそうするかもしれません。
Kaufman [Page 102] RFC 1507 DASS September 1993
コーフマン[102ページ]RFC1507ダス1993年9月
one for creating a new CA.
新しいカリフォルニアを作成するためのもの。
A.3 Creating a Server Principal
サーバ元本を創造するA.3
A server also has a public/private key pair. Conceptually, the same procedure used to create a user principal can be used to create a server. In practice, the most important difference is likely to be how the password is protected when installing it on a server compared to giving it to a user.
また、サーバには、公衆/秘密鍵組があります。 概念的に、サーバを作成するのにユーザ元本を創造するのに用いられた同じ手順は用いることができます。それをユーザに与えると比べて、サーバにそれをインストールするとき、実際には、最も重要な違いはパスワードがどのように保護されるかということである傾向があります。
A server may wish to retrieve (and store) its Encrypted Credentials directly and never have them placed in the naming service. In this case some other mechanism can be used (e.g., passing the floppy disk containing the encrypted credentials to the server). This would require a variant of the Initialize_Server routine which does not fetch the Encrypted Credentials from the naming service.
サーバは、直接(そして、店)Encrypted Credentialsを検索して、彼らを名前付けサービスに決して置くかもしれなくて頂きたくはありません。 この場合、ある他のメカニズムを使用できます(例えば、暗号化された資格証明書をサーバに含むフロッピーディスクを渡します)。 これは名前付けサービスからEncrypted Credentialsをとって来ないInitialize_Serverルーチンの異形を必要とするでしょう。
A.4 Booting a Server Principal
サーバ元本をブートするA.4
When the server first boots it needs its name (unreliably) and password (reliably). It then calls Initialize_Server to obtain its credentials and trusted authority certificates (which it will later need in order to authenticate users). These credentials never time out, and are expected to be saved for a long time. In particular the associated Incoming Timestamp List must be preserved while there are any timestamps on it. It is desirable to preserve the Cached Incoming Contexts as long as there are any contexts likely to be reused.
サーバが最初にいつそれをブートするかがその名前(当てにならずに)とパスワード(確かである)を必要とします。 それは、次に、資格証明書を得るためにInitialize_Serverと呼んで、権威証明書(それが後でユーザを認証するために必要とする)を信じました。 これらの資格証明書、決してどんなタイムアウト、も長い間保存されるのは予想されません。 それに関するどんなタイムスタンプもある間、特に、関連Incoming Timestamp Listを保存しなければなりません。 再利用されそうなどんな文脈もある限り、Cached Incoming Contextsを保存するのは望ましいです。
If a server wants to initiate associations on its own behalf then it must call Generate_Server_Ticket. It must repeat this at intervals if the expiration period expires.
サーバがそれ自身に代わって協会を開始したいと思うなら、それは呼び出しGenerate_Server_Ticketがそうしなければなりません。 間隔を置いて、満了の期間が期限が切れるなら、それはこれを繰り返さなければなりません。
A node that wishes to do node authentication (or which acts as a server under its own name) must be created as a server.
サーバとしてノード認証(どれがサーバとしてそれ自身の名前の下で機能する)をしたがっているノードを作成しなければなりません。
A.5 A user logs on to the network
ユーザがネットワークにログオンするA.5
The system that the user logs onto finds the user's name and password. It then calls Network_Login to obtain credentials for the user. These credentials are saved until the user wants to make a network connection. The credentials have a time limit, so the user will have to obtain new credentials in order to make connections after the time limit. The credentials are then checked by calling Verify_Principal_Name, in order to check that the key specified in the encrypted credentials has been certified by the CA.
ユーザがログオンするシステムはユーザの名前とパスワードに当たります。 そして、それは、資格証明書をユーザに得るためにNetwork_Loginと呼びます。 ユーザがネットワーク接続を作りたがっているまで、これらの資格証明書は保存されます。 資格証明書にはタイムリミットがあるので、ユーザはタイムリミットの後に接続を作るために新しい資格証明書を得なければならないでしょう。 次に、Verify_をプリンシパル_Nameと呼ぶことによって、資格証明書はチェックされます、暗号化された資格証明書で指定されたキーがカリフォルニアによって公認されたのをチェックするために。
If the system does source node authentication it will call Combine_credentials, once the local username has been found. (This
システムがそれが呼ぶソースノード認証にCombine_資格証明書をするなら、一度、ローカルのユーザ名は見つけられたことがあります。 (これ
Kaufman [Page 103] RFC 1507 DASS September 1993
コーフマン[103ページ]RFC1507ダス1993年9月
can either be found by looking the principal's global name up in a file, or the user can be asked to give the local name directly. Alternatively the user can be asked to give his local username, which the system looks up to find the global name).
ファイルで主体のグローバル名を調べることによって見つけられるか、または直接地方名を与えることができますユーザに頼むことができる。 あるいはまた、ユーザによる地元のユーザ名と尋ねることができる、)。(システムは、グローバル名を見つけるためにユーザ名を調べます)。
A.6 An Rlogin (TCP/IP) connection is made
Rlogin(TCP/IP)接続が作られているA.6
When the user calls a modified version of the rlogin utility, it calls Create_token in order to create the Initial Authentication Token, which is passed to the other system as part of the rlogin protocol. The rlogind utility at the destination node calls Accept_token to verify it. It then looks up in a local rhosts-like database to determine whether this global user is allowed access to the requested destination account. It calls Verify_principal_name and/or Verify_node_name to confirm the identity of the requester. If access is allowed, the connection is accepted and the Mutual Authentication Token is returned in the response message.
それは、Initial Authentication Tokenを作成するためにCreate_トークンとユーザがrloginユーティリティの変更されたバージョンを呼ぶとき、どれがrloginプロトコルの一部としてもう片方のシステムに通過されるかと呼びます。 目的地ノードのrlogindユーティリティは、それについて確かめるためにAccept_トークンと呼びます。 そして、それは、要求された目的地アカウントへのアクセスがこのグローバルなユーザに許されているかどうか決定するためにローカルのrhostsのようなデータベースを調べます。 それは、主体_名前にVerify_を呼ぶ、そして/または、確認するVerify_ノード_名をリクエスタのアイデンティティと呼びます。 アクセスを許すなら、接続を受け入れます、そして、応答メッセージでMutual Authentication Tokenを返します。
The source receives the returned Mutual Authentication Token and uses it to confirm it communicating with the correct destination node.
情報筋は、正しい目的地ノードで交信しながらそれを確認するのに返されたMutual Authentication Tokenを受け取って、それを使用します。
Rlogind then calls Combine_credentials to combine its node/account information with the global user identification in the received credentials in case the user accesses any network resources from the destination system.
そして、Rlogindは、ユーザが目的地システムからどんなネットワーク資源にもアクセスするといけないので容認された資格証明書におけるグローバルなユーザ登録名にノード/会計情報を結合するためにCombine_資格証明書と呼びます。
A.7 A Transport-Independent Connection
A.7は輸送から独立している接続です。
As an alternative to the description in A.6, an application wishing to be portable between different underlying transports may call create_token to create an authentication token which it then sends to its peer. The peer can then call accept_token and verify_principal_name and learn the identity of the requester.
A.6の記述、異なった基本的な輸送の間で携帯用になりたがっているアプリケーションに代わる手段として、呼び出しが、次にそれが同輩に送る認証トークンを作成するために_トークンを作成しますように。 同輩が学ぶことができて、次に、呼び出しは、_トークンを受け入れて、_主体_名前について確かめて、リクエスタのアイデンティティを学びます。
Annex B
別館B
Support of the GSSAPI
GSSAPIのサポート
In order to support applications which need to be portable across a variety of underlying security mechanisms, a "Generic Security Service API" (or GSSAPI) was designed which gives access to a common core of security services expected to be provided by several mechanisms. The GSSAPI was designed with DASS, Kerberos V4, and Kerberos V5 in mind, and could be written as a front end to any or all of those systems. It is hoped that it could serve as an interface to other security systems as well.
さまざまな基本的なセキュリティー対策の向こう側に携帯用である必要があるアプリケーションをサポートするために、数個のメカニズムによって提供されると予想されたセキュリティー・サービスの一般的なコアへのアクセスを与える「ジェネリックセキュリティー・サービスAPI」(または、GSSAPI)は設計されました。GSSAPIをダス、ケルベロスV4、およびケルベロスV5で念頭に設計して、フロントエンドとしてそれらのシステムのいずれかすべてに書くことができました。それがインタフェースとしてまた、他のセキュリティシステムに機能できたことが望まれています。
Application portability requires that the security services supported
移植性が必要とするセキュリティー・サービスがサポートしたアプリケーション
Kaufman [Page 104] RFC 1507 DASS September 1993
コーフマン[104ページ]RFC1507ダス1993年9月
be comparable. Applications using the GSSAPI will not be able to access all of the features of the underlying security mechanisms. For example, the GSSAPI does not allow access to the "node authentication" features of DASS. To the extent the underlying security mechanisms do not support all the features of GSSAPI, applications using those features will not be portable to those security mechanisms. For example, Kerberos V4 does not support delegation, so applications using that feature of the GSSAPI will not be portable to Kerberos V4.
匹敵してください。 GSSAPIを使用するアプリケーションは基本的なセキュリティー対策の特徴のすべてにアクセスできないでしょう。例えば、GSSAPIはダスの「ノード認証」の特徴へのアクセスを許しません。 それらの特徴を使用するアプリケーションが基本的なセキュリティー対策がGSSAPIのすべての特徴をサポートするというわけではないという範囲に、それらのセキュリティー対策に携帯用にならないでしょう。例えば、ケルベロスV4は委譲をサポートしません、したがって、GSSAPIのその特徴を使用するアプリケーションがケルベロスV4に携帯用にならないでしょう。
This annex explains how the GSSAPI can be implemented using the primitive services provided by DASS.
この別館で、ダスによって提供された原始のサービスを利用することでどうGSSAPIを実装することができるかがわかります。
B.1 Summary of GSSAPI
GSSAPIのB.1概要
The latest draft of the GSSAPI specification is available as an internet draft. The following is a brief summary of that evolving document and should not be taken as definitive. Included here are only those aspects of GSSAPI whose implementation would be DASS specific.
GSSAPI仕様の最新の草稿はインターネット草稿として利用可能です。 以下をその発展ドキュメントの簡潔な概要であり、決定的であるとしてみなすべきではありません。 ここに含まれているのは、実装がダス特有であるGSSAPIのそれらの局面だけです。
The GSSAPI provides four classes of functions: Credential Management, Context-Level Calls, Per-message calls, and Support Calls; two types of objects: Credentials and Contexts; and two kinds of data structures to be transmitted as opaque byte strings: Tokens and Messages. Credentials hold keys and support information used in creating tokens. Contexts hold keys and support information used in signing and encrypting messages.
GSSAPIは4つのクラスの関数を提供します: 資格証明Management、Context-レベルCalls、Per-メッセージ呼び出し、およびSupport Calls。 2つのタイプのオブジェクト: 資格証明書と文脈。 そして、不透明なバイトとして伝えられるべきデータ構造の2種類は以下を結びます。 トークンとメッセージ。 資格証明書は、キーとサポート情報がトークンを作成する際に使用されるままにします。 文脈は、キーとサポート情報がメッセージに署名して、暗号化する際に使用されるままにします。
The Credential Management functions of GSSAPI are "incomplete" in the sense that one could not build a useful security implementation using only GSSAPI. Functions which create credentials based on passwords or smart cards are needed but not provided by GSSAPI. It is envisioned that such functions would be invoked by security mechanism specific functions at user login or via some separate utility rather than from within applications intended to be portable. The Credential Management functions available to portable applications are:
GSSAPIのCredential Management機能は人がGSSAPIだけを使用することで役に立つセキュリティ実装を築き上げることができないだろうという意味で「不完全です」。 パスワードかスマートカードに基づく資格証明書を作成する機能が、GSSAPIによって必要ですが、提供されません。 携帯用であることは、セキュリティー対策具体的な機能によってユーザログインで呼び出されるだろうか、またはアプリケーションからというよりむしろ何らかの別々のユーティリティで意図する思い描かれたそんなにそのような機能です。 携帯用のアプリケーションに利用可能なCredential Management機能は以下の通りです。
- GSS_Acquire_cred: get a handle to an existing credential
structure based on a name or process default.
- GSS_は_信用を取得します: 名前に基づく既存の資格証明構造かプロセスデフォルトにハンドルを手に入れてください。
- GSS_Release_cred: release credentials after use.
- GSS_リリース_信用: 使用の後に資格証明書をリリースしてください。
The Context-Level Calls use credentials to establish contexts. Contexts are like connections: they are created in pairs and are generally used at the two ends of a connection to process messages associated with that connection. The Context-Level Calls of interest
Context平らなCallsは、文脈を証明するのに資格証明書を使用します。 文脈は接続に似ています: それらは、組で作成されて、一般に、接続の2つの終わりにその接続に関連しているメッセージを処理するのに使用されます。 興味があるContext平らなCalls
Kaufman [Page 105] RFC 1507 DASS September 1993
コーフマン[105ページ]RFC1507ダス1993年9月
are:
あります:
- GSS_Init_sec_context: given credentials and the name of a
destination, create a new context and a token which will
permit the destination to create a corresponding context.
- GSS_イニット_秒_文脈: 目的地の資格証明書と名前を考えて、目的地が対応する文脈を作成することを許可する新しい関係とトークンを作成してください。
- GSS_Accept_sec_context: given credentials and an incoming
token, create a context corresponding to the one at the
initiating end and provide information identifying the
initiator.
- GSS_は_秒_文脈を受け入れます: 資格証明書と入って来るトークンを考えて、開始終わりのものに対応する文脈を作成してください、そして、創始者を特定する情報を提供してください。
- GSS_Delete_sec_context: delete a context after use.
- GSS_は_秒_文脈を削除します: 使用の後に文脈を削除してください。
The Per-Message Calls use contexts to sign, verify, encrypt, and decrypt messages between the holders of matching contexts. The Per- Message Calls are:
Per-メッセージCallsは、合っている文脈の所有者の間のメッセージに署名して、確かめて、暗号化して、解読するのに文脈を使用します。 PerメッセージCallsは以下の通りです。
- GSS_Sign: Given a context and a message, produces a string of
bytes which constitute a signature on a provided message.
- GSS_サイン: 提供されたメッセージに文脈とメッセージを与えて、署名を構成する一連のバイトを生産します。
- GSS_Verify: Given a context, a message, and the bytes
returned by GSS_Sign, verifies the message to be authentic
(unaltered since it was signed by the corresponding context).
- GSS_は以下について確かめます。 文脈を考えて、メッセージ、およびGSS_Signによって返されたバイトは正統になるメッセージ(それが対応する文脈によって署名されたので、非変更した)について確かめます。
- GSS_Seal: Given a context and a message, produces a string of
bytes which include the message and a signature; the message
may optionally be encrypted.
- GSS_シール: 文脈とメッセージを与えて、メッセージと署名を含んでいる一連のバイトを生産します。 メッセージは任意に暗号化されるかもしれません。
- GSS_Unseal: Given a context and the string of bytes from
GSS_Seal, returns the original message and a status indicating
its authenticity.
- GSS_は開かれます: GSS_Sealからのバイト、リターンの文脈とストリングにオリジナルのメッセージを与えて、状態表示に信憑性を与えます。
The Support Calls provide utilities like translating names and status codes into printable strings.
Support Callsは名前とステータスコードを印刷可能なストリングに翻訳するようなユーティリティを提供します。
B.2 Implementation of GSSAPI over DASS
ダスの上のGSSAPIのB.2実装
B.2.1 Data Structures
B.2.1データ構造
The objects and data structures of the GSSAPI do not map neatly into the objects and data structures of the DASS architecture.
GSSAPIのオブジェクトとデータ構造はダスアーキテクチャのオブジェクトとデータ構造にどんな地図もきちんと翻訳しません。
This section describes how those data structures can be implemented using the DASS data structures and primitives
ダスデータ構造を使用して、基関数であるとどうそれらのデータ構造を実装することができるかをこのセクションは説明します。
Credential handles correspond to the credentials structures in DASS, where the portable API assumes that the credential structures themselves are kept from applications and handles are passed to and
そして資格証明ハンドルがダスの資格証明書構造に対応している。(そこでは、携帯用のAPIが資格証明構造自体がアプリケーションから妨げられて、ハンドルに移られると仮定します)。
Kaufman [Page 106] RFC 1507 DASS September 1993
コーフマン[106ページ]RFC1507ダス1993年9月
from the various subroutines.
様々なサブルーチンから。
Context initialization tokens correspond to the tokens of DASS. The GSSAPI prescribes a particular ASN.1 encoded form for tokens which includes a mechanism specific bit string within it. An implementation of GSSAPI should enclose the DASS token within the GSSAPI "wrapper".
文脈初期化トークンはダスのトークンに対応しています。 GSSAPIはトークンのためのそれの中にメカニズムの特定のビット列を含んでいる特定のASN.1のコード化されたフォームを定めます。 GSSAPIの実装はGSSAPI「ラッパー」の中にダストークンを同封するべきです。
Context handles have no corresponding structure in DASS. The Create_token and Accept_token calls of DASS return a shared key and instance identifier. An implementation of the GSSAPI must take those values along with some other status information and package it as a "context" opaque structure. These data structures must be allocated and freed with the appropriate calls.
文脈ハンドルはダスにどんな対応する構造も持っていません。 ダスのCreate_象徴とAccept_象徴呼び出しは共有されたキーと例の識別子を返します。 GSSAPIの実現は、ある他の状態情報と共にそれらの値を取って、「文脈」不明瞭な構造としてそれをパッケージしなければなりません。 適切な呼び出しでこれらのデータ構造を割り当てられて、解放しなければなりません。
Per-message tokens and sealed messages have no corresponding data structure within DASS. To fully support the GSSAPI functionality, DASS must be extended to include this functionality. These data structures are created by cryptographic routines given the keys and status information in context structures and the messages passed to them. While not properly part of the DASS architecture, the formats of these data structures are included in section C.3.
1メッセージあたりの象徴と密封されたメッセージはダスの中にどんな対応するデータ構造も持っていません。 GSSAPIの機能性を完全に支持するなら、この機能性を含むようにダスを広げなければなりません。 文脈構造のキーと状態情報とそれらに通過されたメッセージを考えて、これらのデータ構造は暗号のルーチンで作成されます。 ダス構造の一部、これらのデータ構造の形式はセクションC.3に適切でなく含まれていますが。
B.2.2 Procedures
B.2.2手順
This section explains how the functions of the GSSAPI can be provided in terms of the Services Provided by DASS. Not all of the DASS features are accessible through the GSSAPI.
このセクションはダスがServices Providedに関してどうGSSAPIの機能を提供できるかを説明します。 ダスの特徴のすべてがGSSAPIを通してアクセスしやすいというわけではありません。
B.2.2.1 GSS_Acquire_cred
B.2.2.1GSS_は_信用を取得します。
The GSSAPI does not provide a mechanism for logging in users or establishing server credentials. It assumes that some system specific mechanism created those credentials and that applications need some mechanism for getting at them. A model implementation might save all credentials in a node-global pool indexed by some sort of credential name. The credentials in the pool would be access controlled by some local policy which is not concern of portable applications. Those applications would simply call GSS_Acquire_cred and if they passed the access control check, they would get a handle to the credentials which could be used in subsequent calls.
GSSAPIはユーザにログインするか、またはサーバ信任状を確立するのにメカニズムを提供しません。 それは、何らかのシステムの特定のメカニズムがそれらの信任状を作成して、アプリケーションがそれらに達するのに何らかのメカニズムを必要とすると仮定します。 モデル実現はある種の信任している名前によって索引をつけられたノードグローバルなプールの中のすべての信任状を保存するかもしれません。 プールの中の信任状は携帯用のアプリケーションの関心でない何らかのローカルの方針で制御されたアクセスでしょう。 それらのアプリケーションは、単にGSS_をAcquire_信用と呼ぶでしょう、そして、彼らがアクセス管理チェックを通過するなら、その後の呼び出しに使用できた信任状にハンドルを手に入れるでしょうに。
B.2.2.2 GSS_Release_cred
B.2.2.2GSS_リリース_信用
This call corresponds to the "delete_credentials" call of DASS.
この呼び出しは「_信任状を削除してください」というダスの呼び出しに対応しています。
Kaufman [Page 107] RFC 1507 DASS September 1993
コーフマン[107ページ]RFC1507ダス1993年9月
B.2.2.3 GSS_Init_sec_context
B.2.2.3GSS_イニット_秒_文脈
In the course of a normal mutual authentication, this routine will be called twice. The procedure can determine whether this is the first or second call by seeing whether the "input_context_handle" is zero (it will be on the first call). On the first call, it will use the DASS Create_token service to create a token and it will also allocate and populate a "context" structure. That structure will hold the key, instance identifier, and mutual authentication token returned by Create_token and will in addition hold the flags which were passed into the Init_sec_context call. The token returned by Init_sec_context will be the DASS token included in the GSSAPI token "wrapper". The DASS token will include the optional principal name.
通常の互いの認証の間に、このルーチンは二度呼ばれるでしょう。 手順は、「入力_文脈_ハンドル」がゼロ(準備ラッパにはそれがある)であるかどうかわかることによって、これが1番目かそれとも2番目の電話することであるかを決定できます。 準備ラッパのときに、象徴を作成するのにダスのCreate_象徴サービスを利用して、また、それは、「文脈」構造を割り当てて、居住するでしょう。 その構造は、Create_象徴によって返されたキー、例の識別子、および互いの認証象徴を保持して、さらに、Init_秒_文脈呼び出しに渡された旗を保持するでしょう。 Init_秒_文脈によって返された象徴はGSSAPI象徴「包装紙」に含まれていたダス象徴になるでしょう。 ダス象徴は任意の主要な名前を含むでしょう。
If mutual authentication is not requested in the GSSAPI call, the mutual authentication token returned by DASS will be ignored and the initial call will return a COMPLETE status. If mutual authentication is requested, the mutual authentication token will be stored in the context information and a CONTINUE_NEEDED status returned.
互いの認証がGSSAPI呼び出しで要求されないと、ダスによって返された互いの認証象徴は無視されるでしょう、そして、初期の呼び出しはCOMPLETE状態を返すでしょう。 互いの認証が要求されると、互いの認証象徴は文脈情報と必要な状態が返したCONTINUE_に格納されるでしょう。
On the second call to GSS_Init_sec_context (with input_context_handle non-zero), the returned token will be compared to the one in the context information using the Compare_mutual_token procedure and a COMPLETE status will be returned if they match.
GSS_Init_秒_文脈(入力_文脈_ハンドルが非ゼロに合わせている)への2番目の呼び出しのときに、返された象徴はCompareの_の互いの_象徴手順を用いることで文脈情報のものと比較されるでしょう、そして、彼らが合っていると、COMPLETE状態は返されるでしょう。
B.2.2.4 GSS_Accept_sec_context
B.2.2.4GSS_は_秒_文脈を受け入れます。
This routine in GSSAPI accepts an incoming token and creates a context. It combines the effects of a series of DASS functions. It could be implemented as follows:
GSSAPIのこのルーチンは、入って来る象徴を受け入れて、文脈を作成します。 それは一連のダスの機能の効果を結合します。 以下の通りそれを実行できました:
- Remove the GSSAPI "wrapper" from the incoming token and pass
the rest and the credentials to "Accept_token". Accept_token
produces a mutual authentication token and a new credentials
structure. If delegation was requested, the new credentials
structure will be an output of GSS_Accept_sec_context. In any
case, it will be used in the subsequent steps of this
procedure.
- 入って来る象徴からGSSAPI「包装紙」を取り除いてください、そして、残りと信任状を通過して、「_象徴を受け入れてください」。 _互いの認証象徴とa新しい信任状が構造化する象徴生産物を受け入れてください。 代表団が要求されたなら、新しい信任状構造はGSS_Accept_秒_文脈の出力になるでしょう。 どのような場合でも、それはこの手順のその後のステップで使用されるでしょう。
- Use the DASS Get_principal_name function to extract the
principal name from the credentials produced by Accept_token.
This name is one of the outputs of "GSS_Accept_sec_context.
- 機能というダスGet_校長_名を使用して、Accept_象徴によって製作された信任状から主要な名前を抜粋してください。 この名前は「GSS_は_秒_文脈を受け入れる」出力の1つです。
- Apply the DASS Verify_principal_name to the new credentials
and the retrieved name to authenticate the token as having
come from the named principal.
- ダスVerify_校長_名を新しい信任状と検索された名前に適用して、命名された校長から来たと象徴を認証してください。
- Create and populate a context structure with the key and
- そしてキーで文脈構造を作成して、居住してください。
Kaufman [Page 108] RFC 1507 DASS September 1993
コーフマン[108ページ]RFC1507ダス1993年9月
timestamp returned by Accept_token and a status of COMPLETE.
Return a handle to that context.
タイムスタンプはAccept_象徴とCOMPLETEの状態のそばで戻りました。 その文脈にハンドルを返してください。
- If delegation was requested, return the new credentials from
GSS_Accept_sec_context. Otherwise, call Delete_credentials.
- 代表団が要求されたなら、GSS_Accept_秒_文脈から新しい信任状を返してください。 さもなければ、Delete_信任状に電話をしてください。
- If mutual authentication was requested, wrap the mutual
authentication token from Accept_token in a GSSAPI "wrapper"
and return it. Otherwise return a null string.
- 互いの認証が要求されたなら、GSSAPI「包装紙」でAccept_象徴から互いの認証象徴を包装してください、そして、それを返してください。 さもなければ、ヌルストリングを返してください。
B.2.2.5 GSS_Delete_sec_context
B.2.2.5GSS_は_秒_文脈を削除します。
This routine simply deletes the context state. No calls to DASS are required.
このルーチンは単に文脈状態を削除します。 ダスへの呼び出しは全く必要ではありません。
B.2.2.6 GSS_Sign
B.2.2.6GSS_サイン
This routine takes as input a context handle and a message. It creates a per_msg_token by computing a digital signature on the message using the key and timestamp in the context block. No DASS services are required. If additional cryptographic services were requested (replay detection or sequencing), a timestamp or sequence number must be prepended to the message and sent with the signature. The syntax for this message is listed in section C.3.
文脈ハンドルとメッセージを入力するとき、このルーチンは取ります。 それは、メッセージで文脈ブロックのキーとタイムスタンプを使用することでデジタル署名を計算することによって、_msg_象徴あたりのaを作成します。 ダスのサービスは全く必要ではありません。 追加暗号のサービスを要求したなら(検出か配列を再演してください)、タイムスタンプか一連番号をメッセージにprependedして、署名と共に送らなければなりません。 このメッセージのための構文はセクションC.3で記載されています。
B.2.2.7 GSS_Verify
_が確かめるB.2.2.7GSS
This routine repeats the calculation of the sign routine and verifies the signature provided. If replay detection or sequencing services are provided, the context must maintain as part of its state information containing the sequence numbers or timestamps of messages already received and this one must be checked for acceptability.
このルーチンは、サインルーチンの計算を繰り返して、提供された署名について確かめます。 再生検出か配列サービスを提供するなら、文脈は、州の情報の一部として受容性がないかどうか既に受け取られたメッセージとこの一連番号かタイムスタンプを含むのをチェックしなければならないと主張しなければなりません。
B.2.2.8 GSS_Seal
B.2.2.8GSS_シール
This routine performs the same functions as Sign but also optionally encrypts the message for privacy using the shared key and encapsulates the whole thing in a GSSAPI specified ASN.1 wrapper.
このルーチンは、Signと同じ機能を実行しますが、任意に、共有を使用するのが合わせて、要約するプライバシーとして、GSSAPIの全体のものがASN.1包装紙を指定したというメッセージをまたコード化します。
B.2.2.9 GSS_Unseal
B.2.2.9GSS_は開かれます。
This routine performs the same functions as GSS_Verify but also parses the data structure including the signature and message and decrypts the message if necessary.
このルーチンは、GSS_Verifyと同じ機能を実行しますが、署名とメッセージを含むデータ構造を分析して、必要なら、メッセージをまた解読します。
Kaufman [Page 109] RFC 1507 DASS September 1993
コーフマン[109ページ]RFC1507ダス1993年9月
B.3 Syntax
B.3構文
The GSSAPI specification recommends the following ASN.1 encoding for the tokens and messages generated through the GSSAPI:
GSSAPI仕様はGSSAPIを通して発生する象徴とメッセージのために以下をコード化する以下のASN.1を推薦します。
--optional top-level token definitions to frame
-- different mechanisms
--縁どる任意のトップレベル象徴定義--異なったメカニズム
GSSAPI DEFINITIONS ::=
BEGIN
GSSAPI定義:、:= 始まってください。
MechType ::= OBJECT IDENTIFIER
-- data structure definitions
ContextToken ::=
-- option indication (delegation, etc.) indicated
-- within mechanism-specific token
[APPLICATION 0] IMPLICIT SEQUENCE {
thisMech MechType,
responseExpected BOOLEAN,
innerContextToken ANY DEFINED BY MechType
-- contents mechanism-specific
}
MechType:、:= OBJECT IDENTIFIER--データ構造定義ContextToken:、:= -- メカニズム特有の象徴[APPLICATION0]IMPLICIT SEQUENCEの中の指示(代表団など)が示したオプションthisMech MechTypeの、そして、responseExpectedブールのinnerContextToken、どんなDEFINED BY MechTypeも--、コンテンツメカニズム詳細
PerMsgToken ::=
-- as emitted by GSS_Sign and processed by
-- GSS_Verify
[APPLICATION 1] IMPLICIT SEQUENCE {
thisMech MechType,
innerMsgToken ANY DEFINED BY MechType
-- contents mechanism-specific
}
SealedMessage ::=
-- as emitted by GSS_Seal and processed by
-- GSS_Unseal
[APPLICATION 2] IMPLICIT SEQUENCE {
sealingToken PERMSGTOKEN,
confFlag BOOLEAN,
userData OCTET STRING
-- encrypted if confFlag TRUE
}
PerMsgToken:、:= -- GSS_Signによって放たれていて、処理されるように--GSS_Verify[APPLICATION1]IMPLICIT SEQUENCE、thisMech MechType、innerMsgToken、どんなDEFINED BY MechTypeも--、コンテンツメカニズム詳細、SealedMessage:、:= -- GSS_Sealによって放たれていて、処理されるように--GSS_Unseal[APPLICATION2]IMPLICIT SEQUENCEsealingToken PERMSGTOKENで、confFlagブール、userData OCTET STRING--confFlag TRUEであるなら、コード化されます。
The object identifier for the DASS MechType is 1.3.12.2.1011.7.5.
ダスMechTypeのための物の識別子はそうです。1.3 .12 .2 .1011 .7 .5。
The innerContextToken of a token is a DASS token or mutual authentication token.
象徴のinnerContextTokenはダス象徴か互いの認証象徴です。
The innerMsgToken is a null string in the case where the message is encrypted and the token is included as part of a SealedMessage.
innerMsgTokenはメッセージがコード化されていて、象徴がSealedMessageの一部として含まれている場合でヌルストリングです。
Kaufman [Page 110] RFC 1507 DASS September 1993
コーフマン[110ページ]RFC1507ダス1993年9月
Otherwise, it is an eight octet sequence computed as the CBC residue computed using a key and string of bytes defined as follows:
さもなければ、それはCBCの残りが以下の通り定義されたバイトのキーとストリングを使用することで計算されたように計算された8八重奏系列です:
- Pad the message provided by the application with 1-8 bytes of
pad to produce a string whose length is a multiple of 8
octets. Each pad byte has a value equal to the number of pad
bytes.
- 長さが8つの八重奏の倍数であるストリングを作り出すためにアプリケーションで1-8 バイトのパッドに提供されたメッセージを水増ししてください。 それぞれのパッドバイトには、パッドバイトの数と等しい値があります。
- Compute the key by taking the timestamp of the association
(two four byte integers laid out in big endian order with the
most significant integer first), complementing the high order
bit (to avoid aliasing with mutual authenticators), and
encrypting the block in ECB mode with the shared key of the
association.
- 協会(最初にビッグエンディアンオーダーで最も重要な整数で広げられた4バイトの2つの整数)に関するタイムスタンプを取ることによって、キーを計算してください、高位のビット(互いの固有識別文字でエイリアシングを避ける)の補足となって、協会の共有されたキーでECBモードによるブロックをコード化して。
The userData field of a SealedMessage is exactly the application provided byte string if confFlag=FALSE. Otherwise, it is the application supplied message encrypted as follows:
confFlag=FALSEであるなら、SealedMessageのuserData分野はまさにアプリケーションの提供されたバイトストリングです。 さもなければ、それは以下の通りコード化されたアプリケーションの供給されたメッセージです:
- Pad the message provided by the application with 1-8 bytes of
pad to produce a string whose length = 4 (mod 8). Each pad
byte has a value equal to the number of pad bytes.
- 長さのストリング=4(モッズ風の8)を生産するためにアプリケーションで1-8 バイトのパッドに提供されたメッセージを水増ししてください。 それぞれのパッドバイトには、パッドバイトの数と等しい値があります。
- Append a four byte CRC32 computed over the message + pad.
- メッセージ+パッドの上に計算された4バイトのCRC32を追加してください。
- Compute a key by taking the timestamp of the association (two
four byte integers laid out in big endian order with the most
significant integer first), complementing the high order bit
(to avoid aliasing with mutual authenticators), and encrypting
the block in ECB mode with the shared key of the association.
- 協会(最初にビッグエンディアンオーダーで最も重要な整数で広げられた4バイトの2つの整数)に関するタイムスタンプを取ることによって、キーを計算してください、高位のビット(互いの固有識別文字でエイリアシングを避ける)の補足となって、協会の共有されたキーでECBモードによるブロックをコード化して。
- Encrypt the message + pad + CRC32 using CBC and the key
computed in the previous step.
- 前のステップで計算されたCBCとキーを使用して、+ メッセージ+パッドCRC32をコード化してください。
A note of the logic behind the above:
上記の後ろの論理の注意:
- Because the shared key of an association may be reused by many
associations between the same pair of principals, it is
necessary to bind the association timestamp into the messages
somehow to prevent messages from a previous association being
replayed into a new sequence. The technique above of
generating an association key accomplishes this and has a side
benefit. An implementation may with to keep the long term
keys out of the hands of applications for purposes of
confinement but may wish to put the encryption associated with
an association in process context for reasons of performance.
Defining an association key makes that possible.
- 協会の共有されたキーが同じ組の校長の間の多くの協会によって再利用されるかもしれないので、新しい系列に再演される前の協会からメッセージを防ぐためにどうにか協会タイムスタンプをメッセージに縛るのが必要です。 協会キーを発生させることにおける上のテクニックは、これを達成して、役得を持っています。 実現がそうするかもしれない、性能の理由で関係に関連している暗号化を過程文脈に入れることを願うかもしれないのを除いて、監禁の目的のためにアプリケーションの手から長期キーであることを保つために。 協会キーを定義するのに、それは可能になります。
Kaufman [Page 111] RFC 1507 DASS September 1993
コーフマン[111ページ]RFC1507ダス1993年9月
- The reason that the association specific key is not specified
as the output of Create_token and Accept_token is that the DCE
RPC security implementation requires that a series of
associations between two principals always have the same key
and we did not want to have to support a different interface
in that application.
- 協会の特定のキーがCreate_象徴とAccept_象徴の出力として指定されない理由はDCE RPCセキュリティ実現が、2人の校長の間の一連の協会には同じキーがいつもあって、私たちが、そのアプリケーションにおける異なったインタフェースを支持しなければならなくて欲しいと思わなかったのを必要とするということです。
- The CRC32 after pad constitutes a cheap integrity check when
data is encrypted.
- The fact that padding is done differently for encrypted and
signed messages means that there are no threats related to
sending the same message encrypted and unencrypted and using
the last block of the encrypted message as a signature on the
unencrypted one.
- パッドが卑しい保全を構成した後にCRC32は、データがいつコード化されているかをチェックします。 - コード化されてサインされたメッセージのために異なって詰め物をするという事実は、コード化されて、非コード化されて、署名として非コード化されたもので暗号化メッセージの最後のブロックを使用することで同じメッセージを送ると関連する脅威が全くないことを意味します。
Annex C
別館C
Imported ASN.1 definitions
輸入されたASN.1定義
This annex contains extracts from the ASN.1 description of X.509 and X.500 definitions referenced by the DASS ASN.1 definitions.
この別館はDASS ASN.1定義で参照をつけられるX.509とX.500定義のASN.1記述からの抽出を含んでいます。
CCITT DEFINITIONS ::=
CCITT定義:、:=
BEGIN joint-iso-ccitt OBJECT IDENTIFIER ::= {2} ds
OBJECT IDENTIFIER ::= {joint-iso-ccitt 5} algorithm
OBJECT IDENTIFIER ::= {ds 8}
BEGINの共同iso-ccitt OBJECT IDENTIFIER:、:= 2ds OBJECT IDENTIFIER:、:= 共同iso-ccitt5アルゴリズムOBJECT IDENTIFIER:、:= ds8
iso OBJECT IDENTIFIER ::= {1} identified-
organization OBJECT IDENTIFIER ::= {iso 3} ecma OBJECT
IDENTIFIER ::= {identified-organization 12} digital
OBJECT IDENTIFIER ::= { ecma 1011 }
iso OBJECT IDENTIFIER:、:= 1 組織OBJECT IDENTIFIERは特定しました:、:= iso3ecma OBJECT IDENTIFIER:、:= 特定された組織12、デジタルOBJECT IDENTIFIER:、:= ecma1011
-- X.501 definitions
-- X.501定義
AttributeType ::= OBJECT IDENTIFIER AttributeValue ::= ANY
-- useful ones are
-- OCTET STRING ,
-- PrintableString ,
-- NumericString ,
-- T61String ,
-- VisibleString
AttributeType:、:= 識別子AttributeValueは反対します:、:= いずれ--役に立つものは--OCTET STRING--PrintableString(NumericString)T61Stringです--、VisibleString
AttributeValueAssertion ::= SEQUENCE {AttributeType,
AttributeValue}
AttributeValueAssertion:、:= 系列AttributeType、AttributeValue
Name ::= CHOICE {-- only one possibility for now --
RDNSequence}
以下を命名してください:= 選択--当分間の1つの可能性だけ--RDNSequence
Kaufman [Page 112] RFC 1507 DASS September 1993
コーフマン[112ページ]RFC1507ダス1993年9月
RDNSequence ::= SEQUENCE OF RelativeDistinguishedName DistinguishedName ::= RDNSequence
RDNSequence:、:= RelativeDistinguishedName DistinguishedNameの系列:、:= RDNSequence
RelativeDistinguishedName ::= SET OF AttributeValueAssertion
RelativeDistinguishedName:、:= AttributeValueAssertionのセット
-- X.509 definitions
-- X.509定義
Certificate ::= SIGNED SEQUENCE {
version [0] Version DEFAULT 1988 ,
serialNumber SerialNumber ,
signature AlgorithmIdentifier ,
issuer Name,
valid Validity,
subject Name,
subjectPublicKey SubjectPublicKeyInfo }
以下を証明してください:= サインされた系列バージョン[0] バージョンDEFAULT1988、serialNumber SerialNumber、署名AlgorithmIdentifier、発行人Name(有効なValidity)はNameをかけます、subjectPublicKey SubjectPublicKeyInfo
Version ::= INTEGER { 1988(0)} SerialNumber ::= INTEGER Validity
::= SEQUENCE{
notBefore UTCTime,
notAfter UTCTime}
バージョン:、:= 整数1988(0)、SerialNumber:、:= 整数の正当性:、:= 系列notBefore UTCTime、notAfter UTCTime
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier ,
subjectPublicKey BIT STRING
}
SubjectPublicKeyInfo:、:= 系列アルゴリズムAlgorithmIdentifier、subjectPublicKey BIT STRING
AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER ,
parameters ANY DEFINED BY algorithm OPTIONAL}
AlgorithmIdentifier:、:= 系列アルゴリズムOBJECT IDENTIFIER、パラメタANY DEFINED BYアルゴリズムOPTIONAL
ALGORITHM MACRO BEGIN TYPE NOTATION ::= "PARAMETER" type VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) END -- of ALGORITHM
アルゴリズムマクロはタイプ記法を始めます:、:= "PARAMETER"はVALUE NOTATIONをタイプします:、:= ALGORITHMの値(VALUE OBJECT IDENTIFIER)のEND
ENCRYPTED MACRO BEGIN TYPE NOTATION ::=type(ToBeEnciphered) VALUE
NOTATION ::= value(VALUE BIT STRING)
-- the value of the bit string is generated by
-- taking the octets which form the complete
-- encoding (using the ASN.1 Basic Encoding Rules)
-- of the value of the ToBeEnciphered type and
-- applying an encipherment procedure to those octets-- END
コード化されたマクロはタイプ記法を始めます:、:=(ToBeEnciphered)値の記法をタイプしてください:、:= コード化することによって(完全を形成する八重奏を取ります)ビット列の値が発生するという(ASN.1Basic Encoding Rulesを使用して)ToBeEncipheredタイプと--暗号文手順をそれらの八重奏に適用します--ENDの価値の値(VALUE BIT STRING)
SIGNED MACRO ::= BEGIN TYPE NOTATION ::= type (ToBeSigned) VALUE
NOTATION ::= value(VALUE SEQUENCE{
ToBeSigned,
AlgorithIdentifier, -- of the algorithm used to generate
-- the signature
ENCRYPTED OCTET STRING
-- where the octet string is the result
サインされたマクロ:、:= タイプ記法を始めてください:、:= (ToBeSigned)VALUE NOTATIONをタイプしてください:、:= 値、(VALUE SEQUENCE、ToBeSigned、八重奏ストリングが結果である発生するのにおいて中古のアルゴリズムのAlgorithIdentifier(署名ENCRYPTED OCTET STRING)
Kaufman [Page 113] RFC 1507 DASS September 1993
コーフマン[113ページ]RFC1507ダス1993年9月
-- of the hashing of the value of "ToBeSigned" END -- of
SIGNED
-- "ToBeSigned"END、SIGNEDの価値を論じ尽くすのについて
SIGNATURE MACRO ::= BEGIN TYPE NOTATION ::= type(OfSignature) VALUE
NOTATION ::= value(VALUE
SEQUENCE{
AlgorithmIdentifier,
-- of the algorithm used to compute the signature
ENCRYPTED OCTET STRING
-- where the octet string is a function (e.g., a
-- compressed or hashed version) of the value
-- "OfSignature", which may include the identifier
-- of the algorithm used to compute
-- the signature--}
) END -- of SIGNATURE
署名マクロ:、:= タイプ記法を始めてください:、:= (OfSignature)値の記法をタイプしてください:、:= SIGNATUREの値(八重奏ストリングがアルゴリズムの価値識別子を含むかもしれない"OfSignature"の関数(例えば、a--圧縮されたか論じ尽くされたバージョン)である署名ENCRYPTED OCTET STRINGを計算するのに使用されるアルゴリズムのAlgorithmIdentifierが以前はよく計算していた(署名)VALUE SEQUENCE)のEND
-- X.509 Annex H (not part of the standard)
-- X.509別館H(規格の一部でない)
encryptionAlgorithm OBJECT IDENTIFIER ::= {algorithm 1} rsa ALGORITHM
PARAMETER KeySize
::= {encryptionAlgorithm 1}
encryptionAlgorithmオブジェクト識別子:、:= アルゴリズム1rsa ALGORITHM PARAMETER KeySize:、:= encryptionAlgorithm1
KeySize ::= INTEGER
KeySize:、:= 整数
END
終わり
Glossary
用語集
authentication
The process of determining the identity
(usually the name) of the other party in some communication
exchange.
認証、何らかのコミュニケーション交換における、相手のアイデンティティ(通常名前)を決定するプロセス。
authentication context
Cached information used during a particular instance of
authentication and including a shared symmetric (DES) key as
well as components of the authentication token conveyed
during establishment of this context.
この文脈の確立の間に伝えられた認証トークンのコンポーネントと同様に認証の特定のインスタンスの間、使用されて、共有された左右対称の(DES)キーを含む認証文脈Cached情報。
authentication token
Information conveyed during a strong authentication exchange
that can be used to authenticate its sender. An
authentication token can, but is not necessarily limited to,
include the claimant identity and ticket, as well as signed
and encrypted secret key exchange messages conveying a
secret key to be used in future cryptographic operations. An
送付者を認証するのに使用できる強い認証交換の間に伝えられた認証トークン情報。 認証トークン缶だけ、必ず有限であるというわけではないことで、主張者のアイデンティティとチケットを含めてください、今後の暗号の操作に使用されるために秘密鍵を運ぶ署名していて暗号化された秘密鍵交換メッセージと同様に。 1
Kaufman [Page 114] RFC 1507 DASS September 1993
コーフマン[114ページ]RFC1507ダス1993年9月
authentication token names a particular protocol data
structure component.
認証トークンは特定のプロトコルデータ構造コンポーネントを命名します。
authorization
The process of determining the rights
associated with a particular principal.
権利を決定するプロセスが特定の元本に関連づけた承認。
certificate
The public key of a particular principal, together
with some other information relating to the names of the
principal and the certifying authority, rendered unforgeable
by encipherment with the private key of the certification
authority that issued it.
それを発行した証明権威の秘密鍵がある暗号文によるレンダリングされた非鍛造可能という主体と公認権威の名前に関連するある他の情報と共に特定の元本の公開鍵を証明してください。
certification authority
An authority trusted by one or more principals to create and
assign certificates.
証明書を作成して、割り当てると1人以上の校長によって信じられた証明権威An権威。
claimant
The party that initiates the authentication process.
In the DASS architecture, claimants possess credentials
which include their identity, authenticating private key and
a ticket certifying their authenticating public key.
主張者、認証過程を開始するパーティー。 ダスアーキテクチャでは、主張者は彼らのアイデンティティを含んでいる資格証明書を持っています、彼らが公開鍵を認証するのを公認する秘密鍵とチケットを認証して。
credentials
Information "state" required by principals in order
to for them to authenticate. Credentials may contain
information used to initiate the authentication process
(claimant information), information used to respond to an
authentication request (verifier information), and cached
information useful in improving performance.
「状態」という資格証明書情報が、校長が、認証するのに必要です。 資格証明書は、認証過程を開始するのに使用される情報(主張者情報)、認証要求に応じるのに使用される情報(検証情報)を含んだかもしれなくて、性能を向上させる際に役に立つ情報をキャッシュしました。
cryptographic checksum
Information which is derived by performing a cryptographic
transformation on the data unit. This information can be
used by the receiver to verify the authenticity of data
passed in cleartext
暗号の変換をデータ単位に実行することによって引き出される暗号のチェックサム情報。 この情報は受信機によって使用されて、cleartextで通過されたデータの信憑性について確かめることができます。
decipher
To reverse the effects of encipherment and render a
message comprehensible by use of a cryptographic key.
暗号文の解読Toは暗号文の効果を逆にして、暗号化キーの使用でメッセージを分かりやすく伝えます。
delegation
The granting of temporary credentials that allow a
process to act on behalf of a principal.
委譲、プロセスが元本を代表して行動する一時的な資格証明書を与えること。
Kaufman [Page 115] RFC 1507 DASS September 1993
コーフマン[115ページ]RFC1507ダス1993年9月
delegation key
A short term public/private key pair used by a claimant
to act on behalf of a principal for a bounded period. The
delegation public key appears in the ticket, whereas the
delegation private key is used to sign secret key exchange
messages.
境界がある期間の元本を代表して行動するのに主張者によって使用された委譲の主要なA短期間公衆/秘密鍵組。 委譲公開鍵はチケットの中に現れますが、委譲秘密鍵は、秘密鍵交換がメッセージであると署名するのに使用されます。
DES
Data Encryption Standard: a symmetric (secret key)
encryption algorithm used by DASS. An alternate encryption
algorithm could be substituted with little or no disruption
to the architecture.
DESデータ暗号化規格: ダスによって使用された左右対称の(秘密鍵)暗号化アルゴリズム。 アーキテクチャの分裂でまず代替の暗号化アルゴリズムを代入できませんでした。
DES key
A 56-bit secret quantity used as a parameter to the
DES encryption algorithm.
パラメタとしてDES暗号化アルゴリズムに使用されるDESの主要なA56ビットの秘密の量。
digital signature
A value computed from a block of data
and a key which could only be computed by someone knowing
the key. A digital signature computed with a secret key can
only be verified by someone knowing that secret key. A
digital signature computed with a private key can be
verified by anyone knowing the corresponding public key.
デジタル署名A価値はキーを知っているだれかが計算できただけである1ブロックのデータとキーから計算されました。 その秘密鍵を知っているだれかが秘密鍵で計算されたデジタル署名について確かめることができるだけです。 対応する公開鍵を知っているだれでも秘密鍵で計算されたデジタル署名について確かめることができます。
encipher
To render incomprehensible except to the holder of a
particular key. If you encipher with a secret key, only the
holder of the same secret can decipher the message. If you
encipher with a public key, only the holder of the
corresponding private key can decipher it.
Toを暗号化してください。特定のキーの所有者を除いて、不可解にします。 あなたが秘密でキーを暗号化するなら、同じ秘密の所有者だけがメッセージを解読できます。 あなたが公開鍵、対応する秘密鍵缶の暗号文の解読の所有者だけをもってそれを暗号化するなら。
initial trust certificate
A certificate signed by a principal for its own use which
states the name and public key of a trusted authority.
初期の信託証券A証明書は信じられた権威の名前と公開鍵を述べるそれ自身の使用のために元本で署名しました。
global user name
A hierarchical name for a user which is
unique within the entire domain of discussion (typically the
network).
グローバルなユーザは議論(通常ネットワーク)の全体のドメインの中でユーザのためのユニークな階層的な名前とAを命名します。
local user name
A simple (non-hierarchical) name by
which a user is known within a limited context such as on a
single computer.
ユーザが単一のコンピュータなどの限られた文脈の中で知られているローカルのユーザ名Aの簡単な(非階層的な)名前。
Kaufman [Page 116] RFC 1507 DASS September 1993
コーフマン[116ページ]RFC1507ダス1993年9月
principal
Abstract entity which can be authenticated by name.
In DASS there are user principals and server principals.
名前で認証できる主要な抽象的な実体。 ダスに、ユーザ主体とサーバ主体があります。
private key
Cryptographic key used in asymmetric (public key)
cryptography to decrypt and/or sign messages. In asymmetric
cryptography, knowing the encryption key is independent of
knowing the decryption key. The decryption (or signing)
private key cannot be derived from the encrypting (or
verifying) public key.
秘密鍵Cryptographicキーは、メッセージに解読する、そして/または、署名するのに非対称の(公開鍵)に暗号を使用しました。 非対称の暗号では、暗号化キーを知っているのは復号化キーを知るのから独立しています。 暗号化(または、検証)公開鍵から復号化(または、署名する)秘密鍵を得ることができません。
proxy
A mapping from an external name to a local account
name for purposes of establishing a set of local access
rights. Note that this differs from the definition in ECMA
TR/46.
1セットの地方のアクセス権を確立する目的のための外部名からローカルのアカウント名までのプロキシAマッピング。 これがECMA TR/46との定義と異なっていることに注意してください。
public key
Cryptographic key used in asymmetric cryptography to
encrypt messages and/or verify signatures.
公開鍵Cryptographicキーは、メッセージを暗号化する、そして/または、署名について確かめるのに非対称で暗号を使用しました。
RSA
The Rivest-Shamir-Adelman public key cryptosystem
based on modular exponentiation where the modulus is the
product of two large primes. When the term RSA key is used,
it should be clear from context whether the public key, the
private key, or the public/private pair is intended.
Rivestシャミル・エーデルマン公開鍵暗号方式が係数が大きい2盛りの製品であるところでモジュールの羃法を基礎づけたRSA。 主要であるという用語RSAが使用されているとき、公開鍵、秘密鍵、または公共の、または、私設の組が意図するかどうかが、文脈から明確であるはずです。
secret key
Cryptographic key used in symmetric cryptography to
encrypt, sign, decrypt and verify messages. In symmetric
cryptography, knowledge of the decryption key implies
knowledge of the encryption key, and vice-versa.
秘密鍵Cryptographicキーは、メッセージに暗号化して、署名して、解読して、確かめるのに左右対称で暗号を使用しました。 左右対称の暗号では、復号化キーに関する知識は暗号化キーに関する知識を含意します、そして、逆もまた同様です。
sign
A process which takes a piece of data and a key and
produces a digital signature which can only be calculated by
someone with the key. The holder of a corresponding key can
verify the signature.
Aが1つのデータとキーを取って、キーでだれかが計算できるだけであるデジタル署名を起こすプロセスであると署名してください。 対応するキーの所有者は署名について確かめることができます。
source
The initiator of an authentication exchange.
認証の創始者が交換するソース。
strong authentication
Authentication by means of cryptographically derived
authentication tokens and credentials. The actual working
definition is closer to that of "zero knowledge" proof:
暗号で派生している認証トークンと資格証明書による強い認証Authentication。 実際の仮の定義が「知識がありません」証拠のものの、より近くにあります:
Kaufman [Page 117] RFC 1507 DASS September 1993
コーフマン[117ページ]RFC1507ダス1993年9月
authentication so as to not reveal any information usable by
either the verifier, or by an eavesdropping third party, to
further their potential ability to impersonate the claimant.
認証、検証、または盗聴第三者は、主張者をまねる彼らの潜在能力を促進するためにどんな情報も使用可能であることを明らかにしません。
target
The intended second party (other than the source) to
an authentication exchange.
認証交換への2番目の意図しているパーティー(ソースを除いた)を狙ってください。
ticket
A data structure certifying an authenticating
(public) key by virtue of being signed by a user principal
using their (long term) private key. The ticket also
includes the UID of the principal.
ユーザ元本によってそれらの(長期)秘密鍵を使用することで署名されることによって認証(公共の)キーを公認するチケットAデータ構造。 また、チケットは主体のUIDを含んでいます。
trusted authority
The public key, name and UID of a
certification authority trusted in some context to certify
the public keys of other principals.
証明権威の信じられた権威の公開鍵、名前、およびUIDは、他の主体の公開鍵を公認するために何らかの文脈を信じました。
UID
A 128 bit unique identifier produced according to OSF
standard specifications.
UID A128はOSFの標準の仕様通りに作り出されたユニークな識別子に噛み付きました。
user key
A "long term" RSA key whose private portion
authenticates its holder as having the access rights of a
particular person.
個人的な部分が特定の人のアクセス権を持っていると所有者を認証するユーザの主要なA「長期」RSAキー。
verify
To cryptographically process a piece of data and a
digital signature to determine that the holder of a
particular key signed the data.
Toについて確かめてください。暗号で1つのデータとデジタル署名を処理して、特定のキーの所有者がデータに署名したことを決定してください。
verifier
The party who will perform the operations necessary
to verify the claimed identity of a claimant.
検証、主張者の要求されたアイデンティティについて確かめるのに必要な操作を実行するパーティー。
Kaufman [Page 118] RFC 1507 DASS September 1993
コーフマン[118ページ]RFC1507ダス1993年9月
Security Considerations
セキュリティ問題
Security issues are discussed throughout this memo.
このメモ中で安全保障問題について議論します。
Author's Address
作者のアドレス
Charles Kaufman Digital Equipment Corporation ZKO3-3/U14 110 Spit Brook Road Nashua, NH 03062
チャールズコーフマンDEC ZKO3-3/U14 110はブルック・Roadナッシュア、ニューハンプシャー 03062に痰唾を吐きました。
Phone: (603) 881-1495 Email: kaufman@zk3.dec.com
以下に電話をしてください。 (603) 881-1495 メールしてください: kaufman@zk3.dec.com
General comments on this document should be sent to cat-ietf@mit.edu. Minor corrections should be sent to the author.
このドキュメントの概評を cat-ietf@mit.edu に送るべきです。 小さい方の修正を作者に送るべきです。
Kaufman [Page 119]
コーフマン[119ページ]
一覧
スポンサーリンク
