RFC4422 日本語訳
4422 Simple Authentication and Security Layer (SASL). A. Melnikov,Ed., K. Zeilenga, Ed.. June 2006. (Format: TXT=73206 bytes) (Obsoletes RFC2222) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Melnikov, Ed.
Request for Comments: 4422 Isode Limited
Obsoletes: 2222 K. Zeilenga, Ed.
Category: Standards Track OpenLDAP Foundation
June 2006
ワーキンググループのA.メリニコフ、エドをネットワークでつないでください。コメントのために以下を要求してください。 4422Isode株式会社は以下を時代遅れにします。 エド2222K.Zeilenga、カテゴリ: 標準化過程OpenLDAP財団2006年6月
Simple Authentication and Security Layer (SASL)
簡易認証とセキュリティは層にされます。(SASL)
Status of This 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 (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-oriented protocols via replaceable mechanisms. It provides a structured interface between protocols and mechanisms. The resulting framework allows new protocols to reuse existing mechanisms and allows old protocols to make use of new mechanisms. The framework also provides a protocol for securing subsequent protocol exchanges within a data security layer.
Simple AuthenticationとSecurity Layer(SASL)は、取替え可能なメカニズムで認証とデータ機密保護サービスを接続指向のプロトコルに提供するためのフレームワークです。それはプロトコルとメカニズムとの構造化されたインタフェースを前提とします。結果として起こるフレームワークは、新しいプロトコルが既存のメカニズムを再利用するのを許容して、古いプロトコルが新しいメカニズムを利用するのを許容します。また、フレームワークはデータ機密保護層の中でその後のプロトコル交換を保証するのにプロトコルを前提とします。
This document describes how a SASL mechanism is structured, describes how protocols include support for SASL, and defines the protocol for carrying a data security layer over a connection. In addition, this document defines one SASL mechanism, the EXTERNAL mechanism.
このドキュメントは、SASLメカニズムがどう構造化されるかを説明して、プロトコルがどうSASLのサポートを含むかを説明して、接続の上までデータ機密保護層を運ぶためにプロトコルを定義します。 さらに、このドキュメントは1つのSASLメカニズム、EXTERNALメカニズムを定義します。
This document obsoletes RFC 2222.
このドキュメントはRFC2222を時代遅れにします。
Melnikov & Zeilenga Standards Track [Page 1] RFC 4422 SASL June 2006
メリニコフとZeilenga規格はSASL2006年6月にRFC4422を追跡します[1ページ]。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Document Audiences .........................................4
1.2. Relationship to Other Documents ............................4
1.3. Conventions ................................................5
2. Identity Concepts ...............................................5
3. The Authentication Exchange .....................................6
3.1. Mechanism Naming ...........................................8
3.2. Mechanism Negotiation ......................................9
3.3. Request Authentication Exchange ............................9
3.4. Challenges and Responses ...................................9
3.4.1. Authorization Identity String ......................10
3.5. Aborting Authentication Exchanges .........................10
3.6. Authentication Outcome ....................................11
3.7. Security Layers ...........................................12
3.8. Multiple Authentications ..................................12
4. Protocol Requirements ..........................................13
5. Mechanism Requirements .........................................16
6. Security Considerations ........................................18
6.1. Active Attacks ............................................19
6.1.1. Hijack Attacks .....................................19
6.1.2. Downgrade Attacks ..................................19
6.1.3. Replay Attacks .....................................20
6.1.4. Truncation Attacks .................................20
6.1.5. Other Active Attacks ...............................20
6.2. Passive Attacks ...........................................20
6.3. Re-keying .................................................21
6.4. Other Considerations ......................................21
7. IANA Considerations ............................................22
7.1. SASL Mechanism Registry ...................................22
7.2. Registration Changes ......................................26
8. References .....................................................26
8.1. Normative References ......................................26
8.2. Informative References ....................................27
9. Acknowledgements ...............................................28
Appendix A. The SASL EXTERNAL Mechanism ..........................29
A.1. EXTERNAL Technical Specification ..........................29
A.2. SASL EXTERNAL Examples ....................................30
A.3. Security Considerations ...................................31
Appendix B. Changes since RFC 2222 ...............................31
1. 序論…3 1.1. 聴衆を記録してください…4 1.2. 他のドキュメントとの関係…4 1.3. コンベンション…5 2. アイデンティティ概念…5 3. 認証交換…6 3.1. メカニズム命名…8 3.2. メカニズム交渉…9 3.3. 認証交換を要求してください…9 3.4. 挑戦と応答…9 3.4.1. 承認アイデンティティストリング…10 3.5. 認証交換を中止します…10 3.6. 認証結果…11 3.7. セキュリティは層にされます…12 3.8. 複数の認証…12 4. 要件について議定書の中で述べてください…13 5. メカニズム要件…16 6. セキュリティ問題…18 6.1. 活発な攻撃…19 6.1.1. 攻撃をハイジャックしてください…19 6.1.2. 攻撃を格下げしてください…19 6.1.3. 反射攻撃…20 6.1.4. トランケーションは攻撃されます…20 6.1.5. 他の活発な攻撃…20 6.2. 受動態は攻撃されます…20 6.3. 再合わせます。21 6.4. 他の問題…21 7. IANA問題…22 7.1. SASLメカニズム登録…22 7.2. 登録は変化します…26 8. 参照…26 8.1. 標準の参照…26 8.2. 有益な参照…27 9. 承認…28付録、A. SASLの外部のメカニズム…29 A.1。 外部の技術的な仕様…29 A.2。 SASLの外部の例…30 A.3。 セキュリティ問題…31 RFC2222以来付録B.は変化します…31
Melnikov & Zeilenga Standards Track [Page 2] RFC 4422 SASL June 2006
メリニコフとZeilenga規格はSASL2006年6月にRFC4422を追跡します[2ページ]。
1. Introduction
1. 序論
The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-oriented protocols via replaceable mechanisms. SASL provides a structured interface between protocols and mechanisms. SASL also provides a protocol for securing subsequent protocol exchanges within a data security layer. The data security layer can provide data integrity, data confidentiality, and other services.
Simple AuthenticationとSecurity Layer(SASL)は、取替え可能なメカニズムで認証とデータ機密保護サービスを接続指向のプロトコルに提供するためのフレームワークです。SASLはプロトコルとメカニズムとの構造化されたインタフェースを提供します。また、SASLはデータ機密保護層の中でその後のプロトコル交換を保証するのにプロトコルを提供します。 データ機密保護層はデータ保全、データの機密性、および他のサービスを提供できます。
SASL's design is intended to allow new protocols to reuse existing mechanisms without requiring redesign of the mechanisms and allows existing protocols to make use of new mechanisms without redesign of protocols.
SASLのデザインは、新しいプロトコルがメカニズムの再設計を必要としないで既存のメカニズムを再利用するのを許容することを意図して、既存のプロトコルがプロトコルの再設計なしで新しいメカニズムを利用するのを許容します。
SASL is conceptually a framework that provides an abstraction layer between protocols and mechanisms as illustrated in the following diagram.
SASLによる概念的に、抽象化を提供するフレームワークが以下のダイヤグラムで例証されるようにプロトコルとメカニズムの間で層にされるということです。
SMTP LDAP XMPP Other protocols ...
\ | | /
\ | | /
SASL abstraction layer
/ | | \
/ | | \
EXTERNAL GSSAPI PLAIN Other mechanisms ...
SMTP LDAP XMPP Otherプロトコル… \ | | / \ | | /SASL抽象化層/| | \ / | | \EXTERNAL GSSAPI PLAIN Otherメカニズム…
It is through the interfaces of this abstraction layer that the framework allows any protocol to utilize any mechanism. While this layer does generally hide the particulars of protocols from mechanisms and the particulars of mechanisms from protocols, this layer does not generally hide the particulars of mechanisms from protocol implementations. For example, different mechanisms require different information to operate, some of them use password-based authentication, some of then require realm information, others make use of Kerberos tickets, certificates, etc. Also, in order to perform authorization, server implementations generally have to implement identity mapping between authentication identities, whose form is mechanism specific, and authorization identities, whose form is application protocol specific. Section 2 discusses identity concepts.
この抽象化層のインタフェースを通して、どんなプロトコルもフレームワークでどんなメカニズムも利用できます。 この層はプロトコルからメカニズムのメカニズムと子細からプロトコルの子細を一般に隠しますが、一般に、この層はプロトコル実装からメカニズムの子細を隠しません。 異なったメカニズムは、異なった情報が操作するのを例えば、彼らの何人かがパスワードベースの認証を使用するのを必要とします、いくつか。その時では、分野情報を必要としてください、そして、他のものはケルベロスチケットを利用します、証明書、など また、一般に、承認を実行するために、サーバ実装はフォームがメカニズム特有である認証のアイデンティティと、承認の間でフォームがアプリケーション・プロトコル特有であるアイデンティティを写像するアイデンティティを実装しなければなりません。 セクション2はアイデンティティ概念について論じます。
It is possible to design and implement this framework in ways that do abstract away particulars of similar mechanisms. Such a framework implementation, as well as mechanisms implementations, could be designed not only to be shared by multiple implementations of a particular protocol but to be shared by implementations of multiple protocols.
同様のメカニズムの子細を遠くの要約にする方法でこのフレームワークを設計して、実装するのは可能です。特定のプロトコルの複数の実装によって単に共有されるのではなく、複数のプロトコルの実装によって共有されるようにそのようなフレームワーク実装、およびメカニズム実装は設計できました。
Melnikov & Zeilenga Standards Track [Page 3] RFC 4422 SASL June 2006
メリニコフとZeilenga規格はSASL2006年6月にRFC4422を追跡します[3ページ]。
The framework incorporates interfaces with both protocols and mechanisms in which authentication exchanges are carried out. Section 3 discusses SASL authentication exchanges.
フレームワークは認証交換が行われるプロトコルとメカニズムの両方とのインタフェースを取り入れます。 セクション3はSASL認証交換について論じます。
To use SASL, each protocol (amongst other items) provides a method for identifying which mechanism is to be used, a method for exchange of mechanism-specific server-challenges and client-responses, and a method for communicating the outcome of the authentication exchange. Section 4 discusses SASL protocol requirements.
SASLを使用するために、各プロトコル(他の項目の中の)はどのメカニズムが使用されているかことであるかを特定するためのメソッド、メカニズム特有のサーバ挑戦とクライアント応答の交換のためのメソッド、および認証交換の結果を伝えるためのメソッドを提供します。 セクション4はSASLプロトコル要件について論じます。
Each SASL mechanism defines (amongst other items) a series of server-challenges and client-responses that provide authentication services and negotiate data security services. Section 5 discusses SASL mechanism requirements.
それぞれのSASLメカニズムは認証サービスを提供して、データ機密保護サービスを交渉する一連のサーバ挑戦とクライアント応答を定義します(他の項目の中で)。 セクション5はSASLメカニズム要件について論じます。
Section 6 discusses security considerations. Section 7 discusses IANA considerations. Appendix A defines the SASL EXTERNAL mechanism.
セクション6はセキュリティ問題について論じます。 セクション7はIANA問題について論じます。 付録AはSASL EXTERNALメカニズムを定義します。
1.1. Document Audiences
1.1. ドキュメントの読者
This document is written to serve several different audiences:
このドキュメントは数人の異なった聴衆に役立つように書かれています:
- protocol designers using this specification to support
authentication in their protocol,
- 彼らのプロトコルにおける認証をサポートするのにこの仕様を使用することでデザイナーについて議定書の中で述べてください。
- mechanism designers that define new SASL mechanisms, and
- そして新しいSASLメカニズムを定義するメカニズムデザイナー。
- implementors of clients or servers for those protocols that
support SASL.
- SASLをサポートするそれらのプロトコルのためのクライアントかサーバの作成者。
While the document organization is intended to allow readers to focus on details relevant to their engineering, readers are encouraged to read and understand all aspects of this document.
ドキュメント組織が、読者がそれらの工学に関連している詳細に焦点を合わせるのを許容することを意図しますが、このドキュメントの全面を読んで、読者が理解しているよう奨励されます。
1.2. Relationship to Other Documents
1.2. 他のドキュメントとの関係
This document obsoletes RFC 2222. It replaces all portions of RFC 2222 excepting sections 7.1 (the KERBEROS_IV mechanism), 7.2 (the GSSAPI mechanism), 7.3 (the SKEY mechanism). The KERBEROS_IV and SKEY mechanisms are now viewed as obsolete and their specifications provided in RFC 2222 are Historic. The GSSAPI mechanism is now separately specified [SASL-GSSAPI].
このドキュメントはRFC2222を時代遅れにします。 それはセクション7.1(ケルベロス_IVメカニズム)を除いてRFC2222のすべての一部を取り替えます、7.2(GSSAPIメカニズム)、7.3(SKEYメカニズム)。 ケルベロス_IVとSKEYメカニズム、見られた現在は同じくらい時代遅れであり、RFC2222に提供されたそれらの仕様はHistoricです。 GSSAPIメカニズムは現在、別々に指定されます[SASL-GSSAPI]。
Appendix B provides a summary of changes since RFC 2222.
付録BはRFC2222以来の変化の概要を提供します。
Melnikov & Zeilenga Standards Track [Page 4] RFC 4422 SASL June 2006
メリニコフとZeilenga規格はSASL2006年6月にRFC4422を追跡します[4ページ]。
1.3. Conventions
1.3. コンベンション
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 BCP 14 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Character names in this document use the notation for code points and names from the Unicode Standard [Unicode]. For example, the letter "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
キャラクター名はコード・ポイントと名前にユニコードStandard[ユニコード]から記法を本書では使用します。 例えば、手紙“a"は<U+0061>か<LATIN SMALL LETTER A>のどちらかとして表されるかもしれません。
Note: a glossary of terms used in Unicode can be found in [Glossary]. Information on the Unicode character encoding model can be found in [CharModel].
以下に注意してください。 [用語集]でユニコードで使用される用語の用語集を見つけることができます。 [CharModel]でユニコード文字符号化モデルに関する情報を見つけることができます。
In examples, "C:" and "S:" indicate lines of data to be sent by the client and server, respectively. Lines have been wrapped for improved readability.
例で「C:」 そして、「S:」 データの系列を示して、クライアントとサーバでそれぞれ送ってください。 改良された読み易さのために線を包装してあります。
2. Identity Concepts
2. アイデンティティ概念
In practice, authentication and authorization may involve multiple identities, possibly in different forms (simple username, Kerberos principal, X.500 Distinguished Name, etc.), possibly with different representations (e.g., ABNF-described UTF-8 encoded Unicode character string, BER-encoded Distinguished Name). While technical specifications often prescribe both the identity form and representation used on the network, different identity forms and/or representations may be (and often are) used within implementations. How identities of different forms relate to each other is, generally, a local matter. In addition, the forms and representations used within an implementation are a local matter.
習慣に、認証と承認は複数のアイデンティティにかかわるかもしれません、ことによると異なったフォーム(簡単なユーザ名、ケルベロス主体、X.500 Distinguished Nameなど)で、ことによると異なった表現で(例えば、ABNFによって説明されたUTF-8がユニコード文字列をコード化しました、BERによってコード化されたDistinguished Name)。 技術仕様書がしばしばアイデンティティフォームとネットワークで使用される表現の両方を処方している間、異なったアイデンティティフォーム、そして/または、表現は実装の中で使用されるかもしれません(そして、しばしばあります)。 一般に、異なったフォームのアイデンティティがどう互いに関連するかは、地域にかかわる事柄です。 さらに、実装の中で使用されたフォームと表現は地域にかかわる事柄です。
However, conceptually, the SASL framework involves two identities:
しかしながら、概念的に、SASLフレームワークは2つのアイデンティティにかかわります:
1) an identity associated with the authentication credentials
(termed the authentication identity), and
そして1) 認証資格証明書(認証のアイデンティティと呼ばれる)に関連しているアイデンティティ。
2) an identity to act as (termed the authorization identity).
2) 行動するアイデンティティ、(承認のアイデンティティと呼ばれます。)
SASL mechanism specifications describe the credential form(s) (e.g., X.509 certificates, Kerberos tickets, simple username/password) used to authenticate the client, including (where appropriate) the syntax and semantics of authentication identities carried in the credentials. SASL protocol specifications describe the identity form(s) used in authorization and, in particular, prescribe the syntax and semantics of the authorization identity character string to be transferred by mechanisms.
SASLメカニズム仕様はクライアントを認証するのに使用される資格証明フォーム(例えば、X.509証明書、ケルベロスチケット、簡単なユーザ名/パスワード)について説明します、資格証明書で運ばれた認証のアイデンティティの構文と意味論を含んでいて(適切であるところ)。 SASLプロトコル仕様は、承認に使用されるアイデンティティフォームについて説明して、メカニズムで移すために承認アイデンティティ文字列の構文と意味論を特に定めます。
Melnikov & Zeilenga Standards Track [Page 5] RFC 4422 SASL June 2006
メリニコフとZeilenga規格はSASL2006年6月にRFC4422を追跡します[5ページ]。
The client provides its credentials (which include or imply an authentication identity) and, optionally, a character string representing the requested authorization identity as part of the SASL exchange. When this character string is omitted or empty, the client is requesting to act as the identity associated with the credentials (e.g., the user is requesting to act as the authentication identity).
クライアントは資格証明書(認証のアイデンティティを含んでいるか、または含意する)と任意にSASL交換の一部として要求された承認のアイデンティティを表す文字列を提供します。 この文字列が省略されているか、または空であるときにクライアントは資格証明書に関連しているアイデンティティとして機能する要求(例えば、ユーザは、認証のアイデンティティとして機能するよう要求している)です。
The server is responsible for verifying the client's credentials and verifying that the identity it associates with the client's credentials (e.g., the authentication identity) is allowed to act as the authorization identity. A SASL exchange fails if either (or both) of these verifications fails. (The SASL exchange may fail for other reasons, such as service authorization failure.)
クライアントの資格証明書について確かめて、それがクライアントの資格証明書(例えば、認証のアイデンティティ)に関連づけるアイデンティティが承認のアイデンティティとして機能できることを確かめるのにサーバは原因となります。 これらの検証のどちらか(ともに)が失敗するなら、SASL交換は失敗します。 (SASL交換はサービス承認失敗などの他の理由で失敗するかもしれません。)
However, the precise form(s) of the authentication identities (used within the server in its verifications, or otherwise) and the precise form(s) of the authorization identities (used in making authorization decisions, or otherwise) are beyond the scope of SASL and this specification. In some circumstances, the precise identity forms used in some context outside of the SASL exchange may be dictated by other specifications. For instance, an identity assumption authorization (proxy authorization) policy specification may dictate how authentication and authorization identities are represented in policy statements.
しかしながら、認証のアイデンティティの正確なフォーム(検証におけるサーバの中で中古の、または、そうでない)と承認のアイデンティティの正確な用紙(承認決定をするのにおいて中古の、または、そうでない)はSASLの範囲とこの仕様を超えています。 いくつかの事情では、フォームが外の何らかの関係で使用したSASL交換の正確なアイデンティティは他の仕様で書き取られるかもしれません。 例えば、アイデンティティ仮定承認(プロキシ承認)方針仕様は認証と承認のアイデンティティが施政方針でどう表されるかを決めるかもしれません。
3. The Authentication Exchange
3. 認証交換
Each authentication exchange consists of a message from the client to the server requesting authentication via a particular mechanism, followed by one or more pairs of challenges from the server and responses from the client, followed by a message from the server indicating the outcome of the authentication exchange. (Note: exchanges may also be aborted as discussed in Section 3.5.)
それぞれの認証交換はメッセージからクライアントから1組以上の挑戦がサーバと応答からクライアントからあとに続いた特定のメカニズムを通した認証が認証交換の結果を示すサーバからのメッセージで続いたよう要求するサーバまで成ります。 (注意: また、交換はセクション3.5で議論するように中止されるかもしれません。)
The following illustration provides a high-level overview of an authentication exchange.
以下のイラストは認証交換のハイレベルの概要を提供します。
C: Request authentication exchange
S: Initial challenge
C: Initial response
<additional challenge/response messages>
S: Outcome of authentication exchange
C: 認証交換Sを要求してください: 挑戦Cに頭文字をつけてください: 応答の<の追加挑戦/応答メッセージ>Sに頭文字をつけてください: 認証交換の結果
If the outcome is successful and a security layer was negotiated, this layer is then installed (see Section 3.7). This also applies to the following illustrations.
結果がうまくいっていて、セキュリティ層が交渉されたなら、この層はインストールされます(セクション3.7を見てください)。 また、これは以下のイラストに適用されます。
Melnikov & Zeilenga Standards Track [Page 6] RFC 4422 SASL June 2006
メリニコフとZeilenga規格はSASL2006年6月にRFC4422を追跡します[6ページ]。
Some mechanisms specify that the first data sent in the authentication exchange is from the client to the server. Protocols may provide an optional initial response field in the request message to carry this data. Where the mechanism specifies that the first data sent in the exchange is from the client to the server, the protocol provides an optional initial response field, and the client uses this field, the exchange is shortened by one round-trip:
いくつかのメカニズムが、最初のデータが、クライアントからサーバまで認証交換があるのを送ったと指定します。プロトコルは任意の初期の応答野原をこのデータを運ぶ要求メッセージに供給するかもしれません。 メカニズムが、最初のデータが、クライアントからサーバまで交換があるのを送ったと指定して、プロトコルが任意の初期の応答野原を供給して、クライアントがこの分野を使用するところでは、交換は1時までに往復で短くされます:
C: Request authentication exchange + Initial response
<additional challenge/response messages>
S: Outcome of authentication exchange
C: 認証交換+初期の応答<追加挑戦/応答メッセージ>Sを要求してください: 認証交換の結果
Where the mechanism specifies that the first data sent in the exchange is from the client to the server and this field is unavailable or unused, the client request is followed by an empty challenge.
メカニズムが、最初のデータがこの分野がクライアントからサーバまで交換があって、入手できないか、または未使用であることを送ったと指定するところに、空の挑戦はクライアント要求のあとに続いています。
C: Request authentication exchange
S: Empty Challenge
C: Initial Response
<additional challenge/response messages>
S: Outcome of authentication exchange
C: 認証交換Sを要求してください: 挑戦Cを空にしてください: Responseの<の追加挑戦/応答メッセージ>Sに頭文字をつけてください: 認証交換の結果
Should a client include an initial response in its request where the mechanism does not allow the client to send data first, the authentication exchange fails.
クライアントがクライアントが最初にメカニズムでデータを送ることができない要求における初期の応答を入れるなら、認証交換は失敗します。
Some mechanisms specify that the server is to send additional data to the client when indicating a successful outcome. Protocols may provide an optional additional data field in the outcome message to carry this data. Where the mechanism specifies that the server is to return additional data with the successful outcome, the protocol provides an optional additional data field in the outcome message, and the server uses this field, the exchange is shortened by one round-trip:
いくつかのメカニズムが、サーバがうまくいっている結果を示すとき、追加データをクライアントに送ることであると指定します。 プロトコルはこのデータを運ぶ結果メッセージに任意の追加データ・フィールドを提供するかもしれません。 メカニズムが、サーバがうまくいっている結果がある追加データを返すことであると指定して、プロトコルが任意の追加データ・フィールドを結果メッセージに提供して、サーバがこの分野を使用するところでは、交換は1時までに往復で短くされます:
C: Request authentication exchange
S: Initial challenge
C: Initial response
<additional challenge/response messages>
S: Outcome of authentication exchange with
additional data with success
C: 認証交換Sを要求してください: 挑戦Cに頭文字をつけてください: 応答の<の追加挑戦/応答メッセージ>Sに頭文字をつけてください: 成功がある追加データがある認証交換の結果
Where the mechanism specifies that the server is to return additional data to the client with a successful outcome and this field is unavailable or unused, the additional data is sent as a challenge whose response is empty. After receiving this response, the server then indicates the successful outcome.
メカニズムがこの分野がサーバがうまくいっている結果をもっているクライアントに追加データを返すことであり、入手できないか、または未使用であると指定するところに、応答が空である挑戦として追加データを送ります。 そして、この応答を受けた後に、サーバはうまくいっている結果を示します。
Melnikov & Zeilenga Standards Track [Page 7] RFC 4422 SASL June 2006
メリニコフとZeilenga規格はSASL2006年6月にRFC4422を追跡します[7ページ]。
C: Request authentication exchange
S: Initial challenge
C: Initial response
<additional challenge/response messages>
S: Additional data challenge
C: Empty Response
S: Outcome of authentication exchange
C: 認証交換Sを要求してください: 挑戦Cに頭文字をつけてください: 応答の<の追加挑戦/応答メッセージ>Sに頭文字をつけてください: 追加データはCに挑戦します: 応答Sを空にしてください: 認証交換の結果
Where mechanisms specify that the first data sent in the exchange is from the client to the server and additional data is sent to the client along with indicating a successful outcome, and the protocol provides fields supporting both, then the exchange takes two fewer round-trips:
次に、メカニズムが、最初のデータが、クライアントからサーバまで交換があるのを送ったと指定して、うまくいっている結果を示すと共に追加データをクライアントに送って、プロトコルが両方をサポートする野原を供給するところでは、交換はもう2つの周遊旅行減を取ります:
C: Request authentication exchange + Initial response
<additional challenge/response messages>
S: Outcome of authentication exchange
with additional data with success
C: 認証交換+初期の応答<追加挑戦/応答メッセージ>Sを要求してください: 成功がある追加データがある認証交換の結果
instead of:
以下の代わりに
C: Request authentication exchange
S: Empty Challenge
C: Initial Response
<additional challenge/response messages>
S: Additional data challenge
C: Empty Response
S: Outcome of authentication exchange
C: 認証交換Sを要求してください: 挑戦Cを空にしてください: Responseの<の追加挑戦/応答メッセージ>Sに頭文字をつけてください: 追加データはCに挑戦します: 応答Sを空にしてください: 認証交換の結果
3.1. Mechanism Naming
3.1. メカニズム命名
SASL mechanisms are named by character strings, from 1 to 20 characters in length, consisting of ASCII [ASCII] uppercase letters, digits, hyphens, and/or underscores. In the following Augmented Backus-Naur Form (ABNF) [RFC4234] grammar, the <sasl-mech> production defines the syntax of a SASL mechanism name.
SASLメカニズムは文字列によって命名されます、長さにおける1〜20のキャラクタまで、ASCII[ASCII]大文字、ケタ、ハイフン、そして/または、強調から成って。 以下のAugmented BN記法(ABNF)[RFC4234]文法では、<sasl-mech>生産はSASLメカニズム名の構文を定義します。
sasl-mech = 1*20mech-char
mech-char = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE
; mech-char is restricted to A-Z (uppercase only), 0-9, -, and _
; from ASCII character set.
sasl-mech=1*20mech-炭mech-炭=UPPER-アルファー/DIGIT/HYPHEN/UNDERSCORE。 mech-炭がA-Z(大文字専用)、0-9に制限される、-、_、。 ASCII文字の組から。
UPPER-ALPHA = %x41-5A ; A-Z (uppercase only)
DIGIT = %x30-39 ; 0-9
HYPHEN = %x2D ; hyphen (-)
UNDERSCORE = %x5F ; underscore (_)
上側のアルファー=%x41-5A。 1Z(大文字専用)のDIGIT=%x30-39。 0-9 =%x2Dをハイフンで結んでください。 (-) UNDERSCORE=%x5Fをハイフンで結んでください。 強調(_)
SASL mechanism names are registered as discussed in Section 7.1.
SASLメカニズム名はセクション7.1で議論するように登録されています。
Melnikov & Zeilenga Standards Track [Page 8] RFC 4422 SASL June 2006
メリニコフとZeilenga規格はSASL2006年6月にRFC4422を追跡します[8ページ]。
3.2. Mechanism Negotiation
3.2. メカニズム交渉
Mechanism negotiation is protocol specific.
メカニズム交渉はプロトコル特有です。
Commonly, a protocol will specify that the server advertises supported and available mechanisms to the client via some facility provided by the protocol, and the client will then select the "best" mechanism from this list that it supports and finds suitable.
一般的に、プロトコルは、サーバがプロトコルによって提供された何らかの施設でサポートしていて利用可能なメカニズムのクライアントに広告を出すと指定するでしょう、そして、次に、クライアントはそれがサポートして、見つけるこのリストからの適当な「最も良い」メカニズムを選択するでしょう。
Note that the mechanism negotiation is not protected by the subsequent authentication exchange and hence is subject to downgrade attacks if not protected by other means.
他の手段で保護されないならメカニズム交渉はその後の認証交換で保護されないで、したがって、受けることがあることに注意して、攻撃を格下げしてください。
To detect downgrade attacks, a protocol can allow the client to discover available mechanisms subsequent to the authentication exchange and installation of data security layers with at least data integrity protection. This allows the client to detect changes to the list of mechanisms supported by the server.
ダウングレード攻撃を検出するために、プロトコルで、クライアントは少なくともデータ保全保護によるデータ機密保護層の認証交換とインストールへのその後の利用可能なメカニズムを発見できます。 これで、クライアントはサーバによってサポートされたメカニズムのリストへの変化を検出できます。
3.3. Request Authentication Exchange
3.3. 認証交換を要求してください。
The authentication exchange is initiated by the client by requesting authentication via a mechanism it specifies. The client sends a message that contains the name of the mechanism to the server. The particulars of the message are protocol specific.
認証交換は、それが指定するメカニズムで認証を要求することによって、クライアントによって起こされます。 クライアントはメカニズムの名前をサーバに含むメッセージを送ります。メッセージの子細はプロトコル特有です。
Note that the name of the mechanism is not protected by the mechanism, and hence is subject to alteration by an attacker if not integrity protected by other means.
メカニズムの名前はメカニズムによって保護されないで、したがって、他の手段で保護された攻撃者か保全で変更を受けることがあることに注意してください。
Where the mechanism is defined to allow the client to send data first, and the protocol's request message includes an optional initial response field, the client may include the response to the initial challenge in the authentication request message.
メカニズムがクライアントが最初にデータを送るのを許容するために定義されて、プロトコルの要求メッセージが任意の初期の応答分野を含んでいるところでは、クライアントは認証要求メッセージにおける初期の挑戦への応答を入れるかもしれません。
3.4. Challenges and Responses
3.4. 挑戦と応答
The authentication exchange involves one or more pairs of server- challenges and client-responses, the particulars of which are mechanism specific. These challenges and responses are enclosed in protocol messages, the particulars of which are protocol specific.
認証交換は1組以上のサーバ挑戦とクライアント応答にかかわります。その子細はメカニズム特有です。 これらの挑戦と応答はプロトコルメッセージに同封されます。その子細はプロトコル特有です。
Through these challenges and responses, the mechanism may:
これらの挑戦と応答で、メカニズムはそうするかもしれません:
- authenticate the client to the server,
- サーバにクライアントを認証してください。
- authenticate the server to the client,
- クライアントにサーバを認証してください。
Melnikov & Zeilenga Standards Track [Page 9] RFC 4422 SASL June 2006
メリニコフとZeilenga規格はSASL2006年6月にRFC4422を追跡します[9ページ]。
- transfer an authorization identity string,
- 承認アイデンティティストリングを移してください。
- negotiate a security layer, and
- そしてセキュリティ層を交渉してください。
- provide other services.
- 他のサービスを提供してください。
The negotiation of the security layer may involve negotiation of the security services to be provided in the layer, how these services will be provided, and negotiation of a maximum cipher-text buffer size each side is able to receive in the layer (see Section 3.6).
セキュリティ層の交渉は層に提供されるセキュリティー・サービスの交渉、どうこれらのサービスを提供するだろうか、そして、およびそれぞれの側が層の中で受けることができる最大の暗号文バッファサイズの交渉にかかわるかもしれません(セクション3.6を見てください)。
After receiving an authentication request or any client response, the server may issue a challenge, abort the exchange, or indicate the outcome of an exchange. After receiving a challenge, a client mechanism may issue a response or abort the exchange.
認証要求かどんなクライアント応答も受け取った後に、サーバは、挑戦を発行するか、交換を中止するか、または交換の結果を示すかもしれません。 挑戦を受けた後に、クライアントメカニズムは、応答を発行するか、または交換を中止するかもしれません。
3.4.1. Authorization Identity String
3.4.1. 承認アイデンティティストリング
The authorization identity string is a sequence of zero or more Unicode [Unicode] characters, excluding the NUL (U+0000) character, representing the identity to act as.
承認アイデンティティストリングは、ゼロの系列か、より多くのユニコード[ユニコード]キャラクタです、NUL(U+0000)キャラクタを除いて、アイデンティティを表して。行動するために。
If the authorization identity string is absent, the client is requesting to act as the identity the server associates with the client's credentials. An empty string is equivalent to an absent authorization identity.
承認アイデンティティストリングが欠けるなら、クライアントは、アイデンティティとして機能するように、サーバがクライアントの資格証明書と交際するよう要求しています。 空のストリングは欠けている承認のアイデンティティに同等です。
A non-empty authorization identity string indicates that the client wishes to act as the identity represented by the string. In this case, the form of identity represented by the string, as well as the precise syntax and semantics of the string, is protocol specific.
非空の承認アイデンティティストリングは、クライアントがストリングによって表されたアイデンティティとして機能したがっているのを示します。 アイデンティティのフォームは、ストリングのストリング、正確な構文、および意味論でプロトコルがこの場合特定であると表しました。
While the character encoding schema used to transfer the authorization identity string in the authentication exchange is mechanism specific, mechanisms are expected to be capable of carrying the entire Unicode repertoire (with the exception of the NUL character).
認証交換で承認アイデンティティストリングを移すのに使用される文字符号化図式がメカニズム特有である間、メカニズムが全体のユニコードレパートリー(NULキャラクタを除いた)を運ぶことができると予想されます。
3.5. Aborting Authentication Exchanges
3.5. 認証交換を中止します。
A client or server may desire to abort an authentication exchange if it is unwilling or unable to continue (or enter into).
または、不本意であるか、または続くことができないならクライアントかサーバが、認証交換を中止することを望むかもしれない、(入る、)
A client may abort the authentication exchange by sending a message, the particulars of which are protocol specific, to the server, indicating that the exchange is aborted. The server may be required by the protocol to return a message in response to the client's abort message.
クライアントはそれの子細がサーバに特定のプロトコルであるメッセージを送ることによって、認証交換を中止するかもしれません、交換が中止されるのを示して。 サーバは、クライアントのアボートメッセージに対応してメッセージを返すためにプロトコルによって必要とされるかもしれません。
Melnikov & Zeilenga Standards Track [Page 10] RFC 4422 SASL June 2006
メリニコフとZeilenga規格はSASL2006年6月にRFC4422を追跡します[10ページ]。
Likewise, a server may abort the authentication exchange by sending a message, the particulars of which are protocol specific, to the client, indicating that the exchange is aborted.
同様に、サーバはそれの子細がクライアントにとって、特定のプロトコルであるメッセージを送ることによって、認証交換を中止するかもしれません、交換が中止されるのを示して。
3.6. Authentication Outcome
3.6. 認証結果
At the conclusion of the authentication exchange, the server sends a message, the particulars of which are protocol specific, to the client indicating the outcome of the exchange.
認証交換の結論のときに、サーバはメッセージを送ります。その子細は交換の結果を示すクライアントにとって、特定のプロトコルです。
The outcome is not successful if
結果はうまくいっていません。
- the authentication exchange failed for any reason,
- 認証交換はどんな理由でも失敗しました。
- the client's credentials could not be verified,
- クライアントの資格証明書について確かめることができませんでした。
- the server cannot associate an identity with the client's
credentials,
- サーバはクライアントの資格証明書にアイデンティティを関連づけることができません。
- the client-provided authorization identity string is malformed,
- クライアントによって提供された承認アイデンティティストリングは奇形です。
- the identity associated with the client's credentials is not
authorized to act as the requested authorization identity,
- クライアントの資格証明書に関連しているアイデンティティが要求された承認のアイデンティティとして機能するのが認可されません。
- the negotiated security layer (or lack thereof) is not
suitable, or
- または交渉されたセキュリティ層(または、それの不足)が適当でない。
- the server is not willing to provide service to the client for
any reason.
- サーバはクライアントに対するサービスをどんな理由にも提供することを望んでいません。
The protocol may include an optional additional data field in this outcome message. This field can only include additional data when the outcome is successful.
プロトコルはこの結果メッセージに任意の追加データ・フィールドを含むかもしれません。 結果がうまくいっているときだけ、この分野は追加データを含むことができます。
If the outcome is successful and a security layer was negotiated, this layer is then installed. If the outcome is unsuccessful, or a security layer was not negotiated, any existing security is left in place.
結果がうまくいっていて、セキュリティ層が交渉されたなら、この層はインストールされます。 結果が失敗しているか、またはセキュリティ層が交渉されなかったなら、どんな既存のセキュリティも適所から外されます。
The outcome message provided by the server can provide a way for the client to distinguish between errors that are best dealt with by re- prompting the user for her credentials, errors that are best dealt with by telling the user to try again later, and errors where the user must contact a system administrator for resolution (see the SYS and AUTH POP Response Codes [RFC3206] specification for an example). This distinction is particularly useful during scheduled server maintenance periods as it reduces support costs. It is also important that the server can be configured such that the outcome
サーバによって提供された結果メッセージはクライアントが彼女の資格証明書のためにユーザを再うながすことによって最も良い対処する誤り、後で再試行するようにユーザに言うことによって最も良い対処する誤り、および誤りを見分ける方法をユーザが解決のためにシステム管理者に連絡しなければならない(例のためのSYSとAUTH POP Response Codes[RFC3206]仕様を見てください)ところに提供できます。 サポートコストを削減するので、この区別は予定されているサーバメインテナンスの期間、特に役に立ちます。 また、サーバが構成されたそのようなものがそれであったならそうすることができるのも重要である、結果
Melnikov & Zeilenga Standards Track [Page 11] RFC 4422 SASL June 2006
メリニコフとZeilenga規格はSASL2006年6月にRFC4422を追跡します[11ページ]。
message will not distinguish between a valid user with invalid credentials and an invalid user.
メッセージは無効の資格証明書と無効のユーザと共に正規ユーザーを見分けないでしょう。
3.7. Security Layers
3.7. セキュリティ層
SASL mechanisms may offer a wide range of services in security layers. Typical services include data integrity and data confidentiality. SASL mechanisms that do not provide a security layer are treated as negotiating no security layer.
SASLメカニズムは安全に層をさまざまなサービスに提供するかもしれません。 典型的なサービスはデータ保全とデータの機密性を含んでいます。 セキュリティ層を提供しないSASLメカニズムがセキュリティ層を全く交渉しないとして扱われます。
If use of a security layer is negotiated in the authentication protocol exchange, the layer is installed by the server after indicating the outcome of the authentication exchange and installed by the client upon receipt of the outcome indication. In both cases, the layer is installed before transfer of further protocol data. The precise position upon which the layer takes effect in the protocol data stream is protocol specific.
セキュリティ層の使用が認証プロトコル交換で交渉されるなら、層は、認証交換の結果を示した後に、サーバによってインストールされて、結果指示を受け取り次第クライアントによってインストールされます。 どちらの場合も、層はさらなるプロトコルデータの転送の前にインストールされます。 層がプロトコルデータ・ストリームで実施する正確な位置はプロトコル特有です。
Once the security layer is in effect in the protocol data stream, it remains in effect until either a subsequently negotiated security layer is installed or the underlying transport connection is closed.
セキュリティ層がいったんプロトコルデータ・ストリームで有効になると、次に交渉されたセキュリティ層がインストールされるか、または基本的な輸送接続が閉じられるまで、それは有効なままで残っています。
When in effect, the security layer processes protocol data into buffers of protected data. If at any time the security layer is unable or unwilling to continue producing buffers protecting protocol data, the underlying transport connection MUST be closed. If the security layer is not able to decode a received buffer, the underlying connection MUST be closed. In both cases, the underlying transport connection SHOULD be closed gracefully.
事実上、セキュリティ層のプロセスが保護されたデータに関するバッファにデータについて議定書の中で述べると。 いつでもセキュリティ層がプロトコルデータを保護するバッファを作り出し続けるために不本意です、基本的な輸送接続が閉店しなければならないということであるなら。 セキュリティ層が受信されたバッファを解読できないなら、基本的な接続は閉店しなければなりません。 両方では、優雅に閉じられて、ケース、基本的さは接続SHOULDを輸送します。
Each buffer of protected data is transferred over the underlying transport connection as a sequence of octets prepended with a four- octet field in network byte order that represents the length of the buffer. The length of the protected data buffer MUST be no larger than the maximum size that the other side expects. Upon the receipt of a length field whose value is greater than the maximum size, the receiver SHOULD close the connection, as this might be a sign of an attack.
八重奏の系列がバッファの長さを表すネットワークバイトオーダーにおける4八重奏分野でprependedされたとき、保護されたデータに関する各バッファを基本的な輸送接続の上に移します。 保護されたデータバッファの長さは反対側が予想する最大サイズより大きいはずがありません。 値が最大サイズより大きい長さの分野の領収書に、受信機SHOULDは接続を終えます、これが攻撃のサインであるかもしれないので。
The maximum size that each side expects is fixed by the mechanism, either through negotiation or by its specification.
それぞれの側が予想する最大サイズは交渉を通して、または、メカニズムか、その仕様で固定されています。
3.8. Multiple Authentications
3.8. 複数の認証
Unless explicitly permitted in the protocol (as stated in the protocol's technical specification), only one successful SASL authentication exchange may occur in a protocol session. In this
プロトコルで明らかに受入れられない場合(プロトコルの技術仕様書に述べられているように)、1回のうまくいっているSASL認証交換だけがプロトコルセッションのときに起こるかもしれません。 これで
Melnikov & Zeilenga Standards Track [Page 12] RFC 4422 SASL June 2006
メリニコフとZeilenga規格はSASL2006年6月にRFC4422を追跡します[12ページ]。
case, once an authentication exchange has successfully completed, further attempts to initiate an authentication exchange fail.
ケース、かつての交換が認証交換を起こす首尾よく完成されていて、さらなる試みによって失敗される認証。
Where multiple successful SASL authentication exchanges are permitted in the protocol, then in no case may multiple SASL security layers be simultaneously in effect. If a security layer is in effect and a subsequent SASL negotiation selects a second security layer, then the second security layer replaces the first. If a security layer is in effect and a subsequent SASL negotiation selects no security layer, the original security layer remains in effect.
複数のうまくいっているSASL認証交換がプロトコルで受入れられるところでは、複数のSASLセキュリティ層が同時に、その時、決して、有効でありませんように。 セキュリティ層が有効であり、その後のSASL交渉が2番目のセキュリティ層を選択するなら、2番目のセキュリティ層は1番目を取り替えます。 セキュリティ層が有効であり、その後のSASL交渉がセキュリティ層を全く選択しないなら、オリジナルのセキュリティ層は有効なままで残っています。
Where multiple successful SASL negotiations are permitted in the protocol, the effect of a failed SASL authentication exchange upon the previously established authentication and authorization state is protocol specific. The protocol's technical specification should be consulted to determine whether the previous authentication and authorization state remains in force, or changed to an anonymous state, or otherwise was affected. Regardless of the protocol- specific effect upon previously established authentication and authorization state, the previously negotiated security layer remains in effect.
複数のうまくいっているSASL交渉がプロトコルで受入れられるところでは、以前に確立した認証と承認状態への失敗したSASL認証交換の効果はプロトコル特有です。 プロトコルの技術仕様書は、前の認証と承認状態が有効なままで残っているかどうか決定するために相談するべきであったか、匿名の状態に変えるべきであった、またはそうでなければ、影響を受けました。 以前に確立した認証と承認状態へのプロトコルの特定の効果にかかわらず、以前に交渉されたセキュリティ層は有効なままで残っています。
4. Protocol Requirements
4. プロトコル要件
In order for a protocol to offer SASL services, its specification MUST supply the following information:
プロトコルがサービスをSASLに提供するように、仕様は以下の情報を提供しなければなりません:
1) A service name, to be selected from registry of "service" elements
for the Generic Security Service Application Program Interface
(GSSAPI) host-based service name form, as described in Section 4.1
of [RFC2743]. Note that this registry is shared by all GSSAPI and
SASL mechanisms.
1) サービス名、「サービス」の登録から選択されるために、Generic Security Service Application Program Interface(GSSAPI)のホストベースのサービス名のための要素は形成されます、[RFC2743]のセクション4.1で説明されるように。 この登録がすべてのGSSAPIとSASLメカニズムによって共有されることに注意してください。
2) Detail any mechanism negotiation facility that the protocol
provides (see Section 3.2).
2) プロトコルが提供するあらゆるメカニズム交渉施設について詳述してください(セクション3.2を見てください)。
A protocol SHOULD specify a facility through which the client may
discover, both before initiation of the SASL exchange and after
installing security layers negotiated by the exchange, the names
of the SASL mechanisms that the server makes available to the
client. The latter is important to allow the client to detect
downgrade attacks. This facility is typically provided through
the protocol's extensions or capabilities discovery facility.
プロトコルSHOULDはSASL交換の開始の前とセキュリティをインストールした後にクライアントが交換で交渉された層を発見するかもしれない施設を指定します、サーバがクライアントにとって利用可能にするSASLメカニズムの名前。 後者は、クライアントがダウングレード攻撃を検出するのを許容するために重要です。 プロトコルの拡大か能力発見施設でこの施設を通常提供します。
3) Definition of the messages necessary for authentication exchange,
including the following:
3) 以下を含む認証交換に必要なメッセージの定義:
Melnikov & Zeilenga Standards Track [Page 13] RFC 4422 SASL June 2006
メリニコフとZeilenga規格はSASL2006年6月にRFC4422を追跡します[13ページ]。
a) A message to initiate the authentication exchange (see Section
3.3).
a) 認証交換(セクション3.3を見る)を起こすメッセージ。
This message MUST contain a field for carrying the name of the
mechanism selected by the client.
このメッセージはクライアントによって選択されたメカニズムの名前を運ぶための分野を含まなければなりません。
This message SHOULD contain an optional field for carrying an
initial response. If the message is defined with this field,
the specification MUST describe how messages with an empty
initial response are distinguished from messages with no
initial response. This field MUST be capable of carrying
arbitrary sequences of octets (including zero-length sequences
and sequences containing zero-valued octets).
このメッセージSHOULDは初期の応答を運ぶための任意の分野を含んでいます。 メッセージがこの分野で定義されるなら、仕様は空の初期の応答があるメッセージがメッセージと初期の応答なしでどう区別されるかを説明しなければなりません。 この分野は八重奏の気紛れな順番を運ぶことができなければなりません(ゼロ・レングス系列と無評価された八重奏を含む系列を含んでいて)。
b) Messages to transfer server challenges and client responses
(see Section 3.4).
b) サーバ挑戦とクライアント応答(セクション3.4を見る)を移すメッセージ。
Each of these messages MUST be capable of carrying arbitrary
sequences of octets (including zero-length sequences and
sequences containing zero-valued octets).
それぞれに関するこれらのメッセージは八重奏の気紛れな順番を運ぶことができなければなりません(ゼロ・レングス系列と無評価された八重奏を含む系列を含んでいて)。
c) A message to indicate the outcome of the authentication
exchange (see Section 3.6).
c) 認証交換(セクション3.6を見る)の結果を示すメッセージ。
This message SHOULD contain an optional field for carrying
additional data with a successful outcome. If the message is
defined with this field, the specification MUST describe how
messages with an empty additional data are distinguished from
messages with no additional data. This field MUST be capable
of carrying arbitrary sequences of octets (including zero-
length sequences and sequences containing zero-valued octets).
このメッセージSHOULDはうまくいっている結果で追加データを運ぶための任意の分野を含んでいます。 メッセージがこの分野で定義されるなら、仕様は空の追加データがあるメッセージがメッセージと追加データなしでどう区別されるかを説明しなければなりません。 この分野は八重奏の気紛れな順番を運ぶことができなければなりません(無の長さの系列と無評価された八重奏を含む系列を含んでいて)。
4) Prescribe the syntax and semantics of non-empty authorization
identity strings (see Section 3.4.1).
4) 非空の承認アイデンティティストリングの構文と意味論を定めてください(セクション3.4.1を見てください)。
In order to avoid interoperability problems due to differing
normalizations, the protocol specification MUST detail precisely
how and where (client or server) non-empty authorization identity
strings are prepared, including all normalizations, for comparison
and other applicable functions to ensure proper function.
異なった正常化のため相互運用性問題を避けるために、プロトコル仕様は、非空の承認のアイデンティティが結ぶ(クライアントかサーバ)が正確にどのように、どこで準備されているかを詳しく述べなければなりません、比較と他の適切な機能が適切な機能を確実にするようにすべての正常化を含んでいて。
Specifications are encouraged to prescribe use of existing
authorization identity forms as well as existing string
representations, such as simple user names [RFC4013].
仕様が既存のストリング表現と同様に既存の承認アイデンティティフォームの使用を定めるよう奨励されます、簡単なユーザ名[RFC4013]などのように。
Where the specification does not precisely prescribe how
identities in SASL relate to identities used elsewhere in the
protocol, for instance, in access control policy statements, it
例えば、仕様が正確にSASLのアイデンティティがどうプロトコルにおけるほかの場所で使用されたアイデンティティに関連するかを処方しないところでは、アクセスでは、施政方針を制御してください、それ
Melnikov & Zeilenga Standards Track [Page 14] RFC 4422 SASL June 2006
メリニコフとZeilenga規格はSASL2006年6月にRFC4422を追跡します[14ページ]。
may be appropriate for the protocol to provide a facility by which
the client can discover information (such as the representation of
the identity used in making access control decisions) about
established identities for these uses.
プロトコルがクライアントがこれらの用途に関して確立したアイデンティティの情報(アクセスをコントロール決定にする際に使用されるアイデンティティの表現などの)を発見できる施設を提供するのは、適切であるかもしれません。
5) Detail any facility the protocol provides that allows the client
and/or server to abort authentication exchange (see Section 3.5).
5) クライアント、そして/または、サーバがプロトコルがそれを提供するどんな施設でも認証交換を中止できるという(セクション3.5を見てください)詳細。
Protocols that support multiple authentications typically allow a
client to abort an ongoing authentication exchange by initiating a
new authentication exchange. Protocols that do not support
multiple authentications may require the client to close the
connection and start over to abort an ongoing authentication
exchange.
複数の認証をサポートするプロトコルで、クライアントは、新しい認証交換を起こすことによって、進行中の認証交換を通常中止できます。 複数の認証をサポートしないプロトコルは、クライアントが進行中の認証交換を中止するために接続を終えて、やり直すのを必要とするかもしれません。
Protocols typically allow the server to abort ongoing
authentication exchanges by returning a non-successful outcome
message.
プロトコルで、サーバは、非うまくいっている結果メッセージを返すことによって、進行中の認証交換を通常中止できます。
6) Identify precisely where newly negotiated security layers start to
take effect, in both directions (see Section 3.7).
6) 新たに交渉されたセキュリティ層が正確にどこから両方の方向に効き始めるか(セクション3.7を見てください)特定してください。
Typically, specifications require security layers to start taking
effect on the first octet following the outcome message in data
being sent by the server and on the first octet sent after receipt
of the outcome message in data being sent by the client.
通常、仕様は、クライアントによって送られながら、データでサーバによって送られて、結果メッセージの領収書の後に最初の八重奏に送られるデータの結果メッセージに従って、最初の八重奏のときに効き始めるようにセキュリティ層を必要とします。
7) If the protocol supports other layered security services, such as
Transport Layer Security (TLS) [RFC4346], the specification MUST
prescribe the order in which security layers are applied to
protocol data.
7) プロトコルが、他の層にされたセキュリティがTransport Layer Securityなどのサービス(TLS)であるとサポートするなら [RFC4346]、仕様はセキュリティ層がデータについて議定書の中で述べるために適用されるオーダーを定めなければなりません。
For instance, where a protocol supports both TLS and SASL security
layers, the specification could prescribe any of the following:
例えば、プロトコルがTLSとSASLの両方にセキュリティ層を支えるところでは、仕様は以下のどれかを処方するかもしれません:
a) SASL security layer is always applied first to data being sent
and, hence, applied last to received data,
a) SASLセキュリティ層は、いつも最初に、送られるデータに適用されて、したがって、最後に受信データに適用されます。
b) SASL security layer is always applied last to data being sent
and, hence, applied first to received data,
b) SASLセキュリティ層は、最後にいつも送られるデータに適用されて、したがって、最初に、受信データに適用されます。
c) Layers are applied in the order in which they were installed,
c) 層はそれらがインストールされたオーダーで適用されます。
d) Layers are applied in the reverse order in which they were
installed, or
d) または層がそれらがインストールされた逆順で適用される。
e) Both TLS and SASL security layers cannot be installed.
e) TLSとSASLセキュリティ層の両方をインストールできません。
Melnikov & Zeilenga Standards Track [Page 15] RFC 4422 SASL June 2006
メリニコフとZeilenga規格はSASL2006年6月にRFC4422を追跡します[15ページ]。
8) Indicate whether the protocol supports multiple authentications
(see Section 3.8). If so, the protocol MUST detail the effect a
failed SASL authentication exchange will have upon a previously
established authentication and authorization state.
8) プロトコルが複数の認証をサポートするかどうかを(セクション3.8を見てください)示してください。 そうだとすれば、プロトコルは失敗したSASL認証交換が以前に確立した認証と承認状態に持っている効果を詳しく述べなければなりません。
Protocol specifications SHOULD avoid stating implementation requirements that would hinder replacement of applicable mechanisms. In general, protocol specifications SHOULD be mechanism neutral. There are a number of reasonable exceptions to this recommendation, including
プロトコル仕様SHOULDは、適切なメカニズムの交換を妨げる実装要件を述べるのを避けます。メカニズムが中立であったなら、一般に、仕様SHOULDについて議定書の中で述べてください。 この推薦、包含への多くの妥当な例外があります。
- detailing how credentials (which are mechanism specific) are
managed in the protocol,
- 資格証明書(メカニズム特有である)がプロトコルでどう管理されるかを詳しく述べます。
- detailing how authentication identities (which are mechanism
specific) and authorization identities (which are protocol
specific) relate to each other, and
- そして認証のアイデンティティ(メカニズム特有である)と承認のアイデンティティ(プロトコル特有である)がどう互いに関連するかを詳しく述べる。
- detailing which mechanisms are applicable to the protocol.
- どのメカニズムがプロトコルに適切であるかを詳しく述べます。
5. Mechanism Requirements
5. メカニズム要件
SASL mechanism specifications MUST supply the following information:
SASLメカニズム仕様は以下の情報を提供しなければなりません:
1) The name of the mechanism (see Section 3.1). This name MUST be
registered as discussed in Section 7.1.
1) メカニズム(セクション3.1を見る)の名前。 セクション7.1で議論するように登録されていて、この名前はそうしなければなりません。
2) A definition of the server-challenges and client-responses of the
authentication exchange, as well as the following:
2) サーバ挑戦の定義と認証交換、および以下のクライアント応答:
a) An indication of whether the mechanism is client-first,
variable, or server-first. If a SASL mechanism is defined as
client-first and the client does not send an initial response
in the authentication request, then the first server challenge
MUST be empty (the EXTERNAL mechanism is an example of this
case). If a SASL mechanism is defined as variable, then the
specification needs to state how the server behaves when the
initial client response in the authentication request is
omitted (the DIGEST-MD5 mechanism [DIGEST-MD5] is an example of
this case). If a SASL mechanism is defined as server-first,
then the client MUST NOT send an initial client response in the
authentication request (the CRAM-MD5 mechanism [CRAM-MD5] is an
example of this case).
a) メカニズムがクライアント-1番目であるかどうかのしるし、変数、またはサーバ-1番目。 SASLメカニズムがクライアント-1番目と定義されて、クライアントが認証要求における初期の応答を送らないなら、最初のサーバ挑戦は空であるに違いありません(EXTERNALメカニズムは本件に関する例です)。 SASLメカニズムが同じくらい可変な状態で定義されるなら、仕様は、認証要求における初期のクライアント応答が省略されるとき(DIGEST-MD5メカニズム[DIGEST-MD5]は本件に関する例です)、サーバがどう振る舞うかを述べる必要があります。 SASLメカニズムがサーバ-1番目と定義されるなら、クライアントは認証要求における初期のクライアント応答を送ってはいけません(CRAM-MD5メカニズム[CRAM-MD5]は本件に関する例です)。
b) An indication of whether the server is expected to provide
additional data when indicating a successful outcome. If so,
if the server sends the additional data as a challenge, the
b) うまくいっている結果を示すとき、サーバが追加データを提供すると予想されるかどうかしるし。 そうだとすれば、サーバがaとして追加データを送るなら、挑戦してください。
Melnikov & Zeilenga Standards Track [Page 16] RFC 4422 SASL June 2006
メリニコフとZeilenga規格はSASL2006年6月にRFC4422を追跡します[16ページ]。
specification MUST indicate that the response to this challenge
is an empty response.
仕様は、この挑戦への応答が空の応答であることを示さなければなりません。
SASL mechanisms SHOULD be designed to minimize the number of
challenges and responses necessary to complete the exchange.
SASLメカニズムSHOULD、設計されていて、交換を終了するのに必要な挑戦と応答の数を最小にしてください。
3) An indication of whether the mechanism is capable of transferring
authorization identity strings (see Section 3.4.1). While some
legacy mechanisms are incapable of transmitting an authorization
identity (which means that for these mechanisms, the authorization
identity is always the empty string), newly defined mechanisms
SHOULD be capable of transferring authorization identity strings.
The mechanism SHOULD NOT be capable of transferring both no
authorization identity string and an empty authorization identity.
3) メカニズムが承認アイデンティティストリングを移すことができるかどうか(セクション3.4.1を見てください)しるし。 いくつかのレガシーメカニズムが承認のアイデンティティ(承認のアイデンティティがいつもこれらのメカニズムのための、空のストリングであることを意味する)を伝えることができないで、新たに定義されたメカニズムSHOULDですが、承認アイデンティティストリングを移すことができてください。 メカニズムSHOULD NOT、承認アイデンティティストリングがなくて空の承認のアイデンティティの両方を移すことができてください。
Mechanisms that are capable of transferring an authorization
identity string MUST be capable of transferring arbitrary non-
empty sequences of Unicode characters, excluding those that
contain the NUL (U+0000) character. Mechanisms SHOULD use the
UTF-8 [RFC3629] transformation format. The specification MUST
detail how any Unicode code points special to the mechanism that
might appear in the authorization identity string are escaped to
avoid ambiguity during decoding of the authorization identity
string. Typically, mechanisms that have special characters
require these special characters to be escaped or encoded in the
character string (after encoding it in a particular Unicode
transformation format) using a data encoding scheme such as Base64
[RFC3548].
承認アイデンティティストリングを移すことができるメカニズムはユニコード文字の任意の非空の系列を移すことができなければなりません、NUL(U+0000)キャラクタを含むものを除いて。 メカニズムSHOULDはUTF-8[RFC3629]変換形式を使用します。 仕様は承認のアイデンティティに現れるかもしれないメカニズムに特別なポイントが結ぶどんなユニコードコードも承認アイデンティティストリングを解読している間、あいまいさを避けるためにどう逃げられるかを詳しく述べなければなりません。 通常、特殊文字を持っているメカニズムは、これらの特殊文字が文字列(特定のユニコード変換形式でそれをコード化した後の)で逃げられるか、またはコード化されるのをBase64[RFC3548]などのzデータの符号化体系を使用することで必要とします。
4) The specification MUST detail whether the mechanism offers a
security layer. If the mechanism does, the specification MUST
detail the security and other services offered in the layer as
well as how these services are to be implemented.
4) 仕様は、メカニズムがセキュリティ層を提供するかどうかを詳しく述べなければなりません。 メカニズムがそうするなら、仕様はどう実装されるかこれらのサービスがことであると同様に層の中で提供されたセキュリティと他のサービスを詳しく述べなければなりません。
5) If the underlying cryptographic technology used by a mechanism
supports data integrity, then the mechanism specification MUST
integrity protect the transmission of an authorization identity
and the negotiation of the security layer.
5) 基本的な暗号化技術であるなら、次に、サポートデータ保全、メカニズム仕様がそうしなければならないメカニズムによって使用されて、保全は承認のアイデンティティの送信とセキュリティ層の交渉を保護します。
SASL mechanisms SHOULD be protocol neutral.
SASLメカニズムSHOULD、プロトコル中立になってください。
SASL mechanisms SHOULD reuse existing credential and identity forms, as well as associated syntaxes and semantics.
SASLメカニズムSHOULDは既存の資格証明書を再利用します、そして、アイデンティティは関連構文と意味論と同様に形成されます。
SASL mechanisms SHOULD use the UTF-8 transformation format [RFC3629] for encoding Unicode [Unicode] code points for transfer.
SASLメカニズムSHOULDは、転送のためにユニコード[ユニコード]コード・ポイントをコード化するのに、UTF-8変換形式[RFC3629]を使用します。
Melnikov & Zeilenga Standards Track [Page 17] RFC 4422 SASL June 2006
メリニコフとZeilenga規格はSASL2006年6月にRFC4422を追跡します[17ページ]。
In order to avoid interoperability problems due to differing normalizations, when a mechanism calls for character data (other than the authorization identity string) to be used as input to a cryptographic and/or comparison function, the specification MUST detail precisely how and where (client or server) the character data is to be prepared, including all normalizations, for input into the function to ensure proper operation.
異なった正常化のため、メカニズムが、暗号である、そして/または、比較機能に入力されるようにキャラクタデータ(承認アイデンティティストリングを除いた)が使用されるように求めるとき、相互運用性問題を避けるために、仕様は、(クライアントかサーバ)キャラクタデータが正確にどのように、どこで準備されているかことであることを詳しく述べなければなりません、機能への入力が適切な操作を確実にするようにすべての正常化を含んでいて。
For simple user names and/or passwords in authentication credentials, SASLprep [RFC4013] (a profile of the StringPrep [RFC3454] preparation algorithm), SHOULD be specified as the preparation algorithm.
簡単なユーザ名、そして/または、認証資格証明書におけるパスワード、SASLprep[RFC4013](StringPrep[RFC3454]準備アルゴリズムのプロフィール)、SHOULDに、準備アルゴリズムとして指定されてください。
The mechanism SHOULD NOT use the authorization identity string in generation of any long-term cryptographic keys or hashes as there is no requirement that the authorization identity string be canonical. Long-term, here, means a term longer than the duration of the authentication exchange in which they were generated. That is, as different clients (of the same or different protocol) may provide different authorization identity strings that are semantically equivalent, use of authorization identity strings in generation of cryptographic keys and hashes will likely lead to interoperability and other problems.
承認アイデンティティストリングが正準であるという要件が全くなくて、メカニズムSHOULD NOTはどんな長期の暗号化キーやハッシュの世代にも承認アイデンティティストリングを使用します。 長期的であることで、ここと、認証の持続時間より長い手段a期間はそれらが生成されたコネを交換します。 すなわち、異なったクライアント(同じであるか異なったプロトコルの)が意味的に同等な異なった承認アイデンティティストリングを提供するかもしれないのに従って、暗号化キーとハッシュの世代における承認アイデンティティストリングの使用はおそらく相互運用性と他の問題を引き起こすでしょう。
6. Security Considerations
6. セキュリティ問題
Security issues are discussed throughout this memo.
このメモ中で安全保障問題について議論します。
Many existing SASL mechanisms do not provide adequate protection against passive attacks, let alone active attacks, in the authentication exchange. Many existing SASL mechanisms do not offer security layers. It is hoped that future SASL mechanisms will provide strong protection against passive and active attacks in the authentication exchange, as well as security layers with strong basic data security features (e.g., data integrity and data confidentiality) services. It is also hoped that future mechanisms will provide more advanced data security services like re-keying (see Section 6.3).
多くの既存のSASLメカニズムはまして、受け身の攻撃、認証交換における活発な攻撃に対する適切な保護を提供しません。 多くの既存のSASLメカニズムはセキュリティ層を提供しません。 将来のSASLメカニズムが認証交換における受け身の、そして、活発な攻撃に対する強い保護を提供することが望まれています、強い基礎データセキュリティ機能(例えば、データ保全とデータの機密性)サービスがあるセキュリティ層と同様に。 また、将来のメカニズムが再の合わせるような、より高度なデータ機密保護サービスを提供することが(セクション6.3を見てください)望まれています。
Regardless, the SASL framework is susceptible to downgrade attacks. Section 6.1.2 offers a variety of approaches for preventing or detecting these attacks. In some cases, it is appropriate to use data integrity protective services external to SASL (e.g., TLS) to protect against downgrade attacks in SASL. Use of external protective security services is also important when the mechanisms available do not themselves offer adequate integrity and/or confidentiality protection of the authentication exchange and/or protocol data.
不注意に、SASLフレームワークは攻撃を格下げするのにおいて影響されやすいです。 セクション6.1 .2 これらの攻撃を防ぐか、または検出するためのさまざまなアプローチを提供します。 いくつかの場合、SASLでダウングレード攻撃から守るのにSASL(例えば、TLS)への外部のデータ保全保護的なサービスを利用するのは適切です。 外部の保護的なセキュリティー・サービスの使用は認証交換、そして/または、プロトコルデータの重要でもある、利用可能なメカニズムがどんな自分たちで申し出適切な保全もしないとそして/または、秘密性保護です。
Melnikov & Zeilenga Standards Track [Page 18] RFC 4422 SASL June 2006
メリニコフとZeilenga規格はSASL2006年6月にRFC4422を追跡します[18ページ]。
6.1. Active Attacks
6.1. 活発な攻撃
6.1.1. Hijack Attacks
6.1.1. ハイジャック攻撃
When the client selects a SASL security layer with at least integrity protection, this protection serves as a counter-measure against an active attacker hijacking the connection and modifying protocol data sent after establishment of the security layer. Implementations SHOULD close the connection when the security services in a SASL security layer report protocol data report lack of data integrity.
クライアントが少なくとも保全保護があるSASLセキュリティ層を選択するとき、セキュリティの設立が層にされた後に接続をハイジャックして、プロトコルデータを変更する活発な攻撃者に対する対応策が発信したので、この保護は役立ちます。 SASLセキュリティ層におけるセキュリティー・サービスがプロトコルデータレポート資料不足保全を報告するとき、実装SHOULDは接続を終えます。
6.1.2. Downgrade Attacks
6.1.2. ダウングレード攻撃
It is important that any security-sensitive protocol negotiations be performed after installation of a security layer with data integrity protection. Protocols should be designed such that negotiations performed prior to this installation should be revalidated after installation is complete. Negotiation of the SASL mechanism is security sensitive.
どんなセキュリティ敏感な議定書交渉もデータ保全保護によるセキュリティ層のインストールの後に実行されるのは、重要です。 プロトコルは、インストールが完全になった後にこのインストールの前に実行された交渉が再有効にされるべきであるように、設計されるべきです。 SASLメカニズムの交渉はセキュリティ敏感です。
When a client negotiates the authentication mechanism with the server and/or other security features, it is possible for an active attacker to cause a party to use the least secure security services available. For instance, an attacker can modify the server-advertised mechanism list or can modify the client-advertised security feature list within a mechanism response. To protect against this sort of attack, implementations SHOULD NOT advertise mechanisms and/or features that cannot meet their minimum security requirements, SHOULD NOT enter into or continue authentication exchanges that cannot meet their minimum security requirements, and SHOULD verify that completed authentication exchanges result in security services that meet their minimum security requirements. Note that each endpoint needs to independently verify that its security requirements are met.
クライアントがサーバ、そして/または、他のセキュリティ機能と認証機構を交渉するとき、活発な攻撃者がパーティーに利用可能な最も安全でないセキュリティー・サービスを使用させるのは、可能です。 例えば、攻撃者は、サーバで広告を出しているメカニズムリストを変更できるか、またはメカニズム応答の中でクライアントによって広告を出されたセキュリティ特徴リストを変更できます。 この種類の攻撃から守るために、実装SHOULD NOTはそれらの最小のセキュリティ必要条件を満たすことができないメカニズム、そして/または、特徴の広告を出します、そして、SHOULD NOTはそれらの最小のセキュリティ必要条件を満たすことができない認証交換を、入るか、または続けています、そして、SHOULDは完成した認証交換がそれらの最小のセキュリティ必要条件を満たすセキュリティー・サービスをもたらすことを確かめます。 各終点が、セキュリティ必要条件が満たされることを独自に確かめる必要に注意してください。
In order to detect downgrade attacks to the least (or less) secure mechanism supported, the client can discover the SASL mechanisms that the server makes available both before the SASL authentication exchange and after the negotiated SASL security layer (with at least data integrity protection) has been installed through the protocol's mechanism discovery facility. If the client finds that the integrity-protected list (the list obtained after the security layer was installed) contains a stronger mechanism than those in the previously obtained list, the client should assume that the previously obtained list was modified by an attacker and SHOULD close the underlying transport connection.
最少(それほど)安全なメカニズムに対する攻撃がサポートしたダウングレードを検出するために、ともにSASL認証交換の前と交渉されたSASLセキュリティ層(少なくともデータ保全保護がある)がプロトコルのメカニズム発見施設でインストールされた後にクライアントはサーバが利用可能にするSASLメカニズムを発見できます。 クライアントが、保全で保護されたリスト(セキュリティ層がインストールされた後に得られたリスト)が以前に得られたリストのそれらより強いメカニズムを入れてあるのがわかるなら、クライアントは、以前に得られたリストが攻撃者によって変更されて、SHOULDが基本的な輸送接続を終えると仮定するべきです。
The client's initiation of the SASL exchange, including the selection of a SASL mechanism, is done in the clear and may be modified by an
SASLメカニズムの選択を含むクライアントのSASL交換の開始を、明確でして、変更するかもしれません。
Melnikov & Zeilenga Standards Track [Page 19] RFC 4422 SASL June 2006
メリニコフとZeilenga規格はSASL2006年6月にRFC4422を追跡します[19ページ]。
active attacker. It is important for any new SASL mechanisms to be designed such that an active attacker cannot obtain an authentication with weaker security properties by modifying the SASL mechanism name and/or the challenges and responses.
活発な攻撃者。 どんな新しいSASLメカニズムも設計されているのは、活発な攻撃者がSASLメカニズム名、そして/または、挑戦と応答を変更することによって、より弱いセキュリティの特性による認証を得ることができないくらい重要です。
Multi-level negotiation of security features is prone to downgrade attack. Protocol designers should avoid offering higher-level negotiation of security features in protocols (e.g., above SASL mechanism negotiation) and mechanism designers should avoid lower- level negotiation of security features in mechanisms (e.g., below SASL mechanism negotiation).
セキュリティ機能のマルチレベル交渉は攻撃を格下げする傾向があります。 プロトコルデザイナーは、プロトコル(例えば、SASLメカニズム交渉を超えた)における、セキュリティ機能の、よりハイレベルの交渉を提供するのを避けるべきです、そして、メカニズムデザイナーはメカニズム(例えば、SASLメカニズム交渉の下における)における、セキュリティ機能の下側の平らな交渉を避けるべきです。
6.1.3. Replay Attacks
6.1.3. 反射攻撃
Some mechanisms may be subject to replay attacks unless protected by external data security services (e.g., TLS).
外部のデータ機密保護サービス(例えば、TLS)で保護されない場合、いくつかのメカニズムが反射攻撃を受けることがあるかもしれません。
6.1.4. Truncation Attacks
6.1.4. トランケーション攻撃
Most existing SASL security layers do not themselves offer protection against truncation attack. In a truncation attack, the active attacker causes the protocol session to be closed, causing a truncation of the possibly integrity-protected data stream that leads to behavior of one or both the protocol peers that inappropriately benefits the attacker. Truncation attacks are fairly easy to defend against in connection-oriented application-level protocols. A protocol can defend against these attacks by ensuring that each information exchange has a clear final result and that each protocol session has a graceful closure mechanism, and that these are integrity protected.
ほとんどの既存のSASLセキュリティ層がトランケーション攻撃に対する申し出保護を自分たちにするというわけではありません。 トランケーション攻撃では、活発な攻撃者はプロトコルセッションを終えさせます、不適当に攻撃者のためになる1の振舞いにつながることによると保全で保護されたデータ・ストリームかプロトコル同輩の両方のトランケーションを引き起こして。 トランケーション攻撃は接続指向のアプリケーションレベルプロトコルでかなり防御しやすいです。 各情報交換には明確な最終的な結果があるのを確実にすることによって、プロトコルはこれらの攻撃に対して防御されることができるでしょう、そして、それぞれのプロトコルセッションには優雅な閉鎖メカニズムがあって、これらが保全であることは保護されました。
6.1.5. Other Active Attacks
6.1.5. 他の活発な攻撃
When use of a security layer is negotiated by the authentication protocol exchange, the receiver SHOULD handle gracefully any protected data buffer larger than the defined/negotiated maximal size. In particular, it MUST NOT blindly allocate the amount of memory specified in the buffer size field, as this might cause the "out of memory" condition. If the receiver detects a large block, it SHOULD close the connection.
セキュリティ層の使用が認証プロトコル交換で交渉されるとき、受信機SHOULDは優雅に定義されたか交渉された最大限度のサイズより大きい状態で保護されたデータがバッファリングするいずれも扱います。 特に、盲目的にバッファサイズ分野で指定されたメモリー容量を割り当ててはいけません、これが「メモリ」状態を引き起こすかもしれないとき。 受信機は大量株を検出して、それはSHOULDです。接続を終えてください。
6.2. Passive Attacks
6.2. 受け身の攻撃
Many mechanisms are subject to various passive attacks, including simple eavesdropping of unprotected credential information as well as online and offline dictionary attacks of protected credential information.
多くのメカニズムが様々な受け身の攻撃を受けることがあります、保護された資格証明情報のオンラインの、そして、オフラインの辞書攻撃と同様に保護のない資格証明情報の簡単な盗聴を含んでいて。
Melnikov & Zeilenga Standards Track [Page 20] RFC 4422 SASL June 2006
メリニコフとZeilenga規格はSASL2006年6月にRFC4422を追跡します[20ページ]。
6.3. Re-keying
6.3. 再の合わせること
The secure or administratively permitted lifetimes of SASL mechanisms' security layers are finite. Cryptographic keys weaken as they are used and as time passes; the more time and/or cipher-text that a cryptanalyst has after the first use of the a key, the easier it is for the cryptanalyst to mount attacks on the key.
SASLメカニズムのセキュリティ層の安全であるか行政上受入れられた寿命は有限です。 それらが使用されていて、時間が経過するのに従って、暗号化キーは弱ります。 そのa暗号解読者がaキーの最初の使用の後に持っている時間、そして/または、暗号文が多ければ多いほど、それは暗号解読者がキーに対する攻撃をより仕掛けやすいです。
Administrative limits on a security layer's lifetime may take the form of time limits expressed in X.509 certificates, in Kerberos V tickets, or in directories, and are often desired. In practice, one likely effect of administrative lifetime limits is that applications may find that security layers stop working in the middle of application protocol operation, such as, perhaps, during large data transfers. As the result of this, the connection will be closed (see Section 3.7), which will result in an unpleasant user experience.
セキュリティ層の生涯における管理限界は、ケルベロスVチケットの中、または、X.509証明書か、ディレクトリで言い表されたタイムリミットの形を取るかもしれなくて、しばしば望まれています。 実際には、管理生涯限界の1つのありそうな効果はアプリケーションが、セキュリティ層がアプリケーション・プロトコル操作の途中で仕事を中止するのがわかるかもしれないということです、恐らく大きいデータ転送などのように。 この結果として、接続(不快なユーザー・エクスペリエンスをもたらす)は閉店するでしょう(セクション3.7を見ます)。
Re-keying (key renegotiation process) is a way of addressing the weakening of cryptographic keys. The SASL framework does not itself provide for re-keying; SASL mechanisms may. Designers of future SASL mechanisms should consider providing re-keying services.
(主要な再交渉プロセス)を再合わせるのは、暗号化キーの弱化を扱う方法です。 それ自体ではなく、フレームワークがするSASLが再の合わせることに備えます。 SASLメカニズムはそうするかもしれません。 将来のSASLメカニズムのデザイナーは、サービスを再合わせながら提供すると考えるべきです。
Implementations that wish to re-key SASL security layers where the mechanism does not provide for re-keying SHOULD reauthenticate the same IDs and replace the expired or soon-to-expire security layers. This approach requires support for reauthentication in the application protocols (see Section 3.8).
メカニズムが同じようにSHOULD reauthenticateを再合わせIDに備えない再主要なSASLセキュリティ層に願って、満期の、または、すぐ吐き出しているセキュリティ層を取り替える実装。 このアプローチは再認証にアプリケーション・プロトコルで支持を要します(セクション3.8を見てください)。
6.4. Other Considerations
6.4. 他の問題
Protocol designers and implementors should understand the security considerations of mechanisms so they may select mechanisms that are applicable to their needs.
プロトコルデザイナーと作成者がメカニズムのセキュリティ問題を理解するべきであるので、彼らは彼らの必要性に適切なメカニズムを選択するかもしれません。
Distributed server implementations need to be careful in how they trust other parties. In particular, authentication secrets should only be disclosed to other parties that are trusted to manage and use those secrets in a manner acceptable to the disclosing party. Applications using SASL assume that SASL security layers providing data confidentiality are secure even when an attacker chooses the text to be protected by the security layer. Similarly, applications assume that the SASL security layer is secure even if the attacker can manipulate the cipher-text output of the security layer. New SASL mechanisms are expected to meet these assumptions.
分配されたサーバ実装は、彼らがどう相手を信じるかで慎重である必要があります。 特に、認証秘密は明らかにするパーティーにおいて、許容できる方法でそれらの秘密を管理して、使用すると信じられる相手に明らかにされるだけであるべきです。 SASLを使用するアプリケーションは、攻撃者がセキュリティ層によって保護されるためにテキストを選ぶときさえ、データの機密性を提供するSASLセキュリティ層が安全であると仮定します。 同様に、アプリケーションは、攻撃者がセキュリティ層の暗号文出力を操作できてもSASLセキュリティ層が安全であると仮定します。 新しいSASLメカニズムがこれらの仮定を満たすと予想されます。
Melnikov & Zeilenga Standards Track [Page 21] RFC 4422 SASL June 2006
メリニコフとZeilenga規格はSASL2006年6月にRFC4422を追跡します[21ページ]。
Unicode security considerations [UTR36] apply to authorization identity strings, as well as UTF-8 [RFC3629] security considerations where UTF-8 is used. SASLprep [RFC4013] and StringPrep [RFC3454] security considerations also apply where used.
ユニコードセキュリティ問題[UTR36]はUTF-8が使用されている承認アイデンティティストリング、およびUTF-8[RFC3629]セキュリティ問題に適用されます。 また、SASLprep[RFC4013]とStringPrep[RFC3454]セキュリティ問題は使用されるところで適用されます。
7. IANA Considerations
7. IANA問題
7.1. SASL Mechanism Registry
7.1. SASLメカニズム登録
The SASL mechanism registry is maintained by IANA. The registry is currently available at <http://www.iana.org/assignments/sasl- mechanisms>.
SASLメカニズム登録はIANAによって維持されます。 登録は現在、<http://www.iana.org/課題/saslメカニズム>で利用可能です。
The purpose of this registry is not only to ensure uniqueness of values used to name SASL mechanisms, but also to provide a definitive reference to technical specifications detailing each SASL mechanism available for use on the Internet.
この登録の目的は値のユニークさが以前はよくSASLメカニズムを命名していたのを単に保証するのではなく、インターネットにおける使用に利用可能なそれぞれのSASLメカニズムについて詳述する技術仕様書に決定的な参照を提供もすることです。
There is no naming convention for SASL mechanisms; any name that conforms to the syntax of a SASL mechanism name can be registered.
SASLのためのコンベンションをメカニズムと命名してはいけません。 SASLメカニズム名の構文に従うどんな名前も登録できます。
The procedure detailed in Section 7.1.1 is to be used for registration of a value naming a specific individual mechanism.
セクション7.1.1で詳細な手順は特定の個々のメカニズムを命名する価値の登録に使用されることです。
The procedure detailed in Section 7.1.2 is to be used for registration of a value naming a family of related mechanisms.
セクション7.1.2で詳細な手順は関連するメカニズムのファミリーを命名する価値の登録に使用されることです。
Comments may be included in the registry as discussed in Section 7.1.3 and may be changed as discussed in Section 7.1.4.
コメントをセクション7.1.3で議論するように登録に含んで、セクション7.1.4で議論するように変えるかもしれません。
The SASL mechanism registry has been updated to reflect that this document provides the definitive technical specification for SASL and that this section provides the registration procedures for this registry.
このドキュメントがSASLに、決定的な技術仕様書を提供して、このセクションが登録手順をこの登録に提供するのを反映するためにSASLメカニズム登録をアップデートしました。
Melnikov & Zeilenga Standards Track [Page 22] RFC 4422 SASL June 2006
メリニコフとZeilenga規格はSASL2006年6月にRFC4422を追跡します[22ページ]。
7.1.1. Mechanism Name Registration Procedure
7.1.1. メカニズム名前登録手順
IANA will register new SASL mechanism names on a First Come First Served basis, as defined in BCP 26 [RFC2434]. IANA has the right to reject obviously bogus registration requests, but will perform no review of claims made in the registration form.
IANAはBCP26[RFC2434]で定義されるようにFirst Come First Servedベースに新しいSASLメカニズム名を登録するでしょう。 IANAは明らかににせの登録要求を拒絶する権利を持っていますが、登録用紙でされたクレームのレビューを全く実行しないでしょう。
Registration of a SASL mechanism is requested by filling in the following template:
SASLメカニズムの登録は以下のテンプレートに記入することによって、要求されています:
Subject: Registration of SASL mechanism X
Subject: SASLメカニズムXの登録
SASL mechanism name (or prefix for the family):
SASLメカニズム名(または、ファミリーのための接頭語):
Security considerations:
セキュリティ問題:
Published specification (recommended):
広められた仕様(お勧めの):
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス:
Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE)
意図している用法: (1つ、コモン使用、または時代遅れで制限されて、
Owner/Change controller:
所有者/変化コントローラ:
Note: (Any other information that the author deems relevant may be
added here.)
以下に注意してください。 (作者が関連していると考えるいかなる他の情報もここで加えられるかもしれません。)
and sending it via electronic mail to IANA at <iana@iana.org>.
IANA at <iana@iana.org への電子メールを通してそれを送る、gt。
While this registration procedure does not require expert review, authors of SASL mechanisms are encouraged to seek community review and comment whenever that is feasible. Authors may seek community review by posting a specification of their proposed mechanism as an Internet-Draft. SASL mechanisms intended for widespread use should be standardized through the normal IETF process, when appropriate.
この登録手順が専門のレビューを必要としていない間、それが可能であるときはいつも、SASLメカニズムの作者が共同体レビューとコメントを求めるよう奨励されます。 作者は、インターネット草稿として彼らの提案されたメカニズムの仕様を掲示することによって、共同体レビューを求めるかもしれません。 適切であるときに、普及使用のために意図するSASLメカニズムは正常なIETFプロセスを通して標準化されるべきです。
Melnikov & Zeilenga Standards Track [Page 23] RFC 4422 SASL June 2006
メリニコフとZeilenga規格はSASL2006年6月にRFC4422を追跡します[23ページ]。
7.1.2. Family Name Registration Procedure
7.1.2. 姓の登録手順
As noted above, there is no general naming convention for SASL mechanisms. However, specifications may reserve a portion of the SASL mechanism namespace for a set of related SASL mechanisms, a "family" of SASL mechanisms. Each family of SASL mechanisms is identified by a unique prefix, such as X-. Registration of new SASL mechanism family names requires expert review as defined in BCP 26 [RFC2434].
SASLメカニズムの各ファミリーはユニークな接頭語によって特定されます、しかしながら、仕様が1セットの関連するSASLメカニズム(SASLの「ファミリー」メカニズム)のためにSASLメカニズム名前空間の部分を予約するかもしれなくて、Xなどのように。上で述べたように、SASLメカニズムのためのどんな一般的な命名規則もありません。新しいSASLメカニズム姓の登録はBCP26[RFC2434]で定義されるように専門のレビューを必要とします。
Registration of a SASL family name is requested by filling in the following template:
SASL姓の登録は以下のテンプレートに記入することによって、要求されています:
Subject: Registration of SASL mechanism family X
Subject: SASLメカニズムファミリーXの登録
SASL family name (or prefix for the family):
SASL姓(または、ファミリーのための接頭語):
Security considerations:
セキュリティ問題:
Published specification (recommended):
広められた仕様(お勧めの):
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス:
Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE)
意図している用法: (1つ、コモン使用、または時代遅れで制限されて、
Owner/Change controller:
所有者/変化コントローラ:
Note: (Any other information that the author deems relevant may be
added here.)
以下に注意してください。 (作者が関連していると考えるいかなる他の情報もここで加えられるかもしれません。)
and sending it via electronic mail to the IETF SASL mailing list at <ietf-sasl@imc.org> and carbon copying IANA at <iana@iana.org>. After allowing two weeks for community input on the IETF SASL mailing list, the expert will determine the appropriateness of the registration request and either approve or disapprove the request with notice to the requestor, the mailing list, and IANA.
IETF SASLメーリングリスト at <ietf-sasl@imc.org への電子メールを通してそれを送る、gt;、IANA at <iana@iana.org をコピーする炭素、gt。 2週間IETF SASLメーリングリストに関する共同体入力を考慮した後に、専門家は、通知で要請者、メーリングリスト、およびIANAに要求を登録要求の適切さを決定して、承認するか、または不可とするでしょう。
The review should focus on the appropriateness of the requested family name for the proposed use and the appropriateness of the proposed naming and registration plan for existing and future mechanism names in the family. The scope of this request review may entail consideration of relevant aspects of any provided technical specification, such as their IANA Considerations section. However, this review is narrowly focused on the appropriateness of the requested registration and not on the overall soundness of any provided technical specification.
レビューは提案された使用のための要求された姓の適切さと存在するための提案された命名と登録プランとファミリーにおける将来のメカニズム名の適切さに焦点を合わせるべきです。 この要求レビューの範囲はどんな提供された技術仕様書の関連局面の考慮も伴うかもしれません、それらのIANA Considerations部などのように。 しかしながら、このレビューは狭くどんな提供された技術仕様書の総合的な健全さではなく、要求された登録の適切さにも焦点を合わせられます。
Melnikov & Zeilenga Standards Track [Page 24] RFC 4422 SASL June 2006
メリニコフとZeilenga規格はSASL2006年6月にRFC4422を追跡します[24ページ]。
Authors are encouraged to pursue community review by posting the technical specification as an Internet-Draft and soliciting comment by posting to appropriate IETF mailing lists.
作者がインターネット草稿として技術仕様書を掲示して、適切なIETFにメーリングリストを掲示することによってコメントに請求することによって共同体レビューを追求するよう奨励されます。
7.1.3. Comments on SASL Mechanism Registrations
7.1.3. SASLメカニズム登録証明書のコメント
Comments on a registered SASL mechanism/family should first be sent to the "owner" of the mechanism/family and/or to the <ietf- sasl@imc.org> mailing list.
最初にメカニズム/ファミリーの「所有者」<ietf- sasl@imc.org に登録されたSASLメカニズム/ファミリーのコメントを送るべきである、gt;、メーリングリスト。
Submitters of comments may, after a reasonable attempt to contact the owner, request IANA to attach their comment to the SASL mechanism registration itself by sending mail to <iana@iana.org>. At IANA's sole discretion, IANA may attach the comment to the SASL mechanism's registration.
コメントのSubmittersが、所有者に連絡する合理的な試みの後にメール to <iana@iana.org を送ることによってSASLメカニズム登録自体に彼らのコメントを付けるようIANAに要求するかもしれない、gt。 IANAの唯一の裁量では、IANAはSASLメカニズムの登録にコメントを付けるかもしれません。
7.1.4. Change Control
7.1.4. 変化コントロール
Once a SASL mechanism registration has been published by IANA, the author may request a change to its definition. The change request follows the same procedure as the registration request.
SASLメカニズム登録がIANAによっていったん発行されると、作者は定義への変化を要求するかもしれません。 変更要求は登録要求と同じ手順に従います。
The owner of a SASL mechanism may pass responsibility for the SASL mechanism to another person or agency by informing IANA; this can be done without discussion or review.
SASLメカニズムの所有者はIANAに知らせることによって、SASLメカニズムへの責任を別の人か政府機関に渡すかもしれません。 議論もレビューなしでこれができます。
The IESG may reassign responsibility for a SASL mechanism. The most common case of this will be to enable changes to be made to mechanisms where the author of the registration has died, has moved out of contact, or is otherwise unable to make changes that are important to the community.
IESGはSASLメカニズムへの責任を再選任するかもしれません。 この最も一般的なケースは、変更を登録の作者が死んだメカニズムにするのを可能にするためにあるか、接触から引っ越したか、またはそうでなければ、共同体に重要な変更を行うことができません。
SASL mechanism registrations may not be deleted; mechanisms that are no longer believed appropriate for use can be declared OBSOLETE by a change to their "intended usage" field; such SASL mechanisms will be clearly marked in the lists published by IANA.
SASLメカニズム登録証明書は削除されないかもしれません。 それらの「意図している用法」分野への変化はOBSOLETEであるともう使用に適切であることは信じられていないメカニズムを申告できます。 そのようなSASLメカニズムはIANAによって発表されたリストで明確にマークされるでしょう。
The IESG is considered to be the owner of all SASL mechanisms that are on the IETF standards track.
IESGはIETF標準化過程の上にあるすべてのSASLメカニズムの所有者であると考えられます。
Melnikov & Zeilenga Standards Track [Page 25] RFC 4422 SASL June 2006
メリニコフとZeilenga規格はSASL2006年6月にRFC4422を追跡します[25ページ]。
7.2. Registration Changes
7.2. 登録変化
The IANA has updated the SASL mechanisms registry as follows:
IANAは以下のSASLメカニズム登録をアップデートしました:
1) Changed the "Intended usage" of the KERBEROS_V4 and SKEY mechanism
registrations to OBSOLETE.
1) ケルベロス_V4とSKEYメカニズム登録証明書の「意図している用法」をOBSOLETEに変えました。
2) Changed the "Published specification" of the EXTERNAL mechanism to
this document as indicated below:
2) 以下に示すようにEXTERNALメカニズムの「広められた仕様」をこのドキュメントに変えます:
Subject: Updated Registration of SASL mechanism EXTERNAL
Family of SASL mechanisms: NO
SASL mechanism name: EXTERNAL
Security considerations: See A.3 of RFC 4422
Published specification (optional, recommended): RFC 4422
Person & email address to contact for further information:
Alexey Melnikov <Alexey.Melnikov@isode.com>
Intended usage: COMMON
Owner/Change controller: IESG <iesg@ietf.org>
Note: Updates existing entry for EXTERNAL
Subject: SASLメカニズムのSASLメカニズムEXTERNAL FamilyのアップデートされたRegistration: NO SASLメカニズム名: EXTERNAL Security問題: RFC4422Published仕様のA.3が(任意で、お勧め)であると見てください: 詳細のために連絡するRFC4422PersonとEメールアドレス: Alexey Melnikov <Alexey.Melnikov@isode.com 、gt;、意図している用法: COMMON Owner/変化コントローラ: IESG <iesg@ietf.org 、gt;、注意: EXTERNALのために既存のエントリーをアップデートします。
8. References
8. 参照
8.1. Normative References
8.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月。
[RFC2244] Newman, C. and J. G. Myers, "ACAP -- Application
Configuration Access Protocol", RFC 2244, November
1997.
[RFC2244] ニューマン、C.、およびJ.G.マイアーズ、「ACAP--アプリケーション構成アクセスは議定書を作る」、RFC2244、11月1997日
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, RFC
2434, October 1998.
[RFC2434]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2743] リン、J.、「ジェネリックセキュリティー・サービス適用業務プログラム・インタフェースバージョン2、アップデート1インチ、RFC2743、2000年1月。」
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings ("stringprep")", RFC 3454,
December 2002.
[RFC3454] ホフマンとP.とM.Blanchet、「国際化しているストリング("stringprep")の準備」、RFC3454、2002年12月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau、F.、「UTF-8、ISO10646の変換形式」STD63、RFC3629、11月2003日
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User
Names and Passwords", RFC 4013, February 2005.
[RFC4013]Zeilenga、K.、「SASLprep:」 「ユーザ名とパスワードのためのStringprepプロフィール」、RFC4013、2005年2月。
Melnikov & Zeilenga Standards Track [Page 26] RFC 4422 SASL June 2006
メリニコフとZeilenga規格はSASL2006年6月にRFC4422を追跡します[26ページ]。
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[RFC4234] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。
[ASCII] Coded Character Set--7-bit American Standard Code for
Information Interchange, ANSI X3.4-1986.
[ASCII]は文字コードをコード化しました--7ビットの情報交換用米国標準コード、ANSI X3.4-1986。
[Unicode] The Unicode Consortium, "The Unicode Standard, Version
3.2.0" is defined by "The Unicode Standard, Version
3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-
61633-5), as amended by the "Unicode Standard Annex
#27: Unicode 3.1"
(http://www.unicode.org/reports/tr27/) and by the
"Unicode Standard Annex #28: Unicode 3.2"
(http://www.unicode.org/reports/tr28/).
[ユニコード] ユニコードConsortium、「ユニコード規格、バージョン、3.2、0インチ、定義される、「ユニコード規格、修正されるバージョン3インチ(読書、MA、アディソン-ウエスリー、2000ISBN0-201- 61633-5)、「ユニコード規格別館#27:」 「ユニコード規格別館#28:」 ユニコード3.2インチ( http://www.unicode.org/reports/tr28/ )。
[CharModel] Whistler, K. and M. Davis, "Unicode Technical Report
#17, Character Encoding Model", UTR17,
<http://www.unicode.org/unicode/reports/tr17/>, August
2000.
[CharModel] ウィスラーとK.とM.デイヴィス、「ユニコード技術報告書#17、文字符号化モデル」、UTR17、<は://www.unicode.org/unicode/reports/tr17/>をhttpして、8月は2000です。
[Glossary] The Unicode Consortium, "Unicode Glossary",
<http://www.unicode.org/glossary/>.
[用語集] ユニコード共同体、「ユニコード用語集」、<http://www.unicode.org/glossary/>。
8.2. Informative References
8.2. 有益な参照
[RFC3206] Gellens, R., "The SYS and AUTH POP Response Codes", RFC
3206, February 2002.
[RFC3206] Gellens、R.、「SYSとAUTHは応答コードを飛び出す」RFC3206、2002年2月。
[RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 3548, July 2003.
[RFC3548]Josefsson、2003年7月のS.、「Base16、Base32、およびBase64データEncodings」RFC3548。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4301] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.1", RFC 4346, April
2006.
[RFC4346] Dierks、T.、およびE.レスコラ、「トランスポート層セキュリティ(TLS)は2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。
[SASL-GSSAPI] Melnikov, A. (Editor), "The Kerberos V5 ("GSSAPI") SASL
Mechanism", Work in Progress, May 2006.
[SASL-GSSAPI]メリニコフ、A.(エディタ)、「ケルベロスV5("GSSAPI")SASLメカニズム」が進歩、2006年5月に働いています。
[UTR36] Davis, M., "(Draft) Unicode Technical Report #36,
Character Encoding Model", UTR17,
<http://www.unicode.org/unicode/reports/tr36/>,
February 2005.
[UTR36] デイヴィス、M.、「(草稿)ユニコード技術報告書#36、文字符号化モデル」、UTR17、<は://www.unicode.org/unicode/reports/tr36/>をhttpして、2月は2005です。
[CRAM-MD5] Nerenberg, L., "The CRAM-MD5 SASL Mechanism", Work in
Progress.
[一夜漬け-MD5] ネーレンバーグ、L.、「一夜漬け-MD5 SASLメカニズム」が進行中で働いています。
Melnikov & Zeilenga Standards Track [Page 27] RFC 4422 SASL June 2006
メリニコフとZeilenga規格はSASL2006年6月にRFC4422を追跡します[27ページ]。
[DIGEST-MD5] Leach, P., C. Newman, and A. Melnikov, "Using Digest
Authentication as a SASL Mechanism", Work in Progress,
March 2006.
[ダイジェスト-MD5] 「SASLメカニズムとしてダイジェスト認証を使用し」て、リーチ、P.、C.ニューマン、およびA.メリニコフは進歩、2006年3月に働いています。
9. Acknowledgements
9. 承認
This document is a revision of RFC 2222 written by John Myers.
このドキュメントはジョン・マイアーズによって書かれたRFC2222の改正です。
This revision is a product of the IETF Simple Authentication and Security Layer (SASL) Working Group.
この改正はIETF Simple AuthenticationとSecurity Layer(SASL)作業部会の製品です。
The following individuals contributed significantly to this revision: Abhijit Menon-Sen, Hallvard Furuseth, Jeffrey Hutzelman, John Myers, Luke Howard, Magnus Nystrom, Nicolas Williams, Peter Saint-Andre, RL 'Bob' Morgan, Rob Siemborski, Sam Hartman, Simon Josefsson, Tim Alsop, and Tony Hansen.
以下の個人はこの改正にかなり貢献しました: Abhijitメノン-銭、Hallvard Furuseth、ジェフリーHutzelman、ジョン・マイアーズ・ルーク・ハワード、マグヌス・ニストロム、ニコラス・ウィリアムズ、ピーターサンアンドレ、RL'ボブ'モーガンはSiemborski、サム・ハートマン、サイモンJosefsson、ティムAlsop、およびトニー・ハンセンから略奪します。
Melnikov & Zeilenga Standards Track [Page 28] RFC 4422 SASL June 2006
メリニコフとZeilenga規格はSASL2006年6月にRFC4422を追跡します[28ページ]。
Appendix A. The SASL EXTERNAL Mechanism
付録A.はSASLの外部のメカニズムです。
This appendix is normative.
この付録は規範的です。
The EXTERNAL mechanism allows a client to request the server to use credentials established by means external to the mechanism to authenticate the client. The external means may be, for instance, IP Security [RFC4301] or TLS [RFC4346] services. In absence of some a priori agreement between the client and the server, the client cannot make any assumption as to what external means the server has used to obtain the client's credentials, nor make an assumption as to the form of credentials. For example, the client cannot assume that the server will use the credentials the client has established via TLS.
EXTERNALメカニズムで、クライアントは、クライアントを認証するためにメカニズムへの外部の手段で確立された資格証明書を使用するようサーバに要求できます。 例えば、外部の手段はIP Security[RFC4301]かTLS[RFC4346]サービスであるかもしれません。 クライアントとサーバとの先験的な何らかの協定の欠如では、クライアントは、クライアントの資格証明書を得るためにサーバにはどんな外部の手段があるかに関するどんな仮定も使用されるのをして、資格証明書のフォームに関して仮定はすることができません。 例えば、クライアントは、サーバがクライアントがTLSを通して確立した資格証明書を使用すると仮定できません。
A.1. EXTERNAL Technical Specification
A.1。 外部の技術的な仕様
The name of this mechanism is "EXTERNAL".
このメカニズムの名前は「外部です」。
The mechanism does not provide a security layer.
メカニズムはセキュリティ層を提供しません。
The mechanism is capable of transferring an authorization identity string. If empty, the client is requesting to act as the identity the server has associated with the client's credentials. If non- empty, the client is requesting to act as the identity represented by the string.
メカニズムは承認アイデンティティストリングを移すことができます。 空であるなら、クライアントは、アイデンティティとしてサーバを機能させるのがクライアントの資格証明書と交際したよう要求しています。 非空であるなら、クライアントは、ストリングによって表されたアイデンティティとして機能するよう要求しています。
The client is expected to send data first in the authentication exchange. Where the client does not provide an initial response data in its request to initiate the authentication exchange, the server is to respond to the request with an empty initial challenge and then the client is to provide its initial response.
クライアントが最初に認証交換におけるデータを送ると予想されます。 サーバが空の初期の挑戦で要求に応じるクライアントが認証交換を起こすという要求における初期の応答データを提供しないところのことであり、次に、クライアントは初期の応答を提供することになっています。
The client sends the initial response containing the UTF-8 [RFC3629] encoding of the requested authorization identity string. This response is non-empty when the client is requesting to act as the identity represented by the (non-empty) string. This response is empty when the client is requesting to act as the identity the server associated with its authentication credentials.
クライアントは要求された承認アイデンティティストリングのUTF-8[RFC3629]コード化を含む初期の応答を送ります。 クライアントが、(非空)のストリングによって表されたアイデンティティとして機能するよう要求しているとき、この応答は非空です。 クライアントが、アイデンティティとして機能するように、サーバが認証資格証明書と交際したよう要求しているとき、この応答は空です。
The syntax of the initial response is specified as a value of the <extern-initial-resp> production detailed below using the Augmented Backus-Naur Form (ABNF) [RFC4234] notation.
Augmented BN記法(ABNF)を使用する下で<通いの人初期のrespの>生産の値が[RFC4234]記法を詳しく述べたので、初期の応答の構文は指定されます。
external-initial-resp = authz-id-string
authz-id-string = *( UTF8-char-no-nul )
UTF8-char-no-nul = UTF8-1-no-nul / UTF8-2 / UTF8-3 / UTF8-4
UTF8-1-no-nul = %x01-7F
外部の初期のrespはauthzイドストリングauthzイドストリング=*と%x01 7 1いいえのUTF8-4 UTF8について(UTF8はnulを全く焦げさせません)のUTF8がnulを全く焦げさせていない1いいえのUTF8について=についてnul/UTF8-2/UTF8-3/nul=F等しいです。
Melnikov & Zeilenga Standards Track [Page 29] RFC 4422 SASL June 2006
メリニコフとZeilenga規格はSASL2006年6月にRFC4422を追跡します[29ページ]。
where the <UTF8-2>, <UTF8-3>, and <UTF8-4> productions are as defined in [RFC3629].
<UTF8-2>、<UTF8-3>、および<UTF8-4>創作が[RFC3629]で定義されるようにあるところで。
There are no additional challenges and responses.
追加挑戦と応答が全くありません。
Hence, the server is to return the outcome of the authentication exchange.
したがって、サーバは認証交換の結果を返すことです。
The exchange fails if
交換は失敗します。
- the client has not established its credentials via external means,
- クライアントは外部の手段で信任状を付していません。
- the client's credentials are inadequate,
- クライアントの資格証明書は不十分です。
- the client provided an empty authorization identity string and the
server is unwilling or unable to associate an authorization
identity with the client's credentials,
- サーバは、クライアントが空の承認アイデンティティストリングを提供して、不本意であるか、または承認のアイデンティティをクライアントの資格証明書に関連づけることができません。
- the client provided a non-empty authorization identity string that
is invalid per the syntax requirements of the applicable
application protocol specification,
- クライアントは適切なアプリケーションプロトコル仕様の構文要件単位で無効の非空の承認アイデンティティストリングを提供しました。
- the client provided a non-empty authorization identity string
representing an identity that the client is not allowed to act as,
or
- またはクライアントがクライアントが行動できないアイデンティティを表す非空の承認アイデンティティストリングを提供した。
- the server is unwilling or unable to provide service to the client
for any other reason.
- サーバは、不本意であるか、またはクライアントに対するサービスをいかなる他の理由にも提供できません。
Otherwise the exchange is successful. When indicating a successful outcome, additional data is not provided.
さもなければ、交換はうまくいっています。 うまくいっている結果を示すとき、追加データは提供されません。
A.2. SASL EXTERNAL Examples
A.2。 SASLの外部の例
This section provides examples of EXTERNAL authentication exchanges. The examples are intended to help the readers understand the above text. The examples are not definitive. The Application Configuration Access Protocol (ACAP) [RFC2244] is used in the examples.
このセクションはEXTERNAL認証交換に関する例を提供します。 例が、読者が上のテキストを理解しているのを助けることを意図します。 例は決定的ではありません。 Application Configuration Accessプロトコル(ACAP)[RFC2244]は例で使用されます。
The first example shows use of EXTERNAL with an empty authorization identity. In this example, the initial response is not sent in the client's request to initiate the authentication exchange.
最初の例は空の承認のアイデンティティがあるEXTERNALの使用を示しています。 この例では、初期の応答は認証交換を起こすというクライアントの要求で送られません。
S: * ACAP (SASL "DIGEST-MD5")
C: a001 STARTTLS
S: a001 OK "Begin TLS negotiation now"
<TLS negotiation, further commands are under TLS layer>
S: * ACAP、(SASL、「ダイジェスト-MD5") C:、」 a001 STARTTLS S: TLS層の>の下にa001OK「現在のTLS交渉を始めてください」<TLS交渉、より遠いコマンドがあります。
Melnikov & Zeilenga Standards Track [Page 30] RFC 4422 SASL June 2006
メリニコフとZeilenga規格はSASL2006年6月にRFC4422を追跡します[30ページ]。
S: * ACAP (SASL "DIGEST-MD5" "EXTERNAL")
C: a002 AUTHENTICATE "EXTERNAL"
S: + ""
C: + ""
S: a002 OK "Authenticated"
S: * ACAP、(SASL、「ダイジェスト-MD5"「外部」) C:、」 a002 AUTHENTICATEの「外部」のS: +、「「C:」 +、「「S:」 OKが「認証した」a002
The second example shows use of EXTERNAL with an authorization identity of "fred@example.com". In this example, the initial response is sent with the client's request to initiate the authentication exchange. This saves a round-trip.
2番目の例は" fred@example.com "の承認のアイデンティティがあるEXTERNALの使用を示しています。 この例では、認証交換を起こすというクライアントの要求と共に初期の応答を送ります。 これは周遊旅行を保存します。
S: * ACAP (SASL "DIGEST-MD5")
C: a001 STARTTLS
S: a001 OK "Begin TLS negotiation now"
<TLS negotiation, further commands are under TLS layer>
S: * ACAP (SASL "DIGEST-MD5" "EXTERNAL")
C: a002 AUTHENTICATE "EXTERNAL" {16+}
C: fred@example.com
S: a002 NO "Cannot assume requested authorization identity"
S: * ACAP、(SASL、「ダイジェスト-MD5") C:、」 a001 STARTTLS S: TLS層の>Sの下にa001OK「現在のTLS交渉を始めてください」<TLS交渉、より遠いコマンドがあります: * ACAP、(SASL、「ダイジェスト-MD5"「外部」) C:、」 a002 AUTHENTICATE「外部」16+、C: fred@example.com S: a002ノー、は「要求された承認のアイデンティティを仮定できません」。
A.3. Security Considerations
A.3。 セキュリティ問題
The EXTERNAL mechanism provides no security protection; it is vulnerable to spoofing by either client or server, active attack, and eavesdropping. It should only be used when adequate security services have been established.
EXTERNALメカニズムは機密保持を全く提供しません。 それはクライアントかサーバのどちらか、活発な攻撃、および盗聴でスプーフィングに被害を受け易いです。 十分な安全性サービスが確立されたときだけ、それは使用されるべきです。
Appendix B. Changes since RFC 2222
RFC2222以来の付録B.変化
This appendix is non-normative.
この付録は非規範的です。
The material in RFC 2222 was significantly rewritten in the production of this document.
RFC2222の材料はこのドキュメントの生産でかなり書き直されました。
RFC 2222, by not stating that the authorization identity string was a string of Unicode characters, let alone character data, implied that the authorization identity string was a string of octets.
承認アイデンティティストリングが一連のユニコード文字であったと述べないのによるRFC2222(まして、キャラクタデータ)は、承認アイデンティティストリングが一連の八重奏であることを含意しました。
- The authorization identity string is now defined as a string of
Unicode characters. The NUL (U+0000) character is prohibited.
While protocol specifications are responsible for defining the
authorization identity form, as well as the Unicode string syntax
and related semantics, mechanism specifications are responsible
for defining how the Unicode string is carried in the
authentication exchange.
- 承認アイデンティティストリングは現在、一連のユニコード文字と定義されます。 NUL(U+0000)キャラクタは禁止されています。 プロトコル仕様は承認アイデンティティフォーム、ユニコードストリング構文、および関連する意味論を定義するのに原因となりますが、メカニズム仕様はユニコードストリングが認証交換でどう運ばれるかを定義するのに原因となります。
- Deleted "If so, when the client does not send data first, the
initial challenge MUST be specified as being an empty challenge."
- 削除されて、「そうだとすれば、クライアントが最初にデータを送らないと、空の挑戦であるとして初期の挑戦を指定しなければなりません」。
Melnikov & Zeilenga Standards Track [Page 31] RFC 4422 SASL June 2006
メリニコフとZeilenga規格はSASL2006年6月にRFC4422を追跡します[31ページ]。
The following technical change was made to the EXTERNAL mechanism:
以下の技術変化をEXTERNALメカニズムにしました:
- The authorization identity string is to be UTF-8 encoded.
- 承認アイデンティティストリングはUTF-8であるコード化されたことです。
Note that protocol and mechanism specification requirements have
been significantly tightened. Existing protocol and mechanism
specifications will need to be updated to meet these requirements.
プロトコルとメカニズム仕様書要求事項がかなりきびしくされたことに注意してください。 既存のプロトコルとメカニズム仕様は、これらの必要条件を満たすためにアップデートする必要があるでしょう。
Editors' Addresses
エディタのアドレス
Alexey Melnikov Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex, TW12 2BX, United Kingdom
城のビジネス村の36駅のRoadハンプトン、ミドルセックスTW12 2BX、AlexeyメリニコフIsode株式会社5イギリス
EMail: Alexey.Melnikov@isode.com URI: http://www.melnikov.ca/
メール: Alexey.Melnikov@isode.com ユリ: http://www.melnikov.ca/
Kurt D. Zeilenga OpenLDAP Foundation
カートD.Zeilenga OpenLDAP財団
EMail: Kurt@OpenLDAP.org
メール: Kurt@OpenLDAP.org
Melnikov & Zeilenga Standards Track [Page 32] RFC 4422 SASL June 2006
メリニコフとZeilenga規格はSASL2006年6月にRFC4422を追跡します[32ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
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.
このドキュメントは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 provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Melnikov & Zeilenga Standards Track [Page 33]
メリニコフとZeilenga標準化過程[33ページ]
一覧
スポンサーリンク
