Page 26

　
7.  Security Considerations

The following security considerations apply when adding or processing the “Authentication-Results” header field:

7.  セキュリティに関する考察

“Authentication-Results”ヘッダフィールドを追加または処理する際には、以下のセキュリティに関する考察が適用される。

7.1.  Forged Header Fields

An MUA or filter that accesses a mailbox whose mail is handled by a non-conformant MTA, and understands Authentication-Results header fields, could potentially make false conclusions based on forged header fields.  A malicious user or agent could forge a header field using the DNS domain of a receiving ADMD as the authserv-id token in the value of the header field, and with the rest of the value claim that the message was properly authenticated.  The non-conformant MTA would fail to strip the forged header field, and the MUA could inappropriately trust it.

7.1.  偽のヘッダフィールド

Authentication-Resultsヘッダフィールドを理解しているMUAまたはフィルタが本仕様に準拠していないMTAが扱うメールのmailboxにアクセスする場合、偽のヘッダフィールドに基づいた偽の認証結果を生成してしまう可能性がある。悪意を持ったユーザまたはエージェントは、本ヘッダフィールドの値に含まれるauthserv-idトークンとして受信ADMDのDNSドメインを用いたヘッダフィールドを偽装し、値の他の部分でメッセージが正しく認証されたと主張する可能性もあるだろう。本仕様に準拠していないMTAが偽のヘッダフィールドを削除できず、MUAが不適切にそのヘッダフィールドを信頼してしまうこともあり得る。

It is for this reason an MUA should not have processing of the “Authentication-Results” header field enabled by default; instead it should be ignored, at least for the purposes of enacting filtering decisions, unless specifically enabled by the user or administrator after verifying that the border MTA is compliant.  It is acceptable to have an MUA aware of this specification, but have an explicit list of hostnames whose “Authentication-Results” header fields are trustworthy; however, this list should initially be empty.

この理由のため、MUAは“Authentication-Results”ヘッダフィールドの処理を指定のない場合に有効にしておくべきではない。むしろ、少なくともフィルタリング判断を行うという目的のためには、境界MTAが本仕様に準拠していることを検証した上で特にユーザまたは管理者によって有効化されない限りこのヘッダフィールドを無視すべきである。MUAが本仕様を解釈できるようにしておくことは許容できるが、“Authentication-Results”ヘッダフィールドを信頼できるホスト名の明示的な一覧を用意すること。ただし、この一覧は当初は空であるべきである。

Proposed alternate solutions to this problem are nascent:

1.  Possibly the simplest is a digital signature protecting the header field, such as using [DKIM], that can be verified by an MUA by using a posted public key.  Although one of the main purposes of this memo is to relieve the burden of doing message authentication work at the MUA, this only requires that the MUA learn a single authentication scheme even if a number of them are in use at the border MTA.  Note that [DKIM] requires that the From header field be signed, although in this application, the signing agent (a trusted MTA) likely cannot authenticate that value, so the fact that it is signed should be ignored.

この問題の解決策としては以下の方法が考えられる。

1.　おそらく最も簡単な方法は、[DKIM]で使われているような、公開されている公開鍵を使ってMUAが検証できる電子署名でヘッダフィールドを保護することだ。本文書の主な目的の1つはMUAでメッセージ認証処理を行う負荷を軽減することだが、この方法なら、境界MTAでは多数の認証機構が使われている場合でもMUAが実装する認証機構は1つで済む。本仕様では署名するエージェント（信頼されるMTA）がその値を認証できないと思われるため、署名されたという事実は無視されるべきであるが、[DKIM]はFromヘッダフィールドが署名されるよう要求していることには注意が必要だ。

2.  Another would be a means to interrogate the MTA that added the header field to see if it is actually providing any message authentication services and saw the message in question, but this isn’t especially palatable given the work required to craft and implement such a scheme.

2.　別の方法としては、ヘッダフィールドを追加したMTAが実際に何らかのメッセージ認証サービスを提供しているのか、またそのメッセージを検査したのかを確かめるため、そのMTAに問い合わせる手段を用意することだ。しかし、このような機構を作成および実装するために必要な作業を考えると、この対策は特によい方法ではない。

3.  Yet another might be a method to interrogate the internal MTAs that apparently handled the message (based on Received: header fields) to determine whether any of them conform to Section 5 of this memo.  This, too, has potentially high barriers-to-entry.

3.　また別の方法としては、（Received：ヘッダフィールドに基づいて）明らかにメッセージを扱った内部MTAに問い合わせを行って、本文書の5章に準拠しているAuthentication-Resultsヘッダフィールドがあるかを判断する方法があるかもしれない。この方法もまた、導入にはおそらく高い障壁があるだろう。

[Page 26]