RFC3760 日本語訳
3760 Securely Available Credentials (SACRED) - Credential ServerFramework. D. Gustafson, M. Just, M. Nystrom. April 2004. (Format: TXT=49910 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループD.グスタフソン要求をネットワークでつないでください: 3760年の将来の財団カテゴリ: まさしく国家財政委員会が入るカナダM.ニストロムRSAセキュリティ2004年4月の情報のM.
Securely Available Credentials (SACRED) - Credential Server Framework
しっかりと利用可能な資格証明書(神聖な)--資格証明サーバフレームワーク
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright(C)インターネット協会(2004)。 All rights reserved。
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標準化のための問題になります。 このドキュメントはRFC3157に記載された資格証明書の安全な交換のためにプロトコルに関する要件に応じます、抽象的なプロトコルフレームワークを提示することによって。
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 機能概要。 . . . . . . . . . . . . . . . . . . . . . 2 2.1. 定義。 . . . . . . . . . . . . . . . . . . . . . . 2 2.2. 資格証明書。 . . . . . . . . . . . . . . . . . . . . . . 4 2.3. ネットワークアーキテクチャ. . . . . . . . . . . . . . . . . . 5 3。 フレームワーク. . . . . . . . . . . . . . . . . . . . . . 6 3.1について議定書の中で述べてください。 資格証明アップロード。 . . . . . . . . . . . . . . . . . . . 8 3.2. 資格証明ダウンロード。 . . . . . . . . . . . . . . . . . . 10 3.3. 資格証明取り外し. . . . . . . . . . . . . . . . . . . 11 3.4。 資格証明管理。 . . . . . . . . . . . . . . . . . 12 4. 問題について議定書の中で述べてください。 . . . . . . . . . . . . . . . . . . . 12 4.1. 資格証明形式を保証してください。 . . . . . . . . . . . . . . . 12 4.2. 認証方法. . . . . . . . . . . . . . . . . 13 4.3。 プロトコル群を輸送してください。 . . . . . . . . . . . . . . . 16 5. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 17 5.1. 通信秘密保全。 . . . . . . . . . . . . . . . . 17 5.2. システム、セキュリティ. . . . . . . . . . . . . . . . . . . . 18
Gustafson, et al. Informational [Page 1] RFC 3760 Securely Available Credentials (SACRED) April 2004
グスタフソン、他 資格証明書(神聖な)2004年4月にしっかりと利用可能な情報[1ページ]のRFC3760
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.1. Normative References . . . . . . . . . . . . . . . . . . 20
6.2. Informative References . . . . . . . . . . . . . . . . . 20
7. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21
8. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 22
6. 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.1。 引用規格. . . . . . . . . . . . . . . . . . 20 6.2。 有益な参照. . . . . . . . . . . . . . . . . 20 7。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 21 8。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 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つ以上のしっかりと利用可能な資格証明書(SACRED)の資格証明交換プロトコルの開発を誘導するのを助ける高い平らなアウトラインを提供します。
2. Functional Overview
2. 機能概要
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) クライアント/サーバCredential Exchange 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を見る)が感染されないのを保証して、ユーザが対話するローミングが資格証明サーバを意図したか、または認可したのを保証するのに使用されるでしょう。
2.1. Definitions
2.1. 定義
This section provides definitions for several terms or phrases used throughout this document.
このセクションはこのドキュメント中で使用されるいくつかの用語か句のための定義を提供します。
Gustafson, et al. Informational [Page 2] RFC 3760 Securely Available Credentials (SACRED) April 2004
グスタフソン、他 資格証明書(神聖な)2004年4月にしっかりと利用可能な情報[2ページ]のRFC3760
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED" and "MAY" in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」“SHOULD"、「」、このドキュメントの「推薦され」て「5月」は[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公開鍵証明書、属性証明書、そして/または、アプリケーションデータから成るかもしれません。 [PKCS15]、資格証明書の表現のためのいくつかの標準化された形式が例えば[PKCS12]存在しています(以下の「機密保護している資格証明書」を見てください)。
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.
パスワード: クライアントだけにおいて知られて、サーバ、そして/または、資格証明書を保証することへの認証の目的に使用される一連のキャラクタ。 ユーザが、1つ以上のパスワードを覚えているのに必要であるかもしれません。
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を暗号化しました。 1つ以上の層の暗号化を使用することで機密保護している資格証明書を保護するかもしれません、例えば、マスターキーが対応していた状態で、ユーザのパスワードとまた、サーバだけに知られているキーは資格証明書を保証します(資格証明書はフォームを保存しました)。 ネットワーク転送の間、追加暗号化層がCredential Server(例えば、伝えられたフォーム)によって選ばれた対称鍵を使用している状態で、マスターキーで保護された資格証明書は保護されるかもしれません。
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
強いパスワードプロトコル: クライアントが小さい秘密(パスワード)を暗記するだけでよいところでしっかりと(例えば[スピーク]、このより詳細な定義に関して、見る)サーバにクライアントを認証して、他の秘密の情報を全く運ばないで、サーバが検証を運ぶプロトコル
Gustafson, et al. Informational [Page 3] RFC 3760 Securely Available Credentials (SACRED) April 2004
グスタフソン、他 資格証明書(神聖な)2004年4月にしっかりと利用可能な情報[3ページ]のRFC3760
(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.
(パスワードトークン) それがクライアントを認証できる。 共有秘密キーは、クライアントとサーバの間で交渉されて、次に交換されたデータを保護するのに使用されます。
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.
「アカウントパスワード」と「資格証明パスワード」の区別に注意してください。 アカウントパスワード(そして、対応するパスワードトークン)はCredential 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.
さらに、ユーザには、ただ一つのパスワードだけを覚えているのが、より都合がよいかもしれませんが、資格証明サーバと資格証明発行人の間の異なった安全保障政策(例えば、パスワード規則)は複数のパスワードを覚えていなければならないユーザをもたらすかもしれません。
2.2. Credentials
2.2. 資格証明書
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
資格証明書が通常資格証明所有者だけにおいて知られている機密情報を含んでいるので、コネが明確であったならディスケットかハードドライブなどのエンドユーザデバイスに保存するとネットワーク送信とSHOULD NOTの間の明確で資格証明書を送ってはいけません。 この理由で、機密保護している資格証明書は定義されます。 私たちが少なくとも観点からのそれを仮定するこのドキュメント
Gustafson, et al. Informational [Page 4] RFC 3760 Securely Available Credentials (SACRED) April 2004
グスタフソン、他 資格証明書(神聖な)2004年4月にしっかりと利用可能な情報[4ページ]のRFC3760
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.
最小限では、すべてが秘密鍵、秘密鍵、およびいかなる他のデータ・オブジェクトのための公開か変更から保護しなければならないプライバシーと保全保護もSHOULDが提供する資格証明形式にサポートしました。 これらのセキュリティ能力が通常、基本的な資格証明形式の一部であるので、ハードドライブ、フレキシブルなディスケットなどに保存されると、資格証明書(例えば、データファイル)は保護されます。
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番目の(外側)の暗号化層で保護されます。 外側の暗号化層は、互いの認証過程の間に引き出されたセッションレベル暗号化キーを使用することで作成されます。 事実上、機密保護している資格証明書は情報が交換した資格証明書(そして、いかなる他のも)のための追加層のプライバシー保護を提供する「暗号化されたトンネル」を横断します。
2.3. Network Architecture
2.3. ネットワークアーキテクチャ
The network diagram below shows the components involved in the SACRED client/server framework.
コンポーネントがSACREDクライアント/サーバフレームワークにかかわったショーの下におけるネットワーク図。
+--------+ +------------+
| Client +-----------| Credential |
+--------+ 1 | Server |
\ +-----+------+
\ |
\ | 2
\ |
\ 3 +-----+------+
-----------| Credential |
| Store(s) |
+------------+
+--------+ +------------+ | クライアント+-----------| 資格証明書| +--------+ 1 | サーバ| \ +-----+------+ \ | \ | 2 \ | \ 3 +-----+------+ -----------| 資格証明書| | (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.
資格証明Server--クライアントから安全な資格証明書をダウンロードして、それらをアップロードするサーバ。 サーバは機密保護している資格証明書が適切なエンドユーザだけと共に交換されるのを保証するためにクライアントを認証するのに原因となります。 資格証明サーバは、クライアントの認証情報が感染されないのを保証するためにクライアントに認証されて、ユーザが、資格証明書が検索したと信じることができるためのそうです。
Gustafson, et al. Informational [Page 5] RFC 3760 Securely Available Credentials (SACRED) April 2004
グスタフソン、他 資格証明書(神聖な)2004年4月にしっかりと利用可能な情報[5ページ]のRFC3760
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)を保存して、検索するのにCredential Serverによって使用されたプロトコル。
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.
また、ユーザは、高められたレベルの有用性を得るためにいくつかの資格証明サーバに彼らの資格証明書をアップロードするかもしれません。 いくつかの資格証明サーバの中のユーザー情報か資格証明データのコーディネート(自動模写)は現在、このドキュメントの範囲を超えています。
3. Protocol Framework
3. プロトコルフレームワーク
This section provides a high level description of client/server protocols that can be used to exchange and manage SACRED credentials.
このセクションはSACRED資格証明書を交換して、管理するのに使用できるクライアント/サーバプロトコルの高い平らな記述を提供します。
Gustafson, et al. Informational [Page 6] RFC 3760 Securely Available Credentials (SACRED) April 2004
グスタフソン、他 資格証明書(神聖な)2004年4月にしっかりと利用可能な情報[6ページ]のRFC3760
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つの基本的で抽象的な操作に基づいています。 「得」て、「置い」て、「削除します」。 機密保護している資格証明交換プロトコルは以下の通り達成されます:
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.
互いの認証/主要な交渉--クライアントがサーバに認証するプロトコル(または、同等物)、サーバがクライアントに認証して、セッションが平らにする強いパスワードを使用して、暗号化キーは交渉されます。 互いの認証プロトコル交換の詳細はメソッドが使用した特定の認証に依存しています。 すべての場合では、結末は、クライアントへのサーバとサーバにクライアントを認証して、2回のパーティーの間で強くて、共有された秘密を確立することです。
client request(s) - the SACRED client issues one or more high
level credential exchange requests (e.g., GET, PUT, or
DELETE).
クライアント要求--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.
サーバ応答--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.
それぞれのハイレベルの資格証明交換操作は一連の要求応答組で作られます。 クライアントは各要求を開始します。(適切な応答を返す前に、サーバはそれを処理します)。 クライアントが次の要求を出す前に各要求は(サーバレポート成否)を完成しなければなりません。 サーバはいつでも、サービス少なくとも1アップロードかうまくいっている互いの認証に続くダウンロード要求にもかかわらず、何れの当事者に論理的な接続を終えることができますSHOULDが望んでいる。
Gustafson, et al. Informational [Page 7] RFC 3760 Securely Available Credentials (SACRED) April 2004
グスタフソン、他 資格証明書(神聖な)2004年4月にしっかりと利用可能な情報[7ページ]のRFC3760
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.
サウスカロライナ-xは機密保護している資格証明ファイルです。(そのファイルは形式ID分野と資格証明データを含んでいます)。 資格証明データは不透明で、暗号化されたデータ・オブジェクト(例えば、PKCS#15かPKCS#12ファイル)です。 形式IDが、正しく資格証明データを分析するのに必要です。
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値のSHOULDはサーバの「最後に変更された」期日を含んでいます、そして、時間(例えば、この特定の資格証明バージョンがサーバに保存された時間)と5月は一連番号か資格証明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.
ただ一つのユーザ名の下で認証することによって、資格証明書というすべてがアクセスされるかもしれません。 ユーザが、アクセスを保護する1つ以上の異なった認証パスワード(そして/または、認証方法)を使用するのを必要があるか、または好むなら、数個が資格証明書を保証して、その人は異なったユーザ/アカウントの下におけるそれらの資格証明書が命名するSHOULDレジスタです、メソッドが使用したそれぞれの異なった認証あたり1つ。
3.1. Credential Upload
3.1. 資格証明アップロード
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).
資格証明アップロード操作の目的はクライアントが新しい資格証明書を登録するか、または現在保存された資格証明書(例えば適切なかぎ管理ソフトウェアを使用することでクライアントによってアップデートされたかもしれない資格証明書)を取り替えるのを許容することです。
Gustafson, et al. Informational [Page 8] RFC 3760 Securely Available Credentials (SACRED) April 2004
グスタフソン、他 資格証明書(神聖な)2004年4月にしっかりと利用可能な情報[8ページ]のRFC3760
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)を含まなければなりません。
3.1.1. Credential Upload Protocol Sequence
3.1.1. 資格証明アップロードプロトコル系列
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 >
<は[ID-1]>--><--サウスカロライナ-1、名前-1、<名前-1を置いて、新しいID1><は[ID-2]>--><--サウスカロライナ-2、名前-2、<名前-2を置きました、新しいID2>。
...
...
< close > -->
<-- OK (+ disconnect)
<の近い>--><--OK(+ 分離)
new-ID-x is the credential-ID of the newly stored credential.
新しいID xは新たに保存された資格証明書の資格証明IDです。
Gustafson, et al. Informational [Page 9] RFC 3760 Securely Available Credentials (SACRED) April 2004
グスタフソン、他 資格証明書(神聖な)2004年4月にしっかりと利用可能な情報[9ページ]のRFC3760
3.2. Credential Download
3.2. 資格証明ダウンロード
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.
- クライアントSHOULDはサーバを認証します。
- 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.
- 応答は資格証明書と形式IDを含んでいます。
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要求を出すなら、サーバSHOULDは現在のユーザアカウントの下で保存されたすべての資格証明書を返します。
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).
サーバは条件付きのダウンロードが実行されなかったのを示す要求された資格証明書か異なった応答のどちらかを返すべきです(例えば、クライアントには、この正確な資格証明書のコピーが既にあります)。
Gustafson, et al. Informational [Page 10] RFC 3760 Securely Available Credentials (SACRED) April 2004
グスタフソン、他 資格証明書(神聖な)2004年4月にしっかりと利用可能な情報[10ページ]のRFC3760
3.2.1. Credential Download Protocol Sequence
3.2.1. 資格証明ダウンロードプロトコル系列
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 >
'[ID-1]>--><--<GET Name-1、<サウスカロライナ-1、ID-1'><GET Name-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.
ID-2以来2番目の要求、資格証明書がないためにクライアントの要求に含まれているように返されている通知はName-2資格証明書のための識別子に合っていました。
3.3. Credential Removal
3.3. 資格証明取り外し
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.
- そして、ユーザは資格証明名前を含むDELETE要求メッセージにどの資格証明書を取り除いたらよいかを示させます。
- 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に合っていると、資格証明書を削除するでしょう。それらの保存された資格証明書を削除するつもりであるクライアントが資格証明書の異なった見解を誤って削除しないのを保証するためにこれをするかもしれません。
Gustafson, et al. Informational [Page 11] RFC 3760 Securely Available Credentials (SACRED) April 2004
グスタフソン、他 資格証明書(神聖な)2004年4月にしっかりと利用可能な情報[11ページ]のRFC3760
3.3.1. Credential Removal Protocol Sequence
3.3.1. 資格証明取り外しプロトコル系列
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 Name-1、[ID1]>--><--<Name-1は><DEL Name-2を削除して、[ID2]>--><--<Name-2は>を削除しました。
...
...
< close > -->
<-- OK (+ disconnect)
<の近い>--><--OK(+ 分離)
3.4. Credential Management
3.4. 資格証明管理
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資格証明書が以前に保存された資格証明書を取り除きながら論理的に相当しているアップロード。
4. Protocol Considerations
4. プロトコル問題
4.1. Secure Credential Formats
4.1. 安全な資格証明形式
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.
オンで、アップロードされていた状態で作成されたその資格証明書を確実にするためにある、いかなる他のデバイスでもあるデバイスをダウンロードして、使用できて、クライアント実装を従わせながらすべてでサポートしなければならない「実装するために義務的」ただ一つの資格証明書式を定義する必要があります。
Gustafson, et al. Informational [Page 12] RFC 3760 Securely Available Credentials (SACRED) April 2004
グスタフソン、他 資格証明書(神聖な)2004年4月にしっかりと利用可能な情報[12ページ]のRFC3760
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.
このドキュメント中では、資格証明書は不透明な(暗号化された)データ・オブジェクトとして扱われます、そして、そういうものとして、資格証明形式は基本的な資格証明交換プロトコルに影響しません。
4.2. Authentication Methods
4.2. 認証方法
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認証方法が攻撃者が潜在的セキュリティの脆弱性を利用するのを試みるかもしれないネットワーク環境にユーザ資格証明書のための保護を提供しなければなりません。 神聖な要件[RFC3157]、セクション3.1、脆弱性を見てください。
At a minimum, each SACRED authentication method SHOULD ensure that:
最小限では、それぞれのSACRED認証方法SHOULDは、以下のことを確実にします。
- 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つ以上のユーザ資格証明書の交換は、このセッションキーを使用することで保護されます。
Gustafson, et al. Informational [Page 13] RFC 3760 Securely Available Credentials (SACRED) April 2004
グスタフソン、他 資格証明書(神聖な)2004年4月にしっかりと利用可能な情報[13ページ]のRFC3760
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と.2がいつこれらの認証方法を使用するかに関して何らかの指導を提供する4.2はSACREDクライアントにとって、有効であるに違いない要素(パスワード、キーは対にされます、ユーザー証明書、カリフォルニア証明書)をそれらが提供するジェネリックセキュリティ能力とセキュリティに基礎づけました。
4.2.1. Strong Password Protocols
4.2.1. 強いパスワードプロトコル
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]、および[スピーク]で説明されたものなどの強いパスワードプロトコルは、互いの認証とプライバシーを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回のパーティーの間でメッセージを交換します、そして、正統のユーザとサーバだけに知られている共有された一般的な値を計算するのに補足的なアルゴリズムを使用します。双方は2回のパーティーのコミュニケーションを保証するのに使用されるかもしれない強い(左右対称の)キーを引き出します。
4.2.2. TLS Authentication
4.2.2. TLS認証
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
TLSはクライアントがサーバを認証する能力(時々サーバサイドTLSと呼ばれる)とセッションレベル暗号化キーの1組がしっかりと交換される基本的な安全なセッションを提供します。
Gustafson, et al. Informational [Page 14] RFC 3760 Securely Available Credentials (SACRED) April 2004
グスタフソン、他 資格証明書(神聖な)2004年4月にしっかりと利用可能な情報[14ページ]のRFC3760
client and server. Following server authentication and security context setup, all client requests and server responses exchanged are integrity and privacy protected.
クライアントとサーバ次のサーバ証明、セキュリティ文脈セットアップ、すべてのクライアント要求、および応答が交換したサーバは保全であり、プライバシーは保護されました。
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.
また、(ますます複雑)のTLSサーバ証明書チェーン処理の不完全な実装がSACREDクライアントで同様の感染につながるかもしれないことに注意してください、うまくいっている資格証明サーバ仮面舞踏会か中央の男性攻撃を許して。
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を使用するか、同様の積層技術)の簡単なレイヤリングが複合体を作り出すのを理解しているのも重要です、個々のプロトコルの知られている弱点を暴露して、開発できる組み合わせ特有の攻撃で容易に破られるかもしれない多層セキュリティプロトコル。
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セッションが2回のパーティーの間で確立された後に資格証明サーバは、クライアントがリモート・ユーザーを認証するために彼女のユーザイドとパスワード情報を提供するよう要求できます。 望ましくは、クライアントとサーバは、サーバがそれで、クライアント(恐らく逆もまた同様である)を認証できる認証操作を実行するのを協力できます。aは「知識方法のゼロを合わせます」。 そのような場合、クライアントには、セキュリティー証明書がある必要はありません。
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つのセキュリティー証明書でクライアントを構成しなければなりません。
Gustafson, et al. Informational [Page 15] RFC 3760 Securely Available Credentials (SACRED) April 2004
グスタフソン、他 資格証明書(神聖な)2004年4月にしっかりと利用可能な情報[15ページ]のRFC3760
4.2.3. Other Authentication Methods
4.2.3. 他の認証方法
Other authentication methods that provide the necessary security capabilities MAY also be suitable for use with SACRED credential exchange protocols.
また、必要なセキュリティ能力を提供する他の認証方法もSACREDの資格証明交換プロトコルによって使用に適しているかもしれません。
4.3. Transport Protocol Suites
4.3. トランスポート・プロトコルスイート
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--ビープ音--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によります。 それぞれのこれらの部分構造合成法は残っている応用層問題(基本的なセッション管理、セッションレベルセキュリティ、プレゼンテーション/形式、アプリケーションの機能性)を取り扱いの異なった方法に提供します。
4.3.1. TCP
4.3.1. 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接続/ソケットに接続するカスタム資格証明交換メッセージング・プロトコルの開発を必要とします。 このアプローチの主要便益はまさに機能性が必要としたプロトコルといいえをさらに提供する能力です。 ほとんどのサーバとクライアント開発環境が既に平らなAPIが必要としたソケットを提供します。
4.3.2. BEEP
4.3.2. ビープ音
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]で説明されたBlocks Extensible Exchangeプロトコル(BEEP)に建てられます。 BEEPは必要なトランスポート層マッピングがTCP、TLSなどの上の操作のために定義された数個の移送機構のどれかの上に汎用、同輩への同輩交換処理を供給します。 また、[RFC3081]を見てください。
Gustafson, et al. Informational [Page 16] RFC 3760 Securely Available Credentials (SACRED) April 2004
グスタフソン、他 資格証明書(神聖な)2004年4月にしっかりと利用可能な情報[16ページ]のRFC3760
BEEP provides the necessary user authentication/session security and session management capabilities needed to support SACRED credential exchange operations.
BEEPは能力がSACREDの資格証明交換が操作であるとサポートする必要があった必要なユーザー認証/セッションセキュリティとセッション管理を提供します。
4.3.3. HTTP
4.3.3. HTTP
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]で説明されたハイパーテキストTransportプロトコル(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)の両方が、使用されるかもしれません。
5. Security Considerations
5. セキュリティ問題
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.
以下のセキュリティ問題は、資格証明移動性をサポートするフレームワークのために考えられるために一般的な観測と注意を特定します。 このフレームワークをサポートするためにプロトコルを設計するか、または実装するとき、これらのセキュリティ問題を認識して、その上、SACRED Requirementsドキュメント[RFC3157]セキュリティConsiderationsに相談するべきです。
5.1. Communications Security
5.1. 通信秘密保全
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はクライアントかサーバ証明に関係する情報、または資格証明書に関するコミュニケーションを含むでしょう。 この情報は以下で特定された伝統的な安全上の配慮を受けることがあります。
5.1.1. Confidentiality
5.1.1. 秘密性
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.
同様に、実体資格証明書はクライアントからサーバまでコミュニケートすると保護された秘密性であるに違いありません、そして、逆もまた同様です。 また、コミュニケートしている値は辞書攻撃に抵抗するべきです。
Gustafson, et al. Informational [Page 17] RFC 3760 Securely Available Credentials (SACRED) April 2004
グスタフソン、他 資格証明書(神聖な)2004年4月にしっかりと利用可能な情報[17ページ]のRFC3760
5.1.2. Integrity
5.1.2. 保全
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).
クライアントと資格証明サーバの間のコミュニケーション保全が必要です。 このように、意図しているクライアント操作は変更されないかもしれません、そして、(例えば、アップデートから資格証明書の削除まで)「古い」資格証明書は陰湿にクライアントに与えられていなくしませんように(例えば、ことによると前の資格証明ダウンロードを再演する攻撃者で)。
5.1.3. Entity Authentication
5.1.3. 実体認証
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.
サーバが適切にクライアントを認証しなければならないので、資格証明書は攻撃者に誤って明らかにされません。 クライアントは、それらのパスワードを攻撃者に明らかにするのを防ぐために資格証明サーバの適切な識別を確実にしなければなりません。 これらの目標は強いパスワードベースのプロトコルでそれとなく明らかに達成されるかもしれません。 サーバが明らかに特定されるなら、ユーザかクライアントが、ユーザパスワードが信じられたサーバに伝えられるのを保証しなければなりません。これは、適切な信じられたキーをクライアントにインストールすることによって、達成されるかもしれません。
5.1.4. Non-repudiation
5.1.4. 非拒否
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プロトコル自体に関する要件は全くありません、資格証明書が使用されている文脈がそのような要件を持っているかもしれませんが。
5.2. Systems Security
5.2. システムセキュリティ
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.
システムセキュリティはSACREDプロトコルを支持してサーバで保存されるプロトコル終点(すなわち、クライアントとサーバ)と情報の保護に関係があります。
5.2.1. Client Security
5.2.1. クライアントセキュリティ
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.
さらに、クライアントインタフェースは、ユーザによって入られるように攻撃者がパスワードを観測できる「ショルダーハック」を阻むように設計されるべきです。 これは、入られる場合パスワードの正確なキャラクタの言葉を繰り返さないことによって、しばしば達成されます。
Gustafson, et al. Informational [Page 18] RFC 3760 Securely Available Credentials (SACRED) April 2004
グスタフソン、他 資格証明書(神聖な)2004年4月にしっかりと利用可能な情報[18ページ]のRFC3760
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.
また、インタフェースは、適切に保護を励行されることができるように、適切なインタフェース分野へのパスワードの入ることを奨励するべきです。 例えば、ユーザは、「ユーザ名」フィールドにそれらのパスワードを誤って入力しないように誘導されるべきです(それらのパスワードがこの場合おそらくスクリーンに反映されて、サーバに伝えられる場合暗号化されないかもしれないので)。 これはユーザ名の自動挿入か例えば、適切なスクリーンの上の対話分野でのいくつかのユーザ名前選択で達成されるかもしれません。
5.2.2. Client Security, TLS Server Authentication
5.2.2. クライアントセキュリティ、TLSサーバー証明
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クライアントSHOULD、クライアントによって使用されることになっているそれらのSACRED信頼アンカーに単に構成されてください。 信頼の再使用は他のアプリケーションから投錨されます、例えば、インターネット・ブラウザがNOT RECOMMENDEDです。
5.2.3. Server Security
5.2.3. サーバセキュリティ
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.
特定のユーザアカウントにアクセスするオンライン試みは、制御されるべきである、または少なくともモニターされているべきです。 コントロールは、特定のアカウントへの多くの失敗のログイン、またはことによると全体でアカウントのロックの後に時間遅れを取り入れることによって、励行されるかもしれません。 あるいはまた、失敗の資格証明アクセス試みの敷居にいったん達していると管理通知が作り出されるところに1つは単に失敗の試みを登録するかもしれません。
Gustafson, et al. Informational [Page 19] RFC 3760 Securely Available Credentials (SACRED) April 2004
グスタフソン、他 資格証明書(神聖な)2004年4月にしっかりと利用可能な情報[19ページ]のRFC3760
5.2.4. Denial of Service
5.2.4. サービス妨害
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攻撃を特定して)。
6. References
6. 参照
6.1. Normative References
6.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC3157] Arsenault, A. and S. Farrell, "Securely Available
Credentials - Requirements", RFC 3157, August 2001.
[RFC3157] Arsenault、A.、およびS.ファレル、「しっかりと利用可能な資格証明書--、要件、」、RFC3157、8月2001日
6.2. Informative References
6.2. 有益な参照
[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.メリット、「主要な状態で暗号化されて、以下を交換してください」 「辞書攻撃に対して安全なパスワードベースのプロトコル」、SecurityとPrivacy、1992年5月のResearchの上のIEEE SymposiumのProceedings。
[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]、「PKCS12v1.0:」 「個人情報交換構文」、RSA研究所、1999年6月24日。
[PKCS15] "PKCS #15 v1.1: Cryptographic Token Information Syntax
Standard", RSA Laboratories, June 2000.
[PKCS15]、「PKCS#15v1.1:」 「暗号のトークン情報構文規格」、RSA研究所、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、「ハイパーテキストはプロトコルを移します--HTTP/1インチ、RFC1945、1996年5月。」
Gustafson, et al. Informational [Page 20] RFC 3760 Securely Available Credentials (SACRED) April 2004
グスタフソン、他 資格証明書(神聖な)2004年4月にしっかりと利用可能な情報[20ページ]のRFC3760
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC2246] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[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.、Gettys、J.、ムガール人、J.、Frysyk、H.、Masinter、L.、リーチ、M.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月」。
[RFC2945] Wu, T., "The SRP Authentication and Key Exchange System",
RFC 2945, September 2000.
[RFC2945] ウーと、T.と、「SRP認証と主要な交換システム」、RFC2945、9月2000日
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
RFC 3080, March 2001.
[RFC3080] ローズ、M.、「ブロックの広げることができる交換プロトコルコア」、RFC3080、2001年3月。
[RFC3081] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March
2001.
M. [RFC3081]ローズ、RFC3081、「TCPへのビープ音コアを写像すること」での3月2001日
[SPEKE] Jablon, D., "Strong Password-Only Authenticated Key
Exchange", September 1996.
[スピーク]Jablon、D.、「強いパスワードだけ認証された主要な交換」、1996年9月。
7. Authors' Addresses
7. 作者のアドレス
Dale Gustafson Future Foundation Inc.
デール・グスタフソンFutureの財団株式会社
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.
マグヌスニストロムRSAセキュリティInc.
EMail: magnus@rsasecurity.com
メール: magnus@rsasecurity.com
Gustafson, et al. Informational [Page 21] RFC 3760 Securely Available Credentials (SACRED) April 2004
グスタフソン、他 資格証明書(神聖な)2004年4月にしっかりと利用可能な情報[21ページ]のRFC3760
8. Full Copyright Statement
8. 完全な著作権宣言文
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.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Gustafson, et al. Informational [Page 22]
グスタフソン、他 情報[22ページ]
一覧
スポンサーリンク
