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.
著作権（C）インターネット協会（2001）。全著作権所有。
Abstract
抽象
This document describes requirements to be placed on Securely Available Credentials (SACRED) protocols.
この文書では、確実に利用可能な資格情報（SACRED）プロトコル上に配置するための要件について説明します。
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.
単純なモデル、ユーザーや他のエンティティでは（例えば、ルータなどのコンピュータが）資格情報を使用して提供され、これらの資格情報は、一つの場所にとどまります。しかし、インターネットにアクセスするために使用できるデバイスの数、そしてもっと重要なのは、異なる種類の数は、増加しています。インターネットサービスにアクセスできるようになりましたし、デスクトップコンピュータ、ラップトップコンピュータ、無線電話、ポケットベル、携帯情報端末（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].
キーワード「MUST」、「必須」、「推奨」、「SHOULD」とは、本書では[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.
インターネット利用の単純なモデルでは、ユーザーや他のエンティティは、資格情報を使用して提供され、これらの資格情報は、一つの場所にとどまります。例えば、ミミは、彼女のデスクトップコンピュータ上の公開鍵と秘密鍵を生成し、証明書に含まれる認証局（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.
しかし、ミミは彼女が道路上にあるとき、彼女はオフィスであり、彼女のラップトップコンピュータからときの彼女のデスクトップコンピュータから署名された電子メールメッセージを送信することにしたいこと、そして彼女は、メッセージの受信者は、違いを知っている必要はありません。これを行うために、彼女は何とか両方のデバイス上で彼女の秘密鍵を利用できるようにする必要があります - つまり、その資格を移動する必要があります。
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.
同様に、ウィルは、彼の携帯電話のどちらからか、彼の双方向ページャから暗号化された電子メールを取得して読むことをお勧めします。彼は現時点で彼と一緒に持っており、彼のメールへのアクセスを拒否することを望んでいないか、彼は間違ったデバイスを持っているという理由だけで、重要なメッセージを解読することができないためにどのデバイスを使用したいと考えています。このように、彼は両方のデバイスで利用できる同じ秘密鍵を持っていることができなければなりません。
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インチのフレキシブルなディスケット、ハード・ディスク・ファイル、携帯電話、スマートカードなど）は、しばしば非常に異なるプロトコル処理を非常に異なるセキュリティ特性を持っているとします機能を提供します。 SACREDプロトコルを使用して、ユーザーが必要に応じて安全に異なる場所、異なるインターネット・デバイス、および異なるストレージメディアの間で資格情報を移動することができるようになります。
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.
SACREDワーキンググループでは、安全に機器間の認証情報を転送するためのプロトコルのセットの標準化に取り組んでいます。一般的なフレームワークは、資格情報転送の要件を満たすことができるプロトコルの抽象定義を与えるよう開発されています。このフレームワークは、いくつかの点で互いに異なっていてもよいプロトコルのセット、の開発を可能にします。フレームワークに準拠して特定のプロトコルは、開発することができます。
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はSACREDソリューションやスマートカードなどのハードウェアコンポーネントを含む資格・モビリティ・ソリューションの関係を説明しています。付録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.
このセクションでは、SACREDフレームワークは、フレームワークを使用する特定のプロトコルによって満たされるべき要件とは対照的に、満たさなければならない要件を記述する。
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つのクラスは、中間ノードとして「信用証明書サーバ」を使用し、および他のクラスは、デバイス間の直接的な転送を提供します。
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.
別のエンドデバイスからセキュアクレデンシャルを転送するには簡単二段階プロセスです。ユーザーは、信用証明書サーバに、一つのデバイス、例えば、携帯電話から「アップロード」しっかりと自分の資格情報を持つことができます。彼らは、信用証明書サーバに格納され、別のデバイスを使用して、必要なときに、「ダウンロード」することができます。例えば、双方向ページャ。
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.これは、概念的に清潔で簡単な方法を提供します。すべてのエンドデバイスの場合、デバイスからサーバーに認証情報を転送するために定義されたアクションのセット、およびデバイスへのサーバから認証情報を転送するために定義されたアクションの別のセットで、あるプロトコルがあります。さらに、このプロトコルは、他の多くのインターネットプロトコルなどのクライアント（デバイス）とサーバ（信用証明書サーバ）を、必要とします。したがって、このプロトコルの設計は、他のほとんどのインターネットプロトコルに精通しているほとんどの人にはおなじみである可能性が高いです。
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.信用証明書サーバは、いくつかの意味での「信頼」する必要があり、また、潜在的な脆弱性のポイントを紹介することがあります。 （問題のいくつかのセキュリティ上の注意事項のセクションを参照してください。）グッドプロトコルとシステム設計は、信用証明書サーバに存在する脆弱性を制限しますが、最低でも、信用証明書サーバへのアクセス権を持つ人は、資格情報を削除し、これを否定することができるようになりますシステムユーザにSACREDサービス。
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.
例えば、ミミが問題の資格情報を含む彼女の携帯電話からメッセージを送信し、それが彼女の双方向ページャを使用して取得する場合を考えます。ある場所から別の場所に得ることに、メッセージのビットが基地局に無線電話網を横切ります。これらのビットは、おそらく携帯電話事業者が運営するメッセージサーバに有線電話ネットワークを介して転送され、ページングオペレータによって実行メッセージサーバにインターネットを介してそこから転送されます。ページングオペレータから彼らはミミのポケットベルに最終的には、基地局に転送しています。確かに、それらは1つの場所から別のビットを送信するという意味でクレデンシャルの転送に関与している元の無線電話と究極ページャ以外の装置があります。しかし、ページャや携帯電話以外のすべてのデバイスに、どのような転送されると、ビットの解釈、国連及び未処理のセットです。いいえ、セキュリティ関連の決定がなされていない、と何のアクションは、このメッセージは、中間ノードのいずれかで、資格情報が含まれているという事実に基づいてとられていません。彼らはビットを転送するために単に存在します。したがって、我々は、これは資格証明書の「直接」転送であると考えています。
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.
私たちは、ソリューションの両方のクラスは、特定の環境で有用であることが、ひいてはSACREDフレームワークは、両方のソリューションを定義する必要がありますと信じています。上記の解決策の要素が残って重複する程度が決定されます。
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.
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.
このセクションでは、SACREDプロトコルが保護を提供する必要があり、それに対しての脆弱性を示しています。本書に記載されている要件を満たしていると主張する任意のプロトコルを明示的に、それはこれらの脆弱性のそれぞれに対する保護を提供していますか（またはかどうか）を示す必要があります。
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。攻撃者が選択した「暗号文」を解読し、得られた平文を使用するようにクライアントを取得するためにクライアントを取得しようとすることができます - 平文が「解読」から生じた場合、攻撃者は、その後、辞書攻撃（例えばを行うことができるかもしれランダムな文字列のDSA秘密鍵）として使用されています。 V4。ユーザーは、その後、彼らは良い資格だと思うものを使用したとき、彼らは自分のパスワード（それゆえ「本物」の資格）についての情報を公開するように、攻撃者は、リポジトリのエントリを上書きすることができます。 V5。攻撃者は、信用証明書サーバのリポジトリをコピーして、辞書攻撃を行うことができます。 V6。攻撃者は、サーバーが後で辞書攻撃を可能にした情報を明らかにするために取得しようとする試みにクライアントを偽装しようとすることができます。 V7。攻撃者は、そうでない場合であっても、成功したログインが発生したサーバーを説得することができます。 V8。 （アップロード）攻撃者は、サーバー上の誰か他の人の資格情報を上書きすることができます。 V9。 （パスワードベースの認証を使用する場合）、攻撃者は、既知の（又は「弱」）パスワードとパスワードの変更を強制することができます。 V10。攻撃者は、たくさんのV11のman-in-the-middle攻撃を試みることができます。ユーザーは、名前の代わりにパスワードを入力します。 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のサポートはREQUIRED（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-から-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.
モバイル資格情報があるため、エンドユーザデバイスのオペレーティングシステムを通じて潜在的な攻撃を、「純粋な」ハードウェアベースのソリューションと同様に安全になることはありません。しかし、セキュリティの許容レベルは、いくつかの簡単な手段によって達成することができます。実際には、セキュリティのレベルはSACREDプロトコルを使用して（パスワード暗号化されたファイルに比べて）向上させることができます。
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クライアントソフトウェアの交換は常に可能となり、このようなプログラムは、プログラムの作成者にユーザー名とパスワードを電子メールで送信できます。
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.
SACREDプロトコルの開発作業の範囲外ものの、実装は慎重に、セキュリティ関連する可能性があるイベントを監査する必要があります。特に資格・サーバの実装は、（おそらくマスクさ - 下記参照）すべての操作を監査すべきであり、動作時およびソース（例えば、IPアドレス）に関する情報が含まれている必要があり、クライアントの要求されたアイデンティティ、操作の種類と結果をとおそらく他の操作固有の情報。また、実装は、監査証跡のセキュリティ機密情報、特に敏感ではない認証情報を含まないように注意する必要があります。
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]カラス、J.、Donnerhacke、L.、フィニー、H.及びR.セイヤー、 "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]ブラドナーの、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]アダムス、C。およびS.ファレル、 "インターネット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]フィールディング、R.、ゲティス、J.、モーグル、J.、Frysyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1"、RFC 2616年、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).
作者は感謝ニールMcのバーネット（nealmcb@avaya.com）によって供給された付録Bに追加のユースケースを含むテキストを認めます。
Authors' Addresses
著者のアドレス
Alfred Arsenault Diversinet Corp. P.O. Box 6530 Ellicott City, MD 21042 USA
アルフレッドArsenault Diversinet社の私書箱ボックス6530エリコットシティー、MD 21042 USA
Phone: +1 410-480-2052 EMail: aarsenault@dvnet.com
電話：+1 410-480-2052電子メール：aarsenault@dvnet.com
Stephen Farrell, Baltimore Technologies, 39 Parkgate Street, Dublin 8, IRELAND
スティーブン・ファレル、ボルチモアテクノロジーズ、39 Parkgateのストリート、ダブリン8、アイルランド
Phone: +353-1-881-6000 EMail: stephen.farrell@baltimore.ie
電話：+ 353-1-881-6000 Eメール：stephen.farrell@baltimore.ie
Appendix A: A note on SACRED vs. hardware support.
付録A：SACRED対ハードウェアのサポートに関する注意事項。
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.
例えば、スマートカード、PCMCIAカード、またはその他のデバイス - SACRED WGの目標の多くを達成する一つの方法は、ハードウェアトークンに信任状を置くことです。機密情報のためのセキュアなストレージを提供するハードウェアトークンの種類数今日、認証のある程度、およびワイヤレスおよびその他のデバイスの種類の数へのインタフェースがあります。このように、セクション1.1からの第二の例では、ウィルは、単に、スマートカード上の彼の秘密鍵を置くことができ、常に彼と一緒にスマートカードを取り、どのデバイス、彼は彼の電子メールを取得するために使用することが保証され、彼はすべてを持っていますメッセージを解読し、読むのに必要な情報。
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.
最後に、神聖なプロトコルは、ハードウェアデバイスに格納された資格情報の更新のための標準的なメカニズムを提供することによって、ハードウェア資格ソリューションを補完することができます。今日、これは多くの場合、多くの場合、不便であり、費用がかかるかもしれ管理センターに（と）デバイスを返す必要とします。 SACREDプロトコルは、このような物理的な存在を必要とせずにハードウェアデバイス上に格納された資格情報を更新して管理する方法を提供します。
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.
この付録では、SACREDプロトコルのためのいくつかの追加のユースケースを記述しています。 SACREDプロトコルは、これらすべてのユースケースをサポートする必要はありません、つまり、このテキストは、純粋に有益です。
B.1 Home/Work Desktop Computer
B.1ホーム/仕事デスクトップコンピュータ
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:
このシナリオのために必要なPKIのモビリティサポートは、一般的には、他のモビリティのシナリオに似ています。しかし、それはいくつかのユニークな側面を持っています：
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.
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.もう一つの重要な違いは想定ダイヤルアップネットワーク接続を与えられた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スタッフによって管理される同等のシステムよりもホームシステムのための非常に少ないです。
B.2 Public Lab / On-campus Shared Workstation
B.2公開ラボ/キャンパス内の共有ワークステーション
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.
多くの大学は、一般の学生の人口で使用するために利用可能なコンピュータシステムの完全なラボを運営しています。これらのコンピュータは通常、同一のハードウェアおよびラボ内のすべてのシステムに複製されているオペレーティングシステムのビルドを使用して構成されています。他の人が中央サーバーに個人的なファイルのための個々のディスクスペースを提供することがありますが、多くの一般的な構成は、任意のタイプの永久的なストレージを提供しません。いくつかのスキームは、一般的に、オペレーティング・システムの構成をユーザー間で保存され、一人のユーザーによって作成された一時ファイルは、の次のユーザがログインする前に削除されていることをされることを保証するために使用されている。学生は、一般的に、使用のいずれかの明確なパターンせずに次の利用可能なワークステーションで座ります。
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.
前記コンピュータ・システムの構成は、集中管理され、カスタマイズを実装するのが比較的容易です。例えば、企業のルート証明書、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.多く予想される実装では、デスクトップ・オペレーティング・システム・レベルで任意のユーザー認証を実装していません。代わりに、ユーザ認証等、電子メール、ウェブベースのサービスなどのネットワークアプリケーションの起動中にで発生するデスクトップレベルでのログインは、より多くのユーザーを特定するよりも、マシンにプリントアウトのマッチングを対象としている一般的なユーザー名がある可能性があります。
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.ワークステーションは、公共の場所やユーザーにインストールされているが、頻繁に永続的にワークステーションから離れて歩いて前にアプリケーションを閉じることを忘れます。
B.3 Public Kiosk Mobility
B.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.
これらのデバイスは一般に公開されているので、私は/ Oポートは、可能性が高いではありません。デバイスおよびその直接のネットワーク環境を保護するために、ほとんどのデバイスは、保護コンテナのいくつかの並べ替えになります。シリアル、パラレル、USB、FireWireの、SCSI、またはPCMCIA接続へのアクセスはできなくなります。同様に、フロッピー、ZIP、または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における主要なコントロールの一つは、秘密鍵の保護です。パブリックネットワークからアクセス可能なホスト上のキーを配置すると、そのネットワークから本来の露出があることを意味します。アクセス制御やホストマシン上の他のセキュリティ対策は、関心領域です。
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.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。