RFC3767 日本語訳
3767 Securely Available Credentials Protocol. S. Farrell, Ed.. June 2004. (Format: TXT=49552 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Farrell, Ed. Request for Comments: 3767 Trinity College Dublin Category: Standards Track June 2004
ワーキンググループのS.ファレル、エドをネットワークでつないでください。コメントのために以下を要求してください。 3767年のトリニティー・カレッジダブリンカテゴリ: 標準化過程2004年6月
Securely Available Credentials Protocol
しっかりと利用可能な資格証明書プロトコル
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(C)インターネット協会(2004)。
Abstract
要約
This document describes a protocol whereby a user can acquire cryptographic credentials (e.g., private keys, PKCS #15 structures) from a credential server, using a workstation that has locally trusted software installed, but with no user-specific configuration. The protocol's payloads are described in XML. This memo also specifies a Blocks Extensible Exchange Protocol (BEEP) profile of the protocol. Security requirements are met by mandating support for TLS and/or DIGEST-MD5 (through BEEP).
このドキュメントはユーザが局所的に信じられたソフトウェアをインストールするワークステーションを使用して、資格証明サーバから暗号の資格証明書(例えば、秘密鍵、PKCS#15構造)を取得しますが、ユーザ特有の構成なしで取得できるプロトコルについて説明します。 プロトコルのペイロードはXMLで説明されます。 また、このメモはプロトコルのBlocks Extensible Exchangeプロトコル(BEEP)プロフィールを指定します。 セキュリティ必要条件は、TLS、そして/または、DIGEST-MD5(BEEPを通した)のサポートを強制することによって、満たされます。
Table Of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. The Protocol. . . . . . . . . . . . . . . . . . . . . . . . . 3 3. BEEP Profile for SACRED. . . . . . . . . . . . . . . . . . . . 9 4. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 13 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 16 Appendix A: XML Schema . . . . . . . . . . . . . . . . . . . . . . 17 Appendix B: An Example of Tuning with BEEP . . . . . . . . . . . . 20 Appendix C: Provision SACRED using other Protocols . . . . . . . . 23 Editor's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 25
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 プロトコル。 . . . . . . . . . . . . . . . . . . . . . . . . 3 3. 神聖な状態でプロフィールを鳴らします。 . . . . . . . . . . . . . . . . . . . 9 4. IANA問題。 . . . . . . . . . . . . . . . . . . . . . 12 5. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 13 6. 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 15承認. . . . . . . . . . . . . . . . . . . . . . . . . 16付録A: XML図式. . . . . . . . . . . . . . . . . . . . . . 17付録B: ビープ音. . . . . . . . . . . . 20付録でCを調整する例: 他のプロトコル. . . . . . . . 23EditorのAddress. . . . . . . . . . . . . . . . . . . . . . . . . 24Full Copyright Statementを使用する支給SACRED。 . . . . . . . . . . . . . . . . . . . . 25
Farrell Standards Track [Page 1] RFC 3767 Secure Credentials Protocol June 2004
ファレル標準化過程[1ページ]RFC3767は、2004年6月に資格証明書がプロトコルであると機密保護します。
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 describes a protocol for the secure exchange of such credentials and is a realization of the abstract protocol framework described in [RFC3760].
このドキュメントは、そのような資格証明書の安全な交換のためにプロトコルについて説明して、[RFC3760]で説明された抽象的なプロトコルフレームワークの実現です。
Many user-chosen passwords are vulnerable to dictionary attacks. So the SACRED protocol is designed to give no information with which an attacker can acquire information for launching a dictionary attack, whether by eavesdropping or by impersonating either the client or server.
多くのユーザによって選ばれたパスワードが辞書攻撃に被害を受け易いです。 それで、SACREDプロトコルは、攻撃者が盗聴かクライアントかサーバをまねることにかかわらず辞書攻撃に着手するための情報を取得できる情報を全く教えないように設計されています。
The protocol also allows a user to create or delete an account, change her account password and/or credentials, and upload the new values to the server. The protocol ensures that only someone that knew the old account password is able to modify the credentials as stored on the credential server. The protocol does not preclude configuring a server to disallow some operations (e.g. credential upload) for some users. The account management operations as a whole are optional implementations for both credential servers and clients.
プロトコルで、ユーザは、アカウントを作成するか、または削除して、彼女のアカウントパスワード、そして/または、資格証明書を変えて、また、新しい値をサーバにアップロードします。プロトコルは、古いアカウントパスワードを知っていただれかだけが資格証明サーバに保存されるように資格証明書を変更できるのを確実にします。プロトコルは、何人かのユーザのために、いくつかの操作(例えば、資格証明アップロード)を禁じるためにサーバを構成するのを排除しません。 全体でアカウント管理操作は資格証明サーバとクライアントの両方のための任意の実装です。
Note that there are potentially two "passwords" involved when using this protocol - the first used to authenticate the user to the credential server, and the second to decrypt (parts of) the credential following a download operation. Where the context requires it, we refer to the former as the account password and the latter as the credential password.
このプロトコルを使用するときかかわる2「パスワード」が潜在的にあることに注意してください--1番目が以前はよく資格証明サーバ、および解読する2番目にユーザを認証していた、(離れている、)、ダウンロード操作に続く資格証明書。 文脈がそれを必要とするところでは、私たちは資格証明パスワードとしてアカウントパスワードと後者と前者を呼びます。
Using a protocol such as this is somewhat less secure than using a smart card, but can be used until smart cards and smart card readers on workstations become ubiquitous, and can be useful even after smart cards are ubiquitous, as a backup strategy when a user's smart card is lost or malfunctioning.
ユーザのスマートカードが失われているか、または誤動作しているとき、これなどのプロトコルを使用するのはスマートカードを使用しますが、ワークステーションの上のスマートカードとスマートカードリーダーが遍在するようになって、スマートカードがバックアップ戦略として遍在していた後にさえ役に立つ場合があるまで使用できるよりいくらか安全ではありません。
The protocol sets out to meet the requirements in [REQS]. Cryptographic credentials may take the form of private keys, PKCS #15 [PKCS15], or structures. As stated, a profile based on BEEP [BEEP] is specified for message transport and security (integrity,
プロトコルは、[REQS]で条件を満たし始めます。 暗号の資格証明書はPKCS#15の秘密鍵の形、[PKCS15]、または構造を取るかもしれません。 BEEP[BEEP]に基づくプロフィールが述べられているようにメッセージ転送とセキュリティに指定される、(保全
Farrell Standards Track [Page 2] RFC 3767 Secure Credentials Protocol June 2004
ファレル標準化過程[2ページ]RFC3767は、2004年6月に資格証明書がプロトコルであると機密保護します。
authentication, and confidentiality). In that case, the security requirements are met by mandating support (via BEEP) for TLS [TLS] and/or DIGEST-MD5 [DIGEST-MD5].
認証、および秘密性、) その場合、セキュリティ必要条件は、TLS[TLS]、そして/または、DIGEST-MD5[DIGEST-MD5]のサポート(BEEPを通した)を強制することによって、満たされます。
We assume the only authentication information available to the user is a username and password.
私たちは、ユーザにとって、利用可能な唯一の認証情報がユーザ名とパスワードであると思います。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. The Protocol
2. プロトコル
This section defines the account management and "run-time" operations for the SACRED protocol.
このセクションはSACREDプロトコルのためのアカウント管理と「ランタイム」操作を定義します。
It also describes the message formats used, which are described in XML [XMLSCHEMA]. Appendix A provides an XML schema for these elements.
また、それは使用されるメッセージ・フォーマットについて説明します。(メッセージ・フォーマットはXML[XMLSCHEMA]で説明されます)。 付録AはXML図式をこれらの要素に供給します。
The approach taken here is to define SACRED elements that are compatible with the elements used in [XKMS] and [XMLDSIG], so that an implementation of this protocol can easily also support XKMS, and vice versa.
ここに取られたアプローチは[XKMS]と[XMLDSIG]で使用される要素と互換性があるSACRED要素を定義することです、また、このプロトコルの実装が容易にXKMSをサポートすることができるように、逆もまた同様に。
It is also intended that other SACRED protocol instances (e.g. using a different authentication scheme, credential format, or transport protocol) could re-use many of the definitions here.
また、他のSACREDプロトコルインスタンス(例えば、異なった認証体系を使用するか、資格証明形式、またはトランスポート・プロトコル)がここで定義の多くを再使用するかもしれないことを意図します。
2.1. Account Management Operations
2.1. アカウント管理操作
These operations MAY be implemented, that is, they are OPTIONAL.
これらの操作は実装されるかもしれません、すなわち、それらがOPTIONALです。
2.1.1. Information Request
2.1.1. 情報要求
This operation does NOT REQUIRE authentication.
この操作はどんなREQUIREにも認証しません。
The purpose of this operation is to provide the client with the values required for account creation.
この操作の目的はアカウント作成に必要である値をクライアントに提供することです。
The client sends an InfoRequest message (which has no content).
クライアントはInfoRequestメッセージ(内容を全く持っていない)を送ります。
The server responds with an InfoResponse message which contains the authentication mechanism parameters for the server and the list of supported ProcessInfo types. For DIGEST-MD5, this consists of the list of realms (each as an XML element named "Realm") which the server supports. There MUST be at least one realm specified.
サーバはサーバのための認証機構パラメタを含むInfoResponseメッセージで反応します、そして、サポートしているProcessInfoのリストはタイプされます。 DIGEST-MD5に関しては、これはサーバがサポートする分野(XML要素がそれぞれ「分野」を命名したので)のリストから成ります。 指定された少なくとも1つの分野があるに違いありません。
Farrell Standards Track [Page 3] RFC 3767 Secure Credentials Protocol June 2004
ファレル標準化過程[3ページ]RFC3767は、2004年6月に資格証明書がプロトコルであると機密保護します。
Clients MUST be able to select one from a list of Realms and MUST be able to disregard any other information present (allowed for extensibility).
クライアントは、Realmsのリストからの1つを選択できなければならなくて、いかなる他の情報プレゼント(伸展性を考慮する)も無視できなければなりません。
2.1.2. Create Account
2.1.2. アカウントを作成してください。
This operation REQUIRES server authentication.
この操作REQUIRESサーバ証明。
The purpose of this operation is to setup a new account on the server. The information required for a "new" account will depend on the SASL [SASL] mechanism used.
この操作の目的はサーバで新しいアカウントをセットアップすることです。「新しい」アカウントに必要である情報は[SASL]メカニズムが使用したSASLによるでしょう。
The client sends a CreateAccountRequest, which contains the account name (e.g. username). It also contains the elements required to create an account for a particular authentication mechanism. The actual information is defined according to the authentication mechanism. For DIGEST-MD5, this consists of the password verifier (the hashed username, password and realm) and the chosen realm. Although more than one set of such data is allowed by the data structures defined in the appendix, clients SHOULD only include one here.
クライアントはCreateAccountRequestを送ります。(CreateAccountRequestはアカウント名(例えば、ユーザ名)を含みます)。 また、それは特定の認証機構のためにアカウントを作成しなければならなかった要素を含んでいます。 認証機構に従って、実際の情報は定義されます。 DIGEST-MD5に関しては、これはパスワード検証(論じ尽くされたユーザ名、パスワード、および分野)と選ばれた分野から成ります。 1セット以上のそのようなデータは付録で定義されたデータ構造によって許容されていますが、クライアントSHOULDはここに1つを含んでいるだけです。
The server responds with an error or acknowledgement message.
サーバは誤りか確認メッセージで反応します。
2.1.3. Remove Account
2.1.3. アカウントを取り除いてください。
This operation REQUIRES mutual authentication.
この操作のREQUIRESの互いの認証。
The purpose of this operation is to delete the entire account.
この操作の目的は全体のアカウントを削除することです。
The client sends a RemoveAccountRequest message (which has no content) to the server.
クライアントはRemoveAccountRequestメッセージ(内容を全く持っていない)をサーバに送ります。
The server MUST delete all information relating to the account and respond with an error or acknowledgement message.
サーバは、アカウントに関連するすべての情報を削除して、誤りか確認メッセージで反応しなければなりません。
2.1.4. Modify Account
2.1.4. アカウントを変更してください。
This operation REQUIRES mutual authentication.
この操作のREQUIRESの互いの認証。
The purpose of this operation is to allow the client to change the information required for authentication. The information required will depend on the authentication method used.
この操作の目的はクライアントが認証に必要である情報を変えるのを許容することです。 必要である情報はメソッドが使用した認証によるでしょう。
Farrell Standards Track [Page 4] RFC 3767 Secure Credentials Protocol June 2004
ファレル標準化過程[4ページ]RFC3767は、2004年6月に資格証明書がプロトコルであると機密保護します。
The client sends a ModifyAccountRequest message, which contains the elements required to change the authentication information for the account, for a particular authentication mechanism. The actual information is defined according to the authentication mechanism. For [DIGEST-MD5], it will consist of a realm and password verifier value.
クライアントはModifyAccountRequestメッセージを送ります、特定の認証機構のために。(メッセージはアカウントのための認証情報を変えなければならなかった要素を含みます)。 認証機構に従って、実際の情報は定義されます。 [DIGEST-MD5]に関しては、それは分野とパスワード検証価値から成るでしょう。
Once the account information has been changed, the server will respond with an error or acknowledgement message.
いったん会計情報を変えると、サーバは誤りか確認メッセージで反応するでしょう。
2.2. "Run-time" Operations
2.2. 「ランタイム」操作
These operations MUST be supported by all conformant implementations.
これらの操作はすべてのconformant実装で後押しされていなければなりません。
2.2.1. Credential Upload
2.2.1. 資格証明アップロード
This operation REQUIRES mutual authentication.
この操作のREQUIRESの互いの認証。
The purpose of this operation is to allow the client to deposit a credential with the server.
この操作の目的はクライアントがサーバに資格証明書を預けるのを許容することです。
The client sends an UploadRequest message to the server which MUST contain one Credential.
クライアントは1Credentialを含まなければならないサーバにUploadRequestメッセージを送ります。
If a credential with the same credential selector field as in the UploadRequest (a "matching" credential) already exists for the account, then that credential is replaced with the new credential from the UploadRequest. Otherwise a "new" credential is associated with that account. If a new credential is being uploaded, then the client SHOULD include (in LastModified) its local concept of the time (if it has one), or an indicator that it has no clock. The actual value of LastModified can be anything, (but the element has to be present) since this will be overwritten by the server in any case.
UploadRequestの(「合わせている」資格証明書)と同じ資格証明セレクタ分野がある資格証明書がアカウントのために既に存在しているなら、その資格証明書をUploadRequestから新しい資格証明書に取り替えます。 さもなければ、「新しい」資格証明書はそのアカウントに関連しています。 新しい資格証明書がアップロードされているなら、クライアントSHOULDは現代のローカルの概念(それに1つがあるなら)、または時計を全く持っていないというインディケータを含んでいます(LastModifiedで)。 LastModifiedの実価が何かであるかもしれない、(要素は現在でなければなりません) これがどのような場合でもサーバによって上書きされるので。
If any change is made to the stored credentials associated with the account, then the server MUST update the corresponding LastModified value (returned in DownloadResponse messages) to the current time (at the server).
何か変更をアカウントに関連している保存された資格証明書にするなら、サーバは現在の時間(サーバにおける)まで対応するLastModified値(DownloadResponseメッセージでは、返す)をアップデートしなければなりません。
Farrell Standards Track [Page 5] RFC 3767 Secure Credentials Protocol June 2004
ファレル標準化過程[5ページ]RFC3767は、2004年6月に資格証明書がプロトコルであると機密保護します。
The LastModified value in the UploadRequest MUST be the value which was most recently received in a corresponding DownloadResponse for that credential. This means the clients are strongly RECOMMENDED to only produce an UploadRequest based on recently downloaded credentials, since otherwise the LastModified value may be out of date.
UploadRequestのLastModified値はごく最近その資格証明書のために対応するDownloadResponseに受け取られた値でなければなりません。 これは、クライアントが強く、UploadRequestが最近に基礎づけた生産物だけへのRECOMMENDEDが資格証明書をダウンロードしました、さもなければ、LastModified値が時代遅れであるかもしれないのでことであることを意味します。
The LastModified value can also be of use in detecting conflicts. For example, download to platform A, download to platform B, update from B, update from A. The server could detect a conflict on the second upload. In this case the server MUST respond with a BEEP error (which SHOULD be StaleCredential).
また、LastModified値も闘争を検出する際に役に立つ場合があります。 例えば、プラットホームAへのダウンロード、プラットホームBへのダウンロード、Bからのアップデート、A. サーバからのアップデートは2番目のアップロードに闘争を検出するかもしれません。 この場合サーバがBEEP誤りで反応しなければならない、(どのSHOULD、StaleCredential)
The server replaces the provided LastModified value with the current time at the server before storing the credential. (Note that this means that it would be unwise for a client to include the LastModified field in a ClientInfo digital signature which is calculated over the CredentialType.)
資格証明書を保存する前に、サーバはサーバで提供されたLastModified値を現在の時間に取り替えます。 (これが、クライアントがCredentialTypeの上で計算されるClientInfoデジタル署名でLastModified分野を入れるのが、賢明でないことを意味することに注意してください。)
The server responds with an error or acknowledgement message.
サーバは誤りか確認メッセージで反応します。
2.2.2. Credential Download
2.2.2. 資格証明ダウンロード
This operation REQUIRES mutual authentication.
この操作のREQUIRESの互いの認証。
The purpose of this operation is to allow a client to get one or more credentials from a server (the purpose of the entire protocol really!).
この操作の目的はクライアントがサーバから1つ以上の資格証明書を得るのを許容する(全体の目的は本当に議定書を作ります!)ことです。
The client sends a DownloadRequest message to the server which MAY contain a credential selector string for the credential. No, or an empty credential selector means the request is for all credentials associated with the account.
クライアントは資格証明書のための資格証明セレクタストリングを含むかもしれないサーバにDownloadRequestメッセージを送ります。 いいえ、空の資格証明セレクタは要求がアカウントに関連しているすべての資格証明書のためのものであることを意味します。
The server responds with a DownloadResponse or an error message. A DownloadResponse contains one or more credential payloads, including the LastModified time which represents the time (at the server) when the last change was made to each credential associated with the account (e.g. subsequent to an UploadRequest).
サーバはDownloadResponseかエラーメッセージで反応します。 DownloadResponseは1個以上の資格証明ペイロードを含んでいます、最後の変更がアカウントに関連しているそれぞれの資格証明書にされた時(サーバにおける)を表すLastModified時間を含んでいて(例えば、UploadRequestにその後、)
2.2.3. Credential Delete
2.2.3. 資格証明書は削除します。
This operation REQUIRES mutual authentication.
この操作のREQUIRESの互いの認証。
The purpose of this operation is to allow the client to delete one or all credentials associated with the account.
この操作の目的はクライアントがアカウントに関連している1かすべての資格証明書を削除するのを許容することです。
Farrell Standards Track [Page 6] RFC 3767 Secure Credentials Protocol June 2004
ファレル標準化過程[6ページ]RFC3767は、2004年6月に資格証明書がプロトコルであると機密保護します。
The client sends a DeleteRequest message to the server which can contain either a CredentialSelector or an All element.
クライアントはCredentialSelectorかAll要素のどちらかを含むことができるサーバにDeleteRequestメッセージを送ります。
If the DeleteRequest contains an All element, then all of the credentials associated with that account are deleted.
DeleteRequestがAll要素を含んでいるなら、そのアカウントに関連している資格証明書のすべてが削除されます。
If the DeleteRequest contains a CredentialSelector, then the request MAY include a LastModified value. If the LastModified value is present in the DeleteRequest, then it MUST be the value which was most recently received in a corresponding DownloadResponse for that credential. If the value does not match, then the server MUST NOT delete the credentials.
DeleteRequestがCredentialSelectorを含んでいるなら、要求はLastModified値を含むかもしれません。 LastModified値がDeleteRequestに存在しているなら、それはごく最近その資格証明書のために対応するDownloadResponseに受け取られた値であるに違いありません。 値が合っていないなら、サーバは資格証明書を削除してはいけません。
If no "matching" credential exists, the server returns an error.
「合わせている」資格証明書が全く存在していないなら、サーバは誤りを返します。
The server responds to this request with an error or acknowledgement message.
サーバは誤りか確認メッセージでこの要求に応じます。
2.3. Miscellaneous
2.3. その他
2.3.1. Session Security
2.3.1. セッションセキュリティ
Six SACRED operations are defined above. In this section we specify the requirements for security for each of the operations (where supported).
6つのSACRED操作が上で定義されます。 このセクションでは、私たちはそれぞれの操作にセキュリティのための要件を指定します(サポートされるところで)。
Operation Security REQUIRED
--------- -----------------
Information request NONE
Create account Server authentication,
Confidentiality, Integrity
Remove account Mutual authentication,
Confidentiality, Integrity
Modify account Mutual authentication,
Confidentiality, Integrity
Credential upload Mutual authentication,
Confidentiality, Integrity
Credential download Mutual authentication,
Confidentiality, Integrity
Credential delete Mutual authentication,
Confidentiality, Integrity
操作セキュリティが必要です。--------- ----------------- 情報要求NONE Createアカウントサーバー証明、Confidentiality、Integrity RemoveアカウントMutual認証、Confidentiality、Integrity ModifyアカウントMutual認証、Confidentiality、Integrity CredentialアップロードMutual認証、Confidentiality、Integrity CredentialダウンロードMutual認証、Confidentiality、Integrity CredentialはMutual認証を削除します、Confidentiality、Integrity
The security requirements can be met by several mechanisms. This document REQUIRES credential servers to support TLS and DIGEST-MD5. Clients MUST support DIGEST-MD5 and TLS with server authentication.
数個のメカニズムこのドキュメントREQUIRES資格証明書のTLSをサポートするサーバとDIGEST-MD5はセキュリティ必要条件を満たすことができます。 クライアントはサーバ証明でDIGEST-MD5とTLSをサポートしなければなりません。
Farrell Standards Track [Page 7] RFC 3767 Secure Credentials Protocol June 2004
ファレル標準化過程[7ページ]RFC3767は、2004年6月に資格証明書がプロトコルであると機密保護します。
The mandatory-to-implement TLS cipher suite for SACRED is TLS_RSA_WITH_3DES-EDE_CBC_SHA. Implementations SHOULD also support TLS_RSA_WITH_AES_128_CBC_SHA [TLSAES].
SACREDに、実装するために義務的なTLS暗号スイートはTLS_RSA_WITH_3DES-EDE_CBC_SHAです。 また、実装SHOULDは、TLS_RSA_がWITH_AES_128_CBC_SHA[TLSAES]であるとサポートします。
When performing mutual authentication using DIGEST-MD5 for the client, DIGEST-MD5 MUST only be used "within" a TLS server- authenticated "pipe", and MUST only be used for client authentication. That is, we do not use the DIGEST-MD5 security services (confidentiality, integrity etc.).
クライアントにDIGEST-MD5を使用することで互いの認証を実行するとき、DIGEST-MD5 MUSTだけをTLSサーバが認証した中古の“within"が「運ばれる」ということであり、クライアント認証に使用するだけでよいです。 すなわち、私たちはDIGEST-MD5セキュリティー・サービス(保全秘密性など)を使用しません。
2.3.2. Handling Multiple Credentials for an Account
2.3.2. アカウントのために複数の資格証明書を扱います。
When more than one credential is stored under a single account, the client can select a single credential using the optional credential selector string.
1つ以上の資格証明書がただ一つのアカウントの下で保存されるとき、クライアントは、任意の資格証明セレクタストリングを使用することでただ一つの資格証明書を選択できます。
There is no concept of a "default credential" - all credentials MUST have an associated selector unique for that account. The selector is REQUIRED for upload requests and OPTIONAL for download requests. If the selector is omitted in a download request, it MUST be interpreted as a request for all the stored credentials.
「デフォルト資格証明書」の概念が全くありません--すべての資格証明書で、関連セレクタはそのアカウントにユニークにならなければなりません。 セレクタは、アップロード要求のためのREQUIREDとダウンロード要求のためのOPTIONALです。 セレクタがダウンロード要求で省略されるなら、すべての保存された資格証明書を求める要求としてそれを解釈しなければなりません。
An empty selector string value (i.e. "") in a credential download request is to be interpreted as if the selector string were omitted, i.e. a download request containing this is a request for all credentials.
すなわち、空のセレクタストリング価値、(「「)、資格証明書では、ダウンロード要求がまるでセレクタストリングが省略されるかのように解釈されることであり、すなわち、すべての資格証明書を求めてこれを含むダウンロード要求が要求である、」
It is an error to have more than one credential stored under the same account where both have the same credential selector string.
それは両方が同じ資格証明セレクタストリングを持っているのと同じアカウントの下で1つ以上の資格証明書を保存させる誤りです。
2.3.3. Common Fields
2.3.3. 共同耕地
All messages sent to the server MAY contain ProcessInfo values. This field MAY be used by other specifications or for vendor extensions. For example, a server might require clients to include a phone number in this field. The information response message contains a list of the types of ProcessInfo that the server supports. This extensibility scheme is similar to that used in [XKMS] and [XBULK].
サーバに送られたすべてのメッセージがProcessInfo値を含むかもしれません。 この分野は他の仕様かベンダー拡大に使用されるかもしれません。 例えば、サーバは、クライアントがこの分野で電話番号を入れるのを必要とするかもしれません。 情報応答メッセージはサーバがサポートするProcessInfoのタイプのリストを含んでいます。 この伸展性体系は[XKMS]と[XBULK]で使用されるそれと同様です。
Where no specific response message is defined for an operation (e.g. for UploadRequest), then the transport will indicate success or failure.
そして、どんな特定の応答メッセージも操作(例えば、UploadRequestのための)のために定義されないところでは、輸送は成否を示すでしょう。
All of the response messages defined here MAY contain a Status string, containing a value intended for human consumption.
人間の消費で意図する値を含んでいて、ここで定義された応答メッセージのすべてがStatusストリングを含むかもしれません。
Farrell Standards Track [Page 8] RFC 3767 Secure Credentials Protocol June 2004
ファレル標準化過程[8ページ]RFC3767は、2004年6月に資格証明書がプロトコルであると機密保護します。
2.3.4. Credential Format
2.3.4. 資格証明形式
A number of messages involve the Credential element. It has the following fields (all optional fields may occur exactly zero or one times unless otherwise stated):
多くのメッセージがCredential要素を伴います。 それには、以下の分野があります(別の方法で述べられない場合、すべての任意の分野がちょうどゼロか1回起こるかもしれません):
- CredentialSelector contains a string by which this particular
credential (for this account) can be identified.
- PayLoad contains either a ds:KeyInfo or some other form of
credential. Implementations MUST support the PKCS #15 form of
ds:KeyInfo defined below (the SacredPKCS15 element).
- LastModified is a string containing the time (at the server) at
which this credential was last modified.
- TimeToLive (optional) is a hint clients SHOULD honor, which
specifies the number of seconds the downloaded credential is to be
usable.
- ProcessInfo (optional) MAY contain any (typed) information that
the server is intended to process. If the server doesn't support
any of the ProcessInfo data, it MAY ignore that data.
- ClientInfo (optional) MAY contain any (typed) information that the
client is intended to process, but which the server MUST ignore.
If the client doesn't support any of the ClientInfo data, it MAY
ignore that data (e.g. if the ClientInfo is device specific).
- CredentialSelectorはこの特定の資格証明書(このアカウントのための)を特定できるストリングを含んでいます。 - PayLoadはdsを含んでいます: KeyInfoかある他のフォームの資格証明書。 実装は、PKCS#がdsの15フォームであるとサポートしなければなりません: (SacredPKCS15要素)の下で定義されたKeyInfo。 - LastModifiedはこの資格証明書が最後に変更された時(サーバにおける)を含むストリングです。 - TimeToLive(任意の)はヒントクライアントSHOULD名誉です、秒数を指定するもの。ダウンロードされた資格証明書は使用可能であることです。 - ProcessInfo(任意の)はサーバが処理することを意図するというどんな(タイプされる)の情報も含むかもしれません。 サーバがProcessInfoデータのいずれもサポートしないなら、それはそのデータを無視するかもしれません。 - ClientInfo(任意の)はクライアントが処理することを意図しますが、サーバが無視しなければならないどんな(タイプされる)の情報も含むかもしれません。 クライアントがClientInfoデータのいずれもサポートしないなら、それはそのデータを無視するかもしれません(例えば、ClientInfoがデバイス特有であるなら)。
3. BEEP Profile for SACRED
3. 神聖な状態でプロフィールを鳴らします。
The protocol described in this memo is realized as a [BEEP] profile.
このメモで説明されたプロトコルは[BEEP]プロフィールとして実現されます。
Future memos may define alternative versions of the BEEP profile for SACRED. When a BEEP peer sends its greeting, it indicates which profiles it is willing to support. Accordingly, when the BEEP client asks to start a channel, it indicates the versions it supports, and if any of these are acceptable to the BEEP server; the latter specifies which profile it is starting.
将来のメモはSACREDのためのBEEPプロフィールの異本を定義するかもしれません。 BEEP同輩が挨拶を送るとき、それは、どのプロフィールを支えるかを構わないそれが、思っている示します。 それに従って、いつBEEPクライアントが、チャンネルを始動するように頼んで、サポートするバージョンを示すか、そして、これらのどれかがBEEPサーバに許容できるかどうか、。 後者は、それがどのプロフィールを始動しているかを指定します。
Profile Identification: http://iana.org/beep/sacred
識別の輪郭を描いてください: http://iana.org/beep/sacred
Messages Exchanged during Channel Creation:
InfoRequest,
CreateAccountRequest,
RemoveAccountRequest,
ModifyAccountRequest,
DownloadRequest,
UploadRequest,
DeleteRequest,
InfoResponse,
メッセージはチャンネル作成の間、交換しました: InfoRequest、CreateAccountRequest、RemoveAccountRequest、ModifyAccountRequest、DownloadRequest、UploadRequest、DeleteRequest、InfoResponse
Farrell Standards Track [Page 9] RFC 3767 Secure Credentials Protocol June 2004
ファレル標準化過程[9ページ]RFC3767は、2004年6月に資格証明書がプロトコルであると機密保護します。
DownloadResponse,
error,
ok
DownloadResponse、誤り、OK
Messages starting one-to-one exchanges:
InfoRequest,
CreateAccountRequest,
RemoveAccountRequest,
ModifyAccountRequest,
DownloadRequest,
UploadRequest,
DeleteRequest
始めが1〜1に以下を交換するというメッセージ InfoRequest、CreateAccountRequest、RemoveAccountRequest、ModifyAccountRequest、DownloadRequest、UploadRequest、DeleteRequest
Messages in positive replies:
ok,
InfoResponse,
DownloadResponse
積極的な返事におけるメッセージ: OK、InfoResponse、DownloadResponse
Messages in negative replies: error
否定的な返事におけるメッセージ: 誤り
Messages in one-to-many changes: none
多くへの1回の変化におけるメッセージ: なし
Message Syntax: c.f.,Section 3
メッセージ構文: c. f.、セクション3
Message Semantics: c.f., Section 2
メッセージ意味論: c. f.、セクション2
Contact Information: c.f., the editor's address section of this memo
問い合わせ先: c. f.、エディタのこのメモのアドレス部
3.1. Profile Initialization
3.1. プロフィール初期設定
Because all but one of the operations of the SACRED profile have security requirements (cf., Section 2.3.1), before starting the SACRED profile, the BEEP session will likely be tuned using either
SACREDプロフィールの操作の1つ以外のすべてには、セキュリティ要件があります。(Cf、セクション2.3.1)、SACREDプロフィールを始動する前に、BEEPセッションは、どちらかを使用することでおそらく調整されるでしょう。
http://iana.org/beep/TLS
http://iana.org/beep/TLS
or
または
http://iana.org/beep/TLS followed by
http://iana.org/SASL/DIGEST-MD5
http://iana.org/SASL/DIGEST-MD5 によって続かれた http://iana.org/beep/TLS
Appendix B gives an example of tuning a BEEP session using DIGEST- MD5 (i.e. it shows how to turn on BEEP security).
付録BはDIGEST MD5を使用することでBEEPセッションを調整する例を出します(すなわち、それは、どのようにBEEPセキュリティをつけるかを示します)。
Regardless, upon completion of the negotiation process, a tuning reset occurs in which both BEEP peers issue a new greeting. Consult Section 3 of [BEEP] for an example of how a BEEP peer may choose to issue different greetings based on whether confidentiality is in use.
不注意に、交渉プロセスの完成のときに、両方のBEEP同輩が新しい挨拶を発行するチューニングリセットは起こります。 BEEP同輩が、秘密性が使用中であるかどうか基づく異なった挨拶を発行するのをどう選ぶかもしれないかに関する例のために[BEEP]のセクション3に相談してください。
Farrell Standards Track [Page 10] RFC 3767 Secure Credentials Protocol June 2004
ファレル標準化過程[10ページ]RFC3767は、2004年6月に資格証明書がプロトコルであると機密保護します。
Any of the messages listed in section 3.2 below may be exchanged during channel initialization (c.f., Section 2.3.1.2 of [BEEP]), e.g.,
チャンネル初期化の間、下のセクション3.2でリストアップされたメッセージのどれかを交換するかもしれない、(c.f.、セクション2.3 .1 .2[BEEP)、例えば。
C: <start number='1'>
C: <profile uri='http://iana.org/beep/sacred'>
C: <![CDATA[<DownloadRequest ...>]]>
C: </profile>
C: </start>
C: <スタート番号は'1'>Cと等しいです:、' <プロフィールuriは' http://iana.org/beep/sacred '>Cと等しいです:、' <[CDATA[<DownloadRequest…>]]!>C: </プロフィール>C: </スタート>。
S: <profile uri='http://iana.org/beep/sacred'>
S: <![CDATA[<DownloadResponse ...>]]>
S: </profile>
S: ' http://iana.org/beep/sacred '<プロフィールuri=>S:、' <[CDATA[<DownloadResponse…>]]!>S: </プロフィール>。
Note that BEEP imposes both encoding and length limitations on the messages that are piggybacked during channel initialization.
BEEPがコード化と長さの制限の両方をチャンネル初期化の間に背負われるメッセージに課すことに注意してください。
3.2. Profile Exchange
3.2. プロフィール交換
All messages are exchanged as "application/beep+xml" (c.f., Section 6.4 of [BEEP]):
「+ アプリケーション/ビープ音xml」(c.f.、[BEEP]のセクション6.4)としてすべてのメッセージを交換します:
Role MSG RPY ERR ---- --- --- --- I InfoRequest InfoResponse error I CreateAccountRequest ok error I RemoveAccountRequest ok error I ModifyAccountRequest ok error I DownloadRequest DownloadResponse error I UploadRequest ok error I DeleteRequest Ok error
役割のMSG RPYは間違えます。---- --- --- --- 間違いない間違いない間違いないI UploadRequest間違いない誤りI DeleteRequest Ok InfoRequest InfoResponse誤りI CreateAccountRequest誤りI RemoveAccountRequest誤りI ModifyAccountRequest誤りI DownloadRequest DownloadResponse誤りI誤り
3.3. Error Handling
3.3. エラー処理
The "error" message from Section 2.3.1.5 of [BEEP] is used to convey error information. Typically, after flagging an error, a peer will initiate a graceful release of the BEEP session.
.5[BEEP]が使用されているセクション2.3.1からの「誤り」メッセージはエラー情報を伝えます。 誤りに旗を揚げさせた後に、通常、同輩はBEEPセッションの優雅なリリースを開始するでしょう。
The following BEEP error reply codes from [BEEP] are to be used:
[BEEP]からの以下のBEEPエラー応答コードは使用されていることです:
code Meaning
==== =======
421 service not available
450 requested action not taken (e.g., lock already in
use)
451 requested action aborted (e.g., local error in
processing)
コードMeaning==== ======= 421 利用可能な450ではなくサービスが、取られた(例えば、既に、使用を閉じ込める)451要求された動作ではなく、動作が中止になったよう要求しました。(例えば、処理における地方の誤り)
Farrell Standards Track [Page 11] RFC 3767 Secure Credentials Protocol June 2004
ファレル標準化過程[11ページ]RFC3767は、2004年6月に資格証明書がプロトコルであると機密保護します。
454 temporary authentication failure
500 general syntax error (e.g., poorly-formed XML)
501 syntax error in parameters (e.g., non-valid XML)
504 parameter not implemented
530 authentication required
534 authentication mechanism insufficient (e.g., too
weak, sequence exhausted, etc.)
535 authentication failure
537 action not authorized for user
538 authentication mechanism requires encryption
550 requested action not taken (e.g., no requested
profiles are acceptable)
553 parameter invalid
554 transaction failed (e.g., policy violation)
454 認証が必要とした530であることは534認証機構不十分な状態で実装されなかったパラメタ(例えば、有効な非XML)504パラメタ(例えば、弱過ぎて、系列疲れ果てているなど)の一時的な認証失敗500の一般的な構文エラー(例えば、不十分に形成されたXML)501構文エラー 535 ユーザ538認証機構が暗号化550を必要とするので、537動作が認可しなかった認証失敗は、取られた(例えば、どんな要求されたプロフィールも許容できません)553パラメタ無効の554トランザクションではなく、動作が失敗したよう要求しました。(例えば、方針違反)
The following SACRED-specific error reply codes can also be used:
また、以下のSACRED特有のエラー応答コードを使用できます:
code Meaning
==== =======
555 Extension (ProcessInfo) used not supported
556 Required extension (ProcessInfo) not present
557 StaleCredential (A bad LastModified value was
contained in an UploadRequest.)
コードMeaning==== ======= 555 (ProcessInfo)が使用した拡張子は、556Required拡張子(ProcessInfo)が現在の557StaleCredentialでないとサポートしませんでした。(悪いLastModified値はUploadRequestに含まれました。)
3.4. SASL Authorization Identity
3.4. SASL承認のアイデンティティ
The use of the SASL authorization identity in this protocol is implementation-specific. If used, the authorization identity is not a substitute for the credential selector field, but may be used to affect authorization for access to credentials.
このプロトコルにおけるSASL承認のアイデンティティの使用は実装特有です。 使用されるなら、承認のアイデンティティは、資格証明セレクタ分野の代用品ではありませんが、資格証明書へのアクセスのための承認に影響するのに使用されるかもしれません。
4. IANA Considerations
4. IANA問題
The IANA has registered the BEEP profile specified in Section 4.
IANAはセクション4で指定されたBEEPプロフィールを登録しました。
http://iana.org/beep/sacred
http://iana.org/beep/sacred
The sacred protocol SHOULD be run over port 1118.
神聖はポートの上の走行が1118であったならSHOULDについて議定書の中で述べます。
The GSSAPI service name (required when using SASL) for this protocol SHALL be "sacred".
The GSSAPI service name (required when using SASL) for this protocol SHALL be "sacred".
Farrell Standards Track [Page 12] RFC 3767 Secure Credentials Protocol June 2004
Farrell Standards Track [Page 12] RFC 3767 Secure Credentials Protocol June 2004
5. Security Considerations
5. Security Considerations
[REQS] calls for specifications to state how they address the vulnerabilities listed below.
[REQS] calls for specifications to state how they address the vulnerabilities listed below.
V1. A passive attacker can watch all packets on the network and
later carry out a dictionary attack.
- The use of DIGEST-MD5 and/or TLS counters this
vulnerability.
V2. An attacker can attempt to masquerade as a credential server
in an attempt to get a client to reveal information online
that allows for a later dictionary attack.
- The use of server or mutual authentication counters this
vulnerability.
V3. An attacker can attempt to get a client to decrypt a chosen
"ciphertext" and get the client to make use of the resulting
plaintext - the attacker may then be able to carry out a
dictionary attack (e.g. if the plaintext resulting from
"decryption" of a random string is used as a DSA private
key).
- The use of server or mutual authentication counters this
vulnerability.
V4. An attacker could overwrite a repository entry so that when
a user subsequently uses what they think is a good
credential, they expose information about their password
(and hence the "real" credential).
- Server implementations SHOULD take measures to protect the
database. Clients MAY use the ClientInfo field to store
e.g. a signature over the Credential, which they then verify
before using the private component.
V5. An attacker can copy a credential server's repository and
carry out a dictionary attack.
- Server implementations SHOULD take measures to protect the
database.
V6. An attacker can attempt to masquerade as a client in an
attempt to get a server to reveal information that allows
for a later dictionary attack.
- The mutual authentication requirements of this protocol
counter this to a great extent. Additionally, credential
servers MAY choose to provide mechanisms that protect
against online dictionary attacks against user account
passwords, either by repeated access attempts to a single
user account (varying the password) or by attempting to
access many user accounts using the same password.
V7. An attacker can persuade a server that a successful login
has occurred, even if it hasn't.
- Client authentication prevents this.
V1. A passive attacker can watch all packets on the network and later carry out a dictionary attack. - The use of DIGEST-MD5 and/or TLS counters this vulnerability. V2. An attacker can attempt to masquerade as a credential server in an attempt to get a client to reveal information online that allows for a later dictionary attack. - The use of server or mutual authentication counters this vulnerability. V3. An attacker can attempt to get a client to decrypt a chosen "ciphertext" and get the client to make use of the resulting plaintext - the attacker may then be able to carry out a dictionary attack (e.g. if the plaintext resulting from "decryption" of a random string is used as a DSA private key). - The use of server or mutual authentication counters this vulnerability. V4. An attacker could overwrite a repository entry so that when a user subsequently uses what they think is a good credential, they expose information about their password (and hence the "real" credential). - Server implementations SHOULD take measures to protect the database. Clients MAY use the ClientInfo field to store e.g. a signature over the Credential, which they then verify before using the private component. V5. An attacker can copy a credential server's repository and carry out a dictionary attack. - Server implementations SHOULD take measures to protect the database. V6. An attacker can attempt to masquerade as a client in an attempt to get a server to reveal information that allows for a later dictionary attack. - The mutual authentication requirements of this protocol counter this to a great extent. Additionally, credential servers MAY choose to provide mechanisms that protect against online dictionary attacks against user account passwords, either by repeated access attempts to a single user account (varying the password) or by attempting to access many user accounts using the same password. V7. An attacker can persuade a server that a successful login has occurred, even if it hasn't. - Client authentication prevents this.
Farrell Standards Track [Page 13] RFC 3767 Secure Credentials Protocol June 2004
Farrell Standards Track [Page 13] RFC 3767 Secure Credentials Protocol June 2004
V8. (Upload) An attacker can overwrite someone else's
credentials on the server.
- Only if they know the account password already (thanks to
mutual authentication).
V9. (When using password-based authentication) An attacker can
force a password change to a known (or "weak") password.
- Client authentication counters this.
V10. An attacker can attempt a man-in-the-middle attack for lots
of reasons...
- Mutual authentication and the encryption of subsequent
messages prevents this.
V11. User enters password instead of name.
- Since the DIGEST-MD5 mechanism is only used after TLS
tuning, the user's name is also protected.
V12. An attacker could attempt various denial-of-service attacks.
- No specific countermeasures against DoS are proposed.
V8. (Upload) An attacker can overwrite someone else's credentials on the server. - Only if they know the account password already (thanks to mutual authentication). V9. (When using password-based authentication) An attacker can force a password change to a known (or "weak") password. - Client authentication counters this. V10. An attacker can attempt a man-in-the-middle attack for lots of reasons... - Mutual authentication and the encryption of subsequent messages prevents this. V11. User enters password instead of name. - Since the DIGEST-MD5 mechanism is only used after TLS tuning, the user's name is also protected. V12. An attacker could attempt various denial-of-service attacks. - No specific countermeasures against DoS are proposed.
If the CreateAccountRequest message were sent over a cleartext channel (or otherwise exposed), then an attacker could mount a dictionary attack and recover the account password. This is why the server authenticated TLS transport is REQUIRED for this operation.
If the CreateAccountRequest message were sent over a cleartext channel (or otherwise exposed), then an attacker could mount a dictionary attack and recover the account password. This is why the server authenticated TLS transport is REQUIRED for this operation.
If someone steals the server database they can launch a dictionary attack. If the dictionary attack is successful, the attacker can decrypt the user's credentials. An attacker that has learned the user's account password can also upload new credentials, assuming the user is authorized to modify the credentials, because someone who knows the user's account password is assumed to be the user. However, if someone steals the server database and is unsuccessful at obtaining the user's account password through a dictionary attack, they will be unable to upload new credentials.
If someone steals the server database they can launch a dictionary attack. If the dictionary attack is successful, the attacker can decrypt the user's credentials. An attacker that has learned the user's account password can also upload new credentials, assuming the user is authorized to modify the credentials, because someone who knows the user's account password is assumed to be the user. However, if someone steals the server database and is unsuccessful at obtaining the user's account password through a dictionary attack, they will be unable to upload new credentials.
Credential servers SHOULD incorporate measures that act to counter denial of service attacks. In particular, they SHOULD drop inactive connections and minimize the use of resources by un-authenticated connections. A number of recommendations are listed at [DDOS].
Credential servers SHOULD incorporate measures that act to counter denial of service attacks. In particular, they SHOULD drop inactive connections and minimize the use of resources by un-authenticated connections. A number of recommendations are listed at [DDOS].
Various operations in the SACRED protocol depend upon server authentication being provided by server authenticated TLS. SACRED clients SHOULD take care that the correct server is at the far end of the TLS "pipe" by performing the checks which are listed in section 3.1 of RFC 2818 [RFC2818]. Clients SHOULD also include the optional BEEP serverName field in their "start" message and SHOULD then ensure that the BEEP serverName is consistent with the checks on the TLS server described in RFC 2818. Failure to carry out these checks could allow a spoof server access to a user's credential.
Various operations in the SACRED protocol depend upon server authentication being provided by server authenticated TLS. SACRED clients SHOULD take care that the correct server is at the far end of the TLS "pipe" by performing the checks which are listed in section 3.1 of RFC 2818 [RFC2818]. Clients SHOULD also include the optional BEEP serverName field in their "start" message and SHOULD then ensure that the BEEP serverName is consistent with the checks on the TLS server described in RFC 2818. Failure to carry out these checks could allow a spoof server access to a user's credential.
Farrell Standards Track [Page 14] RFC 3767 Secure Credentials Protocol June 2004
Farrell Standards Track [Page 14] RFC 3767 Secure Credentials Protocol June 2004
If the SACRED account password were to be used in some other, less secure protocol, using DIGEST-MD5, then it might appear to be the case that a man-in-the-middle (MITM) attack could be mounted. However, this is not the case since the DIGEST-MD5 client hash includes a client-selected "digest-uri-value", which in SACRED's case will be "sacred/<serverName>". In a MITM attack, those values will be something else. A MITM attack as described is therefore thwarted, because digest-uri-value wouldn't match what the SACRED server is expecting.
If the SACRED account password were to be used in some other, less secure protocol, using DIGEST-MD5, then it might appear to be the case that a man-in-the-middle (MITM) attack could be mounted. However, this is not the case since the DIGEST-MD5 client hash includes a client-selected "digest-uri-value", which in SACRED's case will be "sacred/<serverName>". In a MITM attack, those values will be something else. A MITM attack as described is therefore thwarted, because digest-uri-value wouldn't match what the SACRED server is expecting.
6. References
6. References
6.1. Normative References
6.1. Normative References
[BEEP] Rose, M., "The Blocks Extensible Exchange Protocol
Core", RFC 3080, March 2001.
[BEEP] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[DIGEST-MD5] Leach, P. and C. Newman, "Using Digest Authentication as
a SASL Mechanism", RFC 2831, May 2000.
[DIGEST-MD5] Leach, P. and C. Newman, "Using Digest Authentication as a SASL Mechanism", RFC 2831, May 2000.
[PKCS15] "PKCS #15 v1.1: Cryptographic Token Information Syntax
Standard," RSA Laboratories, June 2000.
[PKCS15] "PKCS #15 v1.1: Cryptographic Token Information Syntax Standard," RSA Laboratories, June 2000.
[REQS] Arsenault, A. and S. Farrell, "Securely Available
Credentials - Requirements", RFC 3157, August 2001.
[REQS] Arsenault, A. and S. Farrell, "Securely Available Credentials - Requirements", RFC 3157, August 2001.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[SASL] Myers, J., "Simple Authentication and Security Layer
(SASL)", RFC 2222, October 1997.
[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[TLS] Dierks, T. and C. Allen, "The TLS Protocol - Version
1.0", RFC 2246, January 1999.
[TLS] Dierks, T. and C. Allen, "The TLS Protocol - Version 1.0", RFC 2246, January 1999.
[TLSAES] Chown, P., "Advanced Encryption Standard (AES)
Ciphersuites for Transport Layer Security (TLS)", RFC
3268, June 2002.
[TLSAES] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002.
[XMLDSIG] Eastlake, 3rd, D., Reagle, J. and D. Solo, "(Extensible
Mark-Up Language) XML-Signature Syntax and Processing",
RFC 3275, March 2002.
[XMLDSIG] Eastlake, 3rd, D., Reagle, J. and D. Solo, "(Extensible Mark-Up Language) XML-Signature Syntax and Processing", RFC 3275, March 2002.
[XMLSCHEMA] "XML Schema Part 1: Structures", D. Beech, M. Maloney,
N. Mendelsohn, and H. Thompson. W3C Recommendation, May
2001. Available at http://www.w3.org/TR/2001/REC-
xmlschema-2-20010502/
[XMLSCHEMA] "XML Schema Part 1: Structures", D. Beech, M. Maloney, N. Mendelsohn, and H. Thompson. W3C Recommendation, May 2001. Available at http://www.w3.org/TR/2001/REC- xmlschema-2-20010502/
Farrell Standards Track [Page 15] RFC 3767 Secure Credentials Protocol June 2004
Farrell Standards Track [Page 15] RFC 3767 Secure Credentials Protocol June 2004
6.2. Informative References
6.2. Informative References
[DDOS] "Recommendations for the Protection against Distributed
Denial-of-Service Attacks in the Internet",
http://www.iwar.org.uk/comsec/resources/dos/ddos_en.htm
[DDOS] "Recommendations for the Protection against Distributed Denial-of-Service Attacks in the Internet", http://www.iwar.org.uk/comsec/resources/dos/ddos_en.htm
[RFC2818] Rescorla, E., "HTTP over TLS", RFC 2818, May 2000.
[RFC2818] Rescorla, E., "HTTP over TLS", RFC 2818, May 2000.
[RFC3760] Gustafson, D., Just, M. and M. Nystrom, "Securely
Available Credentials - Credential Server Framework,"
RFC 3760, April 2004.
[RFC3760] Gustafson, D., Just, M. and M. Nystrom, "Securely Available Credentials - Credential Server Framework," RFC 3760, April 2004.
[XKMS] Hallam-Baker, P. (ed), "XML Key Management
Specification", http://www.w3.org/TR/xkms2/
[XKMS] Hallam-Baker, P. (ed), "XML Key Management Specification", http://www.w3.org/TR/xkms2/
[XBULK] Hughes, M (ed), "XML Key Management Specification - Bulk
Operation", http://www.w3.org/TR/xkms2-xbulk/
[XBULK] Hughes, M (ed), "XML Key Management Specification - Bulk Operation", http://www.w3.org/TR/xkms2-xbulk/
Acknowledgements
Acknowledgements
Radia Perlman (radia.perlman@sun.com) and Charlie Kaufman (charliek@microsoft.com) co-authored earlier versions of this document. Michael Zolotarev (mzolotar@tpg.com.au) did much of the initial work, adapting an earlier version to the use of SRP (though SRP was subsequently dropped, much of the framework survives). Marshall Rose (mrose@dbc.mtview.ca.us) helped out a lot, in particular, with the BEEP profile. And the following people were actively involved in the mailing list discussions leading to this document:
Radia Perlman (radia.perlman@sun.com) and Charlie Kaufman (charliek@microsoft.com) co-authored earlier versions of this document. Michael Zolotarev (mzolotar@tpg.com.au) did much of the initial work, adapting an earlier version to the use of SRP (though SRP was subsequently dropped, much of the framework survives). Marshall Rose (mrose@dbc.mtview.ca.us) helped out a lot, in particular, with the BEEP profile. And the following people were actively involved in the mailing list discussions leading to this document:
David Chizmadia,
Dave Crocker (dcrocker@brandenburg.com),
Lawrence Greenfield (leg+@andrew.cmu.edu),
Dale Gustafson (degustafson@comcast.net),
Mike Just (just.mike@tbs-sct.gc.ca),
John Linn (jlinn@rsasecurity.com),
Neal McBurnett (neal@bcn.boulder.co.us),
Keith Moore (moore@cs.utk.edu),
RL "Bob" Morgan (rlmorgan@washington.edu),
Magnus Nystrom (magnus@rsasecurity.com),
Eamon O'Tuathail (eamon.otuathail@clipcode.com),
Gareth Richards (grichards@rsasecurity.com)
David Chizmadia, Dave Crocker (dcrocker@brandenburg.com), Lawrence Greenfield (leg+@andrew.cmu.edu), Dale Gustafson (degustafson@comcast.net), Mike Just (just.mike@tbs-sct.gc.ca), John Linn (jlinn@rsasecurity.com), Neal McBurnett (neal@bcn.boulder.co.us), Keith Moore (moore@cs.utk.edu), RL "Bob" Morgan (rlmorgan@washington.edu), Magnus Nystrom (magnus@rsasecurity.com), Eamon O'Tuathail (eamon.otuathail@clipcode.com), Gareth Richards (grichards@rsasecurity.com)
Of course, any and all errors remain the editor's responsibility.
Of course, any and all errors remain the editor's responsibility.
Farrell Standards Track [Page 16] RFC 3767 Secure Credentials Protocol June 2004
Farrell Standards Track [Page 16] RFC 3767 Secure Credentials Protocol June 2004
Appendix A: XML Schema
Appendix A: XML Schema
<?xml version="1.0" encoding="UTF-8"?>
<schema
targetNamespace="urn:sacred-2002-12-19"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:sacred="urn:sacred-2002-12-19"
xmlns="http://www.w3.org/2001/XMLSchema">
<import namespace="http://www.w3.org/2000/09/xmldsig#"
schemaLocation=
"http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd"/>
<!-- extensibility holes -->
<complexType name="ProcessInfoType">
<sequence maxOccurs="unbounded">
<any namespace="##other"/>
</sequence>
</complexType>
<element name="ProcessInfo" type="sacred:ProcessInfoType"/>
<complexType name="ClientInfoType">
<sequence maxOccurs="unbounded">
<any namespace="##other"/>
</sequence>
</complexType>
<element name="ClientInfo" type="sacred:ClientInfoType"/>
<!-- Where to put authenentication information -->
<complexType name="AuthInfoType">
<choice maxOccurs="unbounded">
<element name="DigestMD5AuthInfo">
<complexType>
<sequence>
<element name="PasswordVerifier" type="base64Binary"/>
<element name="Realm" type="string" />
</sequence>
</complexType>
</element>
<any namespace="##other"/>
</choice>
</complexType>
<element name="AuthInfo" type="sacred:AuthInfoType"/>
<!-- authentication mechanism parameters -->
<complexType name="AuthParamsType">
<choice maxOccurs="unbounded">
<element name=" DigestMD5AuthParams">
<complexType>
<sequence>
<element name="Realm" type="string"
minOccurs="1" maxOccurs="unbounded"/>
</sequence>
<?xml version="1.0" encoding="UTF-8"?> <schema targetNamespace="urn:sacred-2002-12-19" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:sacred="urn:sacred-2002-12-19" xmlns="http://www.w3.org/2001/XMLSchema"> <import namespace="http://www.w3.org/2000/09/xmldsig#" schemaLocation= "http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd"/> <!-- extensibility holes --> <complexType name="ProcessInfoType"> <sequence maxOccurs="unbounded"> <any namespace="##other"/> </sequence> </complexType> <element name="ProcessInfo" type="sacred:ProcessInfoType"/> <complexType name="ClientInfoType"> <sequence maxOccurs="unbounded"> <any namespace="##other"/> </sequence> </complexType> <element name="ClientInfo" type="sacred:ClientInfoType"/> <!-- Where to put authenentication information --> <complexType name="AuthInfoType"> <choice maxOccurs="unbounded"> <element name="DigestMD5AuthInfo"> <complexType> <sequence> <element name="PasswordVerifier" type="base64Binary"/> <element name="Realm" type="string" /> </sequence> </complexType> </element> <any namespace="##other"/> </choice> </complexType> <element name="AuthInfo" type="sacred:AuthInfoType"/> <!-- authentication mechanism parameters --> <complexType name="AuthParamsType"> <choice maxOccurs="unbounded"> <element name=" DigestMD5AuthParams"> <complexType> <sequence> <element name="Realm" type="string" minOccurs="1" maxOccurs="unbounded"/> </sequence>
Farrell Standards Track [Page 17] RFC 3767 Secure Credentials Protocol June 2004
Farrell Standards Track [Page 17] RFC 3767 Secure Credentials Protocol June 2004
</complexType>
</element>
<any namespace="##other"/>
</choice>
</complexType>
<element name="AuthParams" type="sacred:AuthParamsType"/>
<!-- Protocol messsages -->
<!-- "account handling" operations -->
<!-- Information request -->
<element name="InfoRequest"/>
<element name="InfoResponse">
<complexType>
<sequence>
<element name="Status" type="string" minOccurs="0"/>
<element name="ServerId" type="string"/>
<element ref="sacred:AuthParams"/>
<element ref="sacred:ProcessInfo" minOccurs="0"/>
</sequence>
</complexType>
</element>
<!-- Create Account Request -->
<element name="CreateAccountRequest">
<complexType>
<sequence>
<element name="UserId" type="string"/>
<element ref="sacred:AuthInfo"/>
<element ref="sacred:ProcessInfo" minOccurs="0"/>
</sequence>
</complexType>
</element>
<!-- remove account request -->
<element name="RemoveAccountRequest">
<complexType>
<sequence>
<element ref="sacred:ProcessInfo" minOccurs="0"/>
</sequence>
</complexType>
</element>
<!-- password change request -->
<element name="ModifyAccountRequest">
<complexType>
<sequence>
<element ref="sacred:AuthInfo"/>
<element ref="sacred:ProcessInfo" minOccurs="0"/>
</sequence>
</complexType>
</element>
<!-- "run-time" operations -->
</complexType> </element> <any namespace="##other"/> </choice> </complexType> <element name="AuthParams" type="sacred:AuthParamsType"/> <!-- Protocol messsages --> <!-- "account handling" operations --> <!-- Information request --> <element name="InfoRequest"/> <element name="InfoResponse"> <complexType> <sequence> <element name="Status" type="string" minOccurs="0"/> <element name="ServerId" type="string"/> <element ref="sacred:AuthParams"/> <element ref="sacred:ProcessInfo" minOccurs="0"/> </sequence> </complexType> </element> <!-- Create Account Request --> <element name="CreateAccountRequest"> <complexType> <sequence> <element name="UserId" type="string"/> <element ref="sacred:AuthInfo"/> <element ref="sacred:ProcessInfo" minOccurs="0"/> </sequence> </complexType> </element> <!-- remove account request --> <element name="RemoveAccountRequest"> <complexType> <sequence> <element ref="sacred:ProcessInfo" minOccurs="0"/> </sequence> </complexType> </element> <!-- password change request --> <element name="ModifyAccountRequest"> <complexType> <sequence> <element ref="sacred:AuthInfo"/> <element ref="sacred:ProcessInfo" minOccurs="0"/> </sequence> </complexType> </element> <!-- "run-time" operations -->
Farrell Standards Track [Page 18] RFC 3767 Secure Credentials Protocol June 2004
Farrell Standards Track [Page 18] RFC 3767 Secure Credentials Protocol June 2004
<!-- DownLoad Request -->
<element name="DownloadRequest">
<complexType>
<sequence>
<element name="CredentialSelector" type="string"
minOccurs="0"/>
<element ref="sacred:ProcessInfo" minOccurs="0"/>
</sequence>
</complexType>
</element>
<!-- Download Response -->
<element name="DownloadResponse">
<complexType>
<sequence>
<element name="Status" type="string" minOccurs="0"/>
<element name="Credential" type="sacred:CredentialType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<!-- Upload request -->
<element name="UploadRequest">
<complexType>
<sequence>
<element name="Credential" type="sacred:CredentialType"/>
</sequence>
</complexType>
</element>
<element name="DeleteRequest">
<complexType>
<sequence>
<choice>
<sequence>
<element name="CredentialSelector" type="string"/>
<element name="LastModified" type="dateTime"
minOccurs="0"/>
</sequence>
<element name="All"/>
</choice>
<element ref="sacred:ProcessInfo" minOccurs="0"/>
</sequence>
</complexType>
</element>
<!-- Credential related structures -->
<!-- A new ds:KeyInfo thing -->
<element name="SacredPKCS15" type="base64Binary"/>
<!-- credential -->
<complexType name="CredentialType">
<!-- DownLoad Request --> <element name="DownloadRequest"> <complexType> <sequence> <element name="CredentialSelector" type="string" minOccurs="0"/> <element ref="sacred:ProcessInfo" minOccurs="0"/> </sequence> </complexType> </element> <!-- Download Response --> <element name="DownloadResponse"> <complexType> <sequence> <element name="Status" type="string" minOccurs="0"/> <element name="Credential" type="sacred:CredentialType" maxOccurs="unbounded"/> </sequence> </complexType> </element> <!-- Upload request --> <element name="UploadRequest"> <complexType> <sequence> <element name="Credential" type="sacred:CredentialType"/> </sequence> </complexType> </element> <element name="DeleteRequest"> <complexType> <sequence> <choice> <sequence> <element name="CredentialSelector" type="string"/> <element name="LastModified" type="dateTime" minOccurs="0"/> </sequence> <element name="All"/> </choice> <element ref="sacred:ProcessInfo" minOccurs="0"/> </sequence> </complexType> </element> <!-- Credential related structures --> <!-- A new ds:KeyInfo thing --> <element name="SacredPKCS15" type="base64Binary"/> <!-- credential --> <complexType name="CredentialType">
Farrell Standards Track [Page 19] RFC 3767 Secure Credentials Protocol June 2004
Farrell Standards Track [Page 19] RFC 3767 Secure Credentials Protocol June 2004
<sequence>
<element name="CredentialSelector" type="string"/>
<element name="LastModified" type="dateTime"/>
<element name="Payload" type="ds:KeyInfoType" minOccurs="0"/>
<element name="TimeToLive" type="string" minOccurs="0"/>
<element ref="sacred:ProcessInfo" minOccurs="0"/>
<element ref="sacred:ClientInfo" minOccurs="0"/>
</sequence>
</complexType>
<sequence> <element name="CredentialSelector" type="string"/> <element name="LastModified" type="dateTime"/> <element name="Payload" type="ds:KeyInfoType" minOccurs="0"/> <element name="TimeToLive" type="string" minOccurs="0"/> <element ref="sacred:ProcessInfo" minOccurs="0"/> <element ref="sacred:ClientInfo" minOccurs="0"/> </sequence> </complexType>
</schema>
</schema>
Appendix B: An Example of Tuning with BEEP
Appendix B: An Example of Tuning with BEEP
Here is what tuning BEEP for authentication and confidentiality looks like using TLS and SASL's DIGEST-MD5:
Here is what tuning BEEP for authentication and confidentiality looks like using TLS and SASL's DIGEST-MD5:
L: <wait for incoming connection> I: <open connection>
L: <wait for incoming connection> I: <open connection>
... each peer sends a greeting indicating the services that
it offers ...
... each peer sends a greeting indicating the services that it offers ...
L: RPY 0 0 . 0 233 L: Content-Type: application/beep+xml L: L: <greeting> L: <profile uri='http://iana.org/beep/SASL/DIGEST-MD5' /> L: <profile uri='http://iana.org/beep/TLS' /> L: <profile uri='http://iana.org/beep/sacred' /> L: </greeting> L: END I: RPY 0 0 . 0 52 I: Content-Type: application/beep+xml I: I: <greeting /> I: END
L: RPY 0 0 . 0 233 L: Content-Type: application/beep+xml L: L: <greeting> L: <profile uri='http://iana.org/beep/SASL/DIGEST-MD5' /> L: <profile uri='http://iana.org/beep/TLS' /> L: <profile uri='http://iana.org/beep/sacred' /> L: </greeting> L: END I: RPY 0 0 . 0 52 I: Content-Type: application/beep+xml I: I: <greeting /> I: END
... the initiator starts a channel for TLS and piggybacks a request
to start the TLS negotiation ...
... the initiator starts a channel for TLS and piggybacks a request to start the TLS negotiation ...
I: MSG 0 1 . 52 149 I: Content-Type: application/beep+xml I: I: <start number='1' serverName="sacred.example.org"> I: <profile uri='http://iana.org/beep/TLS'> I: <ready />
I: MSG 0 1 . 52 149 I: Content-Type: application/beep+xml I: I: <start number='1' serverName="sacred.example.org"> I: <profile uri='http://iana.org/beep/TLS'> I: <ready />
Farrell Standards Track [Page 20] RFC 3767 Secure Credentials Protocol June 2004
Farrell Standards Track [Page 20] RFC 3767 Secure Credentials Protocol June 2004
I: </profile> I: </start> I: END
I: </profile> I: </start> I: END
... the listener creates the channel and piggybacks its readiness to
start TLS ...
... the listener creates the channel and piggybacks its readiness to start TLS ...
L: RPY 0 1 . 233 112 L: Content-Type: application/beep+xml L: L: <profile uri='http://iana.org/beep/TLS'> L: <proceed /> L: </profile> L: END
L: RPY 0 1 . 233 112 L: Content-Type: application/beep+xml L: L: <profile uri='http://iana.org/beep/TLS'> L: <proceed /> L: </profile> L: END
... upon receiving the reply, the initiator starts up TLS ...
... upon receiving the reply, the initiator starts up TLS ...
... successful transport security negotiation ...
... successful transport security negotiation ...
... a new greeting is sent (cf., Section 9 of RFC 3080), note that
the listener no longer advertises TLS (we're already running
it)
... a new greeting is sent (cf., Section 9 of RFC 3080), note that the listener no longer advertises TLS (we're already running it)
L: RPY 0 0 . 0 186 L: Content-Type: application/beep+xml L: L: <greeting> L: <profile uri='http://iana.org/beep/SASL/DIGEST-MD5' /> L: <profile uri='http://iana.org/beep/sacred' /> L: </greeting> L: END I: RPY 0 0 . 0 52 I: Content-Type: application/beep+xml I: I: <greeting /> I: END
L: RPY 0 0 . 0 186 L: Content-Type: application/beep+xml L: L: <greeting> L: <profile uri='http://iana.org/beep/SASL/DIGEST-MD5' /> L: <profile uri='http://iana.org/beep/sacred' /> L: </greeting> L: END I: RPY 0 0 . 0 52 I: Content-Type: application/beep+xml I: I: <greeting /> I: END
... the initiator starts a channel for DIGEST-MD5 and piggybacks
initialization information for the mechanism ...
... the initiator starts a channel for DIGEST-MD5 and piggybacks initialization information for the mechanism ...
I: MSG 0 1 . 52 178 I: Content-Type: application/beep+xml I: I: <start number='1'> I: <profile uri='http://iana.org/beep/SASL/DIGEST-MD5'> I: <blob> ... </blob> I: </profile>
I: MSG 0 1 . 52 178 I: Content-Type: application/beep+xml I: I: <start number='1'> I: <profile uri='http://iana.org/beep/SASL/DIGEST-MD5'> I: <blob> ... </blob> I: </profile>
Farrell Standards Track [Page 21] RFC 3767 Secure Credentials Protocol June 2004
Farrell Standards Track [Page 21] RFC 3767 Secure Credentials Protocol June 2004
I: </start> I: END
I: </start> I: END
... the listener creates the channel and piggybacks a challenge ...
... the listener creates the channel and piggybacks a challenge ...
L: RPY 0 1 . 186 137 L: Content-Type: application/beep+xml L: L: <profile uri='http://iana.org/beep/SASL/DIGEST-MD5'> L: <blob> ... </blob> L: </profile> L: END
L: RPY 0 1 . 186 137 L: Content-Type: application/beep+xml L: L: <profile uri='http://iana.org/beep/SASL/DIGEST-MD5'> L: <blob> ... </blob> L: </profile> L: END
... the initiator sends a response to the challenge ...
... the initiator sends a response to the challenge ...
I: MSG 1 0 . 0 58 I: Content-Type: application/beep+xml I: I: <blob> ... </blob> I: END
I: MSG 1 0 . 0 58 I: Content-Type: application/beep+xml I: I: <blob> ... </blob> I: END
... the listener accepts the challenge and tells the initiator
that it is now authenticated ...
... the listener accepts the challenge and tells the initiator that it is now authenticated ...
L: RPY 1 0 . 0 66 L: Content-Type: application/beep+xml L: L: <blob status='complete' /> L: END
L: RPY 1 0 . 0 66 L: Content-Type: application/beep+xml L: L: <blob status='complete' /> L: END
... the initiator starts a channel for SACRED and piggybacks its
initial SACRED request ...
... the initiator starts a channel for SACRED and piggybacks its initial SACRED request ...
I: MSG 0 2 . 230 520 I: Content-Type: application/beep+xml I: I: <start number='3'> I: <profile uri='http://iana.org/beep/sacred' /> I: <?xml version="1.0" encoding="UTF-8"?> I: <sacred:DownloadRequest I: xmlns:sacred="urn:sacred-2002-12-19" I: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" I: xsi:schemaLocation="urn:sacred-2002-12-19 sacred.xsd"> I: <CredentialSelector> I: magnus-credentials</CredentialSelector> I: </sacred:DownloadRequest> I: </start>
I: MSG 0 2 . 230 520 I: Content-Type: application/beep+xml I: I: <start number='3'> I: <profile uri='http://iana.org/beep/sacred' /> I: <?xml version="1.0" encoding="UTF-8"?> I: <sacred:DownloadRequest I: xmlns:sacred="urn:sacred-2002-12-19" I: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" I: xsi:schemaLocation="urn:sacred-2002-12-19 sacred.xsd"> I: <CredentialSelector> I: magnus-credentials</CredentialSelector> I: </sacred:DownloadRequest> I: </start>
Farrell Standards Track [Page 22] RFC 3767 Secure Credentials Protocol June 2004
Farrell Standards Track [Page 22] RFC 3767 Secure Credentials Protocol June 2004
I: END
I: END
... the listener creates the channel and piggybacks the response to
the initial SACRED request
... the listener creates the channel and piggybacks the response to the initial SACRED request
L: RPY 0 2 . 323 805 L: Content-Type: application/beep+xml L: L: <profile uri='http://iana.org/beep/sacred' /> L: <?xml version="1.0" encoding="UTF-8"?> L: <sacred:DownloadResponse L: xmlns:sacred="urn:sacred-2002-12-19" L: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" L: xsi:schemaLocation="urn:sacred-2002-12-19 sacred.xsd"> L: <Status>Success</Status> L: <Credential> L: <CredentialSelector> L: magnus-credential</CredentialSelector> L: <LastModified>2002-11-22T00:00:08Z</LastModified> L: <Payload> L: <sacred:SacredPKCS15 L: xmlns:sacred="urn:sacred-2002-12-19">GpM7 L: </sacred:SacredPKCS15> L: </Payload> L: </Credential> L: </sacred:DownloadResponse> L: </profile> L: END
L: RPY 0 2 . 323 805 L: Content-Type: application/beep+xml L: L: <profile uri='http://iana.org/beep/sacred' /> L: <?xml version="1.0" encoding="UTF-8"?> L: <sacred:DownloadResponse L: xmlns:sacred="urn:sacred-2002-12-19" L: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" L: xsi:schemaLocation="urn:sacred-2002-12-19 sacred.xsd"> L: <Status>Success</Status> L: <Credential> L: <CredentialSelector> L: magnus-credential</CredentialSelector> L: <LastModified>2002-11-22T00:00:08Z</LastModified> L: <Payload> L: <sacred:SacredPKCS15 L: xmlns:sacred="urn:sacred-2002-12-19">GpM7 L: </sacred:SacredPKCS15> L: </Payload> L: </Credential> L: </sacred:DownloadResponse> L: </profile> L: END
Appendix C: Provision SACRED using other Protocols
Appendix C: Provision SACRED using other Protocols
SACRED may be implemented in a non-BEEP environment, provided that before any SACRED PDUs are sent, the application protocol must be protected according to the security mandates provided in Section 2.3.
SACRED may be implemented in a non-BEEP environment, provided that before any SACRED PDUs are sent, the application protocol must be protected according to the security mandates provided in Section 2.3.
For example, if SACRED is provisioned as the payload of an application protocol that supports SASL and TLS, then the appropriate SASL and/or TLS negotiation must successfully occur before exchanging Sacred PDUs.
For example, if SACRED is provisioned as the payload of an application protocol that supports SASL and TLS, then the appropriate SASL and/or TLS negotiation must successfully occur before exchanging Sacred PDUs.
Alternatively, if the application protocol doesn't support SASL, then one or more PDUs are defined to facilitate a SASL negotiation, and the appropriate negotiation must occur before exchanging Sacred PDUs.
Alternatively, if the application protocol doesn't support SASL, then one or more PDUs are defined to facilitate a SASL negotiation, and the appropriate negotiation must occur before exchanging Sacred PDUs.
Farrell Standards Track [Page 23] RFC 3767 Secure Credentials Protocol June 2004
ファレル標準化過程[23ページ]RFC3767はプロトコル2004年6月に信任状を保証します。
Editor's Address
エディタのアドレス
Stephen Farrell, Distributed Systems Group, Computer Science Department, Trinity College Dublin, IRELAND Phone: +353-1-608-3070 EMail: stephen.farrell@cs.tcd.ie
スティーブン・ファレル、分散システムグループ、コンピュータ理学部、トリニティー・カレッジダブリン、アイルランドは以下に電話をします。 +353-1-608-3070 メールしてください: stephen.farrell@cs.tcd.ie
Farrell Standards Track [Page 24] RFC 3767 Secure Credentials Protocol June 2004
ファレル標準化過程[24ページ]RFC3767はプロトコル2004年6月に信任状を保証します。
Full Copyright Statement
完全な著作権宣言文
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機能のための基金は現在、インターネット協会によって提供されます。
Farrell Standards Track [Page 25]
ファレル標準化過程[25ページ]
一覧
スポンサーリンク
