[要約] RFC 3157は、セキュアに利用可能な資格情報の要件についての規格です。その目的は、資格情報の安全な管理と共有を確保するためのガイドラインを提供することです。
Network Working Group A. Arsenault
Request for Comments: 3157 Diversinet
Category: Informational S. Farrell
Baltimore Technologies
August 2001
Securely Available Credentials - Requirements
安全に利用可能な資格情報 - 要件
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
Abstract
概要
This document describes requirements to be placed on Securely Available Credentials (SACRED) protocols.
このドキュメントでは、安全に利用可能な資格情報（神聖な）プロトコルに配置される要件について説明します。
Table Of Contents
目次
1. Introduction.................................................1
2. Framework Requirements.......................................4
3. Protocol Requirements........................................7
4. Security Considerations.....................................10
References.....................................................12
Acknowledgements...............................................12
Authors' Addresses.............................................13
Appendix A: A note on SACRED vs. hardware support..............14
Appendix B: Additional Use Cases...............................14
Full Copyright Statement.......................................20
"Credentials" are information that can be used to establish the identity of an entity, or help that entity communicate securely. Credentials include such things as private keys, trusted roots, tickets, or the private part of a Personal Security Environment (PSE) [RFC2510] - that is, information used in secure communication on the Internet. Credentials are used to support various Internet protocols, e.g., S/MIME, IPSec and TLS.
「資格情報」とは、エンティティのアイデンティティを確立するために使用できる情報、またはそのエンティティが安全にコミュニケーションをとるのを支援できる情報です。資格には、プライベートキー、信頼できるルーツ、チケット、または個人セキュリティ環境（PSE）[RFC2510]のプライベート部分など、インターネット上の安全な通信で使用される情報などが含まれます。資格情報は、S/MIME、IPSEC、TLSなど、さまざまなインターネットプロトコルをサポートするために使用されます。
In simple models, users and other entities (e.g., computers like routers) are provided with credentials, and these credentials stay in one place. However, the number, and more importantly the number of different types, of devices that can be used to access the Internet is increasing. It is now possible to access Internet services and accounts using desktop computers, laptop computers, wireless phones, pagers, personal digital assistants (PDAs) and other types of devices. Further, many users want to access private information and secure services from a number of different devices, and want access to the same information from any device. Similarly credentials may have to be moved between routers when they are upgraded.
単純なモデルでは、ユーザーやその他のエンティティ（例：ルーターのようなコンピューター）に資格情報が提供されており、これらの資格情報は1か所に留まります。ただし、インターネットへのアクセスに使用できるデバイスの数、さらに重要なことには、さまざまなタイプの数が増加しています。現在、デスクトップコンピューター、ラップトップコンピューター、ワイヤレス電話、ページャー、パーソナルデジタルアシスタント（PDA）、およびその他のタイプのデバイスを使用して、インターネットサービスとアカウントにアクセスできるようになりました。さらに、多くのユーザーは、多くの異なるデバイスから個人情報にアクセスし、サービスを保護したいと考えており、あらゆるデバイスから同じ情報にアクセスしたいと考えています。同様に、資格情報をアップグレードしたときにルーター間で移動する必要がある場合があります。
This document identifies a set of requirements for credential mobility. The Working Group will also produce companion documents, which describe a framework for secure credential mobility, and a set of protocols for accomplishing this goal.
このドキュメントは、資格のモビリティに関する一連の要件を識別します。ワーキンググループは、セキュアな資格モビリティのフレームワークと、この目標を達成するための一連のプロトコルを説明するコンパニオンドキュメントも作成します。
The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in [RFC2119].
このドキュメントの「必須」、「必須」、「必須」、「必要」、「推奨」、および「5月」は、[RFC2119]で説明されているように解釈されます。
In simple models of Internet use, users and other entities are provided with credentials, and these credentials stay in one place. For example, Mimi generates a public and private key on her desktop computer, provides the public key to a Certification Authority (CA) to be included in a certificate, and keeps the private key on her computer. It never has to be moved.
インターネット使用の単純なモデルでは、ユーザーや他のエンティティに資格情報が提供されており、これらの資格情報は1か所に留まります。たとえば、MIMIはデスクトップコンピューターで公開キーと秘密鍵を生成し、公開キーを認証機関（CA）に提供して証明書に含め、コンピューターに秘密鍵を維持します。移動する必要はありません。
However, Mimi may want to able to send signed e-mail messages from her desktop computer when she is in the office, and from her laptop computer when she is on the road, and she does not want message recipients to know the difference. In order to do this, she must somehow make her private key available on both devices - that is, that credential must be moved.
ただし、Mimiは、オフィスにいるときはデスクトップコンピューターから、および彼女が道路にいるときはラップトップコンピューターから署名された電子メールメッセージを送信したい場合があり、メッセージ受信者に違いを知りたくありません。これを行うには、彼女は何らかの形で両方のデバイスで秘密鍵を利用できるようにしなければなりません。つまり、その資格情報を移動する必要があります。
Similarly, Will may want to retrieve and read encrypted e-mail from either his wireless phone or from his two-way pager. He wants to use whichever device he has with him at the moment, and does not want to be denied access to his mail or to be unable to decrypt important messages simply because he has the wrong device. Thus, he must be able to have the same private key available on both devices.
同様に、Willは、彼のワイヤレス電話または双方向のページのいずれかから暗号化された電子メールを取得して読み取ることをお勧めします。彼は現在、彼と一緒に持っているデバイスを使用したいと考えており、彼のメールへのアクセスを拒否されたり、間違ったデバイスを持っているという理由だけで重要なメッセージを解読したりすることができないようにしたいと考えています。したがって、彼は両方のデバイスで同じ秘密鍵を利用できるようにすることができなければなりません。
The following scenario relating to routers has also been offered: "Once upon a time, a router generated a keypair. The administrators transferred the public key of that router to a lot of other (peer) routers and used that router to encrypt traffic to the other routers. And this was good for many years. Then one day, the network administrators found that this particular little router couldn't handle an OC-192. So they trashed it and replaced it with a really big router. While they were there, the craft workers inserted a smart card into the router and logged into the router. They gave the appropriate commands and entered the correct answers and so the credentials (keypair) were transferred to the new, big router. Alternatively, the craft people could have logged into the router, given it a minimal configuration and transferred the credentials from a credential server to the router. They had to perform the correct incantations and authentications for the transfer to be successful. In this way, the identity of the router was moved from an old router to a new one. The administrators were glad that they didn't have to edit the configurations of all of the peer routers as well."
ルーターに関連する以下のシナリオも提供されています。「昔々、ルーターがキーペアを生成しました。管理者はそのルーターの公開鍵を他の多くの（ピア）ルーターに転送し、そのルーターを使用してトラフィックを使用してトラフィックを暗号化しました。他のルーター。そしてこれは長年にわたって良かった。それからある日、ネットワーク管理者は、この特定の小さなルーターがOC-192を処理できないことを発見した。だから彼らはそれをゴミ箱に捨てて、本当に大きなルーターに置き換えた。、クラフトワーカーはスマートカードをルーターに挿入し、ルーターにログインしました。彼らは適切なコマンドを与え、正しい答えを入力したので、資格情報（キーピーア）が新しい大きなルーターに転送されました。最小限の構成を考慮してルーターにログインし、資格情報を資格情報サーバーからルーターに転送しました。転送を成功させるには、正しい呪文と認証を実行する必要がありました。このようにして、ルーターのアイデンティティは移動しました。新しいルーターへの古いルーター。管理者は、すべてのピアルーターの構成も編集する必要がないことを喜んでいた。」
It is generally accepted that the private key in these examples must be transferred securely. In the first example, the private key should not be exposed to anyone other than Mimi herself (and ideally, it would not be directly exposed to her). Furthermore, it must be transferred correctly. It must be transferred to the proper device, and it must not be corrupted - improperly modified - during transfer.
これらの例の秘密鍵を安全に転送する必要があることは一般に受け入れられています。最初の例では、秘密鍵をミミ自身以外の人にさらされるべきではありません（そして、理想的には、それは彼女に直接さらされることはありません）。さらに、正しく転送する必要があります。それは適切なデバイスに転送する必要があり、転送中に破損してはならない - 不適切に変更してはなりません。
Making credentials securely available (in an interoperable fashion) will provide substantial value to network owners, administrators, and end users. The intent is that this value be provided largely independent of the hardware device used to access the secure credential and the type of storage medium to which the secure credential is written. Different credential storage devices, (e.g., desktop or laptop PC computer memory, a 3.5 inch flexible diskette, a hard disk file, a cell phone, a smart card, etc.) will have very different security characteristics and, often very different protocol handling capabilities. Using SACRED protocols, users will be able to securely move their credentials between different locations, different Internet devices, and different storage media as needed.
（相互運用可能な方法で）安全に利用可能な資格情報を作成すると、ネットワークの所有者、管理者、エンドユーザーにかなりの価値が提供されます。意図は、この値は、安全な資格情報と安全な資格情報が書かれているストレージ媒体のタイプにアクセスするために使用されるハードウェアデバイスと大きく独立して提供されることです。さまざまな資格ストレージデバイス（デスクトップまたはラップトップPCコンピューターメモリ、3.5インチの柔軟なディスケット、ハードディスクファイル、携帯電話、スマートカードなど）は、非常に異なるセキュリティ特性と、しばしば非常に異なるプロトコルハンドリングを持ちます。機能。神聖なプロトコルを使用して、ユーザーは、必要に応じて、異なる場所、異なるインターネットデバイス、異なるストレージメディア間で資格情報を安全に移動できます。
In the remainder of this document we present a set of requirements for the secure transfer of software-based credentials.
このドキュメントの残りの部分では、ソフトウェアベースの資格情報の安全な転送に関する一連の要件を提示します。
The SACRED Working Group is working on the standardization of a set of protocols for securely transferring credentials among devices. A general framework is being developed that will give an abstract definition of protocols which can meet the credential-transfer requirements. This framework will allow for the development of a set of protocols, which may vary from one another in some respects. Specific protocols that conform to the framework can then be developed.
神聖なワーキンググループは、デバイス間で資格情報を安全に転送するための一連のプロトコルの標準化に取り組んでいます。資格輸送要件を満たすことができるプロトコルの抽象的な定義を提供する一般的なフレームワークが開発されています。このフレームワークにより、一連のプロトコルの開発が可能になります。これは、いくつかの点で互いに異なる場合があります。その後、フレームワークに準拠する特定のプロトコルを開発できます。
Work is being done on a number of documents. This document identifies the requirements for the general framework, as well as the requirements for specific protocols. Another document will describe the protocol framework. Still others will define the protocols themselves.
多くのドキュメントで作業が行われています。このドキュメントは、一般的なフレームワークの要件と、特定のプロトコルの要件を特定します。別のドキュメントでは、プロトコルフレームワークについて説明します。さらに他の人は、プロトコル自体を定義します。
Section 1 of this document provides an introduction to the problem being solved by this working group. Section 2 describes requirements on the framework. Section 3 identifies the overall requirements for secure credential-transfer protocols, and separate requirements for two different classes of solutions. Section 4 identifies Security Considerations. Appendix A describes the relationship of the SACRED solutions and credential-mobility solutions involving hardware components such as smart cards. Appendix B contains some additional scenarios which were considered when developing the requirements.
このドキュメントのセクション1では、このワーキンググループが解決する問題の紹介を提供します。セクション2では、フレームワークの要件について説明します。セクション3では、安全な資格輸送プロトコルの全体的な要件と、2つの異なるクラスのソリューションの個別の要件を特定します。セクション4では、セキュリティ上の考慮事項を特定します。付録Aでは、Smart Cardsなどのハードウェアコンポーネントを含む神聖なソリューションと資格型モビリティソリューションの関係について説明しています。付録Bには、要件を開発する際に考慮されたいくつかの追加のシナリオが含まれています。
This section describes requirements that the SACRED framework has to meet, as opposed to requirements that are to be met by a specific protocol that uses the framework.
このセクションでは、フレームワークを使用する特定のプロトコルによって満たされる要件とは対照的に、神聖な枠組みが満たさなければならない要件について説明します。
There are at least two different ways to solve the problem of secure credential transfer between devices. One class of solutions uses a "credential server" as an intermediate node, and the other class provides direct transfer between devices.
デバイス間の安全な資格転送の問題を解決するには、少なくとも2つの異なる方法があります。1つのクラスのソリューションは、「資格的サーバー」を中間ノードとして使用し、もう1つのクラスはデバイス間の直接転送を提供します。
A "credential server" can be likened to a server that sits in front of a repository where credentials can be securely stored for later retrieval. The credential server is active in the protocol, that is, it implements security enforcing functionality.
「資格的サーバー」は、後で検索するために資格情報を安全に保存できるリポジトリの前にあるサーバーに例えることができます。資格的サーバーはプロトコルでアクティブです。つまり、セキュリティを実施する機能を実装します。
To transfer credentials securely from one end device to another is a straightforward two-step process. Users can have their credentials securely "uploaded" from one device, e.g., a wireless phone, to the credential server. They can be stored on the credential server, and "downloaded" when needed using another device; e.g., a two-way pager.
資格情報を一方のエンドデバイスから別のデバイスに安全に転送することは、簡単な2段階のプロセスです。ユーザーは、資格情報を1つのデバイスから、たとえばワイヤレス電話である資格情報サーバーに安全に「アップロード」することができます。資格情報サーバーに保存し、必要に応じて別のデバイスを使用して「ダウンロード」できます。たとえば、双方向のページャー。
Some advantages of a credential server approach compared to credential transfer are: 1. It provides a conceptually clean and straightforward approach. For all end devices, there is one protocol, with a set of actions defined to transfer credentials from the device to the server, and another set of actions defined to transfer credentials from the server to the device. Furthermore, this protocol involves clients (the devices) and a server (the credential server), like many other Internet protocols; thus, the design of this protocol is likely to be familiar to most people familiar with most other Internet protocols.
資格的サーバーアプローチのいくつかの利点は、資格情報の転送と比較して次のとおりです。1。概念的にクリーンで簡単なアプローチを提供します。すべてのエンドデバイスには、1つのプロトコルがあり、デバイスからサーバーに資格情報を転送するために定義された一連のアクションと、サーバーからデバイスに資格情報を転送するために定義された別のアクションセットがあります。さらに、このプロトコルには、他の多くのインターネットプロトコルと同様に、クライアント（デバイス）とサーバー（資格サーバー）が含まれます。したがって、このプロトコルの設計は、他のほとんどのインターネットプロトコルに精通しているほとんどの人に馴染みがある可能性があります。
2. It provides for a place where credentials can be securely stored for arbitrary lengths of time. Given a reasonable-quality server operating under generally accepted practices, it is unlikely the credentials will be permanently lost due to a hardware failure. This contrasts with systems where credentials are only stored on end devices, in which a failure of or the loss of the device could mean that the credentials are lost forever.
2. 資格情報を任意の時間のためにしっかりと保存できる場所を提供します。一般に受け入れられているプラクティスの下で動作する合理的な品質のサーバーを考えると、ハードウェアの障害により資格情報が永久に失われる可能性は低いです。これは、資格情報がエンドデバイスにのみ保存されているシステムとは対照的であり、デバイスの障害または損失が資格情報が永久に失われることを意味する可能性があります。
3. The credential server may be able to enforce a uniform security policy regarding credential handling. This is particularly the case where credentials are issued by an organization for its own purposes, and are not "created" by the end user, and so must be governed by the policies of the issuer, not the user.
3. 資格的サーバーは、資格情報の取り扱いに関する均一なセキュリティポリシーを実施できる場合があります。これは特に、資格情報が独自の目的のために組織によって発行され、エンドユーザーによって「作成」されていないため、ユーザーではなく発行者のポリシーによって統治される必要があります。
However, the credential server approach has some potential disadvantages, too:
ただし、資格的サーバーアプローチには、いくつかの潜在的な欠点もあります。
1. It might be somewhat expensive to maintain and run the credential server, particularly if there are stringent requirements on availability and reliability of the server. This is particularly true for servers which are used for a large community of users. When the credential server is intended for a small community, the complexity and cost would be much less.
1. 特にサーバーの可用性と信頼性に関する厳格な要件がある場合、資格的サーバーを維持および実行するのはやや費用がかかる可能性があります。これは、ユーザーの大規模なコミュニティに使用されるサーバーに特に当てはまります。資格的サーバーが小さなコミュニティを対象としている場合、複雑さとコストははるかに少なくなります。
2. The credential server may have to be "trusted" in some sense and also introduces a point of potential vulnerability. (See the Security Considerations section for some of the issues.) Good protocol and system design will limit the vulnerability that exists at the credential server, but at a minimum, someone with access to the credential server will be able to delete credentials and thus deny the SACRED service to system users.
2. 資格的サーバーは、ある意味で「信頼」されなければならず、潜在的な脆弱性のポイントも導入する必要があります。（いくつかの問題については、セキュリティに関する考慮事項セクションを参照してください。）優れたプロトコルとシステム設計は、資格情報サーバーに存在する脆弱性を制限しますが、少なくとも資格情報サーバーにアクセスできる人は資格情報を削除できるため、拒否できます。システムユーザーへの神聖なサービス。
Thus, some users may prefer a different class of solution, in which credentials are transferred directly from one device to another (i.e., having no intermediary element that processes or has any understanding of the credentials).
したがって、一部のユーザーは、資格情報があるデバイスから別のデバイスに直接転送される別のクラスのソリューションを好む場合があります（つまり、資格情報を処理するか、理解している中間要素がありません）。
For example, consider the case where Mimi sends a message from her wireless phone containing the credentials in question, and retrieves it using her two-way pager. In getting from one place to another, the bits of the message cross the wireless phone network to a base station. These bits are likely transferred over the wired phone network to a message server run by the wireless phone operator, and are transferred from there over the Internet to a message server run by the paging operator. From the paging operator they are transferred to a base station and then finally to Mimi's pager. Certainly, there are devices other than the original wireless phone and ultimate pager that are involved in the credential transfer, in the sense that they transmit bits from one place to another. However, to all devices except the pager and the wireless phone, what is being transferred is an un-interpreted and unprocessed set of bits. No security-related decisions are made, and no actions are taken based on the fact that this message contains credentials, at any of the intermediate nodes. They exist simply to forward bits. Thus, we consider this to be a "direct" transfer of credentials.
たとえば、MIMIが問題の資格情報を含むワイヤレス電話からメッセージを送信し、双方向のページャーを使用してそれを取得する場合を考えてみましょう。ある場所から別の場所に到達する際に、メッセージのビットはワイヤレス電話ネットワークを越えて基地局に向かいます。これらのビットは、有線電話ネットワークを介してワイヤレス電話オペレーターが実行するメッセージサーバーに転送される可能性が高く、インターネットを介してページングオペレーターが実行するメッセージサーバーにそこを介して転送されます。ページングオペレーターから基地局に移され、最後にミミのページャーに移されます。確かに、ある場所から別の場所にビットを送信するという意味で、元のワイヤレス電話と資格の転送に関与する究極のポケットベル以外のデバイスがあります。ただし、ページャーとワイヤレス電話を除くすべてのデバイスにとって、転送されているのは、解釈されていない未処理のビットセットです。セキュリティ関連の決定は行われず、このメッセージには中間ノードのいずれかに資格情報が含まれているという事実に基づいてアクションが実行されません。それらは単にビットを転送するために存在します。したがって、これは資格情報の「直接的な」転送であると考えています。
Solutions involving the direct transfer of credentials from one device to another are potentially somewhat more complex than the credential-server approach, owing to the large number of different devices and formats that may have to be supported. Complexity is also added due to the fact that each device may in turn have to exhibit the behavior of both a client and a server.
あるデバイスから別のデバイスへの資格情報の直接転送を含むソリューションは、サポートする必要がある多数の異なるデバイスとフォーマットにより、資格情報のアプローチよりも潜在的にやや複雑です。また、各デバイスがクライアントとサーバーの両方の動作を示す必要がある可能性があるため、複雑さも追加されています。
We believe that both classes of solutions are useful in certain environments, and thus that the SACRED framework will have to define solutions for both. The extent to which elements of the above solutions overlap remains to be determined.
両方のクラスのソリューションは特定の環境で有用であり、したがって、神聖な枠組みが両方のソリューションを定義する必要があると考えています。上記のソリューションの要素がどの程度重複するかはまだ決定されていません。
This all leads to our first set of requirements:
これはすべて、最初の一連の要件につながります。
F1. The framework MUST support both "credential server" and "direct" solutions. F2. The "credential server" and "direct" solutions SHOULD use the same technology as far as possible.
F1。フレームワークは、「資格的サーバー」と「ダイレクト」ソリューションの両方をサポートする必要があります。F2。「クレデンシャルサーバー」と「ダイレクト」ソリューションは、可能な限り同じテクノロジーを使用する必要があります。
There is a wide range of deployment options for credential mobility solutions. In many of these cases, it is useful to be able to re-use an existing user authentication scheme, for example where passwords have previously been established, it may be more secure to re-use these than try to manage a whole new set of passwords. Different devices may also limit the types of user authentication scheme that are possible, e.g., not all mobile devices are practically capable of carrying out asymmetric cryptography.
資格のモビリティソリューションのための幅広い展開オプションがあります。これらのケースの多くでは、既存のユーザー認証スキームを再利用できると便利です。たとえば、パスワードが以前に確立されていた場合、まったく新しいセットのセットを管理しようとするよりも、これらを再利用する方が安全かもしれません。パスワード。また、さまざまなデバイスが可能なユーザー認証スキームの種類を制限する場合があります。たとえば、すべてのモバイルデバイスが実際に非対称暗号化を実行できるわけではありません。
F3. The framework MUST allow for protocols which support different user authentication schemes
F3。フレームワークは、さまざまなユーザー認証スキームをサポートするプロトコルを許可する必要があります
Today there is no single standard format for credentials and this is not likely to change in the near future. There are a number of fairly widely deployed formats, e.g., [PGP], [PKCS#12] that have to be supported. This means that the framework has to allow for protocols supporting any credential format.
今日、資格情報の単一の標準形式はありません。これは近い将来に変更される可能性は低いです。かなり広く展開されている形式が多数あります。たとえば、[PGP]、[PKCS＃12]をサポートする必要があります。これは、フレームワークが資格情報形式をサポートするプロトコルを許可する必要があることを意味します。
F4. The details of the actual credential type or format MUST be opaque to the protocol, though not to processing within the protocol's peers. The protocol MUST NOT depend on the internal structure of any credential type or format.
F4。プロトコルのピア内での処理ではありませんが、実際の資格のタイプまたは形式の詳細はプロトコルに不透明でなければなりません。プロトコルは、資格情報のタイプまたは形式の内部構造に依存してはなりません。
Different devices allow for different transport layer possibilities, e.g., current WAP 1.x devices do not support TCP. For this reason the framework has to be transport "agnostic".
さまざまなデバイスにより、さまざまな輸送層の可能性が可能になります。たとえば、現在のWAP 1.xデバイスはTCPをサポートしていません。このため、フレームワークは「不可知論者」を輸送する必要があります。
F5. The framework MUST allow use of different transports.
F5。フレームワークは、異なる輸送の使用を許可する必要があります。
In this section, we identify the requirements for secure credential-transfer solutions. We will begin by listing a set of relevant vulnerabilities and the requirements that must be met by all solutions. Then we identify additional requirements that must be met by solutions involving a credential server, followed by additional requirements that must be met by solutions involving direct transfer of credentials.
このセクションでは、安全な資格輸送ソリューションの要件を特定します。まず、関連する脆弱性のセットと、すべてのソリューションで満たさなければならない要件をリストすることから始めます。次に、資格情報サーバーを含むソリューションで満たされなければならない追加の要件を特定し、その後、資格情報の直接転送を含むソリューションで満たされなければならない追加要件を特定します。
This section lists the vulnerabilities against which a SACRED protocol SHOULD offer protection. Any protocol claiming to meet the requirements listed in this document MUST explicitly indicate how (or whether) it offers protection for each of these vulnerabilities.
このセクションには、神聖なプロトコルが保護を提供すべき脆弱性をリストします。このドキュメントにリストされている要件を満たすと主張するプロトコルは、これらの脆弱性のそれぞれを保護する方法（または）を明示的に示す必要があります。
V1. A passive attacker can watch all packets on the network and later carry out a dictionary attack. V2. An attacker can attempt to masquerade as a credential server in an attempt to get a client to reveal information on line that allows for a later dictionary attack.
V1。受動的な攻撃者は、ネットワーク上のすべてのパケットを視聴し、後で辞書攻撃を実行できます。V2。攻撃者は、クライアントに後の辞書攻撃を可能にする情報をオンライン上の情報を明らかにしようとするために、資格サーバーを装っていようと試みることができます。
V3. An attacker can attempt to get a client to decrypt a chosen "ciphertext" and get the client to make use of the resulting plaintext - the attacker may then be able to carry out a dictionary attack (e.g., if the plaintext resulting from "decryption" of a random string is used as a DSA private key). V4. An attacker could overwrite a repository entry so that when a user subsequently uses what they think is a good credential, they expose information about their password (and hence the "real" credential). V5. An attacker can copy a credential server's repository and carry out a dictionary attack. V6. An attacker can attempt to masquerade as a client in an attempt to get a server to reveal information that allows for a later dictionary attack. V7. An attacker can persuade a server that a successful login has occurred, even if it hasn't. V8. (Upload) An attacker can overwrite someone else's credentials on the server. V9. (When using password-based authentication) An attacker can force a password change to a known (or "weak") password. V10. An attacker can attempt a man-in-the-middle attack for lots V11. User enters password instead of name. V12. An attacker could attempt various denial-of-service attacks.
V3。攻撃者は、選択した「ciphertext」を復号化してクライアントにクライアントに結果のプレーンテキストを使用させようとすることができます。攻撃者は辞書攻撃を実行できる場合があります（たとえば、「復号化」に起因する平文の場合は、ランダムな文字列のDSA秘密キーとして使用されます）。V4。攻撃者は、リポジトリエントリを上書きすることができ、ユーザーがその後、自分が優れた資格情報であると思うものを使用すると、パスワードに関する情報（したがって「実際の」資格情報）を公開することができます。V5。攻撃者は、資格情報サーバーのリポジトリをコピーして、辞書攻撃を実行できます。V6。攻撃者は、サーバーを取得して、後の辞書攻撃を可能にする情報を明らかにしようとするために、クライアントを装っていようと試みることができます。V7。攻撃者は、たとえそうでなくても、ログインが成功したことをサーバーに説得することができます。V8。（アップロード）攻撃者は、サーバー上の他の誰かの資格情報を上書きすることができます。V9。（パスワードベースの認証を使用する場合）攻撃者は、既知の（または「弱い」）パスワードにパスワードの変更を強制することができます。V10。攻撃者は、ロットV11の中間攻撃を試みることができます。ユーザーは名前の代わりにパスワードを入力します。V12。攻撃者は、さまざまなサービス拒否攻撃を試みることができます。
Looking again at the examples described in Section 1.1, we can readily see that there are a number of requirements that must apply to the transfer of credentials if the ultimate goal of supporting the Internet security protocols (e.g., TLS, IPSec, S/MIME) is to be met. For example, the credentials must remain confidential at all times; it is unacceptable for nodes other than the end-user's device(s) to see the credentials in any readable, cleartext form.
セクション1.1で説明した例をもう一度見ると、インターネットセキュリティプロトコル（TLS、IPSEC、S/MIMEなど）をサポートするという最終的な目標がある場合、資格の転送に適用する必要がある要件がいくつかあることがすぐにわかります。満たされることです。たとえば、資格情報は常に機密のままでなければなりません。エンドユーザーのデバイス以外のノードが読み取り可能なクリアテキストフォームの資格情報を表示することは受け入れられません。
These, then, are the requirements that apply to all secure credential-transfer solutions:
これらは、すべての安全な資格輸送ソリューションに適用される要件です。
G1. Credential transfer both to and from a device MUST be supported. G2. Credentials MUST NOT be forced by the protocol to be present in cleartext at any device other than the end user's. G3. The protocol SHOULD ensure that all transferred credentials be authenticated in some way (e.g., digitally signed or MAC-ed). G4. The protocol MUST support a range of cryptographic algorithms, including symmetric and asymmetric algorithms, hash algorithms, and MAC algorithms.
G1。デバイスとの両方からの資格転送をサポートする必要があります。G2。資格情報は、エンドユーザー以外のどのデバイスでも、プロトコルによってクリアテキストに存在することを強制してはなりません。G3。プロトコルは、転送されたすべての資格情報が何らかの方法で認証されることを保証する必要があります（例：デジタル署名またはMac-Edなど）。G4。プロトコルは、対称および非対称アルゴリズム、ハッシュアルゴリズム、MACアルゴリズムなど、さまざまな暗号化アルゴリズムをサポートする必要があります。
G5. The protocol MUST allow the use of various credential types and formats (e.g., X.509, PGP, PKCS12, ...). G6. One mandatory to support credential format MUST be defined. G7. One mandatory to support user authentication scheme MUST be defined. G8. The protocol MAY allow credentials to be labeled with a text handle, (outside the credential), to allow the end user to select amongst a set of credentials or to name a particular credential. G9. Full I18N support is REQUIRED (via UTF8 support) [RFC2277]. G10. It is desirable that the protocol be able to support privacy, that is, anonymity for the client. G11. Transferred credentials MAY incorporate timing information, for example a "time to live" value determining the maximum time for which the credential is to be usable following transfer/download.
G5。プロトコルでは、さまざまな資格情報のタイプと形式の使用を許可する必要があります（X.509、PGP、PKCS12、...など）。G6。資格情報形式をサポートするための1つの必須を定義する必要があります。G7。ユーザー認証スキームをサポートするための1つの必須を定義する必要があります。G8。このプロトコルにより、資格情報をテキストハンドル（資格情報の外側）でラベル付けすることができ、エンドユーザーが資格情報のセットから選択したり、特定の資格情報を挙げたりすることができます。G9。完全なI18Nサポートが必要です（UTF8サポートを介して）[RFC2277]。G10。プロトコルがプライバシー、つまりクライアントの匿名性をサポートできることが望ましいです。G11。転送された資格情報には、タイミング情報が組み込まれている場合があります。たとえば、「生きる時間」値が、送金/ダウンロード後に資格情報が使用できる最大時間を決定する場合があります。
The following requirements assume that there is a credential server from which credentials are downloaded to the end user device, and to which credentials are uploaded from an end user device.
以下の要件は、資格情報がエンドユーザーデバイスにダウンロードされ、エンドユーザーデバイスからアップロードされる資格情報がダウンロードされる資格情報サーバーがあることを想定しています。
S1. Credential downloads (to an end user) and upload (to the credential server) MUST be supported. S2. Credentials MUST only be downloadable following user authentication or else only downloaded in a format that requires completion of user authentication for deciphering. S3. It MUST be possible to ensure the authenticity of a credential during upload. S4. Different end user devices MAY be used to download/upload/manage the same set of credentials. S5. Credential servers SHOULD be authenticated to the user for all operations except download. Note: This requirement can be ignored if the credential format itself is strongly protected, as there is no risk (other than user confusion) from an unauthenticated credential server. S6. It SHOULD be possible to authenticate the credential server to the user as part of a download operation. S7. The user SHOULD only have to enter a single secret value in order to download and use a credential. S8. Sharing of secrets across multiple servers MAY be possible, so that penetration of some servers does not expose the private parts of a credential ("m-from-n" operation). S9. The protocol MAY support "away-from-home" operation, where the user enters both a name and a domain (e.g. RoamingStephen@baltimore.ie) and the domain can be used in order to locate the user's credential server.
S1。資格情報のダウンロード（エンドユーザーへ）とアップロード（資格的サーバーへ）をサポートする必要があります。S2。資格情報は、ユーザー認証後にのみダウンロード可能であるか、解読のためにユーザー認証の完了を必要とする形式でのみダウンロードされる必要があります。S3。アップロード中に資格情報の信頼性を確保することは可能である必要があります。S4。異なるエンドユーザーデバイスを使用して、同じセットの資格情報をダウンロード/アップロード/管理することができます。S5。資格情報サーバーは、ダウンロードを除くすべての操作に対してユーザーに認証される必要があります。注：認定されていない資格情報サーバーからのリスク（ユーザーの混乱以外）がないため、資格情報形式自体が強く保護されている場合、この要件は無視できます。S6。ダウンロード操作の一部として、資格情報サーバーをユーザーに認証することが可能です。S7。ユーザーは、資格情報をダウンロードして使用するために、単一の秘密値を入力するだけで済む必要があります。S8。複数のサーバーでの秘密の共有が可能になる場合があります。そのため、一部のサーバーの侵入は、資格情報の私的部分（「m-from-n」操作）を公開しません。S9。プロトコルは「アウェイから家から離れた」操作をサポートする場合があります。ユーザーは、ユーザーの資格的サーバーを見つけるために、ユーザーが名前とドメイン（例：roamingStephen@baltimore.ie）の両方を使用し、ドメインを使用できます。
S10. The protocol MUST provide operations allowing users to manage their credentials stored on the credential server, e.g., to retrieve a list of their credentials stored on a server; add credentials to the server; delete credentials from the server. S11. Client-initiated authentication information (e.g., password) change MUST be supported. S12. The user SHOULD be able to retrieve a list of accesses/changes to their credentials. S13. The protocol MUST support user self-enrollment. One scenario calling for this is where a previously unknown user uploads his credential without requiring manual operator intervention. S14. The protocol MUST NOT prevent bulk initializing of a credential server's repository. S15. The protocol SHOULD require minimal client configuration.
S10。プロトコルは、ユーザーがクレデンシャルサーバーに保存されている資格情報を管理できるようにする操作を提供する必要があります。たとえば、サーバーに保存されている資格情報のリストを取得する必要があります。サーバーに資格情報を追加します。サーバーから資格情報を削除します。S11。クライアント開始認証情報（パスワードなど）の変更をサポートする必要があります。S12。ユーザーは、資格情報へのアクセス/変更のリストを取得できる必要があります。S13。プロトコルは、ユーザーの自己導入をサポートする必要があります。これを要求するシナリオの1つは、以前は不明なユーザーが手動オペレーターの介入を必要とせずに資格をアップロードする場所です。S14。プロトコルは、資格情報サーバーのリポジトリのバルク初期化を防止してはなりません。S15。プロトコルには、最小限のクライアント構成が必要です。
The full set of requirements for this case has not been elucidated, and this list is therefore provisional. An additional requirements document (or a modification of this one) will be required prior to progression of a direct-transfer protocol.
このケースの完全な要件は解明されていないため、このリストは暫定的です。直接移動プロトコルの進行の前に、追加の要件ドキュメント（またはこれの変更）が必要です。
The following requirements apply to solutions supporting the "direct" transfer of credentials from one device to another. (See Section 2 for the note on the meaning of "direct" in this case.)
次の要件は、あるデバイスから別のデバイスへの資格情報の「直接」転送をサポートするソリューションに適用されます。（この場合の「直接」の意味に関するメモについては、セクション2を参照してください。）
D1. It SHOULD be possible for the receiving device to authenticate that the credential package indeed came from the purported sending device. D2. In order for a sender to know that a credential has been received by a recipient, it SHOULD be possible for the receiving device to send an acknowledgment of credential receipt back to the sending device, and for the sending device to authenticate this acknowledgment.
D1。受信デバイスが、資格情報パッケージが実際に送信デバイスから来たことを認証することが可能です。D2。送信者が受信者によって資格情報が受信されたことを知るためには、受信デバイスが資格情報の領収書の確認を送信デバイスに送り返すことができるはずです。
Mobile credentials will never be as secure as a "pure" hardware-based solution, because of potential attacks through the operating system of the end-user device. However, an acceptable level of security may be accomplished through some simple means. In fact the level of security may be improved (compared to password encrypted files) through the use of SACRED protocols.
エンドユーザーデバイスのオペレーティングシステムを介した潜在的な攻撃のため、モバイル資格情報は「純粋な」ハードウェアベースのソリューションほど安全ではありません。ただし、許容可能なレベルのセキュリティは、いくつかの簡単な手段を通じて達成される場合があります。実際、セキュリティのレベルは、神聖なプロトコルを使用して（パスワード暗号化されたファイルと比較して）改善される場合があります。
The platforms to which credentials are downloaded usually cannot be regarded as tamper-resistant, and it therefore is not too hard to analyze contents of their memories. Further, storage of private keys, even if they are encrypted, on a credential server, will be unacceptable in some environments. Lastly, replacement of installed or downloaded SACRED client software with a Trojan horse program will always be possible, such a program could email the username and password to the program's author.
クレデンシャルがダウンロードされるプラットフォームは通常、改ざん耐性と見なすことができないため、記憶の内容を分析するのはそれほど難しくありません。さらに、プライベートキーのストレージは、クレデンシャルサーバーで暗号化されていても、一部の環境では受け入れられません。最後に、インストールまたはダウンロードされたSacred ClientソフトウェアをTrojan Horseプログラムに置き換えることは常に可能です。そのようなプログラムは、ユーザー名とパスワードをプログラムの著者に電子メールで送信できます。
Although out of scope of the SACRED protocol development work, implementations should carefully audit events that may be security relevant. In particular credential server implementations should audit all operations and should include information about the time and source (e.g., IP address) of the operation, the claimed identity of the client (possibly masked - see below), the type and result of the operation and possibly other operation specific information. Implementations should also take care not to include security sensitive information in the audit trail, especially not sensitive authentication information.
神聖なプロトコル開発作業の範囲外ですが、実装はセキュリティに関連する可能性のあるイベントを慎重に監査する必要があります。特に資格情報サーバーの実装は、すべての操作を監査する必要があり、操作の時間とソース（例えば、IPアドレス）、クライアントの請求されたID（おそらくマスクされた - 以下を参照）、操作のタイプと結果、および操作の結果と結果を含める必要があります。おそらく他の操作特定の情報。また、実装は、特に機密認証情報ではなく、監査証跡にセキュリティに敏感な情報を含めないように注意する必要があります。
It may be sensible to mask the claimed identity in some way in order to ensure that even if a user enters her password in a "username" field, that that information is not in clear in the audit trail, regardless of whether or not it was received in clear.
ユーザーが「ユーザー名」フィールドでパスワードを入力したとしても、監査証跡でその情報が明確ではないことを保証するために、何らかの方法で請求された身元をマスクするのが賢明かもしれません。明確に受け取った。
Similar mechanisms which should be supported, but which are out of scope of protocol development include alerts and account locking, in particular following repeated authentication failures.
サポートする必要があるが、プロトコル開発の範囲外である同様のメカニズムには、特に繰り返される認証障害に続いて、アラートとアカウントロックが含まれます。
Credential servers are major targets. Someone who can successfully attack a credential server might be able to gain access to the credentials of a number of users, unless those credentials are sufficiently protected (e.g., encrypted sufficiently that they cannot be read or used by someone who gains access to them). Attackers might also be able to substitute credentials of users, to carry out other system attacks (e.g., an attacker could provide a user with a "trusted root" credential that the attacker controls, which would later allow the attacker to have some other certificate accepted by the user counter to policy).
資格的サーバーは主要なターゲットです。資格的サーバーを正常に攻撃できる人は、それらの資格情報が十分に保護されていない限り、多くのユーザーの資格情報にアクセスできる可能性があります（たとえば、十分に暗号化されているため、アクセスを獲得している人が読み取ったり使用したりすることができません）。攻撃者は、ユーザーの資格情報を代用して他のシステム攻撃を実行することもできます（たとえば、攻撃者は攻撃者がコントロールする「信頼できるルート」資格情報をユーザーに提供できます。ユーザーカウンターによるポリシーによる）。
In addition, a credential server is a major target for denial of service attacks. Ensuring that a credential server is unavailable to legitimate users can be of great assistance to attackers. Users who were not able to retrieve needed credentials might be forced to operate insecurely, or not operate at all. Credential servers are especially vulnerable to denial of service attacks if they do lots of expensive cryptographic operations - it might not take very many operations for the attacker to bring service to an unacceptable level.
さらに、資格的サーバーは、サービス拒否攻撃の主要なターゲットです。資格のサーバーが正当なユーザーが利用できないことを確認することは、攻撃者に大きな支援を得ることができます。必要な資格情報を取得できなかったユーザーは、不安に動作することを余儀なくされるか、まったく操作しない可能性があります。資格のサーバーは、高価な暗号化操作をたくさん行う場合、サービス拒否攻撃に対して特に脆弱です。攻撃者がサービスを容認できないレベルにするためにはそれほど多くの操作が必要ではないかもしれません。
Thus, great care should be taken in designing systems that use credential servers to protect against these attacks.
したがって、これらの攻撃から保護するために資格情報サーバーを使用するシステムを設計することには注意する必要があります。
References
参考文献
[PGP] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998.
[PGP] Callas、J.、Donnerhacke、L.、Finney、H。およびR. Thayer、「OpenPGPメッセージ形式」、RFC 2440、1998年11月。
[PKCS12] "PKCS #12 v1.0: Personal Information Exchange Syntax Standard", RSA Laboratories, June 24, 1999.
[PKCS12]「PKCS＃12 V1.0：個人情報交換構文標準」、RSA Laboratories、1999年6月24日。
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
[CMS] Housley、R。、「暗号化メッセージの構文」、RFC 2630、1999年6月。
[PKCS15] "PKCS #15 v1.1: Cryptographic Token Information Syntax Standard," RSA Laboratories, June 2000.
[PKCS15]「PKCS＃15 V1.1：暗号化トークン情報構文標準」、RSA Laboratories、2000年6月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026] Bradner、S。、「インターネット標準プロセス - リビジョン3」、BCP 9、RFC 2026、1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2277] Alvestrand, H., " IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand、H。、「キャラクターセットと言語に関するIETFポリシー」、BCP 18、RFC 2277、1998年1月。
[RFC2510] Adams, C. and S. Farrell, "Internet X.509 Public Key Infrastructure Certificate Management Protocols", RFC 2510, March 1999.
[RFC2510] Adams、C。and S. Farrell、「Internet X.509公開キーインフラストラクチャ証明書管理プロトコル」、RFC 2510、1999年3月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frysyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", RFC 2616, June 1999.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frysyk、H.、Masinter、L.、Leach、P。and T. Berners -lee、 "HyperText Transfer Protocol -HTTP/1.1"、RFC2616、1999年6月。
Acknowledgements
謝辞
The authors gratefully acknowledge the text containing additional use cases in Appendix B that was supplied by Neal Mc Burnett (nealmcb@avaya.com).
著者は、Neal Mc Burnett（nealmcb@avaya.com）が提供した付録Bの追加のユースケースを含むテキストを感謝しています。
Authors' Addresses
著者のアドレス
Alfred Arsenault Diversinet Corp. P.O. Box 6530 Ellicott City, MD 21042 USA
Alfred Arsenault Diversinet Corp. P.O.Box 6530 Ellicott City、MD 21042 USA
Phone: +1 410-480-2052
EMail: aarsenault@dvnet.com
Stephen Farrell, Baltimore Technologies, 39 Parkgate Street, Dublin 8, IRELAND
スティーブンファレル、ボルチモアテクノロジーズ、39パークゲートストリート、ダブリン8、アイルランド
Phone: +353-1-881-6000
EMail: stephen.farrell@baltimore.ie
Appendix A: A note on SACRED vs. hardware support.
付録A：神聖なハードウェアサポートに関するメモ。
One way of accomplishing many of the goals of the SACRED WG is to put the credentials on hardware tokens - e.g., smart cards, PCMCIA cards, or other devices. There are a number of types of hardware tokens today that provide secure storage for sensitive information, some degree of authentication, and interfaces to a number of types of wireless and other devices. Thus, in the second example from section 1.1, Will could simply put his private key on a smart card, always take the smart card with him, and be assured that whichever device he uses to retrieve his e-mail, he will have all of the information necessary to decrypt and read messages.
神聖なWGの多くの目標を達成する1つの方法は、ハードウェアトークン（スマートカード、PCMCIAカード、またはその他のデバイスなど）に資格情報を置くことです。現在、機密情報、ある程度の認証、および多数の種類のワイヤレスおよびその他のデバイスにインターフェイスのための安全なストレージを提供する多くの種類のハードウェアトークンがあります。したがって、セクション1.1の2番目の例では、彼の秘密鍵をスマートカードに単純に配置し、常にスマートカードを持ち、彼が電子メールを取得するために使用するデバイスがすべてを持っていることを保証することができます。メッセージを解読して読み取るために必要な情報。
However, hardware tokens are not appropriate for every environment. They cost more than software-only solutions, and the additional security they provide may or may not be worth the incremental cost. Not all devices have interfaces for the same hardware tokens. And hardware tokens are subject to different failure modes than typical computers - it is not at all unusual for a smart card to be lost or stolen; or for a PCMCIA card to physically break.
ただし、ハードウェアトークンはすべての環境に適していません。彼らはソフトウェアのみのソリューションよりも費用がかかり、彼らが提供する追加のセキュリティは、増分コストの価値がある場合とそうでない場合があります。すべてのデバイスに同じハードウェアトークンのインターフェイスがあるわけではありません。また、ハードウェアトークンは、一般的なコンピューターとは異なる障害モードの対象となります。スマートカードが紛失または盗難されることはまったく珍しいことではありません。または、PCMCIAカードが物理的に壊れるように。
Thus, it is appropriate to develop complementary software-based solution that allows credentials to be moved from one device to another, and provides a level of security sufficient for its environments. While we recognize that the level of security provided by a software solution may not be as high as that provided by the hardware solutions discussed above, and some organizations may not consider it sufficient at all, we believe that a worthwhile solution can be developed.
したがって、資格情報をあるデバイスから別のデバイスに移動できるようにする補完的なソフトウェアベースのソリューションを開発し、その環境に十分なレベルのセキュリティを提供することが適切です。ソフトウェアソリューションによって提供されるセキュリティのレベルは、上記のハードウェアソリューションが提供するものほど高くない可能性があることを認識していますが、一部の組織はそれを十分に考慮していないかもしれませんが、価値のあるソリューションを開発できると考えています。
Finally, SACRED protocols can also complement hardware credential solutions by providing standard mechanisms for the update of credentials which are stored on the hardware device. Today, this often requires returning (with) the device to an administrative centre, which is often inconvenient and may be costly. SACRED protocols provide a way to update and manage credentials stored on hardware devices without requiring such physical presence.
最後に、神聖なプロトコルは、ハードウェアデバイスに保存されている資格情報の更新に標準的なメカニズムを提供することにより、ハードウェア資格情報ソリューションを補完することもできます。今日、これには多くの場合、デバイスを管理センターに（で）返す必要があります。神聖なプロトコルは、そのような物理的存在を必要とせずに、ハードウェアデバイスに保存されている資格情報を更新および管理する方法を提供します。
Appendix B: Additional Use Cases
付録B：追加のユースケース
This appendix describes some additional use cases for SACRED protocols. SACRED protocols are NOT REQUIRED to support all these use cases, that is, this text is purely informative.
この付録では、神聖なプロトコルのいくつかの追加のユースケースについて説明しています。これらのすべてのユースケースをサポートするために神聖なプロトコルは必要ありません。つまり、このテキストは純粋に有益です。
Scenario Overview
シナリオの概要
A university utilizing a PKI for various applications and services on-campus is likely to find that many of its users would like to make use of the same PKI-enabled services and applications on computers located in their residence. These home computers may be owned either by the university or by the individual but are permanently located at the residence as opposed to laptop systems that may be taken home. The usage depicted in this scenario may be motivated by formal telecommuting arrangements or simply by the need to catch up on work from home in the evenings. The basic scenario should apply equally well to the commercial, health care, and higher education environments.
さまざまなアプリケーションおよびキャンパスサービスにPKIを使用している大学は、そのユーザーの多くが、居住地にあるコンピューターで同じPKI対応サービスとアプリケーションを利用したいと考えている可能性があります。これらのホームコンピューターは、大学または個人が所有する場合がありますが、持ち帰る可能性のあるラップトップシステムとは対照的に、恒久的に住居にあります。このシナリオに描かれている使用法は、正式なテレコミューティングの取り決めや、単に夕方に自宅で仕事に追いつく必要性によって動機付けられる可能性があります。基本的なシナリオは、商業、ヘルスケア、および高等教育環境にも同様に適用されるはずです。
Assumptions
仮定
This scenario assumes that the institution has not implemented a hardware token-based PKI mobility solution
このシナリオは、機関がハードウェアトークンベースのPKIモビリティソリューションを実装していないことを前提としています
The home computer has a dial-up as opposed to a permanent network connection.
ホームコンピューターには、永続的なネットワーク接続とは対照的に、ダイヤルアップがあります。
The PKI applications, whenever practical, should be functional in both on-line and off-line modes. For example, the home user signing an email message to be queued for later bulk sending and the reading of a received encrypted message may be supported off-line while composing and queuing of an encrypted message might not be supported in off-line mode.
PKIアプリケーションは、実用的な場合はいつでも、オンラインモードとオフラインモードの両方で機能する必要があります。たとえば、ホームユーザーは、後のバルク送信のためにキューに入る電子メールメッセージに署名し、[暗号化]メッセージの作成とキューイングがオフラインでサポートされている場合は、オフラインでオフラインでサポートされる場合があります。
Applications using digital signatures may require "non-repudiation".
デジタル署名を使用したアプリケーションには、「非繰り返し」が必要になる場合があります。
The institution prefers that the user be identified via a single certificate / key-pair from all computers used by the individual.
機関は、個人が使用するすべてのコンピューターからの単一の証明書 /キーペアを介してユーザーが識別されることを好みます。
The home computer system can not be directly supported by the institution's IT staff. Hardware, operating system versions, and operating system configurations will vary widely. Significant software installation or specialized configurations will be difficult to implement.
ホームコンピューターシステムは、機関のITスタッフによって直接サポートできません。ハードウェア、オペレーティングシステムバージョン、およびオペレーティングシステムの構成は大きく異なります。重要なソフトウェアのインストールまたは特殊な構成を実装するのは困難です。
Uniqueness of Scenario
シナリオの独自性
vThe PKI mobility support needed for this scenario is, in general, similar to the other mobility scenarios. However, it does have several unique aspects: 1. The home-user scenario differs from the general public workstation case in that it provides the opportunity to permanently store the user's certificate and key-pair on the workstation.
vこのシナリオに必要なPKIモビリティサポートは、一般に、他のモビリティシナリオと同様です。ただし、いくつかのユニークな側面があります。1。ホームユーザーシナリオは、ワークステーションにユーザーの証明書とキーペアを永久に保存する機会を提供するという点で、一般的なパブリックワークステーションのケースとは異なります。
2. Likewise the appropriate CA certificates and even certificates for other users can be permanently stored or cached on the home workstation.
2. 同様に、他のユーザー向けの適切なCA証明書および証明書も、ホームワークステーションに永久に保存またはキャッシュできます。
3. Another key difference is the need to support off-line use of the PKI credentials given the assumed dial-up network connection.
3. もう1つの重要な違いは、想定されるダイヤルアップネットワーク接続を考慮して、PKI資格のオフライン使用をサポートする必要性です。
4. The level of hardware and software platform consistency (operating system versions and configurations) will vary widely.
4. ハードウェアおよびソフトウェアプラットフォームの一貫性（オペレーティングシステムのバージョンと構成）のレベルは大きく異なります。
5. Finally, the level of available technical support is significantly less for home systems than for equivalent systems managed by the IT staff at the office location.
5. 最後に、利用可能なテクニカルサポートのレベルは、オフィスの場所のITスタッフが管理する同等のシステムよりも、ホームシステムの方が大幅に少ないです。
Scenario Overview
シナリオの概要
Many colleges and universities operate labs full of computer systems that are available for use by the general student population. These computers are typically configured with identical hardware and an operating system build that is replicated to all of the systems in the lab. Many typical configurations provide no permanent storage of any type while others may offer individual disk space for personal files on a central server. Some scheme is generally used to ensure that the configuration of the operating system is preserved across users and that temporary files created by one user are removed before the next user logs in. Students generally sit down at the next available workstation without any clear pattern of usage.
多くの大学は、一般学生人口が使用できるコンピューターシステムでいっぱいのラボを運営しています。これらのコンピューターは通常、同一のハードウェアとラボ内のすべてのシステムに複製されるオペレーティングシステムビルドで構成されています。多くの典型的な構成は、どのタイプの永久的なストレージを提供しませんが、他の構成は中央サーバー上の個人ファイル用の個別のディスクスペースを提供する場合があります。一部のスキームは、一般に、オペレーティングシステムの構成がユーザー間で保存され、1人のユーザーが作成した一時ファイルが次のユーザーがログインする前に削除されることを保証するために使用されます。一般的に、生徒は使用可能なパターンなしで次の利用可能なワークステーションに座っています。
The same basic technical solutions used to operate public labs are often also used in general environments where several people share a single workstation. This is often found in locations with shift work such as medical facilities and service bureaus that provide services to multiple time zones.
パブリックラボの運用に使用される同じ基本的な技術ソリューションは、多くの場合、数人が単一のワークステーションを共有する一般的な環境でも使用されます。これは、多くの場合、複数のタイムゾーンにサービスを提供する医療施設やサービス局などのシフト作業がある場所で見られます。
Assumptions
仮定
1. This scenario assumes that the institution has not implemented a hardware token-based PKI mobility solution.
1. このシナリオは、機関がハードウェアトークンベースのPKIモビリティソリューションを実装していないことを前提としています。
2. The computer systems are permanently networked with LAN connections.
2. コンピューターシステムは、LAN接続と永久にネットワーク化されています。
3. The configuration of the computer system is centrally maintained and customizations are relatively easy to implement. For example it would be easy to load enterprise root certificates, LDAP server configurations, specialized software, and any other needed components of the PKI on to the workstations.
3. コンピューターシステムの構成は中央に維持されており、カスタマイズは比較的簡単に実装できます。たとえば、エンタープライズルート証明書、LDAPサーバー構成、専門ソフトウェア、およびワークステーションにPKIのその他の必要なコンポーネントを簡単にロードできます。
4. Applications using digital signatures may require "non-repudiation" in some of the anticipated environments. Examples of this might include homework submission in a public lab environment or medical records in a health care environment.
4. デジタル署名を使用したアプリケーションでは、予想される環境の一部で「非繰り返し」が必要になる場合があります。この例には、公共研究所環境での宿題の提出や、医療環境での医療記録が含まれる場合があります。
5. The institution prefers that the user be identified via a single certificate / key-pair from all computers used by the individual.
5. 機関は、個人が使用するすべてのコンピューターからの単一の証明書 /キーペアを介してユーザーが識別されることを好みます。
6. Many anticipated implementations of this scenario will not implement any user authentication at the desktop operating system level. Instead, user authentication will occur at during the startup of networked applications such as email, web-based services, etc. Login at the desktop level may be with generic user names that are more targeted at matching printouts to machines than identifying users.
6. このシナリオの予想される実装の多くは、デスクトップオペレーティングシステムレベルでユーザー認証を実装しません。代わりに、ユーザー認証は、電子メール、Webベースのサービスなどのネットワーク化されたアプリケーションの起動中に発生します。デスクトップレベルでのログインは、ユーザーを識別するよりもマシンにプリントアウトを一致させることを目的とする一般的なユーザー名を使用する場合があります。
7. Users, with almost ridiculous frequency, will walk away from a system forgetting to first logout from running authenticated applications.
7. ほとんどばかげた頻度のユーザーは、認証されたアプリケーションの実行から最初にログアウトするのを忘れてシステムから離れます。
Uniqueness of Scenario
シナリオの独自性
The PKI mobility support needed for this scenario is, in general, similar to the other mobility scenarios. However, it does have several unique aspects:
このシナリオに必要なPKIモビリティサポートは、一般に、他のモビリティシナリオと同様です。ただし、いくつかのユニークな側面があります。
1. Unlike situations with personal workstations, there is no permanent storage available to hold user key pairs and certificates.
1. パーソナルワークステーションのある状況とは異なり、ユーザーキーペアや証明書を保持するための恒久的なストレージはありません。
2. Appropriate CA certificates and custom software are easily added and maintained for these types of shared systems.
2. 適切なCA証明書とカスタムソフトウェアは、これらのタイプの共有システムに対して簡単に追加および維持されます。
3. The workstations are installed in public locations and users will frequently forget to close applications before permanently walking away from the workstation.
3. ワークステーションは公共の場所にインストールされており、ユーザーはワークステーションから永久に歩く前に、アプリケーションを閉鎖することを頻繁に忘れます。
Overview
概要
This scenario describes the needs of the traveler or the shopper. This person is traveling light (no computer) or is burdened with everything but a computer. It recognizes the increasing availability of Internet access points in public spaces, such as libraries, airports, shopping malls, and "cyber cafes".
このシナリオでは、旅行者または買い物客のニーズを説明しています。この人は光（コンピューターなし）を走行しているか、コンピューター以外のすべてのものを負担しています。図書館、空港、ショッピングモール、「サイバーカフェ」などの公共スペースでのインターネットアクセスポイントの可用性の向上を認識しています。
The Need
必要なもの
In our increasingly mobile society, the chances of needing information when away from the normal computing place are great. One may need to look up a telephone number. Have you tried to find a phone book at a public phone lately? It may become necessary to use a data device to find the next place to rush to. With the proliferation of wireless devices (electronic leashes), others have the ability to create a need for quick access to electronic information. A pager can generate a need to check the email inbox or address book. A cell phone can drive you to your database to answer a pressing question.
ますます機動性のある社会では、通常のコンピューティングの場所から離れているときに情報を必要とする可能性があります。電話番号を調べる必要があるかもしれません。最近公立電話で電話帳を見つけようとしましたか？データデバイスを使用して、急いで次の場所を見つける必要がある場合があります。ワイヤレスデバイス（電子鎖）の急増により、他のものは電子情報に迅速にアクセスする必要があることを作成することができます。ポケットベルは、電子メールの受信トレイまたはアドレス帳を確認する必要性を生成できます。携帯電話は、差し迫った質問に答えるためにあなたをデータベースに駆り立てることができます。
The ability to quickly access sensitive or protected information or services from publicly available devices will only become more necessary as we become more and more "connected".
公開されているデバイスから機密性または保護された情報またはサービスに迅速にアクセスする機能は、ますます「接続」になると、より必要になります。
The Device
デバイス
The access device is more a function of the best discount or marketing effort than of design. Any number of hardware platforms will be encountered.
アクセスデバイスは、設計よりも最高の割引やマーケティングの取り組みの機能です。任意の数のハードウェアプラットフォームに遭遇します。
Since these devices are open to the public I/O ports are not likely to be. In order to protect the device and its immediate network environment, most devices will be in some sort of protective container. Access to serial, parallel, USB, firewire, SCSI, or PCMCIA connections will not be possible. Likewise floppy, zip, or CD drives. Therefore, any software "token" must be obtained from the network itself.
これらのデバイスは公開されているため、I/Oポートはそうではない可能性があります。デバイスとその即時のネットワーク環境を保護するために、ほとんどのデバイスは何らかの保護容器にあります。シリアル、パラレル、USB、FireWire、SCSI、またはPCMCIA接続へのアクセスは不可能です。同様に、フロッピー、ジップ、またはCDドライブ。したがって、任意のソフトウェア「トークン」は、ネットワーク自体から取得する必要があります。
The Concerns
懸念
1. Getting the "token". Since it will be necessary to obtain the token (key, certificate, credential) from across the network. How can it be protected during transit?
1. 「トークン」を取得します。ネットワーク全体からトークン（キー、証明書、資格情報）を取得する必要があるためです。輸送中にどのように保護できますか？
2. Where did you get it? One of the primary controls in PKI is protection of the private key. Placing the key on a host that is accessible from a public network means that there is an inherent exposure from that network. The access controls and other security measures on the host machine are an area of concern.
2. どこで手に入れましたか？PKIの主要なコントロールの1つは、秘密鍵の保護です。パブリックネットワークからアクセスできるホストにキーを配置することは、そのネットワークから固有の露出があることを意味します。ホストマシンのアクセス制御とその他のセキュリティ対策は、懸念事項です。
3. How did you get it? When you obtained the token from the server, how did it know that you are you? Authentication becomes critical.
3. どうやって手に入れたの？サーバーからトークンを取得したとき、あなたがいることをどのように知っていましたか？認証が重要になります。
4. What happens to the token when you leave? You've checked your mail, downloaded a recipe from that super-secure recipe server, found out how to get to the adult beverage store for the... uh... accessories... for the meal, and you're off! Is your token? Or is it still sitting there on the public kiosk waiting for those youngsters coming out of the music store to notice and cruise the information highway on your ticket?
4. あなたが去るとき、トークンはどうなりますか？あなたはあなたのメールをチェックし、その超安全なレシピサーバーからレシピをダウンロードしました、...ええと...ええと...アクセサリー...食事のために大人の飲料店に行く方法を見つけました！トークンですか？それとも、音楽店から出てくる若者があなたのチケットの情報高速道路に気づき、巡航するのを待っている公のキオスクの上にまだ座っていますか？
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があり、それについてコメントまたは説明する派生作品、またはその実装を支援することができます。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。