[要約] RFC 4467は、IMAPプロトコルのURLAUTH拡張機能に関する仕様です。この拡張機能の目的は、IMAPセッション内でURLに基づいた認証を提供することです。
Network Working Group M. Crispin
Request for Comments: 4467 University of Washington
Updates: 3501 May 2006
Category: Standards Track
Internet Message Access Protocol (IMAP) - URLAUTH Extension
インターネットメッセージアクセスプロトコル（IMAP） - urlauth拡張機能
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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This document describes the URLAUTH extension to the Internet Message Access Protocol (IMAP) (RFC 3501) and the IMAP URL Scheme (IMAPURL) (RFC 2192). This extension provides a means by which an IMAP client can use URLs carrying authorization to access limited message data on the IMAP server.
このドキュメントでは、インターネットメッセージアクセスプロトコル（IMAP）（RFC 3501）およびIMAP URLスキーム（IMAPURL）（RFC 2192）へのUrlauth拡張について説明します。この拡張機能は、IMAPクライアントが認証を運ぶURLを使用して、IMAPサーバー上の限られたメッセージデータにアクセスできる手段を提供します。
An IMAP server that supports this extension indicates this with a capability name of "URLAUTH".
この拡張機能をサポートするIMAPサーバーは、「urlauth」の機能名でこれを示します。
In [IMAPURL], a URL of the form imap://fred@example.com/INBOX/;uid=20 requires authorization as userid "fred". However, [IMAPURL] implies that it only supports authentication and confuses the concepts of authentication and authorization.
[imapurl]では、imap：//fred@example.com/inbox/; uid = 20のフォームのURLは、userId "fred"として承認を必要とします。ただし、[Imapurl]は、認証のみをサポートし、認証と認証の概念を混同することを意味します。
The URLAUTH extension defines an authorization mechanism for IMAP URLs to replace [IMAPURL]'s authentication-only mechanism. URLAUTH conveys authorization in the URL string itself and reuses a portion of the syntax of the [IMAPURL] authentication mechanism to convey the authorization identity (which also defines the default namespace in [IMAP]).
Urlauth拡張は、[Imapurl]の認証のみのメカニズムを置き換えるIMAP URLの認証メカニズムを定義します。Urlauthは、URL文字列自体の承認を伝え、[iMapurl]認証メカニズムの構文の一部を再利用して、認証IDを伝えます（[IMAP]のデフォルトの名前空間も定義します）。
The URLAUTH extension provides a means by which an authorized user of an IMAP server can create URLAUTH-authorized IMAP URLs. A URLAUTH-authorized URL conveys authorization (not authentication) to the data addressed by that URL. This URL can be used in another IMAP session to access specific content on the IMAP server, without otherwise providing authorization to any other data (such as other data in the mailbox specified in the URL) owned by the authorizing user.
Urlauth拡張機能は、IMAPサーバーの承認されたユーザーがUrlauthを認めるIMAP URLを作成できる手段を提供します。urlauthが許可したURLは、そのURLによって扱われたデータに許可（認証ではない）を伝えます。このURLは、別のIMAPセッションで使用して、IMAPサーバー上の特定のコンテンツにアクセスすることができますが、他のデータ（URLで指定されたメールボックスの他のデータなど）に認可を提供することはできません。
Conceptually, a URLAUTH-authorized URL can be thought of as a "pawn ticket" that carries no authentication information and can be redeemed by whomever presents it. However, unlike a pawn ticket, URLAUTH has optional mechanisms to restrict the usage of a URLAUTH-authorized URL. Using these mechanisms, URLAUTH-authorized URLs can be usable by:
概念的には、認証情報を持たず、それを提示する人によって引き換えることができる「ポーンチケット」と考えることができます。ただし、ポーンチケットとは異なり、Urlauthには、Urlauthが許可されたURLの使用を制限するオプションのメカニズムがあります。これらのメカニズムを使用して、urlauthは認可されたURLを使用できます。
. anonymous (the "pawn ticket" model) . authenticated users only . a specific authenticated user only . message submission acting on behalf of a specific user only
。匿名（「ポーンチケット」モデル）。認証されたユーザーのみ。特定の認証されたユーザーのみ。特定のユーザーのみに代わって作用するメッセージの送信
There is also a mechanism for expiration.
有効期限のメカニズムもあります。
A URLAUTH-authorized URL can be used in the argument to the BURL command in message composition, as described in [BURL], for such purposes as allowing a client (with limited memory or other resources) to submit a message forward or to resend from an IMAP mailbox without requiring the client to fetch that message data.
[burl]に記載されているように、クライアント（メモリが限られているかその他のリソースが限られている）を許可するような目的のために、[burl]に記載されているように、メッセージ構成のburlコマンドの引数で、urlauthを許可したURLを使用できます。クライアントにそのメッセージデータを取得する必要がないIMAPメールボックス。
The URLAUTH is generated using an authorization mechanism name and an authorization token, which is generated using a secret mailbox access key. An IMAP client can request that the server generate and assign a new mailbox access key (thus effectively revoking all current URLs using URLAUTH with the old mailbox access key) but cannot set the mailbox access key to a key of its own choosing.
Urlauthは、承認メカニズム名と承認トークンを使用して生成されます。これは、シークレットメールボックスアクセスキーを使用して生成されます。IMAPクライアントは、サーバーが新しいメールボックスアクセスキーを生成して割り当てることを要求できます（したがって、古いメールボックスアクセスキーを使用してurlauthを使用してすべての現在のURLを効果的に取り外します）が、自分の選択のキーにメールボックスアクセスキーを設定することはできません。
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as defined in [KEYWORDS].
このドキュメントの「必須」、「そうでなければならない」、「そうでなければ」、「すべきではない」、「そうでない」、「必要はない」は、[キーワード]で定義されていると解釈されます。
The formal syntax uses the Augmented Backus-Naur Form (ABNF) notation including the core rules defined in Appendix A of [ABNF].
正式な構文では、[ABNF]の付録Aで定義されているコアルールを含む、拡張されたBackus-Naurフォーム（ABNF）表記を使用します。
In examples, "C:" and "S:" indicate lines sent by the client and server, respectively. If a single "C:" or "S:" label applies to multiple lines, then the line breaks between those lines are for editorial clarity only and are not part of the actual protocol exchange.
例では、「C：」と「S：」は、それぞれクライアントとサーバーから送信された行を示します。単一の「c：」または「s：」が複数の行に適用される場合、それらの線間のラインが編集の明確さのみを目的としており、実際のプロトコル交換の一部ではありません。
The URLAUTH is a component, appended at the end of a URL, that conveys authorization to access the data addressed by that URL. It contains an authorized access identifier, an authorization mechanism name, and an authorization token. The authorization token is generated from the URL, the authorized access identifier, the authorization mechanism name, and a mailbox access key.
Urlauthは、URLの最後に追加されたコンポーネントであり、そのURLによってアドレス指定されたデータにアクセスする許可を伝えます。承認されたアクセス識別子、承認メカニズム名、および承認トークンが含まれています。承認トークンは、URL、認定アクセス識別子、承認メカニズム名、およびメールボックスアクセスキーから生成されます。
The mailbox access key is a random string with at least 128 bits of entropy. It is generated by software (not by the human user) and MUST be unpredictable.
メールボックスアクセスキーは、少なくとも128ビットのエントロピーを持つランダムな文字列です。ソフトウェア（人間のユーザーではなく）によって生成され、予測不可能でなければなりません。
Each user has a table of mailboxes and an associated mailbox access key for each mailbox. Consequently, the mailbox access key is per-user and per-mailbox. In other words, two users sharing the same mailbox each have a different mailbox access key for that mailbox, and each mailbox accessed by a single user also has a different mailbox access key.
各ユーザーには、メールボックスのテーブルと、各メールボックスの関連するメールボックスアクセスキーがあります。したがって、メールボックスアクセスキーはユーザーごととメールごとになります。言い換えれば、同じメールボックスを共有する2人のユーザーには、そのメールボックスの異なるメールボックスアクセスキーがあり、1人のユーザーがアクセスする各メールボックスには異なるメールボックスアクセスキーもあります。
The authorized access identifier restricts use of the URLAUTH authorized URL to certain users authorized on the server, as described in section 3.
承認されたアクセス識別子は、セクション3で説明されているように、サーバー上で承認された特定のユーザーにurlauth認定URLの使用を制限します。
The authorization mechanism is the algorithm by which the URLAUTH is generated and subsequently verified, using the mailbox access key.
承認メカニズムは、メールボックスアクセスキーを使用して、Urlauthが生成され、その後検証されるアルゴリズムです。
This specification defines the INTERNAL mechanism, which uses a token generation algorithm of the server's choosing and does not involve disclosure of the mailbox access key to the client.
この仕様は、サーバーの選択のトークン生成アルゴリズムを使用し、クライアントへのメールボックスアクセスキーの開示を伴わない内部メカニズムを定義します。
Note: The token generation algorithm chosen by the server implementation should be modern and reasonably secure. At the time of the writing of this document, an [HMAC] such as HMAC-SHA1 is recommended.
注：サーバーの実装によって選択されたトークン生成アルゴリズムは、最新で合理的に安全でなければなりません。このドキュメントの執筆時点では、HMAC-Sha1などの[HMAC]が推奨されます。
If it becomes necessary to change the token generation algorithm of the INTERNAL mechanism (e.g., because an attack against the current algorithm has been discovered), all currently existing URLAUTH-authorized URLs are invalidated by the change in algorithm. Since this would be an unpleasant surprise to applications that depend upon the validity of a URLAUTH-authorized URL, and there is no good way to do a bulk update of existing deployed URLs, it is best to avoid this situation by using a secure algorithm as opposed to one that is "good enough".
内部メカニズムのトークン生成アルゴリズムを変更する必要がある場合（たとえば、現在のアルゴリズムに対する攻撃が発見されたため）、現在既存のUrlauthが認可したURLはすべて、アルゴリズムの変化によって無効になります。これは、Urlauthが許可されたURLの有効性に依存するアプリケーションにとって不快な驚きであり、既存の展開されたURLのバルクアップデートを行う良い方法はないため、安全なアルゴリズムを使用してこの状況を回避することをお勧めします。「十分に良い」ものに反対します。
Server implementations SHOULD consider the possibility of changing the algorithm. In some cases, it may be desirable to implement the change of algorithm in a way that newly-generated tokens use the new algorithm, but that for a limited period of time tokens using either the new or old algorithm can be validated. Consequently, the server SHOULD incorporate some means of identifying the token generation algorithm within the token.
サーバーの実装は、アルゴリズムを変更する可能性を考慮する必要があります。場合によっては、新しく生成されたトークンが新しいアルゴリズムを使用する方法でアルゴリズムの変更を実装することが望ましい場合がありますが、新しいまたは古いアルゴリズムを使用して限られた期間トークンを検証できます。したがって、サーバーは、トークン内のトークン生成アルゴリズムを識別する何らかの手段を組み込む必要があります。
Although this specification is extensible for other mechanisms, none are defined in this document. In addition to the mechanism name itself, other mechanisms may have mechanism-specific data, which is to be interpreted according to the definition of that mechanism.
この仕様は他のメカニズムに対して拡張可能ですが、このドキュメントで定義されているものはありません。メカニズム名自体に加えて、他のメカニズムにはメカニズム固有のデータがあり、そのメカニズムの定義に従って解釈される場合があります。
The authorization token is a deterministic string of at least 128 bits that an entity with knowledge of the secret mailbox access key and URL authorization mechanism can use to verify the URL.
承認トークンは、Secret MailboxアクセスキーとURL認証メカニズムの知識を持つエンティティがURLを検証するために使用できる少なくとも128ビットの決定論的な文字列です。
[IMAPURL] is extended by allowing the addition of ";EXPIRE=<datetime>" and ";URLAUTH=<access>:<mech>:<token>" to IMAP URLs that refer to a specific message or message parts.
[imapurl]は、 "; expire = <datetime>"および "; urlauth = <cassion>：<mech>：<token>"を特定のメッセージまたはメッセージパーツを参照するimap URLに追加することで拡張されます。
The URLAUTH is comprised of ";URLAUTH=<access>:<mech>:<token>" and MUST be at the end of the URL.
urlauthは「; urlauth = <cassion>：<mech>：<token>」で構成されており、URLの最後になければなりません。
URLAUTH does not apply to, and MUST NOT be used with, any IMAP URL that refers to an entire IMAP server, a list of mailboxes, an entire IMAP mailbox, or IMAP search results.
Urlauthは、IMAPサーバー全体、メールボックスのリスト、IMAPメールボックス全体、またはIMAP検索結果を指すIMAP URLには適用されず、使用してはなりません。
When ";EXPIRE=<datetime>" is used, this indicates the latest date and time that the URL is valid. After that date and time, the URL has expired, and server implementations MUST reject the URL. If ";EXPIRE=<datetime>" is not used, the URL has no expiration, but still can be revoked as discussed below.
"; expire = <datetime>"が使用されると、これはURLが有効である最新の日付と時刻を示します。その日付と時刻の後、URLの有効期限が切れ、サーバーの実装はURLを拒否する必要があります。"; expire = <datetime>"が使用されない場合、URLには有効期限がありませんが、以下で説明するように取り消すことができます。
The URLAUTH takes the form ";URLAUTH=<access>:<mech>:<token>". It is composed of three parts. The <access> portion provides the authorized access identifiers, which may constrain the operations and users that are permitted to use this URL. The <mech> portion provides the authorization mechanism used by the IMAP server to generate the authorization token that follows. The <token> portion provides the authorization token.
urlauthは "; urlauth = <cassion>：<mech>：<token>" ";3つの部分で構成されています。<access>部分は、承認されたアクセス識別子を提供します。これにより、このURLを使用することが許可されている操作とユーザーが制約される場合があります。<mech>部分は、IMAPサーバーが使用する承認メカニズムを提供して、次のような承認トークンを生成します。<token>部分は、承認トークンを提供します。
The "submit+" access identifier prefix, followed by a userid, indicates that only a userid authorized as a message submission entity on behalf of the specified userid is permitted to use this URL. The IMAP server does not validate the specified userid but does validate that the IMAP session has an authorization identity that is authorized as a message submission entity. The authorized message submission entity MUST validate the userid prior to contacting the IMAP server.
「送信」アクセス識別子プレフィックス、次にユーザーIDが続くと、指定されたユーザーIDに代わってメッセージ提出エンティティとして承認されたユーザーIDのみがこのURLを使用することが許可されていることを示します。IMAPサーバーは、指定されたユーザーIDを検証するものではなく、IMAPセッションにメッセージ提出エンティティとして承認された承認IDがあることを検証します。承認されたメッセージ提出エンティティは、IMAPサーバーに連絡する前に、userIDを検証する必要があります。
The "user+" access identifier prefix, followed by a userid, indicates that use of this URL is limited to IMAP sessions that are logged in as the specified userid (that is, have authorization identity as that userid).
「ユーザー」アクセス識別子プレフィックス、次にユーザーIDが続くと、このURLの使用は、指定されたユーザーIDとしてログインされるIMAPセッションに限定されていることを示しています。
Note: If a SASL mechanism that provides both authorization and authentication identifiers is used to authenticate to the IMAP server, the "user+" access identifier MUST match the authorization identifier.
注：承認識別子と認証識別子の両方を提供するSASLメカニズムがIMAPサーバーに認証されるために使用される場合、「ユーザー」アクセス識別子は承認識別子と一致する必要があります。
The "authuser" access identifier indicates that use of this URL is limited to IMAP sessions that are logged in as an authorized user (that is, have authorization identity as an authorized user) of that IMAP server. Use of this URL is prohibited to anonymous IMAP sessions.
「authuser」アクセス識別子は、このURLの使用が、そのiMAPサーバーの認定ユーザー（つまり、認定ユーザーとしての認定アイデンティティを持っている）としてログインされるIMAPセッションに限定されていることを示しています。このURLの使用は、匿名のIMAPセッションに禁止されています。
The "anonymous" access identifier indicates that use of this URL is not restricted by session authorization identity; that is, any IMAP session in authenticated or selected state (as defined in [IMAP]), including anonymous sessions, may issue a URLFETCH using this URL.
「匿名」アクセス識別子は、このURLの使用がセッション認証IDによって制限されていないことを示しています。つまり、匿名のセッションを含む、認証された状態または選択された状態（[IMAP]で定義されている）でのIMAPセッションは、このURLを使用してURLFetchを発行する場合があります。
The authorization token is represented as an ASCII-encoded hexadecimal string, which is used to authorize the URL. The length and the calculation of the authorization token depends upon the mechanism used; but, in all cases, the authorization token is at least 128 bits (and therefore at least 32 hexadecimal digits).
承認トークンは、URLの承認に使用されるAscii-Encoded Hexadecimal Stringとして表されます。承認トークンの長さと計算は、使用されるメカニズムに依存します。しかし、すべての場合において、承認トークンは少なくとも128ビット（したがって、少なくとも32の16進数桁）です。
In [IMAPURL], the userid before the "@" in the URL has two purposes:
[imapurl]では、URLの「@」の前のユーザーIDには2つの目的があります。
1) It provides context for user-specific mailbox paths such as "INBOX".
1) 「受信トレイ」などのユーザー固有のメールボックスパスのコンテキストを提供します。
2) It specifies that resolution of the URL requires logging in as that user and limits use of that URL to only that user.
2) URLの解像度には、そのユーザーとしてログインする必要があり、そのURLの使用をそのユーザーのみに制限することが指定されています。
An obvious limitation of using the same field for both purposes is that the URL can only be resolved by the mailbox owner.
両方の目的で同じフィールドを使用することの明らかな制限は、URLがメールボックスの所有者によってのみ解決できることです。
URLAUTH overrides the second purpose of the userid in the IMAP URL and by default permits the URL to be resolved by any user permitted by the access identifier.
Urlauthは、IMAP URLのユーザーIDの2番目の目的をオーバーライドし、デフォルトでは、アクセス識別子によって許可されているユーザーによってURLを解決することを許可します。
The "user+<userid>" access identifier limits resolution of that URL to a particular userid, whereas the "submit+<userid>" access identifier is more general and simply requires that the session be authorized by a user that has been granted a "submit" role within the authentication system. Use of either of these access identifiers makes it impossible for an attacker, spying on the session, to use the same URL, either directly or by submission to a message submission entity.
「user <userid>」アクセス識別子は、そのURLの解像度を特定のuserIDに制限しますが、「<userId>」アクセス識別子はより一般的であり、「submis」を付与されたユーザーによってセッションを許可する必要があります。「認証システム内の役割。これらのアクセス識別子のいずれかを使用すると、攻撃者がセッションをスパイし、直接またはメッセージ提出エンティティへの提出により、同じURLを使用することができません。
The "authuser" and "anonymous" access identifiers do not have this level of protection and should be used with caution. These access identifiers are primarily useful for public export of data from an IMAP server, without requiring that it be copied to a web or anonymous FTP server. Refer to the Security Considerations for more details.
「authuser」および「匿名」アクセス識別子には、このレベルの保護がなく、注意して使用する必要があります。これらのアクセス識別子は、Webまたは匿名のFTPサーバーにコピーすることを要求することなく、主にIMAPサーバーからのデータの公開エクスポートに役立ちます。詳細については、セキュリティに関する考慮事項を参照してください。
A URLAUTH-authorized URL is generated from an initial URL as follows:
次のように、初期のURLからurlauthを認めるURLが生成されます。
An initial URL is built, ending with ";URLAUTH=<access>" but without the ":<mech>:<token>" components. An authorization mechanism is selected and used to calculate the authorization token, with the initial URL as the data and a secret known to the IMAP server as the key. The URLAUTH-authorized URL is generated by taking the initial URL and appending ":", the URL authorization mechanism name, ":", and the ASCII-encoded hexadecimal representation of the authorization token.
「; urlauth = <cassion>」で終わる最初のURLが構築されていますが、「：<mech>：<token>」コンポーネントはありません。承認メカニズムが選択され、承認トークンを計算するために使用され、初期URLはデータと秘密をキーとして知られています。Urlauthは、初期のURLを取得し、Appling "："、URL認証メカニズム名 "、"、およびAscii-Encoded authorizationトークンの16進表現によって生成されます。
Note: ASCII-encoded hexadecimal is used instead of BASE64 because a BASE64 representation may have "=" padding characters, which would be problematic in a URL.
注：base64表現には「=」パディング文字がある可能性があるため、Ascii-Encoded Hexadecimalはbase64の代わりに使用されます。これはURLで問題があります。
In the INTERNAL mechanism, the mailbox access key for that mailbox is the secret known to the IMAP server, and a server-selected algorithm is used as described in section 2.4.1.
内部メカニズムでは、そのメールボックスのメールボックスアクセスキーはIMAPサーバーに知られている秘密であり、セクション2.4.1で説明されているように、サーバーが選択したアルゴリズムが使用されます。
A URLAUTH-authorized URL is validated as follows:
urlauth-authorized URLは次のように検証されます。
The URL is split at the ":" that separates "<access>" from "<mech>:<token>" in the ";URLAUTH=<access>:<mech>:<token>" portion of the URL. The "<mech>:<token>" portion is first parsed and saved as the authorization mechanism and the authorization token. The URL is truncated, discarding the ":" described above, to create a "rump URL" (the URL minus the ":" and the "<mech>:<token>" portion). The rump URL is then analyzed to identify the mailbox.
URLは、「<cassion>」から「<mech>：<token>」の「<cassion>」を「<cassion>：<cassion>：<mech>：<token>」のURLの部分から分離する「：」で分割されます。「<mech>：<token>」部分は、最初に解析され、承認メカニズムと承認トークンとして保存されます。URLは切り捨てられ、上記の「：」を破棄して、「rump url」を作成します（urlは「：」と「<mech>：<token>」部分を引いたものです。次に、Rump URLを分析して、メールボックスを識別します。
If the mailbox cannot be identified, an authorization token is calculated on the rump URL, using random "plausible" keys (selected by the server) as needed, before returning a validation failure. This prevents timing attacks aimed at identifying mailbox names.
メールボックスを識別できない場合、検証障害を返す前に、必要に応じて、ランダムな「もっともらしい」キー（サーバーが選択）を使用して、承認トークンがRump URLで計算されます。これにより、メールボックス名の識別を目的としたタイミング攻撃が防止されます。
If the mailbox can be identified, the authorization token is calculated on the rump URL and a secret known to the IMAP server using the given URL authorization mechanism. Validation is successful if, and only if, the calculated authorization token for that mechanism matches the authorization token supplied in ";URLAUTH=<access>:<mech>:<token>".
メールボックスを識別できる場合、承認トークンは、指定されたURL認証メカニズムを使用して、Rump URLとIMAPサーバーに知られている秘密で計算されます。検証は、そのメカニズムの計算された承認トークンが、 "; urlauth = <access>：<mech>：<token>"で提供された承認トークンと一致する場合にのみ成功します。
Removal of the ":<mech>:<token>" portion of the URL MUST be the only operation applied to the URLAUTH-authorized URL to get the rump URL. In particular, URL percent escape decoding and case-folding (including to the domain part of the URL) MUST NOT occur.
「：<mech>：<token>」の削除URLの部分は、Rump URLを取得するためにUrlauthが許可されたURLに適用される唯一の操作でなければなりません。特に、URLパーセントはデコードとケースの折りたたみ（URLのドメイン部分を含む）を発生させてはなりません。
In the INTERNAL mechanism, the mailbox access key for that mailbox is used as the secret known to the IMAP server, and the same server-selected algorithm used for generating URLs is used to calculate the authorization token for verification.
内部メカニズムでは、そのメールボックスのメールボックスアクセスキーはIMAPサーバーに知られている秘密として使用され、URLの生成に使用される同じサーバー選択されたアルゴリズムを使用して、検証のための認証トークンを計算します。
These commands are extensions to the [IMAP] base protocol.
これらのコマンドは、[IMAP]ベースプロトコルへの拡張です。
The section headings of these commands are intended to correspond with where they would be located in the base protocol document if they were part of that document.
これらのコマンドのセクション見出しは、そのドキュメントの一部である場合、ベースプロトコルドキュメントのどこに配置されるかに対応することを目的としています。
BASE.6.3.RESETKEY. RESETKEY Command
base.6.3.ResetKey。リセットキーコマンド
Arguments: optional mailbox name optional mechanism name(s)
引数：オプションのメールボックス名オプションのメカニズム名（s）
Responses: none other than in result
応答：結果以外はありません
Result: OK - RESETKEY completed, URLMECH containing new data
NO - RESETKEY error: can't change key of that mailbox
BAD - command unknown or arguments invalid
The RESETKEY command has two forms.
ResetKeyコマンドには2つのフォームがあります。
The first form accepts a mailbox name as an argument and generates a new mailbox access key for the given mailbox in the user's mailbox access key table, replacing any previous mailbox access key (and revoking any URLs that were authorized with a URLAUTH using that key) in that table. By default, the mailbox access key is generated for the INTERNAL mechanism; other mechanisms can be specified with the optional mechanism argument.
最初のフォームは、メールボックス名を引数として受け入れ、ユーザーのメールボックスアクセスキーテーブルの指定されたメールボックスの新しいメールボックスアクセスキーを生成し、以前のメールボックスアクセスキーを置き換えます（およびそのキーを使用してUrlauthで承認されたURLを取り消す）そのテーブルで。デフォルトでは、内部メカニズムに対してメールボックスアクセスキーが生成されます。他のメカニズムは、オプションのメカニズム引数で指定できます。
The second form, with no arguments, removes all mailbox access keys in the user's mailbox access key table, revoking all URLs currently authorized using URLAUTH by the user.
2番目のフォームでは、引数なしで、ユーザーのメールボックスアクセスキーテーブルのすべてのメールボックスアクセスキーを削除し、ユーザーがUrlauthを使用して現在認定されているすべてのURLを取り消します。
Any current IMAP session logged in as the user that has the mailbox selected will receive an untagged OK response with the URLMECH status response code (see section BASE.7.1.URLMECH for more details about the URLMECH status response code).
メールボックスを選択したユーザーとしてログインした現在のIMAPセッションは、URLMechステータス応答コードを使用してUntagged OK応答を受け取ります（URLMechステータス応答コードの詳細については、セクションBase.7.1.urlmechを参照）。
Example:
例：
C: a31 RESETKEY
S: a31 OK All keys removed
C: a32 RESETKEY INBOX
S: a32 OK [URLMECH INTERNAL] mechs
C: a33 RESETKEY INBOX XSAMPLE
S: a33 OK [URLMECH INTERNAL XSAMPLE=P34OKhO7VEkCbsiYY8rGEg==] done
BASE.6.3.GENURLAUTH. GENURLAUTH Command
Base.6.3.Genurlauth。Genurlauthコマンド
Argument: one or more URL/mechanism pairs
引数：1つ以上のURL/メカニズムペア
Response: untagged response: GENURLAUTH
応答：編集されていない応答：Genurlauth
Result: OK - GENURLAUTH completed
NO - GENURLAUTH error: can't generate a URLAUTH
BAD - command unknown or arguments invalid
The GENURLAUTH command requests that the server generate a URLAUTH-authorized URL for each of the given URLs using the given URL authorization mechanism.
Genurlauthコマンドは、指定されたURL認証メカニズムを使用して、指定された各URLに対して、サーバーがurlauthを認めるURLを生成することを要求します。
The server MUST validate each supplied URL as follows:
サーバーは、次のように提供される各URLを検証する必要があります。
(1) The mailbox component of the URL MUST refer to an existing mailbox.
(1) URLのメールボックスコンポーネントは、既存のメールボックスを参照する必要があります。
(2) The server component of the URL MUST contain a valid userid that identifies the owner of the mailbox access key table that will be used to generate the URLAUTH-authorized URL. As a consequence, the iserver rule of [IMAPURL] is modified so that iuserauth is mandatory.
(2) URLのサーバーコンポーネントには、urlauthが許可されたURLを生成するために使用されるメールボックスアクセスキーテーブルの所有者を識別する有効なユーザーIDを含める必要があります。結果として、[imapurl]のiServerルールが変更されているため、iUserauthが必須です。
Note: the server component of the URL is generally the logged in userid and server. If not, then the logged in userid and server MUST have owner-type access to the mailbox access key table owned by the userid and server indicated by the server component of the URL.
注：URLのサーバーコンポーネントは、通常、ユーザーIDとサーバーに記録されています。そうでない場合は、ユーザーIDとサーバーにログインしている場合、URLのサーバーコンポーネントが示すユーザーIDとサーバーが所有するメールボックスアクセスキーテーブルへの所有者タイプのアクセスが必要です。
(3) There is a valid access identifier that, in the case of "submit+" and "user+", will contain a valid userid. This userid is not necessarily the same as the owner userid described in (2).
(3) 「送信」と「ユーザー」の場合、有効なユーザーIDが含まれる有効なアクセス識別子があります。このユーザーIDは、（2）に記載されている所有者のユーザーIDと必ずしも同じではありません。
(4) The server MAY also verify that the iuid and/or isection components (if present) are valid.
(4) サーバーは、IUIDおよび/またはisectionコンポーネント（存在する場合）が有効であることを確認することもできます。
If any of the above checks fail, the server MUST return a tagged BAD response with the following exception. If an invalid userid is supplied as the mailbox access key owner and/or as part of the access identifier, the server MAY issue a tagged OK response with a generated mailbox key that always fails validation when used with a URLFETCH command. This exception prevents an attacker from validating userids.
上記のチェックのいずれかが失敗した場合、サーバーは次の例外を除いてタグ付けされた悪い応答を返す必要があります。無効なuseridがメールボックスアクセスキーの所有者として、および/またはアクセス識別子の一部として提供されている場合、サーバーは、urlfetchコマンドで使用されたときに常に検証に失敗する生成されたメールボックスキーでタグ付きOK応答を発行する場合があります。この例外により、攻撃者がuserIdsの検証を防ぎます。
If there is currently no mailbox access key for the given mailbox in the owner's mailbox access key table, one is automatically generated. That is, it is not necessary to use RESETKEY prior to first-time use of GENURLAUTH.
現在、所有者のメールボックスアクセスキーテーブルに指定されたメールボックスにメールボックスアクセスキーがない場合、1つは自動的に生成されます。つまり、Genurlauthを初めて使用する前に、Resetkeyを使用する必要はありません。
If the command is successful, a GENURLAUTH response code is returned listing the requested URLs as URLAUTH-authorized URLs.
コマンドが成功した場合、要求されたURLをurlauthが許可したURLとしてリストするGenurlauth応答コードが返されます。
Examples:
例：
C: a775 GENURLAUTH "imap://joe@example.com/INBOX/;uid=20/
;section=1.2" INTERNAL
S: a775 BAD missing access identifier in supplied URL
C: a776 GENURLAUTH "imap://example.com/Shared/;uid=20/
;section=1.2;urlauth=submit+fred" INTERNAL
S: a776 BAD missing owner username in supplied URL
C: a777 GENURLAUTH "imap://joe@example.com/INBOX/;uid=20/
;section=1.2;urlauth=submit+fred" INTERNAL
S: * GENURLAUTH "imap://joe@example.com/INBOX/;uid=20/;section=1.2
;urlauth=submit+fred:internal:91354a473744909de610943775f92038"
S: a777 OK GENURLAUTH completed
BASE.6.3.URLFETCH. URLFETCH Command
base.6.3.urlfetch。urlfetchコマンド
Argument: one or more URLs
引数：1つ以上のURL
Response: untagged response: URLFETCH
応答：Untagged Response：urlfetch
Result: OK - urlfetch completed NO - urlfetch failed due to server internal error BAD - command unknown or arguments invalid
結果：OK -urlfetchが完了しました - サーバー内部エラーのためにurlfetchが失敗しました - コマンド不明または引数が無効です
The URLFETCH command requests that the server return the text data associated with the specified IMAP URLs, as described in [IMAPURL] and extended by this document. The data is returned for all validated URLs, regardless of whether or not the session would otherwise be able to access the mailbox containing that data via SELECT or EXAMINE.
urlfetchコマンドは、[imapurl]で説明され、このドキュメントで拡張されたように、指定されたIMAP URLに関連付けられたテキストデータをサーバーに返すことを要求します。それ以外の場合、セッションが選択または検査を介してそのデータを含むメールボックスにアクセスできるかどうかに関係なく、データはすべての検証済みのURLに対して返されます。
Note: This command does not require that the URL refer to the selected mailbox; nor does it require that any mailbox be selected. It also does not in any way interfere with any selected mailbox.
注：このコマンドでは、URLが選択したメールボックスを参照する必要はありません。また、メールボックスを選択する必要もありません。また、選択したメールボックスに干渉しません。
The URLFETCH command effectively executes with the access of the userid in the server component of the URL (which is generally the userid that issued the GENURLAUTH). By itself, the URLAUTH does NOT grant access to the data; once validated, it grants whatever access to the data is held by the userid in the server component of the URL. That access may have changed since the GENURLAUTH was done.
URLFETCHコマンドは、URLのサーバーコンポーネントにユーザーIDにアクセスすることで効果的に実行されます（一般にGenurlauthを発行したユーザーIDです）。それ自体、Urlauthはデータへのアクセスを許可しません。検証されると、URLのサーバーコンポーネントのユーザーIDが保持しているデータへのアクセスを許可します。そのアクセスは、Genurluthが完了してから変更された可能性があります。
The URLFETCH command MUST return an untagged URLFETCH response and a tagged OK response to any URLFETCH command that is syntactically valid. A NO response indicates a server internal failure that may be resolved on later retry.
URLFETCHコマンドは、UNTAGGED URLFETCH Responseと、構文的に有効な任意のurlfetchコマンドに対するタグ付きOK応答を返す必要があります。NO応答は、後の再試行時に解決される可能性のあるサーバー内部障害を示します。
Note: The possibility of a NO response is to accommodate implementations that would otherwise have to issue an untagged BYE with a fatal error due to an inability to respond to a valid request. In an ideal world, a server SHOULD NOT issue a NO response.
注：対応のない可能性は、有効なリクエストに応答できないため、致命的なエラーを備えた攻撃されていないさようならを発行する必要がある実装に対応することです。理想的な世界では、サーバーは応答なしを発行してはなりません。
The server MUST return NIL for any IMAP URL that references an entire IMAP server, a list of mailboxes, an entire IMAP mailbox, or IMAP search results.
サーバーは、IMAPサーバー全体、メールボックスのリスト、IMAPメールボックス全体、またはIMAP検索結果を参照するIMAP URLに対してnilを返す必要があります。
Example:
例：
Note: For clarity, this example uses the LOGIN command, which SHOULD NOT be used over a non-encrypted communication path.
注：明確にするために、この例ではログインコマンドを使用します。これは、暗号化されていない通信パスで使用しないでください。
This example is of a submit server, obtaining a message segment for a message that it has already validated was submitted by "fred".
この例は、既に検証されているメッセージのメッセージセグメントを取得して、「Fred」によって提出されました。
S: * OK [CAPABILITY IMAP4REV1 URLAUTH] example.com IMAP server
C: a001 LOGIN submitserver secret
S: a001 OK submitserver logged in
C: a002 URLFETCH "imap://joe@example.com/INBOX/;uid=20/
;section=1.2;urlauth=submit+fred:internal
:91354a473744909de610943775f92038"
S: * URLFETCH "imap://joe@example.com/INBOX/;uid=20/;section=1.2
;urlauth=submit+fred:internal
:91354a473744909de610943775f92038" {28}
S: Si vis pacem, para bellum.
S:
S: a002 OK URLFETCH completed
These responses are extensions to the [IMAP] base protocol.
これらの応答は、[IMAP]ベースプロトコルへの拡張です。
The section headings of these responses are intended to correspond with where they would be located in the base protocol document if they were part of that document.
これらの応答のセクション見出しは、そのドキュメントの一部である場合、ベースプロトコルドキュメントのどこに配置されるかに対応することを目的としています。
BASE.7.1.URLMECH. URLMECH Status Response Code
base.7.1.urlmech。urlmechステータス応答コード
The URLMECH status response code is followed by a list of URL authorization mechanism names. Mechanism names other than INTERNAL may be appended with an "=" and BASE64-encoded form of mechanism-specific data.
URLMechステータス応答コードの後に、URL認証メカニズム名のリストが続きます。内部以外のメカニズム名には、メカニズム固有のデータの「=」およびbase64エンコード形式の形式で追加される場合があります。
This status response code is returned in an untagged OK response in response to a RESETKEY, SELECT, or EXAMINE command. In the case of the RESETKEY command, this status response code can be sent in the tagged OK response instead of requiring a separate untagged OK response.
このステータス応答コードは、リセットキー、選択、または審査コマンドに応じて、じゃがいになっていないOK応答で返されます。ResetKeyコマンドの場合、このステータス応答コードは、個別の未積載されたOK応答を必要とする代わりに、タグ付きOK応答で送信できます。
Example:
例：
C: a33 RESETKEY INBOX XSAMPLE
S: a33 OK [URLMECH INTERNAL XSAMPLE=P34OKhO7VEkCbsiYY8rGEg==] done
In this example, the server supports the INTERNAL mechanism and an experimental mechanism called XSAMPLE, which also holds some mechanism-specific data (the name "XSAMPLE" is for illustrative purposes only).
この例では、サーバーはXsampleと呼ばれる内部メカニズムと実験メカニズムをサポートします。これは、いくつかのメカニズム固有のデータも保持します（「Xsample」という名前は、説明のみを目的としています）。
BASE.7.4.GENURLAUTH. GENURLAUTH Response
Base.7.4.Genurlauth。Genurluth応答
Contents: One or more URLs
内容：1つ以上のURL
The GENURLAUTH response returns the URLAUTH-authorized URL(s) requested by a GENURLAUTH command.
Genurlauthの応答は、Genurlauthコマンドによって要求されたUrlauthを認めるURLを返します。
Example:
例：
C: a777 GENURLAUTH "imap://joe@example.com/INBOX/;uid=20/
;section=1.2;urlauth=submit+fred" INTERNAL
S: * GENURLAUTH "imap://joe@example.com/INBOX/;uid=20/;section=1.2
;urlauth=submit+fred:internal:91354a473744909de610943775f92038"
S: a777 OK GENURLAUTH completed
BASE.7.4.URLFETCH. URLFETCH Response
base.7.4.urlfetch。urlfetch応答
Contents: One or more URL/nstring pairs
内容：1つ以上のURL/nStringペア
The URLFETCH response returns the message text data associated with one or more IMAP URLs, as described in [IMAPURL] and extended by this document. This response occurs as the result of a URLFETCH command.
urlfetch応答は、[imapurl]で説明され、このドキュメントで拡張されたように、1つ以上のIMAP URLに関連付けられたメッセージテキストデータを返します。この応答は、urlfetchコマンドの結果として発生します。
The returned data string is NIL if the URL is invalid for any reason (including validation failure). If the URL is valid, but the IMAP fetch of the body part returned NIL (this should not happen), the returned data string should be the empty string ("") and not NIL.
返されたデータ文字列は、何らかの理由でURLが無効である場合はゼロです（検証障害を含む）。URLが有効であるが、ボディパーツのIMAPフェッチがnilを返した場合（これは発生しないはずです）、返されたデータ文字列は空の文字列（ ""）であり、nilではなく、nilでなければなりません。
Note: This command does not require that the URL refer to the selected mailbox; nor does it require that any mailbox be selected. It also does not in any way interfere with any selected mailbox.
注：このコマンドでは、URLが選択したメールボックスを参照する必要はありません。また、メールボックスを選択する必要もありません。また、選択したメールボックスに干渉しません。
Example:
例：
C: a002 URLFETCH "imap://joe@example.com/INBOX/;uid=20/
;section=1.2;urlauth=submit+fred:internal
:91354a473744909de610943775f92038"
S: * URLFETCH "imap://joe@example.com/INBOX/;uid=20/;section=1.2
;urlauth=submit+fred:internal
:91354a473744909de610943775f92038" {28}
S: Si vis pacem, para bellum.
S:
S: a002 OK URLFETCH completed
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [ABNF].
次の構文仕様では、[ABNF]で指定されているように、拡張されたBackus-Naurフォーム（ABNF）表記を使用します。
The following modifications are made to the Formal Syntax in [IMAP]:
[IMAP]の正式な構文には、次の変更が行われます。
resetkey = "RESETKEY" [SP mailbox *(SP mechanism)]
resetkey = "resetkey" [sp mailbox *（spメカニズム）]
capability =/ "URLAUTH"
command-auth =/ resetkey / genurlauth / urlfetch
resp-text-code =/ "URLMECH" SP "INTERNAL" *(SP mechanism ["=" base64])
genurlauth = "GENURLAUTH" 1*(SP url-rump SP mechanism)
genurlauth = "genurlauth" 1*（sp url-rump spメカニズム）
genurlauth-data = "*" SP "GENURLAUTH" 1*(SP url-full)
url-full = astring
; contains authimapurlfull as defined below
url-rump = astring ; contains authimapurlrump as defined below
url-rump = astring;以下に定義するように、authimapurlrumpが含まれています
urlfetch = "URLFETCH" 1*(SP url-full)
urlfetch = "urlfetch" 1*（sp url-full）
urlfetch-data = "*" SP "URLFETCH" 1*(SP url-full SP nstring)
The following extensions are made to the Formal Syntax in [IMAPURL]:
[imapurl]の正式な構文には、次の拡張が行われます。
authimapurl = "imap://" enc-user [iauth] "@" hostport "/" imessagepart ; replaces "imapurl" and "iserver" rules for ; URLAUTH authorized URLs
authimapurl = "imap：//" enc-user [iauth] "@" hostport "/" imessagepart;「imapurl」および「iserver」ルールを置き換えます。urlauth認定URL
authimapurlfull = authimapurl iurlauth
authimapurlrump = authimapurl iurlauth-rump
enc-urlauth = 32*HEXDIG
enc-urlauth = 32*hexdig
enc-user = 1*achar
; same as "enc_user" in RFC 2192
iurlauth = iurlauth-rump ":" mechanism ":" enc-urlauth
iurlauth-rump = [expire] ";URLAUTH=" access
access = ("submit+" enc-user) / ("user+" enc-user) /
"authuser" / "anonymous"
expire = ";EXPIRE=" date-time
; date-time defined in [DATETIME]
mechanism = "INTERNAL" / 1*(ALPHA / DIGIT / "-" / ".")
; case-insensitive
; new mechanisms MUST be registered with IANA
Security considerations are discussed throughout this memo.
このメモ全体でセキュリティ上の考慮事項について説明します。
The mailbox access key SHOULD have at least 128 bits of entropy (refer to [RANDOM] for more details) and MUST be unpredictable.
メールボックスアクセスキーには、少なくとも128ビットのエントロピーが必要である必要があります（詳細については[ランダム]を参照）、予測不可能である必要があります。
The server implementation of the INTERNAL mechanism SHOULD consider the possibility of needing to change the token generation algorithm, and SHOULD incorporate some means of identifying the token generation algorithm within the token.
内部メカニズムのサーバーの実装では、トークン生成アルゴリズムを変更する必要がある可能性を考慮し、トークン内のトークン生成アルゴリズムを識別する何らかの手段を組み込む必要があります。
The URLMECH status response code may expose sensitive data in the mechanism-specific data for mechanisms other than INTERNAL. A server implementation MUST implement a configuration that will not return a URLMECH status response code unless some mechanism is provided that protects the session from snooping, such as a TLS or SASL security layer that provides confidentiality protection.
URLMechステータス応答コードは、内部以外のメカニズムのメカニズム固有のデータに機密データを公開する場合があります。サーバーの実装は、秘密保護を提供するTLSやSASLセキュリティレイヤーなど、セッションをスヌーピングから保護するメカニズムが提供されない限り、URLMechステータス応答コードを返さない構成を実装する必要があります。
The calculation of an authorization token with a "plausible" key if the mailbox can not be identified is necessary to avoid attacks in which the server is probed to see if a particular mailbox exists on the server by measuring the amount of time taken to reject a known bad name versus some other name.
メールボックスを識別できない場合の「もっともらしい」キーを使用した認証トークンの計算は、サーバーが調査されるためにサーバーが調査されるかどうかを確認する攻撃を避けるために必要です。既知の悪い名前と他の名前。
To protect against a computational denial-of-service attack, a server MAY impose progressively longer delays on multiple URL requests that fail validation.
計算拒否攻撃から保護するために、サーバーは、検証に失敗した複数のURL要求に徐々に長い遅延を課す場合があります。
The decision to use the "authuser" access identifier should be made with caution. An "authuser" access identifier can be used by any authorized user of the IMAP server; therefore, use of this access identifier should be limited to content that may be disclosed to any authorized user of the IMAP server.
「authuser」アクセス識別子を使用する決定は、注意して行う必要があります。IMAPサーバーの承認されたユーザーが「authuser」アクセス識別子を使用できます。したがって、このアクセス識別子の使用は、IMAPサーバーの承認されたユーザーに開示される可能性のあるコンテンツに限定する必要があります。
The decision to use the "anonymous" access identifier should be made with extreme caution. An "anonymous" access identifier can be used by anyone; therefore, use of this access identifier should be limited to content that may be disclosed to anyone. Many IMAP servers do not permit anonymous access; in this case, the "anonymous" access identifier is equivalent to "authuser", but this MUST NOT be relied upon.
「匿名」アクセス識別子を使用する決定は、非常に注意して行う必要があります。「匿名」アクセス識別子は誰でも使用できます。したがって、このアクセス識別子の使用は、誰にでも開示される可能性のあるコンテンツに限定する必要があります。多くのIMAPサーバーは、匿名のアクセスを許可していません。この場合、「匿名」アクセス識別子は「authuser」と同等ですが、これに依存してはなりません。
Although this specification does not prohibit the theoretical capability to generate a URL with a server component other than the logged in userid and server, this capability should only be provided when the logged in userid/server has been authorized as equivalent to the server component userid/server, or otherwise has access to that userid/server mailbox access key table.
この仕様では、ユーザーIDおよびサーバーに記録されたサーバーコンポーネントを使用してURLを生成する理論的機能は禁止されていませんが、この機能は、ユーザーID/サーバーに記録されたサーバーがサーバーコンポーネントに相当するものとして承認されている場合にのみ提供する必要があります。サーバー、またはその他のユーザーID/サーバーメールボックスアクセスキーテーブルにアクセスできます。
This document constitutes registration of the URLAUTH capability in the imap4-capabilities registry.
このドキュメントでは、IMAP4-キャピリティレジストリにおけるUrlauth機能の登録を構成します。
URLAUTH authorization mechanisms are registered by publishing a standards track or IESG-approved experimental RFC. The registry is currently located at:
Urlauth認証メカニズムは、標準トラックまたはIESGが承認した実験RFCを公開することにより登録されます。レジストリは現在、次のようにしています。
http://www.iana.org/assignments/urlauth-authorization-mechanism-registry
This registry is case-insensitive.
このレジストリはケースに依存しません。
This document constitutes registration of the INTERNAL URLAUTH authorization mechanism.
このドキュメントは、内部のurlauth認証メカニズムの登録を構成します。
IMAP URLAUTH Authorization Mechanism Registry
IMAP Urlauth認証メカニズムレジストリ
Mechanism Name Reference
-------------- ---------
INTERNAL [RFC4467]
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[ABNF] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 4234、2005年10月。
[BURL] Newman, C., "Message Submission BURL Extension", RFC 4468, May 2006.
[Burl] Newman、C。、「Message Submission Burl Extension」、RFC 4468、2006年5月。
[DATETIME] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.
[DateTime] Klyne、G。and C. Newman、「インターネット上の日時：タイムスタンプ」、RFC 3339、2002年7月。
[IMAP] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 3501, March 2003.
[IMAP] Crispin、M。、「インターネットメッセージアクセスプロトコル -バージョン4REV1」、RFC 3501、2003年3月。
[IMAPURL] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997.
[Imapurl] Newman、C。、「IMAP URLスキーム」、RFC 2192、1997年9月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[HMAC] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：メッセージ認証のためのキー付きハッシング」、RFC 2104、1997年2月。
[RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[ランダム] Eastlake、D.、3rd、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、BCP 106、RFC 4086、2005年6月。
Author's Address
著者の連絡先
Mark R. Crispin Networks and Distributed Computing University of Washington 4545 15th Avenue NE Seattle, WA 98105-4527
マークR.クリスピンネットワークと分散コンピューティングワシントン大学4545 15th Avenue NEシアトル、ワシントン州98105-4527
Phone: (206) 543-5762 EMail: MRC@CAC.Washington.EDU
電話：（206）543-5762メール：mrc@cac.washington.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。