Network Working Group D. Gustafson
Request for Comments: 3760 Future Foundation
Category: Informational M. Just
Treasury Board of Canada
M. Nystrom
RSA Security
April 2004
Securely Available Credentials (SACRED) - Credential Server Framework
安全に利用可能な資格情報（SACRED） - 資格・サーバー・フレームワーク
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 (2004). All Rights Reserved.
著作権（C）インターネット協会（2004）。全著作権所有。
Abstract
抽象
As the number, and more particularly the number of different types, of devices connecting to the Internet increases, credential mobility becomes an issue for IETF standardization. This document responds to the requirements on protocols for secure exchange of credentials listed in RFC 3157, by presenting an abstract protocol framework.
数として、より具体的にインターネット増加に接続するデバイスの異なるタイプの数、資格移動度はIETF標準化のために問題となります。この文書では、抽象プロトコルフレームワークを提示することによって、RFC 3157に記載されている資格情報を安全にやり取りするためのプロトコル上の要求に応答します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Functional Overview. . . . . . . . . . . . . . . . . . . . . . 2
2.1. Definitions. . . . . . . . . . . . . . . . . . . . . . . 2
2.2. Credentials. . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Network Architecture . . . . . . . . . . . . . . . . . . 5
3. Protocol Framework . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Credential Upload. . . . . . . . . . . . . . . . . . . . 8
3.2. Credential Download. . . . . . . . . . . . . . . . . . . 10
3.3. Credential Removal . . . . . . . . . . . . . . . . . . . 11
3.4. Credential Management. . . . . . . . . . . . . . . . . . 12
4. Protocol Considerations. . . . . . . . . . . . . . . . . . . . 12
4.1. Secure Credential Formats. . . . . . . . . . . . . . . . 12
4.2. Authentication Methods . . . . . . . . . . . . . . . . . 13
4.3. Transport Protocol Suites. . . . . . . . . . . . . . . . 16
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 17
5.1. Communications Security. . . . . . . . . . . . . . . . . 17
5.2. Systems Security . . . . . . . . . . . . . . . . . . . . 18
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.1. Normative References . . . . . . . . . . . . . . . . . . 20
6.2. Informative References . . . . . . . . . . . . . . . . . 20
7. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21
8. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 22
1 Introduction
1はじめに
Digital credentials, such as private keys and corresponding certificates, are used to support various Internet protocols, e.g., S/MIME, IPSec, and TLS. In a number of environments end users wish to use the same credentials on different end-user devices. In a "typical" desktop environment, the user already has many tools available to allow import/export of these credentials. However, this is not very practical. In addition, with some devices, especially wireless and other more constrained devices, the tools required simply do not exist.
そのような秘密鍵とそれに対応する証明書などのデジタル資格情報は、様々なインターネットプロトコル、例えば、S / MIME、IPSecの、およびTLSをサポートするために使用されています。環境の数では、ユーザーが別のエンドユーザデバイスで同じ資格情報を使用したい終了。 「典型的な」デスクトップ環境では、ユーザーはすでにこれらの資格情報のインポート/エクスポートを可能にするために使用できる多くのツールを持っています。しかし、これは非常に実用的ではありません。また、いくつかの特に無線機器、および他のより制約の装置で、単純に必要なツールは存在しません。
This document proposes a general framework for secure exchange of such credentials and provides a high level outline that will help guide the development of one or more securely available credentials (SACRED) credential exchange protocols.
この文書では、そのような資格情報を安全に交換するための一般的な枠組みを提案し、一つ以上の安全利用可能なクレデンシャル（SACRED）資格交換プロトコルの開発を導くのを助ける高レベル概要を提供します。
Requirements for SACRED are fully described in [RFC3157]. These requirements assume that two distinctly different network architectures will be created to support credential exchange for roaming users:
SACREDための要件は完全には[RFC3157]に記載されています。これらの要件は明確に異なる2つのネットワーク・アーキテクチャは、ユーザーのローミングのための資格情報交換をサポートするために作成されることを前提としています。
a) Client/Server Credential Exchange b) Peer-to-Peer Credential Exchange
a）は、クライアント/サーバ資格情報交換b）のピア・ツー・ピアの資格交換
This document describes the framework for one or more client/server credential exchange protocols.
この文書では、1つ以上のクライアント/サーバーの資格情報の交換プロトコルのためのフレームワークについて説明します。
In all cases, adequate user authentication methods will be used to ensure credentials are not divulged to unauthorized parties. As well, adequate server authentication methods will be used to ensure that each client's authentication information (see Section 2.1) is not compromised, and to ensure that roaming users interact with intended/authorized credential servers.
すべての場合において、十分なユーザ認証方法は、資格情報が権限のない者には明かされていないことを確認するために使用されます。同様に、十分なサーバーの認証方法は、各クライアントの認証情報が（2.1節を参照）を損なわれないことを保証するために、ローミングユーザーが意図した/認可資格のサーバーと相互作用することを確実にするために使用されます。
This section provides definitions for several terms or phrases used throughout this document.
このセクションでは、この文書全体で使用されるいくつかの用語やフレーズの定義を提供します。
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED" and "MAY" in this document are to be interpreted as described in [RFC2119].
キーワード「MUST」、「MUST NOT」は、「SHOULD NOT」、「推奨」および「SHOULD」本書では[RFC2119]で説明されるように解釈される「場合があります」。
client authentication information: information that is presented by the client to a server to authenticate the client. This may include a password token, a registration string that may have been received out-of-band (and possibly used for initially registering a roaming user) or data signed with a signature key belonging to the client (e.g., as part of TLS [RFC2246] client authentication).
クライアント認証情報：クライアントを認証するために、サーバーにクライアントから提示された情報。これは、パスワード・トークン、（最初はローミングユーザーを登録するために使用し、おそらく）の帯域外受信されている可能性があり、登録文字列が含まれるか、TLSの一部として、例えば（クライアントに属する署名鍵で署名されたデータも[ RFC2246]クライアント認証）。
credentials: cryptographic objects and related data used to support secure communications over the Internet. Credentials may consist of public/private key pairs, symmetric keys, X.509 public key certificates, attribute certificates, and/or application data. Several standardized formats for the representation of credentials exist, e.g., [PKCS12], [PKCS15] (see "secured credentials" below).
資格情報：暗号オブジェクトやインターネット上での安全な通信をサポートするために使用される関連データ。資格情報は、公開鍵/秘密鍵のペア、対称鍵、X.509公開鍵証明書、属性証明書、および/またはアプリケーションデータから構成されてもよいです。資格情報の表現のためのいくつかの標準化されたフォーマットは、例えば、[PKCS12]、[PKCS15]（以下、「保護された資格情報」を参照）、存在します。
passkey: a symmetric key, derived from a password.
パスキー：パスワードから派生した対称キー、。
password: a string of characters known only to a client and used for the purposes of authenticating to a server and/or securing credentials. A user may be required to remember more than one password.
パスワード：クライアントにのみ知られており、サーバーへの認証および/または資格情報を確保する目的で使用される文字列。ユーザーは複数のパスワードを覚えておくことが必要になることがあります。
password token: a value derived from a password using a one-way function that may be used by a client to authenticate to a server. A password token may be derived from a password using a one-way hash function, for example.
パスワードトークン：サーバーへの認証にクライアントによって使用される一方向関数を使用してパスワードから得られた値。パスワードトークンは、例えば、一方向ハッシュ関数を使用してパスワードから導出することができます。
secured credentials: a set of one or more credentials that have been cryptographically secured, e.g., encrypted/MACed with a passkey. Secured credentials may be protected using more than one layer of encryption, e.g., the credential is secured with a passkey corresponding to a user's password and also by a key known only to the server (the credential's stored form). During network transfer, the passkey-protected credential may be protected with an additional encryption layer using a symmetric key chosen by the Credential Server (e.g., the transmitted form).
セキュリティで保護された資格情報：暗号的に確保されている1つ以上の資格情報のセットは、例えば、暗号化/パスキーをMACed。保護された資格情報は、例えば、信任状は、ユーザのパスワードに対応するパスキーで固定し、また、唯一のサーバ（資格情報の格納された形）に知られているキーによってれる、暗号化の複数の層を使用して保護されていてもよいです。ネットワーク転送中に、パスキーで保護された証明書は、信用証明書サーバ（例えば、送信形式）によって選択された対称鍵を使用して追加の暗号化層で保護されていてもよいです。
strong password protocol: a protocol that authenticates clients to servers securely (see e.g., [SPEKE] for a more detailed definition of this), where the client need only memorize a small secret (a password) and carries no other secret information, and where the server carries a verifier (password token) which allows it to authenticate the client. A shared secret is negotiated between client and server and is used to protect data subsequently exchanged.
強力なパスワードプロトコル：安全にサーバにクライアントを認証するプロトコル、クライアントが唯一の小さな秘密（パスワード）を暗記する必要が、（本のより詳細な定義については、例えば[SPEKE]を参照）、および他の機密情報を運ばないし、どこサーバはクライアントを認証することができます検証（パスワードトークン）を運びます。共有シークレットは、クライアントとサーバー間でネゴシエートされ、続いて交換されるデータを保護するために使用されます。
Note the distinction between an "account password" and a "credential password." An account password (and corresponding password token) is used to authenticate to a Credential Server and to negotiate a key that provides session level encryption between client and server.
「アカウントのパスワード」との区別に注意してください「の資格パスワードを。」アカウントパスワード（および対応するパスワードトークン）が信用証明書サーバへの認証に、クライアントとサーバ間のセッション・レベルの暗号化を提供し、キーを交渉するために使用されます。
A credential password is used to derive a passkey that's used to provide persistent encryption and authentication for a stored credential. Applicable secured credential standards documents (e.g., [PKCS15]) describe the technical details of specific password-based-encryption (pbe) techniques that are used to protect credentials from unauthorized use.
資格パスワードが保存された資格のための永続的な暗号化と認証を提供するために使用されますパスキーを導出するために使用されます。適用を確保資格規格文書は、（例えば、[PKCS15]）特定のパスワードベース暗号化（PBE）不正使用からの資格情報を保護するために使用されている技術の技術的な詳細を説明します。
Although the same password value may be used to provide both services, it is likely that different, algorithm specific passkeys would be generated from this password (i.e., because of different salt values, etc.).
同じパスワード値は、両方のサービスを提供するために使用することができるが、異なる、アルゴリズム特定パスキーこのパスワードから（すなわち、理由等異なる塩値の）が生成される可能性があります。
In addition, although it may be more convenient for a user to remember only a single password, differing security policies (e.g., password rules) between the credential server and the credential issuers may result in a user having to remember multiple passwords.
ユーザーがクレデンシャルサーバと複数のパスワードを覚える必要がユーザーをもたらすことができる資格の発行体との間にセキュリティポリシー（例えば、パスワードルール）が異なるだけで、単一のパスワードを覚えておくために加えて、けれどもそれがより便利かもしれません。
This document is concerned with the secure exchange and online management of credentials in a roaming or mobile environment. Credentials MAY be usable with any end user device that can connect to the Internet, such as:
この文書では、ローミングやモバイル環境での資格情報の安全な交換とオンライン管理と懸念しています。資格情報のような、インターネットに接続することができる任意のエンドユーザ装置と使用可能です。
- desktop or laptop PC - mobile phone - personal digital assistant (PDA) - etc.
- デスクトップまたはラップトップPC - 携帯電話 - 携帯情報端末（PDA） - など
The end user system may, optionally, store its credential information on special hardware devices that provide enhanced portability and protection for user credentials.
エンドユーザのシステムは、必要に応じて、ユーザーの資格情報のために強化された携帯性と保護を提供する特別なハードウェア・デバイス上での資格情報を格納することができます。
Since the credential usually contains sensitive information that is known only to the credential holder, credentials MUST NOT be sent in the clear during network transmission and SHOULD NOT be in the clear when stored on an end user device such as a diskette or hard drive. For this reason, a secured credential is defined. Throughout this document we assume that, at least from the point of view of the protocol, a secured credential is an opaque (and at least partially privacy and integrity protected) data object that can be used by a network connected device. Once downloaded, clients must be able to recover their credentials from this opaque format.
クレデンシャルは通常のみ資格保持者にはよく知られている機密情報が含まれているので、資格情報は、ネットワーク伝送中に平文で送信されてはいけませんと、ディスケットまたはハードドライブなどのエンドユーザデバイスに格納されているときに明らかにされるべきではありません。このため、セキュリティで保護された資格情報が定義されています。本明細書を通して、我々はプロトコルの観点から、少なくとも、保護された資格が不透明（少なくとも部分的にプライバシーおよび完全性保護された）ネットワーク接続されたデバイスで使用可能なデータオブジェクトである、と仮定する。ダウンロードしたら、クライアントはこの不透明な形式から自分の資格情報を回復できなければなりません。
At a minimum, all supported credential formats SHOULD provide privacy and integrity protection for private keys, secret keys, and any other data objects that must be protected from disclosure or modification. Typically, these security capabilities are part of the basic credential format such that the credential (e.g., a data file) is protected when stored on hard drives, flexible diskettes, etc.
最低でも、すべてのサポートされている資格情報の形式は、秘密鍵、秘密鍵、および開示または変更から保護されなければならない任意の他のデータオブジェクトのプライバシーと完全性保護を提供する必要があります。典型的には、これらのセキュリティ機能等のハードドライブ、フレキシブルディスケット、上に格納されたときにクレデンシャル（例えば、データファイル）が保護されているような基本的な信用証明書フォーマットの一部であります
During network transmission, the secured credential is protected with a second (outer) encryption layer. The outer encryption layer is created using a session-level encryption key that was derived during the mutual authentication process. Effectively, secured credentials traverse an "encrypted tunnel" that provides an additional layer of privacy protection for credentials (and any other) information exchanged.
ネットワーク送信中に、保護された資格情報は、第二（外側）の暗号化層で保護されています。外側の暗号化層は、相互認証プロセス中に誘導されたセッション・レベルの暗号化キーを使用して作成されます。効果的に、固定された資格情報は、資格情報のプライバシー保護の追加の層（及びその他）交換される情報を提供する「暗号化トンネル」を横切ります。
The network diagram below shows the components involved in the SACRED client/server framework.
下記のネットワークダイアグラムはSACREDクライアント/サーバフレームワークに関連するコンポーネントを示しています。
+--------+ +------------+
| Client +-----------| Credential |
+--------+ 1 | Server |
\ +-----+------+
\ |
\ | 2
\ |
\ 3 +-----+------+
-----------| Credential |
| Store(s) |
+------------+
Client - The entity that wants to retrieve their credentials from a credential server.
クライアント - 資格サーバーから自分の資格情報を取得しようとするエンティティ。
Credential Server - The server that downloads secure credentials to and uploads them from the client. The server is responsible for authenticating the client to ensure that the secured credentials are exchanged only with an appropriate end user. The credential server is authenticated to the client to ensure that the client's authentication information is not compromised and so that the user can trust the credentials retrieved.
信用証明書サーバ - への安全な認証情報をダウンロードし、クライアントからアップロードし、サーバー。サーバーはセキュリティで保護された資格情報は、該当するエンドユーザーとの間で交換されることを保証するために、クライアントを認証するための責任があります。信用証明書サーバは、クライアントの認証情報が損なわれないことを保証するために、クライアントに認証されたユーザは、取得した資格証明書を信頼できるようにします。
Credential Store - The repository for secured credentials. There might be access control features but those generally aren't sufficient in themselves for securing credentials. The credential server may be capable of splitting credentials across multiple credential stores for redundancy or to provide additional levels of protection for user credentials.
資格証明ストア - セキュリティで保護された資格情報のリポジトリ。そこアクセス制御機能であってもよいが、これらは一般的に資格情報を保護するために自分自身では十分ではないかもしれません。信用証明書サーバは、冗長性のために複数の資格証明ストア間クレデンシャルを分割することが可能であってもよいし、ユーザーの資格情報の保護の追加レベルを提供します。
Protocol 1 - The protocol used to authenticate the client and credential server, and download and upload user credentials from a credential server.
プロトコル1 - クライアントと信用証明書サーバを認証、および信用証明書サーバからユーザ証明書をダウンロードし、アップロードするために使用されるプロトコル。
Protocol 2 - The protocol used by the Credential Server to store and retrieve user credentials (LDAP, LDAP/SSL, or other).
プロトコル2 - ユーザーの資格情報（LDAP、LDAP / SSL、または他の）を格納および取得するために信用証明書サーバが使用するプロトコル。
Protocol 3 - The protocol used by the client to store and retrieve user credentials from the credential store (LDAP, LDAP/SSL, or other).
プロトコル3 - 資格証明ストア（LDAP、LDAP / SSL、または他の）からユーザーの資格情報を格納および取得するためにクライアントによって使用されるプロトコル。
This framework describes the high level design for protocol 1. Protocols 2 and 3 are closely related (but out of scope for this document) and could be implemented using standard protocols, such as LDAP or secure LDAP, or other standard or proprietary protocols. Note also that any administrator-credential server protocols are assumed to be server vendor specific and are not the subject of SACRED standardization efforts at this time.
このフレームワークは、1プロトコル2および3は密接に関連した（しかし、この文書の範囲外）されているプロトコルのための高レベルの設計を説明し、そのようなLDAPまたはセキュアLDAP、または他の標準または独自のプロトコルなどの標準プロトコルを使用して実施することができます。任意の管理者の資格証明サーバプロトコルは、サーバベンダ固有であると仮定し、この時点でSACRED標準化の努力の対象ではありませんされていることにも注意してください。
Clients are not precluded from exchanging credentials directly with a credential store (or any other server of it's choosing). However, mutual authentication with roaming users and a consistent level of protection for credential data while stored on network servers and while in transit is provided by SACRED protocols exchanged with the credential server. Depending on credential server design, user credentials may flow through the credential server to the credential store or directly between the client and the credential store.
クライアントは資格証明ストア（または、それは選択だの他のサーバ）との直接の資格情報をやり取りから除外されません。ただし、ネットワークサーバーに保存されている間、輸送中にSACREDプロトコルによって提供されている間、ユーザーとクレデンシャルデータの保護の一貫したレベルをローミングとの相互認証は、信用証明書サーバと交換しました。信用証明書サーバの設計に応じて、ユーザーの資格情報は、資格証明ストアへの信用証明書サーバを介して流れるか、直接クライアントと資格証明ストアの間にあります。
Also, users may upload their credentials to several credential servers to obtain enhanced levels of availability. Coordination (automatic replication) of user information or credential data among several credential servers is currently beyond the scope of this document.
また、ユーザーは、可用性の強化レベルを得るために、いくつかの資格のサーバーに資格情報をアップロードすることができます。複数の資格証明サーバ間でのユーザ情報や資格データの調整（自動複製）は、現在、このドキュメントの範囲を超えています。
This section provides a high level description of client/server protocols that can be used to exchange and manage SACRED credentials.
このセクションでは、SACRED資格情報を交換し、管理するために使用することができ、クライアント/サーバプロトコルの高レベルの記述を提供します。
The client/server credential exchange protocol is based on three basic and abstract operations; "GET", "PUT", and "DELETE". The secured credential exchange protocol is accomplished as follows:
クライアント/サーバーのクレデンシャルの交換プロトコルは、3つの基本的な抽象操作に基づいています。 "PUT"、 "GET"、および "DELETE"。次のように固定された資格情報交換プロトコルが達成されます。
connect - the client initiates a connection to a credential server for the purpose of secure credential exchange.
接続 - クライアントは、安全な資格情報交換を目的とした信用証明書サーバへの接続を開始します。
mutual authentication/key negotiation - using a strong password protocol (or equivalent) the client authenticates to the server, the server authenticates to the client, and a session level encryption key is negotiated. The details of the mutual authentication protocol exchange are dependent upon the particular authentication method used. In all cases, the end result is to authenticate the client to the server and server to the client, and establish a strong, shared secret between the two parties.
相互認証/キー交渉 - 強力なパスワードのプロトコル（または同等）を使用して、クライアントがサーバーに認証し、サーバーはクライアントに認証し、セッション・レベルの暗号化キーがネゴシエートされます。相互認証プロトコル交換の詳細は、使用される特定の認証方法に依存します。すべての場合において、最終的な結果は、クライアントにサーバとクライアントをサーバーに認証し、両者の間には強い、共有秘密を確立することです。
client request(s) - the SACRED client issues one or more high level credential exchange requests (e.g., GET, PUT, or DELETE).
クライアント要求（S） - SACREDクライアントが1つ以上の高レベルの資格情報の交換要求を発行する（例えば、GET、PUT、またはDELETE）。
server response(s) - the SACRED credential server responds to each request, either performing the operation successfully or indicating an appropriate error.
サーバ応答（S） - SACRED信用証明書サーバが正常に動作を実行するか、または適切なエラーを示すいずれか、各要求に応答します。
close - the client indicates it has no more requests for the server at this time. The security context between client and server is no longer needed. Close is a logical, session management operation.
クローズ - クライアントは、この時点で、サーバーのためのより多くの要求を持っていないことを示します。クライアントとサーバ間のセキュリティコンテキストが不要になりました。閉じるには、論理、セッション管理操作です。
disconnect - the parties disconnect the transport level connection between client and server. Note that "connect" and "disconnect" are logical, transport-layer dependent operations that enclose the protocol exchange between the two communicating processes.
切断 - 当事者は、クライアントとサーバ間のトランスポートレベルの接続を切断します。なお、「接続」と「切断」の2つの通信プロセス間のプロトコル交換を囲む論理、トランスポート層に依存する動作です。
Each high-level credential exchange operation is made up of a series of request-response pairs. The client initiates each request, which the server processes before returning an appropriate response. Each request must complete (server reports success or failure) before the client issues the next request. The server SHOULD be willing to service at least one upload or download request following successful mutual authentication but either party can terminate the logical connection at any time.
各ハイレベルの資格証明の交換操作が要求 - 応答ペアの系列から構成されています。クライアントは、適切な応答を返す前に、各要求、サーバプロセスを開始します。クライアントは次のリクエストを発行する前に各要求は（サーバーが成功または失敗を報告します）完了する必要があります。サーバーは、成功した相互認証以下の少なくとも一つのアップロードまたはダウンロード要求にサービスを提供することをいとわないはずですが、いずれかの当事者は、いつでも論理的な接続を終了することができます。
In the following sections, secured credentials and related values are represented using the following notation:
以下のセクションでは、保護された資格情報と関連する値は、次の表記法を使用して表されます。
SC-x is the secured credential file, which includes a format identifier field and credential data. The credential data is an opaque, encrypted data object (e.g., PKCS#15 or PKCS#12 file). The format identifier is needed to correctly parse the credential data.
SC-Xは、フォーマット識別子フィールドおよび資格データを含む固定資格ファイル、です。資格証明データは、不透明、暗号化されたデータオブジェクト（例えば、PKCS＃15またはPKCS＃12ファイル）です。フォーマット識別子が正しく資格データを解析するために必要とされます。
Name-x is an account-defined selector or locator (a user friendly name) that is used to indicate a specific secured credential. The name of each credential stored under a given user account MUST be unique e.g., there may be one credential called "financial" and another called "healthcare", etc. At a minimum, credential names MUST be unique across a given account/user name. When no name is supplied for a GET operation, all credentials stored for the given username will be returned.
名前-xは、特定の保護された資格情報を示すために使用されるアカウントに定義されたセレクタまたはロケータ（ユーザーフレンドリー名）です。特定のユーザーアカウントで格納されている各資格の名前はユニークでなければならない例えば、最低でも「金融」と「ヘルスケア」と呼ばれる別、などと呼ばれる1つの資格があるかもしれない、資格名が与えられたアカウント/ユーザー名で一意である必要があります。名前がGET操作のために供給されていない場合は、指定されたユーザー名のために保存されているすべての資格情報が返されます。
ID-x is a distinct credential version indicator that MAY be used to request a conditional GET/PUT/DELETE operation. This credential-ID value SHOULD contain the server's "last-modified" date and time (e.g., the time that this particular credential version was stored on the server) and MAY contain additional information such as a sequence number or a (complete or partial) credential fingerprint that is used to ensure the credential-ID is unique from other credential versions stored under the same user account and credential name.
ID-Xは、条件付きのGET / PUT / DELETEオペレーションを要求するために使用されるかもしれ異なる資格バージョンインジケータです。この資格-ID値は、サーバの「最終更新」の日付と時刻（例えば、この特定の資格のバージョンがサーバ上に格納された時間）を含むべきであると、このようなシーケンス番号または（完全または部分的）などの追加情報が含まれる場合があり資格-IDを確保するために使用される資格指紋が同じユーザーアカウントと資格名の下に格納されている他の資格のバージョンからユニークです。
All named credentials may be accessed by authenticating under a single username. If a user needs or prefers to use more than one distinct authentication password (and/or authentication method) to protect access to several secured credentials, he/she SHOULD register those credentials under distinct user/account names, one for each different authentication method used.
すべての名前の資格情報は、単一のユーザー名で認証することによってアクセスすることができます。ユーザーが必要とする、またはいくつかの確保資格情報へのアクセスを保護するために、複数の異なる認証パスワード（および/または認証方式）を使用することを好む場合は、彼/彼女は明確なユーザー/アカウント名の下に、これらの資格情報を登録する必要があり、それぞれ異なる認証方式の一つが使用さ。
The purpose of a credential upload operation is to allow a client to register new credentials, or replace currently stored credentials (e.g., credentials that may have been updated by the client using appropriate key management software).
資格アップロード操作の目的は、クライアントが新しい資格情報を登録、または現在保存されている資格情報を交換できるようにすることです（例えば、適切なキー管理ソフトウェアを使用して、クライアントによって更新されている可能性が資格情報）。
The framework for the credential upload, as implemented using the PUT operation, is:
資格アップロードするためのフレームワークは、PUT操作を使用して実現されるよう、です。
- The client and server establish a mutually authenticated session and negotiate a shared secret.
- クライアントとサーバが相互に認証されたセッションを確立し、共有秘密を交渉します。
- The client will then issue a PUT message that contains the upload credential and related data fields.
- その後、クライアントは、アップロード資格および関連データフィールドを含むPUTメッセージを発行します。
- The server will respond to the PUT, indicating the credential was successfully stored on the server or that an error occurred.
- サーバーは、サーバーに正常にまたはエラーが発生したことを保存した証明書を示し、PUTに応答します。
The client's PUT request MAY contain an optional identifier (credential-ID) field. If present, the new credential will only be stored if a credential with the same name and credential-ID is currently stored on the server (e.g., a logical REPLACE operation is performed). The server MUST return an error if a client attempts to replace a credential that does not exist on the server.
クライアントのPUTリクエストは、オプションの識別子（資格-ID）フィールドを含むかもしれません。存在する場合、同じ名前とクレデンシャル-IDと信任状が現在のサーバ上に格納されている場合、新たな資格のみが保存される（例えば、REPLACE論理演算が行われます）。クライアントがサーバー上に存在しない資格を交換しようとすると、サーバーはエラーを返さなければなりません。
The credential server's response to a PUT request MUST contain a credential version identifier (credential-ID) for the newly stored credential that MAY be used by clients to optimize subsequent download operations and avoid credential version mismatches.
PUT要求に対する信用証明書サーバの応答は、その後のダウンロード操作を最適化し、資格バージョンの不一致を回避するためにクライアントによって使用されるかもしれ新たに記憶された資格情報の資格バージョン識別子（資格-ID）を含まなければなりません。
The following gives an example of a "credential upload" protocol sequence:
以下は、「資格情報のアップロード」プロトコルシーケンスの例を示します：
client server
------- -------
< connect > -->
<接続> - >
<--- mutual authentication --->
< PUT SC-1, Name-1, [ID-1] > --> <-- < Name-1, new-ID-1 > < PUT SC-2, Name-2, [ID-2] > --> <-- < Name-2, new-ID-2 >
<PUT SC-1、名-1、[ID-1]> - > < - <名-1、新しい-ID-1> <PUT SC-2、名前-2、[ID-2] - > - > < - <名前-2、新-ID-2>
...
。。。
< close > --> <-- OK (+ disconnect)
<クローズ> - > < - OK（+切断）
new-ID-x is the credential-ID of the newly stored credential.
新しい-ID-xは、新たに保存された資格の資格-IDです。
Roaming clients can download their credentials at any time after they have been uploaded to the server.
彼らは、サーバーにアップロードされた後でローミングクライアントは、いつでも自分の資格情報をダウンロードすることができます。
The framework for a credential download, as implemented using the GET operation, is:
GET操作を使用して実装されている資格のダウンロードのためのフレームワークは、次のとおりです。
- The client SHOULD authenticate the server.
- クライアントがサーバを認証すべきです。
- The user MUST be authenticated (by the server).
- ユーザーは（サーバによって）認証されなければなりません。
- A GET request for the credential download is issued.
- 資格のダウンロードのためのGETリクエストが発行されます。
- The response contains the credential and format identifier.
- 応答は、クレデンシャルとフォーマット識別子を含んでいます。
The specific user credential being requested may be identified by name in the message sent to the credential server. If successful, the response MUST contain the requested credential data element (format ID and data) as defined above.
要求されている特定のユーザークレデンシャルは、信用証明書サーバに送信されるメッセージ内の名前によって識別され得ます。成功した場合は上記で定義したように、応答は、要求された資格認定データ要素（フォーマットIDとデータ）を含まなければなりません。
If the user issues a GET request with a NULL credential name field, the server SHOULD return all credentials stored under the current user account.
ユーザーがNULL資格名フィールドでGETリクエストを発行した場合、サーバは、現在のユーザーアカウントの下に保存されているすべての資格情報を返すべきです。
Optionally, the client MAY include a credential-ID to indicate a conditional download request. In this case, the server will return the requested credential if and only if the ID of the credential currently stored on the server does NOT match the ID specified.
必要に応じて、クライアントは、条件付きのダウンロード要求を示すために、資格-IDを含むかもしれません。現在はサーバーに保存されている資格のIDが一致しない場合にのみIDが指定されている場合この場合、サーバは要求された証明書を返します。
The server should return either the requested credential or a distinct response indicating that the conditional download was not performed (e.g., the client already has a copy of this exact credential).
サーバは、要求された資格情報または条件ダウンロード（例えば、クライアントは、既にこの正確な資格のコピーを有する）が行われなかったことを示す明確な応答のいずれかを返さなければなりません。
The following gives an example of a "credential download" protocol sequence:
以下は、「資格情報のダウンロード」プロトコルシーケンスの例を示します：
client server
------- --------
< connect > -->
<接続> - >
<--- mutual authentication -->
< GET Name-1, [ID-1] > --> <-- < SC-1, ID-1' > < GET Name-2, [ID-2] > --> <-- < GET response >
<GET名-1、[ID-1]> - > < - <SC-1、ID-1' > <GET名-2、[ID-2]> - > < - <応答GET>
...
。。。
< close > --> <-- OK (+ disconnect)
<クローズ> - > < - OK（+切断）
Notice that for the second request, no credential has been returned since ID-2, as included in the client's request, matched the identifier for the Name-2 credential.
クライアントのリクエストに含まれるように、第2の要求のために、何の資格は、ID-2が返されていないことに注意してください、名前-2資格のための識別子と一致しました。
The framework for the credential removal, as implemented with the DELETE operation, is:
信任状を除去するためのフレームワークは、DELETE操作で実施されるように、です。
- The credential server MUST be authenticated (by the client) using a method-dependent protocol sequence.
- 信用証明書サーバは、メソッドに依存プロトコルシーケンスを使用して（クライアントによって）認証されなければなりません。
- The user MUST be authenticated (by the server) using a method-dependent protocol sequence.
- ユーザは、メソッドに依存するプロトコルシーケンスを使用して（サーバによって）認証されなければなりません。
- The user then sends a DELETE request message that contains the credential name indicating which credential to remove.
- 次いで、ユーザは、削除するためにどの信用証明を示す資格名が含まれている削除要求メッセージを送信します。
- Optionally, the client may include a credential-ID in the DELETE request. In this case, the credential will be deleted if the request ID matches the ID of the credential currently stored on the server. This may be done to ensure that a client intending to delete their stored credential does not mistakenly delete a different version of the credential.
- 必要に応じて、クライアントはDELETE要求に資格-IDを含むことができます。リクエストIDは現在サーバーに保存されている資格のIDと一致した場合には、この場合には、資格情報が削除されます。これは彼らの保存された資格情報を削除しようとするクライアントが誤って資格の異なるバージョンを削除しないことを確実にするために行うことができます。
The following gives an example of a "credential removal" protocol sequence:
以下は、「資格情報の削除」プロトコルシーケンスの例を示します：
client server
------- --------
< connect > -->
<接続> - >
<-------- mutual authentication -------->
< DEL Name-1, [ID1] > --> <-- < Name-1 deleted > < DEL Name-2, [ID2] > --> <-- < Name-2 deleted >
<DEL名-1、[ID1]> - > < - <名前-1削除> <DEL名-2、[ID2]> - > < - 名前-2が削除<>
...
。。。
< close > --> <-- OK (+ disconnect)
<クローズ> - > < - OK（+切断）
Note that the three operations defined above (GET, PUT, DELETE) can be used to perform the basic credential management operations:
（GET、PUT、DELETE）上記で定義された3つの動作は、基本的な資格管理操作を実行するために使用することができることに留意されたいです。
- add a new credential on the server, - update (replace) an existing credential, and - delete an existing credential.
- 既存の資格情報を削除 - （置き換え）既存の証明書を更新し、そして - 、サーバー上で新しい証明書を追加します。
The information provided for these basic operations might be used to help guide the design of more complex operations such as user registration (add account), user deregistration (remove account), change account password, or list all credentials.
これらの基本的な操作のために提供される情報には、ユーザー登録（アカウントを追加）、ユーザー登録解除（アカウントを削除）、変更アカウントのパスワード、またはすべての資格情報を一覧表示するなど、より複雑な操作の設計を手助けするために使用される可能性があります。
Note that, in the case where a credential with the same name exists on the server, uploading a NULL credential is logically equivalent to removing a previously stored credential.
同じ名前の資格がNULL資格をアップロード、サーバ上に存在する場合に、以前に格納された証明書を除去すると論理的に等価であることに留意されたいです。
To ensure that credentials created on, and uploaded from, one device can be downloaded and used on any other device, there is a need to define a single "mandatory to implement" credential format that must be supported by all conforming client implementations.
上で作成された資格情報、およびからアップロード、1つのデバイスが他のデバイスにダウンロードして使用することができることを確実にするために、すべての適合クライアントの実装によってサポートされている必要があり、単一の「実装が必須」資格のフォーマットを定義する必要があります。
At least two well-defined credential formats are available today: [PKCS12] and [PKCS15].
[PKCS12]と[PKCS15]：少なくとも2つのよく定義された資格情報の形式は、今日利用可能です。
Other optional credential formats may also be supported if necessary. For example, additional credential formats might be defined for use with specific (compatible) client devices. Each credential format MUST provide adequate privacy protection for user credentials when they are stored on flexible diskettes, hard disks, etc.
必要に応じて他の任意の資格フォーマットもサポートすることができます。例えば、追加の資格情報のフォーマットは、特定の（互換の）クライアント装置で使用するために定義されるかもしれません。彼らはなど柔軟ディスケット、ハードディスク、上に格納されている場合、各資格情報のフォーマットは、ユーザーの資格情報のための適切なプライバシー保護を提供しなければなりません
Throughout this document, the credential is treated as an opaque (encrypted) data object and, as such, the credential format does not affect the basic credential exchange protocol.
本明細書を通して、信用証明書は、不透明な（暗号化された）データオブジェクトとして扱われ、など、資格情報のフォーマットは、基本的な信用証明交換プロトコルに影響を及ぼしません。
Authentication is vitally important to ensure that credentials are accepted from and delivered to the authorized end user only. If an unsecured credential is delivered to some other party, the credential may be more easily compromised. If a credential is accepted from an unauthorized party, the user might be tricked into using a credential that has been substituted by an attacker (e.g., an attacker might replace a newer credential with an older credential belonging to the same user).
認証は、資格情報が受け入れられたからとだけ権限のあるエンドユーザに配信されることを保証するために極めて重要です。無担保資格が他の当事者に配信されている場合は、資格情報をより簡単に妥協することができます。資格が無許可の当事者から受理された場合、ユーザーが攻撃者によって置換された資格情報を使用してだまされるかもしれない（例えば、攻撃者は、同じユーザーに属する古い資格に新しい資格情報を交換するかもしれません）。
Ideally, the list of authentication methods should be open ended, allowing new methods to be added as needs are identified and as they become available. For all credentials, the user authentication method and data is defined when a user is first registered with the credential server and may be updated from time to time thereafter by the authorized user.
理想的には、認証方法のリストが開いている必要があり、彼らが利用可能になるようなニーズが識別されているように、新しいメソッドを追加することができ、終わりました。ユーザが最初に信用証明書サーバに登録され、許可されたユーザによってその後随時更新することができるときに、すべての資格情報、ユーザ認証方式とデータが定義されています。
To adequately protect user credentials from unauthorized disclosure or modification in a roaming environment, all SACRED authentication methods MUST provide protection for user credentials in network environments where attackers might attempt to exploit potential security vulnerabilities. See SACRED Requirements [RFC3157], Section 3.1, Vulnerabilities.
適切にローミング環境で、不正な開示または変更からユーザーの資格情報を保護するために、すべてのSACRED認証方法は、攻撃者が潜在的なセキュリティの脆弱性を悪用しようとするかもしれないネットワーク環境でのユーザーの資格情報の保護を提供しなければなりません。 SACRED要件[RFC3157]、セクション3.1、脆弱性を参照してください。
At a minimum, each SACRED authentication method SHOULD ensure that:
最低でも、各SACRED認証方法のことを確保すべきです。
- The server authenticates the client
- The client authenticates the server
- The client and server securely negotiate (or derive) a
cryptographically strong, secret key (e.g., a session key).
- The exchange of one or more user credentials is protected
using this session key.
It is expected that all SACRED client/server protocols will provide each of these basic security functions. Some existing authentication protocols that might be used for this purpose include:
すべてのSACREDクライアント/サーバプロトコルはこれらの基本的なセキュリティ機能のそれぞれを提供することが期待されます。この目的のために使用される可能性がありますいくつかの既存の認証プロトコルは、次のとおりです。
- Strong password protocols - TLS
- 強力なパスワードプロトコル - TLS
Sections 4.2.1 and 4.2.2 provide some guidance about when to use these authentication methods based on the generic security capabilities they provide and the security elements (passwords, key pairs, user certificates, CA certificates) that must be available to the SACRED client.
セクション4.2.1と4.2.2は、それらが提供する一般的なセキュリティ機能とSACREDクライアントに利用可能でなければならないセキュリティ・エレメント（パスワード、鍵ペア、ユーザー証明書、CA証明書）に基づいて、これらの認証方式を使用するときについていくつかのガイダンスを提供します。
Strong password protocols such as those described in [RFC2945], [BM92], [BM94], and [SPEKE] MAY be used to provide mutual authentication and privacy for SACRED protocols.
このような[RFC2945]に記載されているような強力なパスワードプロトコルは、[BM92]、[BM94]、および[SPEKE]はSACREDプロトコル用の相互認証とプライバシーを提供するために使用され得ます。
All strong password protocols require that user-specific values (i.e., a passtoken and related values) be configured within the server. Only a party who knows the password can calculate the verifier value. It must be securely delivered to the server at a time when the client establishes a relationship with the server. At connect time, messages are exchanged between the two parties and complementary algorithms are used to compute a shared common value known only to the legitimate user and the server. Both parties derive a strong (symmetric) key that may be used to secure communications between the two parties.
すべての強力なパスワードプロトコルは、ユーザ固有の値（すなわち、passtokenと関連する値）がサーバ内に構成されることを必要とします。パスワードを知っている唯一の政党は、検証値を計算することができます。これは、安全に、クライアントがサーバーとの関係を確立時にサーバーに配信されなければなりません。接続時に、メッセージが2者間で交換され、補完的なアルゴリズムは唯一の正当なユーザとサーバに知られている共通の値を計算するために使用されています。両当事者は、両当事者間の通信を保護するために使用することができる強力な（対称）鍵を導出します。
TLS authentication may either be mutual between the client and server or unilateral where only the server is authenticated to the client. These options are described in the next two subsections.
TLS認証は、サーバがクライアントに認証されたクライアントとサーバまたは一方的との相互のいずれかであってもよいです。これらのオプションは、次の2つのサブセクションで説明されています。
In both cases, TLS can be used to authenticate the server whenever the TLS client has been pre-configured with the necessary certificates needed to validate the server's certificate chain (including revocation status checking).
どちらの場合も、TLSは、TLSクライアントが（失効ステータスのチェックを含む）、サーバの証明書チェーンを検証するのに必要な証明書で事前に設定されている時はいつでもサーバーを認証するために使用することができます。
TLS Server Authentication (sTLS)
TLSサーバー認証（STLS）
TLS provides a basic secure session capability (sometimes called server-side TLS) whereby the client authenticates the server and a pair of session level encryption keys is securely exchanged between client and server. Following server authentication and security context setup, all client requests and server responses exchanged are integrity and privacy protected.
TLSは、クライアントがサーバを認証し、セッション・レベルの暗号化キーのペアが確実にクライアントとサーバの間で交換される（時々サーバー側TLSと呼ばれる）基本的なセキュア・セッション機能を提供します。サーバー認証とセキュリティコンテキストの設定に続いて、すべてのクライアント要求とサーバの応答が交換完全性とプライバシ保護されています。
Protocol designers and implementors should be aware that the flexibility of the certificate-based TLS server authentication method creates security risks that need to be mitigated. Specifically, the need to ensure the user is connected to the intended credential server (secure site), and no other. The TLS v1.0 standard [RFC2246] identifies the basis for managing this risk in section F.3 (see also Section 5.2 in this document):
プロトコルの設計者と実装者は、証明書ベースのTLSサーバ認証方式の柔軟性を軽減する必要があるセキュリティリスクを作成することに注意する必要があります。具体的には、ユーザを確実にする必要が意図した信用証明書サーバ（セキュアサイト）、およびなし他に接続されています。 TLS v1.0の標準[RFC2246]（この文書でも、5.2節を参照してください）セクションF.3でこのリスクを管理するための基礎を識別します。
"Implementations and users must be careful when deciding which certificates and certificate authorities are acceptable; a dishonest certificate authority can do tremendous damage."
「許容された証明書と認証局を決定する際に実装し、ユーザーが注意しなければなりません。不正認証局は、多大な被害を行うことができます。」
Note also that a faulty implementation of (increasingly complex) TLS server certificate chain processing, by the SACRED client, could lead to similar compromise, allowing successful credential server masquerade or man-in-the-middle attacks.
（ますます複雑）TLSサーバー証明書チェーン処理の障害のある実装は、SACREDクライアントによって、成功した信用証明書サーバのなりすましやman-in-the-middle攻撃が可能、同様の妥協につながる可能性があることにも注意してください。
An engineering approach that provides an enhanced or augmented server authentication method may be warranted for SACRED protocol designs. It is also important to understand that simple layering of independently developed security protocols (e.g., using BEEP or similar layering techniques) produces a complex, multilayer security protocol that might be easily defeated by a combination-specific attack that is able to expose and exploit known weaknesses of the individual protocol(s).
増強または増補サーバーの認証方法を提供し、エンジニアリングのアプローチがSACREDプロトコルの設計のために正当化されうる。 （BEEPまたは類似の積層技術を使用して、例えば、）独自に開発したセキュリティプロトコルのシンプルなレイヤーを簡単に公開し、既知活用することができます組み合わせ、特定の攻撃によって敗北する可能性がある複雑な、多層セキュリティプロトコルを生成することを理解することも重要それがあります個々のプロトコル（S）の弱点。
When necessary, and after a TLS session has been established between the two parties, the credential server can request that the client provide her user id and password information to authenticate the remote user. Preferably, client and server can cooperate to perform an authentication operation that allows the server to authenticate the client (and perhaps vice-versa) in a "zero knowledge manner". In such cases, the client need not have a security credential.
必要な場合、およびTLSセッションが両者の間で確立された後、信用証明書サーバは、クライアントがリモートユーザを認証するために、彼女のユーザーIDとパスワードの情報を提供するように要求することができます。好ましくは、クライアントとサーバは、サーバが「ゼロ知識方法」にクライアント（そしておそらくその逆）を認証することを可能にする認証動作を実行するために協働することができます。このような場合には、クライアントは、セキュリティ資格を有する必要はありません。
TLS with Client Authentication (cTLS)
クライアント認証とTLS（CTL）を
TLS provides an optional, secure session capability (sometimes called client-side TLS) whereby the TLS server can request client authentication by verifying the client's digital signature.
TLSは、TLSサーバーがクライアントのデジタル署名を検証することにより、クライアント認証を要求することができるオプション、セキュアセッション機能（とも呼ばれるクライアント側TLS）を提供します。
In order to use cTLS to provide mutual authentication, the client must also be configured with at least one security credential that is acceptable to the TLS server for remote client authentication purposes.
相互認証を提供するために、CTLを使用するためには、クライアントは、リモートクライアント認証のためにTLSサーバに受け入れられる少なくとも1つのセキュリティ資格情報を使用して設定する必要があります。
Other authentication methods that provide the necessary security capabilities MAY also be suitable for use with SACRED credential exchange protocols.
必要なセキュリティ機能を提供する他の認証方法もSACRED資格交換プロトコルでの使用に適しています。
It is intended that one or more underlying protocol stacks may carry the SACRED credential exchange protocols. It is recognized at the outset that the use of several underlying protocol suites, although not ideal from an interoperability standpoint, may well be required to support the wide variety of needs anticipated.
1つのまたは複数の基本的なプロトコル・スタックがSACRED資格交換プロトコルを運ぶことができることが意図されています。相互運用性の観点からは理想的ではないが、十分に予想されるニーズを幅広くサポートするために必要な場合がありますが、それは、いくつかの基本的なプロトコル・スイートを使用することを最初に認識されています。
The SACRED list members have discussed several protocol suites that have been considered on their technical merits, each with distinct benefits and protocol design/implementation costs. Among these protocols are:
SACREDリストのメンバーは、明確な利点とプロトコルの設計/実装コストを持つ各、彼らの技術的なメリットに検討されているいくつかのプロトコルスイートを議論してきました。これらのプロトコルの中には：
- TCP - BEEP - HTTP
- TCP - BEEP - HTTP
All protocol suites listed here depend on TCP to provide a reliable, end-to-end transport layer protocol. Each of these building block approaches provides a different way of handling the remaining application layer issues (basic session management, session level security, presentation/formatting, application functionality).
ここに記載されているすべてのプロトコルスイートは、信頼性の高い、エンドツーエンドのトランスポート層プロトコルを提供するために、TCPに依存しています。これらのビルディング・ブロック・アプローチのそれぞれは、残りのアプリケーション層の問題（基本的なセッション管理、セッションレベルのセキュリティ、プレゼンテーション/フォーマット、アプリケーション機能）を処理する別の方法を提供します。
This approach (layering a SACRED credential exchange protocol directly on top of a TCP connection) requires the development of a custom credential exchange messaging protocol that interfaces to a TCP connection/socket. The primary benefit of this approach is the ability to provide exactly the protocol functionality needed and no more. Most server and client development environments already provide the socket level API needed.
（TCPコネクションの上に直接SACREDクレデンシャル交換プロトコルを積層）このアプローチは、TCP接続/ソケットにインターフェースカスタム資格Exchangeメッセージングプロトコルの開発を必要とします。このアプローチの主な利点は、正確にプロトコル機能に必要な、それ以上を提供する能力です。ほとんどのサーバーとクライアントの開発環境は、すでに必要なソケットレベルのAPIを提供しています。
This approach builds on the Blocks Extensible Exchange Protocol (BEEP) described in [RFC3080]. BEEP provides general purpose, peer-to-peer message exchange over any of several transport mechanisms where the necessary transport layer mappings have been defined for operation over TCP, TLS, etc. See also [RFC3081].
このアプローチは、[RFC3080]に記載のブロック拡張交換プロトコル（BEEP）の上に構築します。 BEEPはまた、[RFC3081]を参照してくださいなど、必要なトランスポート層マッピングはTCP、TLSでの動作が定義されているいくつかのトランスポート機構のいずれかの上にピア・ツー・ピア・メッセージ交換、一般的な目的を提供します。
BEEP provides the necessary user authentication/session security and session management capabilities needed to support SACRED credential exchange operations.
BEEPはSACRED資格交換操作をサポートするのに必要なユーザー認証/セッションセキュリティおよびセッション管理機能を提供します。
This approach builds on the Hypertext Transport Protocol (HTTP) described in [RFC1945] and [RFC2616]. HTTP provides general purpose typing and negotiation of data representation, allowing systems to be built independently of the data objects being transferred. HTTP support is available in a wide variety of server and client platforms, including portable devices that apply to roaming environments (laptop PCs, PDAs, mobile phones, etc.).
このアプローチは、[RFC1945]及び[RFC2616]で説明ハイパーテキスト転送プロトコル（HTTP）に基づいています。 HTTPは、システムは、独立して転送されるデータオブジェクトの構築することを可能にする、データ表現の汎用タイピング及び交渉を提供します。 HTTPのサポートは、環境（ノートPC、PDA、携帯電話など）をローミングには適用され、ポータブル機器など、サーバーとクライアントの様々なプラットフォームで使用可能です。
HTTP is layered over TCP and can be used, optionally, with TLS to provide authenticated, session level security. Either or both TLS authentication options, sTLS or cTLS, may be used whenever TLS is supported.
HTTPはTCP上に積層され、認証、セッション・レベルのセキュリティを提供するために、TLSと、必要に応じて、使用することができます。 TLSがサポートされているときはいつでもいずれかまたはTLS認証オプション、STLSまたはCTLを両方使用することができます。
The following security considerations identify general observations and precautions to be considered for a framework supporting credential mobility. When designing or implementing a protocol to support this framework, one should recognize these security considerations, and furthermore consult the SACRED Requirements document [RFC3157] Security Considerations.
次のセキュリティの考慮事項は、資格のモビリティをサポートするフレームワークのために考慮すべき一般的な観察と注意事項を確認します。設計またはこのフレームワークをサポートするためのプロトコルを実装する場合、1は、これらのセキュリティ上の考慮事項を認識し、さらにSACRED要件ドキュメント[RFC3157]のセキュリティの考慮事項を相談してください。
A SACRED PDU will contain information pertaining to client or server authentication, or communication of credentials. This information is subject to the traditional security concerns identified below.
SACRED PDUは、クライアントまたはサーバ認証、または資格情報の通信に関する情報が含まれています。この情報は、以下に特定の伝統的な安全保障上の懸念の対象となります。
The password or password verifier should be protected when communicated from the client to credential server. The communicated value should be resistant to a dictionary attack.
資格クライアントからサーバに伝えたときに、パスワードまたはパスワード・ベリファイアを保護する必要があります。連値は、辞書攻撃に対して耐性であるべきです。
Similarly, the entity credentials must be confidentiality protected, when communicated from the client to the server and vice-versa. The communicated value should also resist a dictionary attack.
クライアントからサーバに伝達し、その逆の場合も同様に、実体の資格情報は、機密性、保護されなければなりません。伝達値も辞書攻撃を耐えなければなりません。
Communication integrity between the client and the credential server is required. In this way, intended client operations may not be altered (e.g., from an update to a deletion of credentials), nor may clients be maliciously given "old" credentials (e.g., possibly by an attacker replaying a previous credential download).
クライアントと信用証明書サーバ間の通信の整合性が必要とされます。このように、意図したクライアントの操作は変更されない場合があり（例えば、資格情報の削除の更新から）、またクライアントが悪意を持って（以前の資格のダウンロードを再生例えば、おそらく攻撃者による）「古い」の資格情報が与えられてもよいです。
Proper authentication of the client and server is required to achieve communication confidentiality and integrity.
クライアントとサーバの適切な認証は、通信の機密性と整合性を達成するために必要とされます。
The server must properly authenticate the client, so that credentials are not mistakenly revealed to an attacker. The client must ensure the proper identification of the credential server so as to prevent revealing their password to an attacker. These goals may be achieved implicitly with a strong password-based protocol or explicitly. If the server is identified explicitly, the user or client must ensure that the user password is conveyed to a trusted server. This might be achieved by installing appropriate trusted key(s) in the client.
資格情報が誤って攻撃者に明らかにされないように、サーバは正しく、クライアントを認証する必要があります。攻撃者に自分のパスワードを明らかにしないように、クライアントは信用証明書サーバの適切な識別を確認する必要があります。これらの目標は、強力なパスワードベースのプロトコルまたは明示的に暗黙的に達成することができます。サーバーが明示的に識別された場合、ユーザーまたはクライアントは、ユーザーのパスワードが信頼できるサーバに伝達されていることを確認する必要があります。これは、クライアントに適切な信頼できるキー（複数可）をインストールすることによって達成される可能性があります。
There are no requirements upon the SACRED protocol itself to support non-repudiation, although the context in which the credentials are being used may have such requirements.
資格情報が使用されている文脈がそのような要件があるかもしれないが否認防止をサポートするSACREDプロトコル自体に何ら要件は存在しません。
Systems security is concerned with protection of the protocol endpoints (i.e., the client and server) and information stored at the server in support of the SACRED protocol.
システムのセキュリティは、プロトコルエンドポイントの保護（すなわち、クライアントおよびサーバ）と神聖なプロトコルをサポートするサーバに格納された情報に関するものです。
As with most security protocols, secure use of the client often relies, in part, upon secure behavior by the user. In the case of a password-based SACRED protocol, users should be educated, or enforced through policy, to choose passwords with a reasonable amount of entropy. Additionally, users should be made aware of the importance of protecting the confidentiality of their account password.
ほとんどのセキュリティプロトコルと同様に、クライアントの安全な使用は、多くの場合、ユーザーが安全な行動に一部依存しています。エントロピーの合理的な金額とパスワードを選択するために、パスワードベースのSACREDプロトコルの場合には、ユーザーが教育をしなければならない、またはポリシーによって施行します。また、ユーザーが自分のアカウントのパスワードの機密性を保護することの重要性を認識してなされるべきです。
In addition, the client interface should be designed to thwart "shoulder surfing" where an attacker can observe the password as entered by a user. This is often achieved by not echoing the exact characters of the password when entered.
また、クライアント・インタフェースは、ユーザによって入力されたとして、攻撃者がパスワードを観察できる「ショルダーサーフィン」を阻止するために設計されなければなりません。これは、多くの場合、入力された際に、パスワードの正確な文字をエコーしないことによって達成されます。
As well, the interface should encourage the entering of the password in the appropriate interface field so that protections can be properly enforced. For example, a user should be guided to not mistakenly enter their password in the "username" field (since their password would likely be echoed to the screen in this case, and might not be encrypted when communicated to the server). This might be accomplished via the automatic insertion of the user name or several user name choices in the appropriate on-screen dialog field, for example.
保護が適切に実施できるように、同様に、インターフェースは、適切なインターフェイスフィールドにパスワードの浸入を奨励すべきです。たとえば、ユーザーが誤っていない「ユーザ名」フィールドにパスワードを入力するように導かれるべき（そのパスワードはおそらくこの場合は画面に表示されるので、サーバに伝達する際に暗号化されないことがあります）。これは、例えば、適切な画面上のダイアログのフィールドにユーザー名または複数のユーザー名の選択肢の自動挿入により達成される可能性があります。
When TLS is used as the SACRED transport protocol, the client interface should be designed to allow the user to verify that she is connected to the intended credential server. For example, client software should allow for the visual display of identifying components from the TLS server's X.509 certificate, like the server's name, the certificate fingerprint, etc.
TLSはSACREDトランスポートプロトコルとして使用する場合、クライアント・インタフェースは、ユーザが自分が意図した信用証明書サーバに接続されていることを確認できるように設計されなければなりません。たとえば、クライアント・ソフトウェアは、TLSサーバのX.509証明書から特定のコンポーネントの視覚的な表示を可能にしなければならないなど、サーバの名前、証明書のフィンガープリントなど
Users should be guided to verify this information regularly, allowing ready recognition of trusted credential servers. In addition, users should be made aware of the importance of verifying their credential server's identity before initiating any credential exchange operations.
ユーザーは、信頼できる資格のサーバーの準備ができて認識できるよう、定期的にこの情報を確認するために導かれる必要があります。また、ユーザーが任意の資格情報の交換作業を開始する前に、自分の信用証明書サーバの身元を検証することの重要性を認識してなされるべきです。
A SACRED client SHOULD only be configured with those SACRED trust anchors that are to be used by the client. Re-use of trust anchors from other applications, e.g., Internet browsers is NOT RECOMMENDED.
SACREDクライアントは、クライアントによって使用されるものをSACREDトラストアンカーを設定する必要があります。再使用、他のアプリケーションからの信頼アンカーの、例えば、インターネットブラウザは推奨されません。
Password verifiers and user credentials must be afforded a high level of protection at the credential server. In addition to salting and super-encrypting each (to ensure resistance to offline dictionary attacks), a system should ensure that credential server keys are protected using sufficient procedural and physical access controls.
パスワードの検証とユーザーの資格情報は、信用証明書サーバで高レベルの保護を与えなければなりません。塩析及び（オフライン辞書攻撃に対する耐性を確保するために）各スーパー暗号化に加えて、システムは、信用証明書サーバキーが十分手続き及び物理的アクセス制御を使用して保護されていることを確認すべきです。
The login to the credential server should be resistant to replay attacks.
信用証明書サーバへのログインには、リプレイ攻撃に耐性でなければなりません。
Online attempts to access a particular user account should be controlled, or at least monitored. Control might be enforced by incorporating a time delay after a number of unsuccessful logins to a particular account, or possibly the locking of the account altogether. Alternatively, one might simply log unsuccessful attempts where an administrative notice is produced once a threshold of unsuccessful credential access attempts is reached.
特定のユーザーアカウントにアクセスするためのオンラインの試みは、制御された、あるいは少なくとも監視する必要があります。コントロールは、特定のアカウントに失敗したログインの回数後の時間遅延、またはおそらく完全にアカウントのロックを組み込むことによって実施される可能性があります。あるいは、単に失敗した資格情報アクセス試行のしきい値に達すると、管理者の通知が生成されて失敗した試行をログに記録することがあります。
As with most protocols, Denial of Service (DoS) issues must also be considered. In the case of SACRED, most DoS issues are a concern for the underlying transport protocol. However, some concerns may still be mitigated.
ほとんどのプロトコルと同様に、サービス拒否（DoS）の問題も考慮しなければなりません。 SACREDの場合は、ほとんどのDoS問題は、基礎となるトランスポートプロトコルのための関心事です。しかし、いくつかの懸念が依然軽減することができます。
Service to a user might be denied in case their account is locked after numerous unsuccessful login attempts. Consideration of protection against online attacks must therefore be considered (as described above). Proper user authentication should ensure that an attacker does not maliciously overwrite a user's credentials. Credential servers should be wary of repeated logins to a particular account (which also identifies a possible security breach, as described above) or abnormal volumes of requests to a number of accounts (possibly identifying a DoS attack).
利用者へのサービスは、自分のアカウントが多数失敗したログイン試行後にロックされている場合には拒否される可能性があります。 （上記のように）、オンライン攻撃に対する保護の検討は、したがって、考慮されなければなりません。適切なユーザ認証は、攻撃者が悪意を持ってユーザーの資格情報を上書きしないことを確認する必要があります。信用証明書サーバは、特定のアカウントへのログインを繰り返す（前述のように、また、可能なセキュリティ侵害を識別する）又は（おそらくはDoS攻撃を識別する）アカウントの数に対する要求の異常なボリュームの警戒すべきです。
[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月。
[RFC3157] Arsenault, A. and S. Farrell, "Securely Available Credentials - Requirements", RFC 3157, August 2001.
[RFC3157] Arsenault、A.とS.ファレル、 "しっかり利用可能な資格情報 - 要求事項"、RFC 3157、2001年8月。
[BM92] Bellovin, S. and M. Merritt, "Encrypted Key Exchange: Password-based protocols secure against dictionary attacks", Proceedings of the IEEE Symposium on Research in Security and Privacy, May 1992.
[BM92] Bellovin氏、S.とM.メリット、「暗号化鍵交換：辞書攻撃に対して安全なパスワードベースのプロトコル」、セキュリティとプライバシー、1992年5月の研究上のIEEEシンポジウム。
[BM94] Bellovin, S. and M. Merritt, "Augmented Encrypted Key Exchange: a Password-Based Protocol Secure Against Dictionary Attacks and Password File Compromise, ATT Labs Technical Report, 1994.
[BM94] Bellovin氏、S.とM.メリット、「増補暗号化鍵交換：辞書攻撃やパスワード・ファイルの妥協、ATT研究所技術報告書、1994に対するセキュリティで保護されたパスワードベースのプロトコル。
[PKCS12] "PKCS 12 v1.0: Personal Information Exchange Syntax", RSA Laboratories, June 24, 1999.
[PKCS12] "PKCS 12 v1.0を：個人情報交換構文"、RSA Laboratories社、1999年6月24日。
[PKCS15] "PKCS #15 v1.1: Cryptographic Token Information Syntax Standard", RSA Laboratories, June 2000.
[PKCS15] "PKCS＃15 V1.1：暗号トークン情報の構文標準"、RSA Laboratories社、2000年6月。
[RFC1945] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer Protocol-- HTTP/1.0", RFC 1945, May 1996.
[RFC1945]バーナーズ=リー、T.、フィールディング、R.、およびH. Frystyk、 "ハイパーテキスト転送Protocol-- HTTP / 1.0"、RFC 1945、1996年5月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246]ダークス、T.とC.アレン、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frysyk, H., Masinter, L., Leach, M. and T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", RFC 2616, June 1999.
[RFC2616]フィールディング、R.、ゲティス、J.、モーグル、J.、Frysyk、H.、Masinter、L.、リーチ、M.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1"、RFC 2616年、1999年6月。
[RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", RFC 2945, September 2000.
[RFC2945]呉、T.、 "SRP認証と鍵交換システム"、RFC 2945、2000年9月。
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[RFC3080]ローズ、M.、 "ブロック拡張可能交換プロトコルコア"、RFC 3080、2001年3月。
[RFC3081] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March 2001.
[RFC3081]ローズ、M.、 "TCP上にBEEPコアのマッピング"、RFC 3081、2001年3月。
[SPEKE] Jablon, D., "Strong Password-Only Authenticated Key Exchange", September 1996.
[SPEKE] Jablon、D.、 "強力なパスワードのみによる認証鍵交換"、1996年9月。
Dale Gustafson Future Foundation Inc.
デール・グスタフソン今後の財団株式会社
EMail: degustafson@comcast.net
メールアドレス：degustafson@comcast.net
Mike Just Treasury Board of Canada, Secretariat
カナダ、事務局のマイク・ジャスト財務省会
EMail: Just.Mike@tbs-sct.gc.ca
メールアドレス：Just.Mike@tbs-sct.gc.ca
Magnus Nystrom RSA Security Inc.
マグナスNystrom RSA Security Inc.の
EMail: magnus@rsasecurity.com
メールアドレス：magnus@rsasecurity.com
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.
著作権（C）インターネット協会（2004）。この文書では、BCP 78に含まれる権利、ライセンスおよび制限があり、そこに記載された以外、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。