RFC3157 日本語訳
3157 Securely Available Credentials - Requirements. A. Arsenault, S.Farrell. August 2001. (Format: TXT=46169 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group A. Arsenault
Request for Comments: 3157 Diversinet
Category: Informational S. Farrell
Baltimore Technologies
August 2001
Arsenaultがコメントのために要求するワーキンググループA.をネットワークでつないでください: 3157年のDiversinetカテゴリ: 情報のS.ファレルボルチモア技術2001年8月
Securely Available Credentials - Requirements
しっかりと利用可能な資格証明書--要件
Status of this Memo
この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)インターネット協会(2001)。 All rights reserved。
Abstract
要約
This document describes requirements to be placed on Securely Available Credentials (SACRED) protocols.
このドキュメントはSecurely Available Credentials(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
1. 序論…1 2. フレームワーク要件…4 3. 要件について議定書の中で述べてください…7 4. セキュリティ問題…10の参照箇所…12の承認…12人の作者のアドレス…13 付録A: SACREDに関する注対ハードウェアサポート…14 付録B: 追加使用は…をケースに入れます…14 完全な著作権宣言文…20
1. Introduction
1. 序論
"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.
「資格証明書」は実体のアイデンティティを証明するか、またはその実体がしっかりと交信するのを助けるのに使用できる情報です。 資格証明書はパーソナルSecurity Environment(PSE)[RFC2510]の秘密鍵、信じられたルーツ、チケット、または個人的な部分のようなものを含んでいます--すなわち、インターネットに関する安全なコミュニケーションで使用される情報。 IPSecとTLS、資格証明書は、様々なインターネットプロトコル、例えばS/MIMEをサポートするのに使用されます。
Arsenault & Farrell Informational [Page 1] RFC 3157 SACRED - Requirements August 2001
Arsenaultとファレル情報[1ページ]のRFC3157SACRED--、要件2001年8月
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.
このドキュメントは資格証明移動性のための1セットの要件を特定します。 また、作業部会は仲間ドキュメントを製作するでしょう。(ドキュメントは安全な資格証明移動性のためのフレームワーク、およびこの目標を達成するための1セットのプロトコルについて説明します)。
The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in [RFC2119].
「必要で」、“SHOULD"の、そして、「お勧め」のキーワード“MUST"、およびこのドキュメントの「5月」は[RFC2119]で説明されるように解釈されることになっています。
1.1 Background and Motivation
1.1 バックグラウンドと動機
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つの場所でままでいます。 例えば、ミミは、彼女のデスクトップコンピュータの上で公衆と秘密鍵を生成して、証明書に含まれるように認証局(カリフォルニア)に公開鍵を提供して、彼女のコンピュータで秘密鍵を保ちます。 それは決して動かされる必要はありません。
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
また、ルータに関連する以下のシナリオを提供しました: 「昔々、ルータはkeypairを生成しました。」 管理者は、他の多くの(同輩)ルータにそのルータの公開鍵を移して、他のルータにトラフィックを暗号化するのにそのルータを使用しました。 そして、これは何年間も良かったです。 次に、1日、ネットワーク
Arsenault & Farrell Informational [Page 2] RFC 3157 SACRED - Requirements August 2001
Arsenaultとファレル情報[2ページ]のRFC3157SACRED--、要件2001年8月
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を扱うことができないのがわかりました。 それで、彼らは、それを破壊して、それを本当に大きいルータに取り替えました。 彼らはそこにいましたが、工芸品の労働者は、スマートカードをルータに挿入して、ルータにログインしました。 彼らが適切なコマンドを与えて、正解を入力したので、資格証明書(keypair)を新しくて、大きいルータに移しました。 あるいはまた、工芸品の人々は、ルータにログインして、最小量の構成をそれに与えて、資格証明サーバからルータまで資格証明書を移したかもしれません。 彼らは、転送がうまくいっているために正しい呪文と認証を実行しなければなりませんでした。 このように、ルータのアイデンティティは古いルータから新しいものまで動かされました。 「管理者は彼らがまた、同輩ルータのすべての構成を編集する必要はないのがうれしかったです。」
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.
このドキュメントの残りでは、私たちはソフトウェアベースの資格証明書の安全な転送のための1セットの要件を提示します。
1.2 Working Group Organization and Documents
1.2 ワーキンググループ組織とドキュメント
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作業部会は、しっかりと資格証明書をデバイスに移すために1セットのプロトコルの標準化に取り組んでいます。 一般的なフレームワークは開発することにされます資格証明転送必要条件を満たすことができるプロトコルの抽象的な定義を与える。 このフレームワークは1セットのプロトコルの開発を考慮するでしょう。(プロトコルはある点でお互いと異なるかもしれません)。 そして、フレームワークに従う特定のプロトコルは開発できます。
Arsenault & Farrell Informational [Page 3] RFC 3157 SACRED - Requirements August 2001
Arsenaultとファレル情報[3ページ]のRFC3157SACRED--、要件2001年8月
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.
多くのドキュメントでは、仕事をしています。 このドキュメントは、一般的なフレームワークのために要件を特定して、特定のプロトコルのために要件を特定します。 別のドキュメントはプロトコルフレームワークについて説明するでしょう。 それでも、他のものはプロトコル自体を定義するでしょう。
1.3 Structure of This Document
1.3 このドキュメントの構造
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はSecurity Considerationsを特定します。 付録Aはスマートカードなどのハードウェアの部品にかかわるSACREDソリューションと資格証明移動性ソリューションの関係について説明します。 付録Bは要件を開発するとき考えられたいくつかの追加シナリオを含んでいます。
2. Framework Requirements
2. フレームワーク要件
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フレームワークに満たされなければならないという要件について説明します、フレームワークを使用する特定のプロトコルによって満たされることになっている必要条件と対照的に。
2.1 Credential Server and Direct solutions
2.1 資格証明ServerとDirectソリューション
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.
片端デバイスから別のデバイスまでしっかりと資格証明書を移すのは、簡単な二段構えの体制です。 ユーザは1台のデバイスから彼らの資格証明書をしっかりと「アップロードさせられることができます」、例えば、無線電話、資格証明サーバに。別のデバイスを使用することで必要であると、それらは、資格証明サーバに保存して、「ダウンロードできます」。 例えば、両用ポケットベル。
Some advantages of a credential server approach compared to credential transfer are:
資格証明転送と比較された資格証明サーバアプローチのいくつかの利点は以下の通りです。
Arsenault & Farrell Informational [Page 4] RFC 3157 SACRED - Requirements August 2001
Arsenaultとファレル情報[4ページ]のRFC3157SACRED--、要件2001年8月
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つのプロトコルがあります、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. それはしっかりと任意の長さの時間として資格証明書を保存できる場所に備えます。 一般に慣例の下で作動する妥当な品質サーバを考えて、資格証明書が永久にハードウェアの故障のため失われるのは、ありそうもないです。 これが資格証明書が端末装置で保存されるだけであるシステム、どのa失敗に対照をなすか、そして、資格証明書は平均ですが、またはいつまでも失われて、デバイスの損失はそうするかもしれません。
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. 資格証明サーバは、何らかの意味で「信じられなければならないかもしれなく」て、また、潜在的脆弱性のポイントを紹介します。 (問題のいくつかに関してSecurity Considerations部を見てください。) 良いプロトコルとシステム設計が資格証明サーバで存在する脆弱性を制限しますが、最小限では、資格証明サーバへのアクセスのだれかが、資格証明書を削除して、その結果、システムユーザに対する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).
したがって、異なったクラスのソリューションを好むユーザもいるかもしれません。(資格証明書はそれで直接1台のデバイスから別のもの(すなわち、資格証明書のどんな理解も処理するか、または持っている仲介者要素を全く持っていない)まで移されます)。
Arsenault & Farrell Informational [Page 5] RFC 3157 SACRED - Requirements August 2001
Arsenaultとファレル情報[5ページ]のRFC3157SACRED--、要件2001年8月
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つの場所から別の場所まで得ることでは、メッセージのビットは無線電話ネットワークを基地局に越えます。 これらのビット、おそらく無線電話オペレータによって実行されたメッセージサーバへのワイヤードな電話ネットワークの上に移されて、そこ、インターネットの上をページングオペレータによって実行されたメッセージサーバに移動されます。 ページングオペレータから、それらを基地局と、そして、そして、最終的なミミのポケットベルに移します。 確かに、資格証明転送にかかわるオリジナルの無線電話と究極のポケットベル以外のデバイスがあります、彼らが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.
資格証明書の1台のデバイスから別のデバイスまでの直接移転にかかわるソリューションは支えられなければならないかもしれない異なったデバイスと多くの形式による資格証明サーバアプローチより潜在的にいくらか複雑です。 また、複雑さは各デバイスが順番にクライアントとサーバの両方の振舞いを示さなければならないかもしれないという事実のため加えられます。
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。 「資格証明サーバ」と「ダイレクトな」ソリューションSHOULDは同じ技術をできるだけ使用します。
2.2 User authentication
2.2 ユーザー認証
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.
資格証明移動性ソリューションのためのさまざまな展開オプションがあります。 これらの場合の多くでは、既存のユーザー認証体系を再使用できるのは役に立ちます、例えば、パスワードが以前に確立されたところでこれらを再使用するのが真新しいセットのパスワードを管理しようとするより安全であるかもしれません。 また、異なったデバイスはユーザー認証体系の可能なタイプを制限するかもしれません、例えば、すべてのモバイル機器がどんな実際に非対称の暗号を行うことができるというわけではありません。
Arsenault & Farrell Informational [Page 6] RFC 3157 SACRED - Requirements August 2001
Arsenaultとファレル情報[6ページ]のRFC3157SACRED--、要件2001年8月
F3. The framework MUST allow for protocols which support different
user authentication schemes
F3。 フレームワークは異なったユーザー認証体系をサポートするプロトコルを考慮しなければなりません。
2.3 Credential Formats
2.3 資格証明形式
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。 実際の資格証明タイプか形式の詳細はプロトコルに不明瞭であるに違いありません、プロトコルの同輩の中のどんな処理にもそうしませんが。 プロトコルはどんな資格証明タイプや形式の内部の構造にも依存してはいけません。
2.4 Transport Issues
2.4 輸送問題
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。 フレームワークは異なった輸送の使用を許さなければなりません。
3. Protocol Requirements
3. プロトコル要件
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.
このセクションで、私たちは安全な資格証明書転送対策のための要件を特定します。 私たちは、1セットの関連脆弱性とすべてのソリューションで満たさなければならない必要条件をリストアップすることによって、始めるつもりです。 そして、私たちは資格証明書の直接移転にかかわるソリューションで満たさなければならない追加必要条件があとに続いた資格証明サーバにかかわるソリューションで満たさなければならない追加必要条件を特定します。
3.1 Vulnerabilities
3.1 脆弱性
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プロトコルSHOULDが保護を提供する脆弱性を記載します。 これに記載されていて、ドキュメントが明らかにどのように(or whether)を示さなければならないかという必要条件を満たすために、それぞれのこれらの脆弱性のために保護を提供すると主張するどんなプロトコル。
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。 攻撃者は、クライアントに情報が稼働中であることを明らかにさせる後の辞書攻撃を考慮する試みにおける資格証明サーバのふりをするのを試みることができます。
Arsenault & Farrell Informational [Page 7] RFC 3157 SACRED - Requirements August 2001
Arsenaultとファレル情報[7ページ]のRFC3157SACRED--、要件2001年8月
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のために介入者攻撃を試みることができます。 ユーザは名前の代わりにパスワードを入力します。 V12。 攻撃者は様々なサービス不能攻撃を試みることができました。
3.2 General Protocol Requirements
3.2 一般プロトコル要件
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)であるとサポートするという究極の目標が会われることであるなら資格証明書の転送に適用されなければならない多くの要件があるのを容易に見ることができます。 例えば、資格証明書はいつも秘密のままで残らなければなりません。 エンドユーザのデバイス以外のノードがどんな読み込み可能なcleartextフォームでも資格証明書を見るのは、容認できません。
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。 資格証明書はプロトコルによってエンドユーザのもの以外のどんなデバイスにもcleartextに存在しているのが強制されてはいけません。 G3。 または、プロトコルSHOULDが、すべてのわたっている資格証明書が何らかの方法で認証されるのを確実にする、(例えば、デジタルに署名される、MAC-教育) G4。 プロトコルは左右対称の、そして、非対称のアルゴリズム、ハッシュアルゴリズム、およびMACアルゴリズムを含むさまざまな暗号アルゴリズムをサポートしなければなりません。
Arsenault & Farrell Informational [Page 8] RFC 3157 SACRED - Requirements August 2001
Arsenaultとファレル情報[8ページ]のRFC3157SACRED--、要件2001年8月
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.
5ヵ国蔵相会議。 プロトコルは様々な資格証明タイプと形式(例えば、X.509、PGP、PKCS12)の使用を許さなければなりません。 G6。 資格証明形式をサポートするために義務的な定義しなければなりません。 G7。 ユーザー認証体系をサポートするために義務的な定義しなければなりません。 G8。 プロトコルが、資格証明書がテキストハンドルでラベルされるのを許容するかもしれない、(資格証明書の外における)、エンドユーザが資格証明書のセットの中で選択するか、または特定の資格証明書と命名するのを許容するために。 G9。 完全なI18NサポートはREQUIRED(UTF8サポートを通した)[RFC2277]です。 10ヵ国蔵相会議。 プロトコルがクライアントのためにプライバシー、すなわち、匿名をサポートすることができるのは、望ましいです。 G11。 わたっている資格証明書はタイミング情報(例えば、転送/ダウンロードに続いて、使用可能である資格証明書がことである最大の時を決定する「生きる時間」値)を取り入れるかもしれません。
3.3 Requirements for Credential Server-based solutions
3.3 Credential Serverベースのソリューションのための要件
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。 資格証明サーバSHOULDはすべての操作のためにユーザに認証されて、ダウンロードします。 以下に注意してください。 資格証明形式自体が強く保護されるなら、この要件を無視できます、リスクが全く非認証された資格証明サーバS6から来ていないとき(ユーザ混乱を除いて)。 それ、SHOULD、ダウンロード操作の一部として資格証明サーバをユーザに認証するのにおいて、可能であってください。 S7。 ユーザSHOULDだけが、資格証明書をダウンロードして、使用するためにただ一つの秘密の値を入れなければなりません。 S8。 複数のサーバの向こう側に秘密を共有するのは可能であるかもしれません、いくつかのサーバの侵入が資格証明書(「nからのm」操作)の恥部を暴露しないように。 S9。 プロトコルは「ホームから遠くへ」操作をサポートするかもしれません、ユーザが名前とドメインの両方(例えば、 RoamingStephen@baltimore.ie )に入って、ユーザの資格証明サーバの場所を見つけるのにドメインは使用できるところで。
Arsenault & Farrell Informational [Page 9] RFC 3157 SACRED - Requirements August 2001
Arsenaultとファレル情報[9ページ]のRFC3157SACRED--、要件2001年8月
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。 ユーザSHOULD、それらの資格証明書へのアクセス/変化のリストを検索できてください。 S13。 プロトコルはユーザ自己登録をサポートしなければなりません。 これを求める1つのシナリオが以前に未知のユーザが手動のオペレータ介入を必要としないで彼の資格証明書をアップロードするところです。 S14。 プロトコルは資格証明サーバの倉庫の大量の初期値設定を防いではいけません。 S15。 プロトコルSHOULDは最小量のクライアント構成を必要とします。
3.4 Requirements for Direct-Transfer Solutions
3.4 直接移転対策のための要件
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.)
以下の要件は資格証明書の「ダイレクトな」1台のデバイスから別のデバイスまでの転送をサポートするソリューションに適用されます。 (この場合「ダイレクトに」の意味に関する注に関してセクション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。 それ、SHOULD、受信デバイスが認証するのにおいて、本当に、資格証明パッケージが主張された送付デバイスから来たのを可能であってください。 D2。 送付者が資格証明書が受取人によって受け取られて、それがSHOULDであることを知る命令では、受信デバイスが資格証明領収書の承認を送付デバイスに送り返して、送付デバイスがこの承認を認証するのにおいて可能であってください。
4. Security Considerations
4. セキュリティ問題
4.1 Hardware vs. Software
4.1 ハードウェア対ソフトウェア
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プロトコルの使用で改良されるかもしれません(パスワードの暗号化されたファイルと比較されます)。
Arsenault & Farrell Informational [Page 10] RFC 3157 SACRED - Requirements August 2001
Arsenaultとファレル情報[10ページ]のRFC3157SACRED--、要件2001年8月
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クライアントソフトウェアの交換がいつも可能になる、そのようなプログラムはプログラムの作者にユーザ名とパスワードをメールするかもしれません。
4.2 Auditing
4.2 監査
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.
サポートされるべきですが、プロトコルの範囲から、開発が警戒とアカウントロックを含んでいるということである同様のメカニズム、認証失敗は以下で特に繰り返されました。
4.3 Defense against attacks
4.3 攻撃に対するディフェンス
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
さらに、資格証明サーバはサービス不能攻撃のための主な対象です。 かなり、資格証明サーバが確実に正統のユーザにとって入手できなくなるようにするのは攻撃者の役に立つことができます。 必要な資格証明書を検索できなかったユーザは強制されるかもしれません。
Arsenault & Farrell Informational [Page 11] RFC 3157 SACRED - Requirements August 2001
Arsenaultとファレル情報[11ページ]のRFC3157SACRED--、要件2001年8月
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メッセージ・フォーマット」、RFC2440、1998年11月。
[PKCS12] "PKCS #12 v1.0: Personal Information Exchange Syntax
Standard", RSA Laboratories, June 24, 1999.
[PKCS12]、「PKCS#12v1.0:」 「個人情報交換構文規格」、RSA研究所、1999年6月24日。
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630,
June 1999.
[cm] Housley、R.、「暗号のメッセージ構文」、RFC2630、1999年6月。
[PKCS15] "PKCS #15 v1.1: Cryptographic Token Information Syntax
Standard," RSA Laboratories, June 2000.
[PKCS15]、「PKCS#15v1.1:」 「暗号のトークン情報構文規格」、RSA研究所、2000年6月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2026] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2277] Alvestrand, H., " IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand、H.、「文字コードと言語に関するIETF方針」、BCP18、RFC2277、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公開鍵暗号基盤証明書管理プロトコル」、RFC2510、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.、Gettys、J.、ムガール人、J.、Frysyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「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).
作者は、追加使用を含むテキストがAppendixでニール・Mcバーネット( nealmcb@avaya.com )によって供給されたBをケースに入れると感謝して認めます。
Arsenault & Farrell Informational [Page 12] RFC 3157 SACRED - Requirements August 2001
Arsenaultとファレル情報[12ページ]のRFC3157SACRED--、要件2001年8月
Authors' Addresses
作者のアドレス
Alfred Arsenault Diversinet Corp. P.O. Box 6530 Ellicott City, MD 21042 USA
アルフレッドArsenault Diversinet社のP.O. Box6530エリコットMD21042市(米国)
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
スティーブン・ファレル、ボルチモア技術、39Parkgate通り、ダブリン8アイルランド
Phone: +353-1-881-6000 EMail: stephen.farrell@baltimore.ie
以下に電話をしてください。 +353-1-881-6000 メールしてください: stephen.farrell@baltimore.ie
Arsenault & Farrell Informational [Page 13] RFC 3157 SACRED - Requirements August 2001
Arsenaultとファレル情報[13ページ]のRFC3157SACRED--、要件2001年8月
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.
SACRED 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.
したがって、資格証明書が1台のデバイスから別のデバイスまで動かされるのを許容して、環境で十分なセキュリティのレベルを前提とする補足的なソフトウェアベースの解決策を見いだすのは適切です。 私たちが、ソフトウェアソリューションによって提供されたセキュリティのレベルが上で議論したハードウェア解決によって提供されたそれほど高くないかもしれないと認めて、いくつかの組織が、それが全く十分であると考えていないかもしれない間、私たちは、価値がある解決策を見いだすことができると信じています。
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プロトコルは、ハードウェアデバイスの上に保存される資格証明書のアップデートに標準のメカニズムを提供することによって、ハードウェア資格証明書解決の補足となることができます。 今日、これは、しばしば管理センターへのデバイスを(with)に返すのが必要であり、高価であるかもしれません。センターはしばしば不便です。 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プロトコルがこれらが使用するすべてにケースを支えるNOT REQUIREDである、すなわち、本稿は純粋に有益です。
Arsenault & Farrell Informational [Page 14] RFC 3157 SACRED - Requirements August 2001
Arsenaultとファレル情報[14ページ]のRFC3157SACRED--、要件2001年8月
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:
一般に、このシナリオに必要であるvThe PKI移動性サポートは他の移動性シナリオと同様です。 しかしながら、それには、いくつかのユニークな局面があります:
Arsenault & Farrell Informational [Page 15] RFC 3157 SACRED - Requirements August 2001
Arsenaultとファレル情報[15ページ]のRFC3157SACRED--、要件2001年8月
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. ホームワークステーションの上で同様に他のユーザへの適切なカリフォルニア証明書と同等の証明書を永久に、保存するか、またはキャッシュできます。
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.
多くの大学と大学は一般的な学生人口に従って使用に利用可能なコンピュータ・システムでいっぱいの研究室を経営します。 これらのコンピュータは同じハードウェアで通常構成されます、そして、研究室でシステムのすべてに模写されるオペレーティングシステムは建てます。 他のものがセントラルサーバーの個人的なファイルのために個々の椎間腔を提供しているかもしれない間、多くの典型的な構成はどんなタイプの永久記録媒体も全く提供しません。一般に、何らかの体系が、オペレーティングシステムの構成がユーザの向こう側に保存されて、次のユーザがログインする前に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.
しばしば公立の研究室を経営するのに使用される同じ基本的な技術的解決法はそうです、また、一般に、使用されて、環境が数個にシェアのa単一のワークステーションを住ませます。 これは交替制の仕事がある複数の時間帯に対するサービスを提供する医療設備やサービス・ビューロなどの位置でしばしば見つけられます。
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接続と共にネットワークでつながれます。
Arsenault & Farrell Informational [Page 16] RFC 3157 SACRED - Requirements August 2001
Arsenaultとファレル情報[16ページ]のRFC3157SACRED--、要件2001年8月
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. コンピュータ・システムの構成は中心で維持されます、そして、改造は比較的実装しやすいです。 例えば、PKIの企業ルート証明書、LDAPサーバ構成、専門化しているソフトウェア、およびいかなる他の必要な部品もワークステーションにロードするのは簡単でしょう。
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. 適切なカリフォルニア証明書とカスタムソフトウェアは、これらのタイプの共有システムのために容易に加えられて、維持されます。
3. The workstations are installed in public locations and users will
frequently forget to close applications before permanently walking
away from the workstation.
3. ワークステーションは公共の位置にインストールされます、そして、ユーザは頻繁にワークステーションから無傷で助かって、永久に前にアプリケーションを終えるのを忘れるでしょう。
Arsenault & Farrell Informational [Page 17] RFC 3157 SACRED - Requirements August 2001
Arsenaultとファレル情報[17ページ]のRFC3157SACRED--、要件2001年8月
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.
中、私たち、ますますモビリティ社会、いつ、大物が正常なコンピューティング場所から遠くにいるかという情報を必要とするという可能性。 電話番号を調べる必要があるかもしれません。 あなたは最近、公衆電話で電話帳を見つけようとしましたか? 急いで行く次の場所を見つけるのにデータデバイスを使用するのは必要になるかもしれません。 ワイヤレス機器(電子革ひも)の増殖によって、他のものには、電子情報への迅速なアクセスの必要性を作成する能力があります。 ポケットベルはEメールインボックスかアドレス帳をチェックする必要性を生むことができます。 携帯電話は、緊急提案に答えるためにあなたのデータベースまであなたを運転できます。
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、ファイヤーワイヤ、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. 「トークン」を得ます。 以来、ネットワークからトークン(キー、証明書、資格証明書)を得るのが必要でしょう。 トランジットの間、どうしたらそれを保護できますか?
Arsenault & Farrell Informational [Page 18] RFC 3157 SACRED - Requirements August 2001
Arsenaultとファレル情報[18ページ]のRFC3157SACRED--、要件2001年8月
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. あなたがいなくなるとき、何が象徴に起こりますか? どうアダルト飲料店に着くかから見つけられたその超安全なレシピサーバからのあなたのメール、ダウンロードされたaレシピをチェックした、… えー… 食事のためのアクセサリー、…あなたはオフです! あなたの象徴はそうですか? または、あなたのチケットの上に情報ハイウェイに気付いて、ゆっくり走らせるのを楽器店から出て来るそれらの子供を待ちながら、それは公立のキオスクにそこにまだ座っていますか?
Arsenault & Farrell Informational [Page 19] RFC 3157 SACRED - Requirements August 2001
Arsenaultとファレル情報[19ページ]のRFC3157SACRED--、要件2001年8月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Arsenault & Farrell Informational [Page 20]
ArsenaultとファレルInformationalです。[20ページ]
一覧
スポンサーリンク
