1
2
3
4
5
6
7Internet Engineering Task Force (IETF) M. Kucherawy
8Request for Comments: 6008 Cloudmark, Inc.
9Category: Standards Track September 2010
10ISSN: 2070-1721
11
12
13 Authentication-Results Registration for Differentiating
14 among Cryptographic Results
15
16Abstract
17
18 This memo updates the registry of properties in Authentication-
19 Results: message header fields to allow a multiple-result report to
20 distinguish among one or more cryptographic signatures on a message,
21 thus associating specific results with the signatures they represent.
22
23Status of This Memo
24
25 This is an Internet Standards Track document.
26
27 This document is a product of the Internet Engineering Task Force
28 (IETF). It represents the consensus of the IETF community. It has
29 received public review and has been approved for publication by the
30 Internet Engineering Steering Group (IESG). Further information on
31 Internet Standards is available in Section 2 of RFC 5741.
32
33 Information about the current status of this document, any errata,
34 and how to provide feedback on it may be obtained at
35 http://www.rfc-editor.org/info/rfc6008.
36
37Copyright Notice
38
39 Copyright (c) 2010 IETF Trust and the persons identified as the
40 document authors. All rights reserved.
41
42 This document is subject to BCP 78 and the IETF Trust's Legal
43 Provisions Relating to IETF Documents
44 (http://trustee.ietf.org/license-info) in effect on the date of
45 publication of this document. Please review these documents
46 carefully, as they describe your rights and restrictions with respect
47 to this document. Code Components extracted from this document must
48 include Simplified BSD License text as described in Section 4.e of
49 the Trust Legal Provisions and are provided without warranty as
50 described in the Simplified BSD License.
51
52
53
54
55
56
57
58Kucherawy Standards Track [Page 1]
59
60RFC 6008 Auth-Results Header.b Registration September 2010
61
62
63Table of Contents
64
65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
66 2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
67 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 2
68 4. Definition . . . . . . . . . . . . . . . . . . . . . . . . . . 3
69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
70 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
71 6.1. Improvement . . . . . . . . . . . . . . . . . . . . . . . . 4
72 6.2. Result Forgeries . . . . . . . . . . . . . . . . . . . . . 4
73 6.3. New Schemes with Small Signatures . . . . . . . . . . . . . 4
74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
75 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5
76 7.2. Informative References . . . . . . . . . . . . . . . . . . 5
77 Appendix A. Authentication-Results Example . . . . . . . . . . . . 6
78 A.1. Multiple DKIM Signatures with One Failure . . . . . . . . . 6
79 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . . 7
80
811. Introduction
82
83 [AUTHRES] defined a new header field for electronic mail messages
84 that presents the results of a message authentication effort in a
85 machine-readable format. Absent from that specification was the
86 means by which the results of two cryptographic signatures, such as
87 those provided by [DKIM], can both have results reported in an
88 unambiguous manner.
89
90 Fortunately, [AUTHRES] created IANA registries of reporting
91 properties, enabling an easy remedy for this problem. This memo thus
92 registers an additional reporting property allowing a result to be
93 associated with a specific digital signature.
94
952. Keywords
96
97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
99 document are to be interpreted as described in [KEYWORDS].
100
1013. Discussion
102
103 A message can contain multiple signatures of a common sender
104 authentication mechanism, such as [DKIM]. For example, a DomainKeys
105 Identified Mail (DKIM) signer could apply signatures using two or
106 more different message canonicalization algorithms to determine the
107 resistance of each to being broken in transit.
108
109
110
111
112
113
114Kucherawy Standards Track [Page 2]
115
116RFC 6008 Auth-Results Header.b Registration September 2010
117
118
119 By applying supported "ptype.property" combinations (cf. the ABNF in
120 [AUTHRES]), a result can be associated with a given signature
121 provided the signatures are all unique within one of the registered
122 values (e.g., all of them had unique "header.d" or "header.i"
123 values). This is not guaranteed, however; a single signing agent
124 might have practical reasons for affixing multiple signatures with
125 the same "d=" values while varying other signature parameters. This
126 means one could get a "dkim=pass" and "dkim=fail" result
127 simultaneously on verification, which is clearly ambiguous.
128
129 It is thus necessary either to create or to identify a signature
130 attribute guaranteed to be unique, such that it is possible to
131 unambiguously associate a result with the signature to which it
132 refers.
133
134 Collisions during general use of SHA1 and SHA256 are uncommon (see
135 [HASH-ATTACKS]), and RSA key signing mechanisms are resilient to
136 producing common substrings. Thus, the actual digital signature for
137 a cryptographic signing of the message is an ideal property for such
138 a unique identification. It is not, however, necessary to include
139 the entire digital signature in an [AUTHRES] header field just to
140 identify which result goes with which signature; since the signatures
141 will almost always be substantially different, it is anticipated that
142 only the first several bytes of a signature will be needed for
143 disambiguating results.
144
1454. Definition
146
147 This memo adds the "header.b" reporting item to the IANA "Email ../smtpserver/server.go:2455
148 Authentication Methods" registry created upon publication of
149 [AUTHRES]. The value associated with this item in the header field
150 MUST be at least the first eight characters of the digital signature
151 (the "b=" tag from a DKIM-Signature) for which a result is being
152 relayed, and MUST be long enough to be unique among the results being
153 reported. Where the total length of the digital signature is fewer
154 than eight characters, the entire signature MUST be included.
155 Matching of the value of this item against the signature itself MUST
156 be case-sensitive.
157
158 If an evaluating agent observes that, despite the use of this
159 disambiguating tag, unequal authentication results are offered about
160 the same signature from the same trusted authserv-id, that agent
161 SHOULD ignore all such results.
162
163
164
165
166
167
168
169
170Kucherawy Standards Track [Page 3]
171
172RFC 6008 Auth-Results Header.b Registration September 2010
173
174
1755. IANA Considerations
176
177 Per [IANA-CONSID], the following item is added to the "Email
178 Authentication Methods" registry:
179
180 +------------+----------+--------+----------------+-----------------+
181 | Method | Defined | ptype | property | value |
182 +------------+----------+--------+----------------+-----------------+
183 | dkim | RFC4871 | header | b | full or partial |
184 | | | | | value of |
185 | | | | | signature "b" |
186 | | | | | tag |
187 +------------+----------+--------+----------------+-----------------+
188
1896. Security Considerations
190
191 [AUTHRES] discussed general security considerations regarding the use
192 of this header field. The following new security considerations
193 apply when adding or processing this new ptype/property combination:
194
1956.1. Improvement
196
197 Rather than introducing a new security issue, this can be seen to fix
198 a security weakness of the original specification: Useful information
199 can now be obtained from results that could previously have been
200 ambiguous and thus obscured or, worse, misinterpreted.
201
2026.2. Result Forgeries
203
204 An attacker could copy a valid signature and add it to a message in
205 transit, modifying some portion of it. This could cause two results
206 to be provided for the same "header.b" value even if the entire "b="
207 string is used in an attempt to differentiate the results. This
208 attack could cause an ambiguous result to be relayed and possibly
209 neutralize any benefit given to a "pass" result that would have
210 otherwise occurred, possibly impacting the delivery of valid
211 messages.
212
213 It is worth noting, however, that a false negative ("fail") can be
214 generated in this way, but it is extremely difficult to create a
215 false positive ("pass") through such an attack. Thus, a cautious
216 implementation could discard the false negative in that instance.
217
2186.3. New Schemes with Small Signatures
219
220 Should a new signing scheme be introduced with a signature whose
221 length is less than eight characters, Section 4 specifies that the
222 entire signature must be used. The obvious concern in such a case
223
224
225
226Kucherawy Standards Track [Page 4]
227
228RFC 6008 Auth-Results Header.b Registration September 2010
229
230
231 would be that the signature scheme is itself prone to collisions,
232 making the value reported by this field not useful. In such cases,
233 the risk is created by the likelihood of collisions and not by this
234 mechanism; furthermore, Section 4 recommends the results be ignored
235 if that were to occur, preventing the application of an ambiguous
236 result.
237
2387. References
239
2407.1. Normative References
241
242 [AUTHRES] Kucherawy, M., "Message Header Field for Indicating
243 Message Authentication Status", RFC 5451, April 2009.
244
245 [DKIM] Allman, E., Callas, J., Delany, M., Libbey, M.,
246 Fenton, J., and M. Thomas, "DomainKeys Identified
247 Mail (DKIM) Signatures", RFC 4871, May 2007.
248
249 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
250 Requirement Levels", BCP 14, RFC 2119, March 1997.
251
2527.2. Informative References
253
254 [HASH-ATTACKS] Hoffman, P. and B. Schneier, "Attacks on
255 Cryptographic Hashes in Internet Protocols",
256 RFC 4270, November 2005.
257
258 [IANA-CONSID] Narten, T. and H. Alvestrand, "Guidelines for Writing
259 an IANA Considerations Section in RFCs", BCP 26,
260 RFC 5226, May 2008.
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282Kucherawy Standards Track [Page 5]
283
284RFC 6008 Auth-Results Header.b Registration September 2010
285
286
287Appendix A. Authentication-Results Example
288
289 This section presents an example of the use of this new item header
290 field to indicate unambiguous authentication results.
291
292A.1. Multiple DKIM Signatures with One Failure
293
294 A message that had two DKIM signatures applied by the same domain,
295 one of which failed:
296
297 Authentication-Results: mail-router.example.net;
298 dkim=pass (good signature) header.d=newyork.example.com
299 header.b=oINEO8hg;
300 dkim=fail (bad signature) header.d=newyork.example.com
301 header.b=EToRSuvU
302 Received: from newyork.example.com
303 (newyork.example.com [192.0.2.250])
304 by mail-router.example.net (8.11.6/8.11.6)
305 for <recipient@example.net>
306 with ESMTP id i7PK0sH7021929;
307 Fri, Feb 15 2002 17:19:22 -0800
308 DKIM-Signature: v=1; a=rsa-sha256; s=rashani;
309 d=newyork.example.com;
310 t=1188964191; c=relaxed/simple;
311 h=From:Date:To:Message-Id:Subject;
312 bh=sEu28nfs9fuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m7=;
313 b=oINEO8hgn/gnunsg ... 9n9ODSNFSDij3=
314 DKIM-Signature: v=1; a=rsa-sha256; s=rashani;
315 d=newyork.example.com;
316 t=1188964191; c=simple/simple;
317 h=From:Date:To:Message-Id:Subject;
318 bh=sEu28nfs9fuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m7=;
319 b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM=
320 From: sender@newyork.example.com
321 Date: Fri, Feb 15 2002 16:54:30 -0800
322 To: meetings@example.net
323 Message-Id: <12345.abc@newyork.example.com>
324 Subject: here's a sample
325
326 Example 1: Header field reporting results from multiple signatures
327 added at initial signing
328
329 Here we see an example of a message that was signed twice by the
330 author's ADministrative Management Domain (ADMD). One signature used
331 "relaxed" header canonicalization, and the other used "simple" header
332 canonicalization; both used "simple" body canonicalization.
333
334
335
336
337
338Kucherawy Standards Track [Page 6]
339
340RFC 6008 Auth-Results Header.b Registration September 2010
341
342
343 Presumably due to a change in one of the five header fields covered
344 by the two signatures, the former signature passed, while the latter
345 signature failed to verify. In particular, the "relaxed" header
346 canonicalization of [DKIM] is resilient to changes in whitespace in
347 the header, while "simple" is not, and the latter is the one that
348 failed in this example.
349
350 The item registered by this memo allows an evaluation module to
351 determine which DKIM result goes with which signature. Without the
352 "header.b" portion of the result, it is unclear which one passed and
353 which one failed.
354
355Appendix B. Acknowledgements
356
357 The author wishes to acknowledge the following for their review and
358 constructive criticism of this proposal: Dave Crocker, Tony Hansen,
359 Eliot Lear, S. Moonesamy, and Alessandro Vesely.
360
361Author's Address
362
363 Murray S. Kucherawy
364 Cloudmark, Inc.
365 128 King St., 2nd Floor
366 San Francisco, CA 94107
367 US
368
369 Phone: +1 415 946 3800
370 EMail: msk@cloudmark.com
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394Kucherawy Standards Track [Page 7]
395
396