[要約] RFC 3760は、SACRED（Securely Available Credentials）のためのCredential Server Frameworkに関するものです。このRFCの目的は、セキュアな認証情報の提供と管理を可能にするためのフレームワークを提供することです。
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
安全に利用可能な資格情報（神聖） - 資格情報サーバーフレームワーク
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）The Internet Society（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.
このドキュメントは、そのような資格の安全な交換のための一般的なフレームワークを提案し、1つ以上の安全に利用可能な資格情報（神聖な）資格情報プロトコルの開発を導くのに役立つ高レベルの概要を提供します。
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:
神聖な要件は[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].
このドキュメントの「必須」、「必要はない」、「そうでなければ」、「すべきではない」、「推奨される」、「推奨」、「可能性」は、[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公開キー証明書、属性証明書、および/またはアプリケーションデータで構成されている場合があります。資格情報を表現するためのいくつかの標準化された形式が存在します。
passkey: a symmetric key, derived from a password.
PassKey：パスワードから派生した対称キー。
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つ以上の資格情報のセット。セキュリティされた資格情報は、複数の暗号化の層を使用して保護される場合があります。たとえば、資格情報は、ユーザーのパスワードに対応するPassKeyで保護され、サーバー（資格情報の保存フォーム）にのみ既知のキーによって保護されます。ネットワーク転送中、PassKeyで保護された資格情報は、資格情報サーバー（たとえば、送信されたフォームなど）によって選択された対称キーを使用して、追加の暗号化層で保護できます。
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.
資格情報パスワードは、保存された資格情報の永続的な暗号化と認証を提供するために使用されるPassKeyを導き出すために使用されます。適用されるセキュリティされた資格標準文書（例：[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.
ネットワーク伝送中、セキュリティで保護された資格情報は、2番目の（外側）暗号化層で保護されます。外側暗号化層は、相互認証プロセス中に導出されたセッションレベルの暗号化キーを使用して作成されます。効果的に、安全な資格情報は、交換された資格情報（およびその他の）情報に対してプライバシー保護の追加層を提供する「暗号化されたトンネル」を横断します。
The network diagram below shows the components involved in the SACRED client/server framework.
以下のネットワーク図は、神聖なクライアント/サーバーフレームワークに関与するコンポーネントを示しています。
+--------+ +------------+
| 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 -Credential Serverがユーザー資格情報（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、またはその他の標準または独自のプロトコルなどの標準プロトコルを使用して実装できます。また、管理者と信頼できるサーバープロトコルは、サーバーベンダー固有であると想定されており、現時点では神聖な標準化の取り組みの対象ではないことに注意してください。
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.
クライアントは、資格情報を資格認定ストア（または選択している他のサーバー）と直接交換することを妨げられません。ただし、ネットワークサーバーに保存されている間、およびクレデンシャルサーバーと交換された神聖なプロトコルによって輸送中に提供されている間、信用データの一貫したレベルの保護を使用した相互認証。資格情報サーバーの設計に応じて、ユーザーの資格情報は、資格情報サーバーを通って資格情報ストアに、またはクライアントと資格のストアの間に直接流れる場合があります。
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.
このセクションでは、神聖な資格を交換および管理するために使用できるクライアント/サーバープロトコルの高レベルの説明を提供します。
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つの基本および抽象的な操作に基づいています。「Get」、「Put」、および「削除」。安全な資格情報交換プロトコルは次のように達成されます。
connect - the client initiates a connection to a credential server for the purpose of secure credential exchange.
Connect-クライアントは、安全な資格情報交換を目的として、資格情報サーバーへの接続を開始します。
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.
相互認証/キーネゴシエーション - クライアントがサーバーに認証する強力なパスワードプロトコル（または同等）を使用し、サーバーがクライアントに認証し、セッションレベルの暗号化キーがネゴシエートされます。相互認証プロトコル交換の詳細は、使用される特定の認証方法に依存します。すべての場合において、最終結果は、クライアントをサーバーとサーバーにクライアントに認証し、2つの当事者間で強力で共有された秘密を確立することです。
client request(s) - the SACRED client issues one or more high level credential exchange requests (e.g., GET, PUT, or DELETE).
クライアントリクエスト - 神聖なクライアントは、1つまたは複数の高レベルの資格情報交換リクエスト（Get、Put、または削除など）を発行します。
server response(s) - the SACRED credential server responds to each request, either performing the operation successfully or indicating an appropriate error.
サーバー応答（S） - Sacred Credential Serverは各要求に応答し、操作を正常に実行するか、適切なエラーを示します。
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.
閉じる - クライアントは、現時点ではサーバーに対するリクエストがもうないことを示します。クライアントとサーバーの間のセキュリティコンテキストは不要になりました。Closeは、論理的なセッション管理操作です。
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.
各高レベルの資格情報交換操作は、一連のリクエスト応答ペアで構成されています。クライアントは、適切な応答を返す前にサーバーが処理する各要求を開始します。クライアントが次のリクエストを発行する前に、各要求（サーバーレポートの成功または失敗）を完了する必要があります。サーバーは、相互認証が成功した後、少なくとも1つのアップロードまたはダウンロードリクエストを使用することをいとわない必要がありますが、いずれかの当事者はいつでも論理接続を終了できます。
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.
name-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/削除操作を要求するために使用できる明確な資格版インジケーターです。この資格情報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:
プット操作を使用して実装されている資格アップアップロードのフレームワークは、次のとおりです。
- 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.
クライアントのプットリクエストには、オプションの識別子（資格情報）フィールドが含まれる場合があります。存在する場合、新しい資格情報は、同じ名前と資格情報IDの資格情報が現在サーバーに保存されている場合にのみ保存されます（たとえば、論理置換操作が実行されます）。サーバーに存在しない資格情報をクライアントが交換しようとする場合、サーバーはエラーを返す必要があります。
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 >
...
...
< close > -->
<-- OK (+ disconnect)
new-ID-x is the credential-ID of the newly stored credential.
New-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と一致しない場合にのみ、サーバーは要求された資格情報を返します。
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 >
...
...
< close > -->
<-- OK (+ disconnect)
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以降、資格情報は返されていないことに注意してください。
The framework for the credential removal, as implemented with the DELETE operation, is:
削除操作で実装されている資格削除のフレームワークは、次のとおりです。
- 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.
- オプションで、クライアントは削除要求に資格情報を含めることができます。この場合、リクエスト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 >
...
...
< close > -->
<-- OK (+ disconnect)
Note that the three operations defined above (GET, PUT, DELETE) can be used to perform the basic credential management operations:
上記の3つの操作（Get、Put、Delete）を使用して、基本的な資格管理操作を実行できることに注意してください。
- 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].
少なくとも2つの明確に定義された資格形式が利用可能です：[PKCS12]と[PKCS15]。
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.
ローミング環境での不正な開示または変更からユーザーの資格情報を適切に保護するために、すべての神聖な認証方法は、攻撃者が潜在的なセキュリティの脆弱性を活用しようとするネットワーク環境でユーザー資格情報を保護する必要があります。神聖な要件[RFC3157]、セクション3.1、脆弱性を参照してください。
At a minimum, each SACRED authentication method SHOULD ensure that:
少なくとも、各神聖な認証方法は次のことを確認する必要があります。
- 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.
- サーバーはクライアントを認証します - クライアントはサーバーを認証します - クライアントとサーバーは、暗号化的に強力な秘密キー（セッションキーなど）を安全にネゴシエート（または導き出します）。 - 1つ以上のユーザー資格情報の交換は、このセッションキーを使用して保護されます。
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:
すべての神聖なクライアント/サーバープロトコルは、これらの基本的なセキュリティ関数のそれぞれを提供することが期待されています。この目的のために使用される可能性のある既存の認証プロトコルは次のとおりです。
- 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は、提供する一般的なセキュリティ機能とセキュリティ要素（パスワード、キーペア、ユーザー証明書、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]に記載されているような強力なパスワードプロトコルを使用して、神聖なプロトコルの相互認証とプライバシーを提供することができます。
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および関連する値）をサーバー内で構成する必要があります。パスワードを知っている当事者のみが検証者値を計算できます。クライアントがサーバーとの関係を確立したときに、サーバーに安全に配信する必要があります。Connect時点では、2つの関係者間でメッセージが交換され、補完的なアルゴリズムが使用されて、正当なユーザーとサーバーにのみ知られている共有値を計算します。両当事者は、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]は、セクションF.3でこのリスクを管理するための基礎を特定します（このドキュメントのセクション5.2も参照）。
"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.
また、神聖なクライアントによる（ますます複雑になっている）サーバー証明書チェーン処理の誤った実装は、同様の妥協につながり、資格のあるサーバーのマスカレードまたは中間の攻撃を成功させることができることに注意してください。
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).
拡張または拡張サーバー認証方法を提供するエンジニアリングアプローチは、神聖なプロトコル設計のために保証される場合があります。独立して開発されたセキュリティプロトコルの単純な階層化（たとえば、ビープ音や類似の階層化技術を使用する）の単純な階層化は、既知を公開および悪用できる組み合わせ固有の攻撃によって簡単に打ち負かされる可能性のある複雑で多層セキュリティプロトコルを生成することを理解することも重要です。個々のプロトコルの弱点。
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.
必要に応じて、および2つの関係者間でTLSセッションが確立された後、クレデンシャルサーバーは、クライアントがユーザーIDとパスワード情報を提供してリモートユーザーを認証することを要求できます。できれば、クライアントとサーバーは、サーバーが「ゼロの知識の方法」でクライアント（おそらくその逆）を認証できるようにする認証操作を実行するために協力できます。そのような場合、クライアントにはセキュリティ資格情報が必要です。
TLS with Client Authentication (cTLS)
クライアント認証を備えたTLS（CTLS）
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.
CTLSを使用して相互認証を提供するために、クライアントは、リモートクライアント認証の目的でTLSサーバーに受け入れられる少なくとも1つのセキュリティ資格情報で構成する必要があります。
Other authentication methods that provide the necessary security capabilities MAY also be suitable for use with SACRED credential exchange protocols.
必要なセキュリティ機能を提供する他の認証方法は、神聖な資格交換プロトコルでの使用にも適している場合があります。
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つ以上の基礎となるプロトコルスタックが、神聖な資格交換プロトコルを運ぶことができることを意図しています。最初から、いくつかの基礎となるプロトコルスイートの使用は、相互運用性の観点からは理想的ではありませんが、予想されるさまざまなニーズをサポートするために必要になる可能性があることが認識されています。
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:
神聖なリストメンバーは、技術的なメリットで考慮されたいくつかのプロトコルスイートについて議論しました。これらのプロトコルの中には、次のとおりです。
- 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接続の上に神聖な資格交換プロトコルを直接階層化する）には、TCP接続/ソケットにインターフェイスするカスタム資格情報交換メッセージプロトコルの開発が必要です。このアプローチの主な利点は、必要なプロトコル機能を正確に提供できることです。ほとんどのサーバーおよびクライアント開発環境は、すでに必要なソケットレベル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は、TCP、TLSなどの動作のために必要な輸送層マッピングが定義されているいくつかの輸送メカニズムのいずれかについて、汎用、ピアツーピアメッセージ交換を提供します。[RFC3081]も参照してください。
BEEP provides the necessary user authentication/session security and session management capabilities needed to support SACRED credential exchange operations.
Beepは、神聖な資格交換操作をサポートするために必要なユーザー認証/セッションセキュリティとセッション管理機能を提供します。
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またはCTLSのいずれかまたは両方が使用される場合があります。
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.
以下のセキュリティ上の考慮事項は、資格のモビリティをサポートするフレームワークの一般的な観察と予防策を特定します。このフレームワークをサポートするためにプロトコルを設計または実装する場合、これらのセキュリティに関する考慮事項を認識し、さらに聖なる要件文書[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.
神聖な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.
信任状が使用されているコンテキストにはそのような要件がある場合がありますが、非繰り返しをサポートするために、神聖なプロトコル自体に要件はありません。
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.
Systemsのセキュリティは、プロトコルエンドポイント（つまり、クライアントとサーバー）の保護と、神聖なプロトコルをサポートするサーバーに保存されている情報に関係しています。
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.
ほとんどのセキュリティプロトコルと同様に、クライアントの安全な使用は、しばしばユーザーによる安全な動作に依存しています。パスワードベースの神聖なプロトコルの場合、ユーザーは、合理的な量のエントロピーを持つパスワードを選択するために、教育を受けたり、ポリシーを通じて施行される必要があります。さらに、ユーザーは、アカウントパスワードの機密性を保護することの重要性を認識させる必要があります。
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 Transport Protocolとして使用される場合、クライアントインターフェイスは、ユーザーが意図した資格的サーバーに接続されていることを確認できるように設計する必要があります。たとえば、クライアントソフトウェアは、サーバーの名前、証明書指紋などなど、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.
ユーザーは、この情報を定期的に検証するように導かれ、信頼できる資格情報サーバーのすぐに認識できるようにする必要があります。さらに、ユーザーは、資格情報交換操作を開始する前に、資格情報サーバーのIDを確認することの重要性を認識させる必要があります。
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.
神聖なクライアントは、クライアントが使用する神聖な信頼のアンカーでのみ構成する必要があります。他のアプリケーションからの信頼のアンカーの再利用、たとえば、インターネットブラウザーは推奨されません。
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）の問題も考慮する必要があります。神聖な場合、ほとんどの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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3157] Arsenault, A. and S. Farrell, "Securely Available Credentials - Requirements", RFC 3157, August 2001.
[RFC3157] Arsenault、A。and S. Farrell、「Securely Availableady Credentials -compoysion」、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. Merritt、「暗号化されたキー交換：パスワードベースのプロトコルは、辞書攻撃に対して安全なパスワードベースのプロトコル」、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. Merritt、「拡張暗号化されたキー交換：辞書攻撃とパスワードファイルの妥協に対するパスワードベースのプロトコル、ATT Labs Technical Report、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] Berners-Lee、T.、Fielding、R。and H. Frystyk、「HyperText Transfer 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] Dierks、T。およびC. Allen、「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] Fielding、R.、Gettys、J.、Mogul、J.、Frysyk、H.、Masinter、L.、Leach、M。and T. Berners -Lee、 "HyperText Transfer Protocol -HTTP/1.1"、RFC2616、1999年6月。
[RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", RFC 2945, September 2000.
[RFC2945] Wu、T。、「SRP認証およびキー交換システム」、RFC 2945、2000年9月。
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[RFC3080] Rose、M。、「ブロック拡張可能な交換プロトコルコア」、RFC 3080、2001年3月。
[RFC3081] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March 2001.
[RFC3081] Rose、M。、「ビープコアのマッピングTCPに」、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.
Dale Gustafson Future Foundation Inc.
EMail: degustafson@comcast.net
Mike Just Treasury Board of Canada, Secretariat
カナダのマイクジャスト財務委員会、事務局
EMail: Just.Mike@tbs-sct.gc.ca
Magnus Nystrom RSA Security Inc.
Magnus Nystrom RSA Security Inc.
EMail: 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）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。