RFC2808 日本語訳
2808 The SecurID(r) SASL Mechanism. M. Nystrom. April 2000. (Format: TXT=20342 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Nystrom Request for Comments: 2808 RSA Laboratories Category: Informational April 2000
コメントを求めるワーキンググループM.ニストロムの要求をネットワークでつないでください: 2808年のRSA研究所カテゴリ: 情報の2000年4月
The SecurID(r) SASL Mechanism
SecurID(r) SASLメカニズム
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
SecurID is a hardware token card product (or software emulation thereof) produced by RSA Security Inc., which is used for end-user authentication. This document defines a SASL [RFC2222] authentication mechanism using these tokens, thereby providing a means for such tokens to be used in SASL environments. This mechanism is only for authentication, and has no effect on the protocol encoding and is not designed to provide integrity or confidentiality services.
SecurIDはエンドユーザ認証に使用されるRSA Security Inc.によって生産されたハードウェアトークン・カード製品(または、それのソフトウェアエミュレーション)です。 このドキュメントはこれらのトークンを使用することでSASL[RFC2222]認証機構を定義します、その結果、そのようなトークンがSASL環境で使用される手段を提供します。 このメカニズムは、認証のためだけにあって、プロトコルコード化のときに効き目がなくて、また保全か秘密性にサービスを提供するように設計されていません。
This memo assumes the reader has basic familiarity with the SecurID token, its associated authentication protocol and SASL.
このメモは、読者がそのSecurIDトークンへの基本的な親しみ、関連認証プロトコル、およびSASLを持っていると仮定します。
How to read this document
このドキュメントを読む方法
The key words "MUST", "MUST NOT", "SHALL", "SHOULD" and "MAY" in this document are to be interpreted as defined in [RFC2119].
このドキュメントのキーワード“MUST"、「必須NOT」、“SHALL"、“SHOULD"、および「5月」は[RFC2119]で定義されるように解釈されることになっています。
In examples, "C:" and "S:" indicate messages sent by the client and server respectively.
例で「C:」 そして、「S:」 クライアントとサーバによってそれぞれ送られたメッセージを示してください。
1. Introduction
1. 序論
The SECURID SASL mechanism is a good choice for usage scenarios where a client, acting on behalf of a user, is untrusted, as a one-time passcode will only give the client a single opportunity to act maliciously. This mechanism provides authentication only.
SECURID SASLメカニズムはユーザを代表して行動して、クライアントが信頼されていない用法シナリオのための良い選択です、1回のpasscodeが陰湿に行動するただ一つの機会をクライアントに与えるだけであるとき。 このメカニズムは認証だけを提供します。
Nystrom Informational [Page 1] RFC 2808 The SecurID(r) SASL Mechanism April 2000
[1ページ]RFC2808SecurID(r) SASLメカニズム2000年4月の情報のニストロム
The SECURID SASL mechanism provides a formal way to integrate the existing SecurID authentication method into SASL-enabled protocols including IMAP [RFC2060], ACAP [RFC2244], POP3 [RFC1734] and LDAPv3 [RFC2251].
SECURID SASLメカニズムはIMAP[RFC2060]、ACAP[RFC2244]、POP3[RFC1734]、およびLDAPv3[RFC2251]を含むSASLによって可能にされたプロトコルと既存のSecurID認証方法を統合する正式な方法を提供します。
2. Authentication Model
2. 認証モデル
The SECURID SASL mechanism provides two-factor based user authentication as defined below.
SECURID SASLメカニズムは以下で定義されるように2要素のベースのユーザー認証を提供します。
There are basically three entities in the authentication mechanism described here: A user, possessing a SecurID token, an application server, to which the user wants to connect, and an authentication server, capable of authenticating the user. Even though the application server in practice may function as a client with respect to the authentication server, relaying authentication credentials etc. as needed, both servers are, unless explicitly mentioned, collectively termed "the server" here. The protocol used between the application server and the authentication server is outside the scope of this memo. The application client, acting on behalf of the user, is termed "the client".
基本的に、ここで説明された認証機構には3つの実体があります: SecurIDトークン、ユーザが接続したがっているアプリケーション・サーバー、および認証サーバを持っていて、ユーザを認証できるユーザ。 両方のサーバはそうです、実際にはアプリケーション・サーバーがクライアントとして認証サーバに関して機能するかもしれませんが、必要に応じて認証資格証明書などをリレーして、明らかに言及されていて、ここに「サーバ」とまとめて呼ばれない場合、リレーします。 このメモの範囲の外にアプリケーション・サーバーと認証サーバの間で使用されるプロトコルがあります。 ユーザを代表して行動して、アプリケーションクライアントは「クライアント」と呼ばれます。
The mechanism is based on the use of a shared secret key, or "seed", and a personal identification number (PIN), which is known both by the user and the authentication server. The secret seed is stored on a token that the user possesses, as well as on the authentication server. Hence the term "two-factor authentication", a user needs not only physical access to the token but also knowledge about the PIN in order to perform an authentication. Given the seed, current time of day, and the PIN, a "PASSCODE(r)" is generated by the user's token and sent to the server.
メカニズムは共有された秘密鍵の使用か、「種子」と、個人識別番号(暗証番号)に基づいています。(それは、ユーザと認証サーバによって知られています)。秘密の種子はユーザが持っているトークンの上と、そして、認証サーバの上に保存されます。したがって、「2要素の認証」という用語、ユーザは認証を実行するためにトークンへの物理的なアクセスだけではなく、暗証番号に関する知識も必要とします。 種子、現在の時刻、および暗証番号を考えて、"PASSCODE(r)"をユーザのトークンで生成して、サーバに送ります。
The SECURID SASL mechanism provides one service:
SECURID SASLメカニズムは1つのサービスを提供します:
- User authentication where the user provides information to the
server, so that the server can authenticate the user.
- サーバがユーザを認証できるようにユーザが情報をサーバに提供するユーザー認証。
This mechanism is identified with the SASL key "SECURID".
このメカニズムはSASLの主要な"SECURID"と同一視されています。
3. Authentication Procedure
3. 認証手順
a) The client generates the credentials using local information
(seed, current time and user PIN/password).
a) クライアントは、ローカルの情報(種子、現在の時間、およびユーザ暗証番号/パスワード)を使用することで資格証明書を生成します。
Nystrom Informational [Page 2] RFC 2808 The SecurID(r) SASL Mechanism April 2000
[2ページ]RFC2808SecurID(r) SASLメカニズム2000年4月の情報のニストロム
b) If the underlying protocol permits, the client sends credentials
to the server in an initial response message. Otherwise, the
client sends a request to the server to initiate the
authentication mechanism, and sends credentials after the server's
response (see [RFC2222] section 5.1 for more information regarding
the initial response option).
b) 基本的なプロトコルが可能にするなら、クライアントは初期の応答メッセージにおけるサーバに資格証明書を送ります。 さもなければ、クライアントは、認証機構を開始するために要求をサーバに送って、サーバの応答の後に資格証明書を送ります(初期の応答選択に関する詳しい情報に関して[RFC2222]セクション5.1を見てください)。
Unless the server requests a new PIN (see below), the contents of
the client's initial response SHALL be as follows:
サーバが、新しい暗証番号(以下を見る)、クライアントの初期の応答SHALLのコンテンツは以下の通りであるよう要求しない場合:
(1) An authorization identity. When this field is empty, it
defaults to the authentication identity. This field MAY be used
by system administrators or proxy servers to login with a
different user identity. This field MUST NOT be longer than 255
octets, SHALL be terminated by a NUL (0) octet, and MUST consist
of UTF-8-encoded [RFC2279] printable characters only (US-ASCII
[X3.4] is a subset of UTF-8).
(1) 承認のアイデンティティ。 この分野が人影がないときに、それは認証のアイデンティティをデフォルトとします。 この分野はシステム管理者かプロキシサーバによって使用されて、異なったユーザアイデンティティでログインするかもしれません。 この分野が255の八重奏より長いはずがなく、SHALLはNUL(0)八重奏で終えられて、コード化されたUTF8[RFC2279]の印刷可能なキャラクタだけから成らなければなりません(米国-ASCII[X3.4]はUTF-8の部分集合です)。
(2) An authentication identity. The identity whose passcode will
be used. If this field is empty, it is assumed to have been
transferred by other means (e.g. if the underlying protocol has
support for this, like [RFC2251]). This field MUST NOT be longer
than 255 octets, SHALL be terminated by a NUL (0) octet, and MUST
consist of UTF-8-encoded printable characters only.
(2) 認証のアイデンティティ。 passcodeが使用されるアイデンティティ。 この分野が人影がないなら、他の手段(例えば、基本的なプロトコルにこのサポートがある[RFC2251]のような)で移されたと思われます。 この分野が255の八重奏より長いはずがなく、SHALLはNUL(0)八重奏で終えられて、コード化されたUTF8の印刷可能なキャラクタだけから成らなければなりません。
(3) A passcode. The one-time password that will be used to grant
access. This field MUST NOT be shorter than 4 octets, MUST NOT be
longer than 32 octets, SHALL be terminated by a NUL (0) octet, and
MUST consist of UTF-8-encoded printable characters only.
Passcodes usually consist of 4-8 digits.
(3) passcode。 アクセサリーを与えるのに使用されるワンタイムパスワード この分野が4より短い八重奏が32の八重奏より長いはずがないということであるはずがなく、SHALLはNUL(0)八重奏で終えられて、コード化されたUTF8の印刷可能なキャラクタだけから成らなければなりません。 通常、Passcodesは4-8 ケタから成ります。
The ABNF [RFC2234] form of this message is as follows:
このメッセージのABNF[RFC2234]フォームは以下の通りです:
credential-pdu = authorization-id authentication-id passcode [pin]
資格証明書-pduは承認イド認証イドpasscodeと等しいです。[ピン]
authorization-id = 0*255VUTF8 %x00
承認イド=0*255VUTF8%x00
authentication-id = 0*255VUTF8 %x00
認証イド=0*255VUTF8%x00
passcode = 4*32VUTF8 %x00
4*32VUTF8passcode=%x00
pin ::= 4*32VUTF8 %x00
以下をピンで止めてください:= 4*32VUTF8%x00
VUTF8 = <Visible (printable) UTF8-encoded characters>
VUTF8は<Visible(印刷可能な)のUTF8によってコード化されたキャラクタ>と等しいです。
Regarding the <pin> rule, see d) below.
<ピン>規則に関して、以下のd)を見てください。
Nystrom Informational [Page 3] RFC 2808 The SecurID(r) SASL Mechanism April 2000
[3ページ]RFC2808SecurID(r) SASLメカニズム2000年4月の情報のニストロム
c) The server verifies these credentials using its own information.
If the verification succeeds, the server sends back a response
indicating success to the client. After receiving this response,
the client is authenticated. Otherwise, the verification either
failed or the server needs an additional set of credentials from
the client in order to authenticate the user.
c) サーバは、それ自身の情報を使用することでこれらの資格証明書について確かめます。 検証が成功するなら、サーバは成功をクライアントに示す応答を返送します。 この応答を受けた後に、クライアントは認証されます。 さもなければ、失敗された検証かサーバが、ユーザを認証するためにクライアントから追加セットの資格証明書を必要とします。
d) If the server needs an additional set of credentials, it requests
them now. This request has the following format, described in ABNF
notation:
d) サーバが追加セットの資格証明書を必要とするなら、それは現在、それらを要求します。 この要求には、ABNF記法で説明された以下の形式があります:
server-request = passcode | pin
サーバ要求=passcode| ピン
passcode = "passcode" %x00
"passcode"passcode=%x00
pin = "pin" %x00 [suggested-pin]
ピン=「ピン」%x00[提案されたピン]
suggested-pin = 4*32VUTF8 %x00 ; Between 4 and 32 UTF-8 characters
提案されたピン=4*32VUTF8%x00。 4〜32のUTF-8キャラクタ
The 'passcode' choice will be sent when the server requests
another passcode. The 'pin' choice will be sent when the server
requests a new user PIN. The server will either send an empty
string or suggest a new user PIN in this message.
サーバが別のpasscodeを要求すると、'passcode'選択を送るでしょう。 サーバが新しいユーザ暗証番号を要求すると、'ピン'選択を送るでしょう。 サーバは、空のストリングを送るか、またはこのメッセージの新しいユーザ暗証番号を示すでしょう。
e) The client generates a new set of credentials using local
information and depending on the server's request and sends them
to the server. Authentication now continues as in c) above.
e) クライアントは、ローカルの情報を使用して、サーバの要求による新しいセットの資格証明書を生成して、それらをサーバに送ります。認証は現在、上のc)のように続きます。
Note 1: Case d) above may occur e.g. when the clocks on which the server and the client relies are not synchronized.
注意1: 上のケースd)は起こったかもしれません、例えば、サーバとクライアントが当てにする時計がいつでないかが連動しました。
Note 2: If the server requests a new user PIN, the client MUST respond with a new user PIN (together with a passcode), encoded as a UTF-8 string. If the server supplies the client with a suggested PIN, the client accepts this by replying with the same PIN, but MAY replace it with another one. The length of the PIN is application- dependent as are any other requirements for the PIN, e.g. allowed characters. If the server for some reason does not accept the received PIN, the client MUST be prepared to receive either a message indicating the failure of the authentication or a repeated request for a new PIN. Mechanisms for transferring knowledge about PIN requirements from the server to the client are outside the scope of this memo. However, some information MAY be provided in error messages transferred from the server to the client when applicable.
注意2: サーバが新しいユーザ暗証番号を要求するなら、クライアントはUTF-8ストリングとしてコード化された新しいユーザ暗証番号(passcodeに伴う)で応じなければなりません。 サーバが提案された暗証番号をクライアントに提供するなら、クライアントは、同じ暗証番号で返答することによってこれを受け入れますが、それを別の1つに取り替えるかもしれません。 暗証番号の長さはアプリケーション暗証番号のためのいかなる他の要件のような扶養家族、例えば、許容キャラクタです。 サーバがある理由で受信された暗証番号を受け入れないなら、クライアントは認証の失敗を示すメッセージか新しい暗証番号に関する繰り返された要求のどちらかを受け取る用意ができていなければなりません。 このメモの範囲の外にサーバからクライアントまで暗証番号要件に関する知識を移すためのメカニズムがあります。 しかしながら、適切であるときにサーバからクライアントまで移されたエラーメッセージに何らかの情報を提供するかもしれません。
Nystrom Informational [Page 4] RFC 2808 The SecurID(r) SASL Mechanism April 2000
[4ページ]RFC2808SecurID(r) SASLメカニズム2000年4月の情報のニストロム
4. Examples
4. 例
4.1 IMAP4
4.1 IMAP4
The following example shows the use of the SECURID SASL mechanism with IMAP4. The example is only designed to illustrate the protocol interaction but do provide valid encoding examples.
以下の例はIMAP4とのSECURID SASLメカニズムの使用を示しています。 例は、プロトコル相互作用を例証しますが、有効なコード化に例を提供するように設計されるだけです。
The base64 encoding of the last client response, as well as the "+ " preceding the response, is part of the IMAP4 profile, and not a part of this specification itself.
応答、および応答に先行する「+」を最後のクライアントにコード化するbase64はこの仕様の一部ではなく、IMAP4プロフィールの一部自体です。
S: * OK IMAP4 server ready C: A001 CAPABILITY S: * CAPABILITY IMAP4 AUTH=CRAM-MD5 AUTH=SECURID S: A001 OK done C: A002 AUTHENTICATE SECURID S: + C: AG1hZ251cwAxMjM0NTY3OAA= S: A002 OK Welcome, SECURID authenticated user: magnus
S: * OK IMAP4のサーバ持ち合わせのC: A001能力S: * 能力IMAP4 AUTHは一夜漬け-MD5 AUTH=SECURID Sと等しいです: Cが行われたA001 OK: A002はSECURID Sを認証します: + C: AG1hZ251cwAxMjM0NTY3OAAはSと等しいです: A002 OK Welcome、SECURIDはユーザを認証しました: magnus
4.2 LDAPv3
4.2 LDAPv3
The following examples show the use of the SECURID SASL mechanism with LDAPv3. The examples are only designed to illustrate the protocol interaction, but do provide valid encoding examples. Usernames, passcodes and PINs are of course fictitious. For readability, all messages are shown in the value-notation defined in [X680]. <credential-pdu> values are shown hex-encoded in the 'credentials' field of LDAP's 'BindRequest' and <server-request> values are shown hex-encoded in the 'serverSaslCreds' field of LDAP's 'BindResponse'.
以下の例はLDAPv3とのSECURID SASLメカニズムの使用を示しています。 例はプロトコル相互作用を例証するように設計されるだけですが、有効なコード化に例を提供してください。 ユーザ名、passcodes、および暗証番号はもちろん架空です。 読み易さにおいて、すべてのメッセージが[X680]で定義された値記法で示されます。 <の資格証明pduの>値は十六進法でLDAPの'serverSaslCreds'分野でコード化された'BindResponse'が十六進法でLDAPの'BindRequest'と<サーバ要求の'資格証明書'分野でコード化された>値に示されるのが示されます。
4.2.1 LDAPv3 Example 1
4.2.1 LDAPv3の例1
Initial response message, successful authentication.
応答メッセージ、うまくいっている認証に頭文字をつけてください。
C: { messageID 1,
protocolOp bindRequest :
{ version 1,
name '434E3D4D41474E5553'H, -- "CN=MAGNUS"
authentication sasl :
{ mechanism '53454355524944'H, -- "SECURID"
credentials '006d61676e757300313233343536373800'H
}
}
}
C: protocolOp bindRequest: バージョン1、名前'434Eの3D4D41474E5553'H--「CNはマグヌスと等しく」認証sasl: メカニズム'53454355524944'H--messageID1、"SECURID"資格証明書'006d61676e757300313233343536373800'H、'
Nystrom Informational [Page 5] RFC 2808 The SecurID(r) SASL Mechanism April 2000
[5ページ]RFC2808SecurID(r) SASLメカニズム2000年4月の情報のニストロム
S: { messageID 1,
protocolOp bindResponse :
{ resultCode success,
matchedDN ''H,
errorMessage ''H,
}
}
S: messageID1、protocolOp bindResponse:、resultCode成功、matchedDN、「H、errorMessage」H
4.2.2 LDAPv3 Example 2
4.2.2 LDAPv3の例2
Initial response message, server requires second passcode.
応答メッセージに頭文字をつけてください、そして、サーバは2番目のpasscodeを必要とします。
C: {
messageID 1,
protocolOp bindRequest : {
version 1,
name '434E3D4D41474E5553'H, -- "CN=MAGNUS"
authentication sasl : {
mechanism '53454355524944'H, -- "SECURID"
credentials '006d61676e757300313233343536373800'H
}
}
}
C: protocolOp bindRequest: バージョン1、名前'434Eの3D4D41474E5553'H--「CNはマグヌスと等しく」認証sasl: メカニズム'53454355524944'H--messageID1、"SECURID"資格証明書'006d61676e757300313233343536373800'H、'
S: {
messageID 1,
protocolOp bindResponse : {
resultCode saslBindInProgress,
matchedDN ''H,
errorMessage ''H,
serverSaslCreds '70617373636f646500'H
}
}
S: messageID1、protocolOp bindResponse:、resultCode saslBindInProgress、matchedDN「H、errorMessage」、H、serverSaslCreds'70617373636f646500'H'
C: {
messageID 1,
protocolOp bindRequest : {
version 1,
name '434E3D4D41474E5553'H, -- "CN=MAGNUS"
authentication sasl : {
mechanism '53454355524944'H, -- "SECURID"
credentials '006d61676e757300383736353433323100'H
}
}
}
C: protocolOp bindRequest: バージョン1、名前'434Eの3D4D41474E5553'H--「CNはマグヌスと等しく」認証sasl: メカニズム'53454355524944'H--messageID1、"SECURID"資格証明書'006d61676e757300383736353433323100'H、'
S: {
messageID 1,
S: messageID1
Nystrom Informational [Page 6] RFC 2808 The SecurID(r) SASL Mechanism April 2000
[6ページ]RFC2808SecurID(r) SASLメカニズム2000年4月の情報のニストロム
protocolOp bindResponse : {
resultCode success,
matchedDN ''H,
errorMessage ''H,
}
}
protocolOp bindResponse: resultCode成功、matchedDN、「H、errorMessage」H
4.2.3 LDAPv3 Example 3
4.2.3 LDAPv3の例3
Initial response message, server requires new PIN and passcode, and supplies client with a suggested new PIN (which the client accepts).
初期の応答メッセージ、サーバは新しい暗証番号とpasscodeを必要として、提案された新しい暗証番号をクライアントに提供します(クライアントが受け入れる)。
C: {
messageID 1,
protocolOp bindRequest : {
version 1,
name '434E3D4D41474E5553'H, -- "CN=MAGNUS"
authentication sasl : {
mechanism '53454355524944'H, -- "SECURID"
credentials '006d61676e757300313233343536373800'H
}
}
}
C: protocolOp bindRequest: バージョン1、名前'434Eの3D4D41474E5553'H--「CNはマグヌスと等しく」認証sasl: メカニズム'53454355524944'H--messageID1、"SECURID"資格証明書'006d61676e757300313233343536373800'H、'
S: {
messageID 1,
protocolOp bindResponse : {
resultCode saslBindInProgress,
matchedDN ''H,
errorMessage ''H,
serverSaslCreds '70696e006b616c6c6500'H
}
}
S: messageID1、protocolOp bindResponse:、resultCode saslBindInProgress、matchedDN「H、errorMessage」、H、serverSaslCreds'70696e006b616c6c6500'H'
C: {
messageID 1,
protocolOp bindRequest : {
version 1,
name '434E3D4D41474E5553'H, -- "CN=MAGNUS"
authentication sasl : {
mechanism '53454355524944'H, -- "SECURID"
credentials '006d61676e7573003837343434363734006b616c6c6500'H
}
}
}
C: protocolOp bindRequest: バージョン1、名前'434Eの3D4D41474E5553'H--「CNはマグヌスと等しく」認証sasl: メカニズム'53454355524944'H--messageID1、"SECURID"資格証明書'006d61676e7573003837343434363734006b616c6c6500'H、'
S: {
messageID 1,
S: messageID1
Nystrom Informational [Page 7] RFC 2808 The SecurID(r) SASL Mechanism April 2000
[7ページ]RFC2808SecurID(r) SASLメカニズム2000年4月の情報のニストロム
protocolOp bindResponse : {
resultCode success,
matchedDN ''H,
errorMessage ''H,
}
}
protocolOp bindResponse: resultCode成功、matchedDN、「H、errorMessage」H
5. Security Considerations
5. セキュリティ問題
This mechanism only provides protection against passive eavesdropping attacks. It does not provide session privacy, server authentication or protection from active attacks. In particular, man-in-the-middle attacks, were an attacker acts as an application server in order to acquire a valid passcode are possible.
このメカニズムは受け身の盗聴攻撃に対する保護を提供するだけです。 それは活発な攻撃からセッションプライバシー、サーバ証明または保護を提供しません。 特に介入者攻撃、攻撃者がアプリケーション・サーバーとして行為であったなら、aを取得するために、有効なpasscodeは可能です。
In order to protect against such attacks, the client SHOULD make sure that the server is properly authenticated. When user PINs are transmitted, user authentication SHOULD take place on a server- authenticated and confidentiality-protected connection.
そのような攻撃から守るために、クライアントSHOULDは、サーバが適切に認証されるのを確実にします。 ユーザ暗証番号がサーバの認証されて秘密性で保護された接続のときに伝えられるとき、ユーザー認証SHOULDは行われます。
Server implementations MUST protect against replay attacks, since an attacker could otherwise gain access by replaying a previous, valid request. Clients MUST also protect against replay of PIN-change messages.
そうでなければ、攻撃者は前の、そして、有効な要求を再演することによって、アクセスを得ることができるでしょう、したがって、サーバ実装は反射攻撃から守らなければなりません。 また、クライアントは暗証番号変化メッセージの再生から守らなければなりません。
5.1 The Race Attack
5.1 レース攻撃
It is possible for an attacker to listen to most of a passcode, guess the remainder, and then race the legitimate user to complete the authentication. As for OTP [RFC2289], conforming server implementations MUST protect against this race condition. One defense against this attack is outlined below and borrowed from [RFC2289]; implementations MAY use this approach or MAY select an alternative defense.
攻撃者が認証を終了するためにpasscodeの大部分を聞いて、残りを推測して、次に、正統のユーザを競走をさせるのは、可能です。 OTP[RFC2289]に関して、サーバ実装を従わせると、この競合条件守られなければなりません。 [RFC2289]からこの攻撃に対する1つのディフェンスを以下に概説して、借ります。 実装は、このアプローチを使用するか、または代替防衛を選択するかもしれません。
One possible defense is to prevent a user from starting multiple simultaneous authentication sessions. This means that once the legitimate user has initiated authentication, an attacker would be blocked until the first authentication process has completed. In this approach, a timeout is necessary to thwart a denial of service attack.
1つの可能なディフェンスはユーザが複数の同時の認証セッションに始めるのを防ぐことです。 これは、正統のユーザがいったん認証を開始すると、攻撃者が認証過程が完成した1日まで妨げられることを意味します。 このアプローチでは、タイムアウトが、サービス不能攻撃を阻むのに必要です。
6. IANA Considerations
6. IANA問題
By registering the SecurID protocol as a SASL mechanism, implementers will have a well-defined way of adding this authentication mechanism to their product. Here is the registration template for the SECURID SASL mechanism:
SASLメカニズムとしてSecurIDプロトコルを登録することによって、implementersには、それらの製品にこの認証機構を加える明確な方法があるでしょう。 ここに、SECURID SASLメカニズムのための登録テンプレートがあります:
Nystrom Informational [Page 8] RFC 2808 The SecurID(r) SASL Mechanism April 2000
[8ページ]RFC2808SecurID(r) SASLメカニズム2000年4月の情報のニストロム
SASL mechanism name: SECURID
Security Considerations: See corresponding section of this memo
Published specification: This memo
Person & email address to
contact for further
information: See author's address section below
Intended usage: COMMON
Author/Change controller: See author's address section below
SASLメカニズム名: SECURIDセキュリティ問題: このメモPublished仕様の該当箇所を見てください: 詳細のために連絡するこのメモPersonとEメールアドレス: Intended用法の下で作者のアドレス部を見てください: COMMON Author/変化コントローラ: 下の作者のアドレス部を見てください。
7. Intellectual Property Considerations
7. 知的所有権問題
RSA Security Inc. does not make any claims on the general constructions described in this memo, although underlying techniques may be covered. Among the underlying techniques, the SecurID technology is covered by a number of US patents (and foreign counterparts), in particular US patent no. 4,885,778, no. 5,097,505, no. 5,168,520, and 5,657,388.
RSA Security Inc.はこのメモで説明された一般的な構造のどんなクレームもしません、基本的なテクニックがカバーされているかもしれませんが。 基本的なテクニックの中では、SecurID技術は多くの米国特許(そして、外交相手)でカバーされています、特定の米国特許No.4,885,778、No.5,097,505、No.5,168,520、および565万7388で。
SecurID is a registered trademark, and PASSCODE is a trademark, of RSA Security Inc.
SecurIDは登録商標です、そして、PASSCODEはRSA Security Inc.の商標です。
8. References
8. 参照
[RFC1734] Myers, J., "POP3 AUTHentication command", RFC 1734,
December 1994.
[RFC1734] マイアーズ、J.、「POP3 AUTHenticationコマンド」、RFC1734、1994年12月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2026] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
[RFC2060] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 2060, December 1996.
[RFC2060] クリスピン、M.、「バージョン4rev1"、RFC2060、1996年インターネットメッセージアクセス・プロトコル--12月。」
[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月。
[RFC2222] Myers, J., "Simple Authentication and Security Layer", RFC
2222, October 1997.
[RFC2222] マイアーズ、J.、「簡易認証とセキュリティは層にする」RFC2222、1997年10月。
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC2234] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[RFC2244] Newman, C. and J. Myers, "ACAP -- Application Configuration
Access Protocol", RFC 2244, November 1997.
[RFC2244] ニューマン、C.、およびJ.マイアーズ、「ACAP--アプリケーション構成アクセスは議定書を作る」、RFC2244、11月1997日
[RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
Access Protocol (v3)", RFC 2251, December 1997.
[RFC2251]ウォールとM.とハウズとT.とS.Kille、「ライトウェイト・ディレクトリ・アクセス・プロトコル(v3)」、RFC2251 1997年12月。
Nystrom Informational [Page 9] RFC 2808 The SecurID(r) SASL Mechanism April 2000
[9ページ]RFC2808SecurID(r) SASLメカニズム2000年4月の情報のニストロム
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 2279, January 1998.
[RFC2279]Yergeau、1998年1月のF.、「UTF-8、ISO10646の変換形式」RFC2279。
[RFC2289] Haller, N., Metz, C., Nesser, P. and M. Straw, "A One-Time
Password System", RFC 2289, February 1998.
[RFC2289] ハラーとN.とメスとC.とNesserとP.とM.わら、「A One-時間パスワードシステム」、RFC2289、1998年2月。
[X3.4] ANSI, "ANSI X3.4: Information Systems - Coded Character
Sets - 7-Bit American National Standard Code for
Information Interchange (7-Bit ASCII)," American National
Standards Institute.
[X3.4]ANSI、「ANSI X3.4:」 「情報システム--コード化文字集合--7ビットの情報交換用米国標準コード(7ビットのASCII)。」(American National Standards Institut)
[X680] ITU-T, "Information Technology - Abstract Syntax Notation
One (ASN.1): Specification of Basic Notation,"
International Telecommunication Union, 1997.
[X680]ITU-T、「情報技術--構文記法1(ASN.1)を抜き取ってください」 「基本的な記法の仕様」、国際電気通信連合、1997。
9. Acknowledgements
9. 承認
The author gratefully acknowledges the contributions of various reviewers of this memo, in particular the ones from John Myers. They have significantly clarified and improved the utility of this specification.
作者はジョン・マイアーズからこのメモの様々な評論家の貢献、特にものを感謝して承認します。 彼らは、この仕様に関するユーティリティをかなりはっきりさせて、改良しました。
10. Author's Address
10. 作者のアドレス
Magnus Nystrom RSA Laboratories Box 10704 121 29 Stockholm Sweden
マグヌス・ニストロムRSA研究所箱10704の121 29ストックホルムスウェーデン
Phone: +46 8 725 0900 EMail: magnus@rsasecurity.com
以下に電話をしてください。 +46 8 725 0900はメールされます: magnus@rsasecurity.com
Nystrom Informational [Page 10] RFC 2808 The SecurID(r) SASL Mechanism April 2000
[10ページ]RFC2808SecurID(r) SASLメカニズム2000年4月の情報のニストロム
11. Full Copyright Statement
11. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Nystrom Informational [Page 11]
ニストロムInformationalです。[11ページ]
一覧
スポンサーリンク
